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內容有一個心跳檢測機制，如果某個實例在規定的時間內沒有進行通訊則會自動被剔除掉，避免了某個實例掛掉而影響服務。

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 各個服務上的監控數據，並提供查詢介面

分散式鏈路跟蹤需要Sleuth+Zipkin結合來實現。

總結

我們從整體上來看一下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規範的誕生，有效推進服務端軟體系統技術水平的進步。