😊你好,我是小航,一個正在變禿、變強的文藝傾年。
🔔本文分享【系統架構師】2025論文《系統可靠性設計》,期待與你一同探索、學習、進步,一起卷起來叭!
目錄
- 項目介紹
- 背景介紹
- 系統模塊
- 技術棧
- 性能優化技術
- 摘要
- 正文
項目介紹
背景介紹
- 時間:2021年3月啟動,2022年3月上線
- 參與方:我單位與某省公安廳聯合研發
- 目標:解決數據全生命周期(存儲/傳輸/使用/共享)安全問題
- 核心價值:通過性能優化保障系統高并發處理能力
- 用戶群體:省市縣三級公務員
系統模塊
模塊名稱 | 功能描述 |
---|---|
資源模塊 | 數據源管理(Oracle/Flink/Spark/文件),支持數據接入、導出及脫敏任務調度 |
敏感屬性模塊 | 自動發現敏感字段,支持自定義敏感屬性與人工復核 |
脫敏規則模塊 | 策略組合配置(含算法版本控制),支持DES/AES/RSA/遮掩/移位等原子脫敏算法 |
脫敏模塊 | 執行可逆/不可逆脫敏,支持同步/異步任務處理 |
權限模塊 | RBAC權限控制(省市縣三級用戶角色分級) |
審計模塊 | 操作日志記錄與合規審查 |
技術棧
- 核心框架:Spring Cloud
- 緩存中間件:Redis(LRU淘汰策略)
- 數據庫:Oracle/Neo4j/Spark + RAID6固態硬盤陣列
性能優化技術
2.1 負載均衡技術
技術組件 | 實現方案 | 效果 |
---|---|---|
Nginx集群 | 前置反向代理+路由模式隔離內外網 | 支持1000+并發連接 |
最小連接算法 | 動態分配請求至空閑節點 | 提升資源利用率30% |
故障轉移 | 自動隔離異常節點 | 服務可用性達99.9% |
2.2 緩存技術
- 緩存策略:
- 數據類型:脫敏規則/用戶登錄信息/字典配置
- 淘汰機制:LRU(最近最少使用)
- 一致性保障:讀時回填、寫時淘汰
- 性能提升:
- 數據庫訪問量減少60%
- 頁面加載時間縮短至200ms以內
2.3 數據庫優化
優化措施 | 技術實現 | 性能指標 |
---|---|---|
主從復制 | 一主三從架構,讀寫分離 | 寫壓力降低70% |
RAID6陣列 | 固態硬盤+雙盤容錯 | 隨機讀寫IOPS提升4倍 |
連接池管理 | 封裝讀寫分離連接池 | 事務響應時間≤50ms |
摘要
2021年3月,我單位聯合某省公安廳研發《數據脫敏管理系統》。系統以數據脫敏功能為核心,分為資源模塊、敏感屬性模塊、脫敏規則模塊、脫敏模塊、權限模塊、審計模塊。在項目中,我擔任系統架構師職務,負責架構設計工作。
本文以該系統為例,主要論述了web技術性能優化在項目中的具體運用。著重介紹負載均衡技術、緩存技術以及數據庫主從部署三種技術。通過負載均衡技術結合服務器集群,提高系統的并發能力;緩存技術基于redis內存數據庫,降低系統數據庫壓力,提高數據脫敏速度;數據庫主從部署實現讀寫分離,極大緩解了數據庫的負載瓶頸。最終項目成功上線,獲得用戶一致好評。
正文
筆者在一個專為政企建設信息系統的集成商任職,過往成果有《某省廳網技綜合平臺》等。2021年3月,我單位聯合某省廳研發了《數據脫敏管理系統》項目(以下簡稱“系統”),解決了數據在其生命周期的傳輸、存儲、使用、共享環節的安全問題,保護了數據安全性和可用性。系統以數據脫敏功能為核心,主要分為資源模塊、敏感屬性模塊、脫敏規則模塊、脫敏模塊、權限模塊、審計模塊等。資源模塊主要負責識別和維護所有需要進行數據脫敏的數據源,支持用戶根據需求接入和導出數據至不同數據源(如oracle、neo4j、spark源、文本文件等),并負責將抽取的數據發送到敏感屬性模塊進行屬性分析;敏感屬性模塊負責自動發現數據中的敏感字段,支持用戶自定義敏感屬性等;脫敏規則模塊根據不同敏感屬性,靈活組合不同脫敏策略,并做好版本控制;數據脫敏模塊按用戶指定或預定義脫敏策略,對數據實施可逆、不可逆脫敏;權限模塊主要是系統安全管理員定義不同角色對應不同模塊的權限,對省市縣三級用戶實行權限控制;審計模塊用于安全審計員對系統操作的監督核查。在這個項目中,我擔任系統架構師的職務,主要負責系統的架構設計相關工作。
系統需要支撐省廳所轄公務員對數據的脫敏,為保證系統的性能和可靠性,對系統進行性能優化顯得尤為重要。傳統的基于單塊架構的數據脫敏管理系統早已無法支撐日益增長的用戶需求,存在嚴重的性能問題,且很難進行擴展,因此該系統在架構設計中必須考慮到Web應用系統性能優化技術的應用。常見的性能優化策略有:1.負載均衡技術。通過請求轉發、監測異常實例、服務故障轉移、自動隔離異常主機保障服務高可用性。通過添加實例至服務集群的方式,提高系統的可擴展性。通過負載均衡策略實現流量均衡;2.緩存技術。通過將讀寫比很高、很少變化的數據寫入緩存中,能夠起到減少數據訪問時間和計算時間的作用,同時能夠降低數據庫訪問壓力;3.數據庫主從部署技術。使用一主多從,實現讀寫分離,減輕主庫訪問壓力,同時防止單一主機的數據丟失,提高數據安全性,還能讓不同從庫使用不同存儲引擎,以適應不同的應用需求。
系統分為前端web服務、平臺保障服務、業務服務,在開發過程中,我們運用了多種性能優化技術。這里重點以負載均衡技術、緩存技術、數據庫主從部署為例,介紹本系統Web性能優化的方案和達到的效果。
-
負載均衡技術。前端web服務主要提供給用戶可使用的界面,分為前置nginx負載均衡服務器、前端網站Nginx集群。當用戶通過網絡訪問系統時,首先會訪問到前置的Nginx負載均衡服務器,負載均衡服務器會將請求轉發到前端網站的Nginx集群,前端網站通過發起http請求來和后端交互,具體是通過Ajax方式來調用后端REST API接口。用戶訪問網站通過前置的nginx負載均衡服務器來轉發到前端網站集群,以起到將用戶請求進行分流的作用。當前端網站集群中的部分服務發生故障時,系統仍可正常地對外提供服務。前置nginx負載均衡服務器使用軟件反向代理的方式來實現負載均衡,部署為路由模式,系統內部網絡與外部網絡分屬于不同的邏輯網絡,以實現系統內部與外部網絡的隔離,保護系統安全。在負載均衡算法選擇上,為了實現連接最優分配,使用了最小連接法,每當用戶請求來臨時,任務分發單元會將任務平滑分給最小連接數的節點,這樣的架構以廉價、透明的方式擴展了服務器和網絡帶寬,能夠極大提升系統的并發量,同時保證前端整體的穩定性和可靠性。
-
緩存技術。通過對系統業務的分析,發現后端業務服務在進行相關的業務邏輯操作時,存在一部分數據使用頻率很高但不會經常變化,如系統基本設置信息、用戶登錄信息等。這一部分數據如果每次使用都直接請求數據庫,將會給數據庫服務帶來非常大的開銷。為了解決這一問題,我們選擇了redis作為緩存數據庫,采用LRU緩存淘汰策略。在系統啟動時,將脫敏規則從專用數據庫中讀出并緩存在redis中,用戶登錄時,也會將登錄信息緩存在redis中,當服務再次使用到這部分信息時,便可直接從效率更高的redis中讀取。對于部分在一定時間內不會變化的數據,如脫敏字典信息、敏感屬性配置信息、脫敏策略信息、頻繁脫敏的數據表等,也進行緩存。為了解決數據庫和緩存一致性的問題,當讀取數據時,會先讀取redis緩存的數據,如果redis緩存不存在所要的數據,則從原數據庫中讀取,并將數據同步更新到redis緩存;當寫回數據時,將數據直接寫入到數據庫中,并同步淘汰緩存中的數據。通過緩存技術,極大地提升了系統的性能,并且緩解了頁面加載緩慢的問題。
-
數據庫主從部署技術。系統使用緩存后,大部分讀操作都可直接通過緩存完成,但仍然有部分讀操作(未命中或緩存過期)和全部寫操作需要訪問數據庫。當系統用戶達到一定規模后,數據庫因負載壓力過高而成為整個系統瓶頸。對于數據脫敏系統來說,后端數據庫存儲的性能是極其重要的,所有用戶的操作記錄,所用脫敏字典策略(周期更新),部分脫敏后的數據(大部分脫敏數據對接到其他系統存儲處理)都存儲在數據庫中。這里要求數據庫讀寫有非常強的性能,考慮到業務讀多寫少,為了解決數據庫的讀性能瓶頸,本系統采用主從式部署數據庫,實現讀寫分離架構。業務數據在寫數據時,訪問主數據庫,主數據庫通過主從復制機制將數據同步更新到從數據庫,當業務服務需要讀取數據時,就可以通過從數據庫獲得數據。業務服務通過使用專門的數據持久層訪問模塊(封裝了讀寫連接池,讀連接池能夠實現故障自動轉移)來訪問讀寫分離后的數據庫,使數據庫讀寫分離對應用透明。為了緩解由磁盤硬件帶來的性能瓶頸,數據庫所依賴的硬件存儲采用raid6的固態硬盤陣列,能夠在硬件方面提升數據庫的隨機讀寫性能。通過主從數據庫設計,提高數據庫的運行效率。
在這次系統性能優化設計中,還使用了很多性能優化策略,如使用消息隊列進行削峰,使用hystrix組件實現服務降級等,這里就不再一一贅述。系統經過性能測試、負載測試、壓力測試、穩定性測試后,自2022年3月上線已運行三年有余,在數據生命周期的存儲、傳輸、使用和共享環節投入使用,截至目前已脫敏3萬余次,脫敏數據量達到103T,獲得了單位領導同事和客戶的一致好評。日常使用過程中最高出現過300余用戶同時進行脫敏的情況,基本未出現請求超時,拒絕服務的情況,滿足了數據脫敏系統的基本性能需求。
實踐證明,數據脫敏系統順利上線,并且穩定運行,與系統采用了充分的性能優化設計密不可分。經過這次數據脫敏系統性能優化方法的實施,我也看到了身上的不足之處,在未來還會不斷更新知識,積累經驗,完善本系統各方面的設計,在下次實施中使整個系統更加好用,更好的為用戶服務,為社會服務。
📌 [ 筆者 ] 文藝傾年
📃 [ 更新 ] 2025.5.15
? [ 勘誤 ] /* 暫無 */
📜 [ 聲明 ] 由于作者水平有限,本文有錯誤和不準確之處在所難免,本人也很想知道這些錯誤,懇望讀者批評指正!