背景與挑戰
爲了支撐業務的飛速發展，分佈式系統架構不斷演進，業務鏈路日趨複雜，服務間相互調用,增加了服務聯調的複雜性;
在如此研發背景下，作爲研發過程中不可或缺的一環業務鏈路聯調，面臨越來越多的挑戰：
- 聯調涉及應用服務多，導致環境構建和維護的成本都非常高，手工搭建一套可用聯調環境，少則1-2天，部分情況下甚至可能花費1到2周。因此，如何降低聯調環境構建成本，讓研發同學專注於業務聯調本身？
- 聯調鏈路上下游依賴應用服務多，爲每一個聯調鏈路都全量搭建一套獨立環境，資源消耗太大，需要對沒有變更的應用服務進行復用。但是複用又帶來了新的問題，每週上N個的並行研發活動，同一個應用服務可能爲了支持不同需求在研發階段存在多個並行研發，如何在資源複用的基礎上，解決並行研發帶來的干擾
- 聯調過程中出現了問題，排查的鏈路往往比較長，一般研發同學對自己負責的應用服務比較瞭解，如果問題出在依賴的下游，往往需要聯繫對應負責的同學排查，過程中有很多的溝通成本，排查效率比較低。如何協助研發同學快速定位聯調問題，提升業務聯調的效率?
聯調環境複用與隔離
一般操作
假如研發團隊有 3套開發環境用於聯調; 每套環境都部署了一套完整的N個服務；
這時候公司同時有4個需求開發聯調;feature_1~4 ;那麼環境佔用情況如下
每個feature佔用了一個環境,而feature_4卻被阻塞聯調了，只能等待環境空閒出來,或者再讓運維增加一套環境 dev4 來使用;但是新增一套環境不僅增加了運維的工作量；而且又增加了研發成本;
難道就沒有解決方法嗎？
將多個需求合併到一個分支
爲了解決上述問題,小企業最常用最省事的方法是:
拉一個新的分支 feature_1_2, 將多個分支都一起合併到這個分支上來進行聯調；共用一套環境;
確實,這是最省事的方法,但是這個方法存在它的侷限性
- 代碼衝突, 需求衝突
- 每次修改了bug都要將代碼合併到合併分支feature_1_2
- 代碼污染, 修改bug的時候沒有寫在需求分支而寫在的合併分支feature_1_2
正常來說,嚴格按照約定操作,也不會出現什麼問題,但是我們有更好的解決方案
聯調環境複用與隔離
上面的方法雖然可以操作，但是使用太複雜;我們可以將沒有收到需求迭代而變更的服務複用起來;
全量部署所有服務的master穩定分支
首先我們把所有服務都部署在一套環境裏面;跟stable環境(或者生產環境)保持一致;
這些服務永遠都是部署master穩定分支,這些服務就是用來被複用的;
假設我們有4個需求並行開發聯調,那調用鏈就是下面這種
上圖假設的feature_1只變更了 S1 S3 S4 的服務，那麼沒有變更的S2 S5就可以直接複用master的穩定服務 M2 M5
上圖假設feature_2 只變更了 S3;其餘的服務都可以服務穩定版本的服務;
理論可以並行開發聯調N個需求
看到上面服務複用的模型,我們來算一個賬;
假設最初的時候 一個需求佔用一套環境; 一套環境可能部署了N套服務;
想要並行聯調Y個需求,那麼就需要 N*Y個服務器資源;
用了服務重用之後;同樣支持Y個需求佔用的服務器資源要遠遠少的多；
因爲每個需求中服務變更的是少數,假如一套環境100個服務,一次需求的變更服務數目一般不超過10個，我們只需要提供變更服務的部署資源就行;
而且不需要完整的重新搭建一套環境,只需要部署變更服務
服務路由隔離
上面介紹的是實現的思路，同一個環境下(指的是同一個zk下注冊的服務)
- 我們要怎麼複用這個穩定服務呢？
- 同一個服務被註冊了多個提供者;如何準確的調用對應需求的服務呢？
因爲不同的RPC的實現不一樣,我這裏主要講解Rpc爲dubbo的情況下，如何實現上述需求;
因爲文字篇幅過長,故新開一篇文章講解 Dubbo下的多版本並行開發測試解決方案
調用入口處理
http請求訪問
統一網關訪問
中間件隔離
配置管理(Nacos、Apollo等等)
消息系統(kafka、RocketMq 等等)
Kafka 隔離
DB隔離
先佔個坑 有空再寫 TODO…