背景

京東到家作為一個即時零售的電商平臺，在提供1小時送達極致服務的同時也力求將萬千好物送到消費者的手中。為了不斷提高平臺露出商品的價值，提高用戶的滿意度，我們設計并投入使用了京東到家商品治理系統(tǒng)，其主要職責是對商品新建、修改、呈現(xiàn)的全鏈路流程進行干預及核驗，旨在發(fā)現(xiàn)并解決商品信息中如：敏感詞、虛假宣傳、錯誤信息等不符合平臺規(guī)范和質量要求的問題，保證商品與實物的匹配度，信息的正確性等。

系統(tǒng)架構介紹

京東到家各業(yè)務線采用的是標準化的微服務架構設計，各個系統(tǒng)在迭代過程中只用按需申請對應的組件即可，下圖為治理系統(tǒng)所用到的技術組件：

• 消息中間件：使用京東的MQ中間件，實現(xiàn)業(yè)務解耦。

• 存儲：Redis集群、MySQL集群等。

• Worker：基于TBSchedule分布式調度引擎框架構建的服務，進行定時任務的執(zhí)行和分發(fā)。

• 服務監(jiān)控：采用統(tǒng)一監(jiān)控與告警服務平臺，可以達到秒級監(jiān)控、多方位監(jiān)控、服務告警、全鏈路追蹤等能力。

• 服務間調用：使用京東的JSF平臺，實現(xiàn)服務間注冊、服務間調用，服務治理等能力，支持請求超時自動阻斷。

• 日志服務：日志采集與查詢服務。

早期的治理系統(tǒng)

治理系統(tǒng)的第一個需求與大多數(shù)業(yè)務系統(tǒng)類似，是基于數(shù)據(jù)的增刪改查，構建一套敏感詞管理模塊，同時為商品主系統(tǒng)提供敏感詞的校驗能力。

它的第二個需求是為運營同學提供一個核驗結果的報表，其主要邏輯是通過上傳Excel，內部解析完成后調用接口得到相應的數(shù)據(jù)結果，基于MySQL進行存儲，然后提供查詢及展示的能力，以便運營使用。

但由于缺乏設計和長遠的思考，因此當時的治理系統(tǒng)與商品主系統(tǒng)耦合嚴重，圖示如下：

而隨著平臺對商品信息合規(guī)性的要求越來越嚴格，針對商品分類、毛重、圖片等等諸多的治理需求也就接踵而來。但在上圖的設計之中，我們不難發(fā)現(xiàn)，治理系統(tǒng)是以具體的業(yè)務來構建對外接口的，那隨著業(yè)務需求的不斷增加，兩個系統(tǒng)之間交互的接口個數(shù)也會出現(xiàn)暴漲，這是我們不希望看到的。

另外，治理的最終目的是期望商品上的問題能夠得到解決，而不僅僅只是發(fā)現(xiàn)，因此將問題暴露給運營或者商家，是勢在必行的，但當下存在兩個問題：

1. 商品系統(tǒng)在自身的主流程中強依賴治理的核驗能力，且隨著業(yè)務的增加，依賴會越來越多。

2. 商品系統(tǒng)只能將前置攔截的核驗結果告知商家，業(yè)務覆蓋面不全。

再加上有諸多問題是屬于弱合規(guī)性（不需要強制攔截但又需要解決），因此我們決定將商品治理業(yè)務的核心由商品系統(tǒng)轉為治理系統(tǒng)。

為了實現(xiàn)高效率的商品治理，我們對治理系統(tǒng)的設計要求和定位作出了一點變更，提出了兩項基本原則：

• 治理系統(tǒng)需要完成整個治理業(yè)務的閉環(huán)，作為商品問題發(fā)現(xiàn)及解決的總入口和總出口

• 治理系統(tǒng)需要具備高拓展性，當增加特定化治理需求時能夠迅速響應

業(yè)務架構升級

抽象思維顯神威

在理清治理系統(tǒng)的業(yè)務架構升級思路之后，我們首先需要確定的一個問題就是：治理系統(tǒng)最基礎的原子能力是什么？

以各個主系統(tǒng)為例，商品系統(tǒng)最基礎的原子能力即：商品的創(chuàng)建、修改和提供查詢能力、庫存系統(tǒng)最基礎的原子能力即：商品庫存信息的維護及查詢能力。根據(jù)治理業(yè)務的發(fā)展規(guī)劃，我們也基本確定出治理系統(tǒng)的原子能力，即：發(fā)現(xiàn)商品存在的合規(guī)問題，并向外提供查詢和輔助解決的能力。

對于合規(guī)問題的定義，我們做出了如下解釋，即：不符合電商平臺商品展示規(guī)范的如敏感詞、虛假渲傳等問題。

例如商品名稱中包含敏感詞，會映射為敏感詞問題，另外需要說明的是：在編碼階段中，一種可量化的具體規(guī)則可以確定對應的一種合規(guī)問題，且同一個商品可能同時存在多個不同的合規(guī)問題。

目前到家治理系統(tǒng)所涉獵的合規(guī)問題主要有：

為了方便理解，我們可以將每一種合規(guī)問題看作是一種策略，而針對策略的頂層接口又定義了四個核心方法：

• 映射關聯(lián)的枚舉：每一個問題都需要關聯(lián)具體的問題原因

• 問題關聯(lián)的字段：每一個問題都需要關聯(lián)具體的影響字段或被影響字段

• 自定義過濾能力：根據(jù)業(yè)務特點，減少無用處理

• 核驗方法：根據(jù)業(yè)務規(guī)則實現(xiàn)的具體核驗邏輯

具體的實現(xiàn)邏輯如下圖所示：

以商品毛重信息填寫錯誤為例，下圖為處理前后的展示結果：

毛重問題有其對應的關聯(lián)枚舉及文案映射，即：商品毛重不準確（問題類型），推薦毛重為 XXX（文案映射），所關聯(lián)的字段為：商品重量及商品名稱，再配合一定的過濾邏輯及核驗算法，那么毛重問題的抽象實體也就完成了，以此類推，我們后續(xù)在增加新的治理問題時，采用類似的方式即可。

如果是對設計模式涉獵較多的讀者應該已經判斷出來，這種設計方案其實就是策略模式及模板方法模式的變種罷了，在編碼階段也肯定少不了工廠的使用，在編碼層面整體的變化如下圖所示：

上述方案落地之后，產研側對于治理業(yè)務的后續(xù)發(fā)展達成了基本共識，同時需求的實現(xiàn)也變得簡單起來，我們不用再關注其他系統(tǒng)的邏輯，而是著眼于具體合規(guī)問題的業(yè)務規(guī)則實現(xiàn)上。

業(yè)務方和產品可以更好的通過數(shù)據(jù)分析來確定未來的治理重點和需求規(guī)劃，研發(fā)人員也以優(yōu)雅的方式解決了系統(tǒng)間耦合、業(yè)務代碼重復的問題。

難點問題巧手破

初步定義好治理系統(tǒng)的業(yè)務架構設計后，在后續(xù)迭代的過程中，我們遇到了兩個較為棘手的問題，一個是業(yè)務問題，一個是技術問題。

業(yè)務問題

業(yè)務方要求APP展示的商品主圖不能與默認圖（例如空白圖、品牌商標圖等不能體現(xiàn)商品信息的圖片）一致，然而商品圖片的核驗邏輯一直由圖片核驗系統(tǒng)承接。

這就引起了一個問題：治理系統(tǒng)是否需要集成圖片核驗邏輯，如果不集成，那又該如何將其圖片違規(guī)問題納入至治理體系中？

如果是經驗豐富的開發(fā)者一定會提出使用MQ的方式由圖片核驗系統(tǒng)發(fā)送核驗結果至治理系統(tǒng)，來解決這個問題。實際上我們也是這么做的，只不過做的更徹底一些。

在設計模式當中，我們通常會將一系列類似業(yè)務整合成一個公共接口向外提供能力，我們將它稱之為：門面模式或者外觀模式。

對于上述的類似問題，我們找到了公共的處理思路，即：將治理系統(tǒng)作為門面，其他系統(tǒng)作為組件，各系統(tǒng)都可以主動的向治理系統(tǒng)提供需要治理的內容。

該方案確定之后，各種令人頭痛的業(yè)務場景也就變得簡單起來，而且此舉還擴大了治理系統(tǒng)的邊界，例如商品無圖合規(guī)問題，商品差評率高的問題，只需要對應系統(tǒng)將相關數(shù)據(jù)/結果以MQ的形式發(fā)送至治理系統(tǒng)，然后由治理系統(tǒng)為其綁定具體的合規(guī)問題即可。

在編碼層面我們采用的是最簡單的MQ解耦的方式實現(xiàn)，示意圖如下：

技術問題

在治理迭代的過程中，有一系列的需求是針對平臺商品的圖片進行治理，以破損圖邏輯為例。

在最開始的處理邏輯中，大家查詢資料整合信息，發(fā)現(xiàn)平臺偶爾出現(xiàn)的破損圖是由于圖片在下載過程中未下載完整后流中斷，觸發(fā)上傳引起的。因此在第一版的邏輯中，我們查閱資料作出了如下邏輯判斷：當圖片下載完成觸發(fā)上傳前，對比請求體中的ContentLength與實際圖片字節(jié)大小，問題初步解決。

但是過了不久問題再次爆發(fā)，此時我們發(fā)現(xiàn)事情沒有那么簡單。

由于到家平臺對接眾多的商家系統(tǒng)，各個系統(tǒng)的圖片服務器與后臺邏輯不一，導致我們無法對所有圖片都使用文件大小比對的方式，因此我們重新調研并實現(xiàn)了針對破損圖的核驗能力。

即通過下載后的圖片內容進行處理和分析，利用算法與目標問題的業(yè)務特征來進行識別，至此，問題基本解決。

同時，基于該思路我們也衍生出針對黑底圖、默認圖的處理方式，在圖片問題的治理上更進一步。

治理觸達終落地

基于上述的方案和設計，治理系統(tǒng)在問題發(fā)現(xiàn)的流程上已經趨于完善，接下來，產品提出了新的要求，即：部分問題實現(xiàn)自動治理及問題觸達商家。

筆者在之前了解機器學習方面的知識時，注意到這樣一個特點，在機器學習中，模型可以分為兩種：判別模型和生成模型。忽略掉其具體含義，吸收其設計思想，我們也可以將治理系統(tǒng)分為兩個階段，即：發(fā)現(xiàn)和解決。

上述的業(yè)務抽象以及技術問題、業(yè)務問題都是在用以發(fā)現(xiàn)問題，當我們將解決問題的目標納入到整個治理體系時，只需要對現(xiàn)有結構進行一定程度的拓展即可滿足。

仍然以商品毛重信息填寫錯誤問題舉例，我們只需要在上文的抽象中增加兩個待實現(xiàn)方法：

• 是否需要自動處理：毛重問題需要自動處理

• 自動處理的具體實現(xiàn)規(guī)則：當實際毛重大于某一閾值時，將商品系統(tǒng)下架處理（依托于商品對外接口能力）

在核驗結果入庫前，根據(jù)具體的實現(xiàn)邏輯以及數(shù)據(jù)反饋結果來判斷需要人工處理還是系統(tǒng)處理即可。

而對于觸達需求，其實現(xiàn)就更簡單了，因為我們在最初就定義好了治理業(yè)務溝通的基本要素是一個個具體的治理問題，我們只需要將存儲好的數(shù)據(jù)以接口亦或是MQ的形式露出即可。

至此，整個治理體系從編碼層面也就建設完成，其核心邏輯在三個環(huán)節(jié)：

1. 商品變動MQ/其他系統(tǒng)治理內容通知觸發(fā)具體合規(guī)問題核驗。

2. 針對核驗結果進行判斷：人工處理或系統(tǒng)自動處理（處理的能力需借助于商品對外接口）。

3. 核驗結果對外露出。

下圖為治理系統(tǒng)當前整體業(yè)務結構圖：

治理業(yè)務全景圖

從治理平臺業(yè)務架構升級至今，已經穩(wěn)定運行9個多月，在業(yè)務發(fā)展過程當中，已經累計治理平臺商品480W+，構建出了8種識別能力，3種處理方式及兩種觸達方式。同時立足于商品、標品系統(tǒng)為商品的快速建品、基礎信息建設、治理審核等保駕護航，下圖為到家治理全景圖：

未來規(guī)劃

目前的治理體系是圍繞商品系統(tǒng)的主環(huán)節(jié)來設計和搭建的，其影響范圍較窄，我們完全可以將商品治理的成果運用于商品體系之外的其他系統(tǒng)。

例如下圖中的各個業(yè)務場景：

以搜索推薦為例，我們可以為各個合規(guī)問題制定相應的扣減分數(shù)，搜索側在構建數(shù)據(jù)時將當前商品的合規(guī)分數(shù)納入至自身體系中，在滿足搜索條件后按分值大小進行排序。

另外，也有很多用算法無法識別的問題需要納入至治理體系中，例如：商品差評率高、退貨率高等等。

總結

隨著業(yè)務的不斷發(fā)展，對于商品信息的質量要求也會越來越高，到家治理系統(tǒng)還需要和各個上下游系統(tǒng)一起聯(lián)動，提供更精細化的商品管控能力，期待未來我們的治理能力越來越出色，為用戶提供更加真實、貼合實際的商品數(shù)據(jù)以及更加優(yōu)質的服務。