周一至周五早8點(diǎn)半！精品技術(shù)文章準(zhǔn)時(shí)送上！

先回顧一下什么叫做服務(wù)注冊中心？

顧名思義，假設(shè)你有一個(gè)分布式系統(tǒng)，里面包含了多個(gè)服務(wù)，部署在不同的機(jī)器上，然后這些不同機(jī)器上的服務(wù)之間要互相調(diào)用。

舉個(gè)現(xiàn)實(shí)點(diǎn)的例子吧，比如電商系統(tǒng)里的訂單服務(wù)需要調(diào)用庫存服務(wù)，如下圖所示。

現(xiàn)在的問題在于，訂單服務(wù)在192.168.31.154這臺機(jī)器上，庫存服務(wù)在192.137.1.33這臺機(jī)器上。

現(xiàn)在訂單服務(wù)是想要調(diào)用庫存服務(wù)，但是他并不知道庫存服務(wù)在哪臺機(jī)器上?。‘吘谷思叶际窃诓煌瑱C(jī)器上的。

所以這個(gè)時(shí)候就需要服務(wù)注冊中心出場了，這個(gè)時(shí)候你的系統(tǒng)架構(gòu)中需要引入獨(dú)立部署在一臺機(jī)器上的服務(wù)注冊中心，如下圖所示。

然后訂單服務(wù)、庫存服務(wù)之類的兄弟，都需要配置上服務(wù)注冊中心部署在哪臺機(jī)器上，比如192.168.31.45這臺機(jī)器。

接著訂單服務(wù)、庫存服務(wù)他們自己啟動(dòng)的時(shí)候，就得發(fā)送請求到到服務(wù)注冊中心上去進(jìn)行服務(wù)注冊。

也就是說，得告訴服務(wù)注冊中心，自己是哪個(gè)服務(wù)，然后自己部署在哪臺機(jī)器上。

然后服務(wù)注冊中心會(huì)把大家注冊上來的信息放在注冊表里，如下圖。

接著訂單服務(wù)假如想要調(diào)用庫存服務(wù)，那么就找服務(wù)注冊中心問問：能不能告訴我?guī)齑娣?wù)部署在哪臺機(jī)器上？

服務(wù)注冊中心是知道這個(gè)信息的，所以就會(huì)告訴訂單服務(wù)：庫存服務(wù)部署在192.1371.133這臺機(jī)器上，你就給這臺機(jī)器發(fā)送請求吧。

然后，訂單服務(wù)就可以往庫存服務(wù)的那臺機(jī)器發(fā)送請求了，完成了服務(wù)間的調(diào)用。

整個(gè)過程，如下圖所示：

上述就是服務(wù)注冊中心的作用、地位以及意義，現(xiàn)在大家應(yīng)該知道服務(wù)注冊中心的作用了吧。

好！接著我們就來看看Consul作為服務(wù)注冊中心，他的架構(gòu)設(shè)計(jì)原理是什么？

如果要基于Consul作為服務(wù)注冊中心，那么首先必須在每個(gè)服務(wù)所在的機(jī)器上部署一個(gè)Consul Agent，作為一個(gè)服務(wù)所在機(jī)器的代理。

然后還得在多臺機(jī)器上部署Consul Server，這就是核心的服務(wù)注冊中心。

這個(gè)Consul Agent可以用來收集你的服務(wù)信息然后發(fā)送給Consul Server，還會(huì)對你的服務(wù)不停的發(fā)送請求檢查他是否健康。

然后你要發(fā)現(xiàn)別的服務(wù)的時(shí)候，Consul Agent也會(huì)幫你轉(zhuǎn)發(fā)請求給Consul Server，查詢其他服務(wù)所在機(jī)器。

Consul Server一般要求部署3~5臺機(jī)器，以保證高可用以及數(shù)據(jù)一致性。

他們之間會(huì)自動(dòng)實(shí)現(xiàn)數(shù)據(jù)同步，而且Consul Server集群會(huì)自動(dòng)選舉出一臺機(jī)器作為leader，其他的Consul Server就是follower。

咱們看下面的圖，先感受一下這個(gè)Consul他整體的架構(gòu)。

首先上篇文章：尷尬了！Spring Cloud微服務(wù)注冊中心Eureka 2.x停止維護(hù)了咋辦？已經(jīng)說了，Eureka服務(wù)注冊中心是不保證數(shù)據(jù)一致性的。

這樣的話，很可能你注冊的服務(wù)，其他人是發(fā)現(xiàn)不了的，或者很遲才能發(fā)現(xiàn)。

OK，那么這里就來討論一下Consul是如何實(shí)現(xiàn)數(shù)據(jù)一致性的。

首先，大家知道Consul Server是部署集群的，而且他會(huì)選舉出來一臺Server作為Leader。

接下來各個(gè)服務(wù)發(fā)送的注冊請求都會(huì)落地給Leader，由Leader同步給其他Follower。

所以首先第一點(diǎn)，Leader Server是絕對有最新的服務(wù)注冊信息的，是不是？

比如庫存服務(wù)發(fā)起注冊了，那么Leader Server上一定有庫存服務(wù)的注冊信息。

接著如果比如訂單服務(wù)要發(fā)現(xiàn)庫存服務(wù)的話，這個(gè)查詢請求會(huì)發(fā)送給Leader Server。

這樣服務(wù)注冊和發(fā)現(xiàn)，都是通過一臺Leader Server來進(jìn)行的，就可以保證服務(wù)注冊數(shù)據(jù)的強(qiáng)一致性了，大家看下圖。

接著大家想，假如說庫存服務(wù)在注冊的時(shí)候數(shù)據(jù)剛寫到Leader Server，結(jié)果Leader Server就宕機(jī)了，這時(shí)候怎么辦？

那么此時(shí)這條注冊數(shù)據(jù)就丟失了，訂單服務(wù)就沒法發(fā)現(xiàn)那個(gè)庫存服務(wù)了。沒關(guān)系，這里Consul會(huì)基于Raft協(xié)議來解決這個(gè)問題。

首先，庫存服務(wù)注冊到Leader Server的時(shí)候，會(huì)采取Raft協(xié)議，要求必須讓Leader Server把這條注冊數(shù)據(jù)復(fù)制給大部分的Follower Server才算成功。

這就保證了，如果你認(rèn)為自己注冊成功了，那么必然是多臺Consul Server都有這條注冊數(shù)據(jù)了。

如果你剛發(fā)送給Leader Server他自己就宕機(jī)了，那么這次注冊會(huì)認(rèn)為失敗。

此時(shí)，Consul Server集群會(huì)重新選舉一個(gè)Leader Server出來，你需要再次重新注冊。

這樣就可以保證你注冊成功的數(shù)據(jù)絕對不會(huì)丟，然后別人發(fā)現(xiàn)服務(wù)的時(shí)候一定可以從Leader Server上獲取到最新的強(qiáng)一致的注冊數(shù)據(jù)。

整個(gè)過程，如下圖所示：

上面的圖就可以看到，只要你注冊的時(shí)候基于Raft協(xié)議強(qiáng)制同步到大多數(shù)Server，哪怕是Leader掛了，也會(huì)選舉新的Leader。

這樣就可以讓別人從新的Leader Server來發(fā)現(xiàn)你這個(gè)服務(wù)，所以數(shù)據(jù)是絕對強(qiáng)一致的。

最后說說Consul是如何通過各個(gè)服務(wù)機(jī)器上部署Agent來實(shí)現(xiàn)分布式健康檢查的。

集中式的心跳機(jī)制，比如傳統(tǒng)的Eureka，是讓各個(gè)服務(wù)都必須每隔一定時(shí)間發(fā)送心跳到Eureka Server。

如果一段時(shí)間沒收到心跳，那么就認(rèn)為這個(gè)服務(wù)宕機(jī)了。

但是這種集中式的心跳機(jī)制會(huì)對Eureka Server造成較大的心跳請求壓力，實(shí)際上平時(shí)Eureka Server接收最多的請求之一就是成千上萬服務(wù)發(fā)送過來的心跳請求。

所以Consul在這塊進(jìn)行了架構(gòu)優(yōu)化，引入了Agent概念。

每個(gè)機(jī)器上的Consul Agent會(huì)不斷的發(fā)送請求檢查服務(wù)是否健康，是否宕機(jī)。如果服務(wù)宕機(jī)了，那么就會(huì)通知Consul Server。

怎么樣？是不是發(fā)現(xiàn)各個(gè)服務(wù)自己不用再發(fā)送心跳請求去Server了？減小了Server這部分的壓力吧？

沒錯(cuò)，這就是Consul基于Agent實(shí)現(xiàn)的分布式健康檢查機(jī)制，可以大幅度的減小Server端的壓力。

這樣一來，哪怕你就部署個(gè)三五臺機(jī)器，可以輕松支持成千上萬個(gè)服務(wù)。

咱們再來一張圖，一起來看看：

End