【Java高階必備】如何優化Spring Cloud微服務註冊中心架構？【石杉的架構筆記】

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）

週一至週五早8點半！精品技術文章準時送上！

精品學習資料獲取通道，參見文末

目錄

一、再回顧：什麼是服務註冊中心？

二、Consul服務註冊中心的總體架構

三、Consul如何經過Raft協議實現強一致性？

四、Consul如何經過Agent實現分佈式健康檢查？

「 上一篇文章：尷尬了！Spring Cloud微服務註冊中心Eureka 2.x中止維護了咋辦？，咱們給你們說了一下Spring Cloud服務註冊中心的一些問題。

若是用Eureka做爲其註冊中心的話，不少同窗都以爲內心沒底，因此如今不少公司都開始使用Consul做爲其註冊中心。

那麼這篇文章咱們就來給你們說說：Consul這種服務註冊中心的架構是如何設計的？

一、再回顧：什麼是服務註冊中心？

先回顧一下什麼叫作服務註冊中心？

顧名思義，假設你有一個分佈式系統，裏面包含了多個服務，部署在不一樣的機器上，而後這些不一樣機器上的服務之間要互相調用。

舉個現實點的例子吧，好比電商系統裏的訂單服務須要調用庫存服務，以下圖所示。

如今的問題在於，訂單服務在192.168.31.154這臺機器上，庫存服務在192.137.1.33這臺機器上。

如今訂單服務是想要調用庫存服務，可是他並不知道庫存服務在哪臺機器上啊！畢竟人家都是在不一樣機器上的。

因此這個時候就須要服務註冊中心出場了，這個時候你的系統架構中須要引入獨立部署在一臺機器上的服務註冊中心，以下圖所示。

而後訂單服務、庫存服務之類的兄弟，都須要配置上服務註冊中心部署在哪臺機器上，好比192.168.31.45這臺機器。

接着訂單服務、庫存服務他們本身啓動的時候，就得發送請求到到服務註冊中心上去進行服務註冊。

也就是說，得告訴服務註冊中心，本身是哪一個服務，而後本身部署在哪臺機器上。

而後服務註冊中心會把你們註冊上來的信息放在註冊表裏，以下圖。

接着訂單服務假如想要調用庫存服務，那麼就找服務註冊中心問問：能不能告訴我庫存服務部署在哪臺機器上？

服務註冊中心是知道這個信息的，因此就會告訴訂單服務：庫存服務部署在192.1371.133這臺機器上，你就給這臺機器發送請求吧。

而後，訂單服務就能夠往庫存服務的那臺機器發送請求了，完成了服務間的調用。

整個過程，以下圖所示：

上述就是服務註冊中心的做用、地位以及意義，如今你們應該知道服務註冊中心的做用了吧。

好！接着咱們就來看看Consul做爲服務註冊中心，他的架構設計原理是什麼？

二、Consul服務註冊中心的總體架構

若是要基於Consul做爲服務註冊中心，那麼首先必須在每一個服務所在的機器上部署一個Consul Agent，做爲一個服務所在機器的代理。

而後還得在多臺機器上部署Consul Server，這就是核心的服務註冊中心。

這個Consul Agent能夠用來收集你的服務信息而後發送給Consul Server，還會對你的服務不停的發送請求檢查他是否健康。

而後你要發現別的服務的時候，Consul Agent也會幫你轉發請求給Consul Server，查詢其餘服務所在機器。

Consul Server通常要求部署3~5臺機器，以保證高可用以及數據一致性。

他們之間會自動實現數據同步，並且Consul Server集羣會自動選舉出一臺機器做爲leader，其餘的Consul Server就是follower。

我們看下面的圖，先感覺一下這個Consul他總體的架構。

三、Consul如何經過Raft協議實現強一致性？

首先上篇文章：尷尬了！Spring Cloud微服務註冊中心Eureka 2.x中止維護了咋辦？已經說了，Eureka服務註冊中心是不保證數據一致性的。

這樣的話，極可能你註冊的服務，其餘人是發現不了的，或者很遲才能發現。

OK，那麼這裏就來討論一下Consul是如何實現數據一致性的。

首先，你們知道Consul Server是部署集羣的，並且他會選舉出來一臺Server做爲Leader。

接下來各個服務發送的註冊請求都會落地給Leader，由Leader同步給其餘Follower。

因此首先第一點，Leader Server是絕對有最新的服務註冊信息的，是否是？

好比庫存服務發起註冊了，那麼Leader Server上必定有庫存服務的註冊信息。

接着若是好比訂單服務要發現庫存服務的話，這個查詢請求會發送給Leader Server。

這樣服務註冊和發現，都是經過一臺Leader Server來進行的，就能夠保證服務註冊數據的強一致性了，你們看下圖。

接着你們想，假如說庫存服務在註冊的時候數據剛寫到Leader Server，結果Leader Server就宕機了，這時候怎麼辦？

那麼此時這條註冊數據就丟失了，訂單服務就無法發現那個庫存服務了。不要緊，這裏Consul會基於Raft協議來解決這個問題。

首先，庫存服務註冊到Leader Server的時候，會採起Raft協議，要求必須讓Leader Server把這條註冊數據複製給大部分的Follower Server纔算成功。

這就保證了，若是你認爲本身註冊成功了，那麼必然是多臺Consul Server都有這條註冊數據了。

若是你剛發送給Leader Server他本身就宕機了，那麼此次註冊會認爲失敗。

此時，Consul Server集羣會從新選舉一個Leader Server出來，你須要再次從新註冊。

這樣就能夠保證你註冊成功的數據絕對不會丟，而後別人發現服務的時候必定能夠從Leader Server上獲取到最新的強一致的註冊數據。

整個過程，以下圖所示：

上面的圖就能夠看到，只要你註冊的時候基於Raft協議強制同步到大多數Server，哪怕是Leader掛了，也會選舉新的Leader。

這樣就可讓別人重新的Leader Server來發現你這個服務，因此數據是絕對強一致的。

四、Consul如何經過Agent實現分佈式健康檢查？

最後說說Consul是如何經過各個服務機器上部署Agent來實現分佈式健康檢查的。

集中式的心跳機制，好比傳統的Eureka，是讓各個服務都必須每隔必定時間發送心跳到Eureka Server。

若是一段時間沒收到心跳，那麼就認爲這個服務宕機了。

可是這種集中式的心跳機制會對Eureka Server形成較大的心跳請求壓力，實際上平時Eureka Server接收最多的請求之一就是成千上萬服務發送過來的心跳請求。

因此Consul在這塊進行了架構優化，引入了Agent概念。

每一個機器上的Consul Agent會不斷的發送請求檢查服務是否健康，是否宕機。若是服務宕機了，那麼就會通知Consul Server。

怎麼樣？是否是發現各個服務本身不用再發送心跳請求去Server了？減少了Server這部分的壓力吧？

沒錯，這就是Consul基於Agent實現的分佈式健康檢查機制，能夠大幅度的減少Server端的壓力。

這樣一來，哪怕你就部署個三五臺機器，能夠輕鬆支持成千上萬個服務。

我們再來一張圖，一塊兒來看看：

End

（封面圖源網絡，侵權刪除）

掃描下方二維碼，備註：「資料」，獲取更多「祕製」 精品學習資料

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授

推薦閱讀：

一、拜託！面試請不要再問我Spring Cloud底層原理

二、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？

三、【性能優化之道】每秒上萬併發下的Spring Cloud參數優化實戰

四、微服務架構如何保障雙11狂歡下的99.99%高可用

五、兄弟，用大白話告訴你小白都能聽懂的Hadoop架構原理

六、大規模集羣下Hadoop NameNode如何承載每秒上千次的高併發訪問

七、【性能優化的祕密】Hadoop如何將TB級大文件的上傳性能優化上百倍

八、拜託，面試請不要再問我TCC分佈式事務的實現原理！

九、【坑爹呀！】最終一致性分佈式事務如何保障實際生產中99.99%高可用？

十、拜託，面試請不要再問我Redis分佈式鎖的實現原理！

十一、【眼前一亮！】看Hadoop底層算法如何優雅的將大規模集羣性能提高10倍以上？

十二、億級流量系統架構之如何支撐百億級數據的存儲與計算

1三、億級流量系統架構之如何設計高容錯分佈式計算系統

1四、億級流量系統架構之如何設計承載百億流量的高性能架構

1五、億級流量系統架構之如何設計每秒十萬查詢的高併發架構

1六、億級流量系統架構之如何設計全鏈路99.99%高可用架構

1七、七張圖完全講清楚ZooKeeper分佈式鎖的實現原理

1八、大白話聊聊Java併發面試問題之volatile究竟是什麼？

1九、大白話聊聊Java併發面試問題之Java 8如何優化CAS性能？

20、大白話聊聊Java併發面試問題之談談你對AQS的理解？

2一、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？

2二、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化

2三、互聯網公司的面試官是如何360°無死角考察候選人的？（上篇）

2四、互聯網公司面試官是如何360°無死角考察候選人的？（下篇）

2五、Java進階面試系列之一：哥們，大家的系統架構中爲何要引入消息中間件？

2六、【Java進階面試系列之二】：哥們，那你說說系統架構引入消息中間件有什麼缺點？

2七、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷

2八、【Java進階面試系列之三】哥們，消息中間件在大家項目裏是如何落地的？

2九、【Java進階面試系列之四】扎心！線上服務宕機時，如何保證數據100%不丟失？

30、一次JVM FullGC的背後，竟隱藏着驚心動魄的線上生產事故！

3一、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？

3二、【Java進階面試系列之五】消息中間件集羣崩潰，如何保證百萬生產數據不丟失？

3三、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（上）？

3四、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（中）？

3五、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（下）？

3六、億級流量架構第二彈：你的系統真的無懈可擊嗎？

3七、億級流量系統架構之如何保證百億流量下的數據一致性（上）

3八、億級流量系統架構之如何保證百億流量下的數據一致性（中）？

3九、億級流量系統架構之如何保證百億流量下的數據一致性（下）？

40、互聯網面試必殺：如何保證消息中間件全鏈路數據100%不丟失（1）

4一、互聯網面試必殺：如何保證消息中間件全鏈路數據100%不丟失（2）

4二、面試大殺器：消息中間件如何實現消費吞吐量的百倍優化？

4三、高併發場景下，如何保證生產者投遞到消息中間件的消息不丟失？

4四、兄弟，用大白話給你講小白都能看懂的分佈式系統容錯架構

4五、從團隊自研的百萬併發中間件系統的內核設計看Java併發性能優化

4六、【非廣告，純乾貨】英語差的程序員如何才能無障礙閱讀官方文檔？

4七、若是20萬用戶同時訪問一個熱點緩存，如何優化你的緩存架構？

4八、【非廣告，純乾貨】中小公司的Java工程師應該如何逆襲衝進BAT？

4九、拜託，面試請不要再問我分佈式搜索引擎的架構原理！

50、【金三銀四跳槽季】Java工程師如何在1個月內作好面試準備？

5一、【offer收割機必備】我簡歷上的Java項目都好low，怎麼辦？

5二、【offer去哪了】我一連面試了十個Java崗，通通石沉大海！

5三、高階Java開發必備：分佈式系統的惟一id生成算法你瞭解嗎？

5四、支撐日活百萬用戶的高併發系統，應該如何設計其數據庫架構？

5五、尷尬了！Spring Cloud微服務註冊中心Eureka 2.x中止維護了咋辦？

做者：石杉的架構筆記 連接：https://juejin.im/post/5c6a9f25518825787e69e70a 來源：掘金 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。