Java的springcloud Sentinel是什麼你知道嗎

Posted on by

Sentinel 是什麼？

概述

  • 分佈式系統的流量防衛兵
  • 隨著微服務的流行，服務和服務之間的穩定性變得越來越重要。Sentinel 以流量為切入點，從流量控制、熔斷降級系統負載保護等多個維度保護服務的穩定性。

Sentinel 的歷史：

歷史

  • 2012 年，Sentinel 誕生，主要功能為入口流量控制。
  • 2013-2017 年，Sentinel 在阿裡巴巴集團內部迅速發展，成為基礎技術模塊，覆蓋瞭所有的核心場景。Sentinel 也因此積累瞭大量的流量歸整場景以及生產實踐。
  • 2018 年，Sentinel 開源，並持續演進。
  • 2019 年，Sentinel 朝著多語言擴展的方向不斷探索，推出 C++ 原生版本，同時針對 Service Mesh 場景也推出瞭 Envoy 集群流量控制支持，以解決 Service Mesh 架構下多語言限流的問題。
  • 2020 年，推出 Sentinel Go 版本，繼續朝著雲原生方向演進。

Sentinel 分為兩個部分:

兩部分

  • 核心庫（Java 客戶端）不依賴任何框架/庫，能夠運行於所有 Java 運行時環境，同時對 Dubbo / Spring Cloud 等框架也有較好的支持。
  • 控制臺（Dashboard）基於 Spring Boot 開發，打包後可以直接運行，不需要額外的 Tomcat 等應用容器。

基本概念及作用

基本概念：

  • 資源
    • 是 Sentinel 的關鍵概念。它可以是 Java 應用程序中的任何內容，例如，由應用程序提供的服務，或由應用程序調用的其它應用提供的服務，甚至可以是一段代碼。在接下來的文檔中，我們都會用資源來描述代碼塊。
    • 隻要通過 Sentinel API 定義的代碼，就是資源，能夠被 Sentinel 保護起來。大部分情況下，可以使用方法簽名，URL，甚至服務名稱作為資源名來標示資源。
    • 我們說的資源，可以是任何東西，服務，服務裡的方法，甚至是一段代碼。使用 Sentinel 來進行資源保護，主要分為幾個步驟:
      • 定義資源
        • 先把可能需要保護的資源定義好，之後再配置規則。也可以理解為，隻要有瞭資源，我們就可以在任何時候靈活地定義各種流量控制規則。在編碼的時候，隻需要考慮這個代碼是否需要保護，如果需要保護，就將之定義為一個資源。
      • 定義規則
      • 檢驗規則是否生效
  • 規則
    • 圍繞資源的實時狀態設定的規則，可以包括流量控制規則、熔斷降級規則以及系統保護規則。所有規則可以動態實時調整。

主要作用：

  •  流量控制
    • 什麼是流量控制
      • 概述
        • 流量控制在網絡傳輸中是一個常用的概念，它用於調整網絡包的發送數據。然而，從系統穩定性角度考慮，在處理請求的速度上，也有非常多的講究。任意時間到來的請求往往是隨機不可控的，而系統的處理能力是有限的。我們需要根據系統的處理能力對流量進行控制。Sentinel 作為一個調配器，可以根據需要把隨機的請求調整成合適的形狀
    • 流量控制有以下幾個角度:
      • 資源的調用關系，例如資源的調用鏈路，資源和資源之間的關系；
      • 運行指標，例如 QPS、線程數等；
      • 控制的效果，例如直接限流（快速失敗）、冷啟動（Warm Up）、勻速排隊（排隊等待）等。
    • Sentinel 的設計理念是讓您自由選擇控制的角度，並進行靈活組合，從而達到想要的效果。
    • QPS流量控制
      • 當 QPS 超過某個閾值的時候，則采取措施進行流量控制。流量控制的效果包括以下幾種：直接拒絕、Warm Up、勻速排隊。
        • 直接拒絕（RuleConstant.CONTROL_BEHAVIOR_DEFAULT）
          • 直接拒方式是默認的流量控制方式，當QPS超過任意規則的閾值後，新的請求就會被立即拒絕，拒絕方式為拋出FlowException。這種方式適用於對系統處理能力確切已知的情況下，比如通過壓測確定瞭系統的準確水位時
        • Warm Up（預熱）
          • Warm Up方式，即預熱/冷啟動方式。當系統長期處於低水位的情況下，當流量突然增加時，直接把系統拉升到高水位可能瞬間把系統壓垮。通過”冷啟動”，讓通過的流量緩慢增加，在一定時間內逐漸增加到閾值上限，給冷系統一個預熱的時間，避免冷系統被壓垮
        • 勻速排隊
          • 勻速排隊方式會嚴格控制請求通過的間隔時間，也即是讓請求以均勻的速度通過，對應的是漏桶算法。
      • 關聯限流
        • 概述
          • 當關聯的資源請求達到閾值時，就限流自己。
      • 鏈路限流
        • 概述
          • 並發線程數限流用於保護業務線程數不被耗盡。例如，當應用所依賴的下遊應用由於某種原因導致服務不穩定、響應延遲增加，對於調用者來說，意味著吞吐量下降和更多的線程數占用，極端情況下甚至導致線程池耗盡。為應對太多線程占用的情況，業內有使用隔離的方案，比如通過不同業務邏輯使用不同線程池來隔離業務自身之間的資源爭搶（線程池隔離）。這種隔離方案雖然隔離性比較好，但是代價就是線程數目太多，線程上下文切換的 overhead 比較大，特別是對低延時的調用有比較大的影響。Sentinel 並發線程數限流不負責創建和管理線程池，而是簡單統計當前請求上下文的線程數目，如果超出閾值，新的請求會被立即拒絕，效果類似於信號量隔離。
    • 熔斷降級
    • 概述
      • Sentinel除瞭流量控制以外，對調用鏈路中不穩定的資源進行熔斷降級也是保障高可用的重要措施之一。
      • Sentinel 熔斷降級會在調用鏈路中某個資源出現不穩定狀態時（例如調用超時或異常比例升高），對這個資源的調用進行限制，讓請求快速失敗，避免影響到其它的資源而導致級聯錯誤。當資源被降級後，在接下來的降級時間窗口之內，對該資源的調用都自動熔斷（默認行為是拋出 DegradeException）。
      • Sentinel 和 Hystrix 的原則是一致的: 當調用鏈路中某個資源出現不穩定，例如，表現為 timeout，異常比例升高的時候，則對這個資源的調用進行限制，並讓請求快速失敗，避免影響到其它的資源，最終產生雪崩的效果。
    • 限流降級指標有三個
      • 平均響應時間（RT）
        • 概述
          • 平均響應時間 (DEGRADE_GRADE_RT)：當資源的平均響應時間超過閾值（DegradeRule 中的 count，以 ms 為單位，默認上限是4900ms）之後，資源進入準降級狀態。如果1s之內持續進入 5 個請求，它們的 RT 都持續超過這個閾值，那麼在接下來的時間窗口（DegradeRule 中的 timeWindow，以 s 為單位）之內，對這個方法的調用都會自動地返回（拋出 DegradeException）。在下一個時間窗口到來時, 會接著再放入5個請求, 再重復上面的判斷。
      • 異常比例
        • 概述
          • 異常比例 (DEGRADE_GRADE_EXCEPTION_RATIO)：當資源的每秒請求量 >= 5，且每秒異常總數占通過量的比值超過閾值（DegradeRule 中的 count）之後，資源進入降級狀態，即在接下的時間窗口（DegradeRule中的 timeWindow，以 s 為單位）之內，對這個方法的調用都會自動地返回。異常比率的閾值范圍是 [0.0, 1.0]，代表 0% – 100%。
      • 異常數
        • 概述
          • 異常數 (DEGRADE_GRADE_EXCEPTION_COUNT)：當資源近 1 分鐘的異常數目超過閾值之後會進行熔斷。
  • 系統負載保護
  • 規則持久化
    • 概述
    • 無論是通過硬編碼的方式來更新規則，還是通過接入 Sentinel Dashboard 後，在頁面上操作更新規則，都無法避免一個問題，那就是服務重啟後，規則就丟失瞭，因為默認情況下規則是保存在內存中的。
    • 我們在 Dashboard 上為客戶端配置好瞭規則，並推送給瞭客戶端。這時由於一些因素客戶端出現異常，服務不可用瞭，當客戶端恢復正常再次連接上 Dashboard 後，這時所有的規則都丟失瞭，我們還需要重新配置一遍規則，這肯定不是我們想要的。

Sleuth

概述

  • Spring Cloud Sleuth為springCloud實現瞭一個分佈式鏈路追蹤解決方案，大量借鑒瞭Dapper，Zipkin和HTrace等鏈路追蹤技術。對於大多數用戶而言，Sleuth應該是不可見的，並且您與外部系統的所有交互都應自動進行檢測。您可以簡單地在日志中捕獲數據，也可以將其發送到遠程收集器服務。
  • 隨著分佈式系統越來越復雜，你的一個請求發過發過去，各個微服務之間的跳轉，有可能某個請求某一天壓力太大瞭，一個請求過去沒響應，一個請求下去依賴瞭三四個服務，但是你去不知道哪一個服務出來問題，這時候我是不是需要對微服務進行追蹤呀？監控一個請求的發起，從服務之間傳遞之間的過程，我最好記錄一下，記錄每一個的耗時多久，一旦出瞭問題，我們就可以針對性的進行優化，是要增加節點，減輕壓力，還是服務繼續拆分，讓邏輯更加簡單點呢？這時候springcloud-sleuth集成zipkin能幫我們解決這些服務追蹤問題。

zipkin分佈式監控客戶端

  • 概述
    • Zipkin是一種分佈式跟蹤系統。它有助於收集解決微服務架構中的延遲問題所需的時序數據。它管理這些數據的收集和查找。Zipkin的設計基於Google Dapper論文。應用程序用於向Zipkin報告時序數據。Zipkin UI還提供瞭一個依賴關系圖，顯示瞭每個應用程序通過的跟蹤請求數。如果要解決延遲問題或錯誤，可以根據應用程序，跟蹤長度，註釋或時間戳對所有跟蹤進行篩選或排序。選擇跟蹤後，您可以看到每個跨度所需的總跟蹤時間百分比，從而可以識別有問題的應用程序。
  • 通過docker安裝
    • docker run -d -p 9411:9411 openzipkin/zipkin
  • 通過jar包安裝
    • java -jar zipkin-server-*exec.jar
  • jar包下載地址
    • https://search.maven.org/remote_content?g=io.zipkin&a=zipkin-server&v=LATEST&c=exec
  • 在瀏覽器端訪問
    • http://localhost:9411

基本概念

  • Span
    • 基本工作單元。發送一個遠程請求就會產生一個span，span通過一個64位ID唯一標識，trace以另一個64位ID表示，span還有其他數據信息，比如摘要、時間戳事件、關鍵值註釋(tags)、span的ID、以及進度ID(通常是IP地址)。span在不斷的啟動和停止，同時記錄瞭時間信息，當你創建瞭一個span，你必須在未來的某個時刻停止它。
  • Trace
    • 一系列spans組成的一個樹狀結構。例如：發送一個請求，需要調用多個微服務，每調用一個微服務都會產生一個span，這些span組成一個trace
  • Annotation
    • 簡介
      • 用來及時記錄一個事件的存在，一些核心annotations用來定義一個請求的開始和結束
      • cs – Client Sent -客戶端發起一個請求，這個annotion描述瞭這個span的開始
      • sr – Server Received -服務端獲得請求並準備開始處理它，如果將其sr減去cs時間戳便可得到網絡延遲
      • ss – Server Sent -註解表明請求處理的完成(當請求返回客戶端)，如果ss減去sr時間戳便可得到服務端需要的處理請求時間
      • cr – Client Received -表明span的結束，客戶端成功接收到服務端的回復，如果cr減去cs時間戳便可得到客戶端從服務端獲取回復的所有所需時間

例如一個請求如下：

使用zipkin跟蹤整個請求過程如下：

 上圖表示一請求鏈路，一條鏈路通過Trace Id唯一標識，Span標識發起的請求信息，各span通過parent id 關聯起來，如圖

總結

本篇文章就到這裡瞭，希望能給你帶來幫助，也希望您能夠多多關註WalkonNet的更多內容！

推薦閱讀：