詳解微服務架構及其演進史

微服務全景架構全面瓦解

微服務架構拆分策略詳解

微服務的注冊與發(fā)現

我們前面在全景架構中對服務注冊與發(fā)現做了大致的說明，本章我們著重詳細說明微服務下注冊與發(fā)現的這個能力。

微服務注冊與發(fā)現類似于生活中的"電話通訊錄"的概念，它記錄了通訊錄服務和電話的映射關系。在分布式架構中，服務會注冊進去，當服務需要調用其它服務時，就這里找到服務的地址，進行調用。

步驟如下：

• 1、你先要把"好友某某"記錄在通訊錄中。
• 2、撥打電話的時候通過通訊錄中找到"好友某某"，并撥通回電話。
• 3、當好友某某電話號碼更新的時候，需要通知到你，并修改通訊錄服務中的號碼。

從這個過程中我們看到了一些特點：

• 1、把 "好友某某" 的電話號碼寫入通訊錄中，統(tǒng)一在通訊錄中維護，后續(xù)號碼變更也是更新到通訊錄中，這個過程就是服務注冊的過程。
• 2、后續(xù)我們通過"好友某某"就可以定位到通訊錄中的電話號碼，并撥通電話，這個過程理解為服務發(fā)現的過程。

而我們微服務架構中的服務注冊與發(fā)現結構如下圖所示：

圖片中是一個典型的微服務架構，這個結構中主要涉及到三大角色：

• provider - 服務提供者
• consumer - 服務消費者
• register center - 注冊中心

它們之間的關系大致如下：

1. 1、每個微服務在啟動時，將自己的網絡地址等信息（微服務的ServiceName、IP、Port、MetaData等）注冊到注冊中心，注冊中心存儲這些數據。
2. 2、服務消費者從注冊中心查詢服務提供者的地址，并通過該地址調用服務提供者的接口。
3. 3、各個微服務與注冊中心使用一定機制（例如心跳）通信。如果注冊中心與某微服務長時間無法通信，就會注銷該實例。

優(yōu)點如下：

1. 1、解耦：服務消費者跟服務提供者解耦，各自變化，不互相影響
2. 2、擴展：服務消費者和服務提供者增加和刪除新的服務，對于雙方沒有任何影響
3. 3、中介者設計模式：用一個中介對象來封裝一系列的對象交互，這是一種多對多關系的中介者模式。

從功能上拆開主要有三塊：服務注冊、服務發(fā)現，和注冊中心。我們一個一個來看。

1、服務注冊

如圖中，為Register注冊中心注冊一個服務信息，會將服務的信息：ServiceName、IP、Port以及服務實例MetaData元數據信息寫入到注冊中心。當服務發(fā)生變化的時候，也可以更新到注冊中心。

服務提供者（服務實例） 的服務注冊模型是一種簡單、容易理解、流行的服務注冊模型，其在多種技術生態(tài)中都有所體現：

1. 1、在K8S生態(tài)中，通過 K8S Service服務信息，和Pod的 endpoint（用來記錄service對應的pod的訪問地址）來進行注冊。
2. 2、在Spring Cloud生態(tài)中，應用名 對應 服務Service，實例 IP + Port 對應 Instance實例。比較典型的就是A服務，后面對應有多個實例做負載均衡。 
3. 3、在其他的注冊組件中，比如 Eureka、Consul，服務模型也都是 服務→ 服務實例。

可以認為服務實例是一個真正的實體的載體，服務是對這些相同能力或者相同功能服務實例的一個抽象。

2、服務發(fā)現

服務發(fā)現實際就是我們查詢已經注冊好的服務提供者，比如 p->p.queryService(serviceName)，通過服務名稱查詢某個服務是否存在，如果存在，

返回它的所有實例信息，即一組包含ip 、 port 、metadata元數據信息的endpoints信息。

這一組endpoints信息一般會被緩存在本地，如果注冊中心掛掉，可保證段時間內依舊可用，這是去中心化的做法。對于單個 Service 后面有多個 Instance的情況（如上圖），做 load balance。

服務發(fā)現的方式一般有兩種：

1、拉取的方式：服務消費方（Consumer）主動向注冊中心發(fā)起服務查詢的請求。

2、推送的方式：服務訂閱/通知變更（下發(fā)）：服務消費方（Consumer）主動向注冊中心訂閱某個服務，當注冊中心中該服務信息發(fā)生變更時，注冊中心主動通知消費者。 

3、注冊中心

注冊中心提供的基本能力包括：提供服務注冊、服務發(fā)現 以及 健康檢查。

服務注冊跟服務發(fā)現上面已經詳細介紹了， 健康檢查指的是指注冊中心能夠感知到微服務實例的健康狀況，便于上游微服務實例及時發(fā)現下游微服務實例的健康狀況。采取必備的訪問措施，如避免訪問不健康的實例。

主要的檢查方式包括：

1. 1、服務Provider 進行 TTL 健康匯報（Time To Live，微服務Provider定期向注冊中心匯報健康狀態(tài)）。
2. 2、注冊中心主動檢查服務Provider接口。

綜合我們前面的內容，可以總結下注冊中心有如下幾種能力：

1、高可用

這個主要體現在兩個方面。一個方面是，注冊中心本身作為基礎設施層，具備高可用；第二種是就是前面我們說到的去中心化，極端情況下的故障，短時間內是不影響微服務應用的調用的

2、可視化操作

常用的注冊中心，類似 Eureka、Consul 都有比較豐富的管理界面，對配置、服務注冊、服務發(fā)現進行可視化管理。

3、高效運維

注冊中心的文檔豐富，對運維的支持比較好，并且對于服務的注冊是動態(tài)感知獲取的，方便動態(tài)擴容。

4、權限控制

數據是具有敏感性，無論是服務信息注冊或服務是調用，需要具備權限控制能力，避免侵入或越權請求

5、服務注冊推、拉能力

這個前面說過了，微服務應用程序（服務的Consumer），能夠快速感知到服務實例的變化情況，使用拉取或者注冊中心下發(fā)的方式進行處理。 

4、現下的主流注冊中心

4.1 Eureka

4.1.1 介紹

Eureka是Netflix OSS套件中關于服務注冊和發(fā)現的解決方案。因為Spring Cloud 在它的微服務解決方案中對Eureka進行了集成，并作為優(yōu)先推薦方案進行宣傳，所以早期有用 Spring Cloud 來建設微服務系統(tǒng)的同學會比較熟悉。

目前大量公司的微服務系統(tǒng)中依舊使用Eureka作為注冊中心，它的核心設計思想也被后續(xù)大量注冊中心產品借鑒。但目前 Eureka 2.0已經停止維護，所以新的微服務架構設計中，不再建議使用。

Spring Cloud Netflix主要分為兩個部分：

1、Eureka Server： 作為注冊中心Server端，向微服務應用程序提供服務注冊、發(fā)現、健康檢查等能力。

2、Eureka Client：  微服務應用程序Client端，用以和Eureka Server進行通信。

 Eureka有比較友好的管理界面，如上圖所示：

1、System Status：顯示當前Eureka Server信息。

2、Instances Current registered with Eureka：在Eureka Server當前注冊的數據，在Spring Cloud生態(tài)中，被注冊的服務可以唄發(fā)現并羅列在這個地方。

3、General Info：基本信息，如cpu、內存、環(huán)境等。

4.1.2 整體架構

Eureka Server可以運行多個實例來構建集群，解決單點問題，但不同于ZooKeeper的選舉leader的過程，Eureka Server采用的是Peer to Peer對等通信。

所以他有如下特點：

1. 1、去中心化的架構：無master/slave區(qū)分，每一個Peer都是對等的。在這種架構中，節(jié)點通過彼此互相注冊來提高可用性，每個節(jié)點需要添加一個或多個有效的serviceUrl指向其他節(jié)點。每個節(jié)點都可被視為其他節(jié)點的副本。
2. 2、故障轉移/故障恢復：如果某臺Eureka Server宕機，Eureka Client的請求會自動切換到新的Eureka Server節(jié)點，當宕機的服務器重新恢復后，Eureka會再次將其納入到服務器集群管理之中。
3. 3、節(jié)點復制：當節(jié)點開始接受客戶端請求時，所有的操作都會進行replicateToPeer（節(jié)點間復制）操作，將請求復制到其他Eureka Server當前所知的所有節(jié)點中。
   同理，一個新的Eureka Server節(jié)點啟動后，會首先嘗試從鄰近節(jié)點獲取所有實例注冊表信息，完成初始化。
4. 4、CAP模式：復制算法非強一致性算法，而是當有數據寫入時，Eureka Server將數據同步給其他的節(jié)點，因此Eureka在CAP提系統(tǒng)（一致性、可用性、分區(qū)容錯性）是典型的AP系統(tǒng)。

4.1.3 接入Spring Cloud

如上圖所示：

1、Provider 服務提供者：服務向注冊中心注冊服務信息，即 服務 -> 服務實例 數據模型， 同時定時向注冊中心匯報健康檢查，如果一定時間內（一般90s）沒有進行心跳匯報，則會被注冊中心剔除。

所以這邊注意，注冊中心感知到應用下線并進行剔除這個過程可能比較長。 

2、Consumer 服務消費者：服務向注冊中心獲取所需服務對應的服務實例信息。這邊需要注意，Eureka不支持訂閱，因此在Spring Cloud生態(tài)中，通過定時拉取方式從注冊中心中獲取所需的服務實例信息。

3、Remote Call 遠程調用：Consumer從注冊中心獲取的Provider的實例信息，通過 Load Balance的策略，確定一個實際的實例，發(fā)起遠程調用。 

4.2 ZooKeeper

4.2.1 介紹

作為一個分布式的、開源的協調服務，ZooKeeper實現了一系列基礎功能，包括簡單易用的接口。

這些接口被用來實現服務的注冊與發(fā)現功能。并實現一些高級功能，如數據同步、分布式鎖、配置中心、集群選舉、命名服務等。

在數據模型上，類似于傳統(tǒng)的文件系統(tǒng)，節(jié)點類型分為：

1、持久節(jié)點：節(jié)點創(chuàng)建后，就一直存在，除非執(zhí)行刪除操作，主動刪掉這個節(jié)點。

2、臨時節(jié)點（注冊中心場景下的主要實現機制）：臨時節(jié)點的生命周期和客戶端會話綁定。也就是說，如果客戶端會話失效，那么這個節(jié)點就會自動被清除掉。

在實際場景下，微服務啟動的時候，會創(chuàng)建一個服務臨時節(jié)點，等把服務停止，短時間后節(jié)點就沒有了。

Zookeeper有如下特點：

1. 1、最終一致性：為客戶端展示同一視圖，這是zookeeper最重要的功能。
2. 2、可靠性：如果消息被到一臺服務器接受，那么它將被所有的服務器接受。
3. 3、實時性：Zookeeper不能保證兩個客戶端能同時得到剛更新的數據，如果需要最新數據，應該在讀數據之前調用sync()接口。
4. 4、等待無關（wait-free）：慢的或者失效的client不干預快速的client的請求。
5. 5、原子性：更新只能成功或者失敗，沒有中間狀態(tài)。
6. 6、順序性：所有Server，同一消息發(fā)布順序一致。

4.2.2 整體架構

上圖是Zookeeper 的服務架構，他有如下流程：

1. 1、 多個節(jié)點組成分布式架構，每個Server在內存中存儲一份數據； 
2. 2、通過選舉產生leader，通過 Paxos(帕克索斯)強一致性算法 進行保證，是典型的CP結構。
3. 3、Leader負責處理數據更新等操作（Zab協議）；

4.2.3 接入Dubbo生態(tài)

上圖中的角色如下：

Provider：提供者,服務發(fā)布方

Consumer：消費者, 調用服務方

Container：Dubbo容器.依賴于Spring容器

Registry：注冊中心，當Container啟動時把所有可以提供的服務列表上Registry中進行注冊，告訴Consumer提供了什么服務，以及服務方的位置

Monitor:監(jiān)聽器

說明：ZooKeeper在注冊中心方面對Dubbo生態(tài)支持的比較好。服務提供者Providerzai Container啟動時主動向注冊中心Registry ZooKeeper中注冊信息。

服務消費者Consumer啟動時向注冊中心Registry ZooKeeper中訂閱注冊中心，當Provider的信息發(fā)生變化時，注冊中心ZooKeeper會主動向Consumer進行推送通知變更。

這邊注意與Eureka的區(qū)別，這是主動推送通知，是注冊中心下發(fā)的操作。

4.3 Consul

4.3.1 介紹

Consul是HashiCorp推出的一款軟件，是一個Service Mesh解決方案，提供了功能豐富的控制面功能：

1、Service Discovery（服務發(fā)現）

2、Configuration（配置化）

3、Segmentation Functionality

這些功能可以根據需要獨立使用，或者將它們一起使用用來構建完整的Service Mesh。

Consul提供的關鍵功能如下：

1. 1、Service Discovery：服務注冊/發(fā)現功能。
2. 2、Health Checking：健康檢查，豐富的健康檢查方式；
3. 3、KV Store：KV存儲功能，可應用多種場景，如動態(tài)配置存儲，分布式協調、leader選舉等。
4. 4、Multi DataCenter：多數據中心。

4.3.2 整體架構

如上圖為Consul的架構，這邊對技術點做一下說明：

1、Raft: 一種分布式一致性算法，Consul使用該算法報紙強一致性，所以也是典型的CP模式

2、Client：Client是一種agent，其將會重定向所有的RPC 請求到Server。Client是無狀態(tài)的，其主要參與LAN Gossip協議池。其占用很少的資源，并且消耗很少的網絡帶寬。

3、Server：Server是一種agent，其包含了一系列的責任包括：參與Raft協議寫半數（Raft Quorum）、維護集群狀態(tài)、響應RPC響應、和其他Datacenter通過WAN gossip交換信息和重定向查詢請求至leader或者遠端Datacenter。

4、Datacenter: Datacenter其是私有的、低延遲、高帶寬的網絡環(huán)境，去除了在公共網絡上的網絡交互。

5、Consensus: Consensus一致性在leader 選舉、順序執(zhí)行transaction 上。當這些事務已經提交至有限狀態(tài)機（finite-state machine）中，Consul定義consensus作為復制狀態(tài)機的一致性。本質上使用實現了Raft協議，對于具體實現細節(jié)可參考 Consensus Protocol。

6、Gossip：Consul使用了Serf，其提供了Gossip協議多種用途，Serf提供成員關系、失敗檢查和事件廣播。

7、LAN Gossip: Local Area Network Gossip其包含在同一個網絡環(huán)境或Datacenter的節(jié)點。

8、WAN Gossip: Wide Area Network Gossip 其只包含Server節(jié)點，這些server分布在不同的datacenter中，其主要通過因特網或廣域網相互交流。

9、RPC: 遠程過程調用，用于服務之間的通信。

10、CAP抉擇：在高可用方面，Consul使用Raft協議作為其分布式一致性協議，本身對故障節(jié)點有一定的容忍性，在單個DataCenter中Consul集群中節(jié)點的數量控制在2*n + 1個節(jié)點，其中n為可容忍的宕機個數，通常為3個節(jié)點。

所以是典型的CP模式。

根據Consul 的選舉機制和服務原理，我們有兩個注意點 ：

1、部署Consul Service 節(jié)點應該奇數為宜，因為+1的偶數節(jié)點和奇數節(jié)點可容忍的故障數是一樣的，比如上圖3和4，另一方面，偶數個節(jié)點在選主節(jié)點的時候可能會出現二分選票的情況，還得重新選舉。

2、Consul Service 節(jié)點數不是越多越好，雖然Server數量越多可容忍的故障數越多，但是Raft進行日志復制也是很耗時間的，而且Server數量越多，性能越低，所以結合實際場景，一般建議Server部署3個即可。 

有興趣的同學可以去Consul官網看看它的選舉機制，還可以對比下Redis中Sentinel模式。

4.3.3 生態(tài)對接

對接Spring Cloud生態(tài)

Consul作為注冊中心，集成在Spring Cloud生態(tài)。可以看出，跟Eureka對接到Spring Cloud 生態(tài)的過程很像。

但是這邊的健康檢查更豐富，可以有多種不同的的Check方式：

• Script check（Script+ Interval）
• 基于HTTP請求
• 基于tcp請求
• 基于grpc請求

4.4 總結對比

4種注冊中心技術對比

這邊是對業(yè)內4種注冊中心各緯度上的對比，Eureka是典型的AP類型，Zookeeper和Consul是典型的CP類型。如何選擇取決你的業(yè)務是傾向A：高可用性 還是 C：強一致性。

當然，業(yè)務是復雜的，在真正的技術選型時，還是要根據自己的實際業(yè)務現狀來判斷。有一些傾向，比如你的系統(tǒng)是Spring Cloud體系下，那優(yōu)先選擇Eureka、Consul。

如果業(yè)務會更多向云原生對齊，則Consul、Etcd會是比較優(yōu)先的選擇。

以上就是微服務架構之服務注冊與發(fā)現功能詳解的詳細內容，更多關于服務注冊與發(fā)現功能的資料請關注腳本之家其它相關文章！

最新評論