針對前幾天某省份健康碼和核算檢測系統出現并發性的問題，總結了一下自己的想法：
在需求方面，梳理了以下三個點：
（1）在一個頁面展示某個人的健康碼狀態和最近若干次的核算檢測結果，每個人的健康碼狀態由大資料系統定期生成，核酸檢測結果也是在每次結果出來時由核酸檢測系統錄入；
（2）健康碼和核算檢測結果的展示為高頻讀取操作，在每個人進入商場、地鐵、公交、小區等地方都需要展示；
（3）健康碼狀態生成與核酸檢測及結果錄入屬于平時低寫入、高可靠類需求，只有在大資料系統計算出健康碼或有核酸檢測時才會寫入，但寫入結果要確保可靠，
在上述政企類需求中，一般對資料安全要求較高，很多核心業務和資料都需要部署在自己的私有云上，但是對于對健康碼和核算檢測結果展示屬于高并發類的需求，只要做好對資料的安全控制，是可以將部分讀業務部署在公有云的，因此，我的想法是：充分利用公有云的彈性擴展能力和私有云的安全要求，采用公私云結合的方式來設計整體系統，
1、架構設計
在安全性方面，除了常用的安全機制外，存盤在查詢系統中的資料均是加密資料，而且是每個用戶一個獨立秘鑰，資料在從發送至公有云之前加密，在用戶讀取之后進行解密，資料本身在公有云以及整個公網傳輸程序中全程加密；另外，用戶標識不可使用用戶身份證，而是系統產生的內部ID，
在性能方面，架構設計時將整個系統分為查詢系統和資料生成系統兩部分，查詢系統應對個人的高頻訪問，部署在公有云中，例如阿里云，騰訊云等；充分利用公有云的彈性資源；資料生成系統用于健康生成及核酸檢測與結果的錄入，主要部署在私有云或私有機房中；查詢與資料生成兩類系統之間通過同步機制完成資料同步，實作兩類系統之間的隔離；在用戶端可選支持多域名選擇策略，多云同時提供服務，不同用戶可基于選擇策略可接入不同廠商的公有云中，如下圖1所示：
圖1、公私混合云的系統架構
在該混合架構中，資料同步采用實時同步和定時同步兩種機制協同的方式，實時同步主要針對某個用戶的健康碼發生變化、產生了新的核酸檢測結果等場景；定時同步可每天將全量用戶更新至查詢系統中，根據過往的經驗，再可靠的實時同步都是不可信的，最終都得加上全量同步來兜底，其架構如下圖2所示：
圖2、查詢系統內部架構
在查詢系統中，包含接入網關、查詢微服務、Redis快取集群、可選的備份資料庫和資料同步客戶端，接入網關獲取請求的用戶ID，并將同一用戶的資料路由至同一查詢服務；在查詢微服務中，采用兩級快取機制，在兩級快取中，查詢服務內部快取2小時內的用戶資料，當有新請求過來時首先查詢記憶體快取，如果記憶體快取中不存在，則訪問Redis快取集群，查詢微服務通過過期逐出和超量逐出機制洗掉微服務記憶體中的資料；Redis集群可采用其原生的Cluster也可以在查詢服務中自己實作集群管理，資料同步服務客戶端用于接收同步資料，并將其放入快取；如果采用資料庫作為資料備份，則Redis主從均無需開啟持久化，否則將從實體開啟持久化；在該架構中，整個資料訪問全部由快取提供資料服務，不使用資料庫，以便最大程度提升資料訪問效率，其架構如圖3所示：
圖3 查詢服務設計思路
上述資料在程式內部或Redis快取中均采用鍵值對方式存盤，其中：
- Key為用戶標識，用戶標識是在登錄成果后由賬號及權限系統回傳，不是用戶的身份證；
- Value是一個加密后生成的字串，加密物件為JSON物件，包含以下資訊：
（1）健康碼的狀態；
（2）每次核酸檢測結果的資訊，例如：
1）檢測時間：UNIX時間戳；
2）檢測結果：1：陰性；2：陽性；
3）檢測單位：限制單位字串長度不可超過250個字符；
上述思路也可以擴展至單獨訪問核算檢測結果，例如：核酸檢測結果串列單獨顯示時，也可以采用該思路實作，
二、資源預估
本文所述架構在公有云中的資源申請估算情況如下：
以如下資料量為例：每個用戶2KB，key為8位元組純數字，按照用戶量3千萬；訪問QPS：10萬/秒，
所需Redis快取10個Redis實體，采用主從部署，每個實體16G記憶體；計算方法為：
（1）直接快取空間：2KB* 3000 0000 = 60GB;
（2）單個Redis快取承擔12GB資料，Redis實體記憶體16GB；
（3）主實體數：5個，備份實體數5個；
所需查詢微服務的配置及數量：2核4G記憶體 ，20個；網關微服務：4核4G記憶體，10個；賬號權限系統及LB另算，資料庫可選配置，
三、運維機制
在上線生產環境之后，應增加相應的運維機制，包括
（1）彈性擴容策略，在公有云中配置微服務、網路的自動擴容策略；對于網路流量，公有云可提供按量收費，采用這種方式比較好，
（2）告警機制，在公有云要配置各微服務實體、快取、網路的告警機制，在壓力增加時及時告知相關研發及運維人員，短信告警最好設定多級，例如CPU利用率持續30分鐘超過70告警一次，持續10分鐘超過80%告警一次，持續5分鐘超過90%一次；
（3）日巡檢機制，每日巡檢各服務的運行狀態、例外日志，并每周分析系統資源使用趨勢，以便對資源做提前擴容；另外，盡量依靠人工擴容，不要依賴平臺的自動彈性擴容機制，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/398648.html
標籤：其他
上一篇：GRE協議