轉(zhuǎn)自：阿里巴巴為什么不用 ZooKeeper 做服務(wù)發(fā)現(xiàn)？

站在未來的路口搪锣，回望歷史的迷途秋忙，常常會很有意思，因為我們會不經(jīng)意地興起瘋狂的念頭构舟，例如如果當(dāng)年某事提前發(fā)生了灰追，而另外一件事又沒有發(fā)生會怎樣？一如當(dāng)年的奧匈帝國皇位繼承人斐迪南大公夫婦如果沒有被塞爾維亞族熱血青年普林西普槍殺會怎樣狗超，又如若當(dāng)年的丘老道沒有經(jīng)過牛家村會怎樣弹澎？

2008 年底，淘寶開啟一個叫做“五彩石”的內(nèi)部重構(gòu)項目努咐，這個項目后來成為了淘寶服務(wù)化苦蒿、面向分布式走自研之路，走出了互聯(lián)網(wǎng)中間件體系之始渗稍，而淘寶服務(wù)注冊中心 ConfigServer 于同年誕生佩迟。

2008 年前后，Yahoo 這個曾經(jīng)的互聯(lián)網(wǎng)巨頭開始逐漸在公開場合宣講自己的大數(shù)據(jù)分布式協(xié)調(diào)產(chǎn)品 ZooKeeper竿屹，這個產(chǎn)品參考了 Google 發(fā)表的關(guān)于 Chubby 以及 Paxos 的論文报强。

2010 年 11 月，ZooKeeper 從 Apache Hadoop 的子項目發(fā)展為 Apache 的頂級項目拱燃，正式宣告 ZooKeeper 成為一個工業(yè)級的成熟穩(wěn)定的產(chǎn)品秉溉。

2011 年，阿里巴巴開源 Dubbo扼雏，為了更好開源坚嗜，需要剝離與阿里內(nèi)部系統(tǒng)的關(guān)系夯膀，Dubbo 支持了開源的 ZooKeeper 作為其注冊中心诗充，后來在國內(nèi)，在業(yè)界諸君的努力實踐下诱建，Dubbo + ZooKeeper 的典型的服務(wù)化方案成就了 ZooKeeper 作為注冊中心的聲名蝴蜓。

2015 年雙 11，ConfigServer 服務(wù)內(nèi)部近 8 個年頭過去了，阿里巴巴內(nèi)部“服務(wù)規(guī)木ソ常”超幾百萬 格仲，以及推進“千里之外”的 IDC 容災(zāi)技術(shù)戰(zhàn)略等，共同促使阿里巴巴內(nèi)部開啟了 ConfigServer 2.0 到 ConfigServer 3.0 的架構(gòu)升級之路诵冒。

時間走向 2018 年凯肋，站在 10 年的時間路口上，有多少人愿意在追逐日新月異的新潮技術(shù)概念的時候汽馋，稍微慢一下腳步侮东，仔細凝視一下服務(wù)發(fā)現(xiàn)這個領(lǐng)域，有多少人想到過或者思考過一個問題：
服務(wù)發(fā)現(xiàn)豹芯，ZooKeeper 真的是最佳選擇么悄雅？
而回望歷史，我們也偶有迷思铁蹈，在服務(wù)發(fā)現(xiàn)這個場景下宽闲，如果當(dāng)年 ZooKeeper 的誕生之日比我們 HSF 的注冊中心 ConfigServer 早一點會怎樣？

我們會不會走向先使用 ZooKeeper 然后瘋狂改造與修補 ZooKeeper 以適應(yīng)阿里巴巴的服務(wù)化場景與需求的彎路握牧？

但是容诬，站在今天和前人的肩膀上，我們從未如今天這樣堅定的認知到我碟，在服務(wù)發(fā)現(xiàn)領(lǐng)域放案，ZooKeeper 根本就不能算是最佳的選擇，一如這些年一直與我們同行的 Eureka 以及這篇文章 《Eureka! Why You Shouldn’t Use ZooKeeper for Service Discovery》那堅定的闡述一樣矫俺，為什么你不應(yīng)該用 ZooKeeper 做服務(wù)發(fā)現(xiàn)吱殉！

吾道不孤矣。

注冊中心需求分析及關(guān)鍵設(shè)計考量

注冊中心是 CP 還是 AP 系統(tǒng)?
CAP 和 BASE 理論相信讀者都已經(jīng)耳熟能詳厘托，其業(yè)已成了指導(dǎo)分布式系統(tǒng)及互聯(lián)網(wǎng)應(yīng)用構(gòu)建的關(guān)鍵原則之一友雳，在此不再贅述其理論，我們直接進入對注冊中心的數(shù)據(jù)一致性和可用性需求的分析:

• 數(shù)據(jù)一致性需求分析
  注冊中心最本質(zhì)的功能可以看成是一個 Query 函數(shù) Si = F(service-name)铅匹，以 service-name 為查詢參數(shù)押赊，service-name 對應(yīng)的服務(wù)的可用的 endpoints (ip:port) 列表為返回值.

注: 后文將 service 簡寫為 svc。

先來看看關(guān)鍵數(shù)據(jù) endpoints (ip:port) 不一致性帶來的影響包斑，即 CAP 中的 C 不滿足帶來的后果 :

注冊中心架構(gòu)圖

如上圖所示流礁，如果一個 svcB 部署了 10 個節(jié)點 (副本 /Replica），如果對于同一個服務(wù)名 svcB, 調(diào)用者 svcA 的 2 個節(jié)點的 2 次查詢返回了不一致的數(shù)據(jù)罗丰，例如: S1 = { ip1,ip2,ip3...,ip9 }, S2 = { ip2,ip3,....ip10 }, 那么這次不一致帶來的影響是什么神帅？相信你一定已經(jīng)看出來了，svcB 的各個節(jié)點流量會有一點不均衡萌抵。

ip1 和 ip10 相對其它 8 個節(jié)點{ip2...ip9}找御，請求流量小了一點元镀，但很明顯，在分布式系統(tǒng)中霎桅，即使是對等部署的服務(wù)栖疑，因為請求到達的時間，硬件的狀態(tài)滔驶，操作系統(tǒng)的調(diào)度遇革，虛擬機的 GC 等，任何一個時間點揭糕，這些對等部署的節(jié)點狀態(tài)也不可能完全一致澳淑，而流量不一致的情況下，只要注冊中心在 SLA 承諾的時間內(nèi)（例如 1s 內(nèi)）將數(shù)據(jù)收斂到一致狀態(tài)（即滿足最終一致）插佛，流量將很快趨于統(tǒng)計學(xué)意義上的一致杠巡，所以注冊中心以最終一致的模型設(shè)計在生產(chǎn)實踐中完全可以接受。

分區(qū)容忍及可用性需求分析
接下來我們看一下網(wǎng)絡(luò)分區(qū)（Network Partition）情況下注冊中心不可用對服務(wù)調(diào)用產(chǎn)生的影響雇寇，即 CAP 中的 A 不滿足時帶來的影響氢拥。
考慮一個典型的 ZooKeeper 三機房容災(zāi) 5 節(jié)點部署結(jié)構(gòu) (即 2-2-1 結(jié)構(gòu))，如下圖:

image.png

也就是說，這時候機房 3 的應(yīng)用服務(wù) svcB 是不可以新部署深滚，重新啟動奕谭，擴容或者縮容的，但是站在網(wǎng)絡(luò)和服務(wù)調(diào)用的角度看痴荐，機房 3 的 svcA 雖然無法調(diào)用機房 1 和機房 2 的 svcB, 但是與機房 3 的 svcB 之間的網(wǎng)絡(luò)明明是 OK 的啊血柳，為什么不讓我調(diào)用本機房的服務(wù)？

現(xiàn)在因為注冊中心自身為了保腦裂 (P) 下的數(shù)據(jù)一致性（C）而放棄了可用性生兆，導(dǎo)致了同機房的服務(wù)之間出現(xiàn)了無法調(diào)用难捌，這是絕對不允許的蹬跃！可以說在實踐中蚁廓，注冊中心不能因為自身的任何原因破壞服務(wù)之間本身的可連通性凯砍，這是注冊中心設(shè)計應(yīng)該遵循的鐵律燕差！ 后面在注冊中心客戶端災(zāi)容上我們還會繼續(xù)討論。

同時我們再考慮一下這種情況下的數(shù)據(jù)不一致性板乙，如果機房 1跋破，2爱谁，3 之間都成了孤島辈末，那么如果每個機房的 svcA 都只拿到本機房的 svcB 的 ip 列表愚争，也即在各機房 svcB 的 ip 列表數(shù)據(jù)完全不一致，影響是什么挤聘？

其實沒啥大影響轰枝，只是這種情況下，全都變成了同機房調(diào)用组去，我們在設(shè)計注冊中心的時候鞍陨，有時候甚至?xí)鲃永眠@種注冊中心的數(shù)據(jù)可以不一致性，來幫助應(yīng)用主動做到同機房調(diào)用从隆，從而優(yōu)化服務(wù)調(diào)用鏈路 RT 的效果诚撵！

通過以上我們的闡述可以看到，在 CAP 的權(quán)衡中键闺，注冊中心的可用性比數(shù)據(jù)強一致性更寶貴寿烟，所以整體設(shè)計更應(yīng)該偏向 AP，而非 CP辛燥，數(shù)據(jù)不一致在可接受范圍筛武，而 P 下舍棄 A 卻完全違反了注冊中心不能因為自身的任何原因破壞服務(wù)本身的可連通性的原則。

服務(wù)規(guī)模挎塌、容量徘六、服務(wù)聯(lián)通性

你所在公司的“微服務(wù)”規(guī)模有多大？數(shù)百微服務(wù)榴都？部署了上百個節(jié)點待锈？那么 3 年后呢？互聯(lián)網(wǎng)是產(chǎn)生奇跡的地方嘴高，也許你的“服務(wù)”一夜之間就家喻戶曉竿音，流量倍增，規(guī)模翻番拴驮！

當(dāng)數(shù)據(jù)中心服務(wù)規(guī)模超過一定數(shù)量 (服務(wù)規(guī)模 =F{服務(wù) pub 數(shù), 服務(wù) sub 數(shù)})谍失，作為注冊中心的 ZooKeeper 很快就會像下圖的驢子一樣不堪重負

image.png

其實當(dāng) ZooKeeper 用對地方時，即用在粗粒度分布式鎖莹汤，分布式協(xié)調(diào)場景下快鱼，ZooKeeper 能支持的 tps 和支撐的連接數(shù)是足夠用的，因為這些場景對于 ZooKeeper 的擴展性和容量訴求不是很強烈纲岭。

但在服務(wù)發(fā)現(xiàn)和健康監(jiān)測場景下抹竹，隨著服務(wù)規(guī)模的增大，無論是應(yīng)用頻繁發(fā)布時的服務(wù)注冊帶來的寫請求止潮，還是刷毫秒級的服務(wù)健康狀態(tài)帶來的寫請求窃判，還是恨不能整個數(shù)據(jù)中心的機器或者容器皆與注冊中心有長連接帶來的連接壓力上，ZooKeeper 很快就會力不從心喇闸，而 ZooKeeper 的寫并不是可擴展的袄琳，不可以通過加節(jié)點解決水平擴展性問題询件。

要想在 ZooKeeper 基礎(chǔ)上硬著頭皮解決服務(wù)規(guī)模的增長問題，一個實踐中可以考慮的方法是想辦法梳理業(yè)務(wù)唆樊，垂直劃分業(yè)務(wù)域宛琅，將其劃分到多個 ZooKeeper 注冊中心，但是作為提供通用服務(wù)的平臺機構(gòu)組逗旁，因自己提供的服務(wù)能力不足要業(yè)務(wù)按照技術(shù)的指揮棒配合劃分治理業(yè)務(wù)嘿辟，真的可行么？

而且這又違反了因為注冊中心自身的原因（能力不足）破壞了服務(wù)的可連通性片效，舉個簡單的例子红伦，1 個搜索業(yè)務(wù)，1 個地圖業(yè)務(wù)淀衣，1 個大文娛業(yè)務(wù)昙读，1 個游戲業(yè)務(wù)，他們之間的服務(wù)就應(yīng)該老死不相往來么膨桥？也許今天是肯定的箕戳，那么明天呢，1 年后呢国撵，10 年后呢陵吸？誰知道未來會要打通幾個業(yè)務(wù)域去做什么奇葩的業(yè)務(wù)創(chuàng)新？注冊中心作為基礎(chǔ)服務(wù)介牙，無法預(yù)料未來的時候當(dāng)然不能妨礙業(yè)務(wù)服務(wù)對未來固有聯(lián)通性的需求壮虫。

注冊中心需要持久存儲和事務(wù)日志么？

需要环础，也不需要囚似。

我們知道 ZooKeeper 的 ZAB 協(xié)議對每一個寫請求，會在每個 ZooKeeper 節(jié)點上保持寫一個事務(wù)日志线得，同時再加上定期的將內(nèi)存數(shù)據(jù)鏡像（Snapshot）到磁盤來保證數(shù)據(jù)的一致性和持久性饶唤，以及宕機之后的數(shù)據(jù)可恢復(fù)，這是非常好的特性贯钩，但是我們要問募狂，在服務(wù)發(fā)現(xiàn)場景中，其最核心的數(shù)據(jù) - 實時的健康的服務(wù)的地址列表真的需要數(shù)據(jù)持久化么角雷？

對于這份數(shù)據(jù)祸穷，答案是否定的。

image.png

如上圖所示勺三，如果 svcB 經(jīng)歷了注冊服務(wù) (ip1) 到擴容到 2 個節(jié)點（ip1雷滚，ip2）到因宕機縮容 (ip1 宕機），這個過程中吗坚，產(chǎn)生了 3 次針對 ZooKeeper 的寫操作祈远。

但是仔細分析呆万，通過事務(wù)日志，持久化連續(xù)記錄這個變化過程其實意義不大车份，因為在服務(wù)發(fā)現(xiàn)中谋减，服務(wù)調(diào)用發(fā)起方更關(guān)注的是其要調(diào)用的服務(wù)的實時的地址列表和實時健康狀態(tài)，每次發(fā)起調(diào)用時躬充，并不關(guān)心要調(diào)用的服務(wù)的歷史服務(wù)地址列表、過去的健康狀態(tài)讨便。

但是為什么又說需要呢充甚，因為一個完整的生產(chǎn)可用的注冊中心，除了服務(wù)的實時地址列表以及實時的健康狀態(tài)之外霸褒，還會存儲一些服務(wù)的元數(shù)據(jù)信息伴找，例如服務(wù)的版本，分組废菱，所在的數(shù)據(jù)中心技矮，權(quán)重，鑒權(quán)策略信息殊轴，service label 等元信息衰倦，這些數(shù)據(jù)需要持久化存儲，并且注冊中心應(yīng)該提供對這些元信息的檢索的能力旁理。

Service Health Check

使用 ZooKeeper 作為服務(wù)注冊中心時樊零，服務(wù)的健康檢測常利用 ZooKeeper 的 Session 活性 Track 機制 以及結(jié)合 Ephemeral ZNode 的機制，簡單而言孽文，就是將服務(wù)的健康監(jiān)測綁定在了 ZooKeeper 對于 Session 的健康監(jiān)測上驻襟，或者說綁定在 TCP 長鏈接活性探測上了。

這在很多時候也會造成致命的問題芋哭，ZK 與服務(wù)提供者機器之間的 TCP 長鏈接活性探測正常的時候沉衣，該服務(wù)就是健康的么？答案當(dāng)然是否定的减牺！注冊中心應(yīng)該提供更豐富的健康監(jiān)測方案豌习，服務(wù)的健康與否的邏輯應(yīng)該開放給服務(wù)提供方自己定義，而不是一刀切搞成了 TCP 活性檢測拔疚！

健康檢測的一大基本設(shè)計原則就是盡可能真實的反饋服務(wù)本身的真實健康狀態(tài)斑鸦，否則一個不敢被服務(wù)調(diào)用者相信的健康狀態(tài)判定結(jié)果還不如沒有健康檢測。

注冊中心的容災(zāi)考慮

前文提過草雕，在實踐中巷屿，注冊中心不能因為自身的任何原因破壞服務(wù)之間本身的可連通性，那么在可用性上墩虹，一個本質(zhì)的問題嘱巾，如果注冊中心（Registry）本身完全宕機了憨琳，svcA 調(diào)用 svcB 鏈路應(yīng)該受到影響么？

image.png

是的旬昭，不應(yīng)該受到影響篙螟。

服務(wù)調(diào)用（請求響應(yīng)流）鏈路應(yīng)該是弱依賴注冊中心，必須僅在服務(wù)發(fā)布问拘，機器上下線遍略，服務(wù)擴縮容等必要時才依賴注冊中心。

這需要注冊中心仔細的設(shè)計自己提供的客戶端骤坐，客戶端中應(yīng)該有針對注冊中心服務(wù)完全不可用時做容災(zāi)的手段绪杏，例如設(shè)計客戶端緩存數(shù)據(jù)機制（我們稱之為 client snapshot）就是行之有效的手段。另外纽绍，注冊中心的 health check 機制也要仔細設(shè)計以便在這種情況不會出現(xiàn)諸如推空等情況的出現(xiàn)蕾久。

ZooKeeper 的原生客戶端并沒有這種能力，所以利用 ZooKeeper 實現(xiàn)注冊中心的時候我們一定要問自己拌夏，如果把 ZooKeeper 所有節(jié)點全干掉僧著，你生產(chǎn)上的所有服務(wù)調(diào)用鏈路能不受任何影響么？而且應(yīng)該定期就這一點做故障演練障簿。

你有沒有 ZooKeeper 的專家可依靠盹愚？

ZooKeeper 看似很簡單的一個產(chǎn)品，但在生產(chǎn)上大規(guī)模使用并且用好站故，并不是那么理所當(dāng)然的事情杯拐。如果你決定在生產(chǎn)中引入 ZooKeeper，你最好做好隨時向 ZooKeeper 技術(shù)專家尋求幫助的心理預(yù)期世蔗，最典型的表現(xiàn)是在兩個方面:
難以掌握的 Client/Session 狀態(tài)機
ZooKeeper 的原生客戶端絕對稱不上好用端逼，Curator 會好一點，但其實也好的有限污淋，要完全理解 ZooKeeper 客戶端與 Server 之間的交互協(xié)議也并不簡單顶滩，完全理解并掌握 ZooKeeper Client/Session 的狀態(tài)機（下圖）也并不是那么簡單明了:

zk狀態(tài)

難以承受的異常處理
我們在阿里巴巴內(nèi)部應(yīng)用接入 ZooKeeper 時叶摄，有一個《ZooKeeper 應(yīng)用接入必知必會》的 WIKI属韧，其中關(guān)于異常處理有過如下的論述:

如果說要選出應(yīng)用開發(fā)者在使用 ZooKeeper 的過程中，最需要了解清楚的事情蛤吓？那么根據(jù)我們之前的支持經(jīng)驗宵喂，一定是異常處理。

當(dāng)所有一切（宿主機会傲，磁盤锅棕，網(wǎng)絡(luò)等等）都很幸運的正常工作的時候，應(yīng)用與 ZooKeeper 可能也會運行的很好淌山，但不幸的是裸燎，我們整天會面對各種意外，而且這遵循墨菲定律艾岂，意料之外的壞事情總是在你最擔(dān)心的時候發(fā)生顺少。

所以務(wù)必仔細了解 ZooKeeper 在一些場景下會出現(xiàn)的異常和錯誤朋其，確保您正確的理解了這些異常和錯誤王浴，以及知道您的應(yīng)用如何正確的處理這些情況。

• ConnectionLossException 和 Disconnected 事件
  簡單來說梅猿，這是個可以在同一個 ZooKeeper Session 恢復(fù)的異常 (Recoverable), 但是應(yīng)用開發(fā)者需要負責(zé)將應(yīng)用恢復(fù)到正確的狀態(tài)氓辣。

發(fā)生這個異常的原因有很多，例如應(yīng)用機器與 ZooKeeper 節(jié)點之間網(wǎng)絡(luò)閃斷袱蚓，ZooKeeper 節(jié)點宕機钞啸，服務(wù)端 Full GC 時間超長，甚至你的應(yīng)用進程 Hang 死喇潘，應(yīng)用進程 Full GC 時間超長之后恢復(fù)都有可能体斩。

要理解這個異常，需要了解分布式應(yīng)用中的一個典型的問題颖低，如下圖：

image.png

在一個典型的客戶端請求絮吵、服務(wù)端響應(yīng)中，當(dāng)它們之間的長連接閃斷的時候忱屑，客戶端感知到這個閃斷事件的時候蹬敲，會處在一個比較尷尬的境地，那就是無法確定該事件發(fā)生時附近的那個請求到底處在什么狀態(tài)莺戒，Server 端到底收到這個請求了么伴嗡？已經(jīng)處理了么？因為無法確定這一點从铲，所以當(dāng)客戶端重新連接上 Server 之后瘪校，這個請求是否應(yīng)該重試（Retry）就也要打一個問號。

所以在處理連接斷開事件中名段，應(yīng)用開發(fā)者必須清楚處于閃斷附近的那個請求是什么（這常常難以判斷）渣淤，該請求是否是冪等的赏寇，對于業(yè)務(wù)請求在 Server 端服務(wù)處理上對于"僅處理一次" "最多處理一次" "最少處理一次"語義要有選擇和預(yù)期。

舉個例子价认，如果應(yīng)用在收到 ConnectionLossException 時嗅定，之前的請求是 Create 操作，那么應(yīng)用的 catch 到這個異常用踩，應(yīng)用一個可能的恢復(fù)邏輯就是渠退，判斷之前請求創(chuàng)建的節(jié)點的是否已經(jīng)存在了，如果存在就不要再創(chuàng)建了脐彩，否則就創(chuàng)建碎乃。

再比如，如果應(yīng)用使用了 exists Watch 去監(jiān)聽一個不存在的節(jié)點的創(chuàng)建的事件惠奸，那么在 ConnectionLossException 的期間梅誓，有可能遇到的情況是，在這個閃斷期間佛南，其它的客戶端進程可能已經(jīng)創(chuàng)建了節(jié)點梗掰，并且又已經(jīng)刪除了，那么對于當(dāng)前應(yīng)用來說嗅回，就 miss 了一次關(guān)心的節(jié)點的創(chuàng)建事件及穗，這種 miss 對應(yīng)用的影響是什么？是可以忍受的還是不可接受绵载？需要應(yīng)用開發(fā)者自己根據(jù)業(yè)務(wù)語義去評估和處理埂陆。

• SessionExpiredException 和 SessionExpired 事件
  Session 超時是一個不可恢復(fù)的異常，這是指應(yīng)用 Catch 到這個異常的時候娃豹，應(yīng)用不可能在同一個 Session 中恢復(fù)應(yīng)用狀態(tài)焚虱，必須要重新建立新 Session，老 Session 關(guān)聯(lián)的臨時節(jié)點也可能已經(jīng)失效懂版，擁有的鎖可能已經(jīng)失效鹃栽。...

我們阿里巴巴的小伙伴在自行嘗試使用 ZooKeeper 做服務(wù)發(fā)現(xiàn)的過程中，曾經(jīng)在我們的內(nèi)網(wǎng)技術(shù)論壇上總結(jié)過一篇自己踩坑的經(jīng)驗分享：
采用zookeeper的EPHEMERAL節(jié)點機制實現(xiàn)服務(wù)集群的陷阱

向左走定续，向右走

阿里巴巴是不是完全沒有使用 ZooKeeper谍咆？并不是！

熟悉阿里巴巴技術(shù)體系的都知道私股，其實阿里巴巴維護了目前國內(nèi)乃至世界上最大規(guī)模的 ZooKeeper 集群摹察，整體規(guī)模有近千臺的 ZooKeeper 服務(wù)節(jié)點。

同時阿里巴巴中間件內(nèi)部也維護了一個面向大規(guī)模生產(chǎn)的倡鲸、高可用供嚎、更易監(jiān)控和運維的 ZooKeeper 的代碼分支 TaoKeeper，如果以我們近 10 年在各個業(yè)務(wù)線和生產(chǎn)上使用 ZooKeeper 的實踐，給 ZooKeeper 用一個短語評價的話克滴，那么我們認為 ZooKeeper 應(yīng)該是 “The King Of Coordination for Big Data”逼争！

image.png

但是在交易場景交易鏈路上予借，在主業(yè)務(wù)數(shù)據(jù)存取越平，大規(guī)模服務(wù)發(fā)現(xiàn)、大規(guī)模健康監(jiān)測等方面有天然的短板灵迫，應(yīng)該竭力避免在這些場景下引入 ZooKeeper秦叛，在阿里巴巴的生產(chǎn)實踐中，應(yīng)用對 ZooKeeper 申請使用的時候要進行嚴格的場景龟再、容量书闸、SLA 需求的評估尼变。

所以可以使用 ZooKeeper利凑，但是大數(shù)據(jù)請向左，而交易則向右嫌术，分布式協(xié)調(diào)向左哀澈，服務(wù)發(fā)現(xiàn)向右。

總結(jié)：

感謝你耐心的閱讀到這里度气，至此割按，我相信你已經(jīng)理解，我們寫這篇文章并不是全盤否定 ZooKeeper磷籍，而只是根據(jù)我們阿里巴巴近 10 年來在大規(guī)模服務(wù)化上的生產(chǎn)實踐适荣，對我們在服務(wù)發(fā)現(xiàn)和注冊中心設(shè)計及使用上的經(jīng)驗教訓(xùn)進行一個總結(jié)，希望對業(yè)界就如何更好的使用 ZooKeeper院领，如何更好的設(shè)計自己的服務(wù)注冊中心有所啟發(fā)和幫助弛矛。

最后，條條大路通羅馬比然，衷心祝愿你的注冊中心直接就誕生在羅馬丈氓。

參考文章

[1]https://medium.com/knerd/eureka-why-you-shouldnt-use-zookeeper-for-service-discovery-4932c5c7e764

[2]https://yq.aliyun.com/articles/227260