springCloud的瞭解（二）

更新時間：2019年7月18日
複製代碼

前言

今天的話，咱們將繼續來學習springCloud。springCloud的組件是極其多的，而其中最爲出色的廠家則是NetFlix，能夠說這個廠家幾乎包攬了springCloud中最爲重要的一些服務，例如：服務發現——Netflix Eureka，客服端負載均衡——Netflix Ribbon，斷路器——Netflix Hystrix，服務網關——Netflix Zuul。所以也是這個廠商，在去年宣佈了再也不更新了Eureka和Hystrix，這其實對於springCloud的生態形成了巨大變化。

固然，即使如此，咱們在實際的生產過程當中，仍是在使用NetFlix的大部分組件，由於這些組件即使再也不更新了，可是在最近這幾年，我相信市場仍是NetFlix的，由於他們作的組件確實是成熟的，也是符合市場要求的。

所以，咱們今天的主題是springCloud的組件，這固然也就包括了NetFlix廠家的組件。

Let's go party!!!

ps：你們快去看《樂隊的夏天》這個綜藝節目，裏面的刺蝟樂隊的主唱子健，聽說是程序員裏面最會唱歌的(￣▽￣)~*。

springCloud的組件以及分析

在開始瞭解springCloud的組件以前，咱們必須先要了解一下微服務究竟是個什麼東西，畢竟咱們的springCloud的基調是springboot，而springboot就是微服務。

一 .微服務

微服務就是把一個項目拆分爲多個項目， 項目之間進行獨立運行。經過Http或者Socket來進行通訊處理數據和調用。這些小的Web服務能夠獨立地編譯及部署，並經過各自暴露的API接口相互通信。它們彼此相互協做，做爲一個總體爲用戶提供功能，卻能夠獨立地進行擴充。

所以衍生出的是微服務的編程思惟：http restful。

確定有人問爲何不使用RPC來編程，RPC的高效低延遲這個性能指標相信是不少微服務求之不得的，若是一個請求所須要的服務是3個以上而且各個服務業務邏輯複雜，甚至涉及衆多IO操做，那是否是RPC的方式更爲保障？

這個問題，咱們留到後面再去詳細瞭解，今天咱們仍是先進入正題。

二. 微服務組件的使用場景

1：咱們把整個系統根據業務拆分紅幾個子系統。
 2：每一個子系統能夠部署多個應用，多個應用之間使用負載均衡（Netflix Ribbon）。
 3：須要一個服務註冊中心，全部的服務都在註冊中心註冊，負載均衡也是經過在註冊中
    心註冊的服務來使用必定策略來實現（Netflix Eureka）。
 4：全部的客戶端都經過同一個網關地址訪問後臺的服務，經過路由配置，網關來判斷一
    個URL請求由哪一個服務處理。請求轉發到服務上的時候也使用負載均衡（Netflix Zuul）。
 5：服務之間有時候也須要相互訪問。例若有一個用戶模塊，其餘服務在處理一些業務的
    時候，要獲取用戶服務的用戶數據（Feign，本質上就是Ribbon+Hystrix，用註解的
    方式進行服務調用，代碼更好看了）。
 6：須要一個斷路器，及時處理服務調用時的超時和錯誤，防止因爲其中一個服務的問題
    而致使總體系統的癱瘓（Netflix Hystrix）。
 7：還須要一個監控功能，監控每一個服務調用花費的時間等（Turbin）。
 8：也須要一個配置中心，支持本地倉庫、SVN、Git、Jar包內配置等模式，相似規章制
    度，每一個人都從這裏獲取規定配置。（Config）
複製代碼

springCloud的組件太多，可是在實際的開發中，咱們使用的組件，可能沒有這麼多，所以在實際的開發中，咱們不須要一次性所有學會，只須要關注比較重要的幾個就好了。固然，今天咱們仍是嘗試着蜻蜓點水的將全部的組件瞭解一遍。

三. srpingCloud的組件解析

接下來咱們開始瞭解springCloud組件，請戴上你的耳機，我推薦一首歌，最近很喜歡的一首歌《say it again》，是國內的一個樂隊「盤尼西林」的歌，也參加了《樂隊的夏天》這個綜藝。哈哈哈哈ヾ(๑╹◡╹)ﾉ"，沒錯，我就是傳說中的自來水粉絲。

接下來，我會按照重要程度降序，來一一解析springCloud的部分重要組件。

1. Netflix Eureka——服務發現

毫無疑問，Eureka是springCloud的組件中的重要程度是要排第一的。

咱們須要分別下載 Eureka 官方源碼和 Spring Cloud Netflix 適配 Eureka 的代碼。

原生 Eureka 代碼： github.com/Netflix/eur…

Spring Cloud針對於Eureka的Spring Cloud適配：github.com/spring-clou…

ps: 沒有下載git的朋友請下載git，用來在github上下載源代碼。

服務發現（Eureka）是NetFlix旗下的核心組件之一，它負責服務註冊，管理服務列表。全部的微服務都須要在Eureka上面進行註冊登記，各個服務之間不須要之間對方的ip和端口，都是經過服務發現中心來進行互相調用API（一個在註冊中心註冊的REST服務），這固然會出現額外的開支--這個開支也就是全部客戶機必須實現某種邏輯來與這個中心點進行交互，這樣在實現服務請求以前將增長一次額外的網絡往返。

springCloud使用Eureka來進行服務發現，在微服務註冊到Eureka的時候，它必須向Eureka發送心跳信息，以此Eureka會判斷這個微服務是否在線上。

若是你相同的微服務你開了多個服務端，那麼在Eureka也會在註冊發現中心顯現出來功能相同的微服務的不一樣的服務端，那麼也是依賴Eureka來進行相似nginx分發服務的負載均衡的功能。

到了這裏，咱們發如今以前的學習過程當中，咱們仍是不夠了解springboot。由於springboot實際上的開發解耦就是將後端和前端直接分離開了，不是說使用springboot或者springCloud不能進行先後端一體開發，而是springCloud乃至springboot的自己就是爲了先後端分離而誕生的。（在springCloud中，後端接口的API都是註冊到了Eureka中的，實際開發中，前端開發工做人員甚至能夠直接在Eureka中直接查找須要的接口API。）

總結：

1. 是純正的 servlet 應用，需構建成war包部署 
2. 使用了 Jersey 框架實現自身的 RESTful HTTP接口 
3. peer之間的同步與服務的註冊所有經過 HTTP 協議實現 
4. 定時任務(發送心跳、定時清理過時服務、節點同步等)經過 JDK 自帶的 Timer 實現 
5. 內存緩存使用Google的guava包實現
複製代碼

其實不須要問爲何使用的是HTTP協議，看看市面上有什麼不支持HTTP的麼？這其實就是爲何要使用HTTP的緣由之一。

2. Netflix Ribbon——客服端負載均衡

Ribbon是Netflix發佈的開源項目，主要功能是提供客戶端的軟件負載均衡算法，將Netflix的中間層服務鏈接在一塊兒。

咱們在配置文件中列出負載均衡全部的機器，Ribbon會自動的幫助咱們基於某種規則（如簡單輪詢、隨機鏈接等等）去鏈接這些機器。

Ribbon客戶端組件提供了一列完善的配置項（如鏈接超時、重試等等），咱們也能很容易的使用Ribbon實現自定義的負載均衡算法。

Ribbon和Eureka整合後服務消費方能夠直接調用服務而不用再關心提供服務的地址以及提供服務的端口號。

Ribbon其實就是一個軟負載均衡的客戶端軟件，它能夠和其它所需請求的客戶端結合使用，和Eureka結合只是其中的一個實例。

接下來貼出一些最基本的配置項：

RoundRobinRule：輪詢
 RandomRule：隨機
 AvailabilityFilteringRule：會先過濾掉因爲屢次訪問故障而處於斷路器跳閘狀態和並
                            發的鏈接數量超過閾值的服務，而後對剩餘的服務列表按
                            照輪詢策略進行訪問。
 WeightedResponseTimeRule：根據平均響應時間計算全部服務的權重，響應時間越快服
                           務權重越大被選中的機率越高。
 RetryRule：先按照RoundRobinRule的策略獲取服務，若是獲取服務失敗，則在指定時間
            內會進行重試，獲取可用的服務。
 BestAvailableRule：會過濾掉因爲屢次訪問故障而處於斷路器跳閘狀態的服務，而後選
                    擇一個併發量最小的服務。
 ZoneAvoidanceRule：默認規則，複合判斷Server所在區域的性能和Server的可用性選擇服
                    務器。
複製代碼

若是須要修改的話也很簡單，我在網絡上找到了一些方法，如今貼出一個來：

固然，我如今也只是大概瞭解了一下，由於在實際開發中，頗有多是須要配置本身自定義的規則，那麼修改方法可能不同了，具體狀況你們感興趣的話能夠在網絡上自行百度。

3. Netflix Zuul——服務網關

在下才疏學淺，不少的東西都解釋很差，所以只能厚顏從網絡上搬來一部分資料。剛剛在網絡上的一個博客看到一個大神解釋的關於Eureka和Ribbon的解釋圖，給你們看看。

其實在以前的Eureka的解析中，我多多少少有解釋過，先後端分離的解耦，最重要的緣由是開發人員能夠直接調用接口API。

可是在實際開發中，咱們在每個服務接口上面都會加上一些權限校驗，那麼在這裏，若是咱們在每一次調用服務接口的時候都進行權限校驗，那麼咱們必須在每一次調用服務接口的時候必須加上權限校驗的代碼，這很明顯的增長了咱們的工做量。

並且若是微服務數量多了，那麼一些接口的調用規則，服務列表的維護工做也會變得十分的麻煩，甚至須要公司在開發以前都要作好接口的規則肯定。

因而，API網關（路由網關）應運而生。

在沒有網關以前，客戶端服務包括兩個步驟：

1.從EurekaServer獲取一個客戶端服務的全部地址
2.經過Ribbon負載均衡選擇一個機器進行訪問
複製代碼

引入網關以後，客戶端經過 「http://gateway/服務ID/url」 URL格式調用網關，網關執行包括兩個步驟：

1.使用服務ID查找客戶端服務
2.使用Netflix Ribbon對調用服務進行負載均衡。
複製代碼

路徑解釋：

gateway:網關服務在Eureka註冊的服務ID
服務ID:客戶端服務在Eureka註冊的服務ID
url:訪問客戶端服務的url。
複製代碼

在上一個圖片的基礎上，咱們貼出有了路由網關的圖：

咱們看到，整個系統的入口就是zuul，當咱們有參數校驗的需求時，咱們就能夠利用Zuul的Pre過濾器，進行參數的校驗。例如我如今但願請求都一概帶上token參數，不然拒絕請求。固然，在這個圖中，沒有加入Pre過濾器。

這就是zuul的兩大功能：過濾（權限控制）和路由轉發。

4. Netflix Hystrix——斷路器

Hystrix的中文翻譯是豪豬，也就是身上長滿了刺的豬。它的主要功能是-自我保護。Hystrix具備服務降級，熔斷，線程池隔離，信號量隔離，緩存等功能，基本上能覆蓋到微服務中調用依賴服務會遇到的問題。

爲了保證其高可用，單個服務一般會集羣部署。因爲網絡緣由或者自身的緣由，服務並不能保
證100%可用，若是單個服務出現問題，調用這個服務就會出現線程阻塞，此時如有大量的請求
涌入，Servlet容器的線程資源會被消耗完畢，致使服務癱瘓。服務與服務之間的依賴性，故
障會傳播，會對整個微服務系統形成災難性的嚴重後果，這就是服務故障的「雪崩」效應。
複製代碼

當執行調用服務方法時，若調用方法出現問題，如：請求超時，拋出異常，線程池拒絕，熔斷這些狀況下，爲該方法定義降級方法，以便在出現問題時執行，實現備用返回。以前咱們已經實現了服務降級功能，主要就是經過@HystrixCommand(fallbackMethod = "defaultMethod")註釋到須要在出現問題時降級的方法。

fallbackMethod指定降級後執行的方法。方法定義在該類中，public，private，protected均可以。在註釋的方法出問題後，如超時未返回(execution.isolation.thread.timeoutinMilliseconds來配置)，就會執行備用方法，返回備用方法的返回值。固然，降級的方法也能夠定義再下一級的降級方法，實現和上面同樣。

上面說到方法拋出異常也會觸發服務降級，可是若是咱們自定義了異常，並須要將異常拋出給上層作操做，不但願Hystrix捕捉到自定義異常執行服務降級時，可使用@HystrixCommand(ignoreExceptions ={MyException.class})來定義忽略捕捉的異常。多個異經常使用逗號隔開。也能夠將拋出的異常經過入參傳到降級的方法，來實現不一樣類型異常的不一樣處理。

小結

到了這裏，我相信你們對springCloud有了一個總體的大概的瞭解，固然，實際狀況中，springCloud的複雜程度是超出當前個人講述的。明天，咱們將繼續來了解springCloud。