谈谈我所理解的流程编排

名词

能力

指完成某一单一的业务行为，比如限购，限流等，流程编排中被编排的即“能力”，他可以由一个或者一组执行组件共同完成，执行组件可以是一个类或者一个spring bean，取决于执行引擎的支持，“能力”应该具有明确的语义，一定的通用性，一般而言，在项目迭代中，无法避免的会遇到一些“能力”被细化拆解，在我们定义能力的时候，需要尽可能去合理的细化“能力”的作用域。

业务身份

描述一条业务的唯一id，通过业务行为(比如下单，退款等)和从业务中抽离的特殊属性(比如商品属性，活动类型等)唯一确定一条业务的身份，业务身份可以是单个维度，也可是多个维度的聚合，只要能够唯一匹配一条业务规则即可。

业务规则

业务能力的聚合，一个业务身份对应一条业务规则，执行引擎按照业务规则调度各个能力，业务规则在执行引擎中会被解释成指令清单，执行引擎利用指令清单去动态或者预生产执行链。

流程编排

使用各种“能力”进行编排来完成某一业务，各个“能力”被有序的编织起来，聚合成一条特定的执行链。流程编排几乎适用于所有的业务型系统，特别是在业务身份非常多的系统中更受青睐。

流程编排的优势

流程配置化

通过配置化的方式形成业务规则，通过插拔某些组件形成新的规则，每条规则对应一个业务身份(比如，“虚拟商品下单”就是一个业务身份)，当我们需要新增业务身份，其实就是在对能力进行聚合编排，最终配置成我们需要的业务规则。

能力复用

在更多的业务身份产生的同时，更多的业务能力也被我们沉淀下来，能力会被编排进更多的业务规则中，在各个规则中复用。

业务细节聚合

在传统模式中，随着需求的不断迭代以及开发人员不同的编码习惯，越来越多的业务逻辑被分散在各个代码模块，给后续业务的理解和迭代造成很大的困难，而通过流程编排，不同的能力被分组聚合，各个能力职责单一，校验只做校验，装配只做装配。

统一开发思维

流程编排“约束”了编码方式，让开发者将注意力集中在业务线的设计和实现点的编码，按照“一切业务皆可编排”原则，所有的业务先按照相对固定的思维去设计“线”，再扣“点”，当开发者结合产品需求对“线”的设计完备以后，完全可以沉浸于“点”的实现，并且可以按照“点”的特性安排不同的开发人员进行编码。

有助于实现可视化的业务地图

根据规则，对应实现可视化的业务地图

通过执行引擎，实现技术细节和业务逻辑的分离

开发人员只需要定规则，具体的执行完全由执行引擎调度，强大的执行引擎通过其本身复杂的实现而让开发者获得更好的编码体验，如帮助完成跨组件事务，依赖注入，监控等。

缩短项目周期

流程编排提倡能力复用，通过编排大部分已经实现的能力和少量新编码的能力来完成业务流程，并不断沉淀新能力以面对更多需求迭代。这是一个不断进化和自我成长的过程。

有助于业务理解

在我之前的公司中，可视化的规则配置中心，对新人以及非开发同学了解业务有很大帮助，在业务身份非常多的系统中，贯通所有的需求场景对任何人来说都不是一件容易的事情，而配置中心正好体现了所有的场景以及其细节，它的职责不仅仅是“配置规则”和“管控规则”，更在于对规则的描述。

如何定义一条业务流程

规则设计优先基于对需求的理解，并且考虑规则的通用性和前瞻性，以满足未来可能的迭代。

列举能力

对需求有了整体的了解之后，流程需要的能力也变得清晰，我们以“限购”这个case为例，分析他需要调配的能力为： 【普通限购参数检查】【用户信息检查】【店铺信息检查】【商品信息装配】【限购逻辑执行】 以上，我们会复用【用户信息检查】【店铺信息检查】【商品信息装配】这三个已经在别的业务流程中沉淀下来的能力，那么本次需求即专注于【普通限购参数检查】和【限购逻辑执行】能力的实现，在设计规则聚合的时候，尽可能的使用已经实现的能力，这些能力相对稳定，低bug，同时也避免重复造轮子，加快研发进程。

能力分组

根据各个能力行为上的差异，我们将能力进行分组：

能力实现

大多数情况下会有一些能力未实现或者现有的能力不满足我们的项目需求，此时需要开发同学去实现这些新的能力，根据执行引擎的不同，编码会有不同的约束，有些需要继承特定的接口，有些需要在注解中申明执行方法，但是能力的实现一定会遵循一些原则：

原则	说明
职责单一	某一“能力”的实现，应该只是去完成一件事情
尽可能小的作用域	能力的作用域必须明确合理(相对而言，也要避免过度设计)，比如“用户信息校验”和“商品信息校验”应该分为两个能力，而不是一个“信息校验”能力
不依赖某一业务场景	能力是通用并且有应该被复用的，比如“限购”会出现在下单流程中，而同时他也可以单独提供限购查询服务

编写配置

按照执行引擎的不同，会有不同的规则配置方式，对于简单的，短期内不会改动的业务场景，可以使用xml进行简单的配置，如：

1. <?xml version="1.0" encoding="UTF-8"?>

2. <business-process-engine>

3.  

4. <business-process id="offline-quota-subtract" desc="线下限购扣减">

5. <business-node name="param-validator" desc="参数校验">

6. <execute group="quota-base-param-validator" desc="用户参数检查"/>

7. <execute group="quota-base-param-validator" desc="商品参数检查"/>

8. </business-node>

9. <business-node name="biz-assembler" desc="业务装配">

10. <execute group="quota-biz-assembler" desc="店铺信息装配"/>

11. <execute group="quota-biz-assembler" desc="限购商品信息装配"/>

12. </business-node>

13. <business-node name="biz-transaction" desc="事务执行">

14. <execute group="subtract-quota-transaction" desc="限购服务执行"/>

15. </business-node>

16. </business-process>

17.  

18. </business-process-engine>

而对于业务身份非常多，业务流程冗长而复杂的场景，建议提供可视化的web配置平台进行配置，配置平台在支持可视化配置的同时，还可以增加很多附属功能服务于规则配置。对于使用了流程编排的大型系统，配置平台尤为重要。