服務發現框架選型: Consul、Zookeeper還是etcd ？

 

背景

本文並不介紹服務發現的基本原理。除了一致性算法之外，其他並沒有太多高深的算法，網上的資料很容易讓大家明白上面是服務發現。
想直接查看結論的同學，請直接跳到文末。
目前，市面上有非常多的服務發現工具，《Open-Source Service Discovery》一文中列舉了如下開源的服務發現工具。

Name	Type	AP or CP	Language	Dependencies	Integration
Zookeeper	General	CP	Java	JVM	Client Binding
Doozer	General	CP	Go		Client Binding
Etcd	General	Mixed (1)	Go		Client Binding/HTTP
SmartStack	Dedicated	AP	Ruby	haproxy/Zookeeper	Sidekick (nerve/synapse)
Eureka	Dedicated	AP	Java	JVM	Java Client
NSQ (lookupd)	Dedicated	AP	Go		Client Binding
Serf	Dedicated	AP	Go		Local CLI
Spotify (DNS)	Dedicated	AP	N/A	Bind	DNS Library
SkyDNS	Dedicated	Mixed (2)	Go		HTTP/DNS Library

(1) If using the consistent parameter, inconsistent reads are possible
(2) If using a caching DNS client in front of SkyDNS, reads could be inconsistent

---

上面表格中，前三個是通用的，后面都是各大公司自己造的輪子，應用范圍並不廣，我也就不深入研究了。
此外，這篇文章是14年寫的，當時它並沒有研究Consul，放到表格中，Consul則應該是General、CP、Go、No dependency、Http/DNS Library。
截止到今天，除了容器編排框架k8s、istio/envoy自己實現了服務發現機制（他們也兼容第三方的服務發現工具），似乎也沒有其他的知名的服務發現框架出現了。
下面我就zookeeper、etcd、consul這三款進行下比較。

比較

zookeeper

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them ,which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.

官網這么介紹zookeeper的，翻譯過來，zookeeper的功能有：

1. 作為配置信息的存儲的中心服務器
2. 命名服務
3. 分布式同步
4. 分組服務

能看出，zookeeper並不只是作為服務發現框架使用的，它非常龐大。
如果只是打算將zookeeper作為服務發現工具，就需要用到其配置存儲和分布式同步的功能。前者可以理解成具有一致性的kv存儲，后者提供了zookeeper特有的watcher注冊於異步通知機制，zookeeper能將節點的狀態實時異步通知給zookeeper客戶端。

zookeeper使用

zookeeper的使用流程如下：

1. 確保有所選語言的sdk，理論上github上第三方的庫有一些，仔細篩選一下應該可以用。
2. 調用zookeeper接口連接zookeeper服務器。
3. 注冊自身服務
4. 通過watcher獲取監聽服務的狀態
5. 服務提供者需自行保持與zookeeper服務器的心跳。

《Zookeeper C API 指南》寫了八篇文章介紹了如何使用zookeeper的c語言api。

總得來說，zookeeper需要胖客戶端，每個客戶端都需要通過其sdk與zookeeper服務保活，增加了編寫程序的復雜性。此外，還提供api實現服務注冊與發現邏輯，需要服務的消費者實現服務提供者存活的檢測。

etcd

etcd是一個采用http協議的分布式鍵值對存儲系統，因其易用，簡單。很多系統都采用或支持etcd作為服務發現的一部分，比如kubernetes。但正事因為其只是一個存儲系統，如果想要提供完整的服務發現功能，必須搭配一些第三方的工具。
比如配合etcd、Registrator、confd組合，就能搭建一個非常簡單而強大的服務發現框架。但這種搭建操作就稍微麻煩了點，尤其是相對consul來說。所以etcd大部分場景都是被用來做kv存儲，比如kubernetes。

consul

相較於etcd、zookeeper，consul最大的特點就是：它整合了用戶服務發現普遍的需求，開箱即用，降低了使用的門檻，並不需要任何第三方的工具。代碼實現上也足夠簡單。

Consul has multiple components, but as a whole, it is a tool for discovering and configuring services in your infrastructure. It provides several key features:

1. Service Discovery
2. Health Checking
3. KV Store
4. Multi Datacenter

展開了說，consul的功能有：

1. 通過DNS或HTTP，應用能輕易地找到它們依賴的系統
2. 提供了多種健康檢查方式：http返回碼200，內存是否超限，tcp連接是否成功
3. kv存儲，並提供http api
4. 多數據中心，這點是zookeeper所不具備的。

consul使用

相比於zookeeper的服務發現使用，consul並不需要專門的sdk集成到服務中，因此它不限制任何語言的使用。我們看看consul一般是怎么使用的。

1. 每台服務器上都要安裝一個consul agent。
2. consul agent支持通過配置文件注冊服務，或者在服務中通過http接口來注冊服務。
3. 注冊服務后，consul agent通過指定的健康檢查方式，定期檢查服務是否存活。
4. 如果服務想查詢其他服務的存活狀態，只需要與本機的consul agent發起一次http請求或者dns請求即可。

簡單點說，consul的使用不依賴任何sdk，依靠簡單的http請求就能滿足服務發現的所有邏輯。
不過，服務每次都從consul agent獲取其他服務的存活狀態，相比於zookeeper的watcher機制，實時性稍差一點，需考慮如何盡可能提高實時性，問題不會很大。

總結

名稱	優點	缺點	接口	一致性算法
zookeeper	1.功能強大，不僅僅只是服務發現 2.提供watcher機制能實時獲取服務提供者的狀態 3.dubbo等框架支持	1.沒有健康檢查 2.需在服務中集成sdk，復雜度高 3.不支持多數據中心	sdk	Paxos
consul	1.簡單易用，不需要集成sdk 2.自帶健康檢查 3.支持多數據中心 4.提供web管理界面	1.不能實時獲取服務信息的變化通知	http/dns	Raft
etcd	1.簡單易用，不需要集成sdk 2.可配置性強	1.沒有健康檢查 2.需配合第三方工具一起完成服務發現 3.不支持多數據中心	http	Raft

為了以后支持多數據中心，同時為了快速支持不同的語言比如nodejs、python服務，我會選擇consul作為我們的服務發現框架，但是實時獲取服務信息變化通知的問題需盡可能減小。

參考文獻：
Consul vs. Other Software
服務發現：Zookeeper vs etcd vs Consul
Consul vs 其他軟件
Comparing ZooKeeper and Consul