Spring Cloud應該怎麼入門？

作者|北蔡

引用 ThoughtWorks 公司的首席科學家 Martin Fowler 的一段話：簡而言之，微服務架構風格是一種将單個應用程式作為一套小型服務開發的方法，每種應用程式都在自己的程序中運作，并與輕量級機制（通常是HTTP資源API）進行通信。這些服務是圍繞業務功能建構的，可以通過全自動部署機制獨立部署。這些服務的集中管理最少，可以用不同的程式設計語言編寫，并使用不同的資料存儲技術。說到微服務，就要從單體服務開始，很多應用初期，都是單體應用，因為初期講究疊代速度，人員也很少，沒有那麼清晰的業務劃分和邊界，從靈活開發的角度，單體服務是最适合初期的。但随着業務發展，業務越來越複雜，單體應用由于部署在一個程序裡面，修改一個小功能，上線就會影響其他功能。随後系統逐漸開始拆分：從資料庫到應用，微服務就開始登場了。

什麼是Spring Cloud ？

Spring Cloud是一個微服務架構，相比Dubbo等RPC架構, Spring Cloud提供全套的分布式系統解決方案，它依賴于 Spring Boot ，有快速開發、持續傳遞和容易部署等特點。

Spring Cloud不像其他Spring子項目那樣相對獨立，它是一個擁有諸多子項目的大型綜合項目。

Spring Cloud有很多元件。

下面可以看下一個由Spring Cloud組成的架構圖：

這裡包含的Spring相關元件，有這些，下面一一介紹一下。

  服務注冊和發現元件 Eureka

介紹

利用 Eureka 元件可以很輕松地實作服務的注冊和發現功能。Eureka 元件提供了服務的健康監測，以及界面友好的 UI 。通過 Eureka 元件提供的 UI，Eureka 元件可以讓開發人員随時了解服務單元的運作情況。另外 Spring Cloud 也支援 Consul 和Zookeeper ，用于注冊和發現服務。

Eureka原理

Eureka Server：服務注冊中心。Eureka Server本身也內建了Eureka Client，彼此通過Eureka Client同步資料給其它執行個體又或者從其他執行個體同步資料。包含功能：服務剔除。

Application Service：服務提供者。包含功能：服務注冊，服務同步，服務續約，服務下線。

Application Client：服務消費者。包含功能：擷取服務，服務調用。

Make Remote Call：RESTful API的調用

us-east-1c,us-east-1d：表示一個叢集。

• CP VS AP

CAP原則又稱CAP定理，指的是在一個分布式系統中，一緻性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）。CAP 原則指的是，這三個要素最多隻能同時實作兩點，不可能三者兼顧。CAP理論提出就是針對分布式資料庫環境的，是以，P這個屬性是必須具備的。Eureka保證AP，zookeeper保證CP。zookeeper通過zab協定維持強一緻性，服務注冊相對Eureka會慢一些，要求過半數節點都寫入成功才認為注冊成功，Leader挂掉時，需要重新選舉，整個叢集不可用。Eureka為了實作更高的服務可用性，犧牲了一定的一緻性。

用戶端負載均衡 Spring Cloud Ribbon

Spring Cloud Ribbon是一個基于HTTP和TCP的用戶端負載均衡工具，它基于Netflix Ribbon實作，可以将面向服務的REST模闆請求自動轉換成用戶端負載均衡的服務調用。

• 使用

在Spring Cloud中，當Ribbon與Eureka配合使用時，Ribbon可自動從Eureka Server擷取服務提供者位址清單，并基于負載均衡算法，選擇其中一個服務提供者執行個體。

• 架構

• RestTemplate

RestTemplate實作了對HTTP請求的封裝處理，形成了一套模闆化的調用方式。

• 幾種負載均衡政策

1. RandomRule：随機選取負載均衡政策，随機Random對象，在所有服務執行個體中随機找一個服務的索引号，然後從上線的服務中擷取對應的服務。
2. RoundRobinRule：線性輪詢負載均衡政策。
3. WeightedResponseTimeRule：響應時間作為選取權重的負載均衡政策，根據平均響應時間計算所有服務的權重，響應時間越短的服務權重越大，被選中的機率越高。剛啟動時，如果統計資訊不足，則使用線性輪詢政策，等資訊足夠時，再切換到WeightedResponseTimeRule。
4. RetryRule：使用線性輪詢政策擷取服務，如果擷取失敗則在指定時間内重試，重新擷取可用服務。
5. ClientConfigEnabledRoundRobinRule：預設通過線性輪詢政策選取服務。通過繼承該類，并且對choose方法進行重寫，可以實作更多的政策，繼承後保底使用RoundRobinRule政策。
6. BestAvailableRule：繼承自ClientConfigEnabledRoundRobinRule。從所有沒有斷開的服務中，選取到目前為止請求數量最小的服務。
7. PredicateBasedRule：抽象類，提供一個choose方法的模闆，通過調用AbstractServerPredicate實作類的過濾方法來過濾出目标的服務，再通過輪詢方法選出一個服務。
8. AvailabilityFilteringRule：按可用性進行過濾服務的負載均衡政策，會先過濾掉由于多次通路故障而處于斷路器跳閘狀态的服務，還有并發的連接配接數超過門檻值的服務，然後對剩餘的服務清單進行線性輪詢。
9. ZoneAvoidanceRule：本身沒有重寫choose方法，用的還是抽象父類PredicateBasedRule的choose。

一般情況，選擇預設的就可以了。

▐  聲明式服務調用 Spring Cloud Feign

Feign是一個聲明式的 Web Service 用戶端，隻需要建立一個接口，并加上對應的 Feign Client 注解，即可進行遠端調用。

• 特性

1. 可插拔的注解支援
2. 可插拔的 HTTP 編碼器、解碼器
3. 支援 Hystrix 斷路器、Fallback
4. 支援 Ribbon 負載均衡
5. 支援 HTTP 請求、響應壓縮

▐  熔斷元件 Spring Cloud Hystrix

Hystrix是Netflix開源的一款容錯架構，包含常用的容錯方法。在高并發通路下，系統所依賴的服務的穩定性對系統的影響非常大，依賴有很多不可控的因素，比如網絡連接配接變慢，資源突然繁忙，暫時不可用，服務脫機等。Hystrix利用熔斷、線程池隔離、信号量隔離、降級回退等方法來處理依賴隔離，使系統變得高可用。

• 線程池VS信号量

相對于其他的熔斷器，Hystrix可以采用線程池來做隔離，好處是通過将發送請求線程與執行請求的線程分離，可有效防止發生級聯故障，但是弊端是就是它增加了計算的開銷，每個業務請求（被包裝成指令）在執行的時候，會涉及到請求排隊，排程和上下文切換。而且他的線程池是針對每個服務，是以服務較多的場景下，那就會有很多個線程池，這也增加了系統本身的開銷。

▐  服務網關 Spring Cloud Gateway

Spring Cloud Gateway是Spring官方推出的服務網關的實作架構，相對于服務網關的概念有點類似于傳統的反向代理伺服器（如nginx），但反向代理一般都隻是做業務無關的轉發請求，而服務網關與服務的整合程度更高，可以看作也是整個服務體系的組成部分，通過過濾器等元件可以在網關中內建一些業務處理的操作（比如權限認證等）。

• 核心概念

1. Route: 負責将某個外部請求路由到一個合适的位址，包含一個ID,一個目标位址，一系列的Predicate和Filter；
2. Predicate: 基于Java 8 Function Predicate的斷言機制，用于将請求比對到某一個Route
3. Filter: 類似于Servlet filter，可以在請求傳遞給下一級處理器之前對請求或響應進行修改，用于實作權限驗證，日志記錄，限流等功能

• 原理圖

Gateway Client發送請求給Spring Cloud Gateway，Gateway Handler Mapping會判斷請求的路徑是否比對路由的配置，如果比對則會進入Gateway Web Handler，Web Handler會讀取路由上所配置的過濾器，然後将該請求交給過濾器去處理，最後轉發到路由配置的微服務。

▐  消息驅動的微服務 Spring Cloud Stream

Spring Cloud Stream是一個用來為微服務應用建構消息驅動能力的架構。

• 特點

1. 屏蔽底層 MQ 實作細節，Spring Cloud Stream 的 API 是統一的。如果從 Kafka 切到 RocketMQ，可以直接修改配置。
2. 與 Spring 生态整合更加友善。Spring Cloud Data Flow的流計算都是基于 Spring Cloud Stream；Spring Cloud Bus 消息總線内部也是用的 Spring Cloud Stream。

Spring Mesh  下一代的Spring Cloud

▐  介紹

根據Linkerd CEO William Morgan定義，Service Mesh是用于處理服務間通信的基礎設施層，用于在雲原生應用複雜的服務拓撲中實作可靠的請求傳遞。在實踐中，Service Mesh通常是一組與應用一起部署，但對應用透明的輕量級網絡代理。目前集團也有很多落地的場景，螞蟻金服在雙11大規模落地了 SOFAMosn，阿裡巴巴在雙11的部分電商核心應用上落地了完整的 Service Mesh 解決方案，可以側面說明這塊的确是未來的發展趨勢。目前比較流行的開源軟體 Istio 和 Linkerd 都是Service Mesh的實作。

▐  架構

Service Mesh，它将分布式服務的通信抽象為單獨一層，在這一層中實作負載均衡、服務發現、認證授權、監控追蹤、流量控制等分布式系統所需要的功能，作為一個和服務對等的代理服務，和服務部署在一起，接管服務的流量，通過代理之間的通信間接完成服務之間的通信請求。替換的元件包括網關（gateway或者Zuul，由Ingress gateway或者egress替換），熔斷器（hystrix，由SideCar替換），注冊中心（Eureka及Eureka client，由Polit，SideCar替換），負責均衡（Ribbon，由SideCar替換），鍊路跟蹤及其用戶端（Pinpoint及Pinpoint client，由SideCar及Mixer替換）。

▐  優點

1. 屏蔽分布式系統通信的複雜性(負載均衡、服務發現、認證授權、監控追蹤、流量控制等等)，服務隻用關注業務邏輯；
2. 真正的語言無關，服務可以用任何語言編寫，隻需和Service Mesh通信即可；
3. 對應用透明，Service Mesh元件可以單獨更新；

推薦學習書籍

1. 《Spring Cloud 微服務實戰》：這本書比較初級，适合大概了解一下所有元件的實用方式。
2. 《分布式服務架構》：雖然不是Spring Cloud的，不過有不少分布式的實戰案例，也比較推薦。