6 通过网关进行服务编排

6.1 服务编排背景与挑战

6.1.1 服务化拆分

服务化拆分的本质是为了将复杂的问题简单化，像分层架构、面向服务架构、微服务架构；从目前主流的微服务架构的角度来说，拆分的对象包括：业务、数据、服务、代码。业务拆分可根据功能分解，比如开放-关闭原则，“我的地盘我做主”，关闭对该业务的所有数据的操作，而是通过关联接口或服务进行开放；根据DDD领域模型思想，将功能拆分成独立的业务逻辑、独立的业务规则、封装好的业务模块。数据拆分包括对数据库拆分和数据表拆分。服务拆分包括将服务拆分为原子服务和组合服务。代码拆分包括微服务拆分和前后端分离。

服务化拆分后所带来的优势：

• 解耦：服务之间是松耦合，内部是高内聚。
• 独立：服务可以独立打包、发布、部署、扩容和升级。

服务化后也带来了诸多的挑战，这主要体现在分布式带来的复杂性，如事务一致性、测试、监控。

6.1.2 中台赋能

中台我们都知道：中台本身就是为业务隔离而设计，以便于一套系统能够支撑不同模式的业务和便于定制化扩展。它能够提供基于API接口级的业务服务能力，并结合DDD领域模型将所在的微服务和前端微应用组合为业务单元。业务中台通常会划分为中台能力层和组合层，其中业务中台能力层的分是为了更好的进行业务沉淀、能力复用；业务中台组合层是通过业务中台基础能力层提供出来的业务能力，对业务重新组合，比如订单类服务、账单类服务等，合既是一种策略，但也在所难免。

6.1.3 API服务治理

API服务治理核心要解决的问题就是服务之间的依赖，始终在考虑如何把各个服务之间的关系变成高内聚，低耦合的状态。中台各服务之间互相解耦，只要统一对外接口，禁止直接访问内部数据。我不需知道你的服务，只需要了解你的接口状态，以此来降低开发沟通成本。业界通过理查森成熟度模型来决定服务的成熟度,来衡量 API服务治理的效果。如图6.1所示。

图6.1 API成熟度模型

API服务治理的成果，可以实现利用API来创新API市场达到以下成效，如以下三个方面：

（1）创造经济价值，拓展收入渠道；

（2）增强合作伙伴协作，推动业务开放创新；

（3）扩大品牌影响力，提高市场占有率；

6.1.4 挑战

在微服务架构的背景下，随着业务微服务变得越来越多，系统之间交互关系变得错综复杂，还有千丝万缕的代码以及理不清的调用关系，通过网关已经无法管控到这一层面，而上层应用想要基于这些服务快速地构建应用，也不可能简单通过调用一个服务就能实现。

微服务架构使得服务、代码、接口交互变得复杂，从而导致业务实现变得愈加困难，主要弊端体现在以下三个方面：

• 缺少全局的业务视图：缺少全局的业务视角来反应整个业务域的上下游整体的运行情况；
• 业务与能力没有隔离：业务与平台代码没有分离，在技术方案评估时，现有平台有哪些能力可以复用；需要变更对现有哪些业务会有哪些影响，类似需求重复建设。 需求发布上线后，随着时间的推移，人员的更换。逐渐没有人知道这个需求当时是如何实现的，而再次遇到类似需求的方案评估，又只能翻代码，或者重复实现一次。
• 控制和逻辑没有解耦：从算法的角度上理解，逻辑用来解决实际的问题，控制决定用什么策略来解决问题。

除了上述弊端外，还有新小业务无法快速试错；内部大量重复建设，缺乏业务核心的固化沉淀，系统不满足业务发展只能推倒重建；无法满足业务的不确定性要求；业务创新困难，无法支撑市场高速变化，如渠道扁平化管理，统一会员营销，全渠道等。企业信息化程度不足，大量人工统计，核心业务没有做到实时、在线、统一。业务系统割裂，数据孤岛，端到端无法实时协同，更无法基于现有系统进一步构建数据中台。

6.2 什么是服务编排

服务编排相关概念如下：

1）服务协作：每个服务都需要知道和说明自己接受和发送消息的约定，所有服务作为参与者都需要事先明确自己的活动顺序。

2）服务组合是指以流程的方式完成服务的编排（orchestration)，一般称为复合服务，也具有服务接口。

3）服务编排关注的是众多的服务的调用链如何的组织，通常会由一个中心协调者（如音乐指挥）完成，实际生活中诸如图一场音乐会的演奏，指挥家指挥及协调音乐家弹奏，各音乐家互不干扰，按曲谱弹奏即可。

服务编排是服务组装的过程，不是简单完成单一服务的设计和开发，即将多个原子服务组装在一起，最终形成一个新的接口能力。从服务角度，它更多的是关注对这些原子服务的调用链如何进行组织。

服务编排通过聚合已有的API接口，实现对业务的重组或重构，以此对外提供新的API服务能力。具体是通过一个请求依次完成调用多个微服务，并对每个服务返回的结果进行数据整合处理，最终形成一个能够满足业务要求的结果集返回给前端。总之，服务编排有以下优势：

• 简化前端调用，对前端优好，无需发起多次API请求；
• 功能解耦，服务能够被复用；
• 实现对业务的重组或重构，以及数据聚合能力；
• 返回数据改动时，对接口无影响。
• 原有系统发生改动时，可通过编排服务做兼容性处理；
• 业务响应速度快，服务能够被快速生成。

6.3 服务编排架构

服务编排整体架构如下图6.2所示：

图6.2 服务编排整体架构

服务编排整体架构共划分为四层，分别为展示层、网关层、聚合层、中心层，如图2-1流程编排整体架构所示，各层职责具体描述如下：

展示层：包括界面服务编排和各渠道使用接入方，其中界面服务编排为前端可视化界面，可进行拖曳式操作，将已有的API接口（如Restful、WebService等）按一定的业务逻辑和流程进行可视化编排的过程，以方便完成服务编排；各渠道接入方通过使用流程编排服务提供的API编排能力实现其所需完成的业务功能，简化了调用过程，降低了接口依赖耦合度，提高了接入开发效率。

网关层：网关作为与外部交互的唯一入口，提供了统一接入、协议转换、编码解码、服务路由、限流熔断、安全认证、安全加解密、负载均衡、指令寻址、日志推送等功能。网关根据API路由规则配置，可将请求转发至聚合层和中心层相关服务，如当网关识别到为API编排请求时，则将转发请求至流程编排服务，并由流程编排服务完成最终请求响应。

聚合层：包括流程编排服务和API聚合服务。流程编排服务又划分为服务接入层、流程调度引擎层和数据流处理层，从而使请求接入、流程处理、数据处理解耦；服务接入层负责接收到从网关转发的服务请求后，通过请求标识查找相应的编排配置内容（文件），并提交至流程调度引擎层；流程调度引擎层根据编排配置内容构建一个流程调度引擎进行自动化调度执行；数据流处理层负责对流程调度过程中的每个节点的数据进行输入输出处理，将各环节的结果数据进行归集，根据相应的数据权限设置对最终结果进行处理并返回。API聚合服务将已有的API接口（如Restful、WebService等）重新聚合成为一个新的API接口，也可以通过聚合现有的API接口进行业务逻辑的重组与重构，可以对业务数据进行聚合处理。

中心层：中心层为各业务中心的微服务，接收网关层的路由转发请求及为聚合层提供服务接入。

6.4 服务编排运行模型

前端应用发起API调用请求，经网关识别到为API编排请求后转发至编排微服务。编排微服务接收到请求，经由请求拦截过滤分发器可分发至不同的过滤器进行个性化授理，也可直接提交至流程调度引擎执行。服务编排运行模型分为串行模式和并行模式，如图6-3服务编排运行模型（串行模式）、图6-4服务编排运行模型（并行模式）所示。

图6-3服务编排运行模型（串行模式）

图6-4服务编排运行模型（并行模式）

流程调度引擎分为两个组成部分：流程引擎解析层和工作流程执行层，流程引擎解析层负责流程规则解析、执行关系解析、元数据解析及语义转换等处理工作，工作流程执行器负责具体的API调度流程控制和过程控制决策；并通过使用切面技术和过滤器技术，实现流程调度前后处理、服务调用、中间流转环节处理等功能。工作流程执行层具体实施API调用流程调度，采用责任链模式和观察者模式两者相结合，根据流程规则，实现对调度活动的拦截和数据过滤处理。

流程引擎语言是基于JSON、XML格式的结构化语言，用于描述和定义编排工作流程中的业务逻辑。在执行时，服务编排将根据编排工作流程定义依次执行相关步骤。编排工作流程由执行节点和过程数据构成，具体介绍如下：

（1）执行节点

执行节点是服务编排工作流程的一个基本单元。每个节点接入输入数据，对数据进行操作处理后，将输出数据传递给下一个节点。节点的组合使用构建了复杂的业务逻辑。通常节点代表的是原子服务接口。

• 链路节点
• 条件节点
• 子流程节点

（2）过程数据

服务编排工作流程的数据分为三类：输入数据、过程数据、输出数据，对应数据处理环节如下：

• 输入数据：初始入参数据，请求过滤器接收到的请求参数。
• 过程数据：活动上下文数据，在活动节点之间流转的数据。
• 输出数据：所有节点执行完成后，最终合并结果并输出的数据。

在对过程数据处理过程中，涉及到数据处理的工作，分为数据字段的拆包和数据封包。

• 字段拆包：将活动节点执行结束后的返回内容提取出来，以作为下一活动节点的请求参数或当前活动节点的返回结果。
• 数据封包：将各活动节点执行结束后的数据整体打包为最终返回的一个对象。

6.5 未来展望

通过服务编排，最终实现让代码更简洁、业务更有序、管理更高效，包括但不限于以下目标：

• 简化服务调用复杂度
• 持续交付
• 调用链路清晰，代码无侵入，业务感知；
• 灰度发布
• 业务聚合
• 业务不确定性 业务不确定性