李寧 張軼昀



摘要:該文敘述了一種基于微服務架構的分布式系統雙緩存解決方案,經過實踐,該方案對分布式系統中大數據量參數查詢交易產生了良好的性能提升作用。
關鍵詞:微服務;應用緩存;公共緩存
中圖分類號:TP393? ? ? ?文獻標識碼:A
文章編號:1009-3044(2020)36-0073-02
Abstract: This article describes a distributed system double cache solution based on microservice architecture. Through practice, the scheme has a good performance improvement on the query transaction of a large amount of data in a distributed system.
Key words: microservice; application cache; public cache
前后端分離的設計方案,有效提高了系統的開發效率,同時使得微服務架構中的服務共享成為可能,目前正在成為主流系統開發架構之一。本文基于銀行財會綜合管理系統,討論一種基于微服務架構的分布式系統緩存解決方案[1]。
財會綜合管理系統由公共應用、核算會計、管理會計、預算、估值、合同等十幾個子系統構成。各個子系統均采用前后端分離架構,SpringBoot開發,系統部署及數據庫均相互獨立。為使用戶對分布式無感,所有子系統進行了統一的微服務發現中心地址配置。如圖1所示:前端發起的交易,通過統一網關,交易碼被轉換為微服務識別碼,經微服務發現中心轉發到對應的后臺服務器,后臺響應報文原路反向回傳前端。系統主要使用了擴展的Spring Cloud注解,Eureka服務注冊發現組件(服務注冊發現、服務續約、獲取注冊列表信息、服務下線、服務剔除)、Ribbon負載均衡組件、Feign面向接口調用組件、Zuul微服務應用網關組件、Hystrix斷路器組件、Sleuth全鏈路采集組件、Redis緩存集群以及接口描述組件Swagger。應用系統鏡像使用K8S部署。
除公共應用外,其他子系統均有自己明確的業務屬性及交易特點。公共應用為所有登錄子系統的用戶提供統一鑒權、會話保持、權限控制以及公共參數的取用。公共參數主要包括機構數據、員工數據、用戶數據、財會產品、會計科目、匯率等適用于全平臺的基礎數據。各個子系統與公共應用間存在大量的參數查詢交易。例如財會產品維護時,產品所屬部門、所屬科目數據在子系統僅保存ID號,查詢反顯時需要從公共應用查詢中文名稱。
微服務架構,有效提高了交易的可復用性,但同時增加了網絡損耗。由于財會系統數據量大,運算復雜的特點,大數據量的參數訪問及需要控制用戶權限的數據查詢交易對整體系統的性能提出挑戰。為了改善系統效率,本系統設計并應用了一種雙緩存策略。
所有子系統分別配置應用緩存和公共緩存兩組Redis服務器集群[2]的訪問路徑,每組服務器內部互為三-三主備。應用緩存用于存放子系統私有數據的緩存信息,由子系統自行搭建。公共緩存由公共應用系統搭建,并進行寫入與更新,各子系統僅擁有讀權限。如圖2所示:子系統發起查詢交易時,先訪問應用緩存,如未命中,則訪問公共緩存,仍未命中,才通過面向接口調用組件Feign,發起交易,經微服務注冊中心中轉至公共應用后臺服務。公共應用響應后,如該查詢交易已配置緩存加載,則會將本次查詢內容加載入公共緩存,緩存Key通常使用邏輯數據庫表主鍵或主鍵對。系統使用SpringBoot注解類并進行了擴展,使得緩存加載配置僅需為指定的查詢交易添加@Cacheable注解,指定使用的緩存名以及緩存id。
由于為查詢類交易在緩存未被命中時添加緩存,緩存未被訪問時間超過閾值才清除,可能導致動賬類交易對數據的修改,在緩存失效前無法被重新加載。對于一些熱表數據,可能存在全天駐留緩存的情況,可能產生以下現象:用戶在公共應用系統對機構數據進行了修改,但由于緩存中存在原數據,子系統查詢交易依然返回修改前數據,由此出現緩存臟讀現象。以上情況可以通過兩種方案解決:1)每日批量;2)實時刷新。
為提高緩存命中率,公共應用系統每日批量于每天早上5點進行參數預讀入,先清空緩存,自動發起機構、員工、財會參數等常用數據的查詢交易,進行緩存預加載。此舉不僅可以在系統正式服務時擁有良好的緩存命中率,且可解決緩存臟讀問題。經實測,系統每日8點正式對外提供聯機服務,日常狀態下,雙緩存命中率可達到95%以上。此方法適用于可容忍T+1時效的系統數據。對于實時性要求很高的數據,如匯率,采用實時刷新方式。在修改了該數據的動賬交易結束后強制刷新緩存內容。出于對整體性能的考慮,本系統對交易進行分類,綜合運用了兩種方法。
為系統添加雙緩存后,系統的整體性能有了顯著提高。以4000條用戶權限范圍內的機構數據下載為例(機構視圖表數據量約50萬,每條記錄約50個屬性,大部分屬性需要子表翻譯),添加緩存前,測試環境響應時間約2分鐘,添加緩存后同環境響應時間降至20s以內。
參考文獻:
[1] 黃向平,彭明田,楊永凱.基于內存映射文件的高性能庫存緩存系統[J].電子技術應用,2020,46(7):113-117,126.
[2] 寧方美,賀雪梅,牟晉娟.SpringBoot集成Redis緩存技術在企業一卡通系統中的應用[J]. 電子技術與軟件工程,2019(24):133-134.
【通聯編輯:唐一東】