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