目錄
前言
參考資料：
《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 目前幾種流行的註冊中心對比
- 基礎對比：
| 名稱 | 廠商 | CAP 模型 | 控制檯管理 | 對外暴露介面 | 社群活躍度 |
|---|---|---|---|---|---|
| Eureka | Netflix | AP | 支援 | HTTP | 低（2.x 版本閉源） |
| Nacos | Alibaba | AP+CP 可切換 | 支援 | HTTP/DNS/UDP | 高 |
| Zookeeper | Apache | CP | 不支援 | TCP 客戶端 | 中 |
| Consul | HashiCorp | CP | 支援 | HTTP/DNS | 高 |
- 功能與支援性對比：
| 比較項 | Eureka | Nacos | Zookeeper | Consul | CoreDNS |
|---|---|---|---|---|---|
| 健康檢查 | Client Beat | TCP/HTTP/MySQL/Client Beat | Client Beat | TCP/HTTP/gRPC/CMD | / |
| 負載均衡 | Ribbon | 權重/DSL/metadata/CMDB | / | Fabio | RR |
| 雪崩保護 | 支援 | 支援 | / | / | / |
| 自動登出例項 | 支援 | 支援 | 支援 | / | / |
| 監聽支援 | 支援 | 支援 | 支援 | 支援 | / |
| 多資料中心 | 支援 | 支援 | / | 支援 | / |
| 跨註冊中心 | / | 支援 | / | 支援 | / |
| Spring Colud 整合 | 支援 | 支援 | 支援 | 支援 | / |
| Dubbo 整合 | / | 支援 | 支援 | 支援 | / |
| kubernates 整合 | / | 支援 | / | 支援 | 支援 |
2. Eureka
Eureka 是 Netflix 開發的服務發現框架，本身是一個基於REST的服務，主要用於定位執行在 AWS 域中的中間層服務，以達到負載均衡和中間層服務故障轉移的目的；
Spring Cloud 將它整合在其子專案 spring-cloud-netflix 中，以實現 Spring Cloud 的服務發現功能；
3. Nacos
Nacos 致力於解決微服務中的統一配置、服務註冊與發現等問題。它提供了一組簡單易用的特性集，幫助開發者快速實現動態服務發現、服務配置、服務後設資料及流量管理；
4. Zookeeper
ZooKeeper 是一個分散式的，開放原始碼的分散式應用程式協調服務，是 Google 的 Chubby 一個開源的實現，是 Hadoop 和 Hbase 的重要元件。它是一個為分散式應用提供一致性服務的軟體，提供的功能包括：配置維護、域名服務、分散式同步、組服務等；
5. Consul
Consul 是一套開源的分散式服務發現和配置管理系統，由 HashiCorp 公司用 Go 語言開發。它提供了微服務系統中的服務治理、配置中心、控制匯流排等功能。這些功能中的每一個都可以根據需要單獨使用，也可以一起使用以構建全方位的服務網格，總之 Consul 提供了一種完整的服務網格解決方案；
最後
