[[349916]]

本文轉(zhuǎn)載自微信公眾號「愛笑的架構(gòu)師」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系愛笑的架構(gòu)師公眾號。

在微服務(wù)架構(gòu)或分布式環(huán)境下，服務(wù)注冊與發(fā)現(xiàn)技術(shù)不可或缺，這也是程序員進(jìn)階之路必須要掌握的核心技術(shù)之一，本文通過圖解的方式帶領(lǐng)大家輕輕松松掌握。

 

引入服務(wù)注冊與發(fā)現(xiàn)組件的原因

先來看一個問題，假如現(xiàn)在我們要做一個商城項(xiàng)目，作為架構(gòu)師的你應(yīng)該怎樣設(shè)計(jì)系統(tǒng)的架構(gòu)?你心里肯定在想：這還不容易直接照搬淘寶的架構(gòu)不就行了。但在現(xiàn)實(shí)的創(chuàng)業(yè)環(huán)境中一個項(xiàng)目可能是九死一生，如果一開始投入巨大的人力和財(cái)力，一旦項(xiàng)目失敗損失就很大。

作為一位有經(jīng)驗(yàn)的架構(gòu)師需要結(jié)合公司財(cái)力、人力投入預(yù)算等現(xiàn)狀選擇最適合眼下的架構(gòu)才是王道。大型網(wǎng)站都是從小型網(wǎng)站發(fā)展而來，架構(gòu)也是一樣。

任何一個大型網(wǎng)站的架構(gòu)都不是從一開始就一層不變的，而是隨著用戶量和數(shù)據(jù)量的不斷增加不斷迭代演進(jìn)的結(jié)果。

在架構(gòu)不斷迭代演進(jìn)的過程中我們會遇到很多問題，技術(shù)發(fā)展的本質(zhì)就是不斷發(fā)現(xiàn)問題再解決問題，解決問題又發(fā)現(xiàn)問題。

單體架構(gòu)

在系統(tǒng)建立之初可能不會有特別多的用戶，將所有的業(yè)務(wù)打成一個應(yīng)用包放在tomcat容器中運(yùn)行，與數(shù)據(jù)庫共用一臺服務(wù)器，這種架構(gòu)一般稱之為單體架構(gòu)。

單體架構(gòu)-應(yīng)用和數(shù)據(jù)庫共同部署

 

在初期這種架構(gòu)的效率非常高，根據(jù)用戶的反饋可以快速迭代上線。但是隨著用戶量增加，一臺服務(wù)的內(nèi)存和CPU吃緊，很容易造成瓶頸，新的問題來了怎么解決呢?

應(yīng)用與數(shù)據(jù)分離

隨著用戶請求量增加，一臺服務(wù)器的內(nèi)存和CPU持續(xù)飆升，用戶請求響應(yīng)時間變慢。這時候可以考慮將應(yīng)用與數(shù)據(jù)庫拆開，各自使用一臺服務(wù)器，你看問題又解決了吧。

單體架構(gòu)-應(yīng)用和數(shù)據(jù)庫分離

 

突然有一天掃地阿姨不小心碰了電線，其中一臺服務(wù)器掉電了，用戶所有的請求都報錯，隨之而來的是一系列投訴電話。

集群部署

單實(shí)例很容易造成單點(diǎn)問題，比如遇到服務(wù)器故障或者服務(wù)能力瓶頸，那怎么辦?聰明的你肯定想到了，用集群呀。

應(yīng)用集群部署

 

集群部署是指將應(yīng)用部署在多個服務(wù)器或者虛機(jī)上，用戶通過服務(wù)均衡隨機(jī)訪問其中的一個實(shí)例，從而使多個實(shí)例的流量均衡，如果一個實(shí)例出現(xiàn)故障可以將其下線，其他實(shí)例不受影響仍然可以對外提供服務(wù)。

隨著用戶數(shù)量快速增加，老板決定增加投入擴(kuò)大團(tuán)隊(duì)規(guī)模。開發(fā)團(tuán)隊(duì)壯大后效率并沒有得到顯著的提高，以前小團(tuán)隊(duì)可以一周迭代上線一次，現(xiàn)在至少需要兩到三周時間。

業(yè)務(wù)邏輯越來越復(fù)雜，代碼間耦合很嚴(yán)重，修改一行代碼可能引入幾個線上問題。架構(gòu)師意識到需要進(jìn)行架構(gòu)重構(gòu)。

微服務(wù)架構(gòu)

當(dāng)單體架構(gòu)演進(jìn)到一定階段后開發(fā)測試的復(fù)雜性都會成本增加，團(tuán)隊(duì)規(guī)模的擴(kuò)大也會使得各自工作耦合性更嚴(yán)重，牽一發(fā)而動全身就是這種場景。

單體架構(gòu)遇到瓶頸了，微服務(wù)架構(gòu)就橫空出世了。微服務(wù)就是將之前的單體服務(wù)按照業(yè)務(wù)維度進(jìn)行拆分，拆分粒度可大可小，拆分時機(jī)可以分節(jié)奏進(jìn)行。最佳實(shí)踐是先將一些獨(dú)立的功能從單體中剝離出來抽成一個或多個微服務(wù)，這樣可以保障業(yè)務(wù)的連續(xù)性和穩(wěn)定性。

微服務(wù)架構(gòu)

 

如上圖將一個商用應(yīng)用拆分為六個獨(dú)立微服務(wù)。六個微服務(wù)可以使用Docker容器化進(jìn)行多實(shí)例部署。

架構(gòu)演化到這里遇到了一個難題，如果要查詢用戶所有的訂單，用戶服務(wù)可能會依賴訂單服務(wù)，用戶服務(wù)如何與訂單服務(wù)交互呢?訂單服務(wù)有多個實(shí)例該訪問哪一個?

通常有幾種解決辦法：

(1)服務(wù)地址硬編碼

服務(wù)的地址寫死在數(shù)據(jù)庫或者配置文件，通過訪問DNS域名進(jìn)行尋址路由。

服務(wù)元數(shù)據(jù)硬編碼

 

服務(wù)B的地址硬編碼在數(shù)據(jù)庫或者配置文件中，服務(wù)A首先需要拿到服務(wù)B的地址，然后通過DNS服務(wù)器解析獲取其中一實(shí)例的真實(shí)地址，最后可以向服務(wù)B發(fā)起請求。

如果遇到大促活動需要對服務(wù)實(shí)例擴(kuò)容，大促完需要對服務(wù)實(shí)例進(jìn)行下線，運(yùn)維人員要做大量的手工操作，非常容易誤操作。

(2)服務(wù)動態(tài)注冊與發(fā)現(xiàn)

服務(wù)地址硬編碼還有一個非常致命的問題，如果一臺實(shí)例掛了，運(yùn)維人員可能不能及時感知到，導(dǎo)致一部分用戶的請求會異常。

引入服務(wù)注冊與發(fā)現(xiàn)組件可以很好解決上面遇到的問題，避免過多的人工操作。

架構(gòu)演進(jìn)總結(jié)

在單體架構(gòu)中一個應(yīng)用程序就是一個服務(wù)包，包內(nèi)的模塊通過函數(shù)方法相互調(diào)用，模型足夠簡單，根本沒有服務(wù)注冊和發(fā)現(xiàn)一說。

在微服務(wù)架構(gòu)中會將一個應(yīng)用程序拆分為多個微服務(wù)，微服務(wù)會部署在不同的服務(wù)器、不同的容器、甚至多數(shù)據(jù)中心，微服務(wù)間要相互調(diào)用，服務(wù)注冊和發(fā)現(xiàn)成為了一個不可或缺的組件。

服務(wù)注冊與發(fā)現(xiàn)基本原理

服務(wù)注冊與發(fā)現(xiàn)是分為注冊和發(fā)現(xiàn)兩個關(guān)鍵的步驟。

服務(wù)注冊：服務(wù)進(jìn)程在注冊中心注冊自己的元數(shù)據(jù)信息。通常包括主機(jī)和端口號，有時還有身份驗(yàn)證信息，協(xié)議，版本號，以及運(yùn)行環(huán)境的信息。

服務(wù)發(fā)現(xiàn)：客戶端服務(wù)進(jìn)程向注冊中心發(fā)起查詢，來獲取服務(wù)的信息。服務(wù)發(fā)現(xiàn)的一個重要作用就是提供給客戶端一個可用的服務(wù)列表。

服務(wù)注冊

服務(wù)注冊有兩種形式：客戶端注冊和代理注冊。

客戶端注冊

客戶端注冊是服務(wù)自己要負(fù)責(zé)注冊與注銷的工作。當(dāng)服務(wù)啟動后注冊線程向注冊中心注冊，當(dāng)服務(wù)下線時注銷自己。

客戶端注冊

 

這種方式的缺點(diǎn)是注冊注銷邏輯與服務(wù)的業(yè)務(wù)邏輯耦合在一起，如果服務(wù)使用不同語言開發(fā)，那需要適配多套服務(wù)注冊邏輯。

代理注冊

代理注冊由一個單獨(dú)的代理服務(wù)負(fù)責(zé)注冊與注銷。當(dāng)服務(wù)提供者啟動后以某種方式通知代理服務(wù)，然后代理服務(wù)負(fù)責(zé)向注冊中心發(fā)起注冊工作。

 

代理注冊

 

這種方式的缺點(diǎn)是多引用了一個代理服務(wù)，并且代理服務(wù)要保持高可用狀態(tài)。

服務(wù)發(fā)現(xiàn)

服務(wù)發(fā)現(xiàn)也分為客戶端發(fā)現(xiàn)和代理發(fā)現(xiàn)。

客戶端發(fā)現(xiàn)

客戶端發(fā)現(xiàn)是指客戶端負(fù)責(zé)向注冊中心查詢可用服務(wù)地址，獲取到所有的可用實(shí)例地址列表后客戶端根據(jù)負(fù)載均衡算法選擇一個實(shí)例發(fā)起請求調(diào)用。

客戶端發(fā)現(xiàn)

 

這種方式非常直接，客戶端可以控制負(fù)載均衡算法。但是缺點(diǎn)也很明顯，獲取實(shí)例地址、負(fù)載均衡等邏輯與服務(wù)的業(yè)務(wù)邏輯耦合在一起，如果服務(wù)發(fā)現(xiàn)或者負(fù)載平衡有變化，那么所有的服務(wù)都要修改重新上線。

代理發(fā)現(xiàn)

代理發(fā)現(xiàn)是指新增一個路由服務(wù)負(fù)責(zé)服務(wù)發(fā)現(xiàn)獲取可用的實(shí)例列表，服務(wù)消費(fèi)者如果需要調(diào)用服務(wù)A的一個實(shí)例可以直接將請求發(fā)往路由服務(wù)，路由服務(wù)根據(jù)配置好的負(fù)載均衡算法從可用的實(shí)例列表中選擇一個實(shí)例將請求轉(zhuǎn)發(fā)過去即可，如果發(fā)現(xiàn)實(shí)例不可用，路由服務(wù)還可以自行重試，服務(wù)消費(fèi)者完全不用感知。

代理路由服務(wù)注冊

 

心跳機(jī)制

如果服務(wù)有多個實(shí)例，其中一個實(shí)例出現(xiàn)宕機(jī)，注冊中心是可以實(shí)時感知到，并且將該實(shí)例信息從列表中移出，也稱為摘機(jī)。

如何實(shí)現(xiàn)摘機(jī)?業(yè)界比較常用的方式是通過心跳檢測的方式實(shí)現(xiàn)，心跳檢測有主動和被動兩種方式。

被動檢測是指服務(wù)主動向注冊中心發(fā)送心跳消息，時間間隔可自定義，比如配置5秒發(fā)送一次，注冊中心如果在三個周期內(nèi)比如說15秒內(nèi)沒有收到實(shí)例的心跳消息，就會將該實(shí)例從列表中移除。

心跳機(jī)制-被動檢測

 

上圖中服務(wù)A的實(shí)例2已經(jīng)宕機(jī)不能主動給注冊中心發(fā)送心跳消息，15秒之后注冊就會將實(shí)例2移除掉。

主動檢測是注冊中心主動發(fā)起，每隔幾秒中會給所有列表中的服務(wù)實(shí)例發(fā)送心跳檢測消息，如果多個周期內(nèi)未發(fā)送成功或未收到回復(fù)就會主動移除該實(shí)例。

心跳機(jī)制-主動檢測

 

業(yè)界常用的服務(wù)注冊與發(fā)現(xiàn)組件對比

了解服務(wù)注冊與發(fā)現(xiàn)的基本原理后，如果你要在項(xiàng)目中使用服務(wù)注冊與發(fā)現(xiàn)組件，當(dāng)面對眾多的開源組件該如何進(jìn)行技術(shù)選型?

在互聯(lián)網(wǎng)公司里，有研發(fā)實(shí)力的大公司一般會選擇自研或者基于開源組件進(jìn)行二次開發(fā)，但是對于中小型公司來說直接選用一款開源軟件會是一個不錯的選擇。

常用的注冊與發(fā)現(xiàn)組件有eureka，zookeeper，consul，etcd等，由于eureka在2018年已經(jīng)宣布放棄維護(hù)，這里就不再推薦使用了。

業(yè)界開源組件

 

下面結(jié)合各個維度對比一下各組件。

組件	優(yōu)點(diǎn)	缺點(diǎn)	接口類型	一致性算法
zookeeper	1.功能強(qiáng)大，不僅僅只是服務(wù)發(fā)現(xiàn)； 2.提供watcher機(jī)制可以實(shí)時獲取服務(wù)提供者的狀態(tài)； 3.廣泛使用，dubbo等微服務(wù)框架已支持；	1.沒有健康檢查； 2.需要在服務(wù)中引入sdk，集成復(fù)雜度高； 3.不支持多數(shù)據(jù)中心；	sdk	Paxos
consul	1.開箱即用，方便集成； 2.帶健康檢查； 3.支持多數(shù)據(jù)中心； 4.提供web管理界面；	不能實(shí)時獲取服務(wù)變換通知	restful/dns	Raft
etcd	1.開箱即用，方便集成； 2.可配置性強(qiáng)	1.沒有健康檢查； 2.需配合三方工具完成服務(wù)發(fā)現(xiàn)功能； 3.不支持多數(shù)據(jù)中心；	restful	Raft

從整體上看consul的功能更加完備和均衡。接下來以consul為例詳細(xì)介紹一下。

Consul——值得推薦的服務(wù)注冊與發(fā)現(xiàn)開源組件

簡單認(rèn)識一下Consul

Consul是HashiCorp公司推出的開源工，使用Go語言開發(fā)，具有開箱即可部署方便的特點(diǎn)。Consul是分布式的、高可用的、 可橫向擴(kuò)展的用于實(shí)現(xiàn)分布式系統(tǒng)的服務(wù)發(fā)現(xiàn)與配置。

Consul有哪些優(yōu)勢?

• 服務(wù)注冊發(fā)現(xiàn)：Consul提供了通過DNS或者restful接口的方式來注冊服務(wù)和發(fā)現(xiàn)服務(wù)。服務(wù)可根據(jù)實(shí)際情況自行選擇。
• 健康檢查：Consul的Client可以提供任意數(shù)量的健康檢查，既可以與給定的服務(wù)相關(guān)聯(lián)，也可以與本地節(jié)點(diǎn)相關(guān)聯(lián)。
• 多數(shù)據(jù)中心：Consul支持多數(shù)據(jù)中心，這意味著用戶不需要擔(dān)心Consul自身的高可用性問題以及多數(shù)據(jù)中心帶來的擴(kuò)展接入等問題。

Consul的架構(gòu)圖

Consul架構(gòu)

 

• Consul 實(shí)現(xiàn)多數(shù)據(jù)中心依賴于gossip protocol協(xié)議。這樣做的目的：
• 不需要使用服務(wù)器的地址來配置客戶端;服務(wù)發(fā)現(xiàn)是自動完成的。

健康檢查故障的工作不是放在服務(wù)器上，而是分布式的。

Consul的使用場景

Consul的應(yīng)用場景包括服務(wù)注冊發(fā)現(xiàn)、服務(wù)隔離、服務(wù)配置等。

服務(wù)注冊發(fā)現(xiàn)場景中consul作為注冊中心，服務(wù)地址被注冊到consul中以后，可以使用consul提供的dns、http接口查詢，consul支持health check。

服務(wù)隔離場景中consul支持以服務(wù)為單位設(shè)置訪問策略，能同時支持經(jīng)典的平臺和新興的平臺，支持tls證書分發(fā)，service-to-service加密。

 

服務(wù)配置場景中consul提供key-value數(shù)據(jù)存儲功能，并且能將變動迅速地通知出去，借助Consul可以實(shí)現(xiàn)配置共享，需要讀取配置的服務(wù)可以從Consul中讀取到準(zhǔn)確的配置信息。