存在多個不一樣註冊中心的時候,如何平滑的統一註冊中心?

這幾天在不一樣的微信羣和社區裏連續碰到了相似的問題:spring

好比spring4all的帖子:http://bbs.spring4all.com/thread/21微信

又好比今天在秦總的羣裏也進行了相似的討論。架構

雖然描述不一樣,但核心都圍繞着一個問題:兩個不一樣註冊中心下的服務要如何互相調用?微服務

下面就針對這個問題,展開說說個人思考、實踐與建議。編碼

爲何會有這樣的場景?

先來講說背景問題,有的羣友在看到這類問題的時候,第一反應就是怎麼用多個註冊中心,是否是蛋疼了瞎搞的?spa

顯然有點腦子的人都不會這樣作!那麼爲何會存在這樣的場景呢,一般都是這樣演變而來的:設計

  1. 缺乏統一的基礎技術平臺管理,幾乎全部作大的企業都會碰到這樣的問題。爲了業務野蠻發展的時期,技術團隊是不多有精力去作這些治理的,經過系統邊界劃分好以後,由於系統與系統間的交互經過協議定義規範就好,每一個系統內部的技術棧根據團隊特性選擇本身最擅長的就行,並不須要去統一就能又好又快的去完成各個系統的建設。因此,不一樣的系統選擇不一樣的註冊中心來治理本身的服務,並無什麼不妥。
  2. 隨着業務的發展,業務須要調整,架構須要進化,複雜的系統關係(以往咱們本身開發的系統,併購進來的系統,外部採購的系統)須要被重建。不管是以微服務的方式,仍是中臺的方式去從新劃分系統邊界,勢必要對現有服務作從新規劃與治理。
  3. 因爲系統複雜,咱們無法一步就位,只能一點點的往改造目標去轉變。勢必會存在一個新老共存,逐步轉化的演進過程。爲了可以平滑的過渡改造的過程,咱們第一個想到的就是先把服務治理統一塊兒來,讓全部內部服務均可以簡單和便捷的發現彼此並可以互相調用。

因而,就有了文首你們討論的這種場景。因此,這是一個架構演進的過程產物,並非設計很差纔出來的怪胎。接口

兩種統一服務治理的思路

方案一:在業務服務端,實現多註冊中心的註冊與發現開發

這種方式就是文首,你們所提問題的方案,實現這種方案涉及幾點核心問題的解決:部署

  1. 服務註冊的擴展:咱們知道Spring Cloud的註冊機制是對單註冊中心的,同時配套的發現也同樣。咱們並不能經過多配置一套服務發現接口的實現來實現多註冊中心的實現。因此,你須要以一套主註冊中心爲Spring Cloud自身的Bean實現,外圍須要另外去學多套(根據註冊中心數量)註冊客戶端的實現。
  2. 服務發現的擴展:對於非主註冊中心的註冊操做實現了一套,那麼發現機制也要實現一套。同時,由於這裏的服務發現,並不與Spring Cloud的服務發現機制綁定,因此這些服務並不會進入到Spring Cloud配置的註冊中心下的ServiceList和對應的ServerList裏。因此在服務發現模塊,須要本身把這些外部註冊中心獲取的服務和實例加入到主註冊中心下的ServiceList和ServerList裏。同時,這裏須要注意的幾個點:

    • 由於業務服務往每一個註冊中內心都註冊了,因此在發現的時候,是會有重疊的,這裏要作好去重。
    • 對於服務名稱的管理也須要防重,不一樣系統下有一些好比用戶中心之類的服務命名是很容易衝突的。一般能夠把系統編碼作前綴來加工服務名,以保證融合後不存在重複的出現。

經過這樣一頓操做,每一個業務服務與全部註冊中心都創建了聯繫,本來處於不一樣系統的各類服務也都能互相發現並實現互相調用了。

方案二:在各個註冊中心之間,實現服務數據的同步

這種方法是新建一個註冊中心同步的服務,它的任務很簡單,就是把每一個註冊中心上的服務信息同步到其餘註冊中心上,同時監聽每一個註冊中心的變化以保持全部不一樣註冊中間都包含了全部系統下的服務。

在這種狀況下,只要是Spring Cloud構建的業務服務,那麼就只須要逐步的更換註冊中心的依賴,就能輕鬆的把本來處於不一樣註冊中心下的服務,轉移到同一註冊中心下的服務了。

兩種思路的優缺點比較

上面所述兩種方案的大體優缺點以下:

| |方案一|方案二|
|---|---|---|
|優勢|不需增長部署成本|業務服務侵入性小|
|缺點|業務服務侵入性大|須要增長部署成本|

固然,對於方案二也會有一些複雜狀況,若是對註冊過程有一些特殊定製的,會須要作一些擴展兼容。但比起第一種實現方式來講,在業務應用側的邏輯複雜度植入是很是小的。

同時,由於要統一服務治理,那麼過後最終狀態每每就是隻保留最後想要集中維護的註冊中心的,這個時候。若是採用第一種方案,那麼勢必還要去從新調整註冊與發現機制,將要淘汰的註冊與發現邏輯去除,又是一件比較複雜的事情。

因此,綜合比較這兩種方法方法來講。我的認爲採用方案二,同步註冊中心的數據來完成統一服務治理的任務,要比方案一更加穩妥,對於業務開發的影響面最小。雖然會引入一些部署成本,但這些成本對於一個多系統的基礎下,那是微乎其微的。

那麼,你們是否有碰到相似的問題呢?又有什麼好的方案呢?留言一塊兒討論下吧!若是你想與更多有趣的靈魂碰撞,也能夠加入咱們的技術交流羣一塊兒探討咱們的技術人生!

歡迎關注個人公衆號:程序猿DD,分享其餘地方看不到的知識與思考
相關文章
相關標籤/搜索