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