【方案-分析】流程编排技术选型_流程编排引擎 技术选型

一、前言

1、背景

内容分发是用户最能感触到的影响，经过多年的发展，覆盖了稿定各类场景的推荐、搜索，以及最近开始接入的花瓣业务线。

从技术层面而言，一次用户推荐的请求过程，可以分为以下几个主要步骤：参数设置、L1召回、L2 粗排、 L3 精排、L4 混排，以及其他打压策略、词权重等过程。如下图所示：即通过设置过滤条件，可以排除掉敏感内容、过气的热点数据等， 再通过召回得到的内容候选集，通过预估对候选集的TopN进行打分排序，最后经过一些机制策略，比如版权素材等商业行为的内容与普通内容进行混合的策略，减少对用户的过度商业化行为的打扰。

2、现状分析

在业务迭代的过程中，随着新业务场景的不断接入，以及原有业务场景功能的不断迭代，系统变得越来越复杂，业务迭代的需求响应逐渐变慢。在业务发展前期，开展业务逻辑抽象重构，如：排序、召回等，虽然对于效率提升有一定的改善，但是还会存在以下一些问题：

1. 业务逻辑复用低：业务逻辑里充斥着大量的隐藏逻辑，比如，L1召回有多个数据来源，而每个数据来源的召回数量基本都是写死的，如果此时其他推荐能力也需要L1召回这部分逻辑，但是需要召回其他池子的数据，那么此时将会很难进行复用。
2. 学习成本高：内容分发的流程较长，且逻辑分支多，导致整体逻辑复杂，如上面提到推荐流程，会涉及到多种召回、排序、混排、打压、Ab实验之外，还有大量业务自定义的逻辑，比如只针对TopN进行的隐藏策略，新同学熟悉代码成本较高，上手较难。（而且还有很多专业名词，可能连需求都看不懂。）
3. PM（产品经理）、开发信息获取难：由于目前业务场景较多、逻辑复杂，对于信息的获取，绝大多数同学很难了解业务的所有逻辑。不管是开发还是产品很难会记住所有逻辑，也无法很直观的方式了解现状，只能通过代码进行理解。
4. 自测困难：由于现状的业务流程长，逻辑分支特别多，想要完成一次自测，要准备太多。比如，开发环境没有离线表数据、数据错误等，可能要实现一次自测还得先把各类数据补齐，测试对于环境的依赖太大。

3、目标

针对以上的问题，我们计划给内容平台接入流程引擎能力，旨在通过流程引擎能力达成以下几个目标：

1. 提升产研效率
   1. 提高功能复用度，提升开发效率；
   2. 降低开发、产品同学之间的协作成本，提升协作的效率；
2. 提升交付质量
   1. 精准测试，提升交付质量；
3. 标准化建设
   1. 功能的标准化
   2. 数据的标准化
   3. 调用流程的标准化

二、技术选型

1、开源流程引擎介绍

市场上比较有名的开源流程引擎有OSWorkflow、Jbpm4、Activiti、Flowable、Camunda。其中：Jbpm4、Activiti、Flowable、Camunda四个框架同宗同源，祖先都是Jbpm4。

参考：

• 引擎类型：开源流程引擎哪个好，如何选型？ - 知乎
• 性能对比：flowable与camunda性能对比测试_camunda flowable对比-CSDN博客
• 功能对比：flowable camunda activiti 功能对比_activity2基本框架对比-CSDN博客

最终选择：Camunda，上手简单、开源、标准协议、性能较佳、可支持扩展。

2、Demo演示

略

三、设计思路

1、标准化建设

1.1 功能的标准化

待补充

• 按业务逻辑有无关系区分
• 按复用范围区分
• 命名上的区分

1.2 数据的标准化

待补充

• 上下文数据传递，组件增加固定约束，哪些值能够被下游修改，哪些下游可看到
• 当前组件需要的参数，该如何得知从上下游获取的方式？比如说，我要通过哪个Key获取？

1.3 调用流程的标准化

待补充

• 数据源调用流程标准化
• 如何保证上下游无重复的调用？

2、技术架构

2.1 项目部署方案

来源：Architecture Overview | docs.camunda.org

采用集群的方式，多个引擎节点共用同一个数据库，实现所有引擎节点都能拿到一致的模型数据。

 

 

2.2 流程引擎平台架构

核心包：主要是包含了Camunda嵌入式引擎，用来执行下发的编排模型；业务采集是用于将已实现的完整业务能力（如：L1召回能力）进行上报给轻舟平台，让轻舟可以拿来即用的组件，进行组装。

能力包：将各类业务能力封装后的组件，也可以理解成可单独执行的部分流程、多个组件、工具包的集合。

组件包：与业务有关系的，比如查询某个离线表。

工具包：与业务无关的通用能力，如ABTest。

参考：

1. 美团外卖广告平台化的探索与实践【强烈推荐】
2. Camunda Architecture