https://tech.youzan.com/haunt-youzan-service-discovery/

背景

Haunt是有贊內(nèi)部使用的服務(wù)發(fā)現(xiàn)系統(tǒng)，下面會詳細(xì)介紹一下該系統(tǒng)的設(shè)計與思考。?
首先，我們設(shè)想一下，我們提供的RESTful API或者其他API的服務(wù)，為了完成一次服務(wù)請求，服務(wù)調(diào)用方需要知道服務(wù)實例的網(wǎng)絡(luò)位置(IP地址和端口)。傳統(tǒng)應(yīng)用都運行在物理硬件上，服務(wù)實例的網(wǎng)絡(luò)位置都是相對固定的。比較常見的做法是，服務(wù)調(diào)用方可以從一個經(jīng)常變更的配置文件中讀取網(wǎng)絡(luò)位置。而對于一個現(xiàn)代的，基于云端微服務(wù)的應(yīng)用來說，這卻是一個很麻煩的問題。如下圖所示：?
PaaS平臺中的應(yīng)用一般都有多個實例，實例故障重啟透明化與負(fù)載均衡都與服務(wù)發(fā)現(xiàn)密切相關(guān)。通過服務(wù)發(fā)現(xiàn)機制，可以透明的對多個實例進(jìn)行訪問，并實現(xiàn)負(fù)載均衡。而且應(yīng)用的某個實例隨時都可能故障重啟，這時就需要動態(tài)配置服務(wù)調(diào)用方的路由信息。服務(wù)發(fā)現(xiàn)就可以解決這個動態(tài)配置的問題，Haunt(Youzan服務(wù)發(fā)現(xiàn)系統(tǒng))也應(yīng)運而生。

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

Haunt使用的服務(wù)發(fā)現(xiàn)模式是客戶端發(fā)現(xiàn)模式。使用客戶端發(fā)現(xiàn)模式時，客戶端決定相應(yīng)服務(wù)實例的網(wǎng)絡(luò)位置，并且對請求實現(xiàn)負(fù)載均衡。客戶端查詢服務(wù)注冊中心，后者是一個可用服務(wù)實例的數(shù)據(jù)庫；然后使用負(fù)載均衡算法從中選擇一個實例，并發(fā)出請求。這種模式相對直接，除了服務(wù)注冊外，其它部分無需變動。此外，由于客戶端知曉可用的服務(wù)實例，能針對特定應(yīng)用實現(xiàn)智能負(fù)載均衡。當(dāng)然缺點也比較明顯，客戶端與服務(wù)注冊中心綁定，要針對服務(wù)端用到的每個編程語言和框架，實現(xiàn)客戶端的服務(wù)發(fā)現(xiàn)邏輯；而且對于服務(wù)治理不是非常友好。架構(gòu)如下圖：?

服務(wù)注冊

服務(wù)實例必須向注冊中心注冊服務(wù)，這樣服務(wù)調(diào)用方才能從注冊中心拉到服務(wù)的實例列表。實現(xiàn)服務(wù)注冊的方式有兩種：自注冊模式和第三方注冊模式。?
自注冊模式是服務(wù)實例自己負(fù)責(zé)在服務(wù)注冊表中注冊與注銷。另外，如果需要的話，一個服務(wù)實例也要發(fā)送心跳到注冊中心來保證注冊信息不會過時。自注冊模式的優(yōu)點是相對簡單，無需其他系統(tǒng)組件。然而，他的主要缺點是把服務(wù)實例與服務(wù)注冊中心耦合，必須在每個編程語言和框架內(nèi)實現(xiàn)注冊代碼。?
Haunt使用的是第三方注冊模式，服務(wù)實例不需要直接跟注冊中心進(jìn)行交互。服務(wù)注冊器(Haunt Agent)負(fù)責(zé)向注冊中心注冊和注銷此服務(wù)，并對服務(wù)進(jìn)行健康檢查。架構(gòu)如下圖：?
第三方注冊模式的優(yōu)點主要是服務(wù)與注冊中心解耦，無需為每個編程語言和框架實現(xiàn)服務(wù)與注冊中心的邏輯(注冊，注銷，維持心跳等)。相反，服務(wù)實例通過一個專有服務(wù)(Haunt)以中心化的方式進(jìn)行管理。不足之處在于，除非該服務(wù)內(nèi)置于部署環(huán)境，否則需要配置和管理一個高可用的系統(tǒng)組件。Haunt Agent單獨內(nèi)置于部署環(huán)境的理由也是如此，因為不想引入一個高可用的系統(tǒng)組件來保證服務(wù)注冊器的數(shù)據(jù)一致性，從而增加系統(tǒng)的復(fù)雜度。?
Haunt Agent運行在集群的每一個節(jié)點上，每一個Haunt Agent擁有分布式健康檢測機制，這個健康檢測機制可以應(yīng)用到任意規(guī)模的集群，而不僅僅是作用于特定的服務(wù)器組。同時，Haunt也支持在本地進(jìn)行多種健康檢測。比如，可以檢測web服務(wù)器是否正在返回200狀態(tài)碼，內(nèi)存利用率是否達(dá)到臨界點，是否有足夠的數(shù)據(jù)存儲盤等。最后，Haunt可以配置健康檢測的間隔時間，對于一些容錯率要求比較高的服務(wù)，可以配置1秒檢測，這樣在服務(wù)故障的情況下，基本可以秒級收斂。

注冊中心

注冊中心是服務(wù)發(fā)現(xiàn)的核心，是包含服務(wù)實例數(shù)據(jù)(例如ip地址，端口等)的數(shù)據(jù)庫。所以注冊中心需要一個高可用的分布式鍵/值存儲，例如Etcd，Zookeeper，Consul等。?
在注冊中心的選型上，Haunt選擇了Etcd。可能很多人會有疑問，為什么不用Zookeeper？不可否認(rèn)，Zookeeper是最早被用來做服務(wù)發(fā)現(xiàn)的開源項目之一，主要優(yōu)勢是擁有成熟、健壯以及豐富的特性。Zookeeper普遍的應(yīng)用場景，按照個人感覺應(yīng)用的頻率從高到低排序主要是這些：可靠存儲(配置管理，名字服務(wù)等)，集群管理，選主服務(wù)，服務(wù)注冊管理，分布式鎖，負(fù)載均衡等。?
然而，Zookeeper的缺點也很明顯。首先，Zookeeper會引入大量的依賴，而運維人員普遍希望機器集群盡可能地簡單，維護(hù)起來也不易出錯；還有，Zookeeper的部署、維護(hù)和使用都很復(fù)雜，管理員需要掌握一系列知識和技能，一方面Zookeeper是功能豐富，但從另一個角度分析，豐富的特性反而將其從優(yōu)勢轉(zhuǎn)變?yōu)槔圪槨Ｒ虼?#xff0c;在我看來，Etcd是在服務(wù)發(fā)現(xiàn)上可能是更好的選擇。?
當(dāng)然不僅僅是以上幾個方面，經(jīng)過詳細(xì)的調(diào)研，下面我會具體來分析下Etcd相比Zookeeper所具有的特點：?
- Etcd更加穩(wěn)定可靠，它的唯一目標(biāo)就是把一致性kv做到極致，更注重穩(wěn)定性和擴展性。?
- 在服務(wù)發(fā)現(xiàn)的實現(xiàn)上，Etcd使用的是節(jié)點租約(Lease)，并且支持Group(多key)；Zookeeper使用臨時節(jié)點，臨時節(jié)點的問題后面會提到。?
- Etcd支持穩(wěn)定的watch，而不是Zookeeper一樣簡單的one time trigger watch。因為在未來微服務(wù)的環(huán)境下，通過調(diào)度系統(tǒng)的調(diào)度一個服務(wù)隨時可能會下線，也可能應(yīng)對臨時訪問壓力增加新的服務(wù)節(jié)點。而很多調(diào)度系統(tǒng)是需要得到完整節(jié)點歷史記錄的，etcd可以存儲上十萬個歷史變更。?
- Etcd支持mvcc，因為有協(xié)同系統(tǒng)需要無鎖操作。?
- Etcd支持更大的數(shù)據(jù)規(guī)模，支持存儲百萬到千萬級別的key。?
- 相比Zookeeper，Etcd性能更好。在一個由3臺8核節(jié)點組成的的云服務(wù)器上，etcd可以做到每秒數(shù)萬次的寫操作和十萬次讀操作。?
關(guān)于性能，下面兩張圖是高并發(fā)下，Etcd與Zookeeper耗時與吞吐量的對比：?
注：上圖來自https://github.com/coreos/dbtester?
紅色線是Etcd，由上面兩個圖可以看出，在高并發(fā)下，Etcd相比Zookeeper，耗時和吞吐量相對而言更加穩(wěn)定，性能更好。?
再來說說Zookeeper的臨時節(jié)點，臨時節(jié)點其實就是Zookeeper里的K/V條目，當(dāng)客戶端跟Zookeeper連接斷開的時候，這些條目會被刪除，它只是一個非常原始的活躍度檢測。也就是說，在客戶端跟Zookeeper之間網(wǎng)絡(luò)分區(qū)或者網(wǎng)絡(luò)不穩(wěn)定的情況下，這些條目也有可能被刪除，導(dǎo)致所有客戶端都刪除該服務(wù)實例，雖然可能此時該服務(wù)實例是健康的。因此Zookeeper的臨時節(jié)點存在固有的擴展性問題，并且會增加客戶端的復(fù)雜性。與ZooKeeper服務(wù)器端連接時，客戶端必須保持活躍，并且去做持續(xù)性連接。此外，ZooKeeper還需要胖客戶端，會暴露系統(tǒng)的復(fù)雜性給客戶端，而胖客戶端是很難編寫的，并且胖客戶端會經(jīng)常導(dǎo)致調(diào)試質(zhì)詢。而Etcd采用的是租約(Lease)機制，通過TTL可以有效的規(guī)避網(wǎng)絡(luò)分區(qū)的問題。

未來展望

我心中相對完整的微服務(wù)架構(gòu)可能如下圖。?

歡迎關(guān)注我們的公眾號

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/9239184.html

總結(jié)

以上是生活随笔為你收集整理的Haunt - Youzan 服务发现 概述的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。