智慧医疗基础平台-07

平台规划-协同平台

一、历史渊源

与服务协同密切相关的技术有ESB/SOA架构和微服务架构。在早期，ESB/SOA架构被广泛应用于组织之间的协同，以确保不同系统之间的通信和交互。随着微服务架构的兴起，服务编排和接口管理变得更加重要，以确保各个服务之间能正确相互通讯。

服务编排并不是一个新技能，在很多年前移动boss1.5的年代，基于API编排的编程方式就已经在多个省级项目中得到了广泛应用。

 

API编排是指将不同的API连接起来，形成一个整体的解决方案。这种方式可以提高开发效率，减少重复劳动，并且可以实现高度自动化的管理。这种模式特别适合有业务沉淀的项目，绝大部分的业务（API）是可以复用的，少量的做本地化开发，一个新的业务流程也简单，通过简单的拖拽，实现若干API的组合，新的业务流程就得以实现，借助这种模式，能在2-3个月内完成一个省级boss开发。

1. 基于MAP做数据扁平化处理，实现通用数据的传输。优点是编程模型简单，缺点就是要运行才知道是否有异常。

2. 每个API对应一个简单的业务功能，具体对应一段SQL语句。

3. 提供Eclipse RCP建模器，图形化流程拖拽设计，以及设置入参出参

4. 编译部署后发布一个功能号，前端应用只要调用这个功能号，就能完成相应业务。

 

二、开发模式

典型的三甲医院包括了数百个异构系统、数十个系统厂商，导致不同业务系统之间需求调用复杂、接口数量多且无统一标准、数据交互效率低下、维护困难。做一次大集成的项目伤筋动骨，而且后期的接口升级和对外开放服务都会涉及到费用问题。

随着SOA到微服务的落地，接口得到了一定的规范和简化，通过Rest和WS实现各个业务系统/模块的调用。这样虽然保持了业务架构灵活性，但给客户端调用带来了一定的复杂性，原本一次请求即可处理完成的业务，现在可能需要多次请求才能完成，有的业务逻辑还需要处理事务，控制消息接收的顺序等。为了降低调用逻辑的复杂性并提高前后端交互效率，可以采用后端服务适配层或者服务编排的方式来完成。

1、 后端服务适配层

作为前后端的代理层，为前端调用提供一个业务接口聚合层，主要实现接口聚合和响应数据裁剪，屏蔽复杂的服务调用关系，让前端应用聚焦在所需要的数据上。这里的后端服务适配层是架构分层的概念，类似mgr->service->dao的模式，在service之前，服务网关之后。其核心职责是为前端（包括小程序/H5等）适配不同的业务场景，降低前后端的耦合，可以通过硬编码的方式来实现功能聚合，但硬编码的弊端在于编码效率低、编码细节难以规范、调试测试效率低和服务治理能力弱等。

2、 服务编排

通过可视化的扩拽，最终实现基于XML/JSON的接口调用说明，完成接口调用关系的编排，包括接口的串行、并行和排他调用等，通过简单的脚本完成不同业务需求的定制，以及对接口返回数据的裁剪、排序、格式化等操作。编排后可通过在线测试的功能，直接对编排的服务进行测试，快速验证功能（接口都是现成的），最大程度降低编码及编译打包的等待时间，最大程度提升业务整体的交付效率。

三、可视化建模

通过建模器生成的服务编排的XML/JSON描述文档，既是对业务流程的描述，也是引擎执行功能的定义，所以XML/JSON的设计需要涵盖整个业务诉求。考虑到业务的多样性，业务表达的包容性，以及将来的业务扩展能力。

 

通过图形建模器拖拽活动元素和连线，快速定义业务过程。采用一个有向循环图（非DAG）可以表达业务逻辑，可以参考部分Petri Net(PN)的语义。整个业务过程分为3大阶段：

1. 建模阶段：通过图形建模器对业务流程进行设计，业务的载体xml保存到文件系统或数据库中。有些场景下本阶段可拆分为2个子阶段，建模阶段和发布阶段。

2. 运行阶段：按照设定的业务逻辑和流程，在内部构建一个流程调度引擎进行自动推进，依次调用各个微服务，并最终完成处理逻辑。

3. 完成阶段：包括正常完成、异常、取消的流程，信息存在数据库中。

四、服务编排流程

当采用微服务架构后，系统已被拆分成了很多新的微服务，服务编排主要基于现有的业务微服务使用在线配置的方式快速的生成一个聚合接口，依赖通过各微服务之间的协作来实现一个完整的业务流程。

在实际的业务场景中，业务模块提供REST接口，通过流程编排这些接口实现一个新的流程模型，活动模型进行赋值、invoke（调用）等，执行流程可分为顺序、分支、循环、异常抛出、异常捕获、并行等，然后给参与编排的服务提供正确的参数。每个接口服务都会有自己的出参入参，适配的过程就是从上下文中给入参赋值以及将出参的结果写入到上下文中。编排服务在执行上下文的组成模型过程中，引擎本身在运行过程中也会产生一部分数据。

五、核心功能

1、接口调用

通过执行引擎把各个模块的API服务(Restful、WebService、Springbean等)通过接口获得流程上下文信息，并和接口服务的参数进行映射。通过编排能把业务系统、数据、业务逻辑进行解藕，业务逻辑的编排交由专门的微服务编排平台完成，而API服务只需要专注完成自已内部的逻辑即可。

2、路由处理

接口间调用的路由关系可以抽象为：串行调用、并行调用、排他调用。当依赖的接口间没有依赖关系时，可以采取并行执行的方式，减少服务的响应时间，从而提高系统整体的吞吐量。

当服务依赖的接口有依赖关系时，如接口A的入参需要通过调用接口B来获取，那接口A和接口B之间就必须通过串行的方式调用，即需要先调用接口B，拿到接口B的响应结果才能才调用接口A。

3、参数处理

接口的入参主要有静态和动态两种形式，针对静态的入参，只需要在界面上提供输入框配置即可。针对动态的参数，值可能来自于其他接口的返回结果，也可能来自动态生成的。参数可以是json或者xml。

对于json数据格式的拆分，合并，数据映射等操作，以及输入信息的参数化处理。这些参数对于整个组合服务运行实例中的全局参数，在后续任何节点可随时引用，编排的时候同时调用多个API接口并不难，难点在于如何完成出参入参的映射以及快速灵活的组装。

4、分布式事务

由于将多个微服务API接口服务编排在一起，会产生分布式事务问题。当前的编排技术实际本身又为了完全同步等待的方式和异步类似任务事件和状态机处理机制。

如果是简单的服务组合，拆分，可以用同步模式。但是如果是类似业务流程处理的多个服务串行编排，可以采用异步任务事件处理机制，底层需要消息中间件和中间态数据的存储机制来进行支撑。在微服务编排里面的分布式事务处理，最佳的方式仍然是基于幂等规则下的事务补偿。

5、调用链路监控

编排后的微服务在内部可能会调用多个微服务API接口，形成微服务API的接口调用链，微服务编排完成的也是一个流程，是自动化的业务流，中间调用多个API接口服务，能够详细看到当前执行到哪个环节，如果出现异常也能够快速地排查到具体的错误异常日志。