设计自己的微服务系统

Bonér的Reactive Microservices Architecture: Design Principles for Distributed Systems 是微服务系统架构师的基本读物。要熟练掌握这个复杂的领域需要时间和经验。通过提供API、支持特性的实现和适当的默认值，Lagom提供了实用的指导。
我们建议从小型服务做起。首先，确定对可以使用异步消息的简单微服务的需求。它不需要很复杂，甚至不需要提供很多价值。这种简单性减少了与部署相关的风险，并可以提供快速的胜利。接下来，在体系结构级别，取出可以划分的核心服务,把它分成一个微服务系统。当您一次解决一个问题时，您和您的团队将会在过程中学习，并将变得越来越有效。使用Domain-driven Design (DDD)等方法可以帮助您的组织处理企业系统中固有的复杂性。

替换巨石应用

在设计一个微服务系统来替代现有的巨石应用时，您的替换方案可以根据需求和现有体系结构而有所不同。例如，如果应用设计得相当好，那么您可以首先将遗留组件分离开来，然后集中精力一次迁移一些功能。如果合理的停机时间是不可接受的，那么您需要一个详细的计划将功能从旧系统切换到新系统。
例如，想象一个处理许多部门核心业务功能的企业应用。可能库存，会计、销售、市场和运营等功能都在以不同的方式使用它。DDD鼓励将如此庞大而笨拙的模型分解为限界上下文。每个限界上下文都定义了一个适用于特定团队的边界，处理特定的用法，并包括数据模式和为该上下文具体化系统所必需的物理元素。使用边界上下文使得小型团队一次只关注一个上下文，可以并行工作。
在第一个实现阶段，您可能会修改巨石应用，以开始发布特定用例中会计部门感兴趣的库存事件。下面的图表说明了Kafka,，一个支持发布/订阅(发布/订阅)的流媒体平台，并作为一个集群运行的性能和可靠性。

接下来，如下图所示，您可以创建订阅主题并处理数据的微服务。微服务的多个实例提供了可伸缩性和容错性。当您测试和微调微服务时，遗留的功能仍然存在。

接下来，如所示，您可以修改巨石应用，对新的微服务进行远程HTTP调用，而不是调用它自己的内部业务逻辑。

当您确信新的微服务运行良好时，就可以从整体上删除内部业务逻辑，转而使用下一个微服务或一组微服务。这个高级示例只是您可以选择的从巨石应用中拆分功能的方法之一。