【華為云專家原創】 服務注冊與發現如何滿足服務治理？

摘要：本文主要介紹了服務注冊與發現的原理，以及常用的幾種服務注冊與發現組件介紹對比，

在單體應用向微服務架構演進的程序中，原本的巨石型應用會按照業務需求被拆分成多個微服務，每個服務提供特定的功能，并可能依賴于其他的微服務，每個微服務實體都可以動態部署，服務實體之間的呼叫通過輕量級的遠程呼叫方式（HTTP、訊息佇列等）實作，它們之間通過預先定義好的介面進行訪問，

由于服務實體是動態部署，每個服務實體的地址和服務資訊都可能動態變化，勢必需要一個中心化的組件對各個服務實體的資訊進行管理，該組件管理了各個部署好的服務實體元資料，包括不僅限于服務名、IP 地址、埠號、服務描述和服務狀態等，

什么是服務注冊與發現？

服務注冊與發現主要包含兩部分：服務注冊與服務發現，服務注冊是指服務實體啟動時將自身資訊注冊到服務注冊與發現中心，并在運行時通過心跳等方式向服務注冊與發現中心匯報自身服務狀態；服務發現是指服務實體向服務注冊與發現中心獲取其他服務實體資訊，用于進行接下來的遠程呼叫，接下來讓我們介紹服務注冊與發現中心的職責和服務實體進行服務注冊的基本流程，以及分布式系統中資料同步的基本原理 CAP，

服務注冊與發現中心有什么功能？

在傳統單體應用中，應用都是部署在固定的物理機器或者云平臺上，他們之間的呼叫一般是通過固定在代碼內部或者組態檔的服務地址和埠直接發起，由于應用數量較少，系統結構復雜度不高，開發人員和運維人員可以較為輕松地進行管理和配置，

隨著應用架構向微服務架構遷移，服務數量的增加和動態部署動態擴展的特性，使得服務地址和埠在運行時是隨時可變的，對此，我們需要一個額外的中心化組件統一管理動態部署的微服務應用的服務實體元資料，一般稱它為服務注冊與發現中心，服務注冊與發現中心主要有以下的職責：

• 管理當前注冊到服務注冊與發現中心的微服務實體元資料資訊，包括服務實體的 服務名、IP 地址、埠號、服務描述和服務狀態等；
• 與注冊到服務發現與注冊中心的微服務實體維持心跳，定期檢查注冊表中的服務實體是否在線，并剔除無效服務實體資訊；
• 提供服務發現能力，為服務呼叫方提供服務提供方的服務實體元資料，

通過服務發現與注冊中心，可以很方便地管理系統中動態變化的服務實體資訊，與此同時，它也可能成為系統的瓶頸和故障點，因為服務之間的呼叫資訊來自于服務注冊與發現中心，當它不可用時，服務之間的呼叫可能無法正常進行，因此服務發現與注冊中心一般會集群化部署，提供高可用性和高穩定性，

分布式中的 CAP 理論

在本質上來講，微服務應用屬于分布式系統的一種落地實踐，而分布式系統最大的難點是處理各個節點之間資料狀態的一致性，即使是倡導無狀態的 HTTP RESTful API 請求，在處理多服務實體情況下的修改資料狀態請求，也是需要通過資料庫或者分布式快取等外部系統維護資料的一致性，CAP 原理是描述分布式系統下節點資料同步的基本定理，

CAP 原理由加州大學的 Eric Brewer 教授提出，分別指 Consistency (一致性)、Availablity (可用性)、Partition tolerance (磁區容忍性)，Eric Brewer 認為，以上三個指標最多同時滿足兩個，

• Consistency，指資料一致性，表示一個系統的資料資訊(包括備份資料)在同一時刻都是一致的，在分布式系統下，同一份資料可能存在于多個不同的實體中，在資料強一致性的要求下，對其中一份資料的修改必須同步到它的所有備份中，在資料同步的任何時候，都需要保證所有對該份資料的請求將回傳同樣的狀態，
• Availablity，指服務可用性，要求服務在接受到客戶端請求后，都能夠給出回應，服務可用性考量的是系統的可用性，要求系統在高并發情況下和部分節點宕機的情況下，系統整體依然能夠回應客戶端的請求，
• Partition tolerance，指磁區容忍性，在分布式系統中，不同節點之間是通過網路進行通信，基于網路的不可靠性，位于不同網路磁區的服務節點可能會通信失敗，如果系統能夠容忍這種情況，說明它是滿足磁區容忍性的，如果系統不能夠滿足磁區容忍性，那么將會限制分布式系統的擴展性，即服務節點的部署數量和地區都會受限，違背了分布式系統設計的初衷，所以一般來講分布式系統都會滿足磁區容忍性，

在滿足了磁區容忍性的前提下，分布式系統并不能同時滿足資料一致性和服務可用性，假設服務A現在有兩個實體A1和A2，它們之間的網路通信出現了例外，基于磁區容忍性，這并不會影響A1和A2獨立的正常運行，假如此時客戶端請求A1，請求將資料B從B1狀態修改為B2，由于網路的不可用，資料B的修改并不能通知到實體A2，如果此時另一個客戶端向A2請求資料B，如果A2回傳資料B1，將滿足服務可用性，但并不能滿足資料一致性；如果A2需要等待A1的通知之后才能夠回傳資料B的正確狀態，雖然滿足了資料一致性，但并不能回應客戶端請求，違背了服務可用性的指標，

基于分布式系統的基本特質，P 是必須要滿足，接下來需要考慮滿足 C 還是 A，在類似銀行之類對金額資料要求強一致性的系統中，要優先考慮滿足資料一致性；而類似大眾網頁之類的系統，用戶對網頁版本的新舊不會有特別的要求，在這種場景下服務可用性高于資料一致性，

如何選擇服務注冊與發現框架？

隨著近幾年微服務框架高速發展，目前業界已經開源出了大量優秀的服務注冊與發現組件，包括不僅限于 Consul、Etcd、Zookeeper、Eureka，它們之間各有千秋，在組件選型時可以根據自身業務的需要進行選擇和改造，接下來我們主要對 Consul、Etcd、Zookeeper 作一些簡單的介紹和比較，

基于 Raft 演算法、開箱即用的服務發現系統 Consul

Consul 由 HashiCorp 開源，是支持多個平臺的分布式高可用系統，Consul 使用 Golang 語言實作，主要用于實作分布式系統的服務發現與配置，滿足 AP 特性，Consul 是分布式、高可用和可橫向擴展的，提供以下主要特性：

• 服務發現：可以使用 HTTP 或者 DNS 的方式將服務實體的元資料注冊到 Consul，和通過 Consul 發現所依賴服務的元資料串列，
• 檢查檢查：Consul 提供定時的健康檢查機制，定時請求注冊到 Consul 中的服務實體提供的健康檢查介面，將例外回傳的服務實體標記為不健康，
• Key/Value：Consul 提供了 Key/Value 存盤功能，可以通過簡單的 HTTP 介面進行使用，
• 多資料中心：Consul 使用 Raft演算法來保證資料一致性，提供了開箱即用的多資料中心功能，

服務實體與 Consul 的互動如下圖所示：

Consul 與服務實體的互動程序

通過 Consul 實作服務注冊與發現中心的呼叫程序如下：

1. Producer在啟動之扯訓通過 /register 介面將自己的服務實體元資料注冊到 Consul 中；
2. Consul 通過 Producer 提供的健康檢查介面 /health 定時檢查 Producer 的服務實體狀態；
3. Consumer 請求 Consul 的介面獲取 Producer 服務的元資料；
4. Consumer 從 Consul 中回傳的 Producer 服務實體元資料串列中選擇合適的服務實體，使用其配置的 IP 和埠資訊發起服務呼叫，如圖 7-1 中 Consumer 呼叫 Producer 的 /service 介面，

Consul 是一個高可用的分布式系統，支持多資料中心部署，一個 Consul 集群由多個部署和運行了 Consul Agent 的節點組成，Consul 集群中存在兩種角色，Server 和 Client，每個 Consul Agent 負責對本地的服務進行監控檢查，并將查詢請求轉發到 Server 中進行處理，Consul 簡單的架構圖如下圖所示：

Consul 架構圖

從上圖可知，Consul 主要由 Consul Client 和 Consul Server 組成，且 Consul 使用 Gossip 協議來管理成員和廣播訊息到集群，

Consul 作為一個開箱即用、高可用分布式服務發現和配置系統，可以很方便地為微服務的服務治理提供強有力的支持，在后面的課時中，我們將實作一個 Consul 的客戶端，將我們自身的 Web 服務注冊到 Consul 中，以供其他服務或者網關呼叫，

基于 HTTP 協議的分布式 key/Value 存盤系統 Etcd

Etcd 是由 CoreOS 開源，采用 Golang 語言撰寫的分布式、高可用的 Key/Value 存盤系統，主要用于服務發現和配置共享，Ectd 的經典應用場景有：

• Key/Value 存盤：Etcd 支持 HTTP RESTful API，提供強一致性、高可用的資料存盤能力，
• 服務發現：通過在 Etcd 中注冊某個服務的目錄，服務實體連接 Etcd 并在目錄下發布對應 IP 和 Port 以供呼叫方使用，可以有效實作服務注冊與發現的功能；
• 訊息發布與訂閱：通過 Etcd 的 Watcher 機制，可以使訂閱者訂閱他們關心的目錄，當訊息發布者修改被監控的目錄內容時，可以將變化實時通知給訂閱者，

Etcd 的集群的基本架構圖

相對于其他的組件來講，Etcd 更為輕量級，部署簡單，支持 HTTP 介面，它可以為服務發現提供一個穩定高可用的訊息注冊倉庫，為微服務協同作業提供了有力的支持，

重量級一致性服務系統 Zookeeper

Zookeeper 作為 Hadoop 和 Hbase 的重要組件，是一個開源的分布式應用協調服務，目前由 Apache 基金會維護，采用 Java 語言開發，Zookeeper 致力于為分布式應用提供一致性服務，它的設計目標是將分布式系統中那些復雜且容易出錯的服務封裝為簡單高效的介面以供開發人員使用，

Zookeeper 底層只提供了兩個功能，管理客戶端提交的資料和為客戶端程式提供資料節點的監聽服務，它是一個典型的分布式資料一致性解決方案，基于 ZooKeeper 可以實作服務發現與注冊、訊息發布與訂閱、分布式協調與通知、分布式鎖、Master 選舉、集群管理和分布式佇列等諸多功能，

Zookeeper 集群中存在三種角色，分別為 Leader、Follower 和 Observer，架構圖如圖所示：

Zookeeper 架構圖

Zookeeper 通過 ZAB 協議來保證其資料一致性，ZAB 不是一種通用的分布式一致性演算法，它是在 Paxos 演算法的基礎上，為 Zookeeper 特別設計的崩潰可恢復的原子訊息廣播協議，ZAB 協議主要包含兩種基本模式，崩潰恢復和訊息廣播：

• 崩潰恢復模式：在服務啟動或者 Leader 服務器崩潰時，ZAB協議就會進入崩潰恢復模式，在所有的 Follower 中選舉出 Leader，當選舉了新的 Leader 后，集群中有半數與新的Leader 完成狀態同步后就會退出恢復模式，進入到訊息廣播模式，
• 訊息廣播模式：ZAB協議訊息廣播程序使用的是一個原子廣播協議，類似于一個二階段提交，但是又有所不同，并非所有 Follower 節點都回傳 Ack 才進行一致性事務完成，而是只需要半數以上即可提交完成一個事務廣播，

Zookeeper 為分布式系統提供協調服務，能夠有效地支持微服務架構的服務注冊和發現機制，同時 Zookeeper 中提供的其他資料一致性解決方案，能夠有力支撐微服務中分布式業務的開發，

服務注冊與發現組件的對比

以上介紹的三種服務注冊與發現組件在業界都已經有了廣泛的應用，在很多大公司的專案中都能看到它們的身影，比如 Zookeeper 在 Hadoop 體系中發揮了極其重要的分布式協調作用，下面將從特性方面比較他們的異同：

從軟體的生態出發，Consul 是以服務發現和配置作為主要功能目標，附帶提供了 Key/Value 存盤，相對于 Etcd 和 Zookeeper 來講業務范圍較小，更適合于服務注冊與發現，Etcd 和 Zookeeper 屬于通用的分布式一致性存盤系統，被應用于分布式系統的協調作業中，使用范圍抽象，具體的業務場景需要開發人員自主實作，如服務發現、分布式鎖等，Zookeeper 具備廣大的周邊生態，在分布式系統中得到了廣泛的使用；而 Etcd 以簡單易用的特性吸引了大量開發人員，在目前火熱的 Kubernetes 中也有應用，僅從服務注冊與發現組件的需求來看，選擇 Consul 作為服務注冊與發現中心能夠取得更好的效果；如果系統存在其他分布式一致性協作需求，選擇 Etcd 和 Zookeeper 反而能夠提供更多的服務支持，

小結

本文主要介紹了服務注冊與發現的原理，以及常用的幾種服務注冊與發現組件介紹對比，服務注冊與發現在微服務架構中是各個微服務之間的協調者，因此掌握服務注冊與發現的基本原理，正確使用服務注冊與發現組件是非常重要的一件事，在接下來的文章中，我們將基于 Consul 實作 Go 微服務的服務注冊與發現，

本文分享自華為云社區《【華為云專家原創】 服務注冊與發現如何滿足服務治理？》，原文作者：aoho ，

點擊關注，第一時間了解華為云新鮮技術~