服務注冊與發現的來源

首先，服務注冊與發現是來自于微服務架構的產物。

在傳統的服務架構中，服務的規模處于運維人員的可控范圍內。當部署服務的多個節點時，一般使用靜態配置的方式實現服務信息的設定。而在微服務應用中，服務實例的數量和網絡地址都是動態變化的，這對系統運維提出了巨大的挑戰。

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

這就是服務注冊與發現的來源，在微服務架構中，服務注冊與發現組件是必不可少的，常用的服務協調器有：Eureka、Zookeeper，ANS、Dubbo、Etcd等。

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

服務注冊與發現主要解決的問題

在一個分布式系統中，服務注冊與發現組件主要解決兩個問題：服務注冊和服務發現。

1.服務注冊

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

2.服務發現

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

除此之外，服務注冊與發現需要關注監控服務實例運行狀態等問題。

3.監控

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

關系調用說明：

• 服務生產者啟動時，向服務注冊中心注冊自己提供的服務
• 服務消費者啟動時，在服務注冊中心訂閱自己所需要的服務
• 注冊中心返回服務提供者的地址信息個消費者
• 消費者從提供者中調用服務

服務注冊與發現的特點

1.高可用

由多個服務節點構成，就算有些節點掛掉也不影響正常運行，避免了單點故障。

2.方便配置

本身是一個分布式，一致性的 k-v 存儲系統。提供方啟動的時候將自身配置信息向協調器中進行注冊，提供方下線的時候向協調器進行反注冊。

3.可監控

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

服務注冊發現的實現方式

我從服務注冊發現實現的早期到現在主流的Zookpeer介紹，這樣可以更加直觀的了解到對應的優劣勢，更有利于今后的選型升級。

1. DNS（早期）

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

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

如果服務的提供者出現故障，由于DNS緩存的存在，服務的調用方會仍然將請求轉發給出現故障的服務提供方。

2.Zookeeper

Zookeeper是google開源的在Java語言上實現的分布式協調服務，是Hadoop和Hbase的重要組件，提供了數據/發布訂閱、負載均衡、分布式同步等功能。

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

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

3.Dubbo

Dubbo的服務發現模塊基于zookeeper實現。
Eureka是spring cloud之下一個專門負責微服務服務注冊和發現的組件，Eureka就是為了服務發現而設計的。是Dubbo對應的概念的一個部分。

4.Eureka

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

上圖是來自eureka的官方架構圖，這是基于集群配置的eureka?
– 處于不同節點的eureka通過Replicate進行數據同步?
– Application Service為服務提供者?
– Application Client為服務消費者?
– Make Remote Call完成一次服務調用

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

當服務注冊中心Eureka Server檢測到服務提供者因為宕機、網絡原因不可用時，則在服務注冊中心將服務置為DOWN狀態，并把當前服務提供者狀態向訂閱者發布，訂閱過的服務消費者更新本地緩存。

Zookeeper與Eureka的區別

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

?

CAP定理

?

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

?

2.Eureka保證AP

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

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

因此， Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況，而不會像zookeeper那樣使整個注冊服務癱瘓。

你可能也喜歡:

微服務系列：Dubbo與SpringCloud的Ribbon、Hystrix、Feign的優劣勢比較

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

RPC框架的實現原理，及RPC架構組件詳解

阿里P8架構師談：從單體架構、到SOA、再到微服務的架構設計詳解

阿里P8架構師談：Zookeeper的原理和架構設計，以及應用場景

阿里P8架構師談：微服務Dubbo和SpringCloud架構設計、優劣勢比較

---

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。