231123-1531926683e817.jpg

前言

歡迎閱讀往期系列：

• 微服務(wù)設(shè)計(jì)學(xué)習(xí)（一）關(guān)于微服務(wù)和如何建模服務(wù)
• 微服務(wù)設(shè)計(jì)學(xué)習(xí)（二）關(guān)于服務(wù)的集成

在微服務(wù)大行其道的今天，服務(wù)的粒度被拆分得非常細(xì)，隨之而來(lái)的是服務(wù)數(shù)量的迅速增長(zhǎng)钻心。在云原生的浪潮中伶选，服務(wù)治理更多情況下與容器調(diào)度平臺(tái)結(jié)合，共同形成一站式的自動(dòng)化調(diào)度治理平臺(tái)负蠕。

當(dāng)然無(wú)論是否使用基于容器的調(diào)度系統(tǒng)干像，服務(wù)治理的原理和范疇都不會(huì)發(fā)生改變帅腌，只是實(shí)現(xiàn)方式不同而已。

服務(wù)治理主要包括服務(wù)發(fā)現(xiàn)麻汰、負(fù)載均衡速客、限流、熔斷五鲫、超時(shí)溺职、重試、服務(wù)追蹤等。我們今天要講的浪耘，就是服務(wù)發(fā)現(xiàn)的內(nèi)容乱灵。

本章概要

本章主要介紹以下內(nèi)容：

1. 什么是服務(wù)發(fā)現(xiàn)？(what)
2. 微服務(wù)框架下為什么需要服務(wù)發(fā)現(xiàn)呢七冲？(why)
3. 服務(wù)發(fā)現(xiàn)是怎么運(yùn)作的呢痛倚？(how)
4. CAP定理
5. 現(xiàn)有的幾種解決方案介紹 (implementations)

現(xiàn)在，讓我們開(kāi)始本次的旅程吧澜躺。

什么是服務(wù)發(fā)現(xiàn)（what）

服務(wù)發(fā)現(xiàn)指的是尋找一個(gè)service provider的 網(wǎng)絡(luò)位置信息蝉稳。

具體指的是，使用一個(gè)注冊(cè)中心來(lái)記錄分布式系統(tǒng)中全部服務(wù)的信息掘鄙，以便讓其他服務(wù)能夠快速找到這些已經(jīng)注冊(cè)的服務(wù)耘戚。

服務(wù)發(fā)現(xiàn)是支撐大規(guī)模SOA和微服務(wù)架構(gòu)的核心模塊，需要具有服務(wù)注冊(cè)操漠、服務(wù)查找收津、服務(wù)健康檢查和服務(wù)變更通知等關(guān)鍵功能。

為什么需要服務(wù)發(fā)現(xiàn)颅夺？（why）

因?yàn)闆](méi)有服務(wù)發(fā)現(xiàn)模塊的話朋截，服務(wù)網(wǎng)絡(luò)位置信息的配置會(huì)耦合在具體服務(wù)消費(fèi)者的配置當(dāng)中，從而導(dǎo)致系統(tǒng)難以維護(hù)吧黄。

想想這么一個(gè)基本的問(wèn)題：服務(wù)消費(fèi)者們是如何知道服務(wù)提供者的IP和端口的呢？

在簡(jiǎn)單的體系架構(gòu)中唆姐，靜態(tài)配置（比如DNS拗慨、Nignx負(fù)載均衡配置等）的方法可以很好的解決問(wèn)題。每個(gè)服務(wù)都部署在同一個(gè)位置奉芦，并且很少更改赵抢。沒(méi)有彈性伸縮的需求。傳統(tǒng)的單體式應(yīng)用的網(wǎng)絡(luò)地址發(fā)生變化的概率較小声功，在發(fā)生變化的時(shí)候烦却，運(yùn)維人員手動(dòng)更新、加載配置文件即可先巴。

但是在微服務(wù)架構(gòu)中并非如此其爵，微服務(wù)更新、發(fā)布頻繁伸蚯，并且經(jīng)常會(huì)根據(jù)負(fù)載情況進(jìn)行彈性伸縮摩渺，因?yàn)槲⒎?wù)應(yīng)用實(shí)例的網(wǎng)絡(luò)地址變化是一個(gè)很常態(tài)的事情，而我們前面提到的靜態(tài)配置的解決方案剂邮，顯然不適合這么一個(gè)高度動(dòng)態(tài)的場(chǎng)景摇幻。所以，我們需要提供一種機(jī)制（模塊），讓服務(wù)消費(fèi)者在服務(wù)提供者的IP地址發(fā)生變化的時(shí)候能夠快速及時(shí)地獲取到最新的服務(wù)信息绰姻。

服務(wù)發(fā)現(xiàn)是怎么運(yùn)作的呢枉侧？(how)

前面說(shuō)過(guò)，使用一個(gè)注冊(cè)中心來(lái)記錄分布式系統(tǒng)中全部服務(wù)的信息狂芋，以便讓其他服務(wù)能夠快速找到這些已經(jīng)注冊(cè)的服務(wù)棵逊。

讓我們用兩個(gè)例子來(lái)說(shuō)明服務(wù)發(fā)現(xiàn)運(yùn)作的機(jī)制（簡(jiǎn)單版本）：

image.png

1. biz service啟動(dòng)，告訴服務(wù)中心它的服務(wù)信息银酗，服務(wù)中心完成寫(xiě)入
2. admin service啟動(dòng)辆影，向服務(wù)中心請(qǐng)求biz service的服務(wù)信息
3. 服務(wù)中心查找對(duì)應(yīng)服務(wù)的位置信息，返回給admin service
4. admin service獲取到實(shí)際的地址之后黍特，向biz service發(fā)起請(qǐng)求

當(dāng) biz service采用集群架構(gòu)蛙讥，有更多的節(jié)點(diǎn)上線時(shí)，整個(gè)工作流是怎么樣的呢灭衷？

image.png

1. 新啟動(dòng)的節(jié)點(diǎn)告訴服務(wù)注冊(cè)發(fā)現(xiàn)中心自己的服務(wù)信息次慢，服務(wù)中心完成寫(xiě)入

2. admin service發(fā)起請(qǐng)求更新 biz service的服務(wù)地址列表

   這里舉的是client端主動(dòng)請(qǐng)求去更新信息，是“pull”的方式翔曲；還有一種是client端注冊(cè)回調(diào)迫像，等待服務(wù)中心通知，是"push"的方式）

CAP 定理

雖然“服務(wù)發(fā)現(xiàn)”的整個(gè)運(yùn)行機(jī)制理解起來(lái)很簡(jiǎn)單瞳遍，但是在實(shí)際的分布式場(chǎng)景下闻妓，作為微服務(wù)架構(gòu)體系的一個(gè)核心，我們肯定需要采用搭建集群的方式掠械，保證其高可用性由缆。這時(shí)候，就需要考慮一個(gè)分布式系統(tǒng)可能會(huì)遇到的一些問(wèn)題猾蒂。

在一個(gè)分布式的計(jì)算機(jī)系統(tǒng)中均唉，只能同時(shí)滿足一致性（Consistency）、可用性（Availability）和分區(qū)容錯(cuò)性（Partition tolerance）這三個(gè)基本特性中的兩個(gè)肚菠，這就是著名的CAP定理舔箭。

• 一致性：指的是所有節(jié)點(diǎn)都能夠在同一時(shí)間返回同一份最新的數(shù)據(jù)副本；

• 可用性：指的是每次請(qǐng)求都能夠返回非錯(cuò)誤的響應(yīng)蚊逢；

• 分區(qū)容錯(cuò)性：指的是服務(wù)器間的通信即使在一定時(shí)間內(nèi)無(wú)法保持暢通也不會(huì)影響系統(tǒng)繼續(xù)運(yùn)行层扶。

undefined

對(duì)于分布式系統(tǒng)來(lái)說(shuō)，分區(qū)容錯(cuò)性是必須滿足的时捌。因此怒医，必須要在一致性和可用性之間進(jìn)行取舍，這就是所謂的“選擇AP還是選擇CP”奢讨。

對(duì)CAP定理不熟悉的童鞋稚叹，可以延伸閱讀 - CAP定理

對(duì)于服務(wù)發(fā)現(xiàn)和注冊(cè)中心集群來(lái)說(shuō)焰薄，如果選擇一致性而犧牲可用性（選擇CP）的話，那么為了保證多點(diǎn)服務(wù)中心上的數(shù)據(jù)一致扒袖，一旦某個(gè)點(diǎn)的服務(wù)中心宕機(jī)塞茅，服務(wù)中心集群都需要暫停對(duì)外提供數(shù)據(jù)寫(xiě)入服務(wù)。在保證服務(wù)中心集群的數(shù)據(jù)一致的同時(shí)季率，犧牲了寫(xiě)入服務(wù)的可用性野瘦。
如果選擇可用性而犧牲一致性（選擇AP）的話，那么為了保證服務(wù)不中斷飒泻，當(dāng)某個(gè)點(diǎn)的服務(wù)中心宕機(jī)時(shí)鞭光，仍然存活的服務(wù)中心節(jié)點(diǎn)可以選擇先將數(shù)據(jù)寫(xiě)入本地存儲(chǔ)然后直接返回客戶端，但這樣又將導(dǎo)致多個(gè)節(jié)點(diǎn)之間的數(shù)據(jù)不一致泞遗。

業(yè)界提供的用于服務(wù)發(fā)現(xiàn)注冊(cè)的系統(tǒng)惰许，本質(zhì)上都是滿足AP或CP的系統(tǒng)。

現(xiàn)有的解決方案 (implementations)

在分布式服務(wù)體系中史辙，所有的服務(wù)提供者和消費(fèi)者都依賴于【服務(wù)中心】汹买，如果服務(wù)中心出現(xiàn)問(wèn)題，將會(huì)出現(xiàn)服務(wù)狀態(tài)感知不敏感等現(xiàn)象聊倔，且波及整個(gè)系統(tǒng)晦毙。因此，保證用于服務(wù)發(fā)現(xiàn)的注冊(cè)中心的可用性至關(guān)重要耙蔑。
為保證注冊(cè)中心的可用性见妒，要保證多節(jié)點(diǎn)部署，如果是大型網(wǎng)站后臺(tái)通常還要跨多機(jī)房進(jìn)行部署纵潦，以確保注冊(cè)中心在單一機(jī)房不可用的情況下仍然可以提供服務(wù)徐鹤。
具有高可用特性的服務(wù)中心需要具備以下幾個(gè)能力：

1. 具有多節(jié)點(diǎn)部署的能力
2. 在分布式場(chǎng)景下具備自我治愈和調(diào)整的能力
3. 節(jié)點(diǎn)健康檢查的能力，可以將訪問(wèn)超時(shí)的節(jié)點(diǎn)從當(dāng)前集群中移除邀层，也可以將恢復(fù)訪問(wèn)能力后的節(jié)點(diǎn)再度加入當(dāng)前集群

在下面的章節(jié)中，我們將介紹幾個(gè)常見(jiàn)的可直接作為注冊(cè)中心的產(chǎn)品遂庄。

Zookeeper

Zookeeper 致力于提供一個(gè)高可用且具有嚴(yán)格順序訪問(wèn)控制能力的分布式協(xié)調(diào)系統(tǒng)寥院，它是一個(gè)分布式數(shù)據(jù)一致性的解決方案。

ZooKeeper 提供了分布式通知和協(xié)調(diào)涛目、配置管理秸谢、命名服務(wù)、主節(jié)點(diǎn)選舉霹肝、分布式鎖估蹄、分布式隊(duì)列等完善的解決方案。其中分布式通知和協(xié)調(diào)被廣泛用于服務(wù)發(fā)現(xiàn)沫换。至今為止臭蚁，它是服務(wù)發(fā)現(xiàn)領(lǐng)域歷史最為悠久、使用最為廣泛的產(chǎn)品。

undefined

本文不具體介紹Zookeeper的一致性協(xié)議垮兑、數(shù)據(jù)結(jié)構(gòu)等知識(shí)冷尉，有興趣的可以閱讀作者之前的Zookeeper文章

Zookeeper學(xué)習(xí)系列【一】 教會(huì)你Zookeeper的一些基礎(chǔ)概念
Zookeeper學(xué)習(xí)系列【三】Zookeeper 集群架構(gòu)、讀寫(xiě)機(jī)制以及一致性原理(ZAB協(xié)議)

Zookeeper的讀寫(xiě)機(jī)制和一致性協(xié)議決定了它是一個(gè)CP系統(tǒng)系枪。

優(yōu)勢(shì)與不足

ZooKeeper 作為使用最為廣泛的分布式協(xié)調(diào)組件雀哨，優(yōu)點(diǎn)非常多。使用廣泛就是它最大的優(yōu)點(diǎn)私爷，這也使得ZooKeeper很容易在架構(gòu)師進(jìn)行技術(shù)選型時(shí)占據(jù)優(yōu)勢(shì)雾棺。但是，需要明確說(shuō)明的是衬浑，Zookeeper并不是服務(wù)發(fā)現(xiàn)領(lǐng)域的最佳選擇了捌浩，它的優(yōu)勢(shì)主要體現(xiàn)在選舉和分布式鎖等分布式強(qiáng)一致性的場(chǎng)景中。
當(dāng)ZooKeeper的主節(jié)點(diǎn)因?yàn)榫W(wǎng)絡(luò)故障與其他節(jié)點(diǎn)失去聯(lián)系而觸發(fā)整個(gè)系統(tǒng)選舉時(shí)嚎卫，集群是不可用的嘉栓，這將導(dǎo)致注冊(cè)服務(wù)體系在選舉期間癱瘓。

延伸閱讀 阿里巴巴為什么不用 ZooKeeper 做服務(wù)發(fā)現(xiàn)拓诸？

服務(wù)中心對(duì)數(shù)據(jù)一致性的要求并不是非城值瑁苛刻的，也難于做到實(shí)時(shí)感知宕機(jī)（會(huì)有時(shí)延）奠支，它更看重的是自愈能力馋辈。通過(guò)Zookeeper的客戶端Curator的緩存能力能夠讓ZooKeeper在服務(wù)發(fā)現(xiàn)領(lǐng)域的適配度更高，但這并非ZooKeeper的原生能力和設(shè)計(jì)初衷倍谜。

etcd

隨著CoreOS和Kubernetes等項(xiàng)目在開(kāi)源社區(qū)日益火熱迈螟，它們項(xiàng)目中都用到的etcd組件作為一個(gè)高可用、強(qiáng)一致性的服務(wù)發(fā)現(xiàn)存儲(chǔ)倉(cāng)庫(kù)，漸漸走進(jìn)開(kāi)發(fā)人員的視野梭姓。

image.png

etcd 是一個(gè)受到Zookeeper啟發(fā)的項(xiàng)目臣疑，和其具有類似的架構(gòu)和功能，基于更為簡(jiǎn)單易懂的Raft協(xié)議和go語(yǔ)言實(shí)現(xiàn)洗搂。etcd也是一個(gè)CP的系統(tǒng)，對(duì)一致性的要求強(qiáng)于可用性的要求载弄。etcd通過(guò)TTL(Time To Live耘拇，存活時(shí)間)來(lái)實(shí)現(xiàn)類似于Zookeeper臨時(shí)節(jié)點(diǎn)的功能，需要etcd客戶端不斷地定時(shí)續(xù)租節(jié)點(diǎn)來(lái)判斷服務(wù)的運(yùn)行狀態(tài)宇攻。

具體可以閱讀下面的延伸文章惫叛。

延伸閱讀 etcd：從應(yīng)用場(chǎng)景到實(shí)現(xiàn)原理的全方位解讀

官網(wǎng)：https://etcd.io/

再介紹一篇高質(zhì)量的etcd實(shí)現(xiàn)原理解讀的文章：高可用分布式存儲(chǔ) etcd 的實(shí)現(xiàn)原理

相比Zookeeper，etcd還具有以下優(yōu)點(diǎn)：

1. 簡(jiǎn)單逞刷。使用 Go 語(yǔ)言編寫(xiě)部署簡(jiǎn)單嘉涌；使用 HTTP 作為接口使用簡(jiǎn)單妻熊；使用 Raft 算法保證強(qiáng)一致性讓用戶易于理解。
2. 數(shù)據(jù)持久化洛心。etcd 默認(rèn)數(shù)據(jù)一更新就進(jìn)行持久化固耘。
3. 安全。etcd 支持 SSL 客戶端安全認(rèn)證词身。

Eureka

Eureka由Netflix公司開(kāi)源厅目，主要用于定位AWS域的中間層服務(wù)。由于Eureka被用作Spring Cloud的注冊(cè)中心法严，因此受到了廣泛的關(guān)注损敷。Eureka由服務(wù)器和客戶端這兩個(gè)組件組成。Eureka服務(wù)器一般用作服務(wù)注冊(cè)服務(wù)器深啤，Eureka客戶端用來(lái)簡(jiǎn)化與服務(wù)器的交互拗馒，作為輪詢負(fù)載均衡器提供對(duì)服務(wù)故障切換的支持。

Eureka比ZooKeeper這類的CP系統(tǒng)更加適合作為服務(wù)發(fā)現(xiàn)體系中的注冊(cè)中心溯街。Eureka優(yōu)先保證了可用性诱桂，它采用了去中心化的設(shè)計(jì)理念，整個(gè)服務(wù)集群由對(duì)等節(jié)點(diǎn)組成呈昔，無(wú)須像ZooKeeper那樣選舉主節(jié)點(diǎn)挥等。集群中失效的節(jié)點(diǎn)不會(huì)影響正常節(jié)點(diǎn)對(duì)外提供服務(wù)注冊(cè)和服務(wù)查詢能力。
Eureka客戶端有失效轉(zhuǎn)移的能力堤尾，如果在向某個(gè)Eureka服務(wù)器注冊(cè)服務(wù)時(shí)發(fā)現(xiàn)連接失敗肝劲，則會(huì)自動(dòng)切換至其他節(jié)點(diǎn)。因此郭宝，只要有一臺(tái)Eureka服務(wù)器節(jié)點(diǎn)還能夠正常工作辞槐，就無(wú)須擔(dān)心注冊(cè)中心的可用性。但是粘室，保證可用性必然造成數(shù)據(jù)一致性的缺失榄檬，客戶端查詢到的信息不一定是最新的。

undefined

Eureka 2.X 雖然已經(jīng)宣布不再維護(hù)衔统，但是其目前的功能已經(jīng)非常穩(wěn)定丙号，就算不升級(jí)，服務(wù)注冊(cè)/發(fā)現(xiàn)這些功能已經(jīng)夠用

Consul

Consul 來(lái)源于HashiCorp的產(chǎn)品缰冤，提供了一些列特性，包括服務(wù)發(fā)現(xiàn)喳魏、更豐富的健康檢查（內(nèi)存棉浸、磁盤(pán)使用情況等細(xì)粒度服務(wù)狀態(tài)檢測(cè)功能）、鍵值對(duì)存儲(chǔ)功能以及多數(shù)據(jù)中心（官網(wǎng)描述的四個(gè)主要特色）刺彩。和其他方案比較起來(lái)迷郑，具有“一站式”的特點(diǎn)枝恋。

image.png

Consul 使用 Go 語(yǔ)言編寫(xiě)，因此具有天然可移植性(支持Linux嗡害、windows和Mac OS X)焚碌；安裝包僅包含一個(gè)可執(zhí)行文件，方便部署霸妹，與 Docker 等輕量級(jí)容器可無(wú)縫配合十电。

和etcd一樣， Consul基于 raft 協(xié)議叹螟，要求必須過(guò)半數(shù)的節(jié)點(diǎn)都寫(xiě)入成功才認(rèn)為注冊(cè)成功 Leader 掛掉時(shí)鹃骂，重新選舉期間整個(gè) Consul 不可用。保證了強(qiáng)一致性但犧牲了可用性罢绽。

作者本人對(duì)Consul研究并不多畏线，感興趣的讀者可以自行查閱相關(guān)的文檔進(jìn)行學(xué)習(xí)。

官網(wǎng)：https://www.consul.io/

Nacos

Nacos 是我們國(guó)內(nèi)阿里巴巴的新開(kāi)源項(xiàng)目良价，其核心定位是 “一個(gè)更易于幫助構(gòu)建云原生應(yīng)用的動(dòng)態(tài)服務(wù)發(fā)現(xiàn)寝殴、配置和服務(wù)管理平臺(tái)”。（通俗的理解就是明垢，注冊(cè)中心 + 配置中心）

image.png

服務(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)測(cè)
• 動(dòng)態(tài)配置服務(wù)
• 動(dòng)態(tài) DNS 服務(wù)
• 服務(wù)及其元數(shù)據(jù)管理

更多的內(nèi)容袖外，請(qǐng)延伸閱讀Nacos的官方文檔：

延伸閱讀 https://nacos.io/zh-cn/docs/what-is-nacos.html

小結(jié)

本章介紹了服務(wù)發(fā)現(xiàn)相關(guān)的一些知識(shí)史隆，和目前市面上比較流行的服務(wù)注冊(cè)中心的相關(guān)特性，希望能對(duì)你有所啟發(fā)曼验。

我們下期再會(huì)泌射。

參考文章

1. Service Discovery in a Microservices Architecture
2. Microservices: Service Registration and Discovery
3. Service Discovery
4. https://nacos.io/zh-cn/
5. etcd：從應(yīng)用場(chǎng)景到實(shí)現(xiàn)原理的全方位解讀
6. 《從服務(wù)化到云原生》
7. 《微服務(wù)設(shè)計(jì)》

如果本文有幫助到你，希望能點(diǎn)個(gè)贊鬓照，這是對(duì)我的最大動(dòng)力熔酷。