一、背景
当下，直播带货已经成为一种重要的消费场景。它重构了传统商场乃至电商的人货场关系，打造了一种即时的、沉浸式的消费体验。有赞做为一个商家 SaaS 服务公司，为商家提供了商品管理，售卖的全流程服务，其中就对接了许多直播带货的渠道，例如快手、陌陌、微博、虎牙等等。有赞的商家可以在上述的渠道直播卖货。但是不同于 SaaS 服务，直播带货属于平台级的业务，平台有义务对平台商家的商品进行审核，剔除部分因为资质或者商品类目不满足平台要求等等原因而不允许售卖的商品。然而，不同的直播卖货渠道审核规则多样化。为满足这个规则多样化且多变的商品审核场景，通用规则平台应运而生。
二、流程
2.1 历史
历史流程通过查询接口获取校验字段，硬编码规则对商品类目、标题等一系列商品属性进行校验，对于不符合规则的商品返回相关的提示文案。因为是代码维护规则，所以规则的变更一般需要代码更改发布，涉及到代码修改就会牵扯出之后一系列的发布测试回归流程。存在以下痛点:
- 商品审核规则不够灵活，只支持校验阈值的快速变更
- 更改依赖代码修改发布，变更周期长
- 回归测试流程繁琐，不支持灰度
2.2 目标
全流程配置化避免了代码的变更，通过规则的灰度发布简化了流程，并且一定程度降低了发布可能导致的风险。
三、整体设计
整体分为2个大的模块：实时数据的聚合查询、规则执行系统。
- 数据作为规则校验的基础。复杂的规则有复杂的数据校验，是以大量数据做为基础。而这部分数据大多是通过调用三方接口获取并聚合而来的。
- 数据产出后，就会流转到规则引擎。基于查询聚合产出的数据，解析配置的规则，执行条件返回最终结果，并给出提示文案。
3.1 实时数据聚合
初始传入的数据可能只是很少的部分，例如商品的主键id。但是规则又要基于商品类型、商品类目等信息做规则校验。就需要实时查询商品信息接口，提取出必要数据信息。不同业务方的接口又有定制的接口参数和返回数据结构。所以接口参数和返回数据解析也要配置化。同时业务接口之间又有依赖关系，需要各自组成并行或者串行的调用流程。
3.1.1 数据源
数据源接入方式有 dubbo 接口、http 接口。其中，dubbo 使用泛化调用的方式实现，dubbo 数据源配置服务名、方法名和入参模板，调用业务方。再根据返回结果的解析，提取需要的返回数据。
3.1.2 整体流程
实时数据聚合接口和规则执行系统是相互独立的。串在一起才是完整的规则平台，但是又可以独立使用，实时数据聚合可以提供通用的查询能力，提供配置化的接口灵活取数，可以提供给后台界面做简单的聚合查询。规则系统也可以不依赖实时数据聚合系统，只要业务方直接传入所有校验参数，规则也能执行得出结果。
3.2 规则系统
3.2.1 规则模型
每个条件由左值、操作符、右值组成，多个条件通过逻辑表达式组成规则，文案可以在任意条件或者规则中配置。多个规则并行组成规则组。其中左值大多是数据聚合的某个字段，操作符是大于、小于、等于之类的判断条件，也可以是个自定义方法，注册到 QLExpress 。右值通常会是阈值，也可以填入数据聚合的字段。自定义的文案可以支持 QLExpress 的函数解析，主要用于拼接数据聚合中的字段。
3.2.2 执行引擎
基于现有业务场景以及开发成本，选择了轻量化的 QLExpress 做规则引擎，基于 QLExpress 封装一套结构化的规则定义，基于固化的规则模型，开发配置化的规则解析。QLExpress 是由阿里的电商业务规则、表达式、数学公式计算、语法分析、脚本二次定制等强需求而设计的一门动态脚本引擎解析工具。在本系统中用于操作符的支持和注册，以及文案的解析。基础表达式则是使用 QLExpress 的比较操作符号，有>、<、==、!=等等。也可自定义函数来实现更加高级的表达式，如正则匹配，字符串 in 操作，甚至是 dubbo 接口调用。除此之外，文案的解析也使用了脚本执行引擎，来支持动态的文案参数解析和逻辑解析。
3.2.3 规则灰度发布流程
配置化导致了变更的便捷。但是便捷的流程如果没有可靠的保障，频繁变更之下就很容易出错。但是一个好的流程规范虽不能完全避免错误，但可以在一定程度上减少错误。
所有的规则变更都需要经过灰度验证流程。在灰度配置中校验规则格式正确性，在灰度运行时校验规则逻辑正确性。
四、总结
配置化的规则替代了硬编码的校验逻辑，减少了修改规则发布代码维护的成本，使原本的规则变更周期从一周的修改测试发布变成了实时更改。同时规则的灰度发布也使验证变得简单。相较于其他规则系统，数据获取和规则执行各自功能完全独立，可以为其他场景复用单独的功能。但是也还存在许多待完善的地方，例如执行的结构化日志，日志的查询分析，数据源的实时监控等等。所以后续也会在这些可靠性优化上持续投入，完善整个系统。
感兴趣的商家，可点击 → 免费试用有赞店铺~
强力驱动