這幾天在不一樣的微信羣和社區裏連續碰到了相似的問題:spring
好比spring4all的帖子:http://bbs.spring4all.com/thread/21微信
又好比今天在秦總的羣裏也進行了相似的討論。架構
雖然描述不一樣,但核心都圍繞着一個問題:兩個不一樣註冊中心下的服務要如何互相調用?微服務
下面就針對這個問題,展開說說個人思考、實踐與建議。編碼
先來講說背景問題,有的羣友在看到這類問題的時候,第一反應就是怎麼用多個註冊中心,是否是蛋疼了瞎搞的?spa
顯然有點腦子的人都不會這樣作!那麼爲何會存在這樣的場景呢,一般都是這樣演變而來的:設計
因而,就有了文首你們討論的這種場景。因此,這是一個架構演進的過程產物,並非設計很差纔出來的怪胎。接口
方案一:在業務服務端,實現多註冊中心的註冊與發現開發
這種方式就是文首,你們所提問題的方案,實現這種方案涉及幾點核心問題的解決:部署
服務發現的擴展:對於非主註冊中心的註冊操做實現了一套,那麼發現機制也要實現一套。同時,由於這裏的服務發現,並不與Spring Cloud的服務發現機制綁定,因此這些服務並不會進入到Spring Cloud配置的註冊中心下的ServiceList和對應的ServerList裏。因此在服務發現模塊,須要本身把這些外部註冊中心獲取的服務和實例加入到主註冊中心下的ServiceList和ServerList裏。同時,這裏須要注意的幾個點:
經過這樣一頓操做,每一個業務服務與全部註冊中心都創建了聯繫,本來處於不一樣系統的各類服務也都能互相發現並實現互相調用了。
方案二:在各個註冊中心之間,實現服務數據的同步
這種方法是新建一個註冊中心同步的服務,它的任務很簡單,就是把每一個註冊中心上的服務信息同步到其餘註冊中心上,同時監聽每一個註冊中心的變化以保持全部不一樣註冊中間都包含了全部系統下的服務。
在這種狀況下,只要是Spring Cloud構建的業務服務,那麼就只須要逐步的更換註冊中心的依賴,就能輕鬆的把本來處於不一樣註冊中心下的服務,轉移到同一註冊中心下的服務了。
上面所述兩種方案的大體優缺點以下:
| |方案一|方案二|
|---|---|---|
|優勢|不需增長部署成本|業務服務侵入性小|
|缺點|業務服務侵入性大|須要增長部署成本|
固然,對於方案二也會有一些複雜狀況,若是對註冊過程有一些特殊定製的,會須要作一些擴展兼容。但比起第一種實現方式來講,在業務應用側的邏輯複雜度植入是很是小的。
同時,由於要統一服務治理,那麼過後最終狀態每每就是隻保留最後想要集中維護的註冊中心的,這個時候。若是採用第一種方案,那麼勢必還要去從新調整註冊與發現機制,將要淘汰的註冊與發現邏輯去除,又是一件比較複雜的事情。
因此,綜合比較這兩種方法方法來講。我的認爲採用方案二,同步註冊中心的數據來完成統一服務治理的任務,要比方案一更加穩妥,對於業務開發的影響面最小。雖然會引入一些部署成本,但這些成本對於一個多系統的基礎下,那是微乎其微的。
那麼,你們是否有碰到相似的問題呢?又有什麼好的方案呢?留言一塊兒討論下吧!若是你想與更多有趣的靈魂碰撞,也能夠加入咱們的技術交流羣一塊兒探討咱們的技術人生!
歡迎關注個人公衆號:程序猿DD,分享其餘地方看不到的知識與思考