Sentinel 是什么？

概述

• 分布式系統(tǒng)的流量防衛(wèi)兵
• 隨著微服務(wù)的流行，服務(wù)和服務(wù)之間的穩(wěn)定性變得越來越重要。Sentinel 以流量為切入點(diǎn)，從流量控制、熔斷降級系統(tǒng)負(fù)載保護(hù)等多個維度保護(hù)服務(wù)的穩(wěn)定性。

Sentinel 的歷史：

歷史

• 2012 年，Sentinel 誕生，主要功能為入口流量控制。
• 2013-2017 年，Sentinel 在阿里巴巴集團(tuán)內(nèi)部迅速發(fā)展，成為基礎(chǔ)技術(shù)模塊，覆蓋了所有的核心場景。Sentinel 也因此積累了大量的流量歸整場景以及生產(chǎn)實(shí)踐。
• 2018 年，Sentinel 開源，并持續(xù)演進(jìn)。
• 2019 年，Sentinel 朝著多語言擴(kuò)展的方向不斷探索，推出 C++ 原生版本，同時針對 Service Mesh 場景也推出了 Envoy 集群流量控制支持，以解決 Service Mesh 架構(gòu)下多語言限流的問題。
• 2020 年，推出 Sentinel Go 版本，繼續(xù)朝著云原生方向演進(jìn)。

Sentinel 分為兩個部分:

兩部分

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

基本概念及作用

基本概念：

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

主要作用：

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

Sleuth

概述

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

zipkin分布式監(jiān)控客戶端

• 概述
  • Zipkin是一種分布式跟蹤系統(tǒng)。它有助于收集解決微服務(wù)架構(gòu)中的延遲問題所需的時序數(shù)據(jù)。它管理這些數(shù)據(jù)的收集和查找。Zipkin的設(shè)計基于Google Dapper論文。應(yīng)用程序用于向Zipkin報告時序數(shù)據(jù)。Zipkin UI還提供了一個依賴關(guān)系圖，顯示了每個應(yīng)用程序通過的跟蹤請求數(shù)。如果要解決延遲問題或錯誤，可以根據(jù)應(yīng)用程序，跟蹤長度，注釋或時間戳對所有跟蹤進(jìn)行篩選或排序。選擇跟蹤后，您可以看到每個跨度所需的總跟蹤時間百分比，從而可以識別有問題的應(yīng)用程序。
• 通過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
  • 基本工作單元。發(fā)送一個遠(yuǎn)程請求就會產(chǎn)生一個span，span通過一個64位ID唯一標(biāo)識，trace以另一個64位ID表示，span還有其他數(shù)據(jù)信息，比如摘要、時間戳事件、關(guān)鍵值注釋(tags)、span的ID、以及進(jìn)度ID(通常是IP地址)。span在不斷的啟動和停止，同時記錄了時間信息，當(dāng)你創(chuàng)建了一個span，你必須在未來的某個時刻停止它。
• Trace
  • 一系列spans組成的一個樹狀結(jié)構(gòu)。例如：發(fā)送一個請求，需要調(diào)用多個微服務(wù)，每調(diào)用一個微服務(wù)都會產(chǎn)生一個span，這些span組成一個trace
• Annotation
  • 簡介
    • 用來及時記錄一個事件的存在，一些核心annotations用來定義一個請求的開始和結(jié)束
    • cs - Client Sent -客戶端發(fā)起一個請求，這個annotion描述了這個span的開始
    • sr - Server Received -服務(wù)端獲得請求并準(zhǔn)備開始處理它，如果將其sr減去cs時間戳便可得到網(wǎng)絡(luò)延遲
    • ss - Server Sent -注解表明請求處理的完成(當(dāng)請求返回客戶端)，如果ss減去sr時間戳便可得到服務(wù)端需要的處理請求時間
    • cr - Client Received -表明span的結(jié)束，客戶端成功接收到服務(wù)端的回復(fù)，如果cr減去cs時間戳便可得到客戶端從服務(wù)端獲取回復(fù)的所有所需時間

例如一個請求如下：

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

 上圖表示一請求鏈路，一條鏈路通過Trace Id唯一標(biāo)識，Span標(biāo)識發(fā)起的請求信息，各span通過parent id 關(guān)聯(lián)起來，如圖

總結(jié)

本篇文章就到這里了，希望能給你帶來幫助，也希望您能夠多多關(guān)注腳本之家的更多內(nèi)容！

最新評論