Day34-21｜15.9.1 原有系统架构中的集成需求：在保留遗产中实现渐进演进
Day34-21｜15.9.1 原有系统架构中的集成需求：在保留遗产中实现渐进演进
对应教材：第15章 面向服务架构设计理论与实践——15.9.1 原有系统架构中的集成需求
学习目标：理解遗留系统集成需求的来源与特点；掌握业务、数据、技术和组织约束的分析方法；能够选择适配器、包装器、消息、文件和数据库迁移等集成方式；在案例分析中提出风险可控的渐进式架构方案。
一、为什么原有系统集成是架构难题
企业信息化通常不是从一张白纸开始。经过多年建设，组织中同时存在主机系统、客户机/服务器系统、Web 应用、ERP、CRM、数据仓库和各类外部平台。这些系统承载着稳定运行的业务和历史数据，不能因为架构升级就全部停机重写。
原有系统集成的难点在于：系统仍然有业务价值，但接口、数据模型、技术栈和责任边界已经不适合新需求。集成方案既要保护现有投资，又要避免把旧系统的缺陷继续传播到新架构。架构师需要回答四个问题：为什么要集成；集成什么；通过什么方式集成；如何控制集成后的风险。
集成需求可以抽象为：
业务变化 → 新旧能力协作 → 数据与流程交换 → 兼容与治理约束 → 渐进式演进
不能只把“增加一个接口”当作需求。真正的集成需求还包括数据同步、身份互认、事务协作、质量目标、审计合规、运行监控和退役计划。
二、集成需求的主要来源
1. 新业务需要复用旧能力
新商城希望复用老 ERP 的客户、商品和财务能力；移动端希望使用既有会员系统；新的审批平台希望调用旧人事系统。此类需求重点是把旧能力包装成可理解、可控制的服务，不能让新系统直接依赖旧数据库结构。
2. 旧系统需要接入新平台
遗留系统可能需要接入统一身份、消息平台、数据平台、监控平台或工作流平台。由于旧系统改造困难，通常需要适配器、代理或批处理接口。架构师要明确哪些能力可以实时开放，哪些只能通过文件或定时同步提供。
3. 数据整合与主数据统一
客户、组织、商品和供应商信息在多个系统中重复维护，导致编码、状态和属性不一致。集成需求不只是“把数据复制过去”，还要确定权威源、数据标准、同步方向、冲突处理、质量校验和历史数据治理。
4. 跨系统业务流程
订单、支付、库存、履约和财务可能由不同系统负责，需要形成完整业务流程。此时要分析同步和异步边界、流程状态、异常补偿、人工介入、超时和审计要求，不能用简单接口串联掩盖流程复杂度。
5. 技术和合规要求
统一安全、数据脱敏、日志审计、灾备、性能和可用性也会产生集成需求。一个旧系统即使没有新业务，也可能必须接入统一认证、漏洞扫描和监控体系。
三、集成分析维度
1. 业务维度
明确业务目标、参与角色、流程边界、业务规则、事务范围和失败后果。核心交易、查询、批处理和通知的要求不同。需要确认业务是否要求实时、是否允许最终一致、是否允许人工补偿，以及数据的合法使用范围。
2. 数据维度
分析数据格式、编码、粒度、频率、所有权、质量和敏感级别。重点识别同名不同义、不同名同义、单位不同、时间格式不同和状态码不同的问题。数据转换必须写清语义映射，不能只做字段名称映射。
3. 技术维度
考察旧系统支持的接口、协议、吞吐量、连接限制、部署环境、操作系统、数据库、批处理窗口和改造能力。技术限制直接影响实时集成和容错方案，例如老系统只能每天批量导出，就不能承诺秒级同步。
4. 质量维度
确定延迟、吞吐、可用性、可靠性、安全、可维护性、恢复时间和数据丢失目标。新旧系统之间的最低质量目标不一致时，需要通过缓存、队列、适配器、隔离和降级保护消费者。
5. 组织维度
明确系统负责人、数据负责人、运维团队、外部厂商和变更审批人。很多集成失败不是技术问题，而是无人负责、窗口冲突、接口承诺不一致和故障处置流程缺失。
四、常见集成方式
1. 直接接口调用
新系统直接调用旧系统提供的 API，实施快，但会把旧协议、错误和性能限制传播给新系统。只有在接口稳定、边界清晰、质量可接受且安全可控时才适用。
2. 包装器或适配器
通过独立适配器封装旧接口，将旧协议和数据模型转换为统一服务契约。适配器保护新系统免受遗留细节影响，也便于未来替换旧系统。缺点是增加一层开发和运维成本，必须做好追踪、超时、错误映射和版本管理。
3. 反腐层
反腐层在新旧模型之间建立隔离边界，防止遗留系统的概念污染新领域模型。它不仅转换字段，还翻译业务语义、状态和错误。对于模型差异较大的核心系统，反腐层比简单字段映射更合适。
4. 文件和批处理
文件交换适合低频、大批量、历史系统改造能力弱的场景，但实时性差，异常重跑和重复处理复杂。必须定义文件命名、校验、加密、传输确认、重复检测、失败隔离和对账规则。
5. 消息和事件
消息适合削峰、异步解耦和跨系统通知。遗留系统可以由适配器将批量变化转换为事件，也可以通过消息驱动新流程。需要处理重复、顺序、死信、重放和数据版本。
6. 数据库直连与数据复制
数据库直连开发成本低，但耦合最强，容易绕过业务规则和权限。若只是建设分析副本，可采用日志捕获、ETL 或受控复制，并明确只读、延迟和数据质量边界；核心交易集成不应把数据库直连作为长期方案。
五、渐进式集成路线
第一步进行资产盘点，记录系统能力、数据权威、接口、负责人、消费者和质量等级。第二步定义目标服务模型和统一术语，选择优先改造的业务能力。第三步用适配器或包装器提供兼容服务，避免新系统继续直接依赖旧实现。第四步引入消息和事件处理可异步流程，降低实时调用链。第五步逐步迁移数据和业务规则，建立新旧结果对账。第六步在消费者迁移完成、旧接口流量归零后退役遗留入口。
渐进路线必须保留回滚和双运行策略。双写会带来一致性风险，应通过幂等、对账和明确的主写源控制；双读要定义结果选择和差异告警；灰度切换应按租户、区域或业务类型进行，不能一次性切换全部流量。
六、案例：老 ERP 接入新订单平台
某企业建设新订单平台，但财务和供应链能力仍在旧 ERP 中。新平台若直接访问 ERP 数据库，会依赖表结构和存储过程，且无法满足高峰订单的响应目标。架构团队决定建设 ERP 适配层。
新订单平台 → 订单服务 → 适配层 → ERP 服务接口/批处理 ↓ ↓ 订单事件 对账与补偿
实时查询采用缓存和受控服务接口；批量记账通过消息和文件适配器完成；适配层将 ERP 错误码转换为统一错误；所有调用携带 traceId 和业务流水号；记账结果通过事件返回订单服务；每日对账发现差异后进入补偿流程。随着 ERP 能力逐步迁移，适配层保持契约不变，只替换内部实现。
七、风险与控制
风险一是遗留系统成为性能瓶颈，控制措施是缓存、队列、限流、批量和资源隔离。风险二是旧系统故障传播，控制措施是超时、熔断、降级和异步解耦。风险三是数据不一致，控制措施是幂等、对账、补偿和明确主数据。风险四是安全边界扩大，控制措施是适配层认证、最小权限、脱敏和审计。风险五是临时适配永久存在，控制措施是登记迁移目标、负责人和退役日期。
八、考试答题模板
题目问“如何集成遗留系统”，可按“需求分析—能力和数据盘点—选择适配器/包装器/消息/文件方式—统一契约—定义一致性和异常—安全与 QoS—监控审计—渐进迁移和退役”回答。题目问“为什么不直接访问数据库”，要写结构耦合、规则绕过、权限扩散、性能风险、变更困难和审计缺失。
论文中可写：面对无法一次性替换的遗留系统，我采用适配器和反腐层隔离旧模型，以统一服务契约对外提供能力；对实时需求采用受控接口和缓存，对批量需求采用消息与文件适配；通过幂等、对账、补偿、链路追踪和灰度切换控制迁移风险，最终在消费者完成迁移后退役旧接口。
九、课后练习
- 为什么遗留系统集成不能只做字段映射？
参考答案：不同系统可能存在业务语义、状态、单位、时间和错误处理差异，字段同名不代表含义相同；需要进行模型翻译、规则映射、校验、异常和版本处理。
- 文件接口如何防止重复导入？
参考答案：使用唯一文件编号和业务批次号，传输完成后校验摘要，记录处理状态，成功文件归档，重复文件拒绝或返回原结果，失败文件进入隔离目录并支持安全重跑。
- 渐进迁移为什么需要对账？
参考答案：双写、异步传播和旧系统异常都会造成差异；对账可以发现遗漏、重复和状态不一致，为补偿、灰度切换和旧系统退役提供证据。
十、今日复盘
遗留系统集成的目标不是把旧系统原样搬到新平台，而是在保护业务连续性的前提下建立新的边界和演进路径。架构师要先理解业务和数据，再选择适配器、消息、文件或复制方式，并通过契约、监控、对账和退役计划控制长期风险。
