這是一篇老文章了，之前換工作的時候，我還特意留意了一下新公司的隊列方案，看到他們內(nèi)部 2019 年剛剛支持了 schema registry 所以在線上可能也并沒有廣泛的應用。只是這家新公司業(yè)務都是 java，大概沒有像使用 PHP 的公司那么痛吧。

下面是正文。

MQ 對于業(yè)務系統(tǒng)建模非常重要，是解決分離關注點、依賴反轉、CQRS、最終一致等業(yè)務問題的重要法寶。

然而企業(yè)對于 MQ 中的數(shù)據(jù)管理卻并不重視。從互聯(lián)網(wǎng)企業(yè)發(fā)展的歷程來看這個問題，最初 MQ 不是很可靠，大家不會把讓特別重要的業(yè)務依賴 MQ，所以接入到 MQ 的業(yè)務事件并不多。總共也就兩三個 topic，開發(fā)相應的系統(tǒng)對這些內(nèi)容進行管理看起來沒什么必要，甚至可能連詳盡的業(yè)務信息都要從生產(chǎn)者的代碼注釋中去尋找。公司規(guī)模不大，這些都是可以接受的。

經(jīng)歷過 1Mb 小水管的朋友大概還記得當初火爆的 Flashget 的 Slogan：

下載的最大問題是什么——速度，其次是什么——下載后的管理。

雖然 Flashget 命運多舛，但不妨礙我們學習這種思考方式。當下載任務較多的時候，我們會非常直覺地對下載任務進行多級類別劃分(這個目錄是游戲；這個目錄是用來學習的，那個目錄，嗯。。也是用來學習的！)，甚至需要給一些任務補充相應的標注(例如這個軟件是從哪里下載的；在安裝的時候會有什么問題；繞過了什么樣的坑才能正確地讓它工作)。因為已經(jīng)使用過太多的工具，受過太多相應的教育和訓練，“分類”和“元信息”管理已經(jīng)深深刻入了我們的思想。

除了分類和元信息管理，對于在下載工具里下載好的任務，我們肯定要試試能不能用，好不好看。如果是垃圾，那自然得刪；如果是寶貝，那肯定是要留下來。這可以理解為一種人肉“校驗”。

雖然分類、管理和校驗是非常顯見的道理，在面對同類問題時，很多企業(yè)卻在此陷入困境。

通常來講，企業(yè)中和 MQ 打交道的團隊可以分為三種角色：

消息生產(chǎn)者，大多為業(yè)務流程系統(tǒng)，KPI 是給系統(tǒng)增加功能，加的越多越好，并希望其它部門盡量不要阻礙我們加功能。MQ 里的消息 80% 其實和他們自己的業(yè)務無關，主要提供給下游進行統(tǒng)計、計算、判責、場景還原等等。剩余 20% 可能涉及到業(yè)務狀態(tài)流轉。

消息消費者，一般是另外的團隊，這里面可能有進行業(yè)務指標計算的團隊；有基于數(shù)據(jù)指標做運營的團隊；有基于統(tǒng)計接入機器學習(其實也是運營啦)的團隊；還有涉及安全、antispam 等等周邊支持團隊。這些團隊對于 MQ 中的數(shù)據(jù)是非常關注的。

MQ 開發(fā)/運維團隊，對于這些人來說，MQ 中的數(shù)據(jù)并不是他們關注的重點。不管你消息長什么樣，對于他們來說只不過是一些 byte 數(shù)據(jù)。他們只關注 MQ 本身的技術特性和運維需求。

三方各懷鬼胎，真正關心 MQ 數(shù)據(jù)的只有整個消息流的末端團隊，因為這里面的數(shù)據(jù)是真的關系到他們自己的 KPI，要是數(shù)算錯了錢多發(fā)了，薅羊毛的沒封了，那都是直接資損。

然而 MQ 兩端的業(yè)務團隊在大多數(shù)情況下卻是 DDD 中講的 conformist 關系：

追隨者-Conformist 當兩個開發(fā)團隊具有上/下游關系時，如果上游團隊沒有動機來滿足下游團隊的需求，那么下游團隊將無能為力。出于利他主義的考慮，上游開發(fā)人員可能會做出承諾，但他們可能不會履行承諾。下游團隊出于良好的意愿會相信這些承諾，從而根據(jù)一些永遠不會實現(xiàn)的特性來制定計劃。下游項目只能被擱置．直到團隊最終學會利用現(xiàn)有條件自力更生為止。下游團隊不會得到根據(jù)他們的需求而量身定做的接口。這時候“客戶/供應商”模式就不湊效了，那么下游系統(tǒng)只能去追隨上游系統(tǒng)，下游系統(tǒng)嚴格遵從上游系統(tǒng)的模型，簡化集成。

這些問題本質上是公司的組織架構導致的，但你非要說把安全之類的團隊也合并到業(yè)務部門來比較扯。很多情況下上下游就是會分屬不同部門，這會觸發(fā)各種意想不到的糟糕問題。所以 DDD 中比這個 Conformist 更靠前的是 Customer/Supplier 模式：

客戶/供應商-Customer/Supplier 不同系統(tǒng)之間存在依賴關系時，下游系統(tǒng)依賴上游系統(tǒng)，下游系統(tǒng)是客戶，上游系統(tǒng)是供應商，雙方協(xié)定好需求，由上游系統(tǒng)完成模型的構建和開發(fā)，并交付給下游系統(tǒng)使用，之后進行聯(lián)調、測試。這種模式建立在團隊之間友好合作和支持的情況下。當兩個具有上游/下游關系的團隊不歸同一個管理者指揮時，Customer/Supplier這樣的合作模式就不會奏效。勉強應用這種模式會給下游團隊帶來麻煩。

而所謂的 Customer/Supplier 模式又是一種純粹的理想，是不現(xiàn)實的。部門都拆了，老板總歸是不能尿到一個壺里的。雖然現(xiàn)狀有點令人絕望，作為技術人員還是希望能有一點曙光。來分析一下這個問題：

無論企業(yè)實際使用了上述兩種模式的哪一種，消息總還是上游發(fā)出的。要求上游系統(tǒng)成為其發(fā)出的業(yè)務消息的 owner 是一件比較自然的事情。

只有 owner 機制也不夠，企業(yè)里所謂的業(yè)務 owner 所能提供給你的幫助，也就只限于對接的時候負責在工作 IM 上陪你聊天，告訴你這個 topic 里有哪些字段，你需要的字段要用什么樣的 jpath 去找。再稍微自覺一點的團隊會維護一個文檔，介紹領域消息內(nèi)包含什么內(nèi)容，做過哪些需求。當文檔不是 KPI 的時候，慢慢地也就不再更新了。

這種工作方式把業(yè)務信息的維護和上游消息的數(shù)據(jù)穩(wěn)定性全部押注在了上游 RD 的良心上，顯然是不靠譜的。更好的方式還是用技術手段解決這里的技術問題，可以有以下一些考量：

由特定團隊提供專門的消息生產(chǎn) SDK，對所有業(yè)務消息進行 schema 管理。消息生產(chǎn)環(huán)節(jié)的代碼要求必須提供帶特定格式的注釋，如：@name 表示字段名，@type 表示數(shù)據(jù)類型，@enum 提供可能的枚舉值。從結構體可以推斷出最終序列化后的數(shù)據(jù)長什么樣。并且在代碼修改上線時，對代碼進行掃描，提取所有相關的業(yè)務消息字段注釋，自動生成相應文檔。

如果團隊技術實力實在不行，做不出自動生成文檔的能力。也可以提供一個 schema 管理和異步數(shù)據(jù)校驗的 validation 系統(tǒng)，在系統(tǒng)外部對數(shù)據(jù) schema 進行管理，并不斷消費上游的消息，以判斷新來到的消息是否符合其 schema 定義。若有不符合期望的數(shù)據(jù)，則對上游值班人進行 on-call 報警，要求修復 schema 描述。

如果實現(xiàn)的是方案 2，理論上還可以開更大的腦洞。除了對 schema 管理外，還可以做一些復雜的邏輯校驗，包括對數(shù)據(jù)的內(nèi)容，邏輯，連續(xù)性，分布進行校驗。并由所有下游業(yè)務方來配置其期望的校驗規(guī)則。

后記

雖然本文現(xiàn)在才發(fā)，但幾年前已經(jīng)有了相關的想法。期間因為種種原因，這樣的平臺一直沒有辦法立項。中間某司斷斷續(xù)續(xù)也遇到了無數(shù)和上游系統(tǒng)重構導致的下游系統(tǒng)故障的問題，還是沒有看到任何改進的跡象。

直到最近看到 Google 的工程論文：data-validation-for-machine-learning[1]。其出發(fā)點是為了避免上游的錯誤數(shù)據(jù)影響到下游的模型訓練結果。但本身 schema 管理，數(shù)據(jù) validation 系統(tǒng)是可以泛用的，既然有很多系統(tǒng)依賴上游系統(tǒng)的 schema 和數(shù)據(jù)正確性，那就應該對這些 schema 和正確性進行管理。

遺憾的是 Google 可以有這樣的項目，而我們卻依然只能靠人肉去為這些無聊的故障做兜底。

如果各位讀者的公司有類似的場景和項目，歡迎在留言區(qū)留下你的想法~

[1]

data-validation-for-machine-learning:?https://blog.acolyer.org/2019/06/05/data-validation-for-machine-learning/

歡迎關注 TechPaper 和碼農(nóng)桃花源：

總結

以上是生活随笔為你收集整理的MQ 正在变成臭水沟的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。