[[411116]]

本文轉載自微信公眾號「腦子進煎魚了」，作者陳煎魚。轉載本文請聯系腦子進煎魚了公眾號。

大家好，我是煎魚。

我有一個好朋友小咸魚，他們經過服務化拆分《微服務的災難：拆的很爽，但服務太小》的磕磕碰碰后，由于一個人負責 N 倍數的服務，多開 IDE，深夜加班，一個不小心，犯迷糊了，就誤操作，邏輯寫錯服務了，就出事故了。

隨后，在小咸魚的 Leader 帶領下，經過會議室多輪爭吵后。總算是重新整理、設計了一版服務邊界，分分合合，原本拆了的合回去，又增添了新服務組合。

于是，小咸魚又可以愉快的 hello world 起來了。這難道就是事故驅動開發的威力!

但，沒開心兩天。又遇到了新的問題...

服務依賴

一般來講，在拆分為微服務后。經歷一段時間的業務規模發展后，我們的服務都是具有比較多的依賴。像是：

一個服務依賴其他多個服務

我們發現業務初始依賴的是 ServiceA，結果跑了一段時間后。服務依賴越來越多，還出現了更進一步依賴，Service A 依賴 B、C，他們背后又調用了一大堆的服務。

同時 ServiceA 依賴的服務，還存在跨業務組的情況，也就是一個普通的業務調用，可能關系到多個業務組的協調：

一次調用涉及 3 個業務組

雖然從圖示來看，只有 3 個業務組。但，一個月前可是都是依賴自己。

說明小咸魚作為業務組 A 的維護方，他所依賴的業務團隊正在不斷地增大，大家都在用力產生新的服務依賴。

假以時日，這個服務的依賴必然變的非常多(不過，小咸魚并沒有意識到這一點)。

開發環境

終于，在小咸魚維護了一段時間后。這一個業務產品，成功走過了嘗試期。他有了好幾位新同事，在迭代的過程中，聯調的訴求出現了。

小咸魚麻利的利用組織里的公共開發環境搭建起了服務：

公共開發環境

小咸魚辛辛苦苦的找了其他幾個組，讓大家都往上面 Push 自己的服務，解決了這一個迭代的聯調的問題。

但，好景不長。業務壓力總是大的，大家都維護著復數的 f 分支。這時候就遇到了新問題：

不同業務組期望依賴不同

業務組A，期望依賴的是：

• ServiceA：v0.1.0。
• ServiceB：v0.2.0。
• ServiceC：v0.3.0。

業務組B，期望依賴的是：

• ServiceA：v1.1.0。
• ServiceB：v1.2.0。
• ServiceC：v1.3.0。

好家伙，在同一個集成開發環境中，大家期望依賴的服務版本壓根不一樣。聯調起來挺費勁，甚至存在一些風險。

例如：你在開發環境，聯調時你以為你依賴的 ServiceB 的 v0.2.0 版本，跑的也好好的。結果其實其他業務在晚上把他更新為 v0.5.0 版本了，接口還是兼容的，但內在邏輯是變了的。當然，你也沒有發現這個問題，因為是 “細微” 的修改。

但上到測試環境后，很快就會出現被測試同學打回來的情況。以此往來多了，你就會成為團隊里質量不好的那一位 TOP1 了...

這問題怎么解決呢?

解決方案

針對微服務架構下的開發環境，核心還是要看公司內的基礎設施建設的怎么樣。

公共 dev 分支

若只是基礎底蘊不夠深厚，鈔能力也不夠的，一般會采取 dev 分支合并的方式。也就是在 ServiceA 上建立 dev 分支，專門用于集成開發環境。由開發同學配合腳本等，進行維護和應用。

雖然容易出現不同分支，影響到同一塊的內容。但由于同一個 Service 一般會由 1~3 個人(小團隊)經手維護，都坐在附近，基本可以控制沖突。

甚至有的小伙伴，為了謹慎起見。合并前會反向合并到自己 f 分支，再跑一遍自己的自動化接口測試，以確保正確。

當然，測試環境也是一樣的問題。在業務迭代的過程中，常常有多個功能在同時開發，會拉多個分支。

• 如果開發、測試環境只有一套，就意味著要么團隊內部商量好時間。
• 輪流使用測試環境，要把不同功能的分支代碼合到某個分支再統一解沖突，再聯調和測試。

這個方案只能治標，但不能完全治本。

多泳道環境

說白了，可能還是需要多套環境來解決。當你期望是某一個泳道用來發布某一個特性分支時。對應的發布系統就會給其相關聯的組件打上泳道標識，自然也就能知道依賴的是誰了。

如下圖：

一個服務存在多個泳道

一般客戶端會帶上泳道標識的 Header，再一路透傳下去。所有相關 Proxy 會根據 Header 內的標識進行選擇。

考慮到有的服務在功能特性中并沒有變更，因此會有 master 和功能泳道的區別，會再根據 Proxy 的規則進行選擇。

當然在這塊也可以結合服務發現的機制去做，具體看技術選型上的差距了。

總結

微服務化后，N 個服務如何聯調，就是開發人員的一個大頭疼問題。而人一多，業務壓力一大，很可能會出現一個服務同時多個分支并行開發的情況。

也就會導致開發、測試環境同一時間遇到這個煩人問題，我們可以通過公共分支，又或是多泳道的方式解決。

但兩者都存在不同程度的缺點：

公共環境，需要公共分支，需要人為的一定介入。

多泳道環境，需要的基礎設施建設較多，同時 MySQL、Redis 等公共介質也是一個問題，成本也是運維的一個考慮因素。

沒有任何一個方案是絕對的銀彈。