【架構師視角系列】風控場景下配置中心的設計實戰

码头工人發表於2024-08-12
架構

宣告

原創文章，轉載請標註。https://www.cnblogs.com/boycelee/p/18355942
《碼頭工人的一千零一夜》是一位專注於技術乾貨分享的博主，追隨博主的文章，你將深入瞭解業界最新的技術趨勢，以及在Java開發和安全領域的實用經驗分享。無論你是開發人員還是對逆向工程感興趣的愛好者，都能在《碼頭工人的一千零一夜》找到有價值的知識和見解。

配置中心繫列文章

《【架構師視角系列】風控場景下的配置中心設計思考》 https://www.cnblogs.com/boycelee/p/18355942
《【架構師視角系列】Apollo配置中心之架構設計（一）》https://www.cnblogs.com/boycelee/p/17967590
《【架構師視角系列】Apollo配置中心之Client端（二）》https://www.cnblogs.com/boycelee/p/17978027
《【架構師視角系列】Apollo配置中心之Server端（ConfigSevice）（三）》https://www.cnblogs.com/boycelee/p/18005318
《【架構師視角系列】QConfig配置中心繫列之架構設計（一）》https://www.cnblogs.com/boycelee/p/18013653
《【架構師視角系列】QConfig配置中心繫列之Client端（二）》https://www.cnblogs.com/boycelee/p/18033286
《【架構師視角系列】QConfig配置中心繫列之Server端（三）》https://www.cnblogs.com/boycelee/p/18055933

目錄
  • 宣告
  • 配置中心繫列文章
  • 1、什麼是配置中心？
    • 1.1、特點
        • 1.1.1、集中管理
        • 1.1.2、動態更新
  • 2、為什麼需要配置中心？
    • 2.1、方案優缺點
      • 2.1.1、共享儲存（如共享Redis）
      • 2.1.2、遠端呼叫（如HTTP呼叫）
      • 2.1.3、配置中心
  • 3、如何設計配置中心？
    • 3.1、架構圖
    • 3.2、架構分層
      • 3.2.1、客戶端層
        • Client
        • Admin
      • 3.2.2、網路層
        • Nginx
      • 3.2.3、服務層
        • Config Service
        • Admin Service
      • 3.2.4、資料層
        • Config DB
        • Admin DB
    • 3.3、時序圖
      • 3.3.1、啟動部分
      • 3.3.2、推送部分
      • 3.3.3、配置同步部分
    • 3.4、設計難點
      • 3.4.1、配置中心啟動
        • 場景描述
        • 問題描述
        • 方案描述
      • 3.4.2、三方應用啟動
        • 場景描述
        • 問題描述
        • 方案描述
      • 3.4.3、配置釋出
        • 場景描述
        • 問題描述
        • 方案描述
      • 3.4.4、快取設計
        • 場景描述
        • 問題描述
        • 方案描述
  • 4、總結
  • 5、最後

1、什麼是配置中心？

配置中心是分散式系統的重要元件，其目的是集中管理與分發服務所需要的配置檔案，將分散式系統中的配置簡化並進行統一管理。

1.1、特點

1.1.1、集中管理

將分散式系統的配置檔案集中儲存和管理，且有統一的管理平臺介面供運維人員對配置進行檢視與修改。避免由於資料配置地點不統一而造成資料不統一的問題。

1.1.2、動態更新

配置中心支援動態更新配置。當配置發生變化時，配置中心會立即將更新後的配置推送給所有訂閱的服務例項，不需要重啟服務例項。

2、為什麼需要配置中心？

風控場景通常需要頻繁修改策略進行攻防對抗，一般策略管理平臺與策略執行引擎是兩個服務，目的是為了解耦，使得業務需求的變更對策略執行引擎執行的影響最小化。通常策略引擎獲取策略配置的方法有以下幾種，分別是：共享儲存、遠端呼叫或配置中心。

2.1、方案優缺點

2.1.1、共享儲存（如共享Redis）

優點：

  • 高效訪問：共享儲存能夠提供快速的資料訪問速度，尤其是在本地或網路延遲較低的情況下。
  • 簡單實現：直接在Redis等共享儲存中儲存策略資料，簡化了策略獲取的實現。

缺點：

  • 資料大小限制：需要控制儲存值的大小，避免大key問題。例如，如果儲存的策略配置過大，可能會導致Redis的效能下降，增加了管理和維護的複雜性。
  • 耦合性問題：策略管理平臺和策略執行引擎之間的耦合性較高。如果策略管理平臺的增刪查改操作未考慮效能最佳化，可能會影響到策略執行引擎的穩定性和效率。策略執行引擎可能因為管理平臺的操作延遲或效能問題而出現異常。

2.1.2、遠端呼叫（如HTTP呼叫）

image-20240812134754252

優點：

  • 解耦：策略管理平臺和策略執行引擎透過遠端呼叫進行互動，減少了兩者之間的直接依賴。策略執行引擎不需要直接訪問共享儲存，而是透過API獲取策略資料，提高了系統的靈活性和擴充套件性。
  • 實時性：可以實現實時的資料獲取和策略更新，只要網路穩定，策略資料可以快速地傳遞到策略執行引擎。

缺點：

  • 穩定性依賴：遠端呼叫依賴於配置管理服務的穩定性。配置管理服務必須保持高可用和高穩定性，否則會影響策略執行引擎的效能。如果配置管理服務不穩定或存在網路問題，可能會導致策略資料獲取失敗或延遲。
  • 網路延遲：遠端呼叫涉及網路傳輸，可能會引入一定的延遲，特別是在網路條件不佳的情況下。這對需要快速響應的場景可能會帶來挑戰。

2.1.3、配置中心

image-20240812135424927

優點：

  • 統一管理：將所有配置資料集中管理，簡化了配置的維護和管理過程。管理員可以在一個地方進行所有配置的修改和管理。

  • 動態更新：支援實時更新配置，策略的修改可以即時生效，無需重啟服務，提高了系統的靈活性和適應能力。

  • 快取機制：許多配置中心實現了快取機制，以提高讀取速度和響應時間，減少對後端儲存的壓力。

  • 分散式架構：透過分散式架構，配置中心能夠處理大量的配置資料，並提供高可用性和容錯能力。

  • 系統解耦：配置中心將配置管理與應用邏輯解耦，應用服務不需要直接訪問資料庫或共享儲存，從而減少了系統之間的耦合度。

缺點：

  • 單點故障：配置中心可能成為系統中的單點故障，如果配置中心出現問題，可能會影響到所有依賴它的服務。需要進行高可用性和容錯設計來減少這種風險。

  • 效能瓶頸：在配置請求頻繁或配置資料量非常大的情況下，配置中心可能成為效能瓶頸，需要對其進行最佳化和擴充套件。

  • 運維成本：高可用性、分散式架構和大規模的資料儲存都可能增加配置中心的運維成本，尤其是在大規模系統中。

3、如何設計配置中心？

3.1、架構圖

image-20240812141812005

3.2、架構分層

分為客戶端層、網路層、服務層以及資料層

3.2.1、客戶端層

  • Client

提供實時配置獲取與更新

  • Admin

提供Web介面用於管理配置

3.2.2、網路層

  • Nginx

流量分發，透過簡單配置檔案來配置後端伺服器列表。當然也可以使用Zookeeper、Eureka等註冊中心，動態地進行服務註冊與發現。

3.2.3、服務層

  • Config Service

提供配置獲取介面

  • Admin Service

提供配置管理介面（配置更新、配置釋出）

3.2.4、資料層

  • Config DB

儲存配置中心與配置相關的資料

  • Admin DB

儲存配置中心與配置無關的資料

3.3、時序圖

image-20240812232041434

其中主要涉及三個部分，分別是啟動部分、推送部分以及配置同步部分。

3.3.1、啟動部分

  • Step 1：啟動配置預熱。在配置中心啟動時，進行預熱，載入零版本資料到本地快取。
  • Step 2：checkUpdateAndLoadData。客戶端攜帶空間ID（namespace）訪問配置中心後端。
  • Step 3：返回最新版本號和配置資料。配置中心返回預熱期間快取的最新版本號和該空間下的配置資料。

3.3.2、推送部分

  • Step 4：checkUpdate（長輪詢）。客戶端將空間ID（namespace）和本地版本號傳送至配置中心，並保持長輪詢以監聽該空間的狀態變化。
  • Step 5：檢測最新版本號（輪詢 + 實時）。透過定時任務輪詢或查詢本地快取，檢測當前請求中的版本號與配置中心的最新版本是否一致。
  • Step 6：版本號不匹配（立即返回）。如果客戶端的版本號與配置中心的版本號不一致，直接返回最新配置的版本號。
  • Step 7：時間輪推進。為了避免“驚群效應”，當配置發生變更時，使用時間輪機制分批推送更新給監聽的客戶端。
  • Step 8：版本號匹配（等待）。如果客戶端的版本號與配置中心的版本號一致，客戶端與配置中心繼續保持長輪詢監聽。
  • Step 9：loadData。當客戶端發現checkUpdate返回的版本號與本地版本不一致時，呼叫loadData介面，並攜帶本地版本號和最新版本號，以獲取最新的配置資料。
  • Step 10：區間版本號配置。服務端使用客戶端提供的本地版本號和最新版本號，查詢快取或資料庫以返回該版本區間的配置資訊。

3.3.3、配置同步部分

  • Step 11：新增、修改或釋出配置，透過配置中心管理平臺的介面進行操作。
  • Step 12：同步通知，將第三方應用的配置修改同步到配置中心。
  • Step 13：同步狀態，配置中心響應狀態並提供對應的配置ID。
  • Step 14：配置釋出，將配置中心返回的ID提交到配置中心，以完成配置釋出。
  • Step 15：釋出結果，配置中心返回配置釋出的結果資訊。

3.4、設計難點

3.4.1、配置中心啟動

場景描述

啟動壓力大。驗證目標是3個namsapce，各10萬條資料量，單條資料2KB，共計600M

image-20240812210046618

問題描述

如果在1秒內，有20臺配置中心例項同時向資料庫請求獲取全量配置，每臺請求的資料量為200M，這樣的高併發請求必然會導致資料庫過載甚至當機。

方案描述

  • 預熱階段：在配置中心啟動後，會經歷一段預熱期。這段時間的長短取決於配置中心中部署的例項數量。為避免資料庫查詢壓力過大，配置中心透過分散式鎖的機制，使各例項依次排隊查詢資料庫，以獲取所需的配置資料。

  • 快取機制：配置中心設計了兩種快取機制：零版本快取和增量快取。零版本快取用於儲存全量配置資料，而增量快取則儲存增量資料。這種設計的原因將在後續內容中詳細解釋。

3.4.2、三方應用啟動

場景描述

1000臺三方應用同時啟動，並在1s內拉取全量配置資料，單臺拉取200m資料。

image-20240812212429445

問題描述

如果1000臺第三方應用同時啟動，並在1秒內每臺都拉取200M的全量配置資料，這樣的高併發請求會對系統造成巨大壓力。

方案描述

  • 本地快取：配置中心會定時或在啟動時將全量配置資料重新整理至“零版本快取”，而在每次配置變更時則會主動重新整理“增量快取”。這樣設計是為了確保配置拉取請求不會直接衝擊資料庫，從而減輕資料庫的負擔。

  • 快取失效處理：在極端情況下，如果本地快取失效，系統會確保每個配置中心例項在同一時間段內僅有一個執行緒能夠訪問資料庫，以避免同時接收大量請求而導致資料庫壓力過大。

3.4.3、配置釋出

場景描述

當新配置釋出時，2000臺第三方應用例項監聽配置變化，需要採取措施避免出現‘驚群效應’。

image-20240812172334386

問題描述

如果同時通知所有監聽配置的第三方應用例項，並且所有應用都訪問配置中心，可能會引發資源競爭，從而導致配置中心效能下降。

方案描述

  • 定時掃描：配置中心例項每30秒掃描一次資料庫，以檢查是否有新的配置更新。當發現最新版本號與註冊的Client版本不一致時，則觸發推送。

  • 配置推送：實現了一個簡易的時間輪機制，每隔100毫秒推送5個第三方應用例項，使2000臺應用例項能夠在40秒內完成推送，實現秒級響應。

3.4.4、快取設計

場景描述

啟動時需要拉取全量資料（零版本），新配置變更推送時需要拉取增量資料（增量）

image-20240812214754178

問題描述

在拉取全量配置資料時，需要根據版本區間進行拉取。例如，當客戶端當前版本為1001時，版本區間為0至1001。如果以版本號作為鍵，每次拉取全量資料時，需要遍歷這些版本號來獲取對應的配置。

方案描述

  • 零版本配置：使用版本區間作為鍵，每小時重新整理一次快取資料，以確保零版本配置與最新版本之間的差距保持在合理範圍內，同時避免增量儲存資料過大。

  • 增量配置：使用版本號作為鍵。每次獲取資料時，透過遍歷版本號來獲取對應的配置。由於版本號數量較少，對效能的影響相對可控，同時由於數量少，儲存時間較短，直接查詢對資料庫的壓力也較小。

4、總結

與Apollo和Qconfig相比，該配置中心更為輕量化。它採用增量更新機制，而Apollo和Qconfig在每次配置更新時都會拉取空間下的全量資料，這在配置量大的場景下可能會導致效能壓力。該配置中心的特點在於支援單條配置儲存量和單個空間下的容量更大，從而更好地滿足大規模配置管理的需求。

5、最後

《碼頭工人的一千零一夜》是一位專注於技術乾貨分享的博主，追隨博主的文章，你將深入瞭解業界最新的技術趨勢，以及在Java開發和安全領域的實用經驗分享。無論你是開發人員還是對逆向工程感興趣的愛好者，都能在《碼頭工人的一千零一夜》找到有價值的知識和見解。

懂得不多，做得太少。歡迎批評、指正。

相關文章