為什么要使用服務(wù)發(fā)現(xiàn)功能？

當(dāng)調(diào)用REST API 或Thrift API的服務(wù)時(shí)，我們在構(gòu)建請求時(shí)通常需要知道服務(wù)實(shí)例的IP和端口。在傳統(tǒng)應(yīng)用中，服務(wù)實(shí)例的地址信息相對固定，可以從配置文件中讀取。而這些地址也只是只會(huì)偶爾更新。

但在現(xiàn)代應(yīng)用程序中，往往是基于云的微服務(wù)架構(gòu)，此時(shí)獲取服務(wù)實(shí)例的IP和端口便是一個(gè)需要解決的難題。如下圖所示：上圖中，服務(wù)實(shí)例實(shí)例的IP是動(dòng)態(tài)分配。同時(shí)，還面臨著服務(wù)的增減、故障以及升級等變化。這對于客戶端程序來說，就需要使用更精確的服務(wù)發(fā)現(xiàn)機(jī)制。

目前，服務(wù)發(fā)現(xiàn)模式主要有兩種：客戶端發(fā)現(xiàn)模式和服務(wù)端發(fā)現(xiàn)模式。先來看一下客戶端發(fā)現(xiàn)模式。

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

使用客戶端發(fā)現(xiàn)模式時(shí)，客戶端負(fù)責(zé)判斷服務(wù)實(shí)例的可用性和請求的負(fù)載均衡。服務(wù)實(shí)例存儲(chǔ)在注冊表中，也就是說注冊表是服務(wù)實(shí)例的數(shù)據(jù)庫。客戶端通過查詢服務(wù)注冊表，獲得服務(wù)實(shí)例列表，然后使用負(fù)載均衡算法從中選擇一個(gè)，然后發(fā)起請求。

下圖為這種模式的架構(gòu)圖：

此種模式下，當(dāng)服務(wù)實(shí)例啟動(dòng)時(shí)，會(huì)將自己的地址信息注冊到服務(wù)注冊表，當(dāng)服務(wù)停止時(shí)從服務(wù)注冊表中移除。這期間，通常使用心跳機(jī)制來定刷新服務(wù)實(shí)例的注冊。

Netflix Eureka就是一個(gè)服務(wù)注冊表組件，它提供了基于REST API的服務(wù)實(shí)例注冊和查詢功能。Netflix Ribbon是一個(gè)IPC客戶端，可配合Eureka實(shí)現(xiàn)對服務(wù)實(shí)例請求的負(fù)載均衡。

客戶端發(fā)現(xiàn)模式的優(yōu)點(diǎn)是相對簡單，除服務(wù)注冊表外，不需要其他部分做改動(dòng)。同時(shí)，由于客戶端知道所有的可用實(shí)例，可以做出更明智的、基于特定應(yīng)用場景的負(fù)載均衡決策，比如使用一致性哈希算法。這種模式的缺點(diǎn)是將客戶端和服務(wù)注冊表功能耦合在了一起，必須為每種編程語言和框架的客戶端實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)邏輯。

服務(wù)器端發(fā)現(xiàn)模式

另外一種服務(wù)發(fā)現(xiàn)模式就是服務(wù)器發(fā)現(xiàn)模式。下圖中展示了該模式的結(jié)構(gòu)：客戶端通過負(fù)載均衡器向服務(wù)發(fā)起請求，負(fù)載均衡器查詢服務(wù)注冊表，并將請求路由到可用的服務(wù)實(shí)例。與客戶端發(fā)現(xiàn)相比，服務(wù)實(shí)例是通過服務(wù)注冊表進(jìn)行注冊和注銷的。

AWS的ELB（Elastic Load Balancer）就是服務(wù)器端發(fā)現(xiàn)路由器的示例。ELB通常用于負(fù)載均衡來自外網(wǎng)的流量，但你也可以使用ELB來負(fù)載均衡私有云（VPV）內(nèi)部的流量?？蛻舳耸褂肈NS名稱，通過ELB發(fā)送請求（Http或TCP），ELB在已注冊的彈性計(jì)算云（EC2）實(shí)例或EC2容器服務(wù)（ECS）的容器之間進(jìn)行負(fù)載均衡。這種實(shí)現(xiàn)并沒有單獨(dú)的服務(wù)注冊表，而是將EC2實(shí)例和ECS容器注冊到ELB自身上。

Http服務(wù)器和負(fù)載均衡器（比如，Nginx plus和Nginx）也可以用作服務(wù)器端發(fā)現(xiàn)的負(fù)載均衡器。比如，使用Consul模板動(dòng)態(tài)配置Nginx反向代理。Consul可以從存儲(chǔ)在Consul服務(wù)注冊表中的配置數(shù)據(jù)中定時(shí)重新生成任意配置文件。每當(dāng)文件改變時(shí)，可以運(yùn)行一個(gè)任意shell命令。比如，Consul模板生成一個(gè)nginx.conf文件，用于配置反向代理，然后執(zhí)行命令告訴Nginx去重新加載配置。

某些部署環(huán)境（例如Kubernetes和Marathon）會(huì)在集群中的每個(gè)主機(jī)上運(yùn)行一個(gè)代理。這個(gè)代理扮演服務(wù)器端發(fā)現(xiàn)負(fù)載平衡器的角色。客戶端向服務(wù)發(fā)出請求時(shí)，會(huì)通過代理進(jìn)行路由，透明地將請求轉(zhuǎn)發(fā)到集群中某個(gè)服務(wù)實(shí)例。

服務(wù)器端發(fā)現(xiàn)模式最大的優(yōu)點(diǎn)是，服務(wù)發(fā)現(xiàn)的實(shí)現(xiàn)細(xì)節(jié)從客戶端抽離出來了，客戶端只用發(fā)送請求到負(fù)載均衡器即可。這樣就無需為每種編程語言和框架的客戶端實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)邏輯。而且，某些部署環(huán)境已經(jīng)免費(fèi)提供了該功能。當(dāng)然，這種模式也有一些缺點(diǎn)，如果部署環(huán)境未提供負(fù)載均衡器，你還需要搭建和管理一個(gè)額外的高可用系統(tǒng)組件。

服務(wù)注冊表

服務(wù)注冊表是服務(wù)發(fā)現(xiàn)的關(guān)鍵，它是一個(gè)包含服務(wù)實(shí)例地址信息的數(shù)據(jù)庫。服務(wù)注冊表需要具有高可用性和實(shí)時(shí)更新性。客戶端可以緩存從注冊表獲得的服務(wù)實(shí)例地址信息。但這些信息會(huì)過時(shí)，因此，服務(wù)注冊表也需要是集群模式，且集群之間還需要通過協(xié)議維持一致性。

Netflix Eureka是一個(gè)服務(wù)注冊表組件，它提供了基于REST API形式的服務(wù)實(shí)例注冊和查詢功能。一個(gè)服務(wù)實(shí)例可以通過POST請求將自己注冊到注冊表中；可以通過PUT請求，每隔30秒刷新它的注冊信息；可以通過Http的DELETE請求或超時(shí)機(jī)制來刪除實(shí)例的注冊信息；可以使用Http的GET請求來檢索注冊的服務(wù)實(shí)例。

常見的服務(wù)注冊表組件有：etcd、Consul、Apache Zookeeper、Nacos等。

服務(wù)注冊的選項(xiàng)

服務(wù)實(shí)例必須通過注冊表進(jìn)行注冊或注銷，通常有幾種不同方式來處理注冊和注銷。一種是服務(wù)實(shí)例自己注冊，即自我注冊模式；另一種是基于其他系統(tǒng)組件來管理服務(wù)實(shí)例的注冊，即第三方注冊模式。先來看一下自我注冊模式。

自我注冊模式

當(dāng)使用自我注冊模式時(shí)，服務(wù)實(shí)例負(fù)責(zé)在服務(wù)注冊表中進(jìn)行自身的注冊和注銷。如果需要，服務(wù)實(shí)例還需要發(fā)送心跳請求以避免因超時(shí)而被注銷。下圖展示了這種模式的結(jié)構(gòu)圖：Netflix OSS Eureka客戶端就是這種模式的示例，Eureka客戶端負(fù)責(zé)處理服務(wù)實(shí)例所有的注冊和注銷事項(xiàng)。在Spring Cloud項(xiàng)目中，實(shí)現(xiàn)了包括服務(wù)發(fā)現(xiàn)的各種模式，基于此可以很輕松的實(shí)現(xiàn)自動(dòng)注冊服務(wù)實(shí)例到Eureka。你只需在Java配置類上使用@EnableEurekaClient注解即可。

自我注冊模式的優(yōu)點(diǎn)是使用起來非常簡單，不需要任何其他系統(tǒng)組件。缺點(diǎn)是服務(wù)實(shí)例與服務(wù)注冊表緊密耦合，需要在每種編程語言和框架中實(shí)現(xiàn)注冊功能。

另外一種方式可以讓服務(wù)和注冊表解耦的方式就是第三方注冊模式。

第三方注冊模式

當(dāng)使用第三方注冊模式時(shí)，服務(wù)實(shí)例不再負(fù)責(zé)將自己注冊到服務(wù)注冊表。這一功能由第三方組件作為服務(wù)注冊商來處理。服務(wù)注冊商通過輪詢或訂閱事件來跟蹤實(shí)例的變化。當(dāng)發(fā)現(xiàn)新的可用服務(wù)實(shí)例時(shí)，會(huì)將服務(wù)實(shí)例注冊到服務(wù)注冊表中。同時(shí)，也會(huì)注銷已經(jīng)停止的服務(wù)實(shí)例。

下圖展示了這種模式的結(jié)構(gòu)：

開源項(xiàng)目Registrator便是一個(gè)示例，它可以基于Docker容器自動(dòng)注冊和注銷服務(wù)實(shí)例。Registrator支持多種注冊表，包括etcd和Consul。

NetflixOSS Prana項(xiàng)目是另外一個(gè)示例，它主要用于非JVM語言編寫的服務(wù)，是與服務(wù)實(shí)例并行的Sidecar應(yīng)用程序。Prana基于Netflix Eureka注冊和注銷服務(wù)實(shí)例。

第三方注冊模式的優(yōu)點(diǎn)是服務(wù)與服務(wù)注冊表分離，無需每種編程語言和框架的客戶端實(shí)現(xiàn)服務(wù)注冊邏輯，而是在專用服務(wù)內(nèi)以集中方式處理服務(wù)實(shí)例注冊。這種模式缺點(diǎn)是，除非部署環(huán)境提供內(nèi)置服務(wù)，否則還需要額外搭建和管理一個(gè)高度可用的系統(tǒng)組件。

總結(jié)

在微服務(wù)應(yīng)用程序中，服務(wù)實(shí)例運(yùn)行狀態(tài)會(huì)動(dòng)態(tài)更改，實(shí)例會(huì)動(dòng)態(tài)分配地址。因此，為了使客戶端可以正常請求服務(wù)，必須使用服務(wù)發(fā)現(xiàn)機(jī)制。而本文正是圍繞服務(wù)發(fā)現(xiàn)中的兩種模式（客戶端發(fā)現(xiàn)和服務(wù)器端發(fā)現(xiàn)）、服務(wù)注冊表及其兩種途徑（自我注冊模式和第三方注冊模式）、反向代理服務(wù)器等知識(shí)點(diǎn)進(jìn)行講解。只有科普了以上基礎(chǔ)知識(shí)，我們才能更好的學(xué)習(xí)和認(rèn)識(shí)微服務(wù)中的服務(wù)發(fā)現(xiàn)功能。