假如我是核酸系統架構師，我會...
開發一個不崩潰的核酸系統到底難不難 ？
這篇文章，勇哥想象自己是核酸系統架構師，談談自己對核酸系統的理解。
1 明確系統邊界
作為架構師，首先需要明確系統邊界。
核酸檢測核心流程：
- 醫護人員打開核酸系統的手機端應用，錄入試管編碼 ;
- 醫護人員掃描居民的健康碼；
- 醫護人員采集咽拭子標本 ；
- 檢測結束之后，醫護人員將檢測標本送至檢測中心；
- 檢測中心將檢測結果提交到核酸系統，然后核酸系統會將核酸結果同步到健康碼系統。
成都核酸系統崩潰時，流程阻塞在步驟一和二。
本文里我們提到的核酸系統，也就是指醫護人員使用的系統。而核酸檢測系統會將檢測結果同步到健康碼系統 , 健康碼系統面向的是大眾居民 , 是高頻場景。
對于成都市居民來講，與他們關系最為密切的就是兩套系統。
- 核酸系統：核酸醫護人員使用 , 東軟負責開發和維護；
- 天府健康通：廣大市民使用，騰訊研發和維護。
2 崩潰疑云
核酸系統軟件是屬于政府購買 (TO G)，市民使用 (TO C) 。
核酸系統是一個多方協作的系統，它不僅直接和政府有關系，還涉及到多個廠商，一個系統工程背后，除了系統集成商之外，包括多個分包商。比如西安的一碼通，曾集結了電信、東軟、美林和安恒等公司。
正因為這套系統涉及面之廣，當成都核酸系統崩潰時，我們需要冷靜下來，縷清條理。
我們先從基礎設施層的維度來分析，很多互聯網公司會將自己的服務部署在阿里云或者騰訊云，部署方便，也可以動態擴容。
那么核酸系統部署在哪里呢？假如核酸系統是以 SAAS 形態部署（東軟自建機房，或者東軟采用阿里云/騰訊云服務），那么成都核酸崩潰事件，東軟必然脫不了干系 。但東軟隨后硬氣的發了公告：
系統上線后，發現有響應延遲、卡頓等現象，東軟集團第一時間組織專家組和堅守現場的公司技術人員，與成都市相關部門一起，排查事故原因，強化安全防護，保證系統運行。據技術專家研判，目前出現的系統響應延遲、卡頓等現象與核酸檢測系統軟件無關。9月3日零點左右，在進行網絡調整之后，系統運行平穩順暢，效率得到極大提升，當日共完成1200萬樣本采集量。
假如核酸系統沒有問題，會不會是網絡問題呢？
成都核酸系統奔潰時，醫護人員以為是信號問題，紛紛舉起手中的手機，捕捉信號，而排隊的市民卻可以刷抖音，頭條。
9月3日下午4點32分，四川省通信管理局發文稱，“全市通信網絡運行平穩，各核酸檢測點移動網絡覆蓋良好，沒有出現網絡擁塞和故障?！?/p>
我們基本可以做出判斷：成都核酸系統部署在政務云，也就是政府部門提供基礎設施 ，應用開發商將軟件部署在政務云機房里 。
核算系統崩潰的可能原因：
- 政務云機房問題
網絡問題（負載均衡，帶寬，防火墻）, 或者機房服務器出現故障； - 核酸系統軟件問題
核酸檢測軟件確實承載能力有限，軟件崩潰了。
3 應用層設計
核酸系統是屬于高并發應用嗎？這里我們做個估算：
- 人口估算法：
據統計成都市人口2千萬多人，假設集中在6小時內做核酸，平均每小時支持的并發人數是3531666。每秒支持的并發約為1000。基于檢測人員的集中度不均衡的因素，假設高峰期是平均并發的2-3倍。則每秒并發“核酸登記”2000-3000左右。
- 檢測點估算法：
今年5月份，上海抗疫期間一共有 15000 + 核酸檢測點 ，我們假設成都有和上海一樣多的核酸檢測點。市民在排隊核酸檢測時，核酸醫護人員掃居民健康碼的時間間隔在10秒到15秒之間，每個核酸檢測點并行兩排檢測通道，那么每秒并發“核酸登記”也是在 2000-3000 左右。
通過兩種估算方法，我們發現：核酸系統的請求并發度并不高。
雖然并發度不高，但每天的業務數據條數量級較高 ，按照東軟的公告，每天可以完成1200萬核酸樣本采集。
假設核酸檢測記錄一天1000萬條數據，一周就有7000萬條，1個月就能達到3億條數據。那么勢必要使用分庫分表。
- 醫護人員掃市民的健康碼 ，核酸登記的請求發送到 api 網關 , api 網關將請求轉發到核酸系統；
- 緩存存儲檢測點，檢測批次等基礎信息，核酸系統通過緩存判斷業務請求是否合法，若合法，則組裝真正的入庫的數據；
- 核酸系統調用分庫分表中間件將數據插入到數據庫 。
看起來，核酸系統的架構設計還是比較簡單清晰的，核心點在于用分庫分表硬擋高流量訪問。
但現在這種模式就完美了嗎 ?
我們舉湖北鄂通碼舉例，核酸登記后，健康碼在 10~20 分鐘狀態會修改成綠色并標識成：核酸已檢測，也就是核酸已檢測的狀態會異步同步到健康碼服務。
我們不由得想到了消息隊列 MQ ，MQ 最大的優勢在于：異步和解耦，MQ 模式還有一個優點：當流量激增時，消息隊列還可以起到消峰的作用。
MQ 方案里，核心流程如下：
- 醫護人員掃市民的健康碼 ，核酸登記的請求發送到 api 網關 ，api 網關將請求轉發到核酸系統；
- 緩存存儲檢測點，檢測批次等基礎信息，核酸系統通過緩存判斷業務請求是否合法，若合法，則組裝真正的入庫的數據；
- 核酸系統將檢測記錄發送到消息隊列，返回給前端響應成功；
- 消費者接收消息后調用分庫分表中間件將數據插入到數據庫 ；
- 消費者接收消息后同步狀態到健康碼服務。
在架構設計中，并不是引入了組件就完事了，更需要考慮如何精準的使用組件。
比如，使用消息隊列 kafka ，如何保證不丟消息，如何保證高可用。使用了分庫分表中間件，是不是需要考慮數據異構，以及冷熱分離等。
4 監控平臺
我們經常講：研發人員有兩只眼睛，一只是監控平臺，另一只是日志平臺。
在對性能和高可用講究的場景里，監控平臺的重要性再怎么強調也不過分。
一、基礎運維監控
基礎運維監控負責監控服務器的 CPU、網絡、磁盤、負載、網絡流量、TCP 連接等指標，并且通過設定報警閾值實時通知指定負責人。
基礎運維監控
我們在基礎設施層這一節里提到：
核酸系統崩潰時，成都政務云不能提供暢通的核酸檢測服務 , 可能原因之一是政務云機房問題。
當政務云機房出現問題時，基礎運維監控可以幫助運維人員更快的發現問題，并制定解決策略。
二、應用系統監控
應用系統監控是研發人員接觸最多的一種監控類型，系統出現瓶頸的時候，應用系統監控會有最直觀的體現。
筆者一般會關注性能監控，方法可用性監控，方法調用次數監控，JVM 監控這四大類。
- 性能監控
性能監控
性能監控不同時間段性能分布，實時統計 TP99、TP999 、AVG 、MAX 等維度指標，這也是性能調優的重點關注對象。
- 方法調用次數監控
方法調用次數監控可以按照機器，時間段分析接口或者方法的調用次數，當大流量來襲時，可以清晰的看到請求的波動。
- 方法可用性監控
方法可用率監控
方法可用性監控是指：當接口被調用或者方法被執行，可能返回異?；蛘叻椒▓绦袙伄惓＃治鲈摲椒ㄊ欠裾{用正常，當系統出現嚴重問題時，方法可用率是一個重要的參考指標。
- JVM 監控
JVM 監控
JVM 監控是 JAVA 工程師特別關注的監控類型，我們會重點關注：堆內存，GC 頻率 ，線程數等等。
三、業務監控
業務監控功能是從業務角度出發，各個應用系統需要從業務層面進行哪些監控，以及提供怎樣的業務層面的監控功能支持業務相關的應用系統。
具體就是對業務數據，業務功能進行監控，實時收集業務流程的數據，并根據設置的策略對業務流程中不符合預期的部分進行預警和報警，并對收集到業務監控數據進行集中統一的存儲和各種方式進行展示。
比如訂單系統中有一個定時結算的服務，每兩分鐘執行一次。我們可以在定時任務 JOB 中添加埋點，并配置業務監控，假如十分鐘該定時任務沒有執行，則發送郵件，短信給相關負責人。
5 多方協作
很多同學都指責東軟失職：“核酸系統在倉促上線之后，到底有沒有進行完備的性能測試 ”。
確實，性能測試非常重要 ，通過壓測可以知道系統的極限值是多大，當系統承受不住訪問時，就會暴露出瓶頸，如服務器 CPU、數據庫、內存、響應速度等，從而促使研發團隊進行再優化。
這里我們先按捺指責的沖動，核酸系統是一個多方協作的系統，它不僅直接和政府有關系，還涉及到多個廠商，一個系統工程背后，除了系統集成商之外，包括多個分包商。
《核酸檢測系統崩潰，東軟該不該背鍋？》這篇文章提到：
原則上，監督管理部門要把所有廠商叫在一塊協同作戰。但沒有頂層統籌的強壓之下，廠商之間的溝通和協調很難達成。大多數情況之下的壓測，各個廠商有點“各自為政”的意思。一般，軟件廠商會自己測試自己，鮮少幾家聯合起來測驗?！安煌瑥S商坐在一起的時候，大家都覺得自己沒有問題，都會覺得是別人的問題。理由也會一致，我們的系統在別的地方跑過，沒出岔子"。甚至應對這一局面，各家的心思都極為微妙?！懊總€廠家在系統上的投入都是一筆不菲的開支，在應急狀態之下，如果上面領導沒表態，也沒明確是公益性質還是有償的付出，廠家相應選擇也是謹慎的?！? 因此大多數情況之下的壓測，各個廠商有點“各自為政”的意思。一般，軟件廠商會自己測試自己，鮮少幾家聯合起來壓測。
這篇文章的一個觀點，“這是技術層面之外，一個城市應急預案的管理能力問題?！? 我深以為然。
6 總結
假如我是核酸系統的架構師。。。。
- 我會使用消息隊列 + 分庫分表來最大程度提升系統的吞吐量。
- 我會在使用消息隊列中間件的時候，重點關注如何不丟失消息，消息系統如何做到高可用。
- 我會使用分庫分表中間件時，重點關注冷熱分離，如何將數據異構到數據倉庫。
- 我會在政務云部署監控系統，提供基礎運維監控，應用系統監控，業務監控的能力，當系統出現問題時，團隊可以以最快的速度發現問題，并解決問題。
可是，核酸系統是一個多方協作的系統，我們不僅需要和政府溝通，也需要和眾多三方廠商協作。
也許，當我提出需要更多服務器預算時，政府部門的預算并不充足，或者就算充足了，走流程也要一個月的時間；
也許，當我提出需要部署監控系統，公司會以人力不足為由或者政務云硬件資源不足，否定我的方案；
也許，當我聯調時發現一個三方接口速度慢，排查起來（溝通成本）需要 4-7 天時，我也不得不沉浸在瑣事中；
直到最后，當系統崩潰時，我也只能嘆息到：“尊重技術，尊重專業”。
