京东到家商品治理体系的建设

背景

系统架构介绍

• 消息中间件：使用京东的MQ中间件，实现业务解耦。
• 存储：Redis集群、MySQL集群等。
• Worker：基于TBSchedule分布式调度引擎框架构建的服务，进行定时任务的执行和分发。
• 服务监控：采用统一监控与告警服务平台，可以达到秒级监控、多方位监控、服务告警、全链路追踪等能力。
• 服务间调用：使用京东的JSF平台，实现服务间注册、服务间调用，服务治理等能力，支持请求超时自动阻断。
• 日志服务：日志采集与查询服务。

早期的治理系统

它的第二个需求是为运营同学提供一个核验结果的报表，其主要逻辑是通过上传Excel，内部解析完成后调用接口得到相应的数据结果，基于MySQL进行存储，然后提供查询及展示的能力，以便运营使用。

但由于缺乏设计和长远的思考，因此当时的治理系统与商品主系统耦合严重，图示如下：

而随着平台对商品信息合规性的要求越来越严格，针对商品分类、毛重、图片等等诸多的治理需求也就接踵而来。但在上图的设计之中，我们不难发现，治理系统是以具体的业务来构建对外接口的，那随着业务需求的不断增加，两个系统之间交互的接口个数也会出现暴涨，这是我们不希望看到的。

另外，治理的最终目的是期望商品上的问题能够得到解决，而不仅仅只是发现，因此将问题暴露给运营或者商家，是势在必行的，但当下存在两个问题：

1. 商品系统在自身的主流程中强依赖治理的核验能力，且随着业务的增加，依赖会越来越多。

2. 商品系统只能将前置拦截的核验结果告知商家，业务覆盖面不全。

再加上有诸多问题是属于弱合规性（不需要强制拦截但又需要解决），因此我们决定将商品治理业务的核心由商品系统转为治理系统。

为了实现高效率的商品治理，我们对治理系统的设计要求和定位作出了一点变更，提出了两项基本原则：

• 治理系统需要完成整个治理业务的闭环，作为商品问题发现及解决的总入口和总出口
• 治理系统需要具备高拓展性，当增加特定化治理需求时能够迅速响应

业务架构升级

抽象思维显神威

以各个主系统为例，商品系统最基础的原子能力即：商品的创建、修改和提供查询能力、库存系统最基础的原子能力即：商品库存信息的维护及查询能力。根据治理业务的发展规划，我们也基本确定出治理系统的原子能力，即：发现商品存在的合规问题，并向外提供查询和辅助解决的能力。

对于合规问题的定义，我们做出了如下解释，即：不符合电商平台商品展示规范的如敏感词、虚假渲传等问题。

例如商品名称中包含敏感词，会映射为敏感词问题，另外需要说明的是：在编码阶段中，一种可量化的具体规则可以确定对应的一种合规问题，且同一个商品可能同时存在多个不同的合规问题。

目前到家治理系统所涉猎的合规问题主要有：

为了方便理解，我们可以将每一种合规问题看作是一种策略，而针对策略的顶层接口又定义了四个核心方法：

• 映射关联的枚举：每一个问题都需要关联具体的问题原因
• 问题关联的字段：每一个问题都需要关联具体的影响字段或被影响字段
• 自定义过滤能力：根据业务特点，减少无用处理
• 核验方法：根据业务规则实现的具体核验逻辑

具体的实现逻辑如下图所示：

以商品毛重信息填写错误为例，下图为处理前后的展示结果：

毛重问题有其对应的关联枚举及文案映射，即：商品毛重不准确（问题类型），推荐毛重为 XXX（文案映射），所关联的字段为：商品重量及商品名称，再配合一定的过滤逻辑及核验算法，那么毛重问题的抽象实体也就完成了，以此类推，我们后续在增加新的治理问题时，采用类似的方式即可。

如果是对设计模式涉猎较多的读者应该已经判断出来，这种设计方案其实就是策略模式及模板方法模式的变种罢了，在编码阶段也肯定少不了工厂的使用，在编码层面整体的变化如下图所示：

上述方案落地之后，产研侧对于治理业务的后续发展达成了基本共识，同时需求的实现也变得简单起来，我们不用再关注其他系统的逻辑，而是着眼于具体合规问题的业务规则实现上。

业务方和产品可以更好的通过数据分析来确定未来的治理重点和需求规划，研发人员也以优雅的方式解决了系统间耦合、业务代码重复的问题。

难点问题巧手破

业务问题

这就引起了一个问题：治理系统是否需要集成图片核验逻辑，如果不集成，那又该如何将其图片违规问题纳入至治理体系中？

如果是经验丰富的开发者一定会提出使用MQ的方式由图片核验系统发送核验结果至治理系统，来解决这个问题。实际上我们也是这么做的，只不过做的更彻底一些。

在设计模式当中，我们通常会将一系列类似业务整合成一个公共接口向外提供能力，我们将它称之为：门面模式或者外观模式。

对于上述的类似问题，我们找到了公共的处理思路，即：将治理系统作为门面，其他系统作为组件，各系统都可以主动的向治理系统提供需要治理的内容。

该方案确定之后，各种令人头痛的业务场景也就变得简单起来，而且此举还扩大了治理系统的边界，例如商品无图合规问题，商品差评率高的问题，只需要对应系统将相关数据/结果以MQ的形式发送至治理系统，然后由治理系统为其绑定具体的合规问题即可。

在编码层面我们采用的是最简单的MQ解耦的方式实现，示意图如下：

技术问题

在最开始的处理逻辑中，大家查询资料整合信息，发现平台偶尔出现的破损图是由于图片在下载过程中未下载完整后流中断，触发上传引起的。因此在第一版的逻辑中，我们查阅资料作出了如下逻辑判断：当图片下载完成触发上传前，对比请求体中的ContentLength与实际图片字节大小，问题初步解决。

但是过了不久问题再次爆发，此时我们发现事情没有那么简单。

由于到家平台对接众多的商家系统，各个系统的图片服务器与后台逻辑不一，导致我们无法对所有图片都使用文件大小比对的方式，因此我们重新调研并实现了针对破损图的核验能力。

即通过下载后的图片内容进行处理和分析，利用算法与目标问题的业务特征来进行识别，至此，问题基本解决。

同时，基于该思路我们也衍生出针对黑底图、默认图的处理方式，在图片问题的治理上更进一步。

治理触达终落地

笔者在之前了解机器学习方面的知识时，注意到这样一个特点，在机器学习中，模型可以分为两种：判别模型和生成模型。忽略掉其具体含义，吸收其设计思想，我们也可以将治理系统分为两个阶段，即：发现和解决。

上述的业务抽象以及技术问题、业务问题都是在用以发现问题，当我们将解决问题的目标纳入到整个治理体系时，只需要对现有结构进行一定程度的拓展即可满足。

仍然以商品毛重信息填写错误问题举例，我们只需要在上文的抽象中增加两个待实现方法：

• 是否需要自动处理：毛重问题需要自动处理
• 自动处理的具体实现规则：当实际毛重大于某一阈值时，将商品系统下架处理（依托于商品对外接口能力）

在核验结果入库前，根据具体的实现逻辑以及数据反馈结果来判断需要人工处理还是系统处理即可。

而对于触达需求，其实现就更简单了，因为我们在最初就定义好了治理业务沟通的基本要素是一个个具体的治理问题，我们只需要将存储好的数据以接口亦或是MQ的形式露出即可。

至此，整个治理体系从编码层面也就建设完成，其核心逻辑在三个环节：

1. 商品变动MQ/其他系统治理内容通知触发具体合规问题核验。
2. 针对核验结果进行判断：人工处理或系统自动处理（处理的能力需借助于商品对外接口）。
3. 核验结果对外露出。

下图为治理系统当前整体业务结构图：

治理业务全景图

未来规划

例如下图中的各个业务场景：

以搜索推荐为例，我们可以为各个合规问题制定相应的扣减分数，搜索侧在构建数据时将当前商品的合规分数纳入至自身体系中，在满足搜索条件后按分值大小进行排序。

另外，也有很多用算法无法识别的问题需要纳入至治理体系中，例如：商品差评率高、退货率高等等。

总结