1. 程式人生 > >微服務技術棧:常見註冊中心元件,對比分析

微服務技術棧:常見註冊中心元件,對比分析

本文原始碼:[GitHub·點這裡](https://github.com/cicadasmile/husky-spring-cloud) || [GitEE·點這裡](https://gitee.com/cicadasmile/husky-spring-cloud) # 一、註冊中心簡介 ## 1、基礎概念 在分散式架構的系統中註冊中心這個概念就已經被提出了,最經典的就是Zookeeper中介軟體。 ![](https://img2020.cnblogs.com/blog/1691717/202006/1691717-20200615215643303-595569320.png) 微服務架構中,註冊中心是最核心的基礎服務之一,註冊中心可以看做是微服務架構中的通訊中心,當一個服務去請求另一個服務時,通過註冊中心可以獲取該服務的狀態,地址等核心資訊。 服務註冊主要關係到三大角色:服務提供者、服務消費者、註冊中心。 ## 2、流程和原理 **基礎流程** - 服務啟動時,將自身的網路地址等資訊註冊到註冊中心,註冊中心記錄服務註冊資料。 - 服務消費者從註冊中心獲取服務提供者的地址,並通過地址和基於特定的方式呼叫服務提供者的介面。 - 各個服務與註冊中心使用一定機制通訊。如果註冊中心與服務長時間無法通訊,就會登出該例項,這也稱為服務下線,當服務重新連線之後,會基於一定的策略在線上線。 - 服務地址相關資訊發生變化時,會重新註冊到註冊中心。這樣,服務消費者就無需手工維護提供者的相關配置。 **核心功能** 通過上面的基本流程,不難發現一個註冊中心需要具備哪些核心功能: - 服務發現 服務發現是指服務在啟動後,註冊到註冊中心,服務方提供自身的元資料,比如IP地址、埠、執行狀況指標的Uri 、主頁地址等資訊。 - 服務記錄 記錄註冊中心的服務的資訊,例如服務名稱、IP地址、埠等。服務消費方基於查詢獲取可用的服務例項列表。 - 動態管理服務 註冊中心基於特定的機制定時測試已註冊的服務,例如:預設的情況下會每隔30秒傳送一次心跳來進行服務續約。通過服務續約來告知Server該Client仍然可用。正常情況下,如果Server在90 秒內沒有收到Client 的心跳,Server會將Client 例項從註冊列表中刪除。 # 二、基礎元件對比 ## 1、Zookeeper元件 **1.1基礎描述** ![](https://img2020.cnblogs.com/blog/1691717/202006/1691717-20200615220010441-947942263.jpg) ZooKeeper是非常經典的服務註冊中心中介軟體,在國內環境下,由於受到Dubbo框架的影響,大部分情況下認為Zookeeper是RPC服務框架下注冊中心最好選擇,隨著Dubbo框架的不斷開發優化,和各種註冊中心元件的誕生,即使是RPC框架,現在的註冊中心也逐步放棄了ZooKeeper。在常用的開發叢集環境中,ZooKeeper依然起到十分重要的作用,Java體系中,大部分的叢集環境都是依賴ZooKeeper管理服務的各個節點。 **1.2元件特點** ![](https://img2020.cnblogs.com/blog/1691717/202006/1691717-20200615220022500-518363372.jpg) 從Zookeeper的資料結構特點看,並不是基於服務註冊而設計的,ZooKeeper提供的名稱空間與檔案系統的名稱空間非常相似,在資料結構上高度抽象為K-V格式,十分通用,說到這裡不得不提一下Redis,也可以作為註冊中心使用,只是用的不多。 ZooKeeper元件支援節點短暫存在,只要建立znode的會話處於活動狀態,這些znode就會存在,會話結束時,將刪除znode。Dubbo框架正是基於這個特點,服務啟動往Zookeeper註冊的就是臨時節點,需要定時發心跳到Zookeeper來續約節點,並允許服務下線時,將Zookeeper上相應的節點刪除,同時Zookeeper使用ZAB協議雖然保證了資料的強一致性。 ## 2、Eureka元件 **2.1基礎描述** ![](https://img2020.cnblogs.com/blog/1691717/202006/1691717-20200615220034219-150455792.png) SpringCloud框架生態中最原生的深度結合元件,Eureka是Netflix開發的服務發現框架,基於REST的服務,主要用於服務註冊,管理,負載均衡和服務故障轉移。但是官方宣告在Eureka2.0版本停止維護,不建議使用。 **2.2元件特點** Eureka包含兩個元件:EurekaServer和EurekaClient。 EurekaServer提供服務註冊服務,各個節點啟動後,會在EurekaServer中進行註冊,這樣EurekaServer中的服務登錄檔中將會儲存所有可用服務節點的資訊,服務節點的資訊可以在介面中直觀的看到。Eureka允許在註冊服務的時候,自定義實現檢查自身狀態的是否健康的方法,這在服務例項能夠保持心跳上報的場景下,是一種比較好的體驗。 EurekaClient是一個java客戶端,用於簡化與EurekaServer的互動,客戶端同時也就是一個內建的、使用輪詢(round-robin)負載演算法的負載均衡器。 ## 3、Consul元件 **3.1基礎描述** ![](https://img2020.cnblogs.com/blog/1691717/202006/1691717-20200615220046635-1973789216.png) Consul是用於服務發現和配置的工具。Consul是分散式的,高度可用的,並且具有極高的可伸縮性,而且開發使用都很簡便。它提供了一個功能齊全的控制面板,主要特點是:服務發現、健康檢查、鍵值儲存、安全服務通訊、多資料中心、ServiceMesh。Consul在設計上把很多分散式服務治理上要用到的功能都包含在內了。 **3.2元件特點** Consul提供多個數據中心的支援,基於Fabio做負載均衡,每個資料中心內,都有客戶端和服務端的混合構成。預計有三到五臺服務端。可以在失敗和效能的可用性之間取得良好的平衡。資料中心中的所有節點都參與八卦協議。這意味著有一個八卦池,其中包含給定資料中心的所有節點。這有幾個目的:首先,不需要為客戶端配置伺服器的地址;發現是自動完成的。其次,檢測節點故障的工作不是放在伺服器上,而是分散式的。這使得故障檢測比天真的心跳方案更具可擴充套件性。第三,它被用作訊息傳遞層,用於在諸如領導者選舉等重要事件發生時進行通知。 ## 4、Nacos元件 **4.1基礎描述** ![](https://img2020.cnblogs.com/blog/1691717/202006/1691717-20200615220058851-84894710.jpg) Nacos致力於發現、配置和管理微服務。Nacos提供了一組簡單易用的特性集,幫助您實現動態服務發現、服務配置管理、服務及流量管理。Nacos更敏捷和容易地構建、交付和管理微服務平臺。 Nacos 是構建以“服務”為中心的現代應用架構(例如微服務正規化、雲原生正規化)的服務基礎設施。Nacos支援作為RPC註冊中心,例如:支援Dubbo框架;也具備微服務註冊中心的能力,例如:SpringCloud框架。 **4.2元件特點** ![](https://img2020.cnblogs.com/blog/1691717/202006/1691717-20200615220108565-1168250675.jpg) Nacos在經過多年生產經驗後提煉出的資料模型,則是一種服務-叢集-例項的三層模型。如上文所說,這樣基本可以滿足服務在所有場景下的資料儲存和管理,資料模型雖然相對複雜,但是並不強制使用資料結構的風格,大多數應用場景下,和Eureka資料模型是類似的。 Nacos提供資料邏輯隔離模型,使用者賬號可以新建多個名稱空間,每個名稱空間對應一個客戶端例項,這個名稱空間對應的註冊中心物理叢集是可以根據規則進行路由的,這樣可以讓註冊中心內部的升級和遷移對使用者是無感知的。 # 三、元件選擇 如下注冊中心對比圖。 ![](https://img2020.cnblogs.com/blog/1691717/202006/1691717-20200615220118716-1338640460.jpg) 綜合上述幾種註冊中心對比,再從現在SpringCloud框架流行趨勢看,個人推薦後續微服務架構體系選擇Nacos元件,大致原因如下,社群活躍,經過大規模業務驗證,不但可以作為微服務註冊中心,也支援作RPC框架Dubbo的註冊中心,且有完善的中文文件,總結下來就一句話:通用中介軟體,省時;文件詳細,省心。 # 四、原始碼地址 ``` GitHub·地址 https://github.com/cicadasmile/husky-spring-cloud GitEE·地址 https://gitee.com/cicadasmile/husky-spring-cloud ``` ![](https://img2018.cnblogs.com/blog/1691717/201908/1691717-20190823075428183-1996768914.png) **推薦文章:微服務基礎系列** |序號|文章標題| |:---:|:---| |01|[微服務基礎:Eureka元件,管理服務註冊發現](https://mp.weixin.qq.com/s/cbEnCOhgo-5wGFX-GAUQtg)| |02|[微服務基礎:Ribbon和Feign元件,實現請求負載均衡](https://mp.weixin.qq.com/s/yHCC-MwFtDda_y817CV2XA)| |03|[微服務基礎:Hystrix元件,實現服務熔斷](https://mp.weixin.qq.com/s/pDrda8tBbNfReWVQrzal6w)| |04|[微服務基礎:Turbine元件,實現微服務叢集監控](https://mp.weixin.qq.com/s/-PPL5jwe4OdoBq7kQwePKA)| |05|[微服務基礎:Zuul元件,實現路由閘道器控制](https://mp.weixin.qq.com/s/A7xiIp9EG62_1y-F23TATg)| |06|[微服務基礎:Config元件,實現配置統一管理](https://mp.weixin.qq.com/s/_WZ1r0Kas5yMMPfwZ4MRUw)| |07|[微服務基礎:Zipkin元件,實現請求鏈路追蹤](https://mp.weixin.qq.com/s/p3p3Wi72rJngqMz4FSICBQ)| |08|[微服務基礎:與Dubbo框架、Boot框架對比分析](https://mp.weixin.qq.com/s/RC8F_D1J75XEv7oR7xdK5Q)| |09|[微服務基礎:Nacos元件,服務和配置管理](https://mp.weixin.qq.com/s/adwfdDGg9DQleYLECA8raQ)| |10|[微服務基礎:Sentinel元件,服務限流和降級](https://mp.weixin.qq.com/s/L_Q9PyPKngmCx-c94o0UmA)| |11|[微服務應用:分庫分表模式下,資料庫擴容方案](https://mp.weixin.qq.com/s/yCRwHGUd7xzQeEhoXFeO-w)| |12|[微服務應用:Shard-Jdbc分庫分表,擴容方案實現](https://mp.weixin.qq.com/s/QHF4qFP0JUhmievl