點擊下方“IT牧場”,選擇“設爲星標”
RPC的目的,是將遠程調用變得像本地調用一樣簡單方便,主要由客戶端、服務端、註冊中心三部分組成。
那麼,服務端發佈的接口怎麼向客戶端暴露?客戶端怎麼獲取到服務端的地址並創建連接執行調用邏輯呢?
本篇將帶大家 通過分析一個由Zookeeper引發的全鏈路服務雪崩的真實案例,來說明註冊中心的生產場景訴求和選型原則。
0.1註冊中心
如圖所示
Provider 主要向註冊中心進行服務註冊,以及上報服務節點心跳。
Consumer 需要向註冊中心訂閱感興趣的服務,將對應服務的節點信息緩存到本地,同時接受註冊中心下發的服務變動通知。
註冊中心 的職權也很明確了,就是維護服務信息以及服務實例節點信息,同時監測服務節點心跳,確認節點狀態,在節點狀態不健康時,從實例列表中剔除;同時在節點列表變動時,負責通知訂閱者,以實現服務的及時更新和數據一致性
0.2Zookeeper 註冊中心實現方案
ZK曾經真的非常火,當然現在也不差。很多年之前,同事曾經笑稱,只要架構裏用上ZK,就可以叫分佈式。
ZK是經常被提及的註冊中心選型。那麼ZK怎麼實現註冊中心呢?
節點創建的能力
持久化節點。在節點創建後,就一直存在,直到有刪除操作來主動清除這個節點。
臨時節點。將自身的生命週期和客戶端狀態綁定。如果客戶端會話失效,那麼這個節點就會自動被清除掉。注意,這裏提到的是會話失效,而非連接斷開。
監聽通知的能力
也就是Watch機制。一個zk的節點可以被監控,包括這個目錄中存儲的數據的修改,子節點目錄的變化,一旦變化可以通知設置監控的客戶端。
這個功能是zookeeper對於應用最重要的特性,通過這個特性可以實現的功能包括配置的集中管理,集羣管理,分佈式鎖等等。
ZK的上述兩個關鍵能力,讓其成爲註冊中心成爲可能。
如上圖所示,ZK創建了Service的持久化節點,在Service下創建了Provider和Consumer兩個子節點,也是持久化的;在Provider和Consumer下掛着很多臨時節點,每一個臨時節點,代表一個應用實例。這樣方便根據實例狀態進行動態增減。然後用wtach機制來監聽服務端心跳,通知客戶端服務節點的變動,從而實現註冊中心的整個能力。
0.3用Zookeeper真的合適麼
前些時候,一篇阿里爲什麼不用zookeeper做服務發現的文章被紛紛傳閱。這裏,我們對涉及到主要觀點再做下簡要闡述:
1、註冊中心的高可用訴求
問:CAP中註冊中心一定要保證的是誰?
是分區容錯性。
分佈式服務依賴網絡進行節點連通,在遇到任何網絡分區故障時,仍然需要能夠保證系統可以對外提供服務(一致性 或 可用性的服務),除非是整個網絡環境都發生了故障。
我們不允許當節點間通信出現故障時,被孤立節點都不能提供服務。最簡單的,可以讓所有節點擁有所有數據。
問:在分區容錯前提下,註冊中心需要保的是一致性還是可用性?
如果保證一致性,是否可以滿足我們對系統的訴求呢。
如圖,假如機房3 內部署了ServiceA,ServiceB,連接ZK5,由於發生網絡異常,ZK5節點無法工作,則serviceB的實例都無法進行註冊,處於機房3內的serviceA , 無法正常調用ServiceB的任何實例,這個是我們不希望看到的。
而如果保證可用性,因爲機房內部各節點是連通的,因此,調用無影響,這才更符合我們的希望。
然而,zookeeper實際上實現的是CP原則。當在Leader選舉過程中或一些極端情況下,整個服務是不可用的。
但是我們對於註冊中心的可用性訴求,要比數據一致性要大的多。也可以說,生產環境,我們是無法容忍註冊中心無法保證可用性。這對實際生產的影響是災難性的。
2、註冊中心的容災訴求
在實踐中,註冊中心不能因爲自身的任何原因破壞服務之間本身的可連通性。所以,如果整個註冊中心宕機了呢?
但是,zookeeper是無法實現跨機房、跨地域容災的。
因爲,它只能存在一個leader。
3、服務規模、容量的增長
互聯網的發展,有一定的偶發性,現在的節點上限、帶寬能滿足業務發展,1年後也能滿足麼? 3年後呢?
當扛不住後,ZK能水平擴展麼?
0.4Zookeeper導致的鏈路雪崩回顧
可能有的人對上述提及的點覺得很有道理,但是沒有多少實際感受。
然而,對於親身經歷過2015年JD 大促時全鏈路雪崩的我來說,卻感觸頗深。
雖然那時候的我,還是個剛參加工作不久的孩子。
歷史回顧:
那個風和日麗的上午,因爲促銷活動早就漫天宣傳,我和組裏的大佬們,早早的就坐在電腦前監控系統指標。
9、10點鐘,突然有一部分系統報警變多,其中的一部分機器頻繁報警--連不上註冊中心。
正促銷呢,快,重啓一下,試試能不能解決。
然而沒用,更多的服務,以及更多的節點出現問題,異常從固定的機房擴展到了全部節點。
我們知道,註冊中心應該是全掛了。
不斷的重啓希望重連註冊中心,然並卵。
後來有平臺的同學說先暫時不要重啓,等待通知。經過漫長的等待,終於,可以重啓了,果然,都連上了,但是,黃花菜。。。
到底發生了什麼:
剛開始,一定是註冊中心某一節點掛了,是因爲秒殺活動等節點大量擴容,還是帶寬打滿現在不得而知了,總之是掛了。
因爲Zookeeper保證的是CP,那此時只有連接Leader的那些節點能提供服務。所以,出現問題的機房,雖然業務服務器都沒問題,但是沒法提供服務。
可是,用戶請求不會少,大量的請求被分流到了正常的機房的服務器上,業務系統扛不住掛了。連帶着吧註冊中心也沖垮了。
然而,ZK不保證可用性,在選舉Leader等情況下是沒法正常服務的。
所以,大量的業務系統同一時間想通過重啓重連註冊中心,要麼是連不上,要麼,大量寫操作一起去註冊服務節點,再次把註冊中心沖垮。
畢竟,想要保證在高併發情況下節點創建的全局唯一,必然要付出更多的系統資源。
惡性循環出現了,越重啓,越起不來。。。
所以,後面當平臺要求分批重啓,才使得註冊中心得以恢復正常。
0.5註冊中心的選型
綜上所述,註冊中心是需要保證AP原則,需要考慮擴容和容災。
JD的註冊中心優化方案:
用mysql+redis 的KV形式,代替了zookeeper的樹狀形式;用戶註冊中心尋址來對註冊中心分片,以實現水平擴展,並支持容災。
Eureka2.0的實現
Eureka2.0在方案上支持讀寫集羣的分離,這個思路也被螞蟻開源的sofa註冊中心中採用。
其實,大概瀏覽一下就會發現,當前比較火的開源註冊中心,其實都是按高可用,可擴展,可容災恢復的方向上進行的。
本文分享自微信公衆號 - IT牧場(itmuch_com)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。