建站
咨詢
售后
建站咨詢
新聞中心
[[411116]]
本文轉載自微信公眾號「腦子進煎魚了」，作者陳煎魚。轉載本文請聯(lián)系腦子進煎魚了公眾號。
大家好，我是煎魚。
我有一個好朋友小咸魚，他們經(jīng)過服務化拆分《微服務的災難：拆的很爽，但服務太小》的磕磕碰碰后，由于一個人負責 N 倍數(shù)的服務，多開 IDE，深夜加班，一個不小心，犯迷糊了，就誤操作，邏輯寫錯服務了，就出事故了。
隨后，在小咸魚的 Leader 帶領下，經(jīng)過會議室多輪爭吵后?？偹闶侵匦抡?、設計了一版服務邊界，分分合合，原本拆了的合回去，又增添了新服務組合。
于是，小咸魚又可以愉快的 hello world 起來了。這難道就是事故驅動開發(fā)的威力!
但，沒開心兩天。又遇到了新的問題...
服務依賴
一般來講，在拆分為微服務后。經(jīng)歷一段時間的業(yè)務規(guī)模發(fā)展后，我們的服務都是具有比較多的依賴。像是：
一個服務依賴其他多個服務
我們發(fā)現(xiàn)業(yè)務初始依賴的是 ServiceA，結果跑了一段時間后。服務依賴越來越多，還出現(xiàn)了更進一步依賴，Service A 依賴 B、C，他們背后又調用了一大堆的服務。
同時 ServiceA 依賴的服務，還存在跨業(yè)務組的情況，也就是一個普通的業(yè)務調用，可能關系到多個業(yè)務組的協(xié)調：
一次調用涉及 3 個業(yè)務組
雖然從圖示來看，只有 3 個業(yè)務組。但，一個月前可是都是依賴自己。
說明小咸魚作為業(yè)務組 A 的維護方，他所依賴的業(yè)務團隊正在不斷地增大，大家都在用力產(chǎn)生新的服務依賴。
假以時日，這個服務的依賴必然變的非常多(不過，小咸魚并沒有意識到這一點)。
開發(fā)環(huán)境
終于，在小咸魚維護了一段時間后。這一個業(yè)務產(chǎn)品，成功走過了嘗試期。他有了好幾位新同事，在迭代的過程中，聯(lián)調的訴求出現(xiàn)了。
小咸魚麻利的利用組織里的公共開發(fā)環(huán)境搭建起了服務：
公共開發(fā)環(huán)境
小咸魚辛辛苦苦的找了其他幾個組，讓大家都往上面 Push 自己的服務，解決了這一個迭代的聯(lián)調的問題。
但，好景不長。業(yè)務壓力總是大的，大家都維護著復數(shù)的 f 分支。這時候就遇到了新問題：
不同業(yè)務組期望依賴不同
業(yè)務組A，期望依賴的是：
- ServiceA：v0.1.0。
- ServiceB：v0.2.0。
- ServiceC：v0.3.0。
業(yè)務組B，期望依賴的是：
- ServiceA：v1.1.0。
- ServiceB：v1.2.0。
- ServiceC：v1.3.0。
好家伙，在同一個集成開發(fā)環(huán)境中，大家期望依賴的服務版本壓根不一樣。聯(lián)調起來挺費勁，甚至存在一些風險。
例如：你在開發(fā)環(huán)境，聯(lián)調時你以為你依賴的 ServiceB 的 v0.2.0 版本，跑的也好好的。結果其實其他業(yè)務在晚上把他更新為 v0.5.0 版本了，接口還是兼容的，但內在邏輯是變了的。當然，你也沒有發(fā)現(xiàn)這個問題，因為是 “細微” 的修改。
但上到測試環(huán)境后，很快就會出現(xiàn)被測試同學打回來的情況。以此往來多了，你就會成為團隊里質量不好的那一位 TOP1 了...
這問題怎么解決呢?
解決方案
針對微服務架構下的開發(fā)環(huán)境，核心還是要看公司內的基礎設施建設的怎么樣。
公共 dev 分支
若只是基礎底蘊不夠深厚，鈔能力也不夠的，一般會采取 dev 分支合并的方式。也就是在 ServiceA 上建立 dev 分支，專門用于集成開發(fā)環(huán)境。由開發(fā)同學配合腳本等，進行維護和應用。
雖然容易出現(xiàn)不同分支，影響到同一塊的內容。但由于同一個 Service 一般會由 1~3 個人(小團隊)經(jīng)手維護，都坐在附近，基本可以控制沖突。
甚至有的小伙伴，為了謹慎起見。合并前會反向合并到自己 f 分支，再跑一遍自己的自動化接口測試，以確保正確。
當然，測試環(huán)境也是一樣的問題。在業(yè)務迭代的過程中，常常有多個功能在同時開發(fā)，會拉多個分支。
- 如果開發(fā)、測試環(huán)境只有一套，就意味著要么團隊內部商量好時間。
- 輪流使用測試環(huán)境，要把不同功能的分支代碼合到某個分支再統(tǒng)一解沖突，再聯(lián)調和測試。
這個方案只能治標，但不能完全治本。
多泳道環(huán)境
說白了，可能還是需要多套環(huán)境來解決。當你期望是某一個泳道用來發(fā)布某一個特性分支時。對應的發(fā)布系統(tǒng)就會給其相關聯(lián)的組件打上泳道標識，自然也就能知道依賴的是誰了。
如下圖：
一個服務存在多個泳道
一般客戶端會帶上泳道標識的 Header，再一路透傳下去。所有相關 Proxy 會根據(jù) Header 內的標識進行選擇。
考慮到有的服務在功能特性中并沒有變更，因此會有 master 和功能泳道的區(qū)別，會再根據(jù) Proxy 的規(guī)則進行選擇。
當然在這塊也可以結合服務發(fā)現(xiàn)的機制去做，具體看技術選型上的差距了。
總結
微服務化后，N 個服務如何聯(lián)調，就是開發(fā)人員的一個大頭疼問題。而人一多，業(yè)務壓力一大，很可能會出現(xiàn)一個服務同時多個分支并行開發(fā)的情況。
也就會導致開發(fā)、測試環(huán)境同一時間遇到這個煩人問題，我們可以通過公共分支，又或是多泳道的方式解決。
但兩者都存在不同程度的缺點：
公共環(huán)境，需要公共分支，需要人為的一定介入。
多泳道環(huán)境，需要的基礎設施建設較多，同時 MySQL、Redis 等公共介質也是一個問題，成本也是運維的一個考慮因素。
沒有任何一個方案是絕對的銀彈。
分享文章：微服務的災難：折磨人的環(huán)境！
網(wǎng)頁地址：http://fisionsoft.com.cn/article/cdepcge.html
