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