为事件驱动的架构使用正确的工具和模式

事件驱动的架构支持事件的高效生产和消费，这些事件传达系统或应用程序状态的变化。这些架构支持系统与支持流程之间的灵活连接，以及跨系统工作的近乎实时的更新。虽然事件驱动架构的优势显而易见，但实施细节并不总是那么清晰。在事件驱动的架构模式中，需要考虑哪些功能？这些模式解决哪些具体问题？解决方案有哪些特殊注意事项，解决这些问题的最佳模式是什么？

本指南介绍了在使用 Salesforce 技术时用于构建最佳事件驱动架构的模式。它还讨论了 Salesforce 提供的事件工具，并为一些用例提供了工具推荐。有关涉及 Salesforce 的数据级集成的信息，请参阅数据集成决策指南。

• **对于不需要同步响应请求的流程，使用事件驱动的架构。**本指南中概述的模式旨在实现数据的一致性、可扩展性和重用，这有助于随着贵组织的应用程序环境的发展，将技术债务保持在最低水平。（有关更多信息，请查看结构合理 - 吞吐量。）

• **如果 MuleSoft 或其他企业服务总线 (ESB) 解决方案是现有环境的一部分，请尽可能使用它。**这些解决方案专为支持事件驱动的架构模式而构建，具有强大的功能，使您能够在整个企业中重复使用集成。

• **将发布/订阅 API 用于任何未来的发布/订阅模式，而不是使用其他 API（包括流 API）构建自己的事件处理器。**现在，发布/订阅 API 已普遍可用，请将其用于任何新的发布/订阅模式。在可行时，计划使用其他平台 API（例如串流 API 或自定义 Apex 服务）将现有事件通信迁移到发布/订阅 API。

• **平台事件和变更数据捕获(CDC)是发布需要其他系统使用的记录和字段变更的首选机制。**我们不建议将 PushTopic 和通用事件用于新实施。Salesforce 将继续在当前功能范围内支持 PushTopic 和通用事件，但不打算对此技术进行进一步投资。

	Salesforce 平台是一个 AI 驱动的综合平台，将员工、自主 AI 客服人员、公司数据和应用程序统一到一个可信的系统中，以提高生产率和客户体验。它通过连接 Customer 360 应用程序、Data Cloud 和 Slack 来实现端到端自动化，从而支持创建“代理企业”。
	MuleSoft 是 Salesforce 领先的集成平台，使组织能够跨本地和云环境连接应用程序、数据和设备。MuleSoft 是一个平台，它为 IT 提供了平台来解锁系统之间的数据，开发可扩展的集成和自动化框架，并快速创建差异化的连接体验。

事件驱动架构 (EDA) 推荐用于需要近乎实时通知、分配高用量或复杂消息的处理负载以及集成需要通过排队实现连接弹性的系统（例如 IoT 和移动设备）的场景。然而，不应为需要即时、同步人工响应的进程实施 EDA，因为它们专为异步执行而设计。如果源数据更改频率如此之低，以至于批处理等简单模式就足够了，那么它们也不适合。

以下是一些通常非常适合事件驱动架构的常见场景：

大多数大型组织都拥有复杂的 IT 环境，这些环境包含具有不同功能的系统组合。您的组织可能或很可能拥有不支持事件驱动集成的传统系统。您可能也有事件驱动的集成没有意义的用例，即使系统将支持它们（例如，第三方的 SFTP 文件传输）。如果您退一步看贵组织的整体 IT 环境，您很可能会像其他架构解决方案一样，采用混合模式来支持不同的场景。当您决定将事件驱动作为集成的首选方法时，请将其视为工具箱中的另一个工具。它可以而且应该在正确的场景中使用，但它不是强加给每个系统的方法。制定全面的集成策略将帮助您确定本指南中描述的模式何时适用或不适用。

许多场景需要事件驱动的架构，而在某些情况下，事件驱动的架构可以工作，即使它们不是最合适的架构。但在某些情况下，根本不应该使用事件驱动的架构。以下是一些决策点问题，可帮助您识别这些情况：

事件驱动的架构模式多种多样。一些是通用模式，可以应用于除事件驱动之外没有任何特殊要求的用例；例如，请参见架构良好 - 交互性。其他模式适用于此处讨论的特定用例，例如涉及大量数据的集成，或需要更长的消息保留时间的场景。

下表比较了本文档中概述的模式的属性。当您需要确定给定用例的潜在模式时，将其用作快速参考。

Salesforce 提供多种工具，以帮助您解决事件驱动的用例。此表包含可用工具的高级概览。

当关键记录在核心应用程序中改变状态时（例如，订单的状态从“正在处理”变为“已发货”），多个其他系统可能需要近乎实时的通知来执行各自的任务。当这些更改的数量很大并且消息很复杂时，就会产生特定的业务需求，这使得传统的点对点集成变得繁重和难以维护。为每个依赖应用程序建立脆弱的自定义连接会导致技术债务，并抑制组织快速扩展的能力。需要一种强大的集成方法来管理这些频繁的数据同步，而无需将源系统直接耦合到每个消耗系统。

下图描述了典型的发布/订阅模式，多个发布者和订阅者通过事件总线共享数据。这种基本模式构成了本指南其余部分中可以找到的更具体的模式的基础。该模式的一些关键特征是：

• 发布者和订阅者之间没有直接联系。发布者只需向事件总线发送消息，事件总线便会将它们广播到任何其他想要监听它们的系统。

• 同一系统可以是发布者和订阅者。

• 系统可以发布或订阅多种类型的事件。

• 与本指南中的所有模式一样，发布/订阅模式属于通用集成模式类别，称为远程过程调用 (RPI)，或简称为"触发并忘记 " 。

当组织需要向大量客户端应用程序发送即时更新时，例如向移动设备发送推送通知或短信，为每个单个收件人创建唯一传输的传统流程会很快成为可扩展性瓶颈。在这种情况下，核心业务需求是同时将单个信息（例如客户提醒或重要服务变更通知）快速、高性能地分发到多个端点应用程序。满足此要求的简化方法包括通过单个队列路由所有消息，该队列充当所有消耗系统的事件信息中心点。这种方法通过消除对许多单独消息副本的管理来提高性能。

通过扇出模式，消息通过单个消息队列传递到一个或多个目的地（即监听客户端或订阅者）。订阅者从队列中检索相同的消息，而不是他们自己的唯一副本。（请注意，虽然这会提高性能，但也会增加验证特定订阅者是否收到消息的难度。）

一些事件场景的特点是大量消息涌入，有可能超出同步和转换流程的工作量，或者具有处理和转换事件数据所需的复杂、多步骤逻辑。

一些示例包括：

• **季节性用量高峰：**当在线零售商选择的产品处于“季节性”时，他们会遇到销量高峰。当大量客户同时进行购买时，生成的事件数量可能会暂时超出同步和转换流程的工作量。有关更多信息，请查看架构良好 - 数据处理。

• **个案或索赔管理：**基于服务的公司在停机期间可能会遇到个案或索赔数量的激增。

• **复杂数据转换：**需要复杂逻辑来转换消息的组织通常担心事件的生成速度比转换速度快。

这种模式解决了消息生成速度超过转换速度的挑战。它确保可以可靠地处理大量消息和所需的数据操纵，将流消息平台和消息处理逻辑细分为专用组件。

“传递的消息”模式的工作方式是将消息处理逻辑划分为多个组件：

• 一个组件处理消息路由，确定所需的转换和最终目的地。

• 一组单独的组件处理不同的消息转换层（例如，字段映射、对象关系等）。

• 最后一个组件会写入最终的修改消息。

一些生产者会生成连续的事件流。一个常见的例子是媒体流，它涉及自然作为离散事件发生的用户交互。多个系统必须同时对相同的用户行为做出反应，而不会阻止核心流体验。

考虑音乐流平台的事件。这些可能包括：

• 跟踪开始/暂停/跳过的事件

• 监听带有时间戳的会话事件

• 播放列表创建/修改事件

• 社交共享事件

• 下载离线收听

在流模式中，订阅者访问每个事件流，并按照接收的确切顺序处理事件。每个消息流的唯一副本被发送给每个订阅者，使得能够交付订阅者特定的内容，并确定哪些订阅者收到了哪些流。

为使流有意义，所有事件及其关联消息需要以正确的顺序显示。如果您从不同系统获取流中的数据，您需要将其他排序逻辑作为设计过程的一部分。

排队用例无处不在。示例包括：

• **互联网连接质量低：**对于拥有移动设备的团队需要在低质量或断断续续的互联网接入区域工作的现场服务组织或其他组织，排队将从中受益，因为这些设备上的应用程序可以连接到他们的队列，并在恢复连接时检索任何相关的消息。

• **消息缓冲：**当消息量偶尔超过订阅者的处理能力，并且增加的延迟不会造成其他问题时，队列可以是存储过量消息和防止数据丢失的缓冲。

• **运输管理：**需要监控车队的物流组织可以使用此模式近乎实时地查看每辆车行驶的路线，并确保司机尽可能高效。

• **IoT 设备：**制造商通常使用可生成快速数据流的系统，而这些流会对其他系统产生下游影响。此模式可用于识别跨多个系统的灾难性故障发生之前需要人为干预的事件序列。

在队列模式中，生产者将消息发送到队列，队列保存消息，直到订阅者检索它们。大多数消息队列遵循先进先出 (FIFO) 顺序，并在检索后删除每条消息。每个订阅者都有一个唯一的队列，这需要额外的设置步骤，但可以保证发送，并确定哪些订阅者收到了哪些消息。

由于队列模式的异步性质，在消息添加到队列和检索消息之间可能会有很长的延迟。队列需要内存或存储空间来保存消息，因此它们不能无限增长，这意味着如果队列中有足够的消息，无限期离线的订阅者可能会导致失败。如果订阅者处理时间过长，导致队列中累积大量消息，则消息缓冲会产生相同效果。为了降低这些风险，请对所有消息队列的存储要求进行透彻的分析，如有必要，还可以设计一些流程，以便在消息未在规定时间内检索到或到达预定的卷时清除和禁用队列。

即使您完全相信事件驱动的架构适合您的组织，您也可能从已经拥有大量点对点集成的环境开始。为项目获得资金以一次替换所有集成可能很困难，甚至可能无法直接将事件驱动的架构与一些原有系统一起使用。在这些场景中，您可以通过先转换最关键业务的应用程序，然后在其他系统在未来项目中更新或替换时转换它们，从而采取增量方法迁移到更松散耦合的架构。此方法可轻松将新应用程序添加到事件总线，并使您的整体 IT 环境保持可扩展性和弹性，因为系统会随着时间的推移不断添加。

作为架构师，我们知道每个架构都有权衡。事件驱动的架构也不例外。虽然充满松散耦合的系统的环境具有高可扩展性和弹性，但也需要考虑一些权衡:

• **整体集成策略：**无论您决定使用什么工具和模式，重要的是从创建如何在贵组织环境中的各种系统之间共享数据的策略开始。此策略应包括贵组织的数据目标、如何共享数据和使用的模式，以及数据源、目标、结构、所有权和访问权限要求。

• **支持原有系统：**贵组织可能拥有根本不支持事件驱动架构模式的原有系统。虽然可以构建解决方法（例如，通过订阅事件并将输出通过不同的数据传输方式发送到目标系统的过程），但在这种情况下，您可能要考虑其他集成方法。

• **消息的结构更改：**一旦发布者和订阅者之间定义并商定了初始消息结构，就很难更改，特别是如果订阅者是外部的。有几种方法可以解决这个问题。您可以使用版本化端点，但请确保为每个版本定义并传达清晰的生命周期，这样开发人员就不必同时维护太多的版本。如果 Heroku 上的 Apache Kafka 是您的环境的一部分，您也可以考虑模式注册表或类似工具，但请确保您的环境中的其他系统也支持它（并使用它）。

• **发布者和订阅者之间缺乏可见性：**在大多数事件驱动的架构模式中，发布者不知道他们的订阅者的状态。因此，如果发布者在所有订阅者离线时发送关键消息，消息可能永远不会被传递。您可以通过使用重放功能或为所有关键消息添加在单独服务器上运行的冗余订阅者来解决这个问题。

• **性能瓶颈：**随着事件驱动架构的扩展，如果太多发布者试图同时向太多的订阅者发送消息，事件总线会成为消息传递的瓶颈。您可以通过增加分配给事件总线的内存和处理资源来解决这个问题，或者通过使用多个事件总线来并行处理不同类型的消息。

在实施事件驱动的架构之前，请首先考虑您是否真正需要使用一个架构。上一节描述了非常适合每个事件驱动架构模式的常见业务场景。您也可以在架构良好 - 交互性中阅读更多信息。查看实施事件驱动架构时需要考虑的挑战，以确定您想到的模式是否最适合您的特定用例。

请注意，虽然本指南涵盖的大多数场景涉及集成，但事件驱动的架构也可用于在单个 Salesforce 组织中发送消息，例如，通过使用平台事件。在设计将平台事件用作内部消息传递系统的流程时，请确保记住任何适用的事件分配限制。

通常，围绕事件驱动架构的反模式来自将事件用作 Salesforce 组织内部通信的解决方法。常见的反模式包括：

• **从与相同事件对象关联的 Apex 触发器发布事件：**这将导致无限的触发器循环。

• **在 DML 交易完成之前从 Apex 发布事件：**如果事务失败并回滚，任何具有“立即发布”发布行为的已发布事件都不会包含在回滚行为中。

• **在流中发布事件以编排后续自动化：**在多个自动化之间协调逻辑的最佳方式是使用子流或 Flow Orchestrator。

• **创建运行时依赖性：**不要发布事件来促进软件包之间的通信，而不采取适当步骤来消除运行时依赖性。

• **不必要的大负载：**在提出请求时，最好在负载中发送和接收尽可能少的数据。用户的每个操作都可能产生多个请求，重要的是要高效地处理这些请求。发送超过必要的数据会导致传输速度变慢和处理时间增加。

• **对应用程序事件的非选择性处理：**在多个组件监听应用程序事件时，开发人员应确保事件处理程序仅在实际需要和有用时执行。例如，在 Lightning 控制台中，选项卡中包含的未聚焦组件仍可以监听，即使它们不可见。开发人员可以使用各种技术，例如将后台实用程序项目用作唯一侦听器，或调用 getEnclosingTabId() 来确定组件的此实例是否包含在聚焦选项卡中，以确保每个事件仅在预期时处理。

• **错误使用平台事件发布行为：**平台事件有两种发布行为 — 立即发布和提交后发布。将实时平台事件用于记录等用例非常有用，在这些用例中，您希望发布记录事件，而不管事务是否成功并提交。但是，对于实时平台事件，请非常谨慎地使用“立即发布”。订阅者可以在相同事务中消耗事件，并导致行锁定或其他竞争条件。

在实施事件驱动的架构时，成功的关键之一是为事件本身的设计方式设置标准。具体情况因贵组织的用例而异，但以下是一些一般指导原则：

• **确定事件负载的最佳结构。**虽然较小的消息大小减少了处理时间，但用大量消息轰炸订阅者会导致性能瓶颈。您可能需要迭代负载大小和结构，以找到正确的平衡。MuleSoft 和类似的 ESB 工具提供了在与事件相关联的消息中设计自定义负载的能力，这可以帮助您可视化数据结构，以提高订阅者侧的性能。（有关更多信息，请查看架构良好 - API 管理。）

• **端到端地思考您的流程。**请确保您没有创建任何“无止境的循环”场景，一旦集成推出，这可能很难跟踪。例如，两个系统会在更新记录时发布事件，同时监听彼此的事件，并在处理时触发其他已发布事件。

  您可以通过向两个系统添加逻辑来修复这种类型的反模式，以确保由于事件被消耗而导致的更改不会导致发布新事件。您还应确保记录所有事件、关联触发器以及可能受影响的下游系统。在设计会议期间，将此文档用作参考，以帮助尽早捕捉无休止的循环和类似场景。（有关更多信息，请查看结构合理 - 流程设计。）

• **跨系统使用通用命名约定。**一致的命名约定是所有软件开发的最佳实践，包括事件驱动的架构。花时间记录事件名称、结构、关联对象和错误处理流程的一组标准，以确保跨系统的一致性。（有关更多信息，请查看设计标准。）