语言 Chinese, Simplified

SEO Title

事件驱动的体系结构必须跨越您的应用程序平台。开发人员构建与事件交互的应用程序，并且应用程序是事件驱动的。也就是说，它们都通过使用事件主干来生成和使用事件。在这种情况下，将事件主干视为微服务网格的一部分，提供微服务之间的发布和订阅通信，并支持松散耦合的事件驱动的微服务。

微服务是云原生平台上的首选应用程序架构。随着企业成为事件驱动，事件驱动模式需要扩展到您的微服务应用程序中。您的微服务仍在对着名的微服务进行REST调用。但是，他们必须回应并发送事件。在事件驱动的条件下，他们需要成为事件生产者和消费者来强制解耦。

事件主干：微服务的发布和订阅通信和数据共享

随着微服务的采用，对服务之间同步通信的关注正在增加。服务网格包（如Istio）可帮助您管理此同步通信环境中的通信，服务发现，负载平衡和可见性。

利用事件驱动的微服务，通信点成为事件主干的发布 - 订阅层。通过采用基于事件的方法实现微服务之间的相互通信，微服务应用程序自然响应（事件驱动）。这种方法增强了微服务的松散耦合性质，因为它使生产者和消费者脱钩。它还可以通过事件日志跨微服务共享数据。

在开发微服务应用程序时，这些事件类型特征是越来越重要的考虑因素。实际上，微服务应用程序是同步API驱动和异步事件驱动通信方式的组合。从实现视图中，使用一组已建立的模式，例如每服务数据库，事件源，命令查询责任分离（CQRS）和Saga。

Event driven microservices

带容器的事件驱动应用程序

虽然使用IBM®CloudFunctions的无服务器方法提供了简化的基于事件的编程模型，但大多数微服务应用程序是为基于容器的云原生堆栈开发和部署的。在云原生景观中，Kubernetes是容器编排的标准平台，也是事件驱动架构中容器平台的基础。

事件主干是用于微服务的共享数据的发布 - 订阅通信提供者和事件日志。在这种情况下，微服务是通过使用主题开发为骨干事件的直接消费者和生产者。此环境中的额外工作是管理消费者实例以响应事件流的需求。您必须确定需要运行多少消费者微服务实例才能跟上或始终可用于运行微服务以响应到达事件。

采用发布和订阅作为微服务通信骨干至少涉及以下模式：

通过子域分解：事件驱动的微服务仍然是微服务，因此您需要找到它们。域驱动子域的使用是识别和分类业务功能的一种好方法，因此也就是微服务。使用事件风暴方法，聚合有助于找到那些负责的子域。
每个服务一个数据库：此模式强制每个服务私有地保留数据，并且只能通过其API访问。
Saga模式：微服务在其控制范围内发生某些事件时发布事件，例如他们负责的业务实体中的更新。对其他业务实体感兴趣的微服务订阅这些事件，并且当微服务接收到这样的事件时可以更新其自己的状态和业务实体。业务实体密钥必须是唯一且不可变的。
事件溯源：此模式将业务实体的状态保持为一系列状态改变事件。
CQRS有助于将查询与命令分开，并解决具有跨微服务边界的查询。

业务事务跨越服务，并且是一系列步骤。每个步骤都由微服务支持，微服务负责更新自己的实体，从而最终实现数据的一致性。
事件主干必须保证事件至少传递一次。微服务负责管理它们与流源的偏移量，并通过检测重复事件来处理不一致性。
在微服务级别，更新数据和发出事件需要是原子操作，以避免在更新数据源之后和事件发出之前服务失败时的不一致。此操作可以通过向微服务数据源添加eventTable并使事件发布者定期读取此表并在发布时更改事件的状态来完成。另一种解决方案是让数据库事务日志读取器或挖掘器负责在日志中的新行上发布事件。
另一种避免两阶段提交和不一致的方法是使用事件存储或事件源模式来跟踪业务实体上的操作，并使用足够的数据来重建数据。事件正在成为描述业务实体状态变化的事实。