高併發整體可用性：細說歷經磨難的註冊中心選型

RPC 的目的，是將遠程調用變得像本地調用一樣簡單方便，主要由客戶端、服務端、註冊中心三部分組成。

那麼，服務端發佈的接口怎麼向客戶端暴露？客戶端怎麼獲取到服務端的地址並創建連接執行調用邏輯呢？

本篇將帶大家 通過分析一個由 Zookeeper 引發的全鏈路服務雪崩的真實案例，來說明註冊中心的生產場景訴求和選型原則。

註冊中心

如圖所示

Provider 主要向註冊中心進行服務註冊，以及上報服務節點心跳。

Consumer 需要向註冊中心訂閱感興趣的服務，將對應服務的節點信息緩存到本地，同時接受註冊中心下發的服務變動通知。

註冊中心 的職權也很明確了，就是維護服務信息以及服務實例節點信息，同時監測服務節點心跳，確認節點狀態，在節點狀態不健康時，從實例列表中剔除；同時在節點列表變動時，負責通知訂閱者，以實現服務的及時更新和數據一致性

Zookeeper 註冊中心實現方案

ZK 曾經真的非常火，當然現在也不差。很多年之前，同事曾經笑稱，只要架構裏用上 ZK，就可以叫分佈式。

ZK 是經常被提及的註冊中心選型。那麼 ZK 怎麼實現註冊中心呢？

節點創建的能力

持久化節點。在節點創建後，就一直存在，直到有刪除操作來主動清除這個節點。

臨時節點。將自身的生命週期和客戶端狀態綁定。如果客戶端會話失效，那麼這個節點就會自動被清除掉。注意，這裏提到的是會話失效，而非連接斷開。

監聽通知的能力

也就是 Watch 機制。一個 zk 的節點可以被監控，包括這個目錄中存儲的數據的修改，子節點目錄的變化，一旦變化可以通知設置監控的客戶端。
這個功能是 zookeeper 對於應用最重要的特性，通過這個特性可以實現的功能包括配置的集中管理，集羣管理，分佈式鎖等等。

ZK 的上述兩個關鍵能力，讓其成爲註冊中心成爲可能。

Zookeeper 註冊中心

如上圖所示，ZK 創建了 Service 的持久化節點，在 Service 下創建了 Provider 和 Consumer 兩個子節點，也是持久化的；在 Provider 和 Consumer 下掛着很多臨時節點，每一個臨時節點，代表一個應用實例。這樣方便根據實例狀態進行動態增減。然後用 wtach 機制來監聽服務端心跳，通知客戶端服務節點的變動，從而實現註冊中心的整個能力。

用 Zookeeper 真的合適麼

前些時候，一篇阿里爲什麼不用 zookeeper 做服務發現的文章被紛紛傳閱。這裏，我們對涉及到主要觀點再做下簡要闡述：

1、註冊中心的高可用訴求

問：CAP 中註冊中心一定要保證的是誰？

是分區容錯性。

分佈式服務依賴網絡進行節點連通，在遇到任何網絡分區故障時，仍然需要能夠保證系統可以對外提供服務（一致性 或 可用性的服務），除非是整個網絡環境都發生了故障。

來源：www.w3cschool.cn/zookeeper/

我們不允許當節點間通信出現故障時，被孤立節點都不能提供服務。最簡單的，可以讓所有節點擁有所有數據。

問：在分區容錯前提下，註冊中心需要保的是一致性還是可用性？

如果保證一致性，是否可以滿足我們對系統的訴求呢。

來源：infoq.cn/article/why-doesnot-alibaba-use-zookeeper

如圖，假如機房 3 內部署了 ServiceA，ServiceB，連接 ZK5，由於發生網絡異常，ZK5 節點無法工作，則 serviceB 的實例都無法進行註冊，處於機房 3 內的 serviceA , 無法正常調用 ServiceB 的任何實例，這個是我們不希望看到的。

而如果保證可用性，因爲機房內部各節點是連通的，因此，調用無影響，這才更符合我們的希望。

然而，zookeeper 實際上實現的是 CP 原則。當在 Leader 選舉過程中或一些極端情況下，整個服務是不可用的。

但是我們對於註冊中心的可用性訴求，要比數據一致性要大的多。也可以說，生產環境，我們是無法容忍註冊中心無法保證可用性。這對實際生產的影響是災難性的。

2、註冊中心的容災訴求

在實踐中，註冊中心不能因爲自身的任何原因破壞服務之間本身的可連通性。所以，如果整個註冊中心宕機了呢？

但是，zookeeper 是無法實現跨機房、跨地域容災的。

因爲，它只能存在一個 leader。

3、服務規模、容量的增長

互聯網的發展，有一定的偶發性，現在的節點上限、帶寬能滿足業務發展，1 年後也能滿足麼?  3 年後呢？

當扛不住後，ZK 能水平擴展麼？

Zookeeper 導致的鏈路雪崩回顧

可能有的人對上述提及的點覺得很有道理，但是沒有多少實際感受。

然而，對於親身經歷過 2015 年 JD 大促時全鏈路雪崩的我來說，卻感觸頗深。

雖然那時候的我，還是個剛參加工作不久的孩子。

歷史回顧：

那個風和日麗的上午，因爲促銷活動早就漫天宣傳，我和組裏的大佬們，早早的就坐在電腦前監控系統指標。

9、10 點鐘，突然有一部分系統報警變多，其中的一部分機器頻繁報警 -- 連不上註冊中心。

正促銷呢，快，重啓一下，試試能不能解決。

然而沒用，更多的服務，以及更多的節點出現問題，異常從固定的機房擴展到了全部節點。

我們知道，註冊中心應該是全掛了。

不斷的重啓希望重連註冊中心，然並卵。

後來有平臺的同學說先暫時不要重啓，等待通知。經過漫長的等待，終於，可以重啓了，果然，都連上了，但是，黃花菜。。。

到底發生了什麼：

剛開始，一定是註冊中心某一節點掛了，是因爲秒殺活動等節點大量擴容，還是帶寬打滿現在不得而知了，總之是掛了。

因爲 Zookeeper 保證的是 CP，那此時只有連接 Leader 的那些節點能提供服務。所以，出現問題的機房，雖然業務服務器都沒問題，但是沒法提供服務。

可是，用戶請求不會少，大量的請求被分流到了正常的機房的服務器上，業務系統扛不住掛了。連帶着吧註冊中心也沖垮了。

然而，ZK 不保證可用性，在選舉 Leader 等情況下是沒法正常服務的。

所以，大量的業務系統同一時間想通過重啓重連註冊中心，要麼是連不上，要麼，大量寫操作一起去註冊服務節點，再次把註冊中心沖垮。

畢竟，想要保證在高併發情況下節點創建的全局唯一，必然要付出更多的系統資源。

惡性循環出現了，越重啓，越起不來。。。

所以，後面當平臺要求分批重啓，才使得註冊中心得以恢復正常。

註冊中心的選型

綜上所述，註冊中心是需要保證 AP 原則，需要考慮擴容和容災。

JD 的註冊中心優化方案：

用 mysql+redis 的 KV 形式，代替了 zookeeper 的樹狀形式；用戶註冊中心尋址來對註冊中心分片，以實現水平擴展，並支持容災。

Eureka2.0 的實現

Eureka2.0 在方案上支持讀寫集羣的分離，這個思路也被螞蟻開源的 sofa 註冊中心中採用。

其實，大概瀏覽一下就會發現，當前比較火的開源註冊中心，其實都是按高可用，可擴展，可容災恢復的方向上進行的。

摘自：blog.csdn.net/fly910905/article/details/100023415

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/hobJs1dRuR8A5lVWuY_t3w