企业架构实践（三）：企业应用集成——从 Web Service 到消息队列
一、系统之间能够连接，不代表集成架构已经清晰
在前两篇文章中，我从企业现有的 IT 环境出发，整理了系统清单，并尝试把系统之间的关系表达出来。
梳理过程中，一个比较明显的感受是：企业里的应用系统通常不是独立运行的。
ERP 需要与其他业务系统交换数据，MES 需要接收生产相关信息，WMS 需要处理仓储业务。为了让这些系统协同工作，企业需要建立各种接口和数据交互机制。
在实际环境中，不同系统之间可能采用不同的集成方式。
例如，目前 ERP 与 WMS 通过 Web Service 进行集成；而 D365 Finance and Operations 与 MES 之间，则通过 ERP Sync Service 和 RabbitMQ 等组件完成相关集成。
这两种方式都能够实现系统间的数据交互，但它们的技术机制、处理流程和运维关注点并不相同。
如果只知道两个系统之间存在接口，还不足以完整理解集成架构。
我们还需要进一步了解：
- 系统之间通过什么方式交互？
- 调用方是否需要等待被调用方完成处理？
- 数据通过什么方式传递？
- 接口失败后如何处理？
- 是否存在独立的集成服务？
- 如何确认数据已经成功处理？
- 当业务量增加时，现有集成方式是否仍然适用？
这些问题既与具体的技术实现有关，也与业务流程和系统职责有关。
因此，这篇文章准备从日常 IT 管理中比较常见的集成场景出发，梳理 Web Service、消息队列和集成服务之间的关系，并尝试理解它们在企业应用架构中的作用。
二、先理解同步调用与异步消息
在分析具体的集成方式之前，我认为有必要先区分两个概念：同步调用和异步消息。
它们描述的是交互过程中的不同处理机制，并不完全等同于某一种具体协议或产品。
2.1 同步调用：调用方需要等待响应
假设 ERP 需要向 WMS 查询某项业务信息。
一种常见的方式是，ERP 调用 WMS 提供的 Web Service 接口，WMS 处理请求后返回结果。
整个过程可以简化为：
- ERP 发起请求。
- WMS 接收请求。
- WMS 执行相应处理。
- WMS 返回响应。
- ERP 根据响应结果继续处理。
在这种模式下，调用方通常需要等待被调用方返回响应，才能根据结果决定下一步操作。
这就是同步调用的基本思路。
这里需要注意，同步调用并不意味着整个业务流程一定在一次请求中全部完成。接口可能只完成查询、校验或接收请求等操作，后续业务处理仍然可能在后台执行。
同样，接口返回成功，也需要明确它所代表的成功含义。
例如，接口返回成功可能只表示请求已被接收，并不一定意味着所有后续业务处理都已完成。
因此，设计接口时，需要明确请求、响应和业务处理结果之间的关系。
2.2 异步消息：发送方与接收方可以分开处理
另一种方式是使用消息队列。
发送方将消息发送到消息中间件，接收方再从中获取消息并进行处理。
简化后的过程如下：
- 发送方准备业务消息。
- 消息被发送到 RabbitMQ。
- 消费方获取消息。
- 消费方执行相应业务处理。
- 根据实际设计，消费方确认消息处理状态。
这种方式允许发送方和接收方在一定程度上独立运行。
例如，发送方成功将消息交给消息中间件后，通常不需要等待接收方完成全部业务处理，便可以继续执行其他工作。
但这里同样需要注意：消息发送成功，不等于接收方已经完成业务处理。
如果业务要求确认最终处理结果，就需要进一步设计处理状态、结果反馈、异常记录等机制。
异步消息并不意味着可以不关心处理结果，只是把发送与处理分成了不同阶段。
2.3 两种方式有什么区别？
可以从以下几个方面进行比较。
| 比较维度 | 同步调用 | 异步消息 |
|---|---|---|
| 基本交互方式 | 请求后等待响应 | 发送消息，接收方后续处理 |
| 调用方是否需要等待业务处理结果 | 通常需要等待接口响应，具体取决于接口语义 | 通常不需要等待消费方完成业务处理 |
| 系统之间的时间耦合 | 较强，调用过程通常要求对方及时响应 | 可以降低发送方与接收方的时间耦合 |
| 处理结果 | 通常通过接口响应返回 | 通常需要结合消息确认、业务状态或结果反馈判断 |
| 典型关注点 | 超时、接口错误、请求失败 | 消息积压、重复处理、消费失败、消息恢复 |
| 常见技术形式 | Web Service、HTTP API | RabbitMQ 等消息中间件 |
这张表只是概括了两种模式的典型特征。
实际系统可能采用混合方式，例如通过同步接口提交请求，再通过消息队列处理后续业务。
因此，在分析企业应用集成时，不应该只根据接口名称判断系统采用了哪种机制，而应该结合实际交互流程进行确认。
三、结合实际环境理解 Web Service 集成
目前，企业 ERP 与 WMS 之间通过 Web Service 进行集成。
这是一种比较常见的企业应用集成方式。
但在架构分析中，我认为有必要区分两个问题：
第一，系统之间采用什么技术方式进行交互。
第二，这种交互方式具体支持什么业务流程。
Web Service 只是技术实现的一部分，真正需要理解的仍然是接口背后的业务含义。
3.1 先明确接口双方的职责
在 ERP 与 WMS 的集成中，ERP 和 WMS 分别承担不同的业务职责。
ERP 负责相关企业资源管理业务，WMS 负责仓储管理。
系统之间需要交换哪些数据，应该由实际业务流程和接口设计决定，而不能仅凭系统名称推断。
在梳理这类集成时，可以先整理一份接口清单。
| 信息项 | 需要记录的内容 |
|---|---|
| 接口名称 | 接口的正式名称或业务用途 |
| 调用方 | 哪个系统发起请求 |
| 被调用方 | 哪个系统提供接口 |
| 交互方式 | Web Service、HTTP API 或其他方式 |
| 业务用途 | 接口解决什么业务问题 |
| 数据内容 | 请求和响应包含哪些主要数据 |
| 调用方向 | 数据从哪个系统流向哪个系统 |
| 异常处理 | 请求失败或处理异常时如何处理 |
| 业务结果 | 如何确认相关业务处理已经完成 |
这份清单不需要一开始就非常复杂。
先把接口名称、调用方、被调用方、业务用途和数据方向整理清楚，就可以帮助我们建立基本认识。
之后再逐步补充超时设置、错误码、重试策略和业务确认机制。
3.2 接口成功，不一定代表业务成功
这是接口设计中容易被忽略的问题。
假设 ERP 调用 WMS 接口，接口返回了成功响应。
这个响应究竟代表什么？
可能是：
- 请求已经成功接收。
- 请求参数已经通过校验。
- 业务数据已经保存。
- 相关业务操作已经全部完成。
这些含义并不相同。
如果接口只是接收了请求，而后续处理仍然在后台进行，那么调用方就不能把接口返回成功直接理解为业务流程已经完成。
因此，在接口设计中，需要明确响应语义。
对于重要业务，还需要考虑如何查询处理状态、识别失败记录，以及在必要时重新发起处理。
这些设计不仅影响接口开发，也会直接影响后续的运维和故障排查。
3.3 需要关注哪些运行问题？
对于 Web Service 集成，可以重点关注以下几个方面。
第一，超时。
如果被调用方处理较慢，调用方可能在等待一段时间后超时。
超时并不一定意味着被调用方没有执行操作。有时请求已经被处理，只是响应没有及时返回。
因此，发生超时后，不能不加判断地直接重复提交可能产生业务副作用的请求。
第二，重试。
对于临时网络异常或短暂服务不可用，可以考虑重试机制。
但重试必须结合业务操作的性质设计。
例如，同一笔业务请求如果被重复执行，可能导致重复创建记录或重复处理业务。
因此，需要考虑请求唯一标识、幂等处理或业务状态校验等机制。
第三，异常记录。
接口调用失败时，应该能够记录必要的请求信息、错误原因和处理状态。
记录内容还需要遵守企业的数据安全要求，避免在日志中不必要地保存敏感信息。
第四，数据一致性。
两个系统可能分别保存自己的业务数据。
当接口调用失败、数据校验不通过或后续处理异常时，需要明确如何发现和处理不一致的情况。
这些问题不是 Web Service 特有的，但在同步调用模式下，通常需要结合请求与响应机制进行设计。 Continue reading “《TOGAF学习之路》企业架构实践（三）：企业应用集成——从 Web Service 到消息队列”
