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