轻量级流程编排组件

本文首发自 微盟技术中心 微信公众平台~

一、项目简介

1.1 项目背景
由于商城的交易流程相对比较复杂，不同业务线针对同一场景的处理流程存在差异，通过硬编码的方式很难实现良好的扩展性和快速试错能力。因此，需要一套流程编排引擎来处理相应的编排需求。目前的编排框架大多不够轻量，比如 Apache Camel。Apache Camel 对编排对象（如方法、类、消息、服务）进行了高度抽象，只要按照规范接入即可。然而，庞大的生态系统包含了大量的组件和插件，导致依赖库和代码规模非常庞大，对内存和 CPU 资源的消耗较高。 而实际上，我们只需要类的编排即可。我们可以按需开发，不需要的功能无需开发，保持轻量级。开源解决方案可能无法很好地支持个性化需求，而自行开发则更容易进行定制修改。

1.2 项目目标

基于以上的需求背景，我们设计了轻量级业务流程编排组件，可以使业务实现更清晰、更灵活。该组件是基于 spring bean 实现的轻量级业务流程编排的；该组件可在复杂场景下，对业务逻辑的组件化抽象，流程化编排，进而实现业务需求，使业务场景清晰化；该组件可提高代码复用率和系统的可维护性、扩展性；      该组件主要由流程和节点两个部分组成：       1、流程：支持本地、远程两种方式定义；通过模板工厂设计模式，统一执行过程；支持串行、并行执行；支持多维度的流程匹配；具备流程变量、灰度等能力；      2、节点：暴露业务处理、执行拦截、前置、后置、回滚等扩展hook，如通过回滚hook，业务可以实现分布式事务一致性；支持节点自定义配置，如应用通过配置策略化的执行业务逻辑，提高系统的扩展性；       目前该组件已在商城交易、商城商家、批价中台等多个应用中使用，承载了70+的业务流程；支持了店铺初始化；线上交易、线下交易、积分商城等10+个商城交易场景；商城、值客推、CRM等产品的商品详情、购物车、结算各场景的优惠计算。节点执行流程图：轻量级流程编排具有以下特点：1、组件定义统一：为所有的逻辑提供统一化的组件实现，使其高内聚，低耦合。2、轻量：按需开发，依赖轻量。3、规则匹配灵活：使用关键词和规则引擎匹配相结合方式，达到更好的流程匹配效果。4、任意编排：支持灵活编排和中断，具备分支、并行、异步等能力，支持轻量级的分布式事务控操作。5、优雅热刷新机制：规则变化，无需重启您的应用，即时改变应用的规则。6、安全机制：接入流程审批功能、灰度同步功能，严格控制发布流程和数据一致性。

二、系统设计

2.1 系统架构图流程如下： 1、项目启动时， Client 扫描实现了Component接口的所有类。2、 Client 将扫描到的类上报到 Server 端。3、 Client 从 Server 中拉取当前服务的流程配置信息。4、 Client 将拉取到的配置信息写入到本地缓存中。5、 请求流量进入业务应用，业务应用通过 Client 查询到具体的流程。6、 Client 从本地缓存中匹配到具体的流程配置信息。7、 Client 根据配置信息执行流程。

2.2 服务端设计

服务端设计主要包含组件管理、流程的配置与发布、流程接口能力、流程的热更新。
1、组件管理：主要将业务配置的组件进行保存。2、流程的配置与发布管理：主要是对流程涉及到的组件进行编排，保存流程数据到数据库。3、流程接口能力：提供组件和流程数据查询功能。4、流程的热更新：通过周期执行器对流程变更配置表的监控，发现流程变更，通知客户端拉取最新的流程更新到本地缓存。

2.3 客户端设计

客户端设计通过流程配置总线管理所有节点，包含组件扫描、组件上报、流程拉取、流程执行。1、组件扫描器：主要在项目启动时扫描实现了 Component 接口的所有计算元组件，然后将类信息发送到流程配置总线中。2、上报控制器：接管组件扫描器扫描到的计算元组件，将所有类信息打包发送给 Server。3、拉取控制器：从 Server 中拉取配置在当前应用上的所有流程，并维护到本地缓存中。4、流程匹配器：通过自定义的规则和条件，匹配出当前要执行的具体流程。5、流程执行器：根据流程每个节点的执行方式（如并行串行回滚）执行节点。6、可在每个节点执行前后织入自定义执行切面。

2.4 多环境发布设计

我们的应用发布通常要经过测试、灰度和发布基准等过程，而流程资源的发布也需要类似的步骤，以确保变更的业务安全性。此处与开发者平台存在关联，环境标识对应的是开发者平台中多环境的标识，通过设置与灰度环境相同的环境标识，就可以在对应的灰度 POD 上来验证我们的规则。这里使用了基础架构提供的调用链上下文，来获取当前 POD 所在的环境标识。资源匹配的时候，优先获取到当前 POD 所在的环境标资源，来达到资源灰度的目的。在灰度完成验证的规则，即可继续完成资源发布上线。1、多环境灰度标：2、灰度流程状态设计：客户端拉取流程只能是灰度、发布状态流程。灰度流程的匹配：优先匹配灰度流程，通过策略条件判断是否存在当前灰度流程，存在返回灰度流程。未命中灰度，匹配已发布的流程。

2.5 模型设计

三、业务实践

应用场景：批价引擎、下单流程、商家初始化店铺等拥有复杂逻辑的业务已接入使用。效果：对业务的多元化、价格计算的多样化提供出色的服务能力，实现业务逻辑自动化处理。比如，批价引擎的通用计算顺序为：限时折扣->会员->满减->优惠券->积分->余额。然而，某些商户可能希望进行定制开发，主要关注券、积分和会员折扣。对于这种情况，流程如下：积分->会员->优惠券->限时折扣->满减->余额。针对这种变动，无需进行开发，只需要在可视化界面上重新配置流程，并增加流程匹配的规则和条件即可。1、流程列表：2、流程编辑：
3、业务流程组件实践模型：我们可以在流程编排的基础上进行业务扩展，对组件进行归纳明确划分，使其更灵活。

四、未来规划

从业务实际使用反馈来看，在后续版本中我们会在几方面迭代优化。1、可视化配置页面：丰富其他场景的可视化拖拽界面，使其更方便灵活。
2、丰富节点执行方式：包括但不限于通过HTTP、Dubbo、脚本以及本地类形式实现的执行节点。3、强化观测能力：支持多种方式的观测数据上报，以便应用可以根据现状选择合适的策略。4、启动开源计划：建立开源生态，共同维护，进一步丰富场景和能力。本文主要从业务场景、设计方案、实现细节、以及业务实践这几方面介绍了流程编排。其中有些地方还可以有进一步的提升，欢迎感兴趣的同学一起交流。