迁移到微服务的最佳实践

Question

对于任何具有真实世界经验的人将单块服务器分解为单独的模块和服务。

我在问这个问题已经阅读Martin Fowler的博客文章MonolithFirst。当拿一块巨石并将其分解成微服务时，等式中的“大小”元素是我思考最多的一个元素。具体来说，如何将微型服务（我们正在谈论2001年：一种太空奥德西;因为它是那么古老和那么大）应用到微服务中，而不会过度细化或过于单一。最终目标是创建独立模块，可以独立升级并独立调整。

基于个人体验将整体转换为微服务的一些推荐最佳实践是什么？

Answer 1

经验法则打破巨石基于有界的上下文。定义有界环境的最常用方法是使用BU（业务单位）。例如，实际支付的模块大多是单独的BU。

第二件要考虑的问题是开销微服务带来的问题。在完全中断服务之前，您应该分析硬件，监控和基础设施。我所看到的是，人们将小型微服务从庞然大物中拿出来，而不是去写新的服务，并贬低庞然大物。

我的建议将会有一个渐进的方法。拿出第一个正在使用的单块BU。这也将为整个团队提供一个goos学习曲线。

Answer 2

您应该明确地区分与您域的子域区域（有界上下文）。

通常（如果您的架构一切正常），您的monolith应用程序中已经有一些单独的组件，负责每个子域。这些组件在一个进程 （在整体应用程序中）相互作用，您应该考虑如何将它们放入单独的进程中。当然，当将整体的各个部分移动到微服务时，您需要进行大量的重构。

请务必记住，每个微服务都负责某个子域。我们强烈建议您学习Domain Driven Design。

• Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
• Implementing Domain-Driven Design by Vaughn Vernon

而且学习CQRS pattern

在你还应该决定你的micservices将如何彼此交互的开始。 有几种选择：从一个服务到另一个

• 直接调用
• 通过一些调度服务 它抽象从哪里调用（目标）服务位于知识的客户服务发送消息。 这种方法类似于NGINX这样的代理服务器。
• 互动通过一些消息总线（中间件），像RabbitMQ

您可以组合这些选项，例如查询请求可以通过调度服务，命令和事件通过消息总线进行处理。

从我的经验来看，最大的问题将是远离单个数据库， 哪个monolith应用程序通常使用。

另外一些好的做法：

• 将在自己的仓库中为每个微服务 - 从直接使用一个微服务的代码在其他的能力这株。 您还可以在CI上获得更快的签出和每个微服务的构建。
• 与任何服务的互动只能通过其公共合同进行。
• 是必要的向往，每个微服务都有自己的数据库子域（界上下文）的一些旅游行业应用的

例。 每个有界的上下文可以由微服务提供服务。

Answer 3

我们也开始我们的旅程一段时间回来，我开始写博客系列完全一样的东西：https://dzone.com/articles/how-i-started-my-journey-in-micro-services-and-how

基本上我的理解是要打破我的问题的差异。微服务，我需要一个Domain Driven Design给出的设计框架（Vaugh Vernon的Domain Driven Design蒸馏书）。

然后执行设计（使用CQRS和事件采购和...）我需要一个框架，提供所有上述支持。

我发现Lagom对此很有帮助（Eventuate，Spring Microservices是其他一些选择）。

样品使用领域驱动设计由微软微服务领域分析：https://docs.microsoft.com/en-us/azure/architecture/microservices/domain-analysis

还有一个分析是：http://cqrs.nu/tutorial/cs/01-design

阅读领域驱动设计后，我觉得lagom以上链接将帮助你建立一个结束最终应用。如果还有疑问，请提出:)