许多组织正在采用微服务架构，以减少系统组件之间的依赖关系，并允许更频繁的发布周期和更灵活的可伸缩性。但是，除非他们清楚地了解底层交互模式，否则团队可能会构建紧密耦合的分布式单体。

本文介绍了支持微服务交互的模式，并解释了事件流如何使事件驱动架构（EDA）支持松散耦合的微服务原则。

成熟的微服务景观

通常，团队通过一小组微服务和他们之间的有限数量的交互开始旅程。随着微服务数量的增长，它们之间的相互作用也在增长。了解这些交互对于维护松散耦合的微服务至关重要。

作为架构师，我们需要更加关注区域内发生的事情而不是区域之间发生的事情 - 构建微服务（Sam Newman）

推理这些交互的一步是将它们分类为命令，查询和事件。

虽然许多组织已经熟练使用现代API实现命令和查询，但大多数组织尚未充分利用事件驱动架构的优势。

在不断发展的生态系统中，服务需要独立发展，命令和查询会增加很多耦合，在运行时将服务捆绑在一起。事件有助于缓解这种紧密耦合，同时仍然促进服务之间的协作。

同步呼叫被认为是有害的 - 微服务（Martin Fowler）

HTTP API需要一个伴侣

HTTP是一种同步的请求 - 响应协议，客户端向已知服务器发送请求并期望来自服务器的响应;它假设服务器可用并且能够响应。此交互样式非常适合实现命令和查询，但不适合基于事件的通信。使用发布 - 订阅模式可以最好地实现基于事件的通信。

事件代表了通知和状态分布的宝贵组合。

事件=通知+状态

事件为应用程序提供了一个选择：继续执行命令和查询或包含事件以触发其进程并引用事件以提取数据供其私人使用。

随着服务生态系统的发展，架构师建议将事件建模为一等公民，并考虑服务需要与外界分享的重要商业事实。

组织经常难以识别其业务流程中的重要事件。 Event Storming研讨会可​​以帮助克服这个最初的障碍，因为它们是有趣的，自由流动的研讨会，将开发人员和领域专家聚集在一起，目的是将业务流程表达为一系列重要事件。

并非所有事件都是平等的，有些事件不会引起反应;然而，最重要的事件引起反应，这些事件应该在我们的软件系统中建模。

拥抱事件减少了对命令和查询的依赖。事件在服务之间传输状态，减少了它们之间的查询需求。他们还通知服务更广泛的生态系统中发生的重大事件，使服务能够做出适当的反应，从而为触发业务流程提供命令式交互的替代方案。

事件通知状态变化。命令导致状态改变。

持久化你的事件流

即使事件跨服务传输状态，订阅者也需要存储事件流的表示以避免远程查询。随着新事件的发布以及数据存储数量的增加，这些本地数据存储必须保持同步，因此数据漂移的可能性也会增加。

持久化事件流使服务能够直接引用共享事件流并从中创建自己的私有视图。 他们不再需要在本地存储事件的副本。

除了缓解一些复杂性之外，事件流开始提供新的机会。 由此产生的历史参考是新服务可以插入的内容，并且是一个强大的引导工具，可以将体系结构打开到扩展。

服务可以参考的事实的中央记录必然会带来很高的回报。

这种类型的持久性事件流可以实现为分布式提交日志。

不可否认，事件驱动架构的承诺已经存在了很长时间，但它是分布式提交日志基础，这次使事情变得与众不同，并释放其真正的潜力。

分布式提交日志在概念上类似于数据库事务日志，有时称为预写日志或提交日志，其是由数据库管理系统执行的动作的历史。

分布式提交日志将消息的消耗与消息的存储分离。这种解耦提供了许多好处，与事件驱动架构最相关的三个好处是

1. 事实来源：日志可以成为事实的来源。事件永久存储在日志中，订阅者可以随时引用。
2. 事件重播和审计跟踪：由于事件是不可变的并且永久存储，因此默认情况下您将获得审计，监视和事件重播。除了允许现有订户重放事件历史记录外，它还允许新订户插入事件流并消耗过去的事件。
3. 流处理：即使在数据进入分析引擎之前，处理提交日志中的数据也可以实现实时业务洞察。

基于分布式提交日志的事件驱动架构（EDA）使组织能够扩展其微服务架构，并从服务之间交换的数据中获得实时洞察。

EDA是微服务架构发展的下一个阶段，毫不奇怪，Google，Azure，Hortonworks等所有主要供应商都拥有支持这种发展的工具。

Apache Kafka是一种广泛采用的实现，还有像AWS Kinesis这样的云原生解决方案。

最后的想法

微服务在组织中越来越重要，这些服务之间交换的数据非常宝贵，利用这些数据进行架构可以为组织提供竞争优势，并且是微服务发展的下一个合乎逻辑的步骤。

原文:https://platform.deloitte.com.au/articles/2018/event-driven-microservices