Day34-06｜15.3 SOA 的参考架构：从服务目录到业务流程的企业级组织方式

一、教材定位与学习目标

15.3“SOA 的参考架构”把前面讲过的服务、契约、流程和治理组织成一套可用于设计的结构。它不是要求所有企业照搬同一张图，而是提供分析企业服务化系统时的共同语言：谁提供服务，谁消费服务，如何发现服务，消息如何传递，业务流程如何组合，数据如何管理，安全和监控如何贯穿。

高级系统架构设计师考试中的参考架构题，通常要求考生根据企业现状补充组件和依赖。例如题目可能描述多个遗留系统、统一门户、跨部门审批和外部合作方，要求设计服务层、总线、注册中心、流程层和治理层。答题时既要给出结构，也要说明每个组件解决什么问题以及可能的瓶颈。

二、SOA 参考架构的分层视角

可以从业务、服务、实现、集成和治理五个视角组织参考架构：

一种常用结构是：

渠道与消费者
  ↓
业务流程/组合层
  ↓
企业服务层：基础服务、业务服务、数据服务
  ↓
集成与适配层：API、消息、ESB、遗留适配器
  ↓
应用与资源层：ERP、CRM、主机、数据库和外部伙伴

治理、安全、监控、配置和服务目录横向贯穿

参考架构的价值在于把“业务能力”和“技术实现”分开。一个服务可能由多个应用和数据库共同实现，消费者只看到稳定契约；一个流程也可能组合多个服务，但流程层不应直接操作底层表。

三、服务提供者、消费者和目录

3.1 服务提供者

服务提供者实现业务能力，发布契约、服务等级、访问策略和版本。提供者要负责服务可用性、性能、错误语义、数据质量和生命周期，不能只把接口上线后交给别人自行理解。

3.2 服务消费者

消费者根据目录和契约发现服务，按照约定调用或订阅。消费者需要遵守访问权限、流量配额和版本策略，并负责自身的超时、降级和业务异常处理。消费者不能依赖提供者内部类、表或未公开字段。

3.3 服务目录与注册中心

服务目录保存服务名称、能力、接口、版本、所有者、质量、依赖、数据级别和生命周期状态。运行时注册中心可以维护实例地址、健康状态和动态发现。二者并不完全相同：目录偏向设计和治理，注册中心偏向运行时定位。

服务目录要避免成为没人维护的文档仓库。服务注册、版本发布、退役和变更应与流水线和权限系统联动，服务信息必须有负责人和更新时间。检索和评审应能帮助团队复用已有能力，减少重复建设。

四、企业服务层的组成

4.1 基础服务

基础服务提供身份、组织、客户、地址、通知、文件、时间和审计等通用能力。它们通常被多个业务流程复用，需要较稳定的契约、较高的可用性和明确的权限边界。

4.2 业务服务

业务服务围绕订单、库存、采购、支付、理赔、授信或合同等业务能力组织，包含领域规则和状态。业务服务应保持自治，拥有数据责任，并通过契约和事件与其他服务协作。

4.3 数据服务

数据服务提供查询、统计和数据交换能力，但不能把数据库表机械包装成 API。查询服务可以采用专用读模型，交易服务负责写入和规则；数据服务要明确数据来源、更新延迟、权限和质量。

4.4 外部伙伴服务

银行、物流、支付、供应商和政府平台等外部能力通过适配器或伙伴服务接入。适配器负责协议、字段、认证和错误转换，内部服务使用统一模型。外部接口的超时、限流、熔断和版本变化不能直接传播到核心业务。

五、组合层与业务流程层

组合层把多个服务组织成面向业务场景的流程或复合服务。例如“企业客户开户”可以组合客户创建、信用校验、合同生成和通知服务；“采购履约”可以组合预算、审批、供应商、收货和付款服务。

组合层有三种常见职责：

1. 组织调用顺序、条件和并行关系。
2. 保存流程实例状态和跨服务关联键。
3. 处理超时、异常、补偿和人工干预。

组合层不能把所有领域规则重新实现一遍。信用额度由信用服务负责，库存规则由库存服务负责，流程层只协调。组合服务也不应成为万能入口，否则会出现巨型编排中心和难以维护的流程。

六、集成层：API、消息、适配器与 ESB

6.1 API

API 适合同步查询、命令和需要立即反馈的场景。接口应定义认证、参数、错误、超时、幂等和版本。API 网关可以提供路由、认证、限流和审计，但不能承载所有业务事务。

6.2 消息与事件

消息适合异步任务、事件通知、削峰和跨组织解耦。事件要有编号、版本、时间和业务关联键，消费者要处理重复、乱序、积压、重试和死信。可靠发布可以采用本地事务加发件箱或事务消息。

6.3 适配器

适配器把遗留系统、外部伙伴和不同协议转换为统一服务模型。它可以隔离主机接口、文件交换、SOAP、REST、数据库存储过程和专用 SDK。适配器应保持薄，核心业务规则不能长期沉淀在协议转换层。

6.4 ESB

ESB 可以提供路由、协议转换、消息转换、安全、监控和部分流程能力，适合遗留集成和企业级治理。但所有流量强制经过一个中心总线可能造成瓶颈和单点，实时微服务调用和大规模事件流应根据场景选择轻量 API 或消息平台。

七、数据架构与事务边界

参考架构中，服务层、数据层和集成层之间应有清晰责任。服务拥有业务数据的逻辑所有权，数据访问通过服务接口或授权查询；流程层不直接连接多个数据库；报表和分析尽量从读模型、数据仓库或数据湖获取，避免冲击交易系统。

服务内部的订单、明细和状态可以使用本地事务；跨服务流程采用事件、状态机、幂等、补偿和对账。若企业确实需要分布式事务，应评估性能、锁、可用性和参与者能力，不能把所有流程都放入长事务。

数据需要区分权威、缓存、读模型和分析结果。消费者看到的查询延迟、数据更新时间和一致性等级应写入服务质量契约。数据复制和同步要记录来源、版本、时间和错误，支持重放和补偿。

八、安全与治理横切架构

8.1 身份与访问控制

服务、用户、设备和外部伙伴应使用相应身份体系。网关可以进行入口认证，服务内部仍需授权；按角色、组织、租户和资源限制访问范围；服务账户遵循最小权限，管理面和业务面分离。

8.2 契约、版本与生命周期

服务契约、消息模式、流程定义和配置都应版本化。新旧版本共存时保持兼容，退役前通知消费者并提供迁移窗口。服务目录记录所有者、质量和依赖，避免服务无人维护。

8.3 监控、日志与审计

系统需要统一指标、结构化日志和分布式追踪，关联请求标识、业务单号、版本和租户。审计重点记录服务发布、权限变化、数据导出、流程状态、关键业务操作和外部回调。敏感字段脱敏和加密，日志访问也要受控制。

8.4 配置和策略

路由、限流、重试、熔断、权限和服务等级可以作为策略管理，但策略变更要经过校验、审批、灰度和回滚。治理不能完全依赖人工文档，应该尽量与流水线、目录和运行平台联动。

九、部署架构与高可用

SOA 参考架构可以部署在应用服务器、虚拟机、容器或云平台上。部署设计要考虑服务实例、网关、消息、注册中心、数据库、存储和外部网络的冗余。高可用不仅是多个应用实例，还包括数据副本、备份恢复、故障切换和业务降级。

运行时应设置健康检查、超时、连接池、线程池、限流和资源配额；关键组件跨可用区或故障域部署；配置和证书支持轮换；发布支持滚动、蓝绿或灰度。控制面故障时，数据面尽量使用最后有效配置继续运行。

灾备要明确恢复时间目标和恢复点目标，设计备份、数据复制、演练和切换流程。SOA 系统的外部伙伴也属于故障域，不能只对自己的服务器做冗余而忽略支付、物流和主机依赖。

十、参考架构的案例落地

某集团需要整合采购、库存、财务和供应商系统，并为移动审批和供应商门户提供服务。可以把供应商、采购申请、预算、合同、收货和付款抽象为业务服务；遗留 ERP 和财务主机通过适配器接入；采购审批由流程层编排，审批结果通过消息通知库存和财务；服务目录记录接口、版本和所有者；网关负责门户认证、路由和限流；报表从数据平台读取；安全层提供统一身份、权限、加密和审计。

采购申请提交和预算扣减在相应服务内使用本地事务，供应商询价和通知采用异步消息，付款结果通过回调和对账确认。供应商接口故障时，流程状态进入等待或人工处理，不阻塞全部门户；消息积压时，优先处理审批和付款，低优先级统计延后。

十一、课后练习

练习一：选择题

SOA 参考架构中，服务目录与运行时注册中心的主要区别是（ ）。

A. 二者完全没有区别

B. 服务目录偏向服务能力、契约和生命周期治理，注册中心偏向运行时实例发现

C. 注册中心负责保存业务订单，服务目录负责数据库备份

D. 服务目录只能管理物理服务器

答案：B。 二者可以协同，但关注范围和生命周期阶段不同。

练习二：简答题

为什么 SOA 参考架构需要同时包含 API、消息和适配器？

参考答案： API 适合同步请求和即时反馈，消息适合异步解耦、削峰和事件传播，适配器用于隔离遗留系统和外部伙伴的协议差异。企业场景既有实时调用，也有异步流程和异构集成，单一通信方式无法兼顾延迟、可靠性、解耦和兼容性。

练习三：案例题

某企业把所有服务、流程、数据转换和安全规则都集中在一个 ESB 中，导致总线升级影响所有应用。请分析并提出改进。

参考答案： ESB 承担了过多职责，形成集中式瓶颈和单点，服务自身缺少业务自治，流程和转换难以独立发布。应把核心业务规则归还业务服务，流程由独立流程层管理，复杂数据转换由适配器或专用集成服务负责，实时调用按需采用 API 或轻量通信，异步场景使用消息平台；ESB 保留遗留协议转换、跨组织路由和必要治理，并进行冗余和分区。策略、契约、日志、追踪和安全统一治理，迁移采用分批、灰度和回退，验证延迟、吞吐、故障影响范围和发布独立性。

十二、论文写作素材

本节适合写“论 SOA 参考架构在企业集成中的应用”“论服务化系统的分层与治理”或“论遗留系统与新应用协同”。论文可按渠道、流程、服务、集成、应用资源和治理层组织，重点描述服务目录、契约、适配器、消息、事务和安全。

写作中应体现组件边界：流程层负责协调，业务服务负责规则，适配器负责协议，数据平台负责分析，网关负责入口，ESB 负责适合的集成。最后写服务等级、监控、审计、灰度、回滚和灾备，避免只画一张“总线连接所有系统”的静态图。

十三、今日复盘清单

• 我能否画出 SOA 参考架构的业务、服务、实现、集成和治理层？
• 我能否区分服务目录与运行时注册中心？
• 我能否说明流程层、业务服务、适配器和 ESB 的职责边界？
• 我能否为 API、消息和外部伙伴设计不同通信策略？
• 我能否写出服务内部事务与跨服务最终一致性的处理方法？
• 我能否补充安全、观测、版本、部署和灾备治理？

本节的核心结论是：SOA 参考架构通过业务流程、服务层、实现层、集成层和治理层组织企业能力，把复用、集成、流程和运行控制纳入同一体系。架构师要根据通信和质量属性选择 API、消息、适配器或总线，明确业务规则、数据和治理边界，避免形成所有能力集中于一个平台的复杂单点。