
注意:本Sentinel與Redis服務Sentinel是兩回事,壓根不是一個概念,請大家不要混肴。
Sentinel是由阿里巴巴中間件團隊開發的開源項目,是一種面向分布式微服務架構的輕量級高可用流量控制組件。
(資料圖片僅供參考)
Sentinel(哨兵)是 Redis 的高可用性解決方案:由一個或多個 Sentinel 實例組成的 Sentinel 系統可以監視任意多個主服務器,以及這些主服務器屬下的所有從服務器,并在被監視的主服務器進入下線狀態時,自動將下線主服務器屬下的某個從服務器升級為新的主服務器。
所以加下來我們介紹的都是【Alibaba的Sentinel】,所以請大家不要理解錯誤哦!好 我們接下來進入正題。
伴隨微服務的的越來越成熟和穩定發展,服務和服務之間的穩定性變得越來越重要。Sentinel以流量為切入點,從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。
首先針對于Sentinel進行梳理一下對應的發展史,看看Sentinel是如何一步一步的發展起來的,Sentinel是2012年創立出來的,距今已經成長了10個年頭了,接下來我們看看每個它階段的成長經歷吧!如下圖所示。
根據上面介紹的對應的發展歷程,我大概給Sentinel的發展經歷劃分為三個大階段,如下所示。
本節內容主要針對于Sentinel的優點和具有的較為不錯的特性進行分析,如以下圖所示。
Sentinel承接了阿里巴巴近10年的"雙十一”大促流量的核心場景,例如,秒殺(將突發流量控制在系統可以承受的范圍)、消息削峰填谷、集群流量控制、實時熔斷下游不可用服務等。
Sentinel提供了實時監控功能。用戶可以在控制臺中看到接入應用的單臺機器的秒級數據,甚至是500臺以下規模集群的匯總運行情況。
Sentinel提供了開箱即用的與其它開源框架或庫(例如:Spring Cloud、Apache Dubbo、gRPC、Quarkus)的整合模塊。我們只要在項目中引入相應的依賴并進行簡單的配置即可快速地接入Sentinel。此外,Sentinel還提供Java、Go 以及 C++ 等多語言的原生實現。
Sentinel提供簡單易、完善的SPI擴展接口,可以通過實現這些擴展接口快速地定制邏輯。
例如,定制規則管理、適配動態數據源等。
SPI ,全稱為 Service Provider Interface,是一種服務發現機制。它可以在 ClassPath 路徑下的 META-INF/services 文件夾查找文件,并自動加載文件中定義的類。
Sentinel與Spring Cloud Netfilx—Hystrix類似,但Sentinel要比Hystrix更加強大。例如,Sentinel提供了流量控制功能、比Hystrix更加完善的實時監控功能等等。
服務框架功能點 | Hystrix | Sentinel |
熔斷能力 | 好 | 好 |
資源隔離 | 很好 | 不太好 |
服務限流 | 好 | 很好 |
實時監控 | 一般 | 很好 |
資源(Resource)是Sentinel的關鍵概念,它可以是Java應用程序中的任何內容,例如,由應用程序提供的服務,或由應用程序調用的其它應用提供的服務,甚至可以是一段代碼。
通過Sentinel API定義的代碼,就是資源,能夠被Sentinel保護起來。大部分情況下,可以使用方法簽名,URL,甚至服務名稱作為資源名來標示資源。
圍繞資源的實時狀態設定的規則,可以包括,流量控制規則、熔斷降級規則以及系統保護規則。所有規則可以動態實時調整。
graph LRA1[服務請求] -- 調用 --> B(資源)A2[服務請求] -- 調用 --> B{資源}B[申請資源] --> C(流量控制規則)B[申請資源] --> D{熔斷降級規則}B[申請資源] --> E{系統保護規則}C(流量控制規則) --> F[請求執行] D(熔斷降級規則) --> F[請求執行]E(系統保護規則) --> F[請求執行]
流量控制在網絡傳輸中是一個常用的概念,它用于調整網絡包的發送數據,主要用于處理服務調用、接口調用及相關的調用流量速度控制和限制的規則。偏向于QPS維度的概念。
對于以上的三點流量控制的要求,Sentinel作為一個流量調配器,可以根據需要把隨機的請求調整成合適的形狀,如下圖所示:
Sentinel的設計理念是讓您自由選擇控制的角度,并進行靈活組合,從而達到想要的效果。
資源的調用鏈路,資源和資源之間的關系
指標名稱 | 備注 |
QPS | 每秒的服務調用量 |
線程池 | 服務線程調用計數器/資源隔離 |
系統負載 | 在動態化調整容器化負載能力 |
指標名稱 | 備注 |
直接限流 | 流量控制 |
冷啟動 | 如何分配對應的規則給 ,調用了較少的服務或者接口 |
排隊 | 請求排隊機制 |
主要用于當服務宕機或者此接口一直處于調用失敗后的,方式進行控制是否進行熔斷降級規則的開關控制。
流量控制以外,降低調用鏈路中的不穩定資源也是Sentinel的使命之一。由于調用關系的復雜性,如果調用鏈路中的某個資源出現了不穩定,最終會導致請求發生堆積。這個問題和Hystrix里面描述的問題是一樣的。如下圖所示
從上面的兩個圖可以看出來Sentinel和Hystrix的原則是一致的: 當調用鏈路中某個資源出現不穩定,例如,表現為 timeout,異常比例升高的時候,則對這個資源的調用進行限制,并讓請求快速失敗,避免影響到其它的資源,最終產生雪崩的效果。
為了實現資源的隔離以及服務的熔斷控制,Sentinel和Hystrix采取了完全不一樣的方法。
如果通過線程池的方式,來對依賴(資源之間的依賴或者資源服務之間的調用鏈路)進行了隔離。好處資源和資源之間做到了最徹底的隔離,并且還可以支持超時時間的控制缺點是除了增加了線程切換的成本,還需要預先給各個資源做線程池大小的分配。如果通過信號量方式進行資源隔離,則只能運行控制調用資源的總量,這與【通過并發線程數進行限制】有點類似。Hystrix采用的是線程池(默認)和信號量兩種方案去實現。
Sentinel采取了兩種手段去實現。
通過并發線程數進行限制資源池隔離的方法不同,Sentinel通過限制資源并發線程的數量,來減少不穩定資源對其它資源的影響。這樣不但沒有線程切換的損耗,也不需要您預先分配線程池的大小。
當某個資源出現不穩定的情況下,例如,響應時間變長,對資源的直接影響就是會造成線程數的逐步積。當線程數在特定資源上堆積到一定的數量之后,對該資源的新請求就會被拒絕。堆積的線程完成任務后才開始繼續接收請求。
通過響應時間對資源進行降級對并發線程數進行控制以外,Sentinel還可以通過響應時間來快速降級不穩定的資源。當依賴的資源出現響應時間過長后,所有對該資源的訪問都會被直接拒絕,直到過了指定的時間窗口之后才重新恢復。
主要用于當服務系統的保護規則能力,覺得是否接收該服務的請求的處理模式機制。
Sentinel 同時提供系統維度的自適應保護能力。防止雪崩,是系統防護中重要的一環。當系統負載較高的時候,如果還持續讓請求進入,可能會導致系統崩潰,無法響應。在集群環境下,網絡負載均衡會把本應這臺機器承載的流量轉發到其它的機器上去。如果這個時候其它的機器也處在一個邊緣狀態的時候,這個增加的流量就會導致這臺機器也崩潰,最后導致整個集群不可用。
針對這個情況,Sentinel 提供了對應的保護機制,讓系統的入口流量和系統的負載達到一個平衡,保證系統在能力范圍之內處理最多的請求。
具體細節功能會在后面的專題文章講述,謝謝大家多指正