服務(wù)注冊與發(fā)現(xiàn)的來源

首先，服務(wù)注冊與發(fā)現(xiàn)是來自于微服務(wù)架構(gòu)的產(chǎn)物。

在傳統(tǒng)的服務(wù)架構(gòu)中，服務(wù)的規(guī)模處于運維人員的可控范圍內(nèi)。當(dāng)部署服務(wù)的多個節(jié)點時，一般使用靜態(tài)配置的方式實現(xiàn)服務(wù)信息的設(shè)定。而在微服務(wù)應(yīng)用中，服務(wù)實例的數(shù)量和網(wǎng)絡(luò)地址都是動態(tài)變化的，這對系統(tǒng)運維提出了巨大的挑戰(zhàn)。

而且服務(wù)集群的跨度很大、數(shù)量很多（數(shù)以百計甚至更多），為保障系統(tǒng)的正常運行，必然需要有一個中心化的組件完成對各個服務(wù)的整合，即將分散于各處的服務(wù)進行匯總，匯總的信息可以是服務(wù)器的名稱、地址、數(shù)量等，并且這些服務(wù)器組件還擁有被監(jiān)聽功能等（服務(wù)發(fā)現(xiàn)）。

這就是服務(wù)注冊與發(fā)現(xiàn)的來源，在微服務(wù)架構(gòu)中，服務(wù)注冊與發(fā)現(xiàn)組件是必不可少的，常用的服務(wù)協(xié)調(diào)器有：Eureka、Zookeeper，ANS、Dubbo、Etcd等。

下面我分別從：服務(wù)注冊發(fā)現(xiàn)主要解決的問題、特點、原理和Zookeeper的實現(xiàn)方式四個維度詳細介紹。

服務(wù)注冊與發(fā)現(xiàn)主要解決的問題

在一個分布式系統(tǒng)中，服務(wù)注冊與發(fā)現(xiàn)組件主要解決兩個問題：服務(wù)注冊和服務(wù)發(fā)現(xiàn)。

1.服務(wù)注冊

服務(wù)實例將自身服務(wù)信息注冊到注冊中心。這部分服務(wù)信息包括服務(wù)所在主機IP和提供服務(wù)的Port，以及暴露服務(wù)自身狀態(tài)以及訪問協(xié)議等信息。

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

服務(wù)實例請求注冊中心獲取所依賴服務(wù)信息。服務(wù)實例通過注冊中心，獲取到注冊到其中的服務(wù)實例的信息，通過這些信息去請求它們提供的服務(wù)。

除此之外，服務(wù)注冊與發(fā)現(xiàn)需要關(guān)注監(jiān)控服務(wù)實例運行狀態(tài)等問題。

3.監(jiān)控

微服務(wù)應(yīng)用中，服務(wù)處于動態(tài)變化的情況，需要一定機制處理無效的服務(wù)實例。一般來講，服務(wù)實例與注冊中心在注冊后通過心跳的方式維系聯(lián)系，一旦心跳缺少，對應(yīng)的服務(wù)實例會被注冊中心剔除。

關(guān)系調(diào)用說明：

• 服務(wù)生產(chǎn)者啟動時，向服務(wù)注冊中心注冊自己提供的服務(wù)
• 服務(wù)消費者啟動時，在服務(wù)注冊中心訂閱自己所需要的服務(wù)
• 注冊中心返回服務(wù)提供者的地址信息個消費者
• 消費者從提供者中調(diào)用服務(wù)

服務(wù)注冊與發(fā)現(xiàn)的特點

1.高可用

由多個服務(wù)節(jié)點構(gòu)成，就算有些節(jié)點掛掉也不影響正常運行，避免了單點故障。

2.方便配置

本身是一個分布式，一致性的 k-v 存儲系統(tǒng)。提供方啟動的時候?qū)⒆陨砼渲眯畔⑾騾f(xié)調(diào)器中進行注冊，提供方下線的時候向協(xié)調(diào)器進行反注冊。

3.可監(jiān)控

提供心跳機制，如果對方程序意外掛掉，沒有進行反注冊，協(xié)調(diào)器也會超時剔除不可用的提供方。

服務(wù)注冊發(fā)現(xiàn)的實現(xiàn)方式

我從服務(wù)注冊發(fā)現(xiàn)實現(xiàn)的早期到現(xiàn)在主流的Zookpeer介紹，這樣可以更加直觀的了解到對應(yīng)的優(yōu)劣勢，更有利于今后的選型升級。

1. DNS（早期）

DNS作為服務(wù)注冊發(fā)現(xiàn)的一種方案，它比較簡單。只要在DNS服務(wù)上，配置一個DNS名稱與IP對應(yīng)關(guān)系即可。定位一個服務(wù)只需要連接到DNS服務(wù)器上，隨機返回一個IP地址即可。由于存在DNS緩存，所以DNS服務(wù)器本身不會成為一個瓶頸。

這種基于Pull的方式不能及時獲取服務(wù)的狀態(tài)的更新（例如：服務(wù)的IP更新等）。

如果服務(wù)的提供者出現(xiàn)故障，由于DNS緩存的存在，服務(wù)的調(diào)用方會仍然將請求轉(zhuǎn)發(fā)給出現(xiàn)故障的服務(wù)提供方。

2.Zookeeper

Zookeeper是google開源的在Java語言上實現(xiàn)的分布式協(xié)調(diào)服務(wù)，是Hadoop和Hbase的重要組件，提供了數(shù)據(jù)/發(fā)布訂閱、負載均衡、分布式同步等功能。

Zookeeper也是基于主從架構(gòu)，搭建了一個可高擴展的服務(wù)集群，其服務(wù)架構(gòu)如下：

• Leader-Server：Leader負責(zé)進行投票的發(fā)起和決議，更新系統(tǒng)中的數(shù)據(jù)狀態(tài)
• Server：Server中存在兩種類型：Follower和Observer。其中Follower接受客戶端的請求并返回結(jié)果（事務(wù)請求將轉(zhuǎn)發(fā)給Leader處理），并在選舉過程中參與投票；Observer與Follower功能一致，但是不參與投票過程，它的存在是為了提高系統(tǒng)的讀取速度
• Client：請求發(fā)起方，Server和Client之間可以通過長連接的方式進行交互。如發(fā)起注冊或者請求集群信息等。

3.Dubbo

Dubbo的服務(wù)發(fā)現(xiàn)模塊基于zookeeper實現(xiàn)。
Eureka是spring cloud之下一個專門負責(zé)微服務(wù)服務(wù)注冊和發(fā)現(xiàn)的組件，Eureka就是為了服務(wù)發(fā)現(xiàn)而設(shè)計的。是Dubbo對應(yīng)的概念的一個部分。

4.Eureka

Eureka 是 Netflix 出品的用于實現(xiàn)服務(wù)注冊和發(fā)現(xiàn)的工具。 Spring Cloud 集成了 Eureka，并提供了開箱即用的支持。其中， Eureka 又可細分為 Eureka Server 和 Eureka Client。

上圖是來自eureka的官方架構(gòu)圖，這是基于集群配置的eureka?
– 處于不同節(jié)點的eureka通過Replicate進行數(shù)據(jù)同步?
– Application Service為服務(wù)提供者?
– Application Client為服務(wù)消費者?
– Make Remote Call完成一次服務(wù)調(diào)用

服務(wù)啟動后向Eureka注冊，Eureka Server會將注冊信息向其他Eureka Server進行同步，當(dāng)服務(wù)消費者要調(diào)用服務(wù)提供者，則向服務(wù)注冊中心獲取服務(wù)提供者地址，然后會將服務(wù)提供者地址緩存在本地，下次再調(diào)用時，則直接從本地緩存中取，完成一次調(diào)用。

當(dāng)服務(wù)注冊中心Eureka Server檢測到服務(wù)提供者因為宕機、網(wǎng)絡(luò)原因不可用時，則在服務(wù)注冊中心將服務(wù)置為DOWN狀態(tài)，并把當(dāng)前服務(wù)提供者狀態(tài)向訂閱者發(fā)布，訂閱過的服務(wù)消費者更新本地緩存。

Zookeeper與Eureka的區(qū)別

想要了解Zk與eureka的區(qū)別首先要知道CAP定理

?

CAP定理

?

1. Zookeeper保證CP
當(dāng)向注冊中心查詢服務(wù)列表時，我們可以容忍注冊中心返回的是幾分鐘以前的注冊信息，但不能接受服務(wù)直接down掉不可用。也就是說，服務(wù)注冊功能對可用性的要求要高于一致性。但是zk會出現(xiàn)這樣一種情況，當(dāng)master節(jié)點因為網(wǎng)絡(luò)故障與其他節(jié)點失去聯(lián)系時，剩余節(jié)點會重新進行l(wèi)eader選舉。問題在于，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集群都是不可用的，這就導(dǎo)致在選舉期間注冊服務(wù)癱瘓。在云部署的環(huán)境下，因網(wǎng)絡(luò)問題使得zk集群失去master節(jié)點是較大概率會發(fā)生的事，雖然服務(wù)能夠最終恢復(fù)，但是漫長的選舉時間導(dǎo)致的注冊長期不可用是不能容忍的。

?

2.Eureka保證AP

Eureka看明白了這一點，因此在設(shè)計時就優(yōu)先保證可用性。Eureka各個節(jié)點都是平等的，幾個節(jié)點掛掉不會影響正常節(jié)點的工作，剩余的節(jié)點依然可以提供注冊和查詢服務(wù)。而Eureka的客戶端在向某個Eureka注冊或時如果發(fā)現(xiàn)連接失敗，則會自動切換至其它節(jié)點，只要有一臺Eureka還在，就能保證注冊服務(wù)可用（保證可用性），只不過查到的信息可能不是最新的（不保證強一致性）。除此之外，Eureka還有一種自我保護機制，如果在15分鐘內(nèi)超過85%的節(jié)點都沒有正常的心跳，那么Eureka就認為客戶端與注冊中心出現(xiàn)了網(wǎng)絡(luò)故障，此時會出現(xiàn)以下幾種情況：?

1. Eureka不再從注冊列表中移除因為長時間沒收到心跳而應(yīng)該過期的服務(wù)?
2. Eureka仍然能夠接受新服務(wù)的注冊和查詢請求，但是不會被同步到其它節(jié)點上（即保證當(dāng)前節(jié)點依然可用）?
3. 當(dāng)網(wǎng)絡(luò)穩(wěn)定時，當(dāng)前實例新的注冊信息會被同步到其它節(jié)點中

因此， Eureka可以很好的應(yīng)對因網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點失去聯(lián)系的情況，而不會像zookeeper那樣使整個注冊服務(wù)癱瘓。

你可能也喜歡:

微服務(wù)系列：Dubbo與SpringCloud的Ribbon、Hystrix、Feign的優(yōu)劣勢比較

如何從0到1設(shè)計一個類Dubbo的RPC框架

RPC框架的實現(xiàn)原理，及RPC架構(gòu)組件詳解

阿里P8架構(gòu)師談：從單體架構(gòu)、到SOA、再到微服務(wù)的架構(gòu)設(shè)計詳解

阿里P8架構(gòu)師談：Zookeeper的原理和架構(gòu)設(shè)計，以及應(yīng)用場景

阿里P8架構(gòu)師談：微服務(wù)Dubbo和SpringCloud架構(gòu)設(shè)計、優(yōu)劣勢比較

---

總結(jié)

以上是生活随笔為你收集整理的微服务系列：服务注册与发现的实现原理、及实现优劣势比较的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。