spring cloud概念總結

1.eureka(註冊與發現)

Eureka是由Netflix(公司)開發的服務發現框架,本身是一個基於RESTful的服務,主要用於定位運行在亞馬遜域中的中間層服務

由兩個組件組成:Eureka Server和Eureka Client。Eureka Server提供服務註冊服務,各個節點啓動後,會在Eureka Server中進行註冊,這樣EurekaServer中的服務註冊表中將會存儲所有可用服務節點的信息,服務節點的信息可以在界面中直觀的看到。Eureka Client即爲微服務節點

Eureka Client啓動後,將會註冊到Eureka Server中,同時會定時發送心跳(默認無配置情況下爲30s),如果Eureka Server在多個心跳週期內沒有接收到某個節點的心跳,那麼Eureka Server將會從服務註冊表中把這個節點移除(默認90s)


Eureka Server之間通過複製的方式完成數據同步,Eureka還提供了客戶端緩存機制,即使所有的Eureka Server都掛掉,客戶端依然可以利用緩存中的信息消費其他服務的API。


綜上,Eureka通過心跳檢查、客戶端緩存等機制,確保了系統的高可用性、靈活性和可伸縮性。



進入自我保護模式時,此時會出現以下幾種情況:
① Eureka Server 不再從註冊列表中移除因爲長時間沒收到心跳而應該過期的服務。
② Eureka Server 仍然能夠接受新服務的註冊和查詢請求,但是不會被同步到其它節點上,保證當前節點依然可用。
③ 當網絡穩定時,當前Eureka Server新的註冊信息會被同步到其它節點中。
自我保護機制通過配置 eureka.server.enable-self-preservation 來開啓/關閉,默認開啓


eureka.instance.lease-renewal-interval-in-seconds: 30 --服務和註冊中心的心跳間隔時間,默認爲30s
eureka.instance.lease-expiration-duration-in-seconds: 90  --服務和註冊中心的心跳超時時間,默認爲90s

2.Hystrix(斷路器容錯)

如果服務提供者相應非常慢,那麼消費者對提供者的請求就會被強制等待,知道提供者響應或超時。在高負載場景下,如果不作任何處理,此類問題可能會導致服務消費者的資源耗竭甚至整個系統崩潰。
微服務架構的應用系統通常包含多個服務層。微服務之間通過網絡進行通信,從而支撐起整個應用系統,因此,微服務之間難免存在依賴關係。而這種由於"基礎服務故障"導致"級聯故障"的現象稱爲雪崩效應

如果A最爲服務提供者(基礎服務),B爲A的服務消費者,C和D是B的服務消費者。當A不可用引起了B的不可用,並將不可用像滾雪球一樣放大到C和D時,雪崩效應就形成了

使用斷路器模式:斷路器可理解爲對容易導致錯誤操作的代理。這種代理能夠統計一段時間內調用失敗的次數,並決定是正常請求依賴的服務還是直接返回;斷路器可以實現快速失敗,如果它在一段時間內檢測到許多類似的錯誤(例如超時),就會在之後的一段時間內,強迫對該服務的調用快速失敗,即不請求所依賴的服務。這樣,應用程序就無須再浪費CPU時間去等待長時間的超時。斷路器也可以自動診斷依賴的服務是否已經恢復正常,如果發現依賴的服務已經恢復正常,那麼就會恢復請求該服務



流程:
正常情況下,斷路器關閉,可以正常請求依賴的服務;

當一段時間內,請求失敗率達到一定閾值(例如錯誤率達到50%,或100次/分鐘等),斷路器就會打開,此時,就不會再去請求依賴的服務;
斷路器打開一段時間後,會自動進入"半開"狀態。此時,斷路器允許一個請求訪問依賴的服務。如果請求能夠調用成功,則關閉斷路器;否則繼續保持打開狀態

3.Ribbon(負載均衡器)

Ribbon(負載均衡器)的作用正是提供負載均衡機制,當爲Ribbon配置服務提供者地址列表後,Ribbon就可以基於某種負載均衡算法,自動地幫助服務消費者去請求。


Ribbon提供的負載均衡算法有多種,例如輪詢、加權響應時間、隨機和區域感知輪詢。


Ribbon與Eureka配合使用時,Ribbon可自動從Eureka Server獲取服務提供者地址列表,並基於負載均衡算法,請求其中一個服務提供者示例。

4.Zuul(微服務網關)

微服務架構經過前幾個組件的組合,已經有了基本的雛形了,那麼我們爲什麼還要使用微服務網關呢?我們可以想象,一般情況下我們一個業務並不是只調用一個接口就可以完成一個業務需求

不使用Zuul的問題如下:
客戶端會多次請求不同的微服務,增加了客戶端的複雜性;

存在跨域請求,在一定場景下處理相對複雜;

認證複雜,每個服務都需要獨立認證;

難以重構,隨着項目的迭代,可能需要重新劃分微服務,如果直接與微服務通信,那麼重構會很難實施

使用Zuul的優點如下:
易於監控;
易於認證:
可在微服務網關上進行認證,然後再將請求轉發到後端的微服務,而無須在每個微服務中進行認證;
減少了客戶端與各個微服務之間的交互次數,微服務網關封裝了應用程序的內部結構,客戶端只須跟網關交互,而無須直接調用特定微服務接口

zuul的核心是一系列的filters, 其作用可以類比Servlet框架的Filter,或者AOP
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章