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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

服務(wù)注冊表

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

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

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

服務(wù)注冊的選項

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

自我注冊模式

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

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

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

第三方注冊模式

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

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

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

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

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

總結(jié)

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