致任何有实际经验的人将单体分解成单独的模块和服务。
我在阅读 Martin Fowler 的 MonolithFirst 博客文章后提出这个问题。当采用单体并将其分解为微服务时，等式中的“大小”元素是我思考最多的元素。具体来说，如何将单体应用程序（我们谈论的是 2001：A Space Oddessy；因为它既古老又庞大）分解为微服务，而不会变得过于细化或保持过于单体。最终目标是创建可以独立升级和独立扩展的独立模块。
根据将单体分解为微服务的个人经验，有哪些推荐的最佳实践？
【问题讨论】：
经验法则是打破基于限界上下文的单体应用。定义有界上下文的最常见方法是使用 BU（业务单元）。比如实际支付的模块大部分是一个单独的BU。
要考虑的第二件事是微服务带来的开销。在完全破坏服务之前，您应该分析硬件、监控、基础设施。我所看到的是人们从单体应用中取出较小的微服务，而不是去编写 10 个新服务并贬低单体应用。
我的建议是采用增量方法。以正在处理的第一个 BU 为例。这也将为整个团队提供良好的学习曲线。
【讨论】：
您应该清楚地将子域区域（有界上下文）与您的域区分开来。
通常（如果您的架构一切正常）您的单体应用程序中已经有一些单独的组件负责每个子域。这些组件在一个进程中相互交互 （在单体应用程序中），您应该考虑如何将它们放入单独的进程中。当然，在将单体应用逐个迁移到微服务时，您需要进行大量重构。
永远记住，每个微服务都负责一些子域。
我强烈建议你学习领域驱动设计。
在开始时，您还应该决定您的 micservices 将如何相互交互。 有几种选择：
您可以组合这些选项，例如 Query 请求可以通过 Dispatcher Service 处理，Commands 和 Events 通过消息总线。
根据我的经验，最大的问题是摆脱单一数据库， 通常使用哪些单体应用程序。
另外一些好的做法：
某些旅游业应用程序的子域（限界上下文）示例。 每个有界上下文都可以由微服务提供服务。
【讨论】：
我们也开始了我们的旅程，我开始为完全相同的事情写一个博客系列：https://dzone.com/articles/how-i-started-my-journey-in-micro-services-and-how
基本上我的理解是在差异中解决我的问题。微服务，我需要一个领域驱动设计提供的设计框架（Vaugh Vernon 的领域驱动设计蒸馏书）。
然后为了实现设计（使用 CQRS 和事件溯源等），我需要一个提供上述所有支持的框架。
我发现 Lagom 很适合这一点。（最终，Spring 微服务是其他一些选择）。
Microsoft 使用域驱动设计的示例微服务域分析：https://docs.microsoft.com/en-us/azure/architecture/microservices/domain-analysis
再分析一下：http://cqrs.nu/tutorial/cs/01-design
阅读领域驱动设计后，我认为 lagom 及以上链接将帮助您构建端到端应用程序。如果还有疑问，请提出:)
【讨论】：