您好,登錄后才能下訂單哦!
今天就跟大家聊聊有關Sentinel動態數據源架構設計理念與改造實踐是怎么樣的,可能很多人都不太了解,為了讓大家更加了解,小編給大家總結了以下內容,希望大家根據這篇文章可以有所收獲。
在介紹集群限流之前需要首先掌握動態數據源的配置方式,根據 Sentinel 官方提供的代碼提出整體架構思路,并最終給出實踐指導。
溫馨提示:本文主要分為動態數據源架構設計理念、從官方示例尋找改造思路、基于SpringBoot改造方案三個部分來詳細剖析 Sentienl 動態數據源的改造方案,循序漸進,不僅解決問題本身,更是反映了作者研究一個問題的思路與方法。
在 Sentinel 中主要有如下幾個角色:管理后臺、限流熔斷規則數據源、應用程序。
1)管理后臺
管理后臺主要用于可視化配置限流規則、熔斷規則,其操作界面截圖如下:
用于存儲限流熔斷規則的數據容器,在 Sentinel 中對應動態數據源這個概念,動態數據源包含兩層含義:
數據容器
數據容器指的就是存儲熔斷、限流等規則配置的數據庫,例如關系型數據庫、Zookeeper等等,在實際生產過程中需要選用支持持久化功能的數據庫,否則程序一重啟,配置規則就會丟失,顯然是不能接受的。
動態
動態二字主要強調的是配置規則的更改能動態及時生效,引入 Sentinel 限流 SDK 的應用程序在不需要重啟的情況下動態感知配置規則發生變化并立即生效。Sentinel 目前對 apollo、consul、etcd、nacos、redis、spring-clould-config、zookeeper 等進行了適配支持。
3)應用程序
希望通過 Sentinel 提供的限流、熔斷功能對應用程序加以保護,需要引用 Sentinel 相關的 SDK,根據采集的調用信息判斷當前是否符合限流規則。
后臺管理系統、動態數據源、應用程序的關系如圖所示:
從官方的文檔中可以明確獲悉 sentinel-dashboard 即官方自帶的后臺管理系統只支持將限流、熔斷等限流配置規則存儲在內存中,一旦后臺管理系統重啟,配置的熔斷規則將全部丟失,所以在生產實踐過程中需要對 sentinel-dashboard 進行一定的改造,引入動態數據源,例如 Zookeeper,對限流等配置進行持久化存儲。
有了上面的架構設計理念為我們的改造提供了方向,那如何具體改造呢?首先我們來看一下官方提供的 Demo 程序。官方提供的示例代碼如下圖所示:
2.1 限流熔斷等規則存儲
首先查閱一下 ZookeeperConfigSender,該類主要的作用是將配置寫入到 zookeeper 中,其關鍵代碼截圖如下:
實踐指導,通常基于 zookeeper 的開發,主要是規劃好目錄結構,關于 Sentinel,我對給出一個初步的目錄規劃。
在 zookeeper 中創建一個根節點,例如 /sentienl 用來表示限流相關的根目錄。
groupId 通常為一個獨立的應用名稱,例如應用的 appId,例如示例中的 provider-demo。
dataId 通常為配置類型,例如限流規則、熔斷規則、熱點規則等類別,例如限流規則使用 /flowRule ,熔斷規則使用 /degradeRule,其 value 值使用 json 存儲,將該應用下的所有限流規則用一個 json 對象表示,其存儲格式類似于 [{},{}]。
實現存儲規則的配置存儲后接下來是需要客戶端能動態感知規則的變化,從而是配置規則實時生效。
我們依然先來看一下官方示例,其核心代碼如圖所示:
創建 ZookeeperDataSource,每一個 ZookeeperDataSource 負責監聽一個節點。
需要調用 FlowRuleManager 的 register2Property 方法將數據源關聯的數據注冊到 FlowRuleManager 中,方便 Sentinel 內核根據數據源中存儲的限流熔斷等規則進行工作。
客戶端在啟動的時候會調用 FlowRuleManager 相關方法加載限流相關的配置,那如果配置規則發生變化后,客戶端如何動態感知呢?其關鍵就在于 ZookeeperDataSource 的實現中,其實現關鍵點如下:
從官方的示例中我們不難發現,引入 Zookeeper 數據源主要有兩個步驟:將數據存儲在Zookeeper中以及在客戶端監聽ZK從而實時生效兩個步驟。
sentinel 官方提供了默認的后臺管理系統實現:sentinel-dashboard,但其缺點非常明顯:基于內存存儲,無法用于實際生產過程。大家可能會向后臺管理系統將配置信息存儲在內存中,那接入的客戶端如何從 sentinel-dashboard 的內存中獲取配置信息呢,這是因為 sentinel-dashboard 里提供了簡單的機器發現,并且內置了 sentinel 客戶端之間、sentinel 客戶端與 sentinel-dashboard 之間的通訊協議,具體由 sentinel-transport 模塊實現,目前提供了基于 http 與 netty 的實現方式,故能將 sentinel-dashboard 內存中的配置信息推送到客戶端,從而使客戶端根據配置進行限流與熔斷。
接下來回答本文的重點部分,基于 sentinel-dashboard 如何引入 zookeeper 等動態數據源呢?
首先我們可以順著 sentinel-dashboard 的提供的控制器,尋找其后臺入口,改造目標也很明確,就是將數據持久化到 zookeeper中,例如增加流控規則的后臺處理入口為:
目前大部分項目都是基于 SpringBoot,故本文給出基于 SpringBoot 進行的客戶端加載實現思路。
利用 SpringBoot 的事件機制,在 Spring 容器初始化后,開始加載 zookeeper 中的配置,其實現思路是讀取 zookeeper 中的 /sentinel 下所有的子節點,然后并依次遍歷其子節點(appid),然后依次讀取 flow(限流)、degrade(熔斷)等配置,并調用 Sentinel 的 相關API完成加載,其偽代碼如下:
其主要關鍵點如下:基于 Spring ApplicationReadyEvent 事件,實現限流規則的加載。
創建 ZookeeperDataSource 創建動態數據源。
并調用 Sentinel 提供的相關 API 完成限流規則的加載。
看完上述內容,你們對Sentinel動態數據源架構設計理念與改造實踐是怎么樣的有進一步的了解嗎?如果還想了解更多知識或者相關內容,請關注億速云行業資訊頻道,感謝大家的支持。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。