随着企业数字化转型进程的加快，零代码平台的应用越来越广泛，逐渐被企业级客户认可和接受。零代码，顾名思义就是不用写代码就可以构建应用和功能来满足客户需求，但现实是残酷的。真正的客户需求总是比我们想象的要复杂。传统的零代码产品需要提供各种扩展能力，比如让开发者能够编写复杂的业务逻辑代码，并接入平台。这样虽然可以满足需求，但是存在两个问题：客户的需求随时可能变化，需求一变化就需要修改代码；一线业务人员无法直接在平台中进行调整，一些小的改动需要开发、测试、发布流程。这时候就需要进行服务编排。什么是服务编排？下面举两个例子：1.仓储物流系统采用先进先出更新库存。需要遵循先入库后出库的原则，如下图所示：在没有服务编排的系统中，构建完功能后，需要编写API接口处理出站逻辑并将其与系统中的某个方法连接起来的方法。这项工作只能由开发人员完成。使用服务器编排工具，可以通过拖拽的方式轻松可视化，如下图所示：2.员工离职后需要处理一系列的操作，比如：修改相应用户在人力资源系统；删除企业微信账号；禁用邮箱；发送通知。使用服务编排可以轻松实现，前提是有丰富的业务组件：服务编排实际上是一系列单独的业务组件通过一个流程组合起来，最终达到业务的目的。该过程可以控制分支逻辑或循环逻辑。说到流程，我们的印象是OA、CRM等系统中的各种请假审批流程、合同审批流程等等。实际上，广义的工作流就是工作流及其各个操作步骤之间的业务规则的抽象、概括和描述。简单地说，为了实现某个业务目标，被抽象和拆解的一系列步骤以及这些步骤之间的协作关系就是工作流。也就是上面提到的业务服务的编排过程。服务编排引擎整体架构图如下：近几年流行的微服务中也存在服务编排。常见的模式有以下三种：Orchestration（编译）：通过一个可执行的流程来协调内部和外部服务的交互，通过流程来控制总体目标、涉及的操作以及服务调用的顺序。这种模式必须有一个流程控制服务来接收请求，组织服务之间的调用，最终完成业务逻辑。大多数这些解决方案都是同步调用。虽然在某个时刻可以清楚地知道服务的执行情况，但是当业务复杂、服务较多时，控制服务的耦合度会很大，难以维护；编排（Choreography）：通过消息的交互顺序来控制各种资源的交互。参与交互的资源都是平等的，没有集中控制。可以看做是消息驱动模式，或者订阅发布模式，不同的服务通过消息机制串联起来，大部分是异步的。优点是耦合度低，但也带来了一些问题，比如：业务流程通过订阅来体现，很难直接监控每个业务的处理情况，调试难度大；因为没有预定义的流程，很难事先保证流程的正确性，基本上是通过事后分析数据来判断；API网关：API网关是一种简单的接口聚合/拆分方式：业务组件的请求先到达网关，网关调用各个微服务，并将最终聚合/拆分的结果反馈。API网关其实就是一个适配网关。比如对于web端，一个页面可以同时发起几十个请求，而对于移动端，最好每个页面只有几个请求。有了API网关，后面的微服务就可以一样了。但是它只能处理一些逻辑上简单的场景。综合上述方法各自的优点，服务编排引擎的实现思路如下：1.一个服务的编排由一个或多个业务服务组件组成；2.一个业务服务组件可以拆解成一个或多个原子服务；3、每个原子服务都可以抽象成一个通用模型；4、每个原子服务提供API接口和事件监听机制；5.每个原子服务根据持久化适配器更新数据到订阅的持久化组件。整体流程如下图所示：服务组件的调用是同步还是异步，我们把这个决定权交给用户，可以通过设置来完成，并提供了重试机制来保证最终的一致性数据。每个服务组件都有自己的输入和输出参数。在服务编排的请求上下文中，参数将根据不同的执行阶段动态组织。参数适配器会根据名称、类型等自动适配，当然也可以根据设置界面手动绑定适配。原子服务只做一件事。通过一个原子服务或多个原子服务，可以组装不同功能的业务组件。通过事件监听机制，可以实现服务与组件的完全解耦，从而实现灵活的组装。随着服务和组件的增加，调用链会变得越来越复杂。一个业务在编排处理时，调用链会形成一个复杂的网络，给故障排查带来很大的麻烦。我们使用全链接跟踪来解决这个问题。当一个完整的业务调用开始时，会生成一个唯一的ID，这个ID会一直保存在调用上下文中。上面提到，原子服务会通过两种方式执行，API和事件监听。如果是API，可以在请求头中将ID传递给下一层。如果是事件监听，ID会作为消息体的一部分进行传递。假设用户现在编排了一个复杂的业务，服务组件之间的调用是同步的还是异步的，当某个环节出现问题时，我们需要保证数据的最终一致性。一种常见的方式是提供补偿机制。补偿模式的核心思想是：对于每一个操作，都要注册一个对应的补偿（撤销）操作。一般来说，操作本身和它的补偿操作会在一个事务中完成。当后面的操作失败时，需要按相反的操作，之前注册的所有撤销操作都是依次进行的。我们的补偿机制分为两种：1.对具体服务组件的独立设置；2.全局控制调用补偿，所有被调用的服务都会被记录在一个列表中，如果有操作需要重试或者回滚，则从列表中获取并执行相应的操作。在补偿模式下，需要提供补偿服务的操作必须支持幂等性，否则多次执行会出现数据错误。一般情况下会自动触发所有补偿，但有些特殊场景还是需要人工干预，管理员可以在调用失败日志列表中手动重试。
