前言
歡迎閱讀往期系列：
在微服務(wù)大行其道的今天，服務(wù)的粒度被拆分得非常細，隨之而來的是服務(wù)數(shù)量的迅速增長。在云原生的浪潮中，服務(wù)治理更多情況下與容器調(diào)度平臺結(jié)合，共同形成一站式的自動化調(diào)度治理平臺。
當然無論是否使用基于容器的調(diào)度系統(tǒng)，服務(wù)治理的原理和范疇都不會發(fā)生改變，只是實現(xiàn)方式不同而已。
服務(wù)治理主要包括服務(wù)發(fā)現(xiàn)、負載均衡、限流、熔斷、超時、重試、服務(wù)追蹤等。我們今天要講的，就是服務(wù)發(fā)現(xiàn)的內(nèi)容。
本章概要
本章主要介紹以下內(nèi)容：
- 什么是服務(wù)發(fā)現(xiàn)？(what)
- 微服務(wù)框架下為什么需要服務(wù)發(fā)現(xiàn)呢？(why)
- 服務(wù)發(fā)現(xiàn)是怎么運作的呢？(how)
- CAP定理
- 現(xiàn)有的幾種解決方案介紹 (implementations)
現(xiàn)在，讓我們開始本次的旅程吧。
什么是服務(wù)發(fā)現(xiàn)（what）
服務(wù)發(fā)現(xiàn)指的是尋找一個service provider的 網(wǎng)絡(luò)位置信息。
具體指的是，使用一個注冊中心來記錄分布式系統(tǒng)中全部服務(wù)的信息，以便讓其他服務(wù)能夠快速找到這些已經(jīng)注冊的服務(wù)。
服務(wù)發(fā)現(xiàn)是支撐大規(guī)模SOA和微服務(wù)架構(gòu)的核心模塊，需要具有服務(wù)注冊、服務(wù)查找、服務(wù)健康檢查和服務(wù)變更通知等關(guān)鍵功能。
為什么需要服務(wù)發(fā)現(xiàn)？（why）
因為沒有服務(wù)發(fā)現(xiàn)模塊的話，服務(wù)網(wǎng)絡(luò)位置信息的配置會耦合在具體服務(wù)消費者的配置當中，從而導致系統(tǒng)難以維護。
想想這么一個基本的問題：服務(wù)消費者們是如何知道服務(wù)提供者的IP和端口的呢？
在簡單的體系架構(gòu)中，靜態(tài)配置（比如DNS、Nignx負載均衡配置等）的方法可以很好的解決問題。每個服務(wù)都部署在同一個位置，并且很少更改。沒有彈性伸縮的需求。傳統(tǒng)的單體式應(yīng)用的網(wǎng)絡(luò)地址發(fā)生變化的概率較小，在發(fā)生變化的時候，運維人員手動更新、加載配置文件即可。
但是在微服務(wù)架構(gòu)中并非如此，微服務(wù)更新、發(fā)布頻繁，并且經(jīng)常會根據(jù)負載情況進行彈性伸縮，因為微服務(wù)應(yīng)用實例的網(wǎng)絡(luò)地址變化是一個很常態(tài)的事情，而我們前面提到的靜態(tài)配置的解決方案，顯然不適合這么一個高度動態(tài)的場景。所以，我們需要提供一種機制（模塊），讓服務(wù)消費者在服務(wù)提供者的IP地址發(fā)生變化的時候能夠快速及時地獲取到最新的服務(wù)信息。
服務(wù)發(fā)現(xiàn)是怎么運作的呢？(how)
前面說過，使用一個注冊中心來記錄分布式系統(tǒng)中全部服務(wù)的信息，以便讓其他服務(wù)能夠快速找到這些已經(jīng)注冊的服務(wù)。
讓我們用兩個例子來說明服務(wù)發(fā)現(xiàn)運作的機制（簡單版本）：
-
biz service啟動，告訴服務(wù)中心它的服務(wù)信息，服務(wù)中心完成寫入 -
admin service啟動，向服務(wù)中心請求biz service的服務(wù)信息 - 服務(wù)中心查找對應(yīng)服務(wù)的位置信息，返回給
admin service -
admin service獲取到實際的地址之后，向biz service發(fā)起請求
當 biz service采用集群架構(gòu)，有更多的節(jié)點上線時，整個工作流是怎么樣的呢？
新啟動的節(jié)點告訴服務(wù)注冊發(fā)現(xiàn)中心自己的服務(wù)信息，服務(wù)中心完成寫入
-
admin service發(fā)起請求更新biz service的服務(wù)地址列表這里舉的是client端主動請求去更新信息，是“pull”的方式；還有一種是client端注冊回調(diào)，等待服務(wù)中心通知，是"push"的方式）
CAP 定理
雖然“服務(wù)發(fā)現(xiàn)”的整個運行機制理解起來很簡單，但是在實際的分布式場景下，作為微服務(wù)架構(gòu)體系的一個核心，我們肯定需要采用搭建集群的方式，保證其高可用性。這時候，就需要考慮一個分布式系統(tǒng)可能會遇到的一些問題。
在一個分布式的計算機系統(tǒng)中，只能同時滿足一致性（Consistency）、可用性（Availability）和分區(qū)容錯性（Partition tolerance）這三個基本特性中的兩個，這就是著名的CAP定理。
一致性：指的是所有節(jié)點都能夠在同一時間返回同一份最新的數(shù)據(jù)副本；
可用性：指的是每次請求都能夠返回非錯誤的響應(yīng)；
分區(qū)容錯性：指的是服務(wù)器間的通信即使在一定時間內(nèi)無法保持暢通也不會影響系統(tǒng)繼續(xù)運行。
對于分布式系統(tǒng)來說，分區(qū)容錯性是必須滿足的。因此，必須要在一致性和可用性之間進行取舍，這就是所謂的“選擇AP還是選擇CP”。
對CAP定理不熟悉的童鞋，可以延伸閱讀 - CAP定理
對于服務(wù)發(fā)現(xiàn)和注冊中心集群來說，如果選擇一致性而犧牲可用性（選擇CP）的話，那么為了保證多點服務(wù)中心上的數(shù)據(jù)一致，一旦某個點的服務(wù)中心宕機，服務(wù)中心集群都需要暫停對外提供數(shù)據(jù)寫入服務(wù)。在保證服務(wù)中心集群的數(shù)據(jù)一致的同時，犧牲了寫入服務(wù)的可用性。
如果選擇可用性而犧牲一致性（選擇AP）的話，那么為了保證服務(wù)不中斷，當某個點的服務(wù)中心宕機時，仍然存活的服務(wù)中心節(jié)點可以選擇先將數(shù)據(jù)寫入本地存儲然后直接返回客戶端，但這樣又將導致多個節(jié)點之間的數(shù)據(jù)不一致。
業(yè)界提供的用于服務(wù)發(fā)現(xiàn)注冊的系統(tǒng)，本質(zhì)上都是滿足AP或CP的系統(tǒng)。
現(xiàn)有的解決方案 (implementations)
在分布式服務(wù)體系中，所有的服務(wù)提供者和消費者都依賴于【服務(wù)中心】，如果服務(wù)中心出現(xiàn)問題，將會出現(xiàn)服務(wù)狀態(tài)感知不敏感等現(xiàn)象，且波及整個系統(tǒng)。因此，保證用于服務(wù)發(fā)現(xiàn)的注冊中心的可用性至關(guān)重要。
為保證注冊中心的可用性，要保證多節(jié)點部署，如果是大型網(wǎng)站后臺通常還要跨多機房進行部署，以確保注冊中心在單一機房不可用的情況下仍然可以提供服務(wù)。
具有高可用特性的服務(wù)中心需要具備以下幾個能力：
- 具有多節(jié)點部署的能力
- 在分布式場景下具備自我治愈和調(diào)整的能力
- 節(jié)點健康檢查的能力，可以將訪問超時的節(jié)點從當前集群中移除，也可以將恢復訪問能力后的節(jié)點再度加入當前集群
在下面的章節(jié)中，我們將介紹幾個常見的可直接作為注冊中心的產(chǎn)品。
Zookeeper
Zookeeper 致力于提供一個高可用且具有嚴格順序訪問控制能力的分布式協(xié)調(diào)系統(tǒng)，它是一個分布式數(shù)據(jù)一致性的解決方案。
ZooKeeper 提供了分布式通知和協(xié)調(diào)、配置管理、命名服務(wù)、主節(jié)點選舉、分布式鎖、分布式隊列等完善的解決方案。其中分布式通知和協(xié)調(diào)被廣泛用于服務(wù)發(fā)現(xiàn)。至今為止，它是服務(wù)發(fā)現(xiàn)領(lǐng)域歷史最為悠久、使用最為廣泛的產(chǎn)品。
本文不具體介紹Zookeeper的一致性協(xié)議、數(shù)據(jù)結(jié)構(gòu)等知識，有興趣的可以閱讀作者之前的Zookeeper文章
Zookeeper學習系列【一】 教會你Zookeeper的一些基礎(chǔ)概念
Zookeeper學習系列【三】Zookeeper 集群架構(gòu)、讀寫機制以及一致性原理(ZAB協(xié)議)
Zookeeper的讀寫機制和一致性協(xié)議決定了它是一個CP系統(tǒng)。
優(yōu)勢與不足
ZooKeeper 作為使用最為廣泛的分布式協(xié)調(diào)組件，優(yōu)點非常多。使用廣泛就是它最大的優(yōu)點，這也使得ZooKeeper很容易在架構(gòu)師進行技術(shù)選型時占據(jù)優(yōu)勢。但是，需要明確說明的是，Zookeeper并不是服務(wù)發(fā)現(xiàn)領(lǐng)域的最佳選擇了，它的優(yōu)勢主要體現(xiàn)在選舉和分布式鎖等分布式強一致性的場景中。
當ZooKeeper的主節(jié)點因為網(wǎng)絡(luò)故障與其他節(jié)點失去聯(lián)系而觸發(fā)整個系統(tǒng)選舉時，集群是不可用的，這將導致注冊服務(wù)體系在選舉期間癱瘓。
服務(wù)中心對數(shù)據(jù)一致性的要求并不是非?？量痰?，也難于做到實時感知宕機（會有時延），它更看重的是自愈能力。通過Zookeeper的客戶端Curator的緩存能力能夠讓ZooKeeper在服務(wù)發(fā)現(xiàn)領(lǐng)域的適配度更高，但這并非ZooKeeper的原生能力和設(shè)計初衷。
etcd
隨著CoreOS和Kubernetes等項目在開源社區(qū)日益火熱，它們項目中都用到的etcd組件作為一個高可用、強一致性的服務(wù)發(fā)現(xiàn)存儲倉庫，漸漸走進開發(fā)人員的視野。
etcd 是一個受到Zookeeper啟發(fā)的項目，和其具有類似的架構(gòu)和功能，基于更為簡單易懂的Raft協(xié)議和go語言實現(xiàn)。etcd也是一個CP的系統(tǒng)，對一致性的要求強于可用性的要求。etcd通過TTL(Time To Live，存活時間)來實現(xiàn)類似于Zookeeper臨時節(jié)點的功能，需要etcd客戶端不斷地定時續(xù)租節(jié)點來判斷服務(wù)的運行狀態(tài)。
具體可以閱讀下面的延伸文章。
延伸閱讀 etcd：從應(yīng)用場景到實現(xiàn)原理的全方位解讀
官網(wǎng)：https://etcd.io/
再介紹一篇高質(zhì)量的etcd實現(xiàn)原理解讀的文章：高可用分布式存儲 etcd 的實現(xiàn)原理
相比Zookeeper，etcd還具有以下優(yōu)點：
- 簡單。使用 Go 語言編寫部署簡單；使用 HTTP 作為接口使用簡單；使用 Raft 算法保證強一致性讓用戶易于理解。
- 數(shù)據(jù)持久化。etcd 默認數(shù)據(jù)一更新就進行持久化。
- 安全。etcd 支持 SSL 客戶端安全認證。
Eureka
Eureka由Netflix公司開源，主要用于定位AWS域的中間層服務(wù)。由于Eureka被用作Spring Cloud的注冊中心，因此受到了廣泛的關(guān)注。Eureka由服務(wù)器和客戶端這兩個組件組成。Eureka服務(wù)器一般用作服務(wù)注冊服務(wù)器，Eureka客戶端用來簡化與服務(wù)器的交互，作為輪詢負載均衡器提供對服務(wù)故障切換的支持。
Eureka比ZooKeeper這類的CP系統(tǒng)更加適合作為服務(wù)發(fā)現(xiàn)體系中的注冊中心。Eureka優(yōu)先保證了可用性，它采用了去中心化的設(shè)計理念，整個服務(wù)集群由對等節(jié)點組成，無須像ZooKeeper那樣選舉主節(jié)點。集群中失效的節(jié)點不會影響正常節(jié)點對外提供服務(wù)注冊和服務(wù)查詢能力。
Eureka客戶端有失效轉(zhuǎn)移的能力，如果在向某個Eureka服務(wù)器注冊服務(wù)時發(fā)現(xiàn)連接失敗，則會自動切換至其他節(jié)點。因此，只要有一臺Eureka服務(wù)器節(jié)點還能夠正常工作，就無須擔心注冊中心的可用性。但是，保證可用性必然造成數(shù)據(jù)一致性的缺失，客戶端查詢到的信息不一定是最新的。
Eureka 2.X 雖然已經(jīng)宣布不再維護，但是其目前的功能已經(jīng)非常穩(wěn)定，就算不升級，服務(wù)注冊/發(fā)現(xiàn)這些功能已經(jīng)夠用
Consul
Consul 來源于HashiCorp的產(chǎn)品，提供了一些列特性，包括服務(wù)發(fā)現(xiàn)、更豐富的健康檢查（內(nèi)存、磁盤使用情況等細粒度服務(wù)狀態(tài)檢測功能）、鍵值對存儲功能以及多數(shù)據(jù)中心（官網(wǎng)描述的四個主要特色）。和其他方案比較起來，具有“一站式”的特點。
Consul 使用 Go 語言編寫，因此具有天然可移植性(支持Linux、windows和Mac OS X)；安裝包僅包含一個可執(zhí)行文件，方便部署，與 Docker 等輕量級容器可無縫配合。
和etcd一樣， Consul基于 raft 協(xié)議，要求必須過半數(shù)的節(jié)點都寫入成功才認為注冊成功 Leader 掛掉時，重新選舉期間整個 Consul 不可用。保證了強一致性但犧牲了可用性。
作者本人對Consul研究并不多，感興趣的讀者可以自行查閱相關(guān)的文檔進行學習。
官網(wǎng)：https://www.consul.io/
Nacos
Nacos 是我們國內(nèi)阿里巴巴的新開源項目，其核心定位是 “一個更易于幫助構(gòu)建云原生應(yīng)用的動態(tài)服務(wù)發(fā)現(xiàn)、配置和服務(wù)管理平臺”。（通俗的理解就是，注冊中心 + 配置中心）
服務(wù)（Service）是 Nacos 世界的一等公民。Nacos 支持幾乎所有主流類型的“服務(wù)”的發(fā)現(xiàn)、配置和管理：
Kubernetes Service
gRPC & Dubbo RPC Service
Spring Cloud RESTful Service
Nacos 的關(guān)鍵特性包括:
- 服務(wù)發(fā)現(xiàn)和服務(wù)健康監(jiān)測
- 動態(tài)配置服務(wù)
- 動態(tài) DNS 服務(wù)
- 服務(wù)及其元數(shù)據(jù)管理
更多的內(nèi)容，請延伸閱讀Nacos的官方文檔：
小結(jié)
本章介紹了服務(wù)發(fā)現(xiàn)相關(guān)的一些知識，和目前市面上比較流行的服務(wù)注冊中心的相關(guān)特性，希望能對你有所啟發(fā)。
我們下期再會。
參考文章
- Service Discovery in a Microservices Architecture
- Microservices: Service Registration and Discovery
- Service Discovery
- https://nacos.io/zh-cn/
- etcd：從應(yīng)用場景到實現(xiàn)原理的全方位解讀
- 《從服務(wù)化到云原生》
- 《微服務(wù)設(shè)計》
如果本文有幫助到你，希望能點個贊，這是對我的最大動力。
