存在多個(gè)不同注冊(cè)中心的時(shí)候，如何平滑的統(tǒng)一注冊(cè)中心？
本文轉(zhuǎn)載自微信公眾號(hào)「程序猿DD」，作者翟永超。轉(zhuǎn)載本文請(qǐng)聯(lián)系程序猿DD公眾號(hào)。
這幾天在不同的微信群和社區(qū)里連續(xù)碰到了一類問題：
比如spring4all的帖子：http://bbs.spring4all.com/thread/21
又比如昨天在秦總的群里也進(jìn)行了類似的討論。
雖然描述不同，但核心都圍繞著一個(gè)問題：多個(gè)不同注冊(cè)中心下的服務(wù)治理問題!下面就針對(duì)這個(gè)問題，展開說說我的思考、實(shí)踐與建議吧。
為什么會(huì)有這樣的場(chǎng)景?
先來說說背景問題，有的群友在看到這類問題的時(shí)候，第一反應(yīng)就是怎么用多個(gè)注冊(cè)中心，是不是蛋疼了瞎搞的?
顯然有點(diǎn)腦子的人都不會(huì)這樣做!那么為什么會(huì)存在這樣的場(chǎng)景呢，通常都是這樣演變而來的：
- 缺少統(tǒng)一的基礎(chǔ)技術(shù)平臺(tái)管理，幾乎所有做大的企業(yè)都會(huì)碰到這樣的問題。為了業(yè)務(wù)野蠻發(fā)展的時(shí)期，技術(shù)團(tuán)隊(duì)是很少有精力去做這些治理的，通過系統(tǒng)邊界劃分好之后，因?yàn)橄到y(tǒng)與系統(tǒng)間的交互通過協(xié)議定義規(guī)范就好，每個(gè)系統(tǒng)內(nèi)部的技術(shù)棧根據(jù)團(tuán)隊(duì)特性選擇自己最擅長(zhǎng)的就行，并不需要去統(tǒng)一就能又好又快的去完成各個(gè)系統(tǒng)的建設(shè)。所以，不同的系統(tǒng)選擇不同的注冊(cè)中心來治理自己的服務(wù)，并沒有什么不妥。
- 隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)需要調(diào)整，架構(gòu)需要進(jìn)化，復(fù)雜的系統(tǒng)關(guān)系(以往我們自己開發(fā)的系統(tǒng)，并購進(jìn)來的系統(tǒng)，外部采購的系統(tǒng))需要被重建。不論是以微服務(wù)的方式，還是中臺(tái)的方式去重新劃分系統(tǒng)邊界，勢(shì)必要對(duì)現(xiàn)有服務(wù)做重新規(guī)劃與治理。
- 由于系統(tǒng)復(fù)雜，我們沒法一步就位，只能一點(diǎn)點(diǎn)的往改造目標(biāo)去轉(zhuǎn)變。勢(shì)必會(huì)存在一個(gè)新老共存，逐步轉(zhuǎn)化的演進(jìn)過程。為了能夠平滑的過渡改造的過程，我們第一個(gè)想到的就是先把服務(wù)治理統(tǒng)一起來，讓所有內(nèi)部服務(wù)都可以簡(jiǎn)單和便捷的發(fā)現(xiàn)彼此并能夠互相調(diào)用。同時(shí)，多種多樣的注冊(cè)中心造成的運(yùn)維復(fù)雜度也能通過統(tǒng)一服務(wù)治理體系得以解決。
于是，這就有了文首大家討論的這種場(chǎng)景。所以，這是一個(gè)架構(gòu)演進(jìn)的過程產(chǎn)物，并不是因?yàn)樵O(shè)計(jì)不好，才出來的怪胎架構(gòu)。
兩種統(tǒng)一服務(wù)治理的思路
方案一：在業(yè)務(wù)服務(wù)端，實(shí)現(xiàn)多注冊(cè)中心的注冊(cè)與發(fā)現(xiàn)
這種方式就是文首，大家所提問題的方案，實(shí)現(xiàn)這種方案涉及幾點(diǎn)核心問題的解決：
- 服務(wù)注冊(cè)的擴(kuò)展：我們知道Spring Cloud的注冊(cè)機(jī)制是對(duì)單注冊(cè)中心的，同時(shí)配套的發(fā)現(xiàn)也一樣。我們并不能通過多配置一套服務(wù)發(fā)現(xiàn)接口的實(shí)現(xiàn)來實(shí)現(xiàn)多注冊(cè)中心的實(shí)現(xiàn)。所以，你需要以一套主注冊(cè)中心為Spring Cloud自身的Bean實(shí)現(xiàn)，外圍需要另外去學(xué)多套(根據(jù)注冊(cè)中心數(shù)量)注冊(cè)客戶端的實(shí)現(xiàn)。
- 服務(wù)發(fā)現(xiàn)的擴(kuò)展：對(duì)于非主注冊(cè)中心的注冊(cè)操作實(shí)現(xiàn)了一套，那么發(fā)現(xiàn)機(jī)制也要實(shí)現(xiàn)一套。同時(shí)，因?yàn)檫@里的服務(wù)發(fā)現(xiàn)，并不與Spring Cloud的服務(wù)發(fā)現(xiàn)機(jī)制綁定，所以這些服務(wù)并不會(huì)進(jìn)入到Spring Cloud配置的注冊(cè)中心下的ServiceList和對(duì)應(yīng)的ServerList里。所以在服務(wù)發(fā)現(xiàn)模塊，需要自己把這些外部注冊(cè)中心獲取的服務(wù)和實(shí)例加入到主注冊(cè)中心下的ServiceList和ServerList里。
同時(shí)，這里需要注意的幾個(gè)點(diǎn)：
- 因?yàn)闃I(yè)務(wù)服務(wù)往每個(gè)注冊(cè)中心里都注冊(cè)了，所以在發(fā)現(xiàn)的時(shí)候，是會(huì)有重疊的，這里要做好去重。
- 對(duì)于服務(wù)名稱的管理也需要防重，不同系統(tǒng)下有一些諸如用戶中心之類的服務(wù)命名是很容易沖突的，可以用系統(tǒng)編碼做前綴來加工服務(wù)名，以保證融合后不存在重復(fù)的出現(xiàn)。
通過這樣一頓操作，每個(gè)業(yè)務(wù)服務(wù)與所有注冊(cè)中心都建立了聯(lián)系，原本處于不同系統(tǒng)的各種服務(wù)也都能互相發(fā)現(xiàn)并實(shí)現(xiàn)互相調(diào)用了。
方案二：在各個(gè)注冊(cè)中心之間，實(shí)現(xiàn)服務(wù)數(shù)據(jù)的同步
這種方法是新建一個(gè)注冊(cè)中心同步的服務(wù)，它的任務(wù)很簡(jiǎn)單，就是把每個(gè)注冊(cè)中心上的服務(wù)信息同步到其他注冊(cè)中心上，同時(shí)監(jiān)聽每個(gè)注冊(cè)中心的變化以保持所有不同注冊(cè)中間都包含了所有系統(tǒng)下的服務(wù)。
在這種情況下，只要是Spring Cloud構(gòu)建的業(yè)務(wù)服務(wù)，那么就只需要逐步的更換注冊(cè)中心的依賴，就能輕松的把原本處于不同注冊(cè)中心下的服務(wù)，轉(zhuǎn)移到同一注冊(cè)中心下的服務(wù)了。
兩種思路的優(yōu)缺點(diǎn)比較
上面所述兩種方案的大致優(yōu)缺點(diǎn)如下：
| 方案一 | 方案二 | |
|---|---|---|
| 優(yōu)點(diǎn) | 不需增加部署成本 | 業(yè)務(wù)服務(wù)侵入性小 |
| 缺點(diǎn) | 業(yè)務(wù)服務(wù)侵入性大 | 需要增加部署成本 |
當(dāng)然，對(duì)于方案二也會(huì)有一些復(fù)雜情況，如果對(duì)注冊(cè)過程有一些特殊定制的，會(huì)需要做一些擴(kuò)展兼容。但比起方案一的改造程度來說，在業(yè)務(wù)應(yīng)用側(cè)的邏輯復(fù)雜度植入是非常小的。
同時(shí)，因?yàn)橐y(tǒng)一服務(wù)治理，那么事后最終狀態(tài)往往就是只保留最后想要集中維護(hù)的注冊(cè)中心的。這個(gè)時(shí)候。如果采用第一種方案，那么勢(shì)必還要去重新調(diào)整注冊(cè)與發(fā)現(xiàn)機(jī)制，將要淘汰的注冊(cè)與發(fā)現(xiàn)邏輯去除，又是一件比較復(fù)雜的事情。
所以，綜合比較這兩種方法方法來說。個(gè)人認(rèn)為采用方案二，同步注冊(cè)中心的數(shù)據(jù)來完成統(tǒng)一服務(wù)治理的任務(wù)，要比方案一更加穩(wěn)妥，對(duì)于業(yè)務(wù)開發(fā)的影響面最小。雖然會(huì)引入一些部署成本，但這些成本對(duì)于一個(gè)多系統(tǒng)的基礎(chǔ)下，那是微乎其微的。
原文鏈接：https://mp.weixin.qq.com/s/7_K7-vw2Yu7ByjyqGcLGYw
