歡迎關注個人公眾號：石杉的架構筆記（ID:shishan100）
週一至週五早8點半！精品技術文章準時送上！
精品學習資料獲取通道，參見文末
目錄
1、再回顧：什麼是服務註冊中心？
2、Consul服務註冊中心的整體架構
3、Consul如何通過Raft協議實現強一致性？
4、Consul如何通過Agent實現分散式健康檢查？
“ 上一篇文章：尷尬了！Spring Cloud微服務註冊中心Eureka 2.x停止維護了咋辦？，我們給大家說了一下Spring Cloud服務註冊中心的一些問題。
如果用Eureka作為其註冊中心的話，很多同學都覺得心裡沒底，所以現在很多公司都開始使用Consul作為其註冊中心。
那麼這篇文章我們就來給大家說說：Consul這種服務註冊中心的架構是如何設計的？
1、再回顧：什麼是服務註冊中心？
先回顧一下什麼叫做服務註冊中心？
顧名思義，假設你有一個分散式系統，裡面包含了多個服務，部署在不同的機器上，然後這些不同機器上的服務之間要互相呼叫。
舉個現實點的例子吧，比如電商系統裡的訂單服務需要呼叫庫存服務，如下圖所示。
現在的問題在於，訂單服務在192.168.31.154這臺機器上，庫存服務在192.137.1.33這臺機器上。
現在訂單服務是想要呼叫庫存服務，但是他並不知道庫存服務在哪臺機器上啊！畢竟人家都是在不同機器上的。
所以這個時候就需要服務註冊中心出場了，這個時候你的系統架構中需要引入獨立部署在一臺機器上的服務註冊中心，如下圖所示。
然後訂單服務、庫存服務之類的兄弟，都需要配置上服務註冊中心部署在哪臺機器上，比如192.168.31.45這臺機器。
接著訂單服務、庫存服務他們自己啟動的時候，就得傳送請求到到服務註冊中心上去進行服務註冊。
也就是說，得告訴服務註冊中心，自己是哪個服務，然後自己部署在哪臺機器上。
然後服務註冊中心會把大家註冊上來的資訊放在登錄檔裡，如下圖。
接著訂單服務假如想要呼叫庫存服務，那麼就找服務註冊中心問問：能不能告訴我庫存服務部署在哪臺機器上？
服務註冊中心是知道這個資訊的，所以就會告訴訂單服務：庫存服務部署在192.1371.133這臺機器上，你就給這臺機器傳送請求吧。
然後，訂單服務就可以往庫存服務的那臺機器傳送請求了，完成了服務間的呼叫。
整個過程，如下圖所示：
上述就是服務註冊中心的作用、地位以及意義，現在大家應該知道服務註冊中心的作用了吧。
好！接著我們就來看看Consul作為服務註冊中心，他的架構設計原理是什麼？
2、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他整體的架構。
3、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來發現你這個服務，所以資料是絕對強一致的。
4、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架構經驗傾囊相授
推薦閱讀：
2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？
3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰
6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問
7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍
9、【坑爹呀！】最終一致性分散式事務如何保障實際生產中99.99%高可用？
11、【眼前一亮！】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上？
16、億級流量系統架構之如何設計全鏈路99.99%高可用架構
18、大白話聊聊Java併發面試問題之volatile到底是什麼？
19、大白話聊聊Java併發面試問題之Java 8如何優化CAS效能？
20、大白話聊聊Java併發面試問題之談談你對AQS的理解？
21、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？
22、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化
23、網際網路公司的面試官是如何360°無死角考察候選人的？（上篇）
24、網際網路公司面試官是如何360°無死角考察候選人的？（下篇）
25、Java進階面試系列之一：哥們，你們的系統架構中為什麼要引入訊息中介軟體？
26、【Java進階面試系列之二】：哥們，那你說說系統架構引入訊息中介軟體有什麼缺點？
27、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷
28、【Java進階面試系列之三】哥們，訊息中介軟體在你們專案裡是如何落地的？
29、【Java進階面試系列之四】扎心！線上服務當機時，如何保證資料100%不丟失？
30、一次JVM FullGC的背後，竟隱藏著驚心動魄的線上生產事故！
31、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？
32、【Java進階面試系列之五】訊息中介軟體叢集崩潰，如何保證百萬生產資料不丟失？
33、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（上）？
34、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（中）？
35、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（下）？
37、億級流量系統架構之如何保證百億流量下的資料一致性（上）
38、億級流量系統架構之如何保證百億流量下的資料一致性（中）？
39、億級流量系統架構之如何保證百億流量下的資料一致性（下）？
40、網際網路面試必殺：如何保證訊息中介軟體全鏈路資料100%不丟失（1）
41、網際網路面試必殺：如何保證訊息中介軟體全鏈路資料100%不丟失（2）
42、面試大殺器：訊息中介軟體如何實現消費吞吐量的百倍優化？
43、高併發場景下，如何保證生產者投遞到訊息中介軟體的訊息不丟失？
45、從團隊自研的百萬併發中介軟體系統的核心設計看Java併發效能優化
46、【非廣告，純乾貨】英語差的程式設計師如何才能無障礙閱讀官方文件？
47、如果20萬使用者同時訪問一個熱點快取，如何優化你的快取架構？
48、【非廣告，純乾貨】中小公司的Java工程師應該如何逆襲衝進BAT？
50、【金三銀四跳槽季】Java工程師如何在1個月內做好面試準備？
51、【offer收割機必備】我簡歷上的Java專案都好low，怎麼辦？
52、【offer去哪了】我一連面試了十個Java崗，統統石沉大海！
53、高階Java開發必備：分散式系統的唯一id生成演算法你瞭解嗎？
作者：石杉的架構筆記
連結：https://juejin.im/post/5c6a9f25518825787e69e70a
來源：掘金
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。