微服務技術棧：常見註冊中心組件，對比分析

本文源碼：GitHub·點這裏 || GitEE·點這裏

1、註冊中心簡介

一、基礎概念

在分佈式架構的系統中註冊中心這個概念就已經被提出了，最經典的就是Zookeeper中間件。

微服務架構中，註冊中心是最核心的基礎服務之一，註冊中心能夠看作是微服務架構中的通訊中心，當一個服務去請求另外一個服務時，經過註冊中心能夠獲取該服務的狀態，地址等核心信息。

服務註冊主要關係到三大角色：服務提供者、服務消費者、註冊中心。

二、流程和原理

基礎流程

• 服務啓動時，將自身的網絡地址等信息註冊到註冊中心，註冊中心記錄服務註冊數據。
• 服務消費者從註冊中心獲取服務提供者的地址，並經過地址和基於特定的方式調用服務提供者的接口。
• 各個服務與註冊中心使用必定機制通訊。若是註冊中心與服務長時間沒法通訊，就會註銷該實例，這也稱爲服務下線，當服務從新鏈接以後，會基於必定的策略在線上線。
• 服務地址相關信息發生變化時，會從新註冊到註冊中心。這樣，服務消費者就無需手工維護提供者的相關配置。

核心功能

經過上面的基本流程，不難發現一個註冊中心須要具有哪些核心功能：

• 服務發現

服務發現是指服務在啓動後，註冊到註冊中心，服務方提供自身的元數據，好比IP地址、端口、運行情況指標的Uri 、主頁地址等信息。

• 服務記錄

記錄註冊中心的服務的信息，例如服務名稱、IP地址、端口等。服務消費方基於查詢獲取可用的服務實例列表。

• 動態管理服務

註冊中心基於特定的機制定時測試已註冊的服務，例如：默認的狀況下會每隔30秒發送一次心跳來進行服務續約。經過服務續約來告知Server該Client仍然可用。正常狀況下，若是Server在90 秒內沒有收到Client 的心跳，Server會將Client 實例從註冊列表中刪除。

2、基礎組件對比

一、Zookeeper組件

1.1基礎描述

ZooKeeper是很是經典的服務註冊中心中間件，在國內環境下，因爲受到Dubbo框架的影響，大部分狀況下認爲Zookeeper是RPC服務框架下注冊中心最好選擇，隨着Dubbo框架的不斷開發優化，和各類註冊中心組件的誕生，即便是RPC框架，如今的註冊中心也逐步放棄了ZooKeeper。在經常使用的開發集羣環境中，ZooKeeper依然起到十分重要的做用，Java體系中，大部分的集羣環境都是依賴ZooKeeper管理服務的各個節點。

1.2組件特色

從Zookeeper的數據結構特色看，並非基於服務註冊而設計的，ZooKeeper提供的命名空間與文件系統的名稱空間很是類似，在數據結構上高度抽象爲K-V格式，十分通用，說到這裏不得不提一下Redis，也能夠做爲註冊中心使用，只是用的很少。

ZooKeeper組件支持節點短暫存在，只要建立znode的會話處於活動狀態，這些znode就會存在，會話結束時，將刪除znode。Dubbo框架正是基於這個特色，服務啓動往Zookeeper註冊的就是臨時節點，須要定時發心跳到Zookeeper來續約節點，並容許服務下線時，將Zookeeper上相應的節點刪除，同時Zookeeper使用ZAB協議雖然保證了數據的強一致性。

二、Eureka組件

2.1基礎描述

SpringCloud框架生態中最原生的深度結合組件，Eureka是Netflix開發的服務發現框架，基於REST的服務，主要用於服務註冊，管理，負載均衡和服務故障轉移。可是官方聲明在Eureka2.0版本中止維護，不建議使用。

2.2組件特色

Eureka包含兩個組件：EurekaServer和EurekaClient。

EurekaServer提供服務註冊服務，各個節點啓動後，會在EurekaServer中進行註冊，這樣EurekaServer中的服務註冊表中將會存儲全部可用服務節點的信息，服務節點的信息能夠在界面中直觀的看到。Eureka容許在註冊服務的時候，自定義實現檢查自身狀態的是否健康的方法，這在服務實例可以保持心跳上報的場景下，是一種比較好的體驗。

EurekaClient是一個java客戶端，用於簡化與EurekaServer的交互，客戶端同時也就是一個內置的、使用輪詢(round-robin)負載算法的負載均衡器。

三、Consul組件

3.1基礎描述

Consul是用於服務發現和配置的工具。Consul是分佈式的，高度可用的，而且具備極高的可伸縮性，並且開發使用都很簡便。它提供了一個功能齊全的控制面板，主要特色是：服務發現、健康檢查、鍵值存儲、安全服務通訊、多數據中心、ServiceMesh。Consul在設計上把不少分佈式服務治理上要用到的功能都包含在內了。

3.2組件特色

Consul提供多個數據中心的支持，基於Fabio作負載均衡，每一個數據中心內，都有客戶端和服務端的混合構成。預計有三到五臺服務端。能夠在失敗和性能的可用性之間取得良好的平衡。數據中心中的全部節點都參與八卦協議。這意味着有一個八卦池，其中包含給定數據中心的全部節點。這有幾個目的：首先，不須要爲客戶端配置服務器的地址;發現是自動完成的。其次，檢測節點故障的工做不是放在服務器上，而是分佈式的。這使得故障檢測比天真的心跳方案更具可擴展性。第三，它被用做消息傳遞層，用於在諸如領導者選舉等重要事件發生時進行通知。

四、Nacos組件

4.1基礎描述

Nacos致力於發現、配置和管理微服務。Nacos提供了一組簡單易用的特性集，幫助您實現動態服務發現、服務配置管理、服務及流量管理。Nacos更敏捷和容易地構建、交付和管理微服務平臺。 Nacos 是構建以「服務」爲中心的現代應用架構(例如微服務範式、雲原生範式)的服務基礎設施。Nacos支持做爲RPC註冊中心，例如：支持Dubbo框架；也具有微服務註冊中心的能力，例如：SpringCloud框架。

4.2組件特色

Nacos在通過多年生產經驗後提煉出的數據模型，則是一種服務-集羣-實例的三層模型。如上文所說，這樣基本能夠知足服務在全部場景下的數據存儲和管理,數據模型雖然相對複雜，可是並不強制使用數據結構的風格，大多數應用場景下，和Eureka數據模型是相似的。

Nacos提供數據邏輯隔離模型，用戶帳號能夠新建多個命名空間，每一個命名空間對應一個客戶端實例，這個命名空間對應的註冊中心物理集羣是能夠根據規則進行路由的，這樣可讓註冊中心內部的升級和遷移對用戶是無感知的。

3、組件選擇

以下注冊中心對比圖。

綜合上述幾種註冊中心對比，再從如今SpringCloud框架流行趨勢看，我的推薦後續微服務架構體系選擇Nacos組件，大體緣由以下，社區活躍，通過大規模業務驗證，不但能夠做爲微服務註冊中心，也支持做RPC框架Dubbo的註冊中心，且有完善的中文文檔，總結下來就一句話：通用中間件，省時；文檔詳細，省心。

4、源代碼地址

GitHub·地址
https://github.com/cicadasmile/husky-spring-cloud
GitEE·地址
https://gitee.com/cicadasmile/husky-spring-cloud

推薦文章：微服務基礎系列

序號	文章標題
01	微服務基礎：Eureka組件，管理服務註冊發現
02	微服務基礎：Ribbon和Feign組件，實現請求負載均衡
03	微服務基礎：Hystrix組件，實現服務熔斷
04	微服務基礎：Turbine組件，實現微服務集羣監控
05	微服務基礎：Zuul組件，實現路由網關控制
06	微服務基礎：Config組件，實現配置統一管理
07	微服務基礎：Zipkin組件，實現請求鏈路追蹤
08	微服務基礎：與Dubbo框架、Boot框架對比分析
09	微服務基礎：Nacos組件，服務和配置管理
10	微服務基礎：Sentinel組件，服務限流和降級
11	微服務應用：分庫分表模式下，數據庫擴容方案
12	微服務應用：Shard-Jdbc分庫分表，擴容方案實現