目前，我国对于业务中台的研究和实际建设已有很多，但对于业务中台建设与现有成熟套装软件的集成方式鲜有涉及。本文借鉴《基于 SOA 企业遗留系统集成的研究和应用》中使用 Web Service 适配器支撑 SOA 系统与企业遗留系统集成的方法，以及 Martin Fowler 提出的“绞杀者”应用模式重构单体系统的思路，提出了一套与遗留系统集成重构的业务中台建设方法。通过制定业务中台与遗留系统的集成策略，并采用集成胶水、定义通信方式、维护数据一致性 3种手段，实现业务中台与成熟套装软件的有效集成，解决企业业务中台建设中面临的遗留系统问题。

1 中台战略与成熟套装软件的冲突与并存趋势

2015 年，阿里巴巴公司提出中台架构概念，通过沉淀企业核心业务能力构建大中台。中台架构已成为大型企业数字化转型的重要核心架构。我国现行企业和机构普遍都有信息化建设的基础。目前，各企业的信息系统体系基本都是以购买的成熟套装软件为核心。各个成熟套装软件由于研发厂商、部署模式、使用技术等多方面的巨大差异，使得企业数字化横向联动、纵向贯通的目标难以达成。企业业务中台的建设应集成融合现有成熟套装软件，逐步构建各业务板块的业务中台系统。这种集成融合的业务中台建设难度堪比高速公路上为行驶中的汽车更换轮胎。

2 业务中台与遗留系统的集成策略

Martin Fowler 针对单体式系统向微服务系统改造的策略，提出了“绞杀者”应用模式，即在原单体系统周边逐步建设开发新的微服务架构的新系统。随着微服务越来越多，原单体系统逐渐被新系统取代。建设企业业务中台时，可借鉴该“绞杀者”应用模式，在原成熟套装软件周边开发新中台服务，由简到繁、由易到难地逐步建设。下面将具体讨论在成熟套装软件周边构建企业业务中台的策略。

2.1 横向提取分割策略

随着互联网及手机 APP 应用的发展，越来越多的移动互联操作需求应运而生。原成熟套装软件往往部署在企业内网，受限于部署模式以及旧的软件架构，无法适应移动互联的需求，导致企业信息化被局限在企业内网，难以扩展触及业务一线。当出现对原系统的新需求时，可横向提取表现层，利用微应用建设试点来推动业务中台建设，而非在原系统上继续做改造和二次开发。使用最新的架构和技术重新实现原系统的表现层。作为新的微应用入口，其应满足不同用户群体和不同使用场景。如图 1所示，横向提取应用入口并进行迁移，构建支撑表现层的新的业务中台服务，通过集成胶水代码实现业务中台与原系统在业务逻辑层的交互，业务中台即可快速提供对外服务支撑。

图1 横向提取应用入口迁移

2.2 纵向分层提取策略

完成业务表现层横向提取分割后，将采用纵向提取分离的策略继续完成业务中台的构建。理想情况下，一个独立完整的功能表现为纵向构建。

（1）表现层具备复杂多变的用户界面，及满足定制化需求的业务逻辑代码，通过 HTTP 请求与中台业务逻辑层进行交互。（2）业务逻辑层是业务中台的核心部分，由实现各种通用业务规则的模块组成。（3）数据持久层包含业务中台的核心数据库。如图 2所示，从业务表现层、业务逻辑层、数据持久层自上而下纵向开展中台提取工作。纵向提取分割中有两项重要的工作，分别是拆解原系统的领域模型以及重构领域服务。

拆解原系统的领域模型：通常纵向拆分的领域模型应当是较为独立、边界较为清晰的领域模型。而边界不清晰的领域模型和有依赖关系的模型可以使用主键而非对象引用。从原系统中提取领域模型后，表从原系统的数据库移动到中台的数据库需要把具体的数据库。通过从原系统的数据库中梳理相关领域的表和字段，重新设计构建中台的领域模型持久层数据库表，复制这些数据到中台的数据库中，以支撑新的中台功能和领域模型。

重构领域服务：对数据持久层进行提取后，就可以基于分离出的新的数据持久层构建相应的领域服务。业务逻辑层构建完成后，原先的系统间集成胶水代码即可去除，改为直接使用新构建的业务逻辑层领域服务。

图2 从表现层、业务逻辑层、数据持久层纵向提取

3 业务中台与成熟套装软件的协作方式

由于业务中台与成熟套装软件两个异构系统存在技术、架构差异性，从设计集成胶水、定义系统间的通信方式、维护数据一致性 3 个方面入手，确保两个异构系统间的高效、可靠交互协作。

3.1 设计集成胶水

为实现中台与原系统间的交互协作，须开发集成胶水代码。集成胶水代码部署在中台与原系统间的出站、入站适配器中。由于业务中台与原系统的数据模型存在差异，必须实现 DDD 中称为反腐层的部分，以确保中台和原系统间的顺畅通信。在这里，反腐层的作用是防止原系统的领域模型对业务中台的领域模型造成污染。为了降低改造难度，需要将反腐层放置在业务中台侧与原系统交互的出站、入站适配器中。这也是业务中台建设过程中，解决与原系统集成时需要注意的关键点。

3.2 两系统间交互通信方式

由于原成熟套装软件往往技术较老，推荐使用基于Web Service 的 API 同步接口方式。Web Service 技术一般用于跨平台系统间的通信，可以由不同的开发语言来实现。通过 WSDL（Web 服务描述语言）来描述服务接口，使用 SOAP 协议和 XML 格式传递数据。业务中台可以引用Apache 的 CXF 组件来实现并对外发布 Web Service 接口。业务中台也可以使用 Axis 组件外部系统发布的 WSDL 文件生成对应的 Java 类，这样业务中台就可以像调用本地Java接口一样调用外部的Web Service服务。

3.3 维护数据一致性

根据数据变更的发起方，分两种情况讨论：原系统数据变更与业务中台数据变更。

原系统数据变更：业务中台需要保持与原系统的数据一致。由于原成熟套装软件内部的逻辑完整性，当原系统数据变更后，业务中台应无条件与原系统保持一致。

因此，原系统的数据变更是“关键性事务”，业务中台的数据变更是“可重复性事务”。业务中台只需在接收到原系统数据变更命令后，确保中台数据变更成功即可。原系统发起数据变更事务，原系统与业务中台的数据流向及处理策略如图3所示。

图3 原系统发起数据变更事务

业务中台数据变更：由于原成熟套装软件在专业业务领域的权威性，往往业务中台数据发起变更请求后，还需要在原成熟套装软件上经过业务校验才能判断该数据变更请求是否合法。因此，业务中台发起数据变更事件是“可补偿性事务”；原系统随之进行数据校验和变更是“关键性事务”；原系统变更成功后，业务中台数据确认变更成功是“可重复性事件”。如图 4 所示，业务中台发起数据变更事务处理。

图4 中台发起数据变更事物处理

由于业务中台常常会同时发起多个数据变更事件，为了保证分布式事务的隔离性，引入中台数据交换 ID 方法，用以区分不同数据变更事件。即业务中台发起数据变更，首先针对该条变更的数据生成唯一的中台数据交换 ID，并将该数据变更后的状态标记为 UPDATE_PENDING。原系统验证该条数据变更是否合法，验证通过后，向业务中台发送确认变更成功请求，请求中带回中台数据交换 ID及确认变更成功信息。业务中台收到确认变更成功返回信息后，通过中台数据交换 ID 找到该条数据，并将数据状态标记为UPDATE_COMMITED。

通过以上 3 种技术手段（设计集成胶水代码、定义系统间通信方式、维护数据一致性），可以实现业务中台与原成熟套装软件异构系统的可靠运行。

4 结语

本文提出一种企业业务中台与成熟套装软件的集成方法，并借鉴遗留系统重构的“绞杀者”模式，采用表现层迁移及纵向分层提取策略，使原系统在其专业领域下正常运行，同时有序推进业务中台建设。通过设计集成胶水代码与系统间通信交互方式，实现了业务中台与成熟套装软件间的交互协作。此外，设计了业务中台与成熟套装软件间维护数据一致性的模式，确保业务中台与成熟套装软件数据孪生架构的数据可靠性。目前，基于本文设计思路的成果已应用于新一代企业业务中台的建设中。实践表明，该设计能有效指导企业业务中台的建设，为企业数字化转型和快速有效推进业务中台建设提供指导方法。

作者：国网电力科学研究院有限公司  朱泐 胡竹青