Spring Cloud五大組件

Spring Cloud是分布式微服務架構的一站式解決方案，在Spring Boot基礎上能夠輕鬆搭建微服務系統的架構。

現有Spring Cloud有兩代實現：

一代：Spring Cloud Netflix，主要由：Eureka、Ribbon、Feign、Hystrix、Zuul｜Gateway、Config等組件組成。

二代：Spring Cloud Alibaba，主要由：Nacos、Sentinel、Seata等組件組成。

一、服務治理組件

一代的服務治理組件為：Spring Cloud Netflix Eureka，主要負責Spring Cloud的服務發現與服務註冊。

二代的服務治理組件為：Spring Cloud Alibaba Nacos，可以將Nacos理解為服務註冊中心和配置中心的結合體；可以替換一代組件中的：Eureka、Config。

1.1 Eureka

Eureka採用C/S架構，包含兩大組件：

Eureka Server：服務註冊中心，其他微服務啟動時，服務註冊到Eureka Server。Eureka Server維護了可用服務列表，存儲所有註冊到Eureka Server的服務的信息。

自己搭建的Eureka Server服務端：https://Gitee.com/Xiaoxinnolabi/my-eureka-server

Eureka Client：客戶端，也就是微服務集群中的各個微服務。微服務啟動後，Eureka Client會向Eureka Server發送心跳（默認周期30S）。Eureka Server在多個心跳周期內（默認90S）沒有接收到某個Eureka Client的心跳，則將該Eureka Client從可用服務列表移除。

Eureka實現服務註冊與發現的原理：

服務註冊中心（Register Service）：Eureka Server，提供服務註冊和服務發現功能
服務提供者（Provider Service）：Eureka Client，服務的提供者，以供應服務給消費者所發現。
服務消費者（Consumer Service）：Eureka Client，服務的消費者，從服務註冊中心獲取服務列表，調用所需服務。
調用所需服務：通過HTTP或者消息中間件遠程調用服務提供者提供的服務。

1.2 Nacos

Nacos 英文全稱為 Dynamic Naming and Configuration Service，是一個由阿里巴巴團隊使用 Java 語言開發的開源項目。

Nacos採用C/S架構，包含兩大組件：

Nacos Server：可以作為服務註冊中心、配置中心，幫助Nacos Client實現服務的發現、註冊，配置的動態刷新。

Nacos Client：通過spring-cloud-starter-alibaba-nacos-discovery，在Nacos Server中實現服務的註冊和發現；通過spring-cloud-starter-alibaba-nacos-config，在Nacos Server中實現配置的動態刷新。

Nacos實現服務註冊與發現的流程：

Nacos Server啟動
服務提供者Nacos Client啟動，把spring.appliction.name服務名註冊到Nacos Server
服務消費者Nacos Client啟動，把spring.appliction.name服務名註冊到Nacos Server，從Nacos Server獲取一份服務註冊信息（包含所有註冊到Nacos Server中的服務的信息）。
服務消費者進行服務消費時，通過HTTP或RPC調用所需服務。

Nacos特性：

服務發現

支持基於DNS和RPC的服務發現。當服務提供者使用原生SDK、OpenAPI或一個獨立的Agent TODO向Nacos註冊服務後，服務消費者可以通過HTTP、DNS TODO、API查找、發現服務。

服務健康監測

提供對服務的實施健康檢查，能夠阻止請求發送到不健康主機或服務實例上。提供了健康檢查儀錶盤，能夠根據健康狀態管理服務的可用性流量

動態配置服務

動態配置服務可以讓我們以中心化、外部化和動態化的方式，管理所有環境的應用配置和服務配置。

Nacos 提供了一個簡潔易用的 UI 幫助我們管理所有服務和應用的配置。Nacos 還提供包括配置版本跟蹤、金絲雀發布、一鍵回滾配置以及客戶端配置更新狀態跟蹤在內的一系列開箱即用的配置管理特性，幫助我們更安全地在生產環境中管理配置變更和降低配置變更帶來的風險。

動態DNS服務

Nacos 提供了動態 DNS 服務，能夠讓我們更容易地實現負載均衡、流量控制以及數據中心內網的簡單 DNS 解析服務。

Nacos 提供了一些簡單的 DNS APIs TODO，可以幫助我們管理服務的關聯域名和可用的 IP:PORT 列表。

服務及其元數據管理

Nacos 能讓我們從微服務平台建設的視角管理數據中心的所有服務及元數據，包括管理服務的描述、生命周期、服務的靜態依賴分析、服務的健康狀態、服務的流量管理、路由及安全策略、服務的 SLA 以及 metrics 統計數據。

二、負載均衡組件

一代的負載均衡組件為：Spring Cloud Ribbon，主要負責Spring Cloud的客戶端負載均衡和服務調用工具。

二代的負載均衡組件為：Spring Cloud Ribbon或Spring Cloud LoadBalancer；由於Spring Cloud Ribbon已停止更新，進入維護階段，因此LoadBalancer是Ribbon新版的解決方案；基於現有市場大部分依舊使用Spring Cloud Ribbon，僅對Spring Cloud Ribbon做介紹。

2.1 Spring Cloud Ribbon

Spring Cloud Ribbon 是一套基於 Netflix Ribbon 實現的客戶端負載均衡和服務調用工具。

Ribbon 是 Spring Cloud 體系中最核心、最重要的組件之一。它雖然只是一個工具類型的框架，並不像 Eureka Server（服務註冊中心）那樣需要獨立部署，但它幾乎存在於每一個使用 Spring Cloud 構建的微服務中。

負載均衡

將用戶請求平攤到多個伺服器上，以達到擴展伺服器帶寬、增強數據處理能力、增加吞吐量、提高網絡的可用性和靈活性的目的。

常見負載均衡方式：

服務端負載均衡

如常規前後端交互中間件Nginx，在客戶端和服務端直接建立一個獨立的負載均衡器，負載均衡器記錄可用伺服器列表，通過心跳機制刪除故障節點。

請求從客戶端發送時，通過中間件Nginx，按照特定算法（輪詢、隨機），從可用伺服器選擇服務端進行轉發。

客戶端負載均衡

客戶端負載均衡是將負載均衡邏輯以代碼的形式封裝到客戶端上，即負載均衡器位於客戶端。客戶端通過服務註冊中心（例如 Eureka Server）獲取到一份服務端提供的可用服務清單。有了服務清單後，負載均衡器會在客戶端發送請求前通過負載均衡算法選擇一個服務端實例再進行訪問，以達到負載均衡的目的；客戶端負載均衡也需要心跳機制去維護服務端清單的有效性，這個過程需要配合服務註冊中心一起完成。

Ribbon 就是一個基於 HTTP 和 TCP 的客戶端負載均衡器，當我們將 Ribbon 和 Eureka 一起使用時，Ribbon 會從 Eureka Server（服務註冊中心）中獲取服務端列表，然後通過負載均衡策略將請求分攤給多個服務提供者，從而達到負載均衡的目的。

三、熔斷器組件

微服務系統架構中，一個請求往往需要多個服務配合處理完成；當一個服務出現故障時，沿著調用鏈路導致微服務故障在系統中蔓延，最終導致整個系統的癱瘓，這就是「雪崩效應」。為了能夠及時對服務故障進行熔斷處理，微服務架構引入了熔斷器組件，確保整個系統的服務容錯、加強保護機制。

3.1 Spring Cloud Hystrix

Spring Cloud Hystrix 是一款優秀的服務容錯與保護組件，也是 Spring Cloud 中最重要的組件之一。

Spring Cloud Hystrix 能夠有效地阻止分布式微服務系統中出現聯動故障，以提高微服務系統的彈性。Spring Cloud Hystrix 具有服務降級、服務熔斷、線程隔離、請求緩存、請求合併以及實時故障監控等強大功能。

四、服務網關組件

在微服務架構中，一個系統往往由多個微服務組成，而這些服務可能部署在不同機房、不同地區、不同域名下。這種情況下，客戶端（例如瀏覽器、手機、軟體工具等）想要直接請求這些服務，就需要知道它們具體的地址信息，例如 IP 地址、埠號等。

可以通過服務網關，請求直接到服務網關，再由服務網關根據不同的標識信息將請求轉發到微服務實例。

可以在服務網關中處理一些非業務功能的邏輯，例如權限驗證、監控、緩存、請求路由等。

常見服務網關實現方案：

Spring Cloud Gateway
Spring Cloud Netflix Zuul
Nginx + Lua

4.1 Spring Cloud Gateway

Spring Cloud GateWay 最主要的功能就是路由轉發，而在定義轉發規則時主要涉及了以下三個核心概念，如下表。

核心概念	描述
Route（路由）	網關最基本的模塊。它由一個 ID、一個目標 URI、一組斷言（Predicate）和一組過濾器（Filter）組成。
Predicate（斷言）	路由轉發的判斷條件，我們可以通過 Predicate 對 HTTP 請求進行匹配，例如請求方式、請求路徑、請求頭、參數等，如果請求與斷言匹配成功，則將請求轉發到相應的服務。
Filter（過濾器）	過濾器，我們可以使用它對請求進行攔截和修改，還可以使用它對上文的響應進行再處理。

Spring Cloud Gateway 工作流程說明如下：

客戶端將請求發送到 Spring Cloud Gateway 上。
Spring Cloud Gateway 通過 Gateway Handler Mapping 找到與請求相匹配的路由，將其發送給 Gateway Web Handler。
Gateway Web Handler 通過指定的過濾器鏈（Filter Chain），將請求轉發到實際的服務節點中，執行業務邏輯返迴響應結果。
過濾器之間用虛線分開是因為過濾器可能會在轉發請求之前（pre）或之後（post）執行業務邏輯。
過濾器（Filter）可以在請求被轉發到服務端前，對請求進行攔截和修改，例如參數校驗、權限校驗、流量監控、日誌輸出以及協議轉換等。
過濾器可以在響應返回客戶端之前，對響應進行攔截和再處理，例如修改響應內容或響應頭、日誌輸出、流量監控等。
響應原路返回給客戶端。

總而言之，客戶端發送到 Spring Cloud Gateway 的請求需要通過一定的匹配條件，才能定位到真正的服務節點。在將請求轉發到服務進行處理的過程前後（pre 和 post），我們還可以對請求和響應進行一些精細化控制。

Predicate 就是路由的匹配條件，而 Filter 就是對請求和響應進行精細化控制的工具。有了這兩個元素，再加上目標 URI，就可以實現一個具體的路由了。

五、分布式配置組件

5.1 Spring Cloud Config

在分布式微服務系統中，幾乎所有服務的運行都離不開配置文件的支持，這些配置文件通常由各個服務自行管理，以 properties 或 yml 格式保存在各個微服務的類路徑下，例如 application.properties 或 application.yml 等。

為了解決這些問題，通常我們都會使用配置中心對配置進行統一管理。市面上開源的配置中心有很多，例如百度的 Disconf、淘寶的 diamond、360 的 QConf、攜程的 Apollo 等都是解決這類問題的。Spring Cloud 也有自己的分布式配置中心，那就是 Spring Cloud Config。

Spring Cloud Config 是由 Spring Cloud 團隊開發的項目，它可以為微服務架構中各個微服務提供集中化的外部配置支持。

Spring Cloud Config 包含以下兩個部分：

Config Server：也被稱為分布式配置中心，它是一個獨立運行的微服務應用，用來連接配置倉庫並為客戶端提供獲取配置信息、加密信息和解密信息的訪問接口。
Config Client：指的是微服務架構中的各個微服務，它們通過 Config Server 對配置進行管理，並從 Config Sever 中獲取和加載配置信息。

Spring Cloud Config 工作流程如下：

開發或運維人員提交配置文件到遠程的 Git 倉庫。
Config 服務端（分布式配置中心）負責連接配置倉庫 Git，並對 Config 客戶端暴露獲取配置的接口。
Config 客戶端通過 Config 服務端暴露出來的接口，拉取配置倉庫中的配置。
Config 客戶端獲取到配置信息，以支持服務的運行。