精華推薦 |【深入淺出Sentinel原理及實戰】「原理探索專題」完整剖析Alibaba微服務架構體系之輕量級高可用流量控制元件Sentinel（1）

Sentinel是什麼？不要概念混淆啊！

注意：本Sentinel與Redis服務Sentinel是兩回事，壓根不是一個概念，請大家不要混餚。

Alibaba的Sentinel

Sentinel是由阿里巴巴中介軟體團隊開發的開源專案，是一種面向分散式微服務架構的輕量級高可用流量控制元件。

Redis中的Sentinel

Sentinel（哨兵）是 Redis 的高可用性解決方案：由一個或多個 Sentinel 範例組成的 Sentinel 系統可以監視任意多個主伺服器，以及這些主伺服器屬下的所有從伺服器，並在被監視的主伺服器進入下線狀態時，自動將下線主伺服器屬下的某個從伺服器升級為新的主伺服器。

所以加下來我們介紹的都是【Alibaba的Sentinel】，所以請大家不要理解錯誤哦！好 我們接下來進入正題。

Sentinel出現的意義

伴隨微服務的的越來越成熟和穩定發展，服務和服務之間的穩定性變得越來越重要。Sentinel以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。

Sentinel的歷史

首先針對於Sentinel進行梳理一下對應的發展史，看看Sentinel是如何一步一步的發展起來的，Sentinel是2012年創立出來的，距今已經成長了10個年頭了，接下來我們看看每個它階段的成長經歷吧！如下圖所示。

根據上面介紹的對應的發展歷程，我大概給Sentinel的發展經歷劃分為三個大階段，如下所示。

基礎功能的不斷升級及開源化（初級成熟階段）

• 2012年：Sentinel誕生，主要功能為入口流量控制。
• 2013 ~ 2017 年：Sentinel在阿里巴巴集團內部迅速發展，成為基礎技術模組，覆蓋了所有的核心場景，Sentinel 也因此積累了大量的流量歸整場景以及生產實踐。
• 2018年：Sentinel開源化，並持續演進。

多語言化擴充套件及Mesh過度化（進階升級階段）

• 2019年：Sentinel多語言擴充套件的方向不斷探索，推出 C++ 原生版本，同時針對 Service Mesh場景也推出了Envoy叢集流量控制支援，以解決Service Mesh架構下多語言限流的問題。
• 2020年：推出Sentinel Go版本，繼續朝著雲原生方向演進。

雲原生化演進及體系標準化（未來發展階段）

• 2021年：Sentinel正在朝著 2.0 雲原生高可用決策中心元件進行演進；同時推出了 Sentinel Rust 原生版本。同時我們也在 Rust 社群進行了 Envoy WASM extension 及 eBPF extension 等場景探索。
• 2022年：Sentinel品牌升級為流量治理，領域涵蓋流量路由/排程、流量染色、流控降級、過載保護/範例摘除等；同時社群將流量治理相關標準抽出到OpenSergo標準中，Sentinel 作為流量治理標準實現。

為什麼選擇Sentinel

本節內容主要針對於Sentinel的優點和具有的較為不錯的特性進行分析，如以下圖所示。

豐富的應用場景

Sentinel承接了阿里巴巴近10年的"雙十一」大促流量的核心場景，例如，秒殺（將突發流量控制在系統可以承受的範圍）、訊息削峰填谷、叢集流量控制、實時熔斷下游不可用服務等。

完備的實時監控

Sentinel提供了實時監控功能。使用者可以在控制檯中看到接入應用的單臺機器的秒級資料，甚至是500臺以下規模叢集的彙總執行情況。

廣泛的開源生態

Sentinel提供了開箱即用的與其它開源框架或庫（例如：Spring Cloud、Apache Dubbo、gRPC、Quarkus）的整合模組。我們只要在專案中引入相應的依賴並進行簡單的設定即可快速地接入Sentinel。此外，Sentinel還提供Java、Go 以及 C++ 等多語言的原生實現。

完善的SPI擴充套件機制

Sentinel提供簡單易、完善的SPI擴充套件介面，可以通過實現這些擴充套件介面快速地客製化邏輯。

例如，客製化規則管理、適配動態資料來源等。

什麼是SPI

SPI ，全稱為 Service Provider Interface，是一種服務發現機制。它可以在 ClassPath 路徑下的 META-INF/services 資料夾查詢檔案，並自動載入檔案中定義的類。

對標Spring Cloud Netflix-Hystrix的熔斷器

功能上簡單對比

Sentinel與Spring Cloud Netfilx—Hystrix類似，但Sentinel要比Hystrix更加強大。例如，Sentinel提供了流量控制功能、比Hystrix更加完善的實時監控功能等等。

Sentinel基本組成概念

資源（Resource）

資源（Resource）是Sentinel的關鍵概念，它可以是Java應用程式中的任何內容，例如，由應用程式提供的服務，或由應用程式呼叫的其它應用提供的服務，甚至可以是一段程式碼。

定義方式

通過Sentinel API定義的程式碼，就是資源，能夠被Sentinel保護起來。大部分情況下，可以使用方法簽名，URL，甚至服務名稱作為資源名來標示資源。

規則

圍繞資源的實時狀態設定的規則，可以包括，流量控制規則、熔斷降級規則以及系統保護規則。所有規則可以動態實時調整。

流量控制規則

流量控制在網路傳輸中是一個常用的概念，它用於調整網路包的傳送資料，主要用於處理服務呼叫、介面呼叫及相關的呼叫流量速度控制和限制的規則。偏向於QPS維度的概念。

功能和設計理念

• 系統穩定性角度：對於使用者端或者呼叫段在處理請求的速度上（TPS/QPS），也有非常多的限制和控制。

• 在系統執行的過程中，任意時間到來的請求往往是隨機不可控的，而系統的處理能力是有限，需要在不均衡的情況下進行控制服務的請求與速度和容錯。

• 根據系統的處理能力對流量進行動態調整和控制。

對於以上的三點流量控制的要求，Sentinel作為一個流量調配器，可以根據需要把隨機的請求調整成合適的形狀，如下圖所示：

流量控制的維度

Sentinel的設計理念是讓您自由選擇控制的角度，並進行靈活組合，從而達到想要的效果。

資源的呼叫關係

資源的呼叫鏈路，資源和資源之間的關係

執行指標

控制的效果

熔斷降級規則

主要用於當服務宕機或者此介面一直處於呼叫失敗後的，方式進行控制是否進行熔斷降級規則的開關控制。

什麼是熔斷降級

流量控制以外，降低呼叫鏈路中的不穩定資源也是Sentinel的使命之一。由於呼叫關係的複雜性，如果呼叫鏈路中的某個資源出現了不穩定，最終會導致請求發生堆積。這個問題和Hystrix裡面描述的問題是一樣的。如下圖所示

Hystrix的熔斷問題圖（雪崩圖）

Sentinel的熔斷問題圖（雪崩圖）

從上面的兩個圖可以看出來Sentinel和Hystrix的原則是一致的: 當呼叫鏈路中某個資源出現不穩定，例如，表現為 timeout，異常比例升高的時候，則對這個資源的呼叫進行限制，並讓請求快速失敗，避免影響到其它的資源，最終產生雪崩的效果。

熔斷降級實現方案

為了實現資源的隔離以及服務的熔斷控制，Sentinel和Hystrix採取了完全不一樣的方法。

Hystrix採用的方案

Hystrix採用的是執行緒池（預設）和號誌兩種方案去實現。

• 如果通過執行緒池的方式，來對依賴（資源之間的依賴或者資源服務之間的呼叫鏈路）進行了隔離。

  • 好處
    • 資源和資源之間做到了最徹底的隔離，並且還可以支援超時時間的控制
  • 缺點
    • 是除了增加了執行緒切換的成本，還需要預先給各個資源做執行緒池大小的分配。

• 如果通過號誌方式進行資源隔離，則只能執行控制呼叫資源的總量，這與【通過並行執行緒數進行限制】有點類似。

Sentinel採用的方案

Sentinel採取了兩種手段去實現。

• 通過並行執行緒數進行限制

資源池隔離的方法不同，Sentinel通過限制資源並行執行緒的數量，來減少不穩定資源對其它資源的影響。這樣不但沒有執行緒切換的損耗，也不需要您預先分配執行緒池的大小。

當某個資源出現不穩定的情況下，例如，響應時間變長，對資源的直接影響就是會造成執行緒數的逐步積。當執行緒數在特定資源上堆積到一定的數量之後，對該資源的新請求就會被拒絕。堆積的執行緒完成任務後才開始繼續接收請求。

• 通過響應時間對資源進行降級

對並行執行緒數進行控制以外，Sentinel還可以通過響應時間來快速降級不穩定的資源。當依賴的資源出現響應時間過長後，所有對該資源的存取都會被直接拒絕，直到過了指定的時間視窗之後才重新恢復。

系統保護規則

主要用於當服務系統的保護規則能力，覺得是否接收該服務的請求的處理模式機制。

系統負載保護

Sentinel 同時提供系統維度的自適應保護能力。防止雪崩，是系統防護中重要的一環。當系統負載較高的時候，如果還持續讓請求進入，可能會導致系統崩潰，無法響應。在叢集環境下，網路負載均衡會把本應這臺機器承載的流量轉發到其它的機器上去。如果這個時候其它的機器也處在一個邊緣狀態的時候，這個增加的流量就會導致這臺機器也崩潰，最後導致整個叢集不可用。

針對這個情況，Sentinel 提供了對應的保護機制，讓系統的入口流量和系統的負載達到一個平衡，保證系統在能力範圍之內處理最多的請求。

具體細節功能會在後面的專題文章講述，謝謝大家多指正