[[339316]]

本文轉(zhuǎn)載自微信公眾號(hào)「腦子進(jìn)煎魚了」，作者陳煎魚 。轉(zhuǎn)載本文請聯(lián)系腦子進(jìn)煎魚了公眾號(hào)。

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

開天辟地

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

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

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

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

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

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

同時(shí)若內(nèi)部微服務(wù)依賴復(fù)雜，可以將腳手架直接 “升級(jí)”，再做多一層基礎(chǔ)平臺(tái)，通過 CI/CD 平臺(tái)等關(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ù)庫、接口平臺(tái)、初始化自動(dòng)化用例等：

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

大眾創(chuàng)新

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

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

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

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

• HTTP Status Code 為金標(biāo)準(zhǔn)，不在主體定義業(yè)務(wù)錯(cuò)誤碼。
• HTTP Status Code 都為 200 OK(除宕機(jī)導(dǎo)致的 500，503 等)，業(yè)務(wù)錯(cuò)誤碼由主體另外定義。

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

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

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

1. A 吞并 B，B 與 A 一致，從例子上來講就是基本公用一套(維度為公司/事業(yè)部/業(yè)務(wù)組級(jí)別，與企業(yè)情況有關(guān))。
2. A，B 均獨(dú)立發(fā)展，從例子上來講就是均獨(dú)立搭建，各管各，偶爾互相觸碰邊界，又或是在公開分享暗中切磋。

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

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

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

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

總結(jié)

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

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