之前写了一篇《千万级电商高性能交易架构》这篇文章，很多人看了之后，私信我能不能写一下它们的一些具体的细节。其实之前有一些细节已经在之前的文档中有所体现，比如：

今天接下来聊聊交易系统的另一个杀手锏——交易编排

如果你的交易系统还没有做交易编排，那说明你目前所做的业务相较然比较简单，交易的场景的较少、业务的复杂度较低，可以通过if-else 硬编码或者是通过一些设计模式也能很好的满足要求。

不管是if-else的硬编码还是设计模式其实都是一种简单的编排。如果的交易系统业务更复杂，需要支持很多种业务形态，少则几十种，多则成百上千种，这个时候很显然通过if-else还是通过设计模式均很难满足要求。

那交易编排是一种什么样的产品形态？

不知道大家有没有用过目前比较火的coze或者是dify的ai编排产品，其实就是一款很好的编排产品，同样也可以适用于交易的业务编排

从整个编排的架构来看，主要分为基础引擎、基础组件、业务插件、业务场景这几层

基础引擎：主要是底层的能力建设，对于规则脚本的编译和执行、根据编排协议进行组件执行，常见的开源规则引擎有drools、Aviator，当然也可以使用一些脚本语言作为规则引擎的基础，比如groovy、js等，但是前提是尽量使用性能高、可扩展性好的一些脚本语言引擎，因为这个对于性能还是有一定要求的，如果性能跟不上，后面很难去优化。

常见的开源编排引擎有大家特别熟悉的基于工作流编排的比如jbpm、Activiti，也有基于微服务编排的Conductor、zeebe，这个的话，如果公司有一定技术实力的话，建议还是自己去实现，因为基于这种开源，很多特性不是很适用，但是整个比较重，另一个的话就是编排这块往往和业务接触的比较紧密，可以在这一层做一些适用于公司自己定制化的一些东西，对于上一层来说更友好。

基础组件：这一层都是与业务无关，都是一些基础组件，比如用于业务判断的条件组件、用于业务循环的循环组件，一些变量设置、变量传递、对象序列化、数据存储等等，就是你平常在代码中能想到或者是用到的最频繁的，都可以变成基础组件，直接变成平台的基础组件，直接给到业务编排的时候去使用，这一层越丰富，业务编排起来就越灵活

业务插件：这一层，基本就是一些和业务紧密结合的原子指令，一般就是我们的一些RPC接口，或者是一些RPC接口进行组合形成的通用型插件，所有它可以用最小粒度的业务组件进行组合变成稍微大一点的业务组件，然后基于这个变成更大的业务组件，有点像葫芦套娃式的。

业务场景：就是基于这些业务组件在结合流程编排出来能独立完成整个业务动作的。就是业务场景，一般是由一些前台的人使用交易编排产品编排出来的。下图就是一个简单的创建订单的编排示例

当交易场景逐渐多的时候，交易编排能很好的把大家从IF-else的固有的编程式思维中解放出来，让大家更关注于业务插件的开发，随着业务插件的逐渐丰富，那么交易场景的建设就真的像搭积木一样的简单。

可能前提起步阶段的时候会比较难，但是只要达成一定阶段就能产生出非常大的作用，也是从交易服务到交易中台的必须的演化路径，像阿里云也开放出了类似的产品Bizworks，大同小异。