阿里工程师手把手教你设计 B 端垂类营销中心

作者| 阿里文娱B端技术专家 和同

责编 | 胡巍巍
出品 | CSDN（ID：CSDNnews）

云智是阿里影业旗下的影院数字化经营治理 开放平台，主要负责影院治理 及影票卖品的售卖。本文以云智营销中心为例，为您揭秘B端垂类营销中心的高复用性、强扩展性的技术架构内幕。

架构设计偏向

1. 营销中心设计

在业务架构设计上，将玩法通用特性进行抽象，实现营销业务和规矩 能力分别 ，静态治理 和动态运行分别 ，营销中心可划分为能力平台和业务平台两年夜 部分  ，如图1所示：

1） 业务平台：负责营销对象 生命周期的维护、资产治理 和其他各类 业务场景的实现；

2）能力平台：负责规矩 数据的标准  化和规矩 关系的配置，将能力进行领域划分。

图1 营销中心业务架构图

在系统架构设计上，业务平台依照 业务治理 视角组织数据，能力平台依照 规矩 运行视角进行领域计划 和办事 裸露 ，如图2所示：

1）业务平台将业务规矩 依照 能力平台界说 出的标准  化规矩 模型，将规矩 数据同步到数据库中，通过标准  化界说 ，实现规矩 祛业务化；

2）能力平台对外统一裸露 办事 ，并在优惠域进行统一参数组装，并依据 对应的业务身份执行不合  的脚本引擎，进而挪用 不合  的领域办事 ，同时能力平台针对规矩 数据依照 其作用范围  进行领域划分，例如：负责计算的价格域、负责过滤的规矩 域等，针对不合  对象 特有规矩 由其对应产品  扩展点实现。

图2 营销中心系统架构图

2. 营销中心解决了那些问题？

B端营销具有对象 多，玩法庞杂 的特点。垂直业务上可以分为如卡、券、积分等跨越 10种营销对象 ，每一种对象 包含  立减、打折等跨越 7类玩法，每一类玩法会在不合  的对象 中有差别 化。因此，在传统的设计思路下就会涌现 “烟囱式”的建设模式，如图3所示：

图3 传统系统建设模式

这种“面向业务”的“烟囱式”建设方法 会对业务和系统带来三年夜 弊病 ：

1) 重复功能  建设和维护带来的重复投资。单单从开发和运维两方面成本投入的角度，对于业务都是一种显性的成本和资源浪费。

2) 买通 “烟囱式”系统间交互的集成和协作成本昂扬 。随着营销业务的成长 ，各“烟囱”之间不得不开始买通 ，涉及到年夜 量的协同和开发成本。

3) 晦气 于业务沉淀和连续 成长 。受限于之前办事 设计时的通用性和业务前瞻性不足，业务领域的数据和业务被打散到不合  的系统中，这样无法满足业务快速响应和模式立异 的需求，同时无法从更高维度上去不雅 察和设计整个领域。

传统建设模式的主要问题是将业务和玩律例 则混杂在一起，使得玩律例 则和业务耦合极强，进而导致系统复用性低，可扩展性弱。营销中心充分  针对这些问题，在架构设计和结构分层上，实现了高复用性和强扩展性。

如何实现高复用性

营销中心在面对年夜 量带有业务特性的数据时，主要通过模型标准  化，通用领域办事 平台化，

平台能力自进化三种方法 实现高复用性：

1) 模型标准  化：通过标准  界说 规矩 描述、统一计算模型，实现底层能力和逻辑祛业务化，将所有规矩 及商品数据依照 标准  模型进行重塑，即将各业务规矩 依照 其实质 拆解为条件&动作的映射，不合  类型商品依照 标准  模型转换，如图4所示。

2) 通用领域办事 平台化：在领域办事 能力实现进程 中，将通用常见的能力抽象为平台能力，如果业务玩法没有特殊设置，则可以快速复用默认的平台能力。例如打折玩法，平台将四舍五入作为默认能力，新的业务接入时可以直接使用平台提供的打折能力，无需二次开发。

3) 平台能力自进化：当扩展点能力逐渐被更多业务使用时，可以将扩展点能力上升为平台通用能力，实现平台能力品级 动态调剂 ，满足业务对通用能力变更 的要求，进而加强营销中心的复用性。

图4 模型标准  化示意图

如何实现强扩展性

营销中心的能力平台需要满足各类 特性的业务玩法接入，所以在设计上我们通过产品  扩展包和流程编排的方法 实现强扩展性：

1. 产品  扩展包：当平台提供的默认能力无法满足业务需求时，则由相应的产品  扩展包来扩展实现。例如打折玩法，平台将四舍五入作为默认能力，然则 在折扣券业务中，要求打折后取整，平台将这类玩法的特殊处理  逻辑在折扣券扩展包中实现，当折扣券计算时，平台通过对象 标识，将请求路由到对应的扩展点执行相应的特殊逻辑，从而解决规矩 的定制化问题。图5为营销中心能力平台挪用 流程图。

图5 能力平台挪用 流程图

2. 流程编排，通过流程编排的方法 ，达到  允许业务依照 场景进行自界说 功能  选择的效果，实现用户自界说 需要。能力平台的流程编排引擎采取 QLExpress技术，如图6所示。

图6 流程调剂   域办事 示意图

总结

云智营销域从“烟囱式”架构演进成“平台化“架构，主要参考了TMF框架的分层、领域划分思想，使用QLExpress脚本引擎实现办事 编排和办事 调剂   。

在架构选型时，与TMF同类框架的还有NBF框架，相比之下，TMF更重视业务抽象，但TMF中有一些分层是B端营销业务不需要的，所以营销中心参考TMF的设计思想，形成了适用于B端营销的BEF框架，上文所述的解决计划 都是BEF的一部分  。在BEF落地进程 中，对优惠计算模型和规矩 模型进行了抽象，以满足对业务对象的需要。因此抽象成为了平台化的症结 所在，抽象水平 决定平台深度。

在流程引擎选择上，QLExpress同类技术还有Drools，但虑到QLExpress较Drools在性能方面有明显优势，可读性较强，开发门槛较低，营销中心最终采取 了QLExpress。