MQ 正在變成臭水溝

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

下面是正文，

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

然而企業對于 MQ 中的資料管理卻并不重視，從互聯網企業發展的歷程來看這個問題，最初 MQ 不是很可靠，大家不會把讓特別重要的業務依賴 MQ，所以接入到 MQ 的業務事件并不多，總共也就兩三個 topic，開發相應的系統對這些內容進行管理看起來沒什么必要，甚至可能連詳盡的業務資訊都要從生產者的代碼注釋中去尋找，公司規模不大，這些都是可以接受的，

經歷過 1Mb 小水管的朋友大概還記得當扯訓爆的 Flashget 的 Slogan：

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

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

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

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

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

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

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

3. MQ 開發/運維團隊，對于這些人來說，MQ 中的資料并不是他們關注的重點，不管你訊息長什么樣，對于他們來說只不過是一些 byte 資料，他們只關注 MQ 本身的技術特性和運維需求，

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

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

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

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

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

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

無論企業實際使用了上述兩種模式的哪一種，訊息總還是上游發出的，要求上游系統成為其發出的業務訊息的 owner 是一件比較自然的事情，

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

這種作業方式把業務資訊的維護和上游訊息的資料穩定性全部押注在了上游 RD 的良心上，顯然是不靠譜的，更好的方式還是用技術手段解決這里的技術問題，可以有以下一些考量：

1. 由特定團隊提供專門的訊息生產 SDK，對所有業務訊息進行 schema 管理，訊息生產環節的代碼要求必須提供帶特定格式的注釋，如：@name 表示欄位名，@type 表示資料型別，@enum 提供可能的列舉值，從結構體可以推斷出最終序列化后的資料長什么樣，并且在代碼修改上線時，對代碼進行掃描，提取所有相關的業務訊息欄位注釋，自動生成相應檔案，

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

如果實作的是方案 2，理論上還可以開更大的腦洞，除了對 schema 管理外，還可以做一些復雜的邏輯校驗，包括對資料的內容，邏輯，連續性，分布進行校驗，并由所有下游業務方來配置其期望的校驗規則，

后記

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

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

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

如果各位讀者的公司有類似的場景和專案，歡迎在留言區留下你的想法~

[1]

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

歡迎關注 TechPaper 和碼農桃花源：