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

背景

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

服務發現

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

服務注冊

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

注冊中心

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

未來展望

我心中相對完整的微服務架構可能如下圖。?

歡迎關注我們的公眾號

轉載于:https://www.cnblogs.com/davidwang456/articles/9239184.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。