[[418629]]

 RPC的目的，是將遠(yuǎn)程調(diào)用變得像本地調(diào)用一樣簡(jiǎn)單方便，主要由客戶端、服務(wù)端、注冊(cè)中心三部分組成。

那么，服務(wù)端發(fā)布的接口怎么向客戶端暴露？客戶端怎么獲取到服務(wù)端的地址并創(chuàng)建連接執(zhí)行調(diào)用邏輯呢？

本篇將帶大家 通過分析一個(gè)由Zookeeper引發(fā)的全鏈路服務(wù)雪崩的真實(shí)案例，來說明注冊(cè)中心的生產(chǎn)場(chǎng)景訴求和選型原則。

0.1注冊(cè)中心

如圖所示

Provider 主要向注冊(cè)中心進(jìn)行服務(wù)注冊(cè)，以及上報(bào)服務(wù)節(jié)點(diǎn)心跳。

Consumer 需要向注冊(cè)中心訂閱感興趣的服務(wù)，將對(duì)應(yīng)服務(wù)的節(jié)點(diǎn)信息緩存到本地，同時(shí)接受注冊(cè)中心下發(fā)的服務(wù)變動(dòng)通知。

注冊(cè)中心 的職權(quán)也很明確了，就是維護(hù)服務(wù)信息以及服務(wù)實(shí)例節(jié)點(diǎn)信息，同時(shí)監(jiān)測(cè)服務(wù)節(jié)點(diǎn)心跳，確認(rèn)節(jié)點(diǎn)狀態(tài)，在節(jié)點(diǎn)狀態(tài)不健康時(shí)，從實(shí)例列表中剔除；同時(shí)在節(jié)點(diǎn)列表變動(dòng)時(shí)，負(fù)責(zé)通知訂閱者，以實(shí)現(xiàn)服務(wù)的及時(shí)更新和數(shù)據(jù)一致性

0.2Zookeeper 注冊(cè)中心實(shí)現(xiàn)方案

ZK曾經(jīng)真的非常火，當(dāng)然現(xiàn)在也不差。很多年之前，同事曾經(jīng)笑稱，只要架構(gòu)里用上ZK，就可以叫分布式。

ZK是經(jīng)常被提及的注冊(cè)中心選型。那么ZK怎么實(shí)現(xiàn)注冊(cè)中心呢？

節(jié)點(diǎn)創(chuàng)建的能力

持久化節(jié)點(diǎn)。在節(jié)點(diǎn)創(chuàng)建后，就一直存在，直到有刪除操作來主動(dòng)清除這個(gè)節(jié)點(diǎn)。

臨時(shí)節(jié)點(diǎn)。將自身的生命周期和客戶端狀態(tài)綁定。如果客戶端會(huì)話失效，那么這個(gè)節(jié)點(diǎn)就會(huì)自動(dòng)被清除掉。注意，這里提到的是會(huì)話失效，而非連接斷開。

監(jiān)聽通知的能力

也就是Watch機(jī)制。一個(gè)zk的節(jié)點(diǎn)可以被監(jiān)控，包括這個(gè)目錄中存儲(chǔ)的數(shù)據(jù)的修改，子節(jié)點(diǎn)目錄的變化，一旦變化可以通知設(shè)置監(jiān)控的客戶端。

這個(gè)功能是zookeeper對(duì)于應(yīng)用最重要的特性，通過這個(gè)特性可以實(shí)現(xiàn)的功能包括配置的集中管理，集群管理，分布式鎖等等。

ZK的上述兩個(gè)關(guān)鍵能力，讓其成為注冊(cè)中心成為可能。

Zookeeper注冊(cè)中心

如上圖所示，ZK創(chuàng)建了Service的持久化節(jié)點(diǎn)，在Service下創(chuàng)建了Provider和Consumer兩個(gè)子節(jié)點(diǎn)，也是持久化的；在Provider和Consumer下掛著很多臨時(shí)節(jié)點(diǎn)，每一個(gè)臨時(shí)節(jié)點(diǎn)，代表一個(gè)應(yīng)用實(shí)例。這樣方便根據(jù)實(shí)例狀態(tài)進(jìn)行動(dòng)態(tài)增減。然后用wtach機(jī)制來監(jiān)聽服務(wù)端心跳，通知客戶端服務(wù)節(jié)點(diǎn)的變動(dòng)，從而實(shí)現(xiàn)注冊(cè)中心的整個(gè)能力。

0.3用Zookeeper真的合適么

前些時(shí)候，一篇阿里為什么不用zookeeper做服務(wù)發(fā)現(xiàn)的文章被紛紛傳閱。這里，我們對(duì)涉及到主要觀點(diǎn)再做下簡(jiǎn)要闡述：

1、注冊(cè)中心的高可用訴求

問：CAP中注冊(cè)中心一定要保證的是誰？

是分區(qū)容錯(cuò)性。

分布式服務(wù)依賴網(wǎng)絡(luò)進(jìn)行節(jié)點(diǎn)連通，在遇到任何網(wǎng)絡(luò)分區(qū)故障時(shí)，仍然需要能夠保證系統(tǒng)可以對(duì)外提供服務(wù)（一致性 或 可用性的服務(wù)），除非是整個(gè)網(wǎng)絡(luò)環(huán)境都發(fā)生了故障。

來源：www.w3cschool.cn/zookeeper/

我們不允許當(dāng)節(jié)點(diǎn)間通信出現(xiàn)故障時(shí)，被孤立節(jié)點(diǎn)都不能提供服務(wù)。最簡(jiǎn)單的，可以讓所有節(jié)點(diǎn)擁有所有數(shù)據(jù)。

問：在分區(qū)容錯(cuò)前提下，注冊(cè)中心需要保的是一致性還是可用性？

如果保證一致性，是否可以滿足我們對(duì)系統(tǒng)的訴求呢。

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

如圖，假如機(jī)房3 內(nèi)部署了ServiceA，ServiceB，連接ZK5，由于發(fā)生網(wǎng)絡(luò)異常，ZK5節(jié)點(diǎn)無法工作，則serviceB的實(shí)例都無法進(jìn)行注冊(cè)，處于機(jī)房3內(nèi)的serviceA , 無法正常調(diào)用ServiceB的任何實(shí)例，這個(gè)是我們不希望看到的。

而如果保證可用性，因?yàn)闄C(jī)房內(nèi)部各節(jié)點(diǎn)是連通的，因此，調(diào)用無影響，這才更符合我們的希望。

然而，zookeeper實(shí)際上實(shí)現(xiàn)的是CP原則。當(dāng)在Leader選舉過程中或一些極端情況下，整個(gè)服務(wù)是不可用的。

但是我們對(duì)于注冊(cè)中心的可用性訴求，要比數(shù)據(jù)一致性要大的多。也可以說，生產(chǎn)環(huán)境，我們是無法容忍注冊(cè)中心無法保證可用性。這對(duì)實(shí)際生產(chǎn)的影響是災(zāi)難性的。

2、注冊(cè)中心的容災(zāi)訴求

在實(shí)踐中，注冊(cè)中心不能因?yàn)樽陨淼娜魏卧蚱茐姆?wù)之間本身的可連通性。所以，如果整個(gè)注冊(cè)中心宕機(jī)了呢？

但是，zookeeper是無法實(shí)現(xiàn)跨機(jī)房、跨地域容災(zāi)的。

因?yàn)椋荒艽嬖谝粋€(gè)leader。

3、服務(wù)規(guī)模、容量的增長

互聯(lián)網(wǎng)的發(fā)展，有一定的偶發(fā)性，現(xiàn)在的節(jié)點(diǎn)上限、帶寬能滿足業(yè)務(wù)發(fā)展，1年后也能滿足么?  3年后呢？

當(dāng)扛不住后，ZK能水平擴(kuò)展么？

0.4Zookeeper導(dǎo)致的鏈路雪崩回顧

可能有的人對(duì)上述提及的點(diǎn)覺得很有道理，但是沒有多少實(shí)際感受。

然而，對(duì)于親身經(jīng)歷過2015年JD 大促時(shí)全鏈路雪崩的我來說，卻感觸頗深。

雖然那時(shí)候的我，還是個(gè)剛參加工作不久的孩子。

歷史回顧：

那個(gè)風(fēng)和日麗的上午，因?yàn)榇黉N活動(dòng)早就漫天宣傳，我和組里的大佬們，早早的就坐在電腦前監(jiān)控系統(tǒng)指標(biāo)。

9、10點(diǎn)鐘，突然有一部分系統(tǒng)報(bào)警變多，其中的一部分機(jī)器頻繁報(bào)警--連不上注冊(cè)中心。

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

然而沒用，更多的服務(wù)，以及更多的節(jié)點(diǎn)出現(xiàn)問題，異常從固定的機(jī)房擴(kuò)展到了全部節(jié)點(diǎn)。

我們知道，注冊(cè)中心應(yīng)該是全掛了。

不斷的重啟希望重連注冊(cè)中心，然并卵。

后來有平臺(tái)的同學(xué)說先暫時(shí)不要重啟，等待通知。經(jīng)過漫長的等待，終于，可以重啟了，果然，都連上了，但是，黃花菜。。。

到底發(fā)生了什么：

剛開始，一定是注冊(cè)中心某一節(jié)點(diǎn)掛了，是因?yàn)槊霘⒒顒?dòng)等節(jié)點(diǎn)大量擴(kuò)容，還是帶寬打滿現(xiàn)在不得而知了，總之是掛了。

因?yàn)閆ookeeper保證的是CP，那此時(shí)只有連接Leader的那些節(jié)點(diǎn)能提供服務(wù)。所以，出現(xiàn)問題的機(jī)房，雖然業(yè)務(wù)服務(wù)器都沒問題，但是沒法提供服務(wù)。

可是，用戶請(qǐng)求不會(huì)少，大量的請(qǐng)求被分流到了正常的機(jī)房的服務(wù)器上，業(yè)務(wù)系統(tǒng)扛不住掛了。連帶著吧注冊(cè)中心也沖垮了。

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

所以，大量的業(yè)務(wù)系統(tǒng)同一時(shí)間想通過重啟重連注冊(cè)中心，要么是連不上，要么，大量寫操作一起去注冊(cè)服務(wù)節(jié)點(diǎn)，再次把注冊(cè)中心沖垮。

畢竟，想要保證在高并發(fā)情況下節(jié)點(diǎn)創(chuàng)建的全局唯一，必然要付出更多的系統(tǒng)資源。

惡性循環(huán)出現(xiàn)了，越重啟，越起不來。。。

所以，后面當(dāng)平臺(tái)要求分批重啟，才使得注冊(cè)中心得以恢復(fù)正常。

0.5注冊(cè)中心的選型

綜上所述，注冊(cè)中心是需要保證AP原則，需要考慮擴(kuò)容和容災(zāi)。

JD的注冊(cè)中心優(yōu)化方案：

用mysql+redis 的KV形式，代替了zookeeper的樹狀形式；用戶注冊(cè)中心尋址來對(duì)注冊(cè)中心分片，以實(shí)現(xiàn)水平擴(kuò)展，并支持容災(zāi)。

Eureka2.0的實(shí)現(xiàn)

Eureka2.0在方案上支持讀寫集群的分離，這個(gè)思路也被螞蟻開源的sofa注冊(cè)中心中采用。

其實(shí)，大概瀏覽一下就會(huì)發(fā)現(xiàn)，當(dāng)前比較火的開源注冊(cè)中心，其實(shí)都是按高可用，可擴(kuò)展，可容災(zāi)恢復(fù)的方向上進(jìn)行的。

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