Spring Cloud 微服務的那點事

在詳細的瞭解SpringCloud中所使用的各個組件以前，咱們先了解下微服務框架的前世此生。

單體架構

在網站開發的前期，項目面臨的流量相對較少，單一應用能夠實現咱們所須要的功能，從而減小開發、部署和維護的難度。這種用於簡單的增刪改查的數據訪問框架（ORM）十分的重要。

垂直應用架構

當用戶訪問量不斷的提高，單一應用須要不斷的增長服務器來應對，同時將單一的應用拆分紅多個應用用來處理提高效率。這種用於加速Web前端加載的Web框架（MVC）起到了關鍵性的做用。

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

在這一階段咱們最常使用到的開發框架就是Spring（業務邏輯層管理POJO）+Struts（web層前置服務控制）+Hibernate（數據庫層持久化）。

服務化架構

伴隨着企業服務量的不斷提高，MVC框架的部署致使系統的負重愈來愈多，沒法知足併發的要求，系統間數據、報文的傳輸會出現頻繁的丟失。這時候咱們須要考慮服務化的架構（SOA）。SOA表示面向服務的架構。將應用根據不一樣的職責劃分紅不一樣的模塊（相似於企業劃分不一樣的事業部），不一樣的模塊使用特定的調用協議（RPC）和接口進行交互。

這樣使整個系統切分紅不少單個組件服務來完成請求，當流量過大時經過水平擴展相應的組件來支撐，全部的組件經過交互來知足總體的業務需求。

SOA服務化的優勢是，它能夠根據需求經過網絡對鬆散耦合的粗粒度應用組件進行分佈式部署、組合和使用。

服務層是SOA的基礎，能夠直接被應用調用，從而有效控制系統中與軟件代理交互的人爲依賴性。

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

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

微服務架構

微服務架構算是SOA架構的一種拓展，主要關注的是服務個體的獨立性、拆分粒度更小。相對於SOA架構來講，微服務擁有如下優點：

微服務強調更深層次的組件化和服務化，每一個微服務均可以擁有獨立的運行空間，確保每個服務組件能夠做爲單獨的產品進行發佈。

微服務拋棄了傳統SOA笨重的企業服務總線，對外發布強調使用HTTP REST API的接口發佈形式。

微服務的切分粒度大。

瞭解了架構的發展過程，咱們來認識一下Spring Cloud。

Spring Cloud來源於Spring，利用Spring Boot進行快捷開發。因爲目前Spring Cloud社區的維護和支持的人員數量衆多，相信Spring Cloud會有很好的發展。並且Spring Cloud基本上都是使用了現有的開源框架進行的集成，學習的難度和部署的門檻就比較低，對於中小型企業來講，更易於使用和落地。

Spring Cloud主要解決了什麼問題？

一、對於企業級的SOA框架來講，服務與服務間的解耦是一項巨大的難題，隨着功能服務的不斷增長，多服務間的相互調用頻繁，調用過程就像一個雜亂無章的毛線球，很容易致使牽一髮而動全身的狀況，常常會因爲在服務更新的過程當中，沒有合理通訊，致使數據的丟失。

這時候就應該進行服務治理，將服務之間的直接依賴轉化爲服務對服務中心的依賴。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。

監控的效果圖以下：

想了解具體都監控了哪些指標，以及如何監控能夠參考這篇文章：熔斷監控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規範的誕生，有效推動服務端軟件系統技術水平的進步。

歡迎工做一到五年的Java工程師朋友們加入Java架構開發：697579751

羣內提供免費的Java架構學習資料（裏面有高可用、高併發、高性能及分佈式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用本身每一分每一秒的時間來學習提高本身，不要再用"沒有時間「來掩飾本身思想上的懶惰！趁年輕，使勁拼，給將來的本身一個交代！