文：戴敏

南天信息金融科技首席架构师

前言：

可以通过实施业务组件化来避开数字化转型焦油坑，具体而言就是建设“业务敏捷性组件基础设施”，包括业务组件及其支撑组件。前面文章描述了一种可参考的业务组件的体系，这个体系可以认为是一个高阶的概念性设计的成果，通过业务能力、业务领域、服务域的分析、设计可以开展后续的开发工作，而开发工作围绕对API的详细设计展开。

鉴于业务组件体系涵盖的工作内容比较多且复杂，本文讨论了一种可参考的落地实施方案，主要包括2个阶段和1个支撑：2个阶段是业务组件蓝图设计阶段、业务组件设计开发阶段，1个支撑即架构设计的支撑。

一、业务组件化实施方案

1、业务组件蓝图设计阶段：

业务组件蓝图明确展示出多级业务领域、服务域的位置，以及服务域之间的可用服务关系，包括总体图和场景图。

•      场景图：

场景图中包括场景涉及的服务域及服务域之间的服务连接，服务连接只针对场景下的可用服务连接而非所有可用服务连接；表示的服务连接在业务组件开发中映射为API服务端点之间的调用。场景图的理想设计模式是分层架构，即，场景图可以通过组装响应更高一级的业务场景。主要展示如下内容：

1）体现涉及的所有服务域；

2）体现场景中每个服务域的活跃状态时间，即业务对象在业务活动处理期间的状态；

3）体现服务域之间服务依赖关系，即先后、并行等，以及明确的服务消费方和服务提供方；

4）体现服务消费的同步响应、异步响应，异步响应应体现出响应点；

5）体现服务消费的动作，标准HTTP动词+动作标识；

6）体现服务交互的要素或文本。

2、业务组件设计开发阶段：

以业务组件蓝图为基础进行业务组件设计工作。

•      服务域设计：

利用面向对象设计方法，围绕业务对象及业务行为进行设计。为了配合后述的架构设计支撑，服务域设计中需要关注：

1）服务域交互的所有信息都应该体现在设计中，这些信息可能影响系统架构对事件的触发；

2）服务域设计应包括事件配置文件的设计，包括关联到关键信息项、信息属性的触发逻辑和触发阈值；

3）服务域设计应包括服务协议定义，包括触发服务域的策略、阈值的定义、服务性能的定义、服务完整的输入输出信息的定义、安全控制信息的定义；

4）服务域的容错处理：例如针对延迟、错误请求的处理，也可以包括类似优雅降级的处理；

5）服务域处理的幂等性设计，其中应该考虑服务域处于并行处理环境中的幂等性。

•      服务域服务操作设计：

服务操作设计需要包括几部分内容：

1）服务域的核心功能：服务域封装的业务对象的核心业务功能；

2）服务操作的动作：例如初始化、更新、检索信息等；

3）每个服务操作对应到API的一个服务端点；

4）在实现中，服务操作可能需要进行细粒度的分解，分解为不同的端点，这种分解也用于错误、异常等的处理；

5）应体现出服务操作的细节，例如消息，对于遗留系统可能还有消息负载的需求；

6）应体现出消息头、安全处理、错误处理、消息索引等附加内容。

3、架构设计的支撑：

架构设计应支撑业务组件体系，与普遍的架构设计相比关键的问题之一是对编排的支撑方案的选择。通常有2种编排方法可以选择。

一是通过专门的独立编排逻辑来实现：服务域以类似服务中心的方式构建，编排逻辑覆盖各个服务域之间的服务调用，由其保障业务操作的可重用性。但独立的编排逻辑也相当于建立了受限的重用路径，新的业务行为通常也需要额外的设计、开发工作。

二是通过事件驱动的编排：服务域通过事件自动响应，对自身支持的业务行为进行处理。当业务操作需要其他服务域进行响应时，系统架构支持服务域之间触发一系列事件，每个服务域针对自己关注的事件进行响应执行所需的各类操作。

更合适的业务组件体系是事件驱动的编排架构，这样的架构能够支撑业务组件体系更好地实现灵活性和弹性。但事件驱动的编排需要设计更复杂的架构，例如支持服务的异步级联，消费方服务域触发起事件后，服务提供方的服务域响应事件，整个级联直到所有的服务提供方都完成处理后才结束。这样的异步架构还需要考虑服务状态的同步，例如串、并、串的组合场景，和整个处理事件的控制，例如通知、中断、主动超时等，而对于执行关键路径上的服务域只要在允许时间内完成即可（非关键路径上的服务域则不同）。

系统架构还应支持事件配置文件、服务目录、数据存储、事务日志、运行数据处理、事务一致性、路由等。

二、遗留系统的组件化

业务敏捷性组件基础设施需要解决遗留系统的问题。遗留系统通常由于基础架构层面的限制而缺乏灵活性，例如：单体架构，但通常包含了大量经过验证的业务能力，彻底组件化重构这些业务能力往往需要较大投入。通常可以利用“遗留系统绞杀”的解决方案或者“针对遗留系统的特殊策略性复刻”的解决方案，本文主要从组件化角度讨论遗留系统的解决思路。

通过对遗留系统进行组件封装的方式，实现遗留系统的组件化，目的是使其能够在业务组件体系中正常运行。进行组件封装后的遗留系统也基于组件架构运行，因而也提升了遗留系统在与其他服务域进行组合时的弹性和灵活性。由于是封装模式，遗留系统内的弹性和灵活性还是大部分取决于系统自身。封装的本质是为遗留系统设计确定的组件边界和上下文，在实践中可以将一个遗留系统划分为多个组件边界。封装需要体现在蓝图、组件开发阶段中，通过这种方式也可以减少遗留系统在组件体系中的运行缺陷。

组件封装不同于以往，需要从业务对象及其相关的业务行为出发对遗留系统进行组件边界和上下文的划定，这相对以往而言工作量更大些，但好处是这种组件边界的划定在组件体系中是相对稳定的，在遗留系统生命周期剩下的时间中不容易发生变化。此处的问题是，需要在实施中结合企业的业务规划，评估哪些遗留系统更适合彻底重新建设而非进行组件封装，结合其在组件蓝图中的位置来分析将有助于评估。

在实施中，遗留系统组件化的重点是对于原有的后端高并发类的事务处理系统的组件封装，这些系统对整个组件体系的运行质量/效果影响更大。

本系列文章至此完结，主要分析了数字化转型焦油坑及避免焦油坑的主要举措：业务组件化。我们谈到了业务敏捷性组件基础设施，并重点针对其中的业务组件进行了分析和阐述。对于业务组件体系，我们谈到了其主要的几个要素：业务能力、业务领域、服务域、API。最后，我们讨论了业务组件化的落地实施方法。

随着数字化转型的深入，行业里对其的思考和实践也大部分开始转向理论指导下的各种创新，数字化转型的复杂性越来越高，对目标及实际效果特别是对业务战略支撑的效果考核比重也越来越重，迫使我们必须正视数字化转型中众多的焦油坑。这些焦油坑消耗了大量的企业实施成本，且对实施效果产生了较大的负面影响。为此，特整理了可参考的实践和思路。

所有的分析和讨论都以当下的新技术体系和能力为基础展开，代表了作者20多年的应用软件开发经验，及对前沿行业实践、技术理论的学习和思考。由于篇幅所限，很多问题没有细化展开，将适时继续展开探讨，期待与大家相互交流、分享经验。