正常情況下當(dāng)我們要訪問服務(wù)時(shí)需要知道服務(wù)實(shí)例地址和端口，如果服務(wù)實(shí)例地址和端口都是固定的我們可以直接將其配置在文件中使用，但大多數(shù)線上生產(chǎn)環(huán)境尤其容器部署情況下服務(wù)實(shí)例地址都是動(dòng)態(tài)分配的，只有當(dāng)服務(wù)實(shí)例實(shí)際部署之后才能獲得地址，服務(wù)調(diào)用者根本無(wú)法提取獲取服務(wù)實(shí)例地址和端口，只能在運(yùn)行時(shí)通過服務(wù)發(fā)現(xiàn)組件解析服務(wù)名來獲取服務(wù)實(shí)例地址和端口。

[[276433]]

服務(wù)發(fā)現(xiàn)簡(jiǎn)單來講就是通過服務(wù)名找到提供服務(wù)的實(shí)例地址和端口，主要用于解決如何獲取服務(wù)實(shí)例地址問題。近年來隨著容器技術(shù)的興起，大量服務(wù)分散在系統(tǒng)各處，服務(wù)彼此之間調(diào)用都需要通過服務(wù)發(fā)現(xiàn)來實(shí)現(xiàn)。服務(wù)發(fā)現(xiàn)是分布式系統(tǒng)中不可或缺的關(guān)鍵組件，常用于構(gòu)建服務(wù)發(fā)現(xiàn)解決方案的開源框架如Zookeeper、 Etcd、Consul。本文主要介紹如何基于Zookeeper、 Etcd、Consul構(gòu)建服務(wù)發(fā)現(xiàn)方案并對(duì)其可能出現(xiàn)的問題進(jìn)行討論。

一個(gè)標(biāo)準(zhǔn)的服務(wù)發(fā)現(xiàn)架構(gòu)主要有三部分組成分別是服務(wù)注冊(cè)中心、服務(wù)調(diào)用者、服務(wù)提供者，架構(gòu)圖如下所示：

服務(wù)注冊(cè)中心是服務(wù)發(fā)現(xiàn)的核心組件，其本質(zhì)上是一個(gè)服務(wù)名和服務(wù)實(shí)例地址映射集合，除了提供基本的服務(wù)名解析功能外，還需要具備如下能力：

• 容錯(cuò)(Fault Tolerance)：服務(wù)注冊(cè)中心保存了分布式系統(tǒng)中所有服務(wù)名與服務(wù)實(shí)例地址映射，一旦故障必將導(dǎo)致整個(gè)系統(tǒng)不可用，是整個(gè)分布式系統(tǒng)核心，必須具備高可用性;
• 服務(wù)健康檢查(Service Health Check)：服務(wù)注冊(cè)中心必須要能及時(shí)發(fā)現(xiàn)故障實(shí)例并將其注銷以防止被錯(cuò)誤訪問;
• 監(jiān)視器(Watcher)：服務(wù)注冊(cè)中心必須具備及時(shí)通知服務(wù)調(diào)用者服務(wù)實(shí)例注冊(cè)或注銷的能力，以便服務(wù)調(diào)用者及時(shí)采取措施。

注冊(cè)或注銷服務(wù)實(shí)例一般有兩種選擇：

1. 服務(wù)實(shí)例自己注冊(cè)即Self-Registration模式，在服務(wù)實(shí)例啟動(dòng)成功后主動(dòng)將自己注冊(cè)到服務(wù)注冊(cè)中心，這種方法好處是架構(gòu)簡(jiǎn)單但需要為服務(wù)用到的每種編程語(yǔ)言實(shí)現(xiàn)注冊(cè)代碼;
2. 通過其他組件來注冊(cè)服務(wù)實(shí)例即Thrid-party Registration模式，例如使用一個(gè)獨(dú)立Agent通過輪詢或監(jiān)聽事件去跟蹤運(yùn)行的服務(wù)實(shí)例變化進(jìn)行注冊(cè)或注銷，好處是服務(wù)實(shí)例與服務(wù)注冊(cè)中心解耦但引入第三方組件增加了架構(gòu)復(fù)雜性。

服務(wù)發(fā)現(xiàn)方案

DNS

DNS(Domain Name System)是一種通過解析域名獲取IP和端口的機(jī)制。將SRV記錄注冊(cè)到DNS服務(wù)器上，通過DNS解析流程進(jìn)行解析。但是DNS存在兩個(gè)問題：一是當(dāng)服務(wù)實(shí)例啟動(dòng)之后將SRV記錄注冊(cè)到DNS服務(wù)器上比較難，需要手動(dòng)維護(hù);二是DNS嚴(yán)重依賴緩存，服務(wù)使用方無(wú)法及時(shí)知道一個(gè)服務(wù)實(shí)例是否已經(jīng)停止。

mDNS

mDNS(multicast DNS即組播DNS)是一種零配置的服務(wù)發(fā)現(xiàn)機(jī)制，在內(nèi)部網(wǎng)絡(luò)中經(jīng)常使用，每個(gè)服務(wù)都有一個(gè)內(nèi)置的mDNS響應(yīng)程序，從而不需要單獨(dú)的服務(wù)注冊(cè)中心。mDNS最大的問題就是要求網(wǎng)絡(luò)基礎(chǔ)設(shè)施支持IP多播(IP multicast)，對(duì)于云環(huán)境來說顯然是無(wú)法滿足的，而且mDNS也無(wú)法解決DNS緩存問題。

DNS與mDNS都具備良好的容錯(cuò)能力，但缺乏服務(wù)健康檢查和變化通知機(jī)制。

Zookeeper

Zookeeper提供分布式協(xié)調(diào)服務(wù)，在分布式系統(tǒng)中常被用于配置管理、名字服務(wù)、分布式鎖及組管理，通常運(yùn)行在一組節(jié)點(diǎn)上實(shí)現(xiàn)容錯(cuò)(當(dāng)運(yùn)行在n個(gè)節(jié)點(diǎn)上時(shí)能容忍n/2個(gè)節(jié)點(diǎn)同時(shí)故障)。

如何通過Zookeeper來實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)?Zookeeper使用臨時(shí)節(jié)點(diǎn)(ephemeral node)來實(shí)現(xiàn)服務(wù)注冊(cè)和基本的健康檢查功能。每當(dāng)服務(wù)實(shí)例啟動(dòng)就會(huì)在Zookeeper中注冊(cè)一個(gè)臨時(shí)節(jié)點(diǎn)，而當(dāng)服務(wù)實(shí)例故障或下線該臨時(shí)節(jié)點(diǎn)會(huì)被Zookeeper自動(dòng)刪除，如果有其他服務(wù)依賴這個(gè)服務(wù)可以設(shè)置監(jiān)聽該服務(wù)實(shí)例對(duì)應(yīng)的臨時(shí)節(jié)點(diǎn)，當(dāng)臨時(shí)節(jié)點(diǎn)被刪除時(shí)，依賴該服務(wù)的其他服務(wù)會(huì)獲得通知。依賴Zookeeper自身的高可用及臨時(shí)節(jié)點(diǎn)提供的健康檢查和監(jiān)聽機(jī)制來實(shí)現(xiàn)具備容錯(cuò)能力的服務(wù)發(fā)現(xiàn)機(jī)制。

實(shí)際開發(fā)過程中建議使用Apache Curator來替代Zookeeper原生客戶端庫(kù)，Apache Curator通過封裝Zookeeper原生API，提供更高抽象層次API讓Zookeeper使用起來更加容易和可靠，而且提供專用于實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)的API。

Etcd

Etcd是一個(gè)基于Raft共識(shí)算法具備線性強(qiáng)一致性(linearizable)的Key-Value存儲(chǔ)系統(tǒng)，可以為每個(gè)Key設(shè)置TTL(time to live)，當(dāng)TTL過后相應(yīng)Key會(huì)自動(dòng)過期失效?；贓tcd構(gòu)建服務(wù)發(fā)現(xiàn)解決方案將Etcd作為服務(wù)注冊(cè)中心，服務(wù)實(shí)例注冊(cè)就是在Etcd中構(gòu)建一個(gè)Key-Value記錄，由服務(wù)實(shí)例自身或代理負(fù)責(zé)設(shè)置并定期更新其關(guān)聯(lián)Key的TTL，如果服務(wù)實(shí)例故障其對(duì)應(yīng)Key就會(huì)在TTL之后過期失效，相當(dāng)于將該故障服務(wù)實(shí)例注銷，通過定時(shí)心跳以達(dá)到監(jiān)控健康狀態(tài)的效果。而且Etcd提供監(jiān)聽機(jī)制，允許為Key設(shè)置監(jiān)聽器當(dāng)該Key發(fā)生變化時(shí)，監(jiān)聽器能及時(shí)獲取通知。Etcd自身的高可用特性，基于TTL提供基本的服務(wù)健康檢查，基于監(jiān)聽機(jī)制及時(shí)感知服務(wù)實(shí)例變化，使Etcd成為微服務(wù)架構(gòu)中常用服務(wù)發(fā)現(xiàn)解決方案。

Consul

Consul是一個(gè)成熟的服務(wù)發(fā)現(xiàn)解決方案。其核心是一個(gè)基于Raft共識(shí)算法具備線性強(qiáng)一致性的Key-Value存儲(chǔ)系統(tǒng)作為服務(wù)注冊(cè)中心，并提供代理(Agent)機(jī)制一方面用于協(xié)調(diào)服務(wù)注冊(cè)，一方面提供服務(wù)健康檢查。代理(Agent)會(huì)在每個(gè)運(yùn)行服務(wù)的節(jié)點(diǎn)上啟動(dòng)，獲取節(jié)點(diǎn)地址并將該服務(wù)實(shí)例注冊(cè)到服務(wù)注冊(cè)中心。架構(gòu)上Consul包括兩類組件：Server、Agent，服務(wù)注冊(cè)信息保存在Server上，通過Raft共識(shí)算法保證多個(gè)Server間數(shù)據(jù)線性強(qiáng)一致，保證服務(wù)注冊(cè)中心高可用;將所有Agent作為集群節(jié)點(diǎn)，使用Gossip協(xié)議進(jìn)行組關(guān)系管理和故障探測(cè)，當(dāng)有Agent加入(啟動(dòng))或離開(故障)集群時(shí)其他Agent會(huì)得到通知，實(shí)現(xiàn)服務(wù)健康檢查和監(jiān)視功能。

Gossip協(xié)議常用于集群組關(guān)系管理和故障檢測(cè)，每個(gè)節(jié)點(diǎn)都通過一個(gè)或多個(gè)引導(dǎo)節(jié)點(diǎn)加入集群，引導(dǎo)節(jié)點(diǎn)有集群中所有節(jié)點(diǎn)列表，每個(gè)節(jié)點(diǎn)都從自己所知節(jié)點(diǎn)列表中隨機(jī)選擇一組節(jié)點(diǎn)周期性地發(fā)送多播消息，最終集群中所有節(jié)點(diǎn)都能知道其他節(jié)點(diǎn)。這個(gè)過程看起來很神奇，實(shí)際上Gossip協(xié)議能在幾秒內(nèi)將消息傳遍有上百節(jié)點(diǎn)的集群。Akka、Riak、Cassandra都使用Gossip協(xié)議維護(hù)集群成員列表和故障探測(cè)。

此外Consul和Etcd都非常適合容器環(huán)境，因?yàn)镈ocker容器啟動(dòng)、停止都會(huì)發(fā)送事件(Event)，基于事件通知機(jī)制非常便于將服務(wù)實(shí)例從Consul或Etcd上注冊(cè)、注銷。

總結(jié)

本文總結(jié)了傳統(tǒng)服務(wù)發(fā)現(xiàn)方案如DNS、mDNS以及微服務(wù)架構(gòu)中常用的解決方案，基于Zookeeper、Etcd、Consul框架方案核心思想是通過一組實(shí)例(3個(gè)或者5個(gè))提供線性強(qiáng)一致性(Linearizable)分布式高可用Key-Value存儲(chǔ)服務(wù)，將Key-Value存儲(chǔ)作為服務(wù)注冊(cè)中心，當(dāng)相關(guān)Key發(fā)生變化時(shí)監(jiān)視器能及時(shí)通知客戶端，通知機(jī)制配合服務(wù)健康檢查當(dāng)有服務(wù)實(shí)例啟動(dòng)或故障時(shí)客戶端能及時(shí)感知服務(wù)拓?fù)渥兓詫?shí)現(xiàn)智能路由，從實(shí)現(xiàn)方式上看它們可以看作是中心化的服務(wù)發(fā)現(xiàn)方案。

其實(shí)對(duì)于服務(wù)發(fā)現(xiàn)來說線性強(qiáng)一致性并不是唯一必須的，最終一致性在數(shù)據(jù)傳播足夠快的情況下一樣能滿足需求，實(shí)踐中Gossip協(xié)議即使在大型集群也能快速傳播數(shù)據(jù)并收斂到最終一致，將服務(wù)實(shí)例作為Gossip集群節(jié)點(diǎn)，使用CRDT(conflict-free replicated data type)存儲(chǔ)服務(wù)注冊(cè)信息通過Gossip快速傳播實(shí)現(xiàn)集群中所有節(jié)點(diǎn)狀態(tài)最終一致，每個(gè)節(jié)點(diǎn)都存儲(chǔ)全部服務(wù)注冊(cè)信息，這樣就不需要單獨(dú)的服務(wù)注冊(cè)中心，這種方式實(shí)現(xiàn)的方案叫去中心化方案，有關(guān)去中心化服務(wù)發(fā)現(xiàn)方案留作下次分享。