微服務(wù)的戰(zhàn)爭：統(tǒng)一且標(biāo)準(zhǔn)化

“微服務(wù)的戰(zhàn)爭” 是一個關(guān)于微服務(wù)設(shè)計思考的系列題材，主要是針對在微服務(wù)化后所出現(xiàn)的一些矛盾/沖突點，不涉及具體某一個知識點深入。如果你有任何問題或建議，歡迎隨時交流。

開天辟地

在遠(yuǎn)古開天辟地時，大單體轉(zhuǎn)換成微服務(wù)化后，服務(wù)的數(shù)量越來越多。每起一個新的服務(wù)，就得把項目的目錄結(jié)構(gòu)，基礎(chǔ)代碼重新整理一遍，并且很有可能都是從最初的 template 上 ctrl+c，ctrl+v 復(fù)制出來的產(chǎn)物，如下：

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

隨著跨事業(yè)部/業(yè)務(wù)組的使用增多，你根本不知道框架的 template 是什么時間節(jié)點被復(fù)制粘貼出去的，也不知道所對應(yīng)的 commit-id 是什么，更不知道先前的 BUG 修復(fù)了沒，也不知道有沒有其他開發(fā)人員私下改過被復(fù)制走的 template。

簡單來講，就是不具備可維護(hù)性，相對獨立，BUG 可能一樣，但卻沒有版本可規(guī)管。這時候，就可以選擇做一個內(nèi)部基礎(chǔ)框架和對應(yīng)的內(nèi)部工具（已經(jīng)有用戶市場了），形成一個腳手架閉環(huán)：

通過基礎(chǔ)工具+基礎(chǔ)接口的方式，就可以解決項目A、B、C...的基礎(chǔ)框架版本管理和公共維護(hù)的問題，且在遇到框架 BUG 時，只需要直接 upgrade 就好了。

而在框架維護(hù)者層面，還能通過注冊機(jī)制知道目前基礎(chǔ)框架的使用情況（例如：版本分布），便于后續(xù)的迭代和規(guī)劃。

同時若內(nèi)部微服務(wù)依賴復(fù)雜，可以將腳手架直接 “升級”，再做多一層基礎(chǔ)平臺，通過 CI/CD 平臺等關(guān)聯(lián)創(chuàng)建應(yīng)用，選擇應(yīng)用類型等基本信息，然后關(guān)聯(lián)創(chuàng)建對應(yīng)的應(yīng)用模板、構(gòu)建工具、網(wǎng)關(guān)、數(shù)據(jù)庫、接口平臺、初始化自動化用例等：

至此，就可以通過結(jié)合基礎(chǔ)平臺（例如：CI/CD）實現(xiàn)流程上的標(biāo)準(zhǔn)化控制，成為一個提效好幫手。

大眾創(chuàng)新

但，一切都有 “開天辟地” 那么順利嗎。實際上并不，在很多的公司中，大多數(shù)是在不同的時間階段在不同的團(tuán)隊同時進(jìn)行了多個開天辟地。

更具現(xiàn)化來講，就是在一家公司內(nèi)，不同的團(tuán)隊里做出了多種基礎(chǔ)工具和基礎(chǔ)框架。更要命的是，他們幾家的規(guī)范可能還不大一樣。例如：框架在 gRPC 錯誤碼的規(guī)范處理上的差異：

• 業(yè)務(wù)錯誤碼放在 grpc.status.details 中。

• 業(yè)務(wù)錯誤碼放在 grpc-status 中。

• 業(yè)務(wù)錯誤碼放在 grpc-message 中。

又或是 HTTP 狀態(tài)碼的差異：

• HTTP Status Code 為金標(biāo)準(zhǔn)，不在主體定義業(yè)務(wù)錯誤碼。

• HTTP Status Code 都為 200 OK（除宕機(jī)導(dǎo)致的 500，503 等），業(yè)務(wù)錯誤碼由主體另外定義。

粗略一看，單單在應(yīng)用錯誤碼/狀態(tài)碼這一件事情上，就能夠玩出花樣。而這件事又會導(dǎo)致各種問題，例如在監(jiān)控平臺上，因為不同團(tuán)隊所定義的狀態(tài)碼規(guī)范不一樣，就會導(dǎo)致連基本的監(jiān)控可用性都會有問題。

像是有的小伙伴會把業(yè)務(wù)錯誤碼放在 grpc-status 屬性中，而在標(biāo)準(zhǔn) gRPC 的規(guī)范中 grpc-status 是和 HTTP Status Code 一樣有特定狀態(tài)碼映射的。這時候就會讓監(jiān)控告警系統(tǒng)十分難做，通用的告警規(guī)則到底是以哪份狀態(tài)碼為準(zhǔn)？

往往最終演進(jìn)的路線與企業(yè)的組織結(jié)構(gòu)有關(guān)，也就是康威定律，一個系統(tǒng)的技術(shù)邊界反映組織的結(jié)構(gòu)。業(yè)界常見的是兩種情況：

1. A 吞并 B，B 與 A 一致，從例子上來講就是基本公用一套（維度為公司/事業(yè)部/業(yè)務(wù)組級別，與企業(yè)情況有關(guān)）。

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

顯然，這其中利與弊就要各自判斷了，多少廠內(nèi)部有多少個框架，也有血汗廠基本一統(tǒng)江湖的，可能做基礎(chǔ)架構(gòu)適配的小伙伴會比較有感觸，不同框架的 Header 規(guī)范不一樣，這樣子即使是 Mesh 也避免不了一頓 if else。

更甚的是，在類似服務(wù)發(fā)現(xiàn)/注冊、限流熔斷、基礎(chǔ)攔截器，各類 SDK 同個廠的每個內(nèi)部框架都重現(xiàn)實現(xiàn)一遍。美其名曰框架支持了這些，就允許讓他上，但這樣子怕是在未來又造成了新的一波技術(shù)債務(wù)。

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

這單從公司層面來講，是一個巨大的傷害，長遠(yuǎn)來看著實是災(zāi)難。

總結(jié)

在本文中，主體分為了 “開天辟地” 和 “大眾創(chuàng)新” 兩塊內(nèi)容，理想是豐滿的，而現(xiàn)實怕是很骨感。微服務(wù)是一把雙刃劍，帶來好處的同時往往也帶來了反面，架構(gòu)的復(fù)雜度很難預(yù)知，因此本質(zhì)上需要一個基架團(tuán)隊不忘初心，持續(xù)發(fā)現(xiàn)，持續(xù)解決問題。

但不論如何，及早的把主力語言、基本技術(shù)棧均基本統(tǒng)一起來，做好產(chǎn)品閉環(huán)，會是一個很好的方向。

推薦閱讀

• 微服務(wù)的戰(zhàn)爭：按什么維度拆分服務(wù)