從架構演進的角度聊聊 Spring Cloud 都作了些什麼？

引用

做者：純潔的微笑

Spring Cloud做爲一套微服務治理的框架，幾乎考慮到了微服務治理的方方面面，以前也寫過一些關於Spring Cloud文章，主要偏重各組件的使用，本次分享主要解答這兩個問題：Spring Cloud在微服務的架構中都作了哪些事情？Spring Cloud提供的這些功能對微服務的架構提供了怎樣的便利？ 

咱們先來簡單回顧一下，咱們以往互聯網架構的發展狀況： 

傳統架構發展史 

單體架構 

單體架構在小微企業比較常見，典型表明就是一個應用、一個數據庫、一個web容器就能夠跑起來，好比咱們開發的開源軟件雲收藏，就是標準的單體架構。 

在兩種狀況下可能會選擇單體架構：一是在企業發展的初期，爲了保證快速上線，採用此種方案較爲簡單靈活；二是傳統企業中垂直度較高，訪問壓力較小的業務。在這種模式下對技術要求較低，方便各層次開發人員接手，也能知足客戶需求。 

下面是單體架構的架構圖： 

在單體架構中，技術選型很是靈活，優先知足快速上線的要求，也便於快速跟進市場。 

垂直架構 

在單體架構發展一段時間後，公司的業務模式獲得了承認，交易量也慢慢的大起來，這時候有些企業爲了應對更大的流量，就會對原有的業務進行拆分，好比說：後臺系統、前端系統、交易系統等。 

在這一階段每每會將系統分爲不一樣的層級，每一個層級有對應的職責，UI層負責和用戶進行交互、業務邏輯層負責具體的業務功能、數據庫層負責和上層進行數據交換和存儲。 

下面是垂直架構的架構圖： 

在這個階段SSH（struts+spring+hibernate）是項目的關鍵技術，Struts負責web層邏輯控制、Spring負責業務層管理Bean、Hibernate負責數據庫操做進行封裝，持久化數據。 

服務化架構 

若是公司進一步的作大，垂直子系統會變的愈來愈多，系統和系統之間的調用關係呈指數上升的趨勢。在這樣的背景下，不少公司都會考慮服務的SOA化。SOA表明面向服務的架構，將應用程序根據不一樣的職責劃分爲不一樣的模塊，不一樣的模塊直接經過特定的協議和接口進行交互。這樣使整個系統切分紅不少單個組件服務來完成請求，當流量過大時經過水平擴展相應的組件來支撐，全部的組件經過交互來知足總體的業務需求。 

SOA服務化的優勢是，它能夠根據需求經過網絡對鬆散耦合的粗粒度應用組件進行分佈式部署、組合和使用。服務層是SOA的基礎，能夠直接被應用調用，從而有效控制系統中與軟件代理交互的人爲依賴性。 

服務化架構是一套鬆耦合的架構，服務的拆分原則是服務內部高內聚，服務之間低耦合。 

下面是服務化架構圖： 

在這個階段可使用WebService或者dubbo來服務治理。 

SOA和微服務架構 

SOA和微服務的區別 

其實服務化架構已經能夠解決大部分企業的需求了，那麼咱們爲何要研究微服務呢？先說說它們的區別； 

• 微服務架構強調業務系統須要完全的組件化和服務化，一個組件就是一個產品，能夠獨立對外提供服務
• 微服務再也不強調傳統SOA架構裏面比較重的ESB企業服務總線
• 微服務強調每一個微服務都有本身獨立的運行空間，包括數據庫資源。
• 微服務架構自己來源於互聯網的思路，所以組件對外發布的服務強調了採用HTTP Rest API的方式來進行
• 微服務的切分粒度會更小

總結:微服務架構是 SOA 架構思想的一種擴展，更增強調服務個體的獨立性、拆分粒度更小。 

爲何考慮Spring Cloud 

• Spring Cloud來源於Spring，質量、穩定性、持續性均可以獲得保證
• Spirng Cloud自然支持Spring Boot，更加便於業務落地。
• Spring Cloud發展很是的快，從16年開始接觸的時候相關組件版本爲1.x，到如今將要發佈2.x系列
• Spring Cloud是Java領域最適合作微服務的框架。
• 相比於其它框架,Spring Cloud對微服務周邊環境的支持力度最大。
• 對於中小企業來說，使用門檻較低。

Spring Cloud　是微服務架構的最佳落地方案 

它的特性 

如下爲Spring Cloud的核心特性： 

• 分佈式/版本化配置
• 服務註冊和發現
• 路由
• 服務和服務之間的調用
• 負載均衡
• 斷路器
• 分佈式消息傳遞

這些特性都是由不一樣的組件來完成，在架構的演進過程當中扮演着重要的角色，接下來咱們一塊兒看看。 

微服務架構 

Spring Cloud解決的第一個問題就是：服務與服務之間的解耦。不少公司在業務高速發展的時候，服務組件也會相應的不斷增長。服務和服務之間有着複雜的相互調用關係，常常有服務A調用服務B，服務B調用服務C和服務D ...，隨着服務化組件的不斷增多，服務之間的調用關係成指數級別的增加，極端狀況下就以下圖所示： 

這樣最容易致使的狀況就是牽一髮而動全身。常常出現因爲某個服務更新而沒有通知到其它服務，致使上線後慘案頻發。這時候就應該進行服務治理，將服務之間的直接依賴轉化爲服務對服務中心的依賴。Spring Cloud 核心組件Eureka就是解決這類問題。 

Eureka 

Eureka是Netflix開源的一款提供服務註冊和發現的產品，它提供了完整的Service Registry和Service Discovery實現。也是Spring Cloud體系中最重要最核心的組件之一。 

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

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

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

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. 監控的效果圖以下： 

配置中心 

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

Spring Cloud Config 

Spring Cloud Config是一個解決分佈式系統的配置管理方案。它包含了Client和Server兩個部分，Server提供配置文件的存儲、以接口的形式將配置文件的內容提供出去，Client經過接口獲取數據、並依據此數據初始化本身的應用。 

其實就是Server端將全部的配置文件服務化，須要配置文件的服務實例去Config Server獲取對應的數據。將全部的配置文件統一整理，避免了配置文件碎片化。 

若是服務運行期間改變配置文件，服務是不會獲得最新的配置信息，須要解決這個問題就須要引入Refresh。能夠在服務的運行期間從新加載配置文件。 

當全部的配置文件都存儲在配置中心的時候，配置中心就成爲了一個很是重要的組件。若是配置中心出現問題將會致使災難性的後果，所以在生產中建議對配置中心作集羣，來支持配置中心高可用性。 

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能夠很清楚的瞭解到一個服務請求通過了哪些服務，每一個服務處理花費了多長時間。從而讓咱們能夠很方便的理清各微服務間的調用關係。 

Zipkin是Twitter的一個開源項目，容許開發者收集 Twitter 各個服務上的監控數據，並提供查詢接口 

總結 

咱們從總體上來看一下Spring Cloud各個組件如何來配套使用： 

從上圖能夠看出Spring Cloud各個組件相互配合，合做支持了一套完整的微服務架構。 

• 其中Eureka負責服務的註冊與發現，很好將各服務鏈接起來
• Hystrix 負責監控服務之間的調用狀況，連續屢次失敗進行熔斷保護。
• Hystrix dashboard,Turbine 負責監控 Hystrix的熔斷狀況，並給予圖形化的展現
• Spring Cloud Config 提供了統一的配置中心服務
• 當配置文件發生變化的時候，Spring Cloud Bus 負責通知各服務去獲取最新的配置信息
• 全部對外的請求和服務，咱們都經過Zuul來進行轉發，起到API網關的做用
• 最後咱們使用Sleuth+Zipkin將全部的請求數據記錄下來，方便咱們進行後續分析

Spring Cloud從設計之初就考慮了絕大多數互聯網公司架構演化所需的功能，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等。這些功能都是以插拔的形式提供出來，方便咱們系統架構演進的過程當中，能夠合理的選擇須要的組件進行集成，從而在架構演進的過程當中會更加平滑、順利。  微服務架構是一種趨勢，Spring Cloud提供了標準化的、全站式的技術方案，意義可能會堪比當前Servlet規範的誕生，有效推動服務端軟件系統技術水平的進步。