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

[[276433]]

服務(wù)發(fā)現(xiàn)簡單來講就是通過服務(wù)名找到提供服務(wù)的實例地址和端口，主要用于解決如何獲取服務(wù)實例地址問題。近年來隨著容器技術(shù)的興起，大量服務(wù)分散在系統(tǒng)各處，服務(wù)彼此之間調(diào)用都需要通過服務(wù)發(fā)現(xiàn)來實現(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)方案并對其可能出現(xiàn)的問題進行討論。

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

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

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

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

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

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

DNS

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

mDNS

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

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

Zookeeper

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

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

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

Etcd

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

Consul

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

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

此外Consul和Etcd都非常適合容器環(huán)境，因為Docker容器啟動、停止都會發(fā)送事件(Event)，基于事件通知機制非常便于將服務(wù)實例從Consul或Etcd上注冊、注銷。

總結(jié)

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

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