问迁移到Microservices时的最佳做法

EN

经验法则是在有界上下文的基础上打破一元论。定义有界上下文的最常见方法是使用BU (业务单元)。例如，进行实际支付的模块主要是一个单独的BU。

要考虑的第二件事是微型服务带来的间接费用。在完全中断服务之前，您应该分析硬件、监控和子部件。我看到的是人们从monolith中拿出较小的微服务，而不是去写作，比如10项新服务，并对monolith进行贬值。

我的建议是采取渐进的办法。以第一个BU为例，它是从单块石上开始工作的。这也将给整个团队的学习曲线。

您应该清楚地区分子域区域(有界上下文)和您的域。

通常(如果您的体系结构很好的话)，您已经在您的单核应用程序中有了一些独立的组件，它们负责每个子域。这些组件在一个流程中相互交互(在monolith应用程序中)，您应该考虑如何将它们放到不同的进程中。当然，当将一体机的各个部分移动到微服务时，您需要进行大量的重构。

请记住，每个微服务都负责某些子域。

我强烈建议您学习域驱动的设计。

• 领域驱动设计:解决软件核心中的复杂性问题
• 用Vaughn Vernon实现领域驱动设计

还可以学习CQRS模式

在开始时，您还应该决定您的micservices将如何相互交互。有几种选择：

• 从一个服务到另一个服务的直接呼叫
• 通过一些dispatcher服务发送消息，该服务将客户端服务从被调用(目标)服务所在的位置提取出来。这种方法类似于像NGINX这样的代理服务器的工作方式。
• 通过一些消息传递总线(中间件)进行交互，如RabbitMQ

您可以组合这些选项，例如，可以通过Dispatcher Service处理查询请求，通过消息总线处理命令和事件。

根据我的经验，最大的问题将是离开单一的数据库，该数据库通常使用monolith应用程序。

此外，还有一些良好做法：

• 将每个微服务放在自己的存储库中--这与在另一个存储库中直接使用一个微服务的代码的能力相分离。您还可以在CI上获得更快的签出和每个微服务的构建。
• 与任何服务的交互只能通过其公共契约进行。
• 有必要期望每个微服务都有自己的数据库。

一些旅游业应用的子域(有界上下文)的例子。每个有界上下文都可以由一个微服务来服务。

​

​

我们也开始了一段时间的旅程，我开始为同样的事情写博客系列：https://dzone.com/articles/how-i-started-my-journey-in-micro-services-and-how。

基本上我理解的是用不同的方法解决我的问题。微服务，我需要一个设计框架，领域驱动的设计给(领域驱动的设计蒸馏书Vaugh Vernon)。

然后实现设计(使用CQRS和事件源和.)我需要一个提供上述所有支持的框架。

我觉得拉格姆对此很有好处。(最终，是其他一些选择)。

基于Microsoft的领域驱动设计的Microservices领域分析示例：https://learn.microsoft.com/en-us/azure/architecture/microservices/domain-analysis

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

在阅读了域驱动设计之后，我认为lagom和上面的链接将帮助您构建一个端到端的应用程序。如仍有疑问，请提出:)