9月3日“成都發布”訊息稱，9月1日，成都市新型冠狀病毒肺炎疫情防控指揮部發布《關於在全市開展全員核酸檢測的通告》，決定自9月1日至9月4日在全市範圍內開展全員核酸檢測。9月2日晚，核酸檢測系統出現異常，導致取樣排隊時間過長，核酸檢測進度緩慢，給市民群眾帶來困擾和不便。

無獨有偶，9月3日12時許，貴州省核酸檢測系統出現異常，導致使用者無法登入。當日16時起，貴州省核酸檢測系統逐步恢復。雲上貴州大資料公司釋出資訊表示歉意，並將以此為鑑，全力改進工作。

頂象業務安全專家認為，核酸檢測系統崩潰的技術原因很多，網路頻寬、雲服務穩定性和資源擴充套件性、應用系設計、資料庫效能以及運維能力都可能影響系統服務。“使用者最能直觀感受到的一個服務節點。當服務頁面出問題後，最先想到的就是應用系統，其實像網路頻寬、負載均衡、CDN、資料庫效能、運維繫統等基礎設施和運維能力，都會影響到使用者的直接體驗。”

頂象業務安全專家建議，應用上線前，企業和單位需要做好應用的容量評估和規劃、效能壓測以及全鏈路壓測，並制定好故障應急處理流程機制。同時，在運維服務上，儘量選擇原廠背後的研發和架構團隊做支援。

核酸檢測系統的載入過程

成都、貴州等地核酸檢測系統頻陷崩潰，背後的技術原因會有多種可能。因為應用系統上線執行後，影響系統效能的環節會非常的多。從技術視角看，使用者的一個url請求到後臺服務，中間要經過多個環節，過程非常複雜。

1、請求發起。瀏覽器發起url請求、DNS解析、和服務端建立TCP連結、HTTPS協議認證、壓縮資料並進行網路傳輸、接收到結構進行頁面渲染

2、網路傳輸。網路節點路由、資料包封包/拆包、安全防火牆規則和限制、負載均衡/代理服務

3、系統服務。身份驗證/許可權控制、業務系統、其他依賴的各類應用服務

4、資料儲存。快取、資料庫、訊息佇列、檔案等。

可以看到，使用者的請求要到達業務系統要經過多個環節，每一個環節都涉及效能上的問題，每一個環節又都有各自可最佳化的點。

例如，前端發起請求的最佳化，從瀏覽器發起url請求，涉及瀏覽器對域名請求併發數限制、js/css/圖片等請求檔案大小、請求內容的CDN加速、請求內容的瀏覽器快取等。現在大多瀏覽器都自帶開發者診斷工具，可以有針對性的去做效能定位，下圖展示了使用者的請求情況和單個請求的timing耗時。

核酸檢測系統“崩潰”的技術原因分析

上面提到的四個流程環節都涉及效能最佳化，每個環節的快與慢都可能影響到使用者的直接體驗。核酸檢測應用系統出現訪問慢、崩潰等情況，可以在以下幾方面查詢原因。

1、網路頻寬。可以類比請求資料傳輸的高速公路，碰到國慶/春節假期高速免費通行，就可能出現堵車的情況，影響出行速度。對應用系統來說，使用者訪問量激增，如果網路頻寬不夠，也會出現網路擁堵，影響頁面的載入速度，表現出來的就是頁面載入不出來或頁面載入出錯。

2、雲服務平臺/基礎設施的穩定性和效能。現在雲端計算服務大範圍普及，應用都執行在公有云或私有云上，會使用到雲伺服器、負載均衡、CDN、雲端儲存、流量頻寬等雲服務。雲服務平臺作為基礎設施的提供方，提升了應用開發部署和運維的效率和降低了運營成本。

一方面，雲服務提供方要保障基礎設施的穩定性，基礎設施出現問題，會影響的業務系統的穩定性；另一方面，雲服務使用方也要合理地採購雲服務資源，避免資源不足影響業務系統的正常使用。

3、應用系統自身設計和效能。系統的設計的大框架，決定了應用系統的效能和穩定性。例如，技術上調侃的二維碼掃描，如果請求響應傳輸的就是二維碼圖片，這種設計就必然限制了介面的效能（一般傳輸文字即可，文字的資料包文大小遠遠小於圖片）。還有就是應用的部署結構，分散式叢集部署的穩定性必然好於單點部署應用，應用系統上線前也要做好效能測試。

4、資料庫的效能。資料庫的效能會影響到應用系統的效能，應用系統的資料查詢、寫入會依賴下面的資料庫，比如資料庫出現慢查詢就會導致頁面查詢變慢。資料庫技術比較成熟，一般都會配合快取使用，提升資料查詢的效能。

5、運維繫統和能力。運維在應用系統的生命週期中會佔到70%以上的時間，高質量的運維繫統和服務，能保障應用系統的效能和穩定性。例如故障前的容量管理、預警、巡檢、演練、日誌管理，故障中的處理機制、oncall、告警、定位和預案執行，故障後的覆盤總結、改進措施的落地閉環。相信只有在日常運維上做好了充分的準備，在面對故障問題時才能做到及時快速地處理。

應用系統效能和穩定效能力要求

可以看到，應用系統只是使用者最能直觀感受到的一個服務節點。頁面出問題後，最先想到的就是應用系統，其實像網路頻寬、負載均衡、CDN、資料庫效能、運維繫統等基礎設施和運維能力，都會影響到使用者的直接體驗。

以頂象風控系統（實時決策引擎）為例，看下頂象風控系統在設計和實施時，對系統效能和穩定性上的能力要求（PS：頂象風控系統在效能和穩定性上，支援TPS>5w的叢集部署，平均rt<100ms，採用分散式叢集部署，支援分鐘級系統預警和線上水平擴充套件）。

設計原則

應用系統的架構設計，要採用分散式設計、叢集化部署。

採用微服務架構，無狀態設計。

功能內聚，模組化、元件化設計。

面對大流量高併發場景下，要具備一定容錯性，有降級保護機制。

動態內容和靜態內容分離，靜態內容放到CDN，加速訪問。

具備可擴充套件性、可運維性。

部署結構

支援DMZ區、業務區、資料庫區、內網區的部署結構，滿足網路隔離要求。

支援多機房容災備份。

支援動態請求代理轉發、靜態內容CDN託管。

應用系統部署，無狀態化，可隨時增減節點。

可擴充套件性

支援配置化、指令碼化對接訊息佇列（kafka、rabbitmq），無需開發，配置即生效。

支援配置化、指令碼化對接其他系統api介面，便於在策略中使用。

支援配置化、指令碼化對原始業務引數進行轉換處理。

支援自定義策略和規則、自定義外部關聯資料等各種衍生變數。

日誌格式化，支援同步到業務系統或大資料平臺。

支援sso對接和二次開發。

支援自定義角色、許可權、背景圖和LOGO的替換。

支援請求由業務系統路由轉發。

可運維性

容器化部署和叢集管理，支援快速線上水平擴縮容。

具備系統監控告警功能和機制，對伺服器資源、網路狀況、API呼叫、中介軟體等效能情況進行監控告警。

具備灰度釋出功能和機制，分別從應用級、功能級進行灰度釋出管理。支援策略灰度上線、上線前進行真實資料試跑和調優。

具備安全管理機制，可針對不同渠道、部門和人員進行許可權控制，實現風控策略和執行資料的隔離，並且對策略的變更有版本記錄和稽核控制。

最後，關於運維，有幾點需要特別強調：

1、儘可能採用原廠運維，在運維服務支援上，原廠人員更熟悉，處理技術問題有原廠背後的研發和架構團隊支援。

2、上線前評估和壓測，任何應用系統上線，都需要做好上線前容量評估和規劃（預估請求量和併發量，準備相應機器資源，留足冗餘量）、效能壓測（穩定性壓測和極限壓測，為應對短時大併發量做好極限壓測，瞭解系統的效能上限），以及全鏈路壓測（評估整個業務鏈路上的效能短板）。

3、故障問題處理閉環，定製好故障應急處理機制，從問題預警、進展同步、定位處理，到事後覆盤、措施的落地和驗證，整個處理閉環做到位，避免問題重複出現。