作者：罗京

部门：增长中心

一、背景

当下，直播带货已经成为一种重要的消费场景。它重构了传统商场乃至电商的人货场关系，打造了一种即时的、沉浸式的消费体验。有赞做为一个商家 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 规则模型

每个条件由左值、操作符、右值组成，多个条件通过逻辑表达式组成�