• 前言
• 1. 服務發現基礎知識
  • 1.1 注冊中心與服務發現的聯系
  • 1.2 使用 DNS 與負載均衡器發現服務的弊端
  • 1.3 云中的服務發現應該具備的特點
  • 1.4 服務發現架構
  • 1.5 服務治理的概念
  • 1.6 服務注冊的概念
  • 1.7 RPC 遠程呼叫框架核心設計思想
  • 1.8 Eureka 與 Dubbo 的系統架構對比圖
  • 1.9 注冊中心的 CAP 理論
  • 1.10 AP 架構和 CP 架構
  • 1.10 目前幾種流行的注冊中心對比
• 2. Eureka
• 3. Nacos
• 4. Zookeeper
• 5. Consul
• 最后

前言

參考資料：
《Spring Microservices in Action》
《Spring Cloud Alibaba 微服務原理與實戰》
《B站 尚硅谷 SpringCloud 框架開發教程 周陽》

注冊中心用來集中管理微服務，實作服務的注冊，發現，檢查等功能；

1. 服務發現基礎知識

1.1 注冊中心與服務發現的聯系

• 注冊中心是用來集中管理微服務，實作服務的注冊，發現，檢查等功能；
• 服務 A 與服務 B 注冊進注冊中心 C，形成服務注冊表（表里登記了服務 A 和服務 B 的地址等相關資訊），當 A 服務想要訪問 B 服務時，可以通過注冊中心 C 的服務發現機制，獲取服務注冊表進而找到服務 B；

1.2 使用 DNS 與負載均衡器發現服務的弊端

• 這種模型適用于在企業資料中心內部運行的應用程式，以及在一組靜態服務器上運行少量服務的情況；
• 對基于云的微服務應用程式不使用，理由如下：
  • 單點故障：如果負載均衡器出現故障，那么依賴它的每個應用程式都會出現故障；
  • 有限的水平可伸縮性：大多數商業負載均衡器使用熱插拔模型實作冗余，只能使用單個服務器來處理負載，跨多個服務器水平伸縮負載均衡基礎設施的能力有限；
  • 靜態管理：大多數傳統的負載均衡器不是為快速注冊和注銷服務設計的，它們使用集中式資料庫來存盤規則的路由；
  • 復雜：需要手動定義和部署服務的映射規則；

1.3 云中的服務發現應該具備的特點

• 高可用：如果一個節點變得不可用，集群中的其他節點應該能夠接管作業；
• 點對點：每個節點共享服務實體的狀態；
• 負載均衡：在所有服務實體之間動態地對請求進行負載均衡；
• 有彈性：務發現的客戶端應該在本地快取服務資訊；
• 容錯：需要檢測出服務實體什么時候是不健康的，并從可以接收客戶端請求的可用服務串列中移除該實體；

1.4 服務發現架構

• 服務發現需要關注的四個概念：
  • 服務注冊；
  • 服務地址的客戶端查找；
  • 資訊共享；
  • 健康監測；
    
• 這種方法很脆弱，因為服務客戶端完全依賴于服務發現引擎來查找和呼叫服務；

1.5 服務治理的概念

• 在傳統的 RPC 遠程呼叫框架中，管理每個服務與服務之間依賴關系比較復雜，管理比較復雜，所以需要使用服務治理，管理服務于服務之間依賴關系；
• 可以實作：服務呼叫、負載均衡、容錯等，實作服務發現與注冊；

1.6 服務注冊的概念

• 在服務注冊與發現中，有一個注冊中心；
• 當服務器啟動的時候，會把當前自己服務器的資訊，如：服務地址通訊地址等以別名方式注冊到注冊中心上；
• 另一方（消費者|服務提供者），以該別名的方式去注冊中心上獲取到實際的服務通訊地址，然后再實作本地 RPC 呼叫 ；

1.7 RPC 遠程呼叫框架核心設計思想

• 在于注冊中心，因為使用注冊中心管理每個服務與服務之間的一個依賴關系（服務治理概念）；
• 在任何RPC 遠程框架中，都會有一個注冊中心，用于存放服務地址相關資訊（介面地址）；

1.8 Eureka 與 Dubbo 的系統架構對比圖

1.9 注冊中心的 CAP 理論

• CAP 含義：
  • C：Consistency 強一致性：注冊一個服務，集群下多節點必須全部注冊成功后才能進行訪問和使用；master節點掛掉了需要等待重新選舉成功后才能使用，選舉期間服務不可用； (所有節點在同一時間具有相同的服務)；
  • A：Availability 可用性：注冊一個服務，只要有一個節點注冊成功就可以對外提供訪問；master節點掛了也可以正常使用； (保證每個請求不管成功或者失敗都有回應)；
  • P：Partition tolerance 磁區容錯性：把服務注冊到每個節點，增強容錯機制 (系統中任意資訊的丟失或失敗不會影響系統的繼續運作)；
• CAP 理論關注粒度是資料，而不是整體系統設計的策略；
• CAP理論的核心是：一個分布式系統不可能同時很好的滿足一致性，可用性和磁區容錯性這三個需求；因此，根據 CAP 原理將 NoSQL 資料庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三大類：
  • CA 原則：單點集群，滿足一致性，可用性的系統，通常在可擴展性上不太強大；
  • CP 原則：滿足一致性，磁區容忍性的系統，通常性能不是特別高；
  • AP 原則：滿足可用性，磁區容忍性的系統，通常可能對一致性要求低一些；
• 經典CAP圖：

1.10 AP 架構和 CP 架構

• AP 架構：
  • 當網路磁區出現后，為了保證可用性，系統 B 可以回傳舊值，保證系統的可用性；
  • 結論：違背了一致性 C 的要求，只滿足可用性和磁區容錯，即 AP；
    
• CP 架構：
  • 當網路磁區出現后，為了保證一致性，就必須拒接請求，否則無法保證一致性；
  • 結論：違背了可用性 A 的要求，只滿足一致性和磁區容錯，即 CP；
    

1.10 目前幾種流行的注冊中心對比

• 基礎對比：

• 功能與支持性對比：

2. Eureka

Eureka 是 Netflix 開發的服務發現框架，本身是一個基于REST的服務，主要用于定位運行在 AWS 域中的中間層服務，以達到負載均衡和中間層服務故障轉移的目的；
Spring Cloud 將它集成在其子專案 spring-cloud-netflix 中，以實作 Spring Cloud 的服務發現功能；

• 點擊跳轉：微服務架構 | 3.1 Netflix Eureka 注冊中心

3. Nacos

Nacos 致力于解決微服務中的統一配置、服務注冊與發現等問題，它提供了一組簡單易用的特性集，幫助開發者快速實作動態服務發現、服務配置、服務元資料及流量管理；

• 點擊跳轉：微服務架構 | 3.2 Alibaba Nacos 注冊中心
• 點擊跳轉：微服務架構 | *3.5 Nacos 服務注冊與發現的原始碼分析

4. Zookeeper

ZooKeeper 是一個分布式的，開放原始碼的分布式應用程式協調服務，是 Google 的 Chubby 一個開源的實作，是 Hadoop 和 Hbase 的重要組件，它是一個為分布式應用提供一致性服務的軟體，提供的功能包括：配置維護、域名服務、分布式同步、組服務等；

• 點擊跳轉：微服務架構 | 3.3 Apache Zookeeper 注冊中心

5. Consul

Consul 是一套開源的分布式服務發現和配置管理系統，由 HashiCorp 公司用 Go 語言開發，它提供了微服務系統中的服務治理、配置中心、控制總線等功能，這些功能中的每一個都可以根據需要單獨使用，也可以一起使用以構建全方位的服務網格，總之 Consul 提供了一種完整的服務網格解決方案；

• 點擊跳轉：微服務架構 | 3.4 HashiCorp Consul 注冊中心

最后

新人制作，如有錯誤，歡迎指出，感激不盡！ 歡迎關注公眾號，會分享一些更日常的東西！ 如需轉載，請標注出處！

標籤：架構設計

上一篇：架構師必備：系統性解決冪等問題

下一篇：微服務架構 | 3.1 Netflix Eureka 注冊中心