零代码平台中的服务编排思路

随着企业数字化转型的进程加快，零代码平台的的应用越来越广泛，逐渐被企业级的客户认可和接受。

零代码顾名思义就是在不写代码的情况下可以搭建应用和功能来满足客户的需求，但事实是残酷的，真实的客户需求永远比我们想象的要复杂，传统的零代码产品需要提供各种扩展能力，比如可以让开发人员编写复杂的业务逻辑代码，并对接到平台中。

这样虽然能够满足需求，但会有两个问题：

1、客户的需求随时可能发生变化，需求一变就需要进行代码的修改；

2、一线业务人员无法直接在平台中进行调整，一些小的改动都需要进行开发、测试、发布的流程。

这时就需要服务编排了，服务编排是什么，下面举两个例子：

1、仓储物流出库先进先出更新库存量

在仓储物流系统中，商品的入库有时间的先后顺序，出库时需要遵循先入库的先进行出库，如下图所示：

iShot2022-02-02 08.39.59

在不具备服务编排的系统中，搭建好功能后，还需要编写处理出库逻辑的 API 接口方法和系统中的某个方法对接起来。这个工作只能由开发人员来完成。

使用服务器编排工具，就能轻松地可视化拖拽就能实现了，如下图：

iShot2022-02-02 08.40.23

2、人员离职后需要处理一系列的操作，比如：

修改 HR 系统中对应用户的状态；
删除企业微信中的账号；
禁用邮箱；
发送通知。

使用服务编排可以很轻松就能实现，前提是要有丰富的业务组件：

iShot2022-02-02 08.40.49

服务编排其实就是一系列单个的业务组件通过流程的方式进行组合起来，最终达到业务的目的，流程中可以控制分支逻辑或循环逻辑。

提到流程，我们印象里都是 OA、CRM 等系统中的各种请假审批流、合同审批流等。事实上，广义上的工作流是对工作流程及其各操作步骤之间业务规则的抽象、概括、描述。

简单的说，为了实现某个业务目标，抽象拆解出来的一系列步骤及这些步骤之间的协作关系，就是工作流。也就是上面所说的业务服务的编排流程。

服务编排引擎的总体架构图如下：

iShot2022-02-02 08.41.14

在近些年比较火的微服务中也存在着服务的编排，常见的有三种模式：

Orchestration（编制）：通过一个可执行的流程来协同内部及外部的服务交互，通过流程来控制总体的目标、涉及的操作、服务调用顺序。这种模式必须有一个流程控制服务，用来接收请求，组织服务间的调用，并最终完成业务逻辑。这种方案中大多是同步调用，虽然在某个时刻能够很清晰的知道服务的执行情况，但当业务复杂，服务很多的情况下，在控制服务中会存在大量的耦合，难以维护；
Choreography（编排）：通过消息的交互序列来控制各个部分资源的交互，参与交互的资源都是对等的，没有集中的控制。可以看作一种消息驱动模式，或者说是订阅发布模式，不同的服务之间通过消息机制串联起来，这种方式大多都是异步的。好处就是耦合度低，但也会带来一些问题，比如：业务流程是通过订阅的方式来体现的，很难直接监控每笔业务的处理，因此难于调试；由于没有预定义流程，所以很难在事前保证流程正确性，基本靠事后分析数据来判断等；
API网关：API网关是一种简单的接口聚合/拆分的方式：业务组件的请求后先到达网关，网关调用各微服务，并最终聚合/拆分需反馈的结果。API网关其实就是一个适配网关，比如对于 Web端，可以一个页面同时发起几十个请求，而对于移动端，最好是一个页面就几个请求。而采用API 网关，后面的微服务可以是相同的。但只能应对一些逻辑简单的场景。

结合上面方式各自的优点，服务编排引擎的实现思路如下：

1、一个服务的编排由一个或多个业务服务组件组成；

2、一个业务服务组件可以拆解为一个或多个原子服务；

3、每个原子服务可以抽象成一个通用模型；

4、每个原子服务提供 API 接口和事件监听机制；

5、每个原子服务根据持久化适配器将数据更新到订阅的持久化组件中。

整体过程如下图：

iShot2022-02-02 08.41.46