本文中我們主要介紹微服務開發框架——Spring Cloud。儘管Spring Cloud帶有"Cloud"的字樣，但它並不是雲計算解決方案，而是Spring Boot的基礎上構建的，用於快速構建分佈式系統的通用模式的工具集。
Spring Cloud的特點
Spring Cloud有以下特點:
- 約定優於配置；
- 適用於各種環境。開發、部署PC Server或各種雲環境（例如阿里雲、AWS等）均可；
- 隱藏了組件的複雜性，並提供聲明式、無xml的配置方式；
- 開箱即用，快速啓動；
- 輕量級的組件。Spring Cloud整合的組件大多比較輕量。例如Eureka、Zuul等，都是各自領域輕量級的實現；
- 組件豐富，功能齊全。Spring Cloud 爲微服務架構提供了非常完整的支持。例如、配置管理、服務發現、斷路器、微服務網關等；
- 選型中立、豐富。例如，Spring Cloud支持使用Eureka、Zookeeper或Consul實現服務發現；
- 靈活。Spring Cloud的組成部分是解耦的，開發人員可以按需靈活挑選技術選型。
Spring Cloud版本簡介
Spring Cloud版本
由上圖可知，Spring Cloud是以英文單詞+SR+數字的形式命名版本號的。那麼英文單詞和SR分別表示什麼呢？
因爲Spring Cloud是一個綜合項目，它包含很多子項目。由於子項目也維護着自己的版本號，Spring Cloud採用了這種命名方式，從而避免與子項目的版本混淆。其中英文單詞如Edware是倫敦某地鐵站名，它們按照字母順序發行，可以將其理解爲主版本的演進。SR表示"Service Release"，一般表示Bug修復。
版本兼容性如下
版本兼容性
版本內容
版本內容
可參考官方文檔：https://spring.io/projects/spring-cloud#overview
Spring Cloud分佈式開發五大組件
- 服務發現——Netflix Eureka
- 客戶端負載均衡——Netflix Ribbon
- 斷路器——Netflix Hystrix
- 服務網關——Netflix Zuul
- 分佈式配置——Spring Cloud Config
Eureka
Eureka
我的上一篇博客(微服務理論篇)中談到，對單體應用進行服務拆分得到各個微服務，而這些服務又是相互獨立的，那麼我們如何知道各個微服務的健康狀態、如何知道某個微服務的存在呢？由此、一個擁有服務發現的框架顯得尤爲重要。這也就是Eureka誕生的原因。
- Eureka是由Netflix開發的服務發現框架，本身是一個基於RESTful的服務，主要用於定位運行在AWS域中的中間層服務。
- 由兩個組件組成：Eureka Server和Eureka Client。Eureka Server提供服務註冊服務，各個節點啓動後，會在Eureka Server中進行註冊，這樣EurekaServer中的服務註冊表中將會存儲所有可用服務節點的信息，服務節點的信息可以在界面中直觀的看到。Eureka Client即爲微服務節點。
- Eureka Client啓動後，將會註冊到Eureka Server中，同時會定時發送心跳（默認無配置情況下爲30s），如果Eureka Server在多個心跳週期內沒有接收到某個節點的心跳，那麼Eureka Server將會從服務註冊表中把這個節點移除(默認90s)。
- Eureka Server之間通過複製的方式完成數據同步，Eureka還提供了客戶端緩存機制，即使所有的Eureka Server都掛掉，客戶端依然可以利用緩存中的信息消費其他服務的API。
綜上，Eureka通過心跳檢查、客戶端緩存等機制，確保了系統的高可用性、靈活性和可伸縮性。
Ribbon
Ribbon
通過使用Eureka已經實現了微服務的註冊與發現。啓動各個微服務時，Eureka Client會把自己的網絡信息註冊到Eureka Server上。似乎一切更美好了一些。然而，這樣的架構依然有一些問題，如負載均衡。一般來說，各個微服務都會部署多個實例。那麼服務消費者要如何將請求分攤到多個服務提供實例上呢？
- Ribbon(負載均衡器)的作用正是提供負載均衡機制，當爲Ribbon配置服務提供者地址列表後，Ribbon就可以基於某種負載均衡算法，自動地幫助服務消費者去請求。
- Ribbon提供的負載均衡算法有多種，例如輪詢、加權響應時間、隨機和區域感知輪詢。
-
Ribbon與Eureka配合使用時，Ribbon可自動從Eureka Server獲取服務提供者地址列表，並基於負載均衡算法，請求其中一個服務提供者示例。(大致架構如下圖)
Ribbon與Eureka配合使用
Hystrix
如果服務提供者相應非常慢，那麼消費者對提供者的請求就會被強制等待，知道提供者響應或超時。在高負載場景下，如果不作任何處理，此類問題可能會導致服務消費者的資源耗竭甚至整個系統崩潰。
微服務架構的應用系統通常包含多個服務層。微服務之間通過網絡進行通信，從而支撐起整個應用系統，因此，微服務之間難免存在依賴關係。而這種由於"基礎服務故障"導致"級聯故障"的現象稱爲雪崩效應。
雪崩效應
如圖所示，A最爲服務提供者（基礎服務），B爲A的服務消費者，C和D是B的服務消費者。當A不可用引起了B的不可用，並將不可用像滾雪球一樣放大到C和D時，雪崩效應就形成了。
那麼Hystrix是如何容錯的呢？
- 爲網絡請求設置超時；
-
使用斷路器模式：斷路器可理解爲對容易導致錯誤操作的代理。這種代理能夠統計一段時間內調用失敗的次數，並決定是正常請求依賴的服務還是直接返回；斷路器可以實現快速失敗，如果它在一段時間內檢測到許多類似的錯誤(例如超時)，就會在之後的一段時間內，強迫對該服務的調用快速失敗，即不請求所依賴的服務。這樣，應用程序就無須再浪費CPU時間去等待長時間的超時。斷路器也可以自動診斷依賴的服務是否已經恢復正常，如果發現依賴的服務已經恢復正常，那麼就會恢復請求該服務。
斷路器狀態轉換圖
以下對該圖做個簡單講解：
- 正常情況下，斷路器關閉，可以正常請求依賴的服務；
- 當一段時間內，請求失敗率達到一定閾值（例如錯誤率達到50%，或100次/分鐘等），斷路器就會打開，此時，就不會再去請求依賴的服務；
- 斷路器打開一段時間後，會自動進入"半開"狀態。此時，斷路器允許一個請求訪問依賴的服務。如果請求能夠調用成功，則關閉斷路器；否則繼續保持打開狀態。
Zuul
Zuul作爲微服務架構中的微服務網關。微服務架構經過前幾個組件的組合，已經有了基本的雛形了，那麼我們爲什麼還要使用微服務網關呢？我們可以想象，一般情況下我們一個業務並不是只調用一個接口就可以完成一個業務需求。
如果讓客戶端直接與各個微服務通信，會有以下問題：
- 客戶端會多次請求不同的微服務，增加了客戶端的複雜性；
- 存在跨域請求，在一定場景下處理相對複雜；
- 認證複雜，每個服務都需要獨立認證；
- 難以重構，隨着項目的迭代，可能需要重新劃分微服務，如果直接與微服務通信，那麼重構會很難實施；
微服務網關
如圖，微服務網關封裝了應用程序的內部結構，客戶端只須跟網關交互，而無須直接調用特定微服務接口。同時，還有以下優點：
- 易於監控；
- 易於認證：可在微服務網關上進行認證，然後再將請求轉發到後端的微服務，而無須在每個微服務中進行認證；
- 減少了客戶端與各個微服務之間的交互次數。
Config
爲什麼要同一管理微服務配置？
對於傳統的單體應用，常常使用配置文件管理所有配置。例如一個Spring Boot 項目開發的單體應用，可以將配置內容放到application.yml文件中。如果需要切換環境，可以設置多個Profile,並在啓用應用時指定spring.profile.active={profile}。
而在微服務架構中，微服務的配置管理一般有以下需求：
- 集中管理配置：一個使用微服務架構的應用系統可能會包含成百上千個微服務，因此，集中管理配置是很有必要的；
- 不同環境不同配置。例如，數據源配置在不同的環境(開發、測試、預發佈、生產等)中是不同的;
- 運行期間可動態調整：例如，可根據各個微服務的負載情況，動態調整數據源連接池的大小或熔斷閾值，並且在調整配置時不停止微服務；
- 配置修改後可自動更新：如配置內容發生變化，微服務能夠自動更新配置。
作者：Jerry_Liang
鏈接：https://www.jianshu.com/p/196a7598b30c
來源：簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。