腾讯广告商品中台流程编排引擎架构实现

本文详细介绍商品中台（ps：腾讯广告商品中台负责全行业商品管理与维护，商品用于广告投放等众多应用场景）如何通过自建流程编排引擎实现各业务场景服务的三高处理，进而提高整体研发效率并保证系统稳定性。

01、商品中台流程编排引擎的使用场景

1.1 场景一：商品库商品加工

商品库管理近40亿商品，日加工商品量级8000万+，为众多业务提供能力支持，加工流程通过流程编排引擎来管理实现，主要加工能力包括：类目识别、属性识别、品牌识别、商品打标、商品理解、商品审核、图片转存、视频转存、创意生成等等。

1.2 场景二：商品审核治理

商品审核治理为商品交易各场景做商品审核，包括：公共特征审核、底线画风审核、低质画风审核、侵权审核、违禁审核等等近百个审核单元组合（被编排节点），同时需要支持人审异步回调继续进行审核流程的复杂交互。

02、为什么使用流程编排引擎

在我们实现的各业务场景中，多服务协同调用最终组装成一个复杂的业务流程，是每个开发人员面临的主要场景。在这些场景的实现过程中，我们会浪费大量精力在服务对接、调用顺序和并行处理、超时重试、服务雪崩处理机制、分布式一致性等问题处理上。如果能通过某种手段，快速实现并解决如上问题，能大大提高我们的研发效率、降低系统的维护成本。我们只需要集中精力于各个高内聚、低耦合的服务节点开发上。为此，流程编排引擎应运而生。

03、构建一个流程编排的过程

在控制台构建一个流程编排的过程非常简单，仅仅需要简单的配置即可实现一个流程编排。

构建流程编排有两种方式，一是可视化拖拽编辑，二是使用工作流语言定义编排逻辑。

3.1 可视化拖拽编辑

在控制台上，可以通过可视化界面，拖拽各种节点（任务节点/流程控制节点）来组合成复杂的业务流程。当前流程编排引擎能够编排的任务节点类型包括云函数 SCF、kafka 生产者、http 接口。

以业务 A 为例，其流程编排包括图片转存和商品审核两个任务节点，且业务流程是先图片转存完成后再审核，拖拽节点，组成如下图所示的图即可。

3.2 代码创建

使用代码构建一个流程编排要用到工作流语言，工作流基于 DSL 语言，用来描述和定义工作流中的业务逻辑。 在执行时，ASW 工作流服务会根据工作流定义依次执行相关步骤。

举个简单例子来说明怎么使用工作流语言构建一个流程编排，以业务 A 这一个流程编排为例，编写如下代码，其表达的含义与上面可视化节点拖拽表达的含义一样。

{
  "Comment": "业务A",
  "StartAt": "Parallel",
  "States": {
    "Parallel": {
      "Type": "Parallel",
      "Next": "FinalState",
      "Branches": [
        {
          "StartAt": "ImageSave",
          "States": {
            "ImageSave": {
              "Type": "Task",
              "Comment": "图片转存",
              "Resource":"resource地址，支持http协议、kafka协议、Serverless协议",
              "Next": "NewAudit"
            },
            "NewAudit": {
              "Type": "Task",
              "Comment": "审核流程",
              "Resource": "resource地址，支持http协议、kafka协议、Serverless协议",
              "InputPath": "$.inputAswStr",
              "End": true
            }
          }
        }
      ]
    },
    "FinalState": {
      "Type": "Task",
      "Comment": "DAG结束节点",
      "Resource": "resource地址，支持http协议、kafka协议、Serverless协议",
      "End": true
    }
  }
}

04、流程编排引擎的架构实现

05、流程编排引擎的三高处理方案

5.1 高可用

流程编排引擎作为各业务场景依赖的核心组件，系统的可用性尤为重要。但由于各业务被编排的服务稳定性差异大，这也对流程编排引擎的异常处理提出了很高要求。为保证高可用性，商品库流程编排引擎做了如下处理：实现任务分配的负载均衡策略、异常熔断策略、服务隔离策略、接口重试机制、接口超时处理、接口限流策略。下面分别做介绍。

5.1.1 负载均衡策略

调度器服务负责将新执行任务分配到不同执行器去执行 DAG 任务，这里核心能力要实现任务的均衡分配，保证执行器的平稳运行。我们常见的负载均衡策略包括：

• 轮询（Round-Robin）：按依次循环的方式将请求调度到不同的服务器上，该算法最大的特点就是实现简单。轮询算法假设所有的服务器处理请求的能力都一样的，调度器会将所有的请求平均分配给每个真实服务器。
• 最小连接（Least-Connection）：该算法中调度器需要记录各个服务器已建立连接的数目，通过服务器当前活跃的连接数来估计服务器的情况。当一个请求被调度到某台服务器，其连接数加 1；当连接中断或者超时，其连接数减 1。该算法将请求分配给当前连接数最少的服务器，确保负载相对均衡，适用于长连接的场景。
• 哈希（Hash）：将请求中的某些特征数据（例如 IP、MAC 或者更上层应用的某些信息）作为特征值来计算需要落在的节点。哈希算法会保证同一个特征值每一次都会落在相同的服务器上。
• 随机均衡（Random）：此种负载均衡算法类似于轮询调度，不过在分配处理请求时是随机的过程。由概率论可以得知，随着客户端调用服务端的次数增多，其实际效果趋近于平均分配请求到服务端的每一台服务器，也就是达到轮询的效果。
• 加权轮询（Weighted Round Robin）：根据服务器的权重值，按比例分配请求，权重高的服务器接收到的请求数更多。

假设现在有三个执行器1、2、3，使用随机负载均衡随机将300个任务分配给三个执行器，很可能的情况是每个执行器执行100个任务，考虑一种极端情况，执行器1分配的任务恰好每个都需要很长时间，比如每次执行要几分钟，执行器2和3的每次执行都是只需要几秒，那么执行器1上就会一直有运行中的任务，接下来分配新任务，执行器1其实就不应该分配任务了，但是由于随机均衡策略，三个执行器分配任务的概率还是一样的，那么就有问题了。

从以上分析可以看出，由于不同任务的耗时可能差别比较大，使用单纯的随机均衡策略会有负载不均衡的问题。为了使得每个执行器的负载差不多，一个比较直观的想法就是调度器每次选择负载最小的执行器，负载最小其实可以理解为执行中的任务数量最小，那么调度器发起请求的时候，怎么知道哪一个执行器执行中的任务数量最小呢？

可以通过健康检查，调度器每1秒向所有执行器发起健康检查，检查的目的有两个：1、看看节点是不是挂了 2、查看节点的负载。通过这种方式，调度器维护了执行器列表以及每个执行器的负载，发起调用的时候查询这个路由表就可以。然而这有个问题，执行器负载不是实时的，而是通过一秒一次的健康检查更新的，按照简单的选负载最小的逻辑，假如很短时间内有100个任务，这时候会将所有的任务都打到同一个执行器上，又会造成不均衡了。

假设每个执行器的负载可以用百分数来表示，0%表示没有负载，100%表示满载，满载的机器不能再接受请求，那么直观的思想是负载低的机器（剩余承载能力越高的机器），分配任务的概率就大一点，假如机器负载是 a%，剩余承载能力可以用100% - a%来表示。假设有三台执行器1、2、3，负载分别是 a%、b%、c%，那么各个机器分配的概率分别是。

一个执行器的负载怎么用百分数来表示呢，可以指定一个满载能力值，比如说执行器执行中的任务数量为300即是满载，那么执行器的负载计算公式就是：执行中的任务数量/300。到此，我们自己实现的负载均衡算法就介绍完了。

5.1.2 接口调用重试策略

流程编排引擎当中编排的各服务节点是通过网络请求的方式来进行信息交换和编排，但网络存在不确定性，会造成请求抖动。对抖动场景接口调用重试的支持，可以有效解决由于短暂抖动造成的编排任务执行失败的场景。通过流程编排引擎统一编排的服务，可以做到单点重试，也避免了重试风暴服务雪崩问题。（重试风暴可自行查阅相关材料）

对于网络通信失败处理会分为以下几步：

1. 感知错误：通过不同的错误码来识别不同的错误，目前流程编排引擎支持的是 Http 接口编排，在 HTTP 中 status code 可以用来识别不同类型的错误。
2. 重试决策：这一步主要用来减少不必要的重试，比如 HTTP 的 4xx 的错误，通常 4xx 表示的是客户端的错误，这时候客户端不应该进行重试操作，或者在业务中自定义的一些错误也不应该被重试。根据这些规则的判断可以有效的减少不必要的重试次数，提升响应速度。
3. 重试策略：重试策略就包含了重试间隔时间，重试次数等。如果次数不够，可能并不能有效的覆盖这个短时间故障的时间段，如果重试次数过多，或者重试间隔太小，又可能造成大量的资源(CPU、内存、线程、网络)浪费。

如果重试之后还是不行，说明这个故障不是短时间的故障，而是长时间的故障。那么可以对服务进行熔断降级，后面的请求不再重试，这段时间做降级处理，减少没必要的请求，等服务端恢复了之后再进行请求。

针对如上的重试场景，编排引擎通过 Retry 模块，配置 ErrorEquals、IntervalSeconds、MaxAttempts、BackoffRate（每次尝试重试时间间隔倍数）来支持接口重试策略的支持。配置示例如下：

{
  "Comment": "业务A",
  "StartAt": "unit_a",
  "States":
  {
    "unit_a":
    {
      "Type": "Task",
      "Comment": "审核A单元",
      "Resource":"resource地址，支持http协议、kafka协议、Serverless协议",
"Retry": [
      {
        "ErrorEquals":["StatesTimeout"],
        "IntervalSeconds": 1,
        "MaxAttempts": 2,
        "BackoffRate": 2.0
      }
    ],
      "End": true
    }
  }
}

5.1.3 限流和熔断处理机制

微服务系统中，一个服务可能依赖另外一个服务，另外一个服务可能也依赖其他服务。这就是我们俗称的微服务调用深度，下面用下图展示：

• 当商品审核服务出现故障，创意服务只能被动地等待依赖服务报错或者请求超时，这会导致： a. 下游连接池会被逐渐耗光； b. 入口请求大量堆积，CPU、内存等资源被逐渐耗尽，最终导致服务宕掉。
• 上游依赖创意服务的视频转存服务，也会因为相同的原因出现故障，一系列的级联故障最终会导致整个系统不可用；

这里对微服务治理当中，每个服务模块都需要引入限流和熔断降级处理机制来避免集群雪崩，那么通过编排引擎实现服务编排同样的场景会变成下面这样。

因为所有服务都统一通过编排引擎来进行编排，我们可以把调用深度理解为1。同样当商品审核服务出现故障，编排引擎只能等待请求超时，如果同样大量请求在不断请求，同样会导致商品网关、编排引擎、商品审核的级联故障。

解决雪崩级联故障的核心思路就是：1、引入熔断器及限流器，请求不超载且服务异常尽早失败避免雪崩。2、通过消息队列抽象出反压层，当下游服务有抖动可以做缓冲和反压。这里采用的后者。

5.1.4 服务隔离策略

通过一张图基本罗列出来了常见的隔离策略，商品库流程编排引擎基于不同业务的执行特点，按照热点和用户场景维度进行了集群的独立部署，实现真正的物理隔离。

5.2 高性能

高性能方面，引擎做了充分的压测，核心对存储引擎 IO 耗时、大对象数据结构、并发处理、依赖组件包使用方式等方面做了不断优化和性能提升。优化细节不在本篇文章做详细阐述。

5.3 可扩展

可扩展性方面，引擎在腾讯云 TKE 上使用 docker 进行部署，且引擎本身无状态，所以基于 TKE 平台的调度策略实现了基于资源压力情况进行资源的动态扩缩容。

-End-

原创作者 | 裴博

你理解的中台是怎样的？欢迎评论留言。