微服務的戰爭：統一且標準化

“微服務的戰爭” 是一個關於微服務設計思考的系列題材 ? ，主要是針對在微服務化後所出現的一些矛盾/衝突點，不涉及具體某一個知識點深入。如果你有任何問題或建議，可以微信搜一搜【腦子進煎魚了】或我的 部落格 進行溝通和交流。

開天闢地

在遠古開天闢地時，大單體轉換成微服務化後，服務的數量越來越多。每起一個新的服務，就得把專案的目錄結構，基礎程式碼重新整理一遍，並且很有可能都是從最初的 template 上 ctrl+c，ctrl+v 複製出來的產物，如下：

但是基於 template 的模式，很快就會遇到各種各樣的新問題：

隨著跨事業部/業務組的使用增多，你根本不知道框架的 template 是什麼時間節點被複制貼上出去的，也不知道所對應的 commit-id 是什麼，更不知道先前的 BUG 修復了沒，也不知道有沒有其他開發人員私下改過被複制走的 template。

簡單來講，就是不具備可維護性，相對獨立，BUG 可能一樣，但卻沒有版本可規管。這時候，就可以選擇做一個內部基礎框架和對應的內部工具（已經有使用者市場了），形成一個腳手架閉環：

通過基礎工具 + 基礎介面的方式，就可以解決專案 A、B、C...的基礎框架版本管理和公共維護的問題，且在遇到框架 BUG 時，只需要直接 upgrade 就好了。而在框架維護者層面，還能通過序號產生器制知道目前基礎框架的使用情況（例如：版本分佈），便於後續的迭代和規劃。

同時若內部微服務依賴複雜，可以將腳手架直接 “升級”，再做多一層基礎平臺，通過 CI/CD 平臺等關聯建立應用，選擇應用型別等基本資訊，然後關聯建立對應的應用模板、構建工具、閘道器、資料庫、介面平臺、初始化自動化用例等：

至此，就可以通過結合基礎平臺（例如：CI/CD）實現流程上的標準化控制，成為一個提效好幫手。

大眾創新

但，一切都有 “開天闢地” 那麼順利嗎。實際上並不，在很多的公司中，大多數是在不同的時間階段在不同的團隊同時進行了多個開天闢地。

更具現化來講，就是在一家公司內，不同的團隊裡做出了多種基礎工具和基礎框架。更要命的是，他們幾家的規範可能還不大一樣。例如：框架在 gRPC 錯誤碼的規範處理上的差異：

• 業務錯誤碼放在 grpc.status.details 中。

• 業務錯誤碼放在 grpc-status 中。

• 業務錯誤碼放在 grpc-message 中。

又或是 HTTP 狀態碼的差異：

• HTTP Status Code 為金標準，不在主體定義業務錯誤碼。

• HTTP Status Code 都為 200 OK（除當機導致的 500，503 等），業務錯誤碼由主體另外定義。

粗略一看，單單在應用錯誤碼/狀態碼這一件事情上，就能夠玩出花樣。而這件事又會導致各種問題，例如在監控平臺上，因為不同團隊所定義的狀態碼規範不一樣，就會導致連基本的監控可用性都會有問題。

像是有的小夥伴會把業務錯誤碼放在 grpc-status 屬性中，而在標準 gRPC 的規範中 grpc-status 是和 HTTP Status Code 一樣有特定狀態碼對映的。這時候就會讓監控告警系統十分難做，通用的告警規則到底是以哪份狀態碼為準？

往往最終演進的路線與企業的組織結構有關，也就是康威定律，一個系統的技術邊界反映組織的結構。業界常見的是兩種情況：

1. A 吞併 B，B 與 A 一致，從例子上來講就是基本公用一套（維度為公司/事業部/業務組級別，與企業情況有關）。

2. A，B 均獨立發展，從例子上來講就是均獨立搭建，各管各，偶爾互相觸碰邊界，又或是在公開分享暗中切磋。

顯然，這其中利與弊就要各自判斷了，多少廠內部有多少個框架，也有血汗廠基本一統江湖的，可能做基礎架構適配的小夥伴會比較有感觸，不同框架的 Header 規範不一樣，這樣子即使是 Mesh 也避免不了一頓 if else。

更甚的是，在類似服務發現/註冊、限流熔斷、基礎攔截器，各類 SDK 同個廠的每個內部框架都重現實現一遍。美其名曰框架支援了這些，就允許讓他上，但這樣子怕是在未來又造成了新的一波技術債務。

同時框架維護者，是有可能離職跳槽到別家去的，這在前端屆也層出不窮，帶著修煉好的真經走了，留下一個沒有人維護的組內框架，這時候只能硬著頭皮找 B/C 角來接受，頂上來的人指不定思想還不一樣。

這單從公司層面來講，是一個巨大的傷害，長遠來看著實是災難。

總結

在本文中，主體分為了 “開天闢地” 和 “大眾創新” 兩塊內容，理想是豐滿的，而現實怕是很骨感。微服務是一把雙刃劍，帶來好處的同時往往也帶來了反面，架構的複雜度很難預知，因此本質上需要一個基架團隊不忘初心，持續發現，持續解決問題。

但不論如何，及早的把主力語言、基本技術棧均基本統一起來，做好產品閉環，會是一個很好的方向。

如果具體到要做的事情，需要有一個明事理的上級，清晰的意識到同個子公司內的技術體系最好是基本一致的，由基礎架構組或相關領頭人拉齊核心 Leader，定義基本規範，構建統一框架，融合 CI/CD 平臺。

當然，反之倒推也是可以的（野蠻生長），就是步驟更多了，更難了。

我的公眾號