漫談微服務架構：什麼是Spring Cloud，爲什麼要選擇Spring Cloud

 

 

Spring Cloud是基於Spring Boot的，所以還在使用SpringMVC的同窗要先了解Spring Boot。先上一段官話，Spring Cloud是一個基於Spring Boot實現的雲應用開發工具，它爲基於JVM的雲應用開發中涉及的配置管理、服務發現、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分佈式會話和集羣狀態管理等操做提供了一種簡單的開發框架。

Spring Cloud並無重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，經過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。

 

 

Spring Cloud全家桶

上面的圖是Spring Cloud的全家桶，一應俱全，猶如水電，涉及到開發的方方頁面。

Spring Cloud從設計之初就考慮了絕大多數互聯網公司架構演化所需的功能，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等。

首先是核心服務治理的組件（服務註冊與發現）Spring Cloud Eureka

Eureka是Netflix開源的一款提供服務註冊和發現的產品，Eureka就是一個服務中心，將全部的能夠提供的服務都註冊到它這裏來管理，其它各調用者須要的時候去註冊中心獲取，而後再進行調用，避免了服務之間的直接調用，方便後續的水平擴展、故障轉移等。以下圖：

 

 

 

固然服務中心這麼重要的組件一但掛掉將會影響所有服務，所以須要搭建Eureka集羣來保持高可用性，生產中建議最少兩臺。隨着系統的流量不斷增長，須要根據狀況來擴展某個服務，Eureka內部已經提供均衡負載的功能，只須要增長相應的服務端實例既可。那麼在系統的運行期間某個實例掛了怎麼辦？Eureka內容有一個心跳檢測機制，若是某個實例在規定的時間內沒有進行通信則會自動被剔除掉，避免了某個實例掛掉而影響服務。

所以使用了Eureka就自動具備了註冊中心、負載均衡、故障轉移的功能。

固然還有另一個實現組件Spring Cloud Consul，這裏不作多介紹。

隨着微服務不斷的增多，每一個微服務都有本身對應的配置文件。在研發過程當中有測試環境、UAT環境、生產環境，所以每一個微服務又對應至少三個不一樣環境的配置文件。這麼多的配置文件，若是須要修改某個公共服務的配置信息，如：緩存、數據庫等，不免會產生混亂，這個時候就須要引入Spring Cloud另一個組件：Spring Cloud Config。

Spring Cloud Config

Spring Cloud Config是一個解決分佈式系統的配置管理方案。它包含了Client和Server兩個部分，其實就是Server端將全部的配置文件服務化，須要配置文件的服務實例去Config Server獲取對應的數據。將全部的配置文件統一整理，避免了配置文件碎片化。

若是服務運行期間改變配置文件，服務是不會獲得最新的配置信息，須要解決這個問題就須要引入Refresh。能夠在服務的運行期間從新加載配置文件，當全部的配置文件都存儲在配置中心的時候，配置中心就成爲了一個很是重要的組件。若是配置中心出現問題將會致使災難性的後果，所以在生產中建議對配置中心作集羣，來支持配置中心高可用性。

Hystrix

在微服務架構中一般會有多個服務層調用，基礎服務的故障可能會致使級聯故障，進而形成整個系統不可用的狀況，這種現象被稱爲服務雪崩效應。

以下圖所示：A做爲服務提供者，B爲A的服務消費者，C和D是B的服務消費者。A不可用引發了B的不可用，並將不可用像滾雪球同樣放大到C和D時，雪崩效應就造成了。

 

 

 

在這種狀況下就須要整個服務機構具備故障隔離的功能，避免某一個服務掛掉影響全局。在Spring Cloud 中Hystrix組件就扮演這個角色。

Hystrix會在某個服務連續調用N次不響應的狀況下，當即通知調用端調用失敗，避免調用端持續等待而影響了總體服務。Hystrix間隔時間會再次檢查此服務，若是服務恢復將繼續提供服務。

Hystrix Dashboard和Turbine

當熔斷髮生的時候須要迅速的響應來解決問題，避免故障進一步擴散，那麼對熔斷的監控就變得很是重要。熔斷的監控如今有兩款工具：Hystrix-dashboard和Turbine。

Hystrix-dashboard是一款針對Hystrix進行實時監控的工具，經過Hystrix Dashboard咱們能夠直觀地看到各Hystrix Command的請求響應時間, 請求成功率等數據。可是隻使用Hystrix Dashboard的話, 你只能看到單個應用內的服務信息, 這明顯不夠. 咱們須要一個工具能讓咱們彙總系統內多個服務的數據並顯示到Hystrix Dashboard上, 這個工具就是Turbine. 監控的效果圖以下：

 

 

 

Spring Cloud Bus消息總線

Refresh方案雖然能夠解決單個微服務運行期間重載配置信息的問題，可是在真正的實踐生產中，可能會有N多的服務須要更新配置，若是每次依靠手動Refresh將是一個巨大的工做量，這時候Spring Cloud提出了另一個解決方案：Spring Cloud Bus

Spring Cloud Bus經過輕量消息代理鏈接各個分佈的節點。這會用在廣播狀態的變化（例如配置變化）或者其它的消息指令中。Spring Cloud Bus的一個核心思想是經過分佈式的啓動器對Spring Boot應用進行擴展，也能夠用來創建一個或多個應用之間的通訊頻道。目前惟一實現的方式是用AMQP消息代理做爲通道。

Spring Cloud Bus是輕量級的通信組件，也能夠用在其它相似的場景中。有了Spring Cloud Bus以後，當咱們改變配置文件提交到版本庫中時，會自動的觸發對應實例的Refresh，具體的工做流程以下：

 

 

 

服務網關

在微服務架構模式下，後端服務的實例數通常是動態的，對於客戶端而言很難發現動態改變的服務實例的訪問地址信息。所以在基於微服務的項目中爲了簡化前端的調用邏輯，一般會引入API Gateway做爲輕量級網關，同時API Gateway中也會實現相關的認證邏輯從而簡化內部服務之間相互調用的複雜度。 

 

 

 

Spring Cloud體系中支持API Gateway落地的技術就是Zuul。Spring Cloud Zuul路由是微服務架構中不可或缺的一部分，提供動態路由，監控，彈性，安全等的邊緣服務。Zuul是Netflix出品的一個基於JVM路由和服務端的負載均衡器。它的具體做用就是服務轉發，接收並轉發全部內外部的客戶端調用。使用Zuul能夠做爲資源的統一訪問入口，同時也能夠在網關作一些權限校驗等相似的功能。

鏈路跟蹤

隨着服務的愈來愈多，對調用鏈的分析會愈來愈複雜，如服務之間的調用關係、某個請求對應的調用鏈、調用之間消費的時間等，對這些信息進行監控就成爲一個問題。在實際的使用中咱們須要監控服務和服務之間通信的各項指標，這些數據將是咱們改進系統架構的主要依據。所以分佈式的鏈路跟蹤就變的很是重要，Spring Cloud也給出了具體的解決方案：Spring Cloud Sleuth和Zipkin

 

 

 

Spring Cloud Sleuth爲服務之間調用提供鏈路追蹤。經過Sleuth能夠很清楚的瞭解到一個服務請求通過了哪些服務，每一個服務處理花費了多長時間。從而讓咱們能夠很方便的理清各微服務間的調用關係。分佈式鏈路跟蹤須要Sleuth+Zipkin結合來實現，固然實現鏈路追蹤的還有三方開源方案，若是zipkin實現的功能很是簡單，圖形化能力也不強，因此能夠試試其它的方案，如pinpoint較成熟的框架等。說到這裏順便給你們推薦一個架構學習交流圈。交流學習企鵝圈號：519-752-913 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

Feign

聲明式遠程調度組件。

Ribbon

負載均衡組件

Spring Cloud Data Flow

大數據操做組件，它是Spring XD的替代品，也是一個混合計算模型，能夠經過命令行的方式操做數據流

Spring Cloud Task

組件基於Spring Tsak，提供任務調度和任務管理的功能

以上只介紹常常用到很是重要的內容，通常的技術棧爲 SpringCloud +GitLab+Jinkins進行普通服務的開發持續集成部署CI，後面可升級用SpingCloud +GitLab+Jinkins+Docker容器化佈署，進一步升級到用 SpingCloud +GitLab+Jinkins+Docker+k8s自動化容器編排內容，這裏的難度等級就徹底不同了，並且每個組件都涉及到不少內容，傳統業務如何進行微服務的拆分下次再進行討論。