当前位置:   article > 正文

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

流程编排引擎 技术选型

一、前言

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。

参考:

最终选择: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

 

声明:本文内容由网友自发贡献,转载请注明出处:【wpsshop博客】
推荐阅读
相关标签
  

闽ICP备14008679号