建站
咨詢
售后
建站咨詢
新聞中心
RPC的目的，是將遠程調(diào)用變得像本地調(diào)用一樣簡單方便，主要由客戶端、服務端、注冊中心三部分組成。
創(chuàng)新互聯(lián)建站"三網(wǎng)合一"的企業(yè)建站思路。企業(yè)可建設擁有電腦版、微信版、手機版的企業(yè)網(wǎng)站。實現(xiàn)跨屏營銷，產(chǎn)品發(fā)布一步更新，電腦網(wǎng)絡+移動網(wǎng)絡一網(wǎng)打盡，滿足企業(yè)的營銷需求！創(chuàng)新互聯(lián)建站具備承接各種類型的網(wǎng)站制作、網(wǎng)站設計項目的能力。經(jīng)過十多年的努力的開拓，為不同行業(yè)的企事業(yè)單位提供了優(yōu)質(zhì)的服務，并獲得了客戶的一致好評。
那么，服務端發(fā)布的接口怎么向客戶端暴露？客戶端怎么獲取到服務端的地址并創(chuàng)建連接執(zhí)行調(diào)用邏輯呢？
本篇將帶大家 通過分析一個由Zookeeper引發(fā)的全鏈路服務雪崩的真實案例，來說明注冊中心的生產(chǎn)場景訴求和選型原則。
0.1注冊中心
如圖所示
Provider 主要向注冊中心進行服務注冊，以及上報服務節(jié)點心跳。
Consumer 需要向注冊中心訂閱感興趣的服務，將對應服務的節(jié)點信息緩存到本地，同時接受注冊中心下發(fā)的服務變動通知。
注冊中心 的職權也很明確了，就是維護服務信息以及服務實例節(jié)點信息，同時監(jiān)測服務節(jié)點心跳，確認節(jié)點狀態(tài)，在節(jié)點狀態(tài)不健康時，從實例列表中剔除；同時在節(jié)點列表變動時，負責通知訂閱者，以實現(xiàn)服務的及時更新和數(shù)據(jù)一致性
0.2Zookeeper 注冊中心實現(xiàn)方案
ZK曾經(jīng)真的非?；?，當然現(xiàn)在也不差。很多年之前，同事曾經(jīng)笑稱，只要架構里用上ZK，就可以叫分布式。
ZK是經(jīng)常被提及的注冊中心選型。那么ZK怎么實現(xiàn)注冊中心呢？
節(jié)點創(chuàng)建的能力
持久化節(jié)點。在節(jié)點創(chuàng)建后，就一直存在，直到有刪除操作來主動清除這個節(jié)點。
臨時節(jié)點。將自身的生命周期和客戶端狀態(tài)綁定。如果客戶端會話失效，那么這個節(jié)點就會自動被清除掉。注意，這里提到的是會話失效，而非連接斷開。
監(jiān)聽通知的能力
也就是Watch機制。一個zk的節(jié)點可以被監(jiān)控，包括這個目錄中存儲的數(shù)據(jù)的修改，子節(jié)點目錄的變化，一旦變化可以通知設置監(jiān)控的客戶端。
這個功能是zookeeper對于應用最重要的特性，通過這個特性可以實現(xiàn)的功能包括配置的集中管理，集群管理，分布式鎖等等。
ZK的上述兩個關鍵能力，讓其成為注冊中心成為可能。
Zookeeper注冊中心
如上圖所示，ZK創(chuàng)建了Service的持久化節(jié)點，在Service下創(chuàng)建了Provider和Consumer兩個子節(jié)點，也是持久化的；在Provider和Consumer下掛著很多臨時節(jié)點，每一個臨時節(jié)點，代表一個應用實例。這樣方便根據(jù)實例狀態(tài)進行動態(tài)增減。然后用wtach機制來監(jiān)聽服務端心跳，通知客戶端服務節(jié)點的變動，從而實現(xiàn)注冊中心的整個能力。
0.3用Zookeeper真的合適么
前些時候，一篇阿里為什么不用zookeeper做服務發(fā)現(xiàn)的文章被紛紛傳閱。這里，我們對涉及到主要觀點再做下簡要闡述：
1、注冊中心的高可用訴求
問：CAP中注冊中心一定要保證的是誰？
是分區(qū)容錯性。
分布式服務依賴網(wǎng)絡進行節(jié)點連通，在遇到任何網(wǎng)絡分區(qū)故障時，仍然需要能夠保證系統(tǒng)可以對外提供服務（一致性 或 可用性的服務），除非是整個網(wǎng)絡環(huán)境都發(fā)生了故障。
來源：www.w3cschool.cn/zookeeper/
我們不允許當節(jié)點間通信出現(xiàn)故障時，被孤立節(jié)點都不能提供服務。最簡單的，可以讓所有節(jié)點擁有所有數(shù)據(jù)。
問：在分區(qū)容錯前提下，注冊中心需要保的是一致性還是可用性？
如果保證一致性，是否可以滿足我們對系統(tǒng)的訴求呢。
來源：infoq.cn/article/why-doesnot-alibaba-use-zookeeper
如圖，假如機房3 內(nèi)部署了ServiceA，ServiceB，連接ZK5，由于發(fā)生網(wǎng)絡異常，ZK5節(jié)點無法工作，則serviceB的實例都無法進行注冊，處于機房3內(nèi)的serviceA , 無法正常調(diào)用ServiceB的任何實例，這個是我們不希望看到的。
而如果保證可用性，因為機房內(nèi)部各節(jié)點是連通的，因此，調(diào)用無影響，這才更符合我們的希望。
然而，zookeeper實際上實現(xiàn)的是CP原則。當在Leader選舉過程中或一些極端情況下，整個服務是不可用的。
但是我們對于注冊中心的可用性訴求，要比數(shù)據(jù)一致性要大的多。也可以說，生產(chǎn)環(huán)境，我們是無法容忍注冊中心無法保證可用性。這對實際生產(chǎn)的影響是災難性的。
2、注冊中心的容災訴求
在實踐中，注冊中心不能因為自身的任何原因破壞服務之間本身的可連通性。所以，如果整個注冊中心宕機了呢？
但是，zookeeper是無法實現(xiàn)跨機房、跨地域容災的。
因為，它只能存在一個leader。
3、服務規(guī)模、容量的增長
互聯(lián)網(wǎng)的發(fā)展，有一定的偶發(fā)性，現(xiàn)在的節(jié)點上限、帶寬能滿足業(yè)務發(fā)展，1年后也能滿足么? 3年后呢？
當扛不住后，ZK能水平擴展么？
0.4Zookeeper導致的鏈路雪崩回顧
可能有的人對上述提及的點覺得很有道理，但是沒有多少實際感受。
然而，對于親身經(jīng)歷過2015年JD 大促時全鏈路雪崩的我來說，卻感觸頗深。
雖然那時候的我，還是個剛參加工作不久的孩子。
歷史回顧：
那個風和日麗的上午，因為促銷活動早就漫天宣傳，我和組里的大佬們，早早的就坐在電腦前監(jiān)控系統(tǒng)指標。
9、10點鐘，突然有一部分系統(tǒng)報警變多，其中的一部分機器頻繁報警--連不上注冊中心。
正促銷呢，快，重啟一下，試試能不能解決。
然而沒用，更多的服務，以及更多的節(jié)點出現(xiàn)問題，異常從固定的機房擴展到了全部節(jié)點。
我們知道，注冊中心應該是全掛了。
不斷的重啟希望重連注冊中心，然并卵。
后來有平臺的同學說先暫時不要重啟，等待通知。經(jīng)過漫長的等待，終于，可以重啟了，果然，都連上了，但是，黃花菜。。。
到底發(fā)生了什么：
剛開始，一定是注冊中心某一節(jié)點掛了，是因為秒殺活動等節(jié)點大量擴容，還是帶寬打滿現(xiàn)在不得而知了，總之是掛了。
因為Zookeeper保證的是CP，那此時只有連接Leader的那些節(jié)點能提供服務。所以，出現(xiàn)問題的機房，雖然業(yè)務服務器都沒問題，但是沒法提供服務。
可是，用戶請求不會少，大量的請求被分流到了正常的機房的服務器上，業(yè)務系統(tǒng)扛不住掛了。連帶著吧注冊中心也沖垮了。
然而，ZK不保證可用性，在選舉Leader等情況下是沒法正常服務的。
所以，大量的業(yè)務系統(tǒng)同一時間想通過重啟重連注冊中心，要么是連不上，要么，大量寫操作一起去注冊服務節(jié)點，再次把注冊中心沖垮。
畢竟，想要保證在高并發(fā)情況下節(jié)點創(chuàng)建的全局唯一，必然要付出更多的系統(tǒng)資源。
惡性循環(huán)出現(xiàn)了，越重啟，越起不來。。。
所以，后面當平臺要求分批重啟，才使得注冊中心得以恢復正常。
0.5注冊中心的選型
綜上所述，注冊中心是需要保證AP原則，需要考慮擴容和容災。
JD的注冊中心優(yōu)化方案：
用mysql+redis 的KV形式，代替了zookeeper的樹狀形式；用戶注冊中心尋址來對注冊中心分片，以實現(xiàn)水平擴展，并支持容災。
Eureka2.0的實現(xiàn)
Eureka2.0在方案上支持讀寫集群的分離，這個思路也被螞蟻開源的sofa注冊中心中采用。
其實，大概瀏覽一下就會發(fā)現(xiàn)，當前比較火的開源注冊中心，其實都是按高可用，可擴展，可容災恢復的方向上進行的。
摘自：blog.csdn.net/fly910905/article/details/100023415
新聞名稱：高并發(fā)整體可用性：細說歷經(jīng)磨難的注冊中心選型
當前鏈接：http://m.5511xx.com/article/djjehpo.html
