我把 Spring Cloud 給拆了!帶你詳細瞭解各組件原理!

我們先認識一下SpringCloud的各個組件,然後知其所以然。

原理講解前,先看一個最經典的業務場景,如開發一個電商網站,要實現支付訂單的功能,流程如下:

  1. 創建一個訂單之後,如果用戶立刻支付了這個訂單,我們需要將訂單狀態更新爲“已支付”
  2. 扣減相應的商品庫存
  3. 通知倉儲中心,進行發貨
  4. 給用戶的這次購物增加相應的積分

如上,微服務的應用場景和核心競爭力:

  • 降低耦合:每一個微服務專注於單一功能,並通過定義良好的接口清晰表述服務邊界。由於體積小、複雜度低,每個微服務可由一個小規模開發團隊完全掌控,易於保持高可維護性和開發效率。
  • 獨立部署:由於微服務具備獨立的運行進程,所以每個微服務也可以獨立部署。當某個微服務發生變更時無需編譯、部署整個應用。由微服務組成的應用相當於具備一系列可並行的發佈流程,使得發佈更加高效,同時降低對生產環境所造成的風險,最終縮短應用交付週期。
  • 選型靈活:微服務架構下,技術選型是去中心化的。每個團隊可以根據自身服務的需求和行業發展的現狀,自由選擇最適合的技術棧。由於每個微服務相對簡單,故需要對技術棧進行升級時所面臨的風險就較低,甚至完全重構一個微服務也是可行的。
  • 容錯機制:當某一組建發生故障時,在單一進程的傳統架構下,故障很有可能在進程內擴散,形成應用全局性的不可用。在微服務架構下,故障會被隔離在單個服務中。若設計良好,其他服務可通過重試、平穩退化等機制實現應用層面的容錯。
  • 靈活擴展:單塊架構應用也可以實現橫向擴展,就是將整個應用完整的複製到不同的節點。當應用的不同組件在擴展需求上存在差異時,微服務架構便體現出其靈活性,因爲每個服務可以根據實際需求獨立進行擴展。

Dubbo對標Spring Cloud微服務

  • 背景分析:Dubbo,是阿里巴巴服務化治理的核心框架,並被廣泛應用於中國各互聯網公司;Spring Cloud是知名的Spring家族的產品。阿里巴巴是一個商業公司,雖然也開源了很多的頂級的項目,但從整體戰略上來講,仍然是服務於自身的業務爲主。Spring專注於企業級開源框架的研發,不論是在中國還是在世界上使用都非常廣泛,開發出通用、開源、穩健的開源框架就是他們的主業。
  • 活躍度對比:Dubbo是一個非常優秀的服務治理框架,並且在服務治理、灰度發佈、流量分發這方面做的比Spring Cloud還好,除過當當網在基礎上增加了rest支持外,已有兩年多的時間幾乎都沒有任何更新了。在使用過程中出現問題,提交到GitHub的Issue也少有回覆。相反Spring Cloud自從發展到現在,仍然在不斷的高速發展,從GitHub上提交代碼的頻度和發佈版本的時間間隔就可以看出,現在Spring Cloud即將發佈2.0版本,到了後期會更加完善和穩定。
  • 平臺架構:Dubbo框架只是專注於服務之間的治理,如果我們需要使用配置中心、分佈式跟蹤這些內容都需要自己去集成,這樣無形中使用Dubbo的難度就會增加。Spring Cloud幾乎考慮了服務治理的方方面面,更有Spring Boot這個大將的支持,開發起來非常的便利和簡單。
  • 技術前景:Dubbo在各中小公司也從中受益不少。經過了這麼多年的發展,互聯網行業也是湧現了更多先進的技術和理念,Dubbo有點可惜。Spring 推出Spring Boot/Cloud也是因爲自身的很多原因。Spring最初推崇的輕量級框架,隨着不斷的發展也越來越龐大,隨着集成項目越來越多,配置文件也越來越混亂,慢慢的背離最初的理念。隨着這麼多年的發展,微服務、分佈式鏈路跟蹤等更多新的技術理念的出現,Spring急需一款框架來改善以前的開發模式,因此纔會出現Spring Boot/Cloud項目,我們現在訪問Spring官網,會發現Spring Boot和Spring Cloud已經放到首頁最重點突出的三個項目中的前兩個,可見Spring對這兩個框架的重視程度。Dubbo實現如下:

Spring Cloud實現思路

Eureka

原理:主管服務註冊與發現,也就是微服務的名稱註冊到Eureka,就可以通過Eureka找到微服務,而不需要修改服務調用的配置文件。

分析:Spring Cloud封裝了Netflix公司開發的Eureka模塊來實現服務的註冊與發現,採用的c-s的設計架構,Eureka Server作爲服務註冊功能的服務器,他是服務註冊中心。而系統的其他微服務,使用Eureka的客戶端連接到Eureka Server並維持心跳。這樣系統的維護人員可以通過Eureka Server來監控系統中的各個微服務是否正常運行。Spring Cloud的一些其他模塊(比如Zuul)就可以通過Eureka Server來發現系統其他的微服務,並執行相關邏輯。

Eureka Server

Eureka Server提供服務註冊服務,各個節點啓動後,會在Eureka Server中進行註冊, 這樣Eureka Server中的服務註冊表中將會存儲所有可用服務節點的信息,服務節點的信息可以在界面中直觀的看到。

Eureka Client

Eureka Client是一個Java客戶端, 用於簡化Eureka Server的交互,客戶端同時也具備一個內置的、 使用輪詢(round-robin)負載算法的負載均衡器。在應用啓動後,將會向Eureka Server發送心跳(默認週期爲30秒),以證明當前服務是可用狀態。如果Eureka Server在一定的時間(默認90秒)未收到客戶端的心跳,Eureka Server將會從服務註冊表中把這個服務節點移除。

Eureka Server的自我保護機制

如果在15分鐘內超過85%的節點都沒有正常的心跳,那麼Eureka就認爲客戶端與註冊中心出現了網絡故障,此時會出現以下幾種情況:

  • Eureka不再從註冊列表中移除因爲長時間沒收到心跳而應該過期的服務
  • Eureka仍然能夠接受新服務的註冊和查詢請求,但是不會被同步到其它節點上(即保證當前節點依然可用)
  • 當網絡穩定時,當前實例新的註冊信息會被同步到其它節點中

因此, Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況,而不會像ZooKeeper那樣使整個註冊服務癱瘓。

Eureka和ZooKeeper

著名的CAP理論指出,一個分佈式系統不可能同時滿足C(一致性)、A(可用性)和P(分區容錯性)。由於分區容錯性在是分佈式系統中必須要保證的,因此我們只能在A和C之間進行權衡。

ZooKeeper保證CP

當向註冊中心查詢服務列表時,我們可以容忍註冊中心返回的是幾分鐘以前的註冊信息,但不能接受服務直接down掉不可用。也就是說,服務註冊功能對可用性的要求要高於一致性。但是ZooKeeper會出現這樣一種情況,當Master節點因爲網絡故障與其他節點失去聯繫時,剩餘節點會重新進行leader選舉。問題在於,選舉leader的時間太長,30 ~ 120s,且選舉期間整個ZooKeeper集羣都是不可用的,這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下,因網絡問題使得ZooKeeper集羣失去Master節點是較大概率會發生的事,雖然服務能夠最終恢復,但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。

Eureka保證AP

Eurek在設計時就優先保證可用性。Eureka各個節點都是平等的,幾個節點掛掉不會影響正常節點的工作,剩餘的節點依然可以提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊或時如果發現連接失敗,則會自動切換至其它節點,只要有一臺Eureka還在,就能保證註冊服務可用(保證可用性),只不過查到的信息可能不是最新的(不保證強一致性)。

除此之外,Eureka還有一種自我保護機制,見上。

總結

Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況,而不會像ZooKeeper那樣使整個註冊服務癱瘓。

Eureka作爲單純的服務註冊中心來說要比ZooKeeper更加“專業”,因爲註冊服務更重要的是可用性,我們可以接受短期內達不到一致性的狀況。

Ribbon和Feign

在微服務架構中,業務都會被拆分成一個獨立的服務,服務與服務的通訊是基於HTTP RESTful的。Spring Cloud有兩種服務調用方式,一種是Ribbon+RestTemplate,另一種是Feign。

概念

基於Netflix Ribbon用過輪詢策略實現的一套客戶端負載均衡的工具。

客戶端負載均衡:負載均衡Zuul網關將一個請求發送給某一個服務的應用的時候,如果一個服務啓動了多個實例,就會通過Ribbon來通過一定的負載均衡策略來發送給某一一個服務實例。Spring Cloud中的Ribbon,客戶端會有一個服務器地址列表,在發送請求前通過負載均衡算法(如簡單輪詢,隨機連接等)選擇一個服務器,然後進行訪問。

負載均衡

  • 負載均衡:用於將工作負載分佈到多個服務器來提高網站、應用、數據庫或其他服務的性能和可靠性。
  • 使用負載均衡帶來的好處很明顯:當集羣裏的1臺或者多臺服務器down的時候,剩餘的沒有down的服務器可以保證服務的繼續使用;將訪問壓力分配到各個服務器,不會由於某一高峯時刻導致系統cpu急劇上升。
  • 負載均衡有好幾種實現策略,常見的有:隨機(Random),輪詢(RoundRobin),一致性哈希(ConsistentHash),哈希(Hash),加權(Weighted)
  • Ribbon的默認策略是輪詢

RestTemplate

傳統情況下在Java代碼裏訪問RESTful服務,一般使用Apache的HttpClient,不過此種方法使用起來太過繁瑣。Spring提供了一種簡單便捷的模板類來進行操作,這就是RestTemplate。

Feign是一個聲明式http客戶端。使用Feign能讓編寫http客戶端更加簡單,它的使用方法是定義一個接口,然後在上面添加註解,避免了調用目標微服務時,需要不斷的解析/封裝json數據的繁瑣。Spring Cloud中Feign默認集成了Ribbon,並和Eureka結合,默認實現了負載均衡的效果。

Ribbon和Feign的區別

Feign目標****使****編寫Java Http客戶端變得更容易

在使用Ribbon+ RestTemplate時,Ribbon需要自己構建http請求,模擬http請求然後使用RestTemplate發送給其他服務,步驟相當繁瑣。利用RestTemplate對http請求的封裝處理,形成了-套模版化的調用方法。但是在實際開發中,由於對服務依賴的調用可能不止一處,往往一個接口會被多處調用,所以通常都會針對每個微服務自行封裝一些客戶端類來包裝這些依賴服務的調用。所以,Feign在此基礎上做了進一步封裝,由他來幫助我們定義和實現依賴服務接口的定義。

在Feign的實現下,我們只需創建一個接口並使用註解的方式來配置它(以前是Dao接口上面標註Mapper註解,現在是一個微服務接口上面標註一個Feign註解即可), 即可完成對服務提供方的接口綁定,簡化了使用Spring Cloud Ribbon時,自動封裝服務調用客戶端的開發量。

Feign集成了Ribbon

Ribbon通過輪詢實現了客戶端的負載均衡,而與Ribbon不同的是,Feign是一個聲明式的Web服務客戶端, 使得編寫Web服務客戶端變得非常容易,只需要創建一個接口, 然後在上面添加註解,像調用本地方法一樣調用它就可以,而感覺不到是調用遠程方法。SpringCloud中Feign默認集成了Ribbon,並和Eureka結合,默認實現了負載均衡的效果。

Ribbon和Nginx的區別

服務器端負載均衡Nginx

Nginx是客戶端所有請求統一交給Nginx,由Nginx進行實現負載均衡請求轉發,屬於服務器端負載均衡。既請求由Nginx服務器端進行轉發。客戶端負載均衡Ribbon,Ribbon是從Eureka註冊中心服務器端上獲取服務註冊信息列表,緩存到本地,然後在本地實現輪詢負載均衡策略。既在客戶端實現負載均衡。

應用場景的區別

Nginx適合於服務器端實現負載均衡,比如:Tomcat,Ribbon適合與在微服務中RPC遠程調用實現本地服務負載均衡,比如:Dubbo、Spring Cloud中都是採用本地負載均衡。

Zuul

應用場景

假如當前有十幾個微服務服務,訂單,商品,用戶等等,顯然是客戶端不需要和每個服務逐一打交道,這就需要有一個統一入口,它就是服務網關。API網關所有的客戶端請求通過這個網關訪問後臺的服務。他可以使用一定的路由配置來判斷某一個URL由哪個服務來處理。並從Eureka獲取註冊的服務來轉發請求。

核心功能

Zuul包含了對請求的路由和過濾兩個最主要的功能,是各種服務的統一入口,同時還會用來提供監控、授權、安全、調度等等。

路由功能:負責將外部請求轉發到具體的微服務實例上,是實現外部訪問統一入口的基礎。

過濾器功能:則負責對請求的處理過程進行干預,是實現請求校驗、服務聚合等功能的基礎。

Zuul和Eureka進行整合:將Zuul自身註冊爲Eureka服務治理下的應用,同時從Eureka中獲得其他微服務的消息,也即以後的訪問微服務都是通過Zuul跳轉後獲得。

注意:Zuul服務最終還是會註冊進Eureka,提供代理+路由+過濾三大功能。

核心原理

Zuul的核心是一系列的filters,其作用可以類比Servlet框架的Filter,或者AOP。

過濾器之間沒有直接進行通信,而是通過Request Context(上下文)進行數據傳遞。

Zuul的過濾器是由Groovy寫成,這些過濾器文件被放在Zuul Server上的特定目錄下面,Zuul會定期輪詢這些目錄,修改過的過濾器會動態的加載到Zuul Server中以便過濾請求使用。

Zuul負載均衡:Zuul攔截對應的API前綴請求做轉發,轉發到對應的serverId上,在Eureka服務上同一個serverId可以對應多個服務,也就是說用同一個服務節點不同的端口註冊兩個實例,但是serverId是一樣Zuul做轉發的時候會結合eureka-server起到負載均衡的效果。

過濾器的種類:

  • PRE(前置):這種過濾器在請求被路由之前調用。我們可利用這種過濾器實現鑑權、限流、參數校驗調整等。
  • ROUTING(路由):這種過濾器將請求路由到微服務。這種過濾器用於構建發送給微服務的請求,並使用Apache HttpClient或Netfilx Ribbon請求微服務。
  • POST(後置):這種過濾器在路由到微服務以後執行。這種過濾器可用來爲響應添加標準的HTTP Header、收集統計信息和指標、將響應從微服務發送給客戶端、日誌等。
  • ERROR(錯誤):在其他階段發生錯誤時執行該過濾器。

Zuul和Nginx

Zuul雖然在性能上和Nginx沒法比,但它也有它的優點。Zuul提供了認證鑑權,動態路由,監控,彈性,安全,負載均衡等邊緣服務,在團隊規模不大的情況下,沒有專門負責路由開發時,使用Zuul當網關是一個快速上手的好方案。

Nginx和Zuul是可以配合使用的,發揮各自的優點,使用Nginx作爲負載均衡實現高併發的請求轉發,Zuul用作網關。

Zuul和Ribbon實現負載均衡

Zuul支持Ribbon和Hystrix,也能夠實現客戶端的負載均衡。我們的Feign不也是實現客戶端的負載均衡和Hystrix的嗎?既然Zuul已經能夠實現了,那我們的Feign還有必要嗎?

可以這樣理解:

Zuul是對外暴露的唯一接口相當於路由的是controller的請求,而Ribbonhe和Fegin路由了service的請求。

Zuul做最外層請求的負載均衡,而Ribbon和Fegin做的是系統內部各個微服務的service的調用的負載均衡。

Hystrix

介紹

Hystrix是一個用於處理分佈式系統的延遲和容錯的開源庫,在分佈式系統裏,許多依賴不可避兔的會調用失敗,比如超時、異常等,Hystrix能夠保證在一個依賴出問題的情況下,不會導致整體服務失敗,避免級聯故障,以提高分佈式系統的彈性。Hystrix的出現就是爲了解決雪崩效應。

服務雪崩

多個微服務之間調用的時候,假設微服務A調用微服務B和微服務C,微服務B和微服務C又調用其它的微服務,這就是所謂的“扇出”。如果扇出的鏈路上某個微服務的調用響應時間過長或者不可用,對微服務A的調用就會佔用越來越多的系統資源,進而引起系統崩潰,所謂的”雪崩效應”。

服務熔斷

熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。

當刪除鏈路的某個微服務不可用或者響應時間太長時,會進行服務的降級,進而熔斷該節點微服務的調用,快速返回”錯誤的響應信息。當檢測到該節點微服務調用響應正常後恢復調用鏈路。在SpringCloud框架裏熔斷機制通過Hystrix實現。Hystrix會監控微服務間調用的狀況,當失敗的調用到一定閾值,缺省是5秒內20次調用失敗就會啓動熔斷機制。熔斷機制的註解是@HystrixCommand。

服務降級

整體資源快不夠了,忍痛將某些服務先關掉,待渡過難關,再開啓回來。

Hystrix監控和斷路器

我們只需要在服務接口上添加Hystrix標籤,就可以實現對這個接口的監控和斷路器功能。

Hystrix Dashboard監控面板,提供了一個界面,可以監控各個服務上的服務調用所消耗的時間等。

Hystrix Turbine監控聚合

使用Hystrix監控,我們需要打開每一個服務實例的監控信息來查看。而Turbine可以幫助我們把所有的服務實例的監控信息聚合到一個地方統查看。這樣就不需要挨個打開一個個的頁面一個個查看。

Zuul的安全機制

簽名機制,爲防止接口數據篡改和重複調用,增加接口參數校驗機制,sig簽名算法爲MD5(appKey+appSecret+timestamp),appKey是分配給客戶端的ID,appSecret是分配給客戶端的密鑰,timestamp爲unix時間戳,請求的URL有效時間爲15分鐘。

Token機制,用戶在登錄之後會返回一個access_ token,客戶端在訪問需要登錄之後才能訪問的資源,需要在在Authorization頭部使用Bearer模式新增token,如head(“Authorization”,” Bearer token”)。

Hystrix的設計原則

  • 資源隔離(線程池隔離和信號量隔離)機制:限制調用分佈式服務的資源使用,某一個調用的服務出現問題不會影響其它服務調用。
  • 限流機制:限流機制主要是提前對各個類型的請求設置最高的QPS閾值,若高於設置的閾值則對該請求直接返回,不再調用後續資源。
  • 熔斷機制:當失敗率達到閥值自動觸發降級(如因網絡故障、超時造成的失敗率真高),熔斷器觸發的快速失敗會進行快速恢復。
  • 降級機制:超時降級、資源不足時(線程或信號量)降級、運行異常降級等,降級後可以配合降級接口返回託底數據。
  • 緩存支持:提供了請求緩存、請求合併實現。
  • 通過近實時的統計/監控/報警功能,來提高故障發現的速度。
  • 通過近實時的屬性和配置熱修改功能,來提高故障處理和恢復的速度。

Config

介紹

Spring Cloud Config是一個解決分佈式系統的配置管理方案。微服務意味着要將單體應用中的業務拆分成一個個子服務,每個服務的粒度相對較小,因此係統 中會出現大量的服務。由於每個服務都需要必要的配置信息才能運行,所以一套集中式的、 動態的配置管理設施是必不可少的。Spring Cloud提供了ConfigServer來解決這個問題,我們每一個微服務自 己帶着一個application.yml 上百個配置文件的管理。

應用場景

  • 不方便維護,多人同時對配置文件進行修改,衝突不斷,很難維護
  • 配置內容安全和權限,主要是針對線上的配置來說,一般不對開發公開,只有運維有權限所以需要將配置文件隔離,不放到項目代碼裏
  • 更新配置項目需要重啓,每次更新配置文件都需要重啓項目,很耗時。使用了配置中心後,即可實現配置實時更新congfig Server和Config Client結合Spring Cloud Bus實現配置自動刷新。

原理

  • 配置文件存儲在遠端Git(比如GitHub,Gitee等倉庫),config-server從遠端Git拉取配置文件,並保存到本地Git。
  • 本地Git和config-server的交互是雙向的,因爲當遠端Git無法訪問時,會從本地Git獲取配置文件。
  • config-client(即各個微服務),從config-server拉取配置文件。

角色

  • Config Server:提供配置文件的存儲、以接口的形式將配置文件的內容提供出去。
  • Config Client:通過接口獲取數據、並依據此數據初始化自己的應用。

總結如下

寫在最後

歡迎大家關注我的公衆號【風平浪靜如碼】,海量Java相關文章,學習資料都會在裏面更新,整理的資料也會放在裏面。

覺得寫的還不錯的就點個贊,加個關注唄!點關注,不迷路,持續更新!!!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章