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

「微服務的戰爭」是一個關於微服務設計思考的系列題材，主要是針對在微服務化後所出現的一些矛盾/衝突點，不涉及具體某一個知識點深刻。若是你有任何問題或建議，歡迎隨時交流。前端

開天闢地

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

可是基於 template 的模式，很快就會遇到各類各樣的新問題：數據庫

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

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

經過基礎工具+基礎接口的方式，就能夠解決項目A、B、C...的基礎框架版本管理和公共維護的問題，且在遇到框架 BUG 時，只須要直接 upgrade 就行了。框架

而在框架維護者層面，還能經過註冊機制知道目前基礎框架的使用狀況（例如：版本分佈），便於後續的迭代和規劃。編輯器

同時若內部微服務依賴複雜，能夠將腳手架直接「升級」，再作多一層基礎平臺，經過 CI/CD 平臺等關聯建立應用，選擇應用類型等基本信息，而後關聯建立對應的應用模板、構建工具、網關、數據庫、接口平臺、初始化自動化用例等：微服務

至此，就能夠經過結合基礎平臺（例如：CI/CD）實現流程上的標準化控制，成爲一個提效好幫手。工具

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

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

又或是 HTTP 狀態碼的差別：

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

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

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

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

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

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

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

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

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

本文分享自微信公衆號 - 腦子進煎魚了（eddycjy）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。