微服務設計學習（三）服務治理之服務註冊與發現

前言

歡迎閱讀往期系列：

• 微服務設計學習（一）關於微服務和如何建模服務
• 微服務設計學習（二）關於服務的集成

在微服務大行其道的今天，服務的粒度被拆分得很是細，隨之而來的是服務數量的迅速增加。在雲原生的浪潮中，服務治理更多狀況下與容器調度平臺結合，共同造成一站式的自動化調度治理平臺。

固然不管是否使用基於容器的調度系統，服務治理的原理和範疇都不會發生改變，只是實現方式不一樣而已。

服務治理主要包括服務發現、負載均衡、限流、熔斷、超時、重試、服務追蹤等。咱們今天要講的，就是服務發現的內容。

本章概要

本章主要介紹如下內容：

1. 什麼是服務發現？(what)
2. 微服務框架下爲何須要服務發現呢？(why)
3. 服務發現是怎麼運做的呢？(how)
4. CAP定理
5. 現有的幾種解決方案介紹 (implementations)

如今，讓咱們開始本次的旅程吧。

什麼是服務發現（what）

服務發現指的是尋找一個service provider的 網絡位置信息。

具體指的是，使用一個註冊中心來記錄分佈式系統中所有服務的信息，以便讓其餘服務可以快速找到這些已經註冊的服務。

服務發現是支撐大規模SOA和微服務架構的核心模塊，須要具備服務註冊、服務查找、服務健康檢查和服務變動通知等關鍵功能。

爲何須要服務發現？（why）

由於沒有服務發現模塊的話，服務網絡位置信息的配置會耦合在具體服務消費者的配置當中，從而致使系統難以維護。

想一想這麼一個基本的問題：服務消費者們是如何知道服務提供者的IP和端口的呢？

在簡單的體系架構中，靜態配置（好比DNS、Nignx負載均衡配置等）的方法能夠很好的解決問題。每一個服務都部署在同一個位置，而且不多更改。沒有彈性伸縮的需求。傳統的單體式應用的網絡地址發生變化的機率較小，在發生變化的時候，運維人員手動更新、加載配置文件便可。

可是在微服務架構中並不是如此，微服務更新、發佈頻繁，而且常常會根據負載狀況進行彈性伸縮，由於微服務應用實例的網絡地址變化是一個很常態的事情，而咱們前面提到的靜態配置的解決方案，顯然不適合這麼一個高度動態的場景。因此，咱們須要提供一種機制（模塊），讓服務消費者在服務提供者的IP地址發生變化的時候可以快速及時地獲取到最新的服務信息。

服務發現是怎麼運做的呢？(how)

前面說過，使用一個註冊中心來記錄分佈式系統中所有服務的信息，以便讓其餘服務可以快速找到這些已經註冊的服務。

讓咱們用兩個例子來講明服務發現運做的機制（簡單版本）：

1. biz service啓動，告訴服務中心它的服務信息，服務中心完成寫入
2. admin service啓動，向服務中心請求biz service的服務信息
3. 服務中心查找對應服務的位置信息，返回給admin service
4. admin service獲取到實際的地址以後，向biz service發起請求

當 biz service採用集羣架構，有更多的節點上線時，整個工做流是怎麼樣的呢？

1. 新啓動的節點告訴服務註冊發現中心本身的服務信息，服務中心完成寫入

2. admin service發起請求更新 biz service的服務地址列表

   這裏舉的是client端主動請求去更新信息，是「pull」的方式；還有一種是client端註冊回調，等待服務中心通知，是"push"的方式）

CAP 定理

雖然「服務發現」的整個運行機制理解起來很簡單，可是在實際的分佈式場景下，做爲微服務架構體系的一個核心，咱們確定須要採用搭建集羣的方式，保證其高可用性。這時候，就須要考慮一個分佈式系統可能會遇到的一些問題。

在一個分佈式的計算機系統中，只能同時知足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）這三個基本特性中的兩個，這就是著名的CAP定理。

• 一致性：指的是全部節點都可以在同一時間返回同一份最新的數據副本；
• 可用性：指的是每次請求都可以返回非錯誤的響應；
• 分區容錯性：指的是服務器間的通訊即便在必定時間內沒法保持暢通也不會影響系統繼續運行。

對於分佈式系統來講，分區容錯性是必須知足的。所以，必需要在一致性和可用性之間進行取捨，這就是所謂的「選擇AP仍是選擇CP」。

對CAP定理不熟悉的童鞋，能夠延伸閱讀 - CAP定理

對於服務發現和註冊中心集羣來講，若是選擇一致性而犧牲可用性（選擇CP）的話，那麼爲了保證多點服務中心上的數據一致，一旦某個點的服務中心宕機，服務中心集羣都須要暫停對外提供數據寫入服務。在保證服務中心集羣的數據一致的同時，犧牲了寫入服務的可用性。
若是選擇可用性而犧牲一致性（選擇AP）的話，那麼爲了保證服務不中斷，當某個點的服務中心宕機時，仍然存活的服務中心節點能夠選擇先將數據寫入本地存儲而後直接返回客戶端，但這樣又將致使多個節點之間的數據不一致。

業界提供的用於服務發現註冊的系統，本質上都是知足AP或CP的系統。

現有的解決方案 (implementations)

在分佈式服務體系中，全部的服務提供者和消費者都依賴於【服務中心】，若是服務中心出現問題，將會出現服務狀態感知不敏感等現象，且波及整個系統。所以，保證用於服務發現的註冊中心的可用性相當重要。
爲保證註冊中心的可用性，要保證多節點部署，若是是大型網站後臺一般還要跨多機房進行部署，以確保註冊中心在單一機房不可用的狀況下仍然能夠提供服務。
具備高可用特性的服務中心須要具有如下幾個能力：

1. 具備多節點部署的能力
2. 在分佈式場景下具有自我治癒和調整的能力
3. 節點健康檢查的能力，能夠將訪問超時的節點從當前集羣中移除，也能夠將恢復訪問能力後的節點再度加入當前集羣

在下面的章節中，咱們將介紹幾個常見的可直接做爲註冊中心的產品。

Zookeeper

Zookeeper 致力於提供一個高可用且具備嚴格順序訪問控制能力的分佈式協調系統，它是一個分佈式數據一致性的解決方案。

ZooKeeper 提供了分佈式通知和協調、配置管理、命名服務、主節點選舉、分佈式鎖、分佈式隊列等完善的解決方案。其中分佈式通知和協調被普遍用於服務發現。至今爲止，它是服務發現領域歷史最爲悠久、使用最爲普遍的產品。

本文不具體介紹Zookeeper的一致性協議、數據結構等知識，有興趣的能夠閱讀做者以前的Zookeeper文章

Zookeeper學習系列【一】 教會你Zookeeper的一些基礎概念
Zookeeper學習系列【三】Zookeeper 集羣架構、讀寫機制以及一致性原理(ZAB協議)

Zookeeper的讀寫機制和一致性協議決定了它是一個CP系統。

優點與不足

ZooKeeper 做爲使用最爲普遍的分佈式協調組件，優勢很是多。使用普遍就是它最大的優勢，這也使得ZooKeeper很容易在架構師進行技術選型時佔據優點。可是，須要明確說明的是，Zookeeper並非服務發現領域的最佳選擇了，它的優點主要體如今選舉和分佈式鎖等分佈式強一致性的場景中。
當ZooKeeper的主節點由於網絡故障與其餘節點失去聯繫而觸發整個系統選舉時，集羣是不可用的，這將致使註冊服務體系在選舉期間癱瘓。

延伸閱讀 阿里巴巴爲何不用 ZooKeeper 作服務發現？

服務中心對數據一致性的要求並非很是苛刻的，也難於作到實時感知宕機（會有時延），它更看重的是自愈能力。經過Zookeeper的客戶端Curator的緩存能力可以讓ZooKeeper在服務發現領域的適配度更高，但這並不是ZooKeeper的原生能力和設計初衷。

etcd

隨着CoreOS和Kubernetes等項目在開源社區日益火熱，它們項目中都用到的etcd組件做爲一個高可用、強一致性的服務發現存儲倉庫，漸漸走進開發人員的視野。

etcd 是一個受到Zookeeper啓發的項目，和其具備相似的架構和功能，基於更爲簡單易懂的Raft協議和go語言實現。etcd也是一個CP的系統，對一致性的要求強於可用性的要求。etcd經過TTL(Time To Live，存活時間)來實現相似於Zookeeper臨時節點的功能，須要etcd客戶端不斷地定時續租節點來判斷服務的運行狀態。

具體能夠閱讀下面的延伸文章。

延伸閱讀 etcd：從應用場景到實現原理的全方位解讀

官網：https://etcd.io/

再介紹一篇高質量的etcd實現原理解讀的文章：高可用分佈式存儲 etcd 的實現原理

相比Zookeeper，etcd還具備如下優勢：

1. 簡單。使用 Go 語言編寫部署簡單；使用 HTTP 做爲接口使用簡單；使用 Raft 算法保證強一致性讓用戶易於理解。
2. 數據持久化。etcd 默認數據一更新就進行持久化。
3. 安全。etcd 支持 SSL 客戶端安全認證。

Eureka

Eureka由Netflix公司開源，主要用於定位AWS域的中間層服務。因爲Eureka被用做Spring Cloud的註冊中心，所以受到了普遍的關注。Eureka由服務器和客戶端這兩個組件組成。Eureka服務器通常用做服務註冊服務器，Eureka客戶端用來簡化與服務器的交互，做爲輪詢負載均衡器提供對服務故障切換的支持。

Eureka比ZooKeeper這類的CP系統更加適合做爲服務發現體系中的註冊中心。Eureka優先保證了可用性，它採用了去中心化的設計理念，整個服務集羣由對等節點組成，無須像ZooKeeper那樣選舉主節點。集羣中失效的節點不會影響正常節點對外提供服務註冊和服務查詢能力。
Eureka客戶端有失效轉移的能力，若是在向某個Eureka服務器註冊服務時發現鏈接失敗，則會自動切換至其餘節點。所以，只要有一臺Eureka服務器節點還可以正常工做，就無須擔憂註冊中心的可用性。可是，保證可用性必然形成數據一致性的缺失，客戶端查詢到的信息不必定是最新的。

Eureka 2.X 雖然已經宣佈再也不維護，可是其目前的功能已經很是穩定，就算不升級，服務註冊/發現這些功能已經夠用

Consul

Consul 來源於HashiCorp的產品，提供了一些列特性，包括服務發現、更豐富的健康檢查（內存、磁盤使用狀況等細粒度服務狀態檢測功能）、鍵值對存儲功能以及多數據中心（官網描述的四個主要特點）。和其餘方案比較起來，具備「一站式」的特色。

Consul 使用 Go 語言編寫，所以具備自然可移植性(支持Linux、windows和Mac OS X)；安裝包僅包含一個可執行文件，方便部署，與 Docker 等輕量級容器可無縫配合。

和etcd同樣， Consul基於 raft 協議，要求必須過半數的節點都寫入成功才認爲註冊成功 Leader 掛掉時，從新選舉期間整個 Consul 不可用。保證了強一致性但犧牲了可用性。

做者本人對Consul研究並很少，感興趣的讀者能夠自行查閱相關的文檔進行學習。

官網： https://www.consul.io/

Nacos

Nacos 是咱們國內阿里巴巴的新開源項目，其核心定位是 「一個更易於幫助構建雲原生應用的動態服務發現、配置和服務管理平臺」。（通俗的理解就是，註冊中心 + 配置中心）

服務（Service）是 Nacos 世界的一等公民。Nacos 支持幾乎全部主流類型的「服務」的發現、配置和管理：

• Kubernetes Service
• gRPC & Dubbo RPC Service
• Spring Cloud RESTful Service

Nacos 的關鍵特性包括:

• 服務發現和服務健康監測
• 動態配置服務
• 動態 DNS 服務
• 服務及其元數據管理

更多的內容，請延伸閱讀Nacos的官方文檔：

延伸閱讀 https://nacos.io/zh-cn/docs/w...

小結

本章介紹了服務發現相關的一些知識，和目前市面上比較流行的服務註冊中心的相關特性，但願能對你有所啓發。

咱們下期再會。

參考文章

1. Service Discovery in a Microservices Architecture
2. Microservices: Service Registration and Discovery
3. Service Discovery
4. https://nacos.io/zh-cn/
5. etcd：從應用場景到實現原理的全方位解讀
6. 《從服務化到雲原生》
7. 《微服務設計》

若是本文有幫助到你，但願能點個贊，這是對個人最大動力。