微服務的戰爭：統一且標準化
本文轉載自微信公眾號「腦子進煎魚了」，作者陳煎魚。轉載本文請聯系腦子進煎魚了公眾號。
“微服務的戰爭” 是一個關于微服務設計思考的系列題材，主要是針對在微服務化后所出現的一些矛盾/沖突點，不涉及具體某一個知識點深入。如果你有任何問題或建議，歡迎隨時交流。
開天辟地
在遠古開天辟地時，大單體轉換成微服務化后，服務的數量越來越多。每起一個新的服務，就得把項目的目錄結構，基礎代碼重新整理一遍，并且很有可能都是從最初的 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 一樣有特定狀態碼映射的。這時候就會讓監控告警系統十分難做，通用的告警規則到底是以哪份狀態碼為準?
往往最終演進的路線與企業的組織結構有關，也就是康威定律，一個系統的技術邊界反映組織的結構。業界常見的是兩種情況：
A 吞并 B，B 與 A 一致，從例子上來講就是基本公用一套(維度為公司/事業部/業務組級別，與企業情況有關)。
A，B 均獨立發展，從例子上來講就是均獨立搭建，各管各，偶爾互相觸碰邊界，又或是在公開分享暗中切磋。
顯然，這其中利與弊就要各自判斷了，多少廠內部有多少個框架，也有血汗廠基本一統江湖的，可能做基礎架構適配的小伙伴會比較有感觸，不同框架的 Header 規范不一樣，這樣子即使是 Mesh 也避免不了一頓 if else。
更甚的是，在類似服務發現/注冊、限流熔斷、基礎攔截器，各類 SDK 同個廠的每個內部框架都重現實現一遍。美其名曰框架支持了這些，就允許讓他上，但這樣子怕是在未來又造成了新的一波技術債務。
同時框架維護者，是有可能離職跳槽到別家去的，這在前端屆也層出不窮，帶著修煉好的真經走了，留下一個沒有人維護的組內框架，這時候只能硬著頭皮找 B/C 角來接受，頂上來的人指不定思想還不一樣。
這單從公司層面來講，是一個巨大的傷害，長遠來看著實是災難。
總結
在本文中，主體分為了 “開天辟地” 和 “大眾創新” 兩塊內容，理想是豐滿的，而現實怕是很骨感。微服務是一把雙刃劍，帶來好處的同時往往也帶來了反面，架構的復雜度很難預知，因此本質上需要一個基架團隊不忘初心，持續發現，持續解決問題。
但不論如何，及早的把主力語言、基本技術棧均基本統一起來，做好產品閉環，會是一個很好的方向。
