作者：中間件小哥
https://yq.aliyun.com/articles/601745
站在未來的路口，回望歷史的迷途，常常會很有意思，因為我們會不經意地興起瘋狂的念頭，例如如果當年某事提前發生了，而另外一件事又沒有發生會怎樣？
一如當年的奧匈帝國皇位繼承人斐迪南大公夫婦如果沒有被塞爾維亞族熱血青年普林西普槍殺會怎樣，又如若當年的丘老道沒有經過牛家村會怎樣？
2007年底，淘寶開啟一個叫做“五彩石”的內部重構專案，這個專案后來成為了淘寶服務化、面向分布式走自研之路，走出了互聯網中間件體系之始，而淘寶服務注冊中心ConfigServer于同年誕生，
2008年前后，Yahoo 這個曾經的互聯網巨頭開始逐漸在公開場合宣講自己的大資料分布式協調產品 ZooKeeper，這個產品參考了Google 發表的關于Chubby以及 Paxos 的論文，
2010年11月，ZooKeeper從 Apache Hadoop的子專案發展為 Apache的頂級專案，正式宣告 ZooKeeper成為一個工業級的成熟穩定的產品，
2011年，阿里巴巴開源Dubbo，為了更好開源，需要剝離與阿里內部系統的關系，Dubbo 支持了開源的 ZooKeeper 作為其注冊中心，后來在國內，在業界諸君的努力實踐下，Dubbo + ZooKeeper 的典型的服務化方案成就了 ZooKeeper 作為注冊中心的聲名，
2015年雙11，ConfigServer 服務內部近8個年頭過去了，阿里巴巴內部“服務規模”超幾百萬 ，以及推進“千里之外”的IDC容災技術戰略等，共同促使阿里巴巴內部開啟了 ConfigServer 2.0 到 ConfigServer 3.0 的架構升級之路，
時間走向2018年，站在10年的時間路口上，有多少人愿意在追逐日新月異的新潮技術概念的時候，稍微慢一下腳步，仔細凝視一下服務發現這個領域，有多少人想到過或者思考過一個問題：
服務發現，ZooKeeper 真的是最佳選擇么？
而回望歷史，我們也偶有迷思，在服務發現這個場景下，如果當年 ZooKeeper 的誕生之日比我們 HSF 的注冊中心 ConfigServer 早一點會怎樣？
我們會不會走向先使用ZooKeeper然后瘋狂改造與修補ZooKeeper以適應阿里巴巴的服務化場景與需求的彎路？
但是，站在今天和前人的肩膀上，我們從未如今天這樣堅定的認知到，在服務發現領域，ZooKeeper 根本就不能算是最佳的選擇，一如這些年一直與我們同行的Eureka以及這篇文章 Eureka! Why You Shouldn’t Use ZooKeeper for Service Discovery 那堅定的闡述一樣，為什么你不應該用 ZooKeeper 做服務發現！
吾道不孤矣，
注冊中心需求分析及關鍵設計考量
接下來，讓我們回歸對服務發現的需求分析，結合阿里巴巴在關鍵場景上的實踐，來一一分析，一起探討為何說 ZooKeeper 并不是最合適的注冊中心解決方案，
注冊中心是 CP 還是 AP 系統?
CAP 和 BASE 理論相信讀者都已經耳熟能詳，其業已成了指導分布式系統及互聯網應用構建的關鍵原則之一，在此不再贅述其理論，我們直接進入對注冊中心的資料一致性和可用性需求的分析:
- 資料一致性需求分析
注冊中心最本質的功能可以看成是一個Query函式 Si = F(service-name)，以 service-name 為查詢引數，service-name 對應的服務的可用的 endpoints (ip:port) 串列為回傳值.
注: 后文將 service 簡寫為 svc，
先來看看關鍵資料 endpoints (ip:port) 不一致性帶來的影響，即 CAP 中的 C 不滿足帶來的后果 :
如上圖所示，如果一個 svcB 部署了10個節點 (副本/Replica），如果對于同一個服務名 svcB, 呼叫者 svcA 的2個節點的2次查詢回傳了不一致的資料，例如: S1 = { ip1,ip2,ip3...,ip9 }, S2 = { ip2,ip3,....ip10 }, 那么這次不一致帶來的影響是什么？
相信你一定已經看出來了，svcB 的各個節點流量會有一點不均衡，
ip1和ip10相對其它8個節點{ip2...ip9}，請求流量小了一點，但很明顯，在分布式系統中，即使是對等部署的服務，因為請求到達的時間，硬體的狀態，作業系統的調度，虛擬機的 GC 等，任何一個時間點，這些對等部署的節點狀態也不可能完全一致，而流量不一致的情況下，只要注冊中心在SLA承諾的時間內（例如1s內）將資料收斂到一致狀態（即滿足最終一致），流量將很快趨于統計學意義上的一致，所以注冊中心以最終一致的模型設計在生產實踐中完全可以接受，
- 磁區容忍及可用性需求分析
接下來我們看一下網路磁區（Network Partition）情況下注冊中心不可用對服務呼叫產生的影響，即 CAP 中的A不滿足時帶來的影響，
考慮一個典型的ZooKeeper三機房容災5節點部署結構 (即2-2-1結構)，如下圖:
當機房3出現網路磁區(Network Partitioned)的時候，即機房3在網路上成了孤島，我們知道雖然整體 ZooKeeper 服務是可用的，但是節點ZK5是不可寫的，因為聯系不上 Leader，
也就是說，這時候機房3的應用服務 svcB 是不可以新部署，重新啟動，擴容或者縮容的，但是站在網路和服務呼叫的角度看，機房3的 svcA 雖然無法呼叫機房1和機房2的 svcB,但是與機房3的svcB之間的網路明明是 OK 的啊，為什么不讓我呼叫本機房的服務？
現在因為注冊中心自身為了保腦裂(P)下的資料一致性（C）而放棄了可用性，導致了同機房的服務之間出現了無法呼叫，這是絕對不允許的！可以說在實踐中，注冊中心不能因為自身的任何原因破壞服務之間本身的可連通性，這是注冊中心設計應該遵循的鐵律！ 后面在注冊中心客戶端災容上我們還會繼續討論，
同時我們再考慮一下這種情況下的資料不一致性，如果機房1，2，3之間都成了孤島，那么如果每個機房的svcA都只拿到本機房的 svcB 的ip串列，也即在各機房svcB 的ip串列資料完全不一致，影響是什么？
其實沒啥大影響，只是這種情況下，全都變成了同機房呼叫，我們在設計注冊中心的時候，有時候甚至會主動利用這種注冊中心的資料可以不一致性，來幫助應用主動做到同機房呼叫，從而優化服務呼叫鏈路 RT 的效果！
通過以上我們的闡述可以看到，在 CAP 的權衡中，注冊中心的可用性比資料強一致性更寶貴，所以整體設計更應該偏向 AP，而非 CP，資料不一致在可接受范圍，而P下舍棄A卻完全違反了注冊中心不能因為自身的任何原因破壞服務本身的可連通性的原則，
服務規模、容量、服務聯通性
你所在公司的“微服務”規模有多大？數百微服務？部署了上百個節點？那么3年后呢？互聯網是產生奇跡的地方，也許你的“服務”一夜之間就家喻戶曉，流量倍增，規模翻番！如果你想學習更多微服務，關注微信公眾號Java技術堆疊在后臺回復微服務即可，
當資料中心服務規模超過一定數量 (服務規模=F{服務pub數,服務sub數})，作為注冊中心的 ZooKeeper 很快就會像下圖的驢子一樣不堪重負
其實當ZooKeeper用對地方時，即用在粗粒度分布式鎖，分布式協調場景下，ZooKeeper 能支持的tps 和支撐的連接數是足夠用的，因為這些場景對于 ZooKeeper 的擴展性和容量訴求不是很強烈，
但在服務發現和健康監測場景下，隨著服務規模的增大，無論是應用頻繁發布時的服務注冊帶來的寫請求，還是刷毫秒級的服務健康狀態帶來的寫請求，還是恨不能整個資料中心的機器或者容器皆與注冊中心有長連接帶來的連接壓力上，ZooKeeper 很快就會力不從心，而 ZooKeeper 的寫并不是可擴展的，不可以通過加節點解決水平擴展性問題，
要想在 ZooKeeper 基礎上硬著頭皮解決服務規模的增長問題，一個實踐中可以考慮的方法是想辦法梳理業務，垂直劃分業務域，將其劃分到多個 ZooKeeper 注冊中心，但是作為提供通用服務的平臺機構組，因自己提供的服務能力不足要業務按照技術的指揮棒配合劃分治理業務，真的可行么？
而且這又違反了因為注冊中心自身的原因（能力不足）破壞了服務的可連通性，舉個簡單的例子，1個搜索業務，1個地圖業務，1個大文娛業務，1個游戲業務，他們之間的服務就應該老死不相往來么？也許今天是肯定的，那么明天呢，1年后呢，10年后呢？誰知道未來會要打通幾個業務域去做什么奇葩的業務創新？注冊中心作為基礎服務，無法預料未來的時候當然不能妨礙業務服務對未來固有聯通性的需求，
注冊中心需要持久存盤和事務日志么？
需要，也不需要，
我們知道 ZooKeeper 的 ZAB 協議對每一個寫請求，會在每個ZooKeeper節點上保持寫一個事務日志，同時再加上定期的將記憶體資料鏡像（Snapshot）到磁盤來保證資料的一致性和持久性，以及宕機之后的資料可恢復，這是非常好的特性，但是我們要問，在服務發現場景中，其最核心的資料-實時的健康的服務的地址串列真的需要資料持久化么？
對于這份資料，答案是否定的，
如上圖所示，如果 svcB 經歷了注冊服務(ip1)到擴容到2個節點（ip1，ip2）到因宕機縮容 (ip1 宕機），這個程序中，產生了3次針對 ZooKeeper 的寫操作，
但是仔細分析，通過事務日志，持久化連續記錄這個變化程序其實意義不大，因為在服務發現中，服務呼叫發起方更關注的是其要呼叫的服務的實時的地址串列和實時健康狀態，每次發起呼叫時，并不關心要呼叫的服務的歷史服務地址串列、過去的健康狀態，
但是為什么又說需要呢，因為一個完整的生產可用的注冊中心，除了服務的實時地址串列以及實時的健康狀態之外，還會存盤一些服務的元資料資訊，例如服務的版本，分組，所在的資料中心，權重，鑒權策略資訊，service label等元資訊，這些資料需要持久化存盤，并且注冊中心應該提供對這些元資訊的檢索的能力，
Service Health Check
使用 ZooKeeper 作為服務注冊中心時，服務的健康檢測常利用 ZooKeeper 的 Session 活性 Track機制 以及結合 Ephemeral ZNode的機制，簡單而言，就是將服務的健康監測系結在了 ZooKeeper 對于 Session 的健康監測上，或者說系結在TCP長鏈接活性探測上了，
這在很多時候也會造成致命的問題，ZK 與服務提供者機器之間的TCP長鏈接活性探測正常的時候，該服務就是健康的么？答案當然是否定的！注冊中心應該提供更豐富的健康監測方案，服務的健康與否的邏輯應該開放給服務提供方自己定義，而不是一刀切搞成了 TCP 活性檢測！
健康檢測的一大基本設計原則就是盡可能真實的反饋服務本身的真實健康狀態，否則一個不敢被服務呼叫者相信的健康狀態判定結果還不如沒有健康檢測，
注冊中心的容災考慮
前文提過，在實踐中，注冊中心不能因為自身的任何原因破壞服務之間本身的可連通性，那么在可用性上，一個本質的問題，如果注冊中心（Registry）本身完全宕機了，svcA 呼叫 svcB鏈路應該受到影響么？
是的，不應該受到影響，
服務呼叫（請求回應流）鏈路應該是弱依賴注冊中心，必須僅在服務發布，機器上下線，服務擴縮容等必要時才依賴注冊中心，
這需要注冊中心仔細的設計自己提供的客戶端，客戶端中應該有針對注冊中心服務完全不可用時做容災的手段，例如設計客戶端快取資料機制（我們稱之為 client snapshot）就是行之有效的手段，另外，注冊中心的 health check 機制也要仔細設計以便在這種情況不會出現諸如推空等情況的出現，
ZooKeeper的原生客戶端并沒有這種能力，所以利用 ZooKeeper 實作注冊中心的時候我們一定要問自己，如果把 ZooKeeper 所有節點全干掉，你生產上的所有服務呼叫鏈路能不受任何影響么？而且應該定期就這一點做故障演練，
你有沒有ZooKeeper的專家可依靠？
ZooKeeper 看似很簡單的一個產品，但在生產上大規模使用并且用好，并不是那么理所當然的事情，如果你決定在生產中引入 ZooKeeper，你最好做好隨時向 ZooKeeper 技術專家尋求幫助的心理預期，最典型的表現是在兩個方面:
- 難以掌握的Client/Session狀態機
ZooKeeper 的原生客戶端絕對稱不上好用，Curator 會好一點，但其實也好的有限，要完全理解 ZooKeeper 客戶端與 Server 之間的互動協議也并不簡單，完全理解并掌握 ZooKeeper Client/Session 的狀態機（下圖）也并不是那么簡單明了:
但基于 ZooKeeper 的服務發現方案卻是依賴 ZooKeeper 提供的長連接/Session管理，Ephemeral ZNode，Event&Notification, ping 機制上，所以要用好ZooKeeper 做服務發現，恰恰要理解這些 ZooKeeper 核心的機制原理，這有時候會讓你陷入暴躁，我只是想要個服務發現而已，怎么要知道這么多？而如果這些你都理解了并且不踩坑，恭喜你，你已經成為ZooKeeper的技術專家了，
- 難以承受的例外處理
我們在阿里巴巴內部應用接入 ZooKeeper 時，有一個《ZooKeeper 應用接入必知必會》的 WIKI，其中關于例外處理有過如下的論述:
如果說要選出應用開發者在使用ZooKeeper的程序中，最需要了解清楚的事情？那么根據我們之前的支持經驗，一定是例外處理，
當所有一切（宿主機，磁盤，網路等等）都很幸運的正常作業的時候，應用與ZooKeeper可能也會運行的很好，但不幸的是，我們整天會面對各種意外，而且這遵循墨菲定律，意料之外的壞事情總是在你最擔心的時候發生，
所以務必仔細了解 ZooKeeper 在一些場景下會出現的例外和錯誤，確保您正確的理解了這些例外和錯誤，以及知道您的應用如何正確的處理這些情況，
- ConnectionLossException 和 Disconnected 事件
簡單來說，這是個可以在同一個 ZooKeeper Session 恢復的例外(Recoverable), 但是應用開發者需要負責將應用恢復到正確的狀態，
發生這個例外的原因有很多，例如應用機器與ZooKeeper節點之間網路閃斷，ZooKeeper節點宕機，服務端Full GC時間超長，甚至你的應用行程Hang死，應用行程 Full GC 時間超長之后恢復都有可能，
要理解這個例外，需要了解分布式應用中的一個典型的問題，如下圖：
在一個典型的客戶端請求、服務端回應中，當它們之間的長連接閃斷的時候，客戶端感知到這個閃斷事件的時候，會處在一個比較尷尬的境地，那就是無法確定該事件發生時附近的那個請求到底處在什么狀態，Server端到底收到這個請求了么？已經處理了么？因為無法確定這一點，所以當客戶端重新連接上Server之后，這個請求是否應該重試（Retry）就也要打一個問號，
所以在處理連接斷開事件中，應用開發者必須清楚處于閃斷附近的那個請求是什么（這常常難以判斷），該請求是否是冪等的，對于業務請求在Server端服務處理上對于"僅處理一次" "最多處理一次" "最少處理一次"語意要有選擇和預期，
舉個例子，如果應用在收到 ConnectionLossException 時，之前的請求是Create操作，那么應用的catch到這個例外，應用一個可能的恢復邏輯就是，判斷之前請求創建的節點的是否已經存在了，如果存在就不要再創建了，否則就創建，
再比如，如果應用使用了exists Watch 去監聽一個不存在的節點的創建的事件，那么在ConnectionLossException的期間，有可能遇到的情況是，在這個閃斷期間，其它的客戶端行程可能已經創建了節點，并且又已經洗掉了，那么對于當前應用來說，就miss了一次關心的節點的創建事件，這種miss對應用的影響是什么？是可以忍受的還是不可接受？需要應用開發者自己根據業務語意去評估和處理，
- SessionExpiredException 和 SessionExpired 事件
Session 超時是一個不可恢復的例外，這是指應用Catch到這個例外的時候，應用不可能在同一個Session中恢復應用狀態，必須要重新建立新Session，老Session關聯的臨時節點也可能已經失效，擁有的鎖可能已經失效，...
阿里巴巴的小伙伴在自行嘗試使用 ZooKeeper 做服務發現的程序中，曾經在我們的內網技術論壇上總結過一篇自己踩坑的經驗分享
在該文中中肯的提到:
... 在編碼程序中發現很多可能存在的陷阱，毛估估，第一次使用zk來實作集群管理的人應該有80%以上會掉坑，有些坑比較隱蔽，在網路問題或者例外的場景時才會出現，可能很長一段時間才會暴露出來 ...
向左走，向右走
阿里巴巴是不是完全沒有使用 ZooKeeper？并不是，
熟悉阿里巴巴技術體系的都知道，其實阿里巴巴維護了目前國內最大規模的ZooKeeper集群，整體規模有近千臺的ZooKeeper服務節點，
同時阿里巴巴中間件內部也維護了一個面向大規模生產的、高可用、更易監控和運維的ZooKeeper的代碼分支TaoKeeper，如果以我們近10年在各個業務線和生產上使用ZooKeeper的實踐，給ZooKeeper 用一個短語評價的話，那么我們認為ZooKeeper應該是 “The King Of Coordination for Big Data”！
在粗粒度分布式鎖，Zookeeper實作分布式鎖這篇推薦看下，分布式選主，主備高可用切換等不需要高TPS 支持的場景下有不可替代的作用，而這些需求往往多集中在大資料、離線任務等相關的業務領域，因為大資料領域，講究分割資料集，并且大部分時間分任務多行程/執行緒并行處理這些資料集，但是總是有一些點上需要將這些任務和行程統一協調，這時候就是 ZooKeeper 發揮巨大作用的用武之地，
但是在交易場景交易鏈路上，在主業務資料存取，大規模服務發現、大規模健康監測等方面有天然的短板，應該竭力避免在這些場景下引入 ZooKeeper，在阿里巴巴的生產實踐中，應用對ZooKeeper申請使用的時候要進行嚴格的場景、容量、SLA需求的評估，
所以可以使用 ZooKeeper，但是大資料請向左，而交易則向右，分布式協調向左，服務發現向右，
結語
感謝你耐心的閱讀到這里，至此，我相信你已經理解，我們寫這篇文章并不是全盤否定 ZooKeeper，而只是根據我們阿里巴巴在近10年來在大規模服務化上的生產實踐，對我們在服務發現和注冊中心設計及使用上的經驗教訓進行一個總結，希望對業界就如何更好的使用 ZooKeeper，如何更好的設計自己的服務注冊中心有所啟發和幫助，
最后，條條大路通羅馬，衷心祝愿你的注冊中心直接就誕生在羅馬，
關注公眾號Java技術堆疊回復"面試"獲取我整理的2020最全面試題及答案，
推薦去我的博客閱讀更多：
1.Java JVM、集合、多執行緒、新特性系列教程
2.Spring MVC、Spring Boot、Spring Cloud 系列教程
3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程
4.Java、后端、架構、阿里巴巴等大廠最新面試題
覺得不錯，別忘了點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/146909.html
標籤：Java
上一篇：Java 在 PDF 中繪制形狀