学习目标
完成本单元后，你将能够：
- 描述什么是集成模式。
- 识别不同的集成模式。
引言
在当今技术格局中，架构师常被要求设计一个包含将遗留系统与新技术集成的集成策略。集成策略是一份路线图，标识实现集成目标所需的步骤。设计集成策略需要对可用解决方案有经验和知识，架构师要权衡各种选项，有时还要做出影响整个设计的艰难抉择。
什么是集成模式？
集成模式是架构师评估集成策略解决方案的宝贵资源。它们标识系统（包括其组件和服务）如何作为集成解决方案设计的一部分进行交互，展示成熟方案如何实现集成目标，并传达整体解决方案如何运作——它们描述（或捕获）一种被验证过的评估和解决集成问题的方式，避免重复造轮子。
评估集成模式
评估集成模式时，要仔细阅读示例场景和推荐方案。示例场景提供能达到特定结果的建议集成技术，评估这些方案看是否有满足你集成需求的。要明白集成模式不是实现指南，每个模式都包含解决集成问题的推荐方法，遵循专家解决类似问题的最佳实践，并标识具体集成技术（如连接器或服务）来为你的集成选择提供参考。
识别集成项目
集成类型决定你如何评估模式中的方案。Salesforce Lightning Platform 最常见的集成项目类型有三种：
- 应用集成：聚焦跨系统扩展特性和功能，包括 UI 触发事件、API 集成、Flow 和连接器。
- 数据集成：聚焦两个或多个系统之间的数据集成与同步，涉及数据完整性、数据治理、数据流设计和数据迁移。
- 流程集成：聚焦跨系统扩展业务流程和服务，例如触发某个系统活动或运行系统间事务的事件。
安全考虑
设计集成解决方案时，安全考虑很重要。每个系统设计都有安全要求，包括 SAML、单点登录（SSO）和数据加密等元素。以 Salesforce → System 方向集成的模式，最能从 Shield Platform Encryption 中受益——它依赖你控制的唯一租户密钥和 Salesforce 维护的主密钥，按 GDPR 要求维护数据完整性。
Salesforce Lightning Platform 集成模式
本模块涵盖以下 Salesforce Lightning Platform 集成模式：
- Remote Process Invocation—Request and Reply：Salesforce 调用远程系统上的流程并等待回复。
- Remote Process Invocation—Fire and Forget：Salesforce 调用远程系统中的流程，但不等待完成。
- Batch Data Synchronization：外部系统或 Lightning Platform 数据更新时，以批处理方式同步到另一系统。
- Remote Call-In：远程系统创建、检索、更新或删除 Lightning Platform 中存储的数据。
- Data Virtualization：Salesforce 实时访问外部数据。
- High-Frequency Data Replication：源系统以近实时、高规模异步复制数据到目标系统。
- Publish/Subscribe：Salesforce 发布事件（如记录创建、更改、删除），任意数量的订阅者监听并处理。
术语
这些模式共享通用术语，帮助你比较选项、确定哪个连接器或服务最符合集成目标。下一单元将介绍如何使用分层方法（layer approach）来评估模式，以及四个维度如何帮助你比较和评估解决方案。
实践分层方法
本单元学习使用分层方法评估应用集成项目的模式。
学习目标
完成本单元后，你将能够：
- 识别用于评估集成模式的三个层次。
- 描述两种时序类型及其重要性。
分层方法：四个维度
在分层方法中，用以下四个维度评估集成模式和方案：
- 层次（Layers）：系统中不同类型的任务。
- 数据量（Volume）：系统间同步的数据量和转换活动。
- 时序（Timing）：通信时序是异步还是同步——数据实时（或尽快）流动，还是批量推迟交付。
- 方向（Direction）：源方向，从 Salesforce 到另一系统、从另一系统到 Salesforce，或双向。
探索不同层次
分层方法把应用架构概念划分为逻辑类别，每个层次代表系统中的一组任务。最常见的划分是三层：用户界面层、业务流程层、数据层。这种任务划分帮助你归类相似的模式和方案；尽管这些层次是分开的，它们之间仍相互通信。
用户界面层
UI 层聚焦用户与系统的交互，在这里识别将第三方 Web 应用集成到 Salesforce 的组件，或组合多个系统的 UI（如在第三方应用中显示 Salesforce UI）。UI 层与业务流程层交互。示例方案：Salesforce Canvas、Mashups 或 Lightning Out。
业务流程层
业务流程层与数据交互，并构建在 UI 层之上。业务逻辑包括数据交互、验证和处理数据事务——这些事务是从 UI 或数据捕获事件到存储数据的数据库的实时调用。示例方案：MuleSoft Anypoint Platform、平台事件总线（含 Streaming API）、Flow、出站消息（Outbound messaging）。
数据层
数据层是 UI 层和业务流程层的连接，映射并标识主要数据源及与系统其他部分的连接。数据转换、迁移和复制常发生在此层，与该层对齐的连接器和服务聚焦数据在解决方案中流动时的准确性和完整性。示例方案：Heroku Connect、Salesforce Connect、Apex、REST 和 SOAP API、Composite API、Bulk API。
各模式所属层次：Request and Reply、Fire and Forget、Remote Call-In 属于业务逻辑层；Data Virtualization、Batch Data Synchronization 属于数据层；High-Frequency Data Replication 属于数据层和 UI 层；Publish/Subscribe 属于数据层和业务逻辑层。
数据量（Volume）
Volume 聚焦数据量和通信消息的大小。每个 Salesforce org 都有硬性的 governor limits 和配额，部分配额（如 API 调用）可通过购买额外许可证扩展，而硬性 governor limits（如 DML 语句更新的记录数）无法扩展。最佳实践是只用必要的技术、连接器和服务，避免不必要地消耗资源。
有些模式的方案适合小数据量——例如 Remote Process Invocation—Request and Reply 适合小（或单个）事务；而 Batch Data Synchronization 等模式更适合批量数据处理（如 Heroku Connect 一次性抓取大量数据而不超限）。
时序（Timing）
通信的时序和频率在评估集成方案时很重要：系统需要近实时发送通信，还是稍后批处理？有两种集成模式：
- 同步通信：客户端发送请求给服务器，等待响应后再发下一个请求（如 Request and Reply）。
- 异步通信：系统不等待回复就继续，发送消息后一旦资源可用就返回回复（如 Fire and Forget、Batch Data Synchronization、Publish/Subscribe）。
方向（Direction）
方向阐明两个系统之间的交互，标识主要源系统和目标系统——它是关于系统如何交互和连接，而非数据流向。例如 Salesforce 因事件发起并调用外部系统，方向记为 Salesforce → System。
各模式方向：Request and Reply、Fire and Forget、Publish/Subscribe、High-Frequency Data Replication、Data Virtualization 是 Salesforce → System；Remote Call-In 是 System → Salesforce；Batch Data Synchronization 双向。
安全要求
安全是集成方案设计的重要考虑，应把用户身份、数据脱敏、PII 存储等纳入集成策略。GDPR 是欧盟关于数据保护和隐私的法规，多数美国公司也把它作为最佳实践。Salesforce → System 方向的集成模式，最能从引入 Shield Platform Encryption 中受益。
错误处理与恢复
集成中会发生多种错误，包括系统阈值（governor limits 和 API 配额）、业务流程错误（请求违反业务规则）、用户授权和认证问题。整体方案中应包含错误处理和恢复策略。
- 错误处理：发生错误时（异常或错误码返回给调用方），由调用方处理——例如错误消息显示在终端用户页面或记录到表格。
- 恢复：在调用方收到成功响应前，改动不会提交到 Salesforce——例如只有收到成功响应，订单状态才更新到数据库；必要时调用方可重试。
耦合（Coupling）
跨多个系统的通信会在不同步时引入延迟和不可靠的风险。每个方案依赖不同的系统间依赖（技术、数据类型、交互风格等）。松耦合方案的组件能在需求或依赖变化时被替换（如异步通信中的消息传递）；紧耦合方案不重新设计集成策略就难以改动。在方案间做选择时，选松耦合以降低依赖断裂的风险。
评估一个集成模式
本单元用学到的工具，实践评估 Remote Process Invocation—Request and Reply 集成模式。
学习目标
完成本单元后，你将能够：
- 识别与 Remote Process Invocation—Request and Reply 模式关联的解决方案。
- 解释该模式的好处。
示例场景
假设你用 Salesforce 管理潜在客户、创建商机和管理联系人，集成方案要求 Salesforce 包含订单信息，但你用外部系统管理订单。你的集成目标是把外部系统连接到 Salesforce 来管理订单。通过评估 Request and Reply 模式，确定哪个方案最适合解决集成问题。
Remote Process Invocation—Request and Reply
该模式的关键特征：
- 层次：业务逻辑
- 时序：同步
- 方向：Salesforce → System
- 数据量：适合小事务（实时活动）
该模式非常适合从 Salesforce 向外部系统发送请求、并需要响应返回的设计。
该模式如何运作？
一个事件驱动的流程从 Salesforce 发起，调用外部系统。请求由 UI 触发——例如点击页面按钮，或 Lightning Web Component（LWC）调用 Apex 类。外部系统完成请求并向 Salesforce 发送同步回复，Salesforce 处理回复并按需更新数据。
解决方案选项
实现该模式可考虑的方案：
- 嵌入 Lightning Flow 的增强外部服务 / Lightning Web Component / Visualforce 与 Apex 控制器：当远程流程作为事件驱动端到端流程的一部分触发时使用——示例场景需要结果显示或更新到 Salesforce 记录，用户发起的动作调用 Apex 类执行远程调用，因此这是最佳选择。
- Apex 触发器：受 Apex governor limits 和配额限制，触发器所有调用异步执行，不适合示例场景。
- Apex 批处理类：支持从 Salesforce 批量远程处理，但受最大批处理调用数限制，也不适合示例场景。
集成示例
在下图中，LWC 用 Apex 调用同步远程处理：Apex 控制器创建连接并调用远程 Web 服务，远程系统响应 Salesforce，Apex 类处理数据，处理完成后结果显示在 Lightning 页面上。步骤总结：用户在 LWC 上交互（如点击按钮发起动作）→ 浏览器执行 HTTP POST 调用 Apex 控制器 → 该活动让 Apex 控制器调用远程 Web 服务 → 消息小且实时、同步返回 Salesforce → Apex 控制器接收并处理响应 → 系统按需更新 Salesforce 数据并重新渲染页面。
幂等设计考虑
「幂等」（idempotent）在数学上描述一个函数作用于自身时产生相同结果。如果用户多次点击同一按钮，Salesforce 会多次向外部系统发送消息。由于无法控制 Salesforce 发送多少次消息、或急躁的用户点击多少次按钮，接收方必须按幂等设计。设计幂等接收方的技巧：在请求消息中加入唯一消息 ID，帮助接收方识别重复请求；插入数据到外部系统前检查重复记录。没有幂等接收方检查重复请求，就会多次处理同一事务，导致性能问题、阻碍后续请求，造成资源浪费和数据完整性差。
探索更多集成模式
更多 Salesforce Lightning Platform 集成模式可参考 Integration Patterns Overview 指南，其中涵盖更多集成用例的解决方案选项，以及可纳入集成设计的额外考虑。
文章来源：Trailhead - Application Integration Patterns for Salesforce Lightning Platform