微服务篇：异步的事件驱动型微服务

应用的任务是满足这些需求并向其他下游消费者发布任何必要的事件。下面是使用事件驱动型微服务的主要优点。

颗粒化

　　服务可以恰当地映射界限上下文，并且在业务需求发生变化时可被轻易重写。

可伸缩性

　　单独的服务可以根据需要进行扩缩容。

技术灵活性

　　服务可以使用最合适的语言和技术，也可以使用最前沿的技术进行简单的原型开发。

业务需求灵活性

　　颗粒化微服务的所有权很容易进行重组。与大型服务相比，它们有更少的跨团队依赖，并且组织可以快速响应业务需求的变化，否则这些变化会受到数据访问障碍的阻碍。

松耦合

　　事件驱动型微服务耦合于领域数据而不是特定的实现 API。数据 schema能极大地改进管理数据变更的方式，这部分内容会在第 3 章中详细介绍。

持续交付支持

　　发布一个小型的、模块化的微服务很容易，并且可在需要时将其回滚。

高可测试性

　　微服务的依赖比大型单体服务少，因此可以更容易地模拟所需的测试端点并保证适当的代码覆盖率。

使用事件驱动型微服务的示例团队

现在回到前面那个团队早期做决策的时候，这次他们使用的是事件驱动的数据沟通结构。

一个新的业务需求被提交给了这个团队。此需求与该团队当前负责的产品相关，但它们的差异程度也足以将其实现到单独的一个服务里。将其添加到当前的服务是否违反了单一权责原则且扩大了当前所定义的界限上下文？或者它就是对现有服务的一次简单扩展，可能添加了一些新的相关数据和功能？

之前所说的技术问题，比如确定从哪里获取数据和如何接收数据、批处理的同步，以及需要实现同步 API 等，在采用事件驱动型微服务后都基本被消除了。该团队可以启动一个新的微服务并从事件流中获取必要的数据。如果需要，可以一直回溯到事件流中最开始时的数据。团队完全可以整合用于其他服务的公共数据，只要这些数据只用于实现新的界限上下文需求。这些数据的存储和结构完全由该团队来决定，他们可以选择保留哪些字段和抛弃哪些字段。

业务风险也得到了缓解，因为小型的、细粒度的服务允许由单一团队来负责，团队可以根据需要进行规模调整和重组。当团队变得太大而无法在单一业务所有者下进行管理时，可以根据需要拆分并重新分配微服务的权责。事件数据的所有权跟着生产事件的服务移动，并且所做出的组织决策会减少将来执行任务时所需的跨团队通信。

如果创建新服务和获取所需数据的开销很小，那么微服务的特性就防止了意大利面式代码和扩大化的单体应用的出现。可伸缩性的关注点现在聚焦于单个事件处理服务，这些服务可以根据需要变更 CPU、内存、磁盘和实例计数的规模。剩余的伸缩需求被转移到了数据沟通结构上，数据沟通结构必须确保能够处理服务从事件流中消费和往事件流生产事件所产生的各种负载。

然而，要实现这一切，团队需要确保数据确实存在于数据沟通结构中，并且他们必须有轻松启动和管理一系列微服务的方法。这就需要整个组织接受事件驱动型微服务架构。