???

【51CTO.com原創稿件】西安一碼通不到一個月就崩潰兩次，雖然說在實際項目和線上運行時系統崩潰是很有可能遇到的問題，但是如此大規模的，而且還是短時間內兩次大規模崩潰，著實少見。那么如果回到未來，該怎么設計一碼通來降低崩潰的情況呢?下面從技術和業務兩方面來談談一碼通的設計。

一、崩潰的原因分析

因為這兩次崩潰的模塊只是掃碼和亮碼，因此我們來分析一下這兩個模塊的業務。掃碼和亮碼功能類似，都是典型的查詢大于更新的業務，大部分流量都來自于查詢。下面我們來看看一碼通在不同版本的發展。

第一版的一碼通只展示個人身份證號、姓名和碼的顏色。這三個字段有可能是存儲于一個表中，使用一條 SQL 就能查出來。但是作為一個上萬人使用的系統，不可能所有數據存在于一張表中，因此身份證號和姓名極有可能存儲在一張表里，碼的顏色在另一張表中，因此這里很有可能最少存在一條 join 連接。

到了第二版和第三版一碼通做了很大的改變，首先是新增了疫苗接種信息，其次又新增了核酸檢測信息，展示核酸檢測的時間和結果。這就增加了兩個查詢，如果一碼通在不考慮使用緩存，只是用關系數據庫的情況下，那么就有可能增加最少兩個 SQL 查詢。

以上就是一碼通掃碼和亮碼兩個模塊大致的業務情況。這個業務所需要面對的是最高百萬級別的并發量(西安人口一千多萬)，這種級別的并發量在互聯網公司就是日常的并發量。那么它怎么就崩了呢?在官方的消息中有這么兩段話(只截取里面關鍵部分)：

1. 西安一碼通用戶訪問量激增，每秒訪問量達到以往峰值的10倍以上，造成網絡擁塞;

2. 判斷問題出現在網絡接口側。

由此可以判斷是網絡出現了問題。一般來說用戶的請求，先訪問域名，然后通過 DNS 服務器解析拿到 IP ，通過 IP 訪問到服務器，最后服務器將響應結果返回給客戶端。本次的故障就出現在通過 IP 訪問服務器階段。因為網絡擁塞，因此可以直接增加帶寬，但當系統恢復時，西安的小伙伴都發現一碼通回滾到了第一版，而且在一碼通的首頁新增加了核酸查詢頁面的鏈接，因此出現崩潰很有可能不只是帶寬的問題。這應該是外部請求的數量超過了系統最大處理能力造成的問題。

一般來說，產生這種問題的原因無非就是系統架構的問題，解決這個問題有兩種方法，擴容和限流：

1. 在請求達到承載的頂峰時，讓后續所有請求等待，進行限流。限流方案很多，最簡單的方式是使用 Nginx，如果效果不理想的話可以自定義算法在接入層限流。限流不能完全解決問題，只會阻擋部分請求。

2. 通過增加服務器數量、增加數據庫數量來提升系統的承載能力，這個是擴容。因為一碼通在出現問題后進行了回滾，并沒有進行擴容。因此大概率他們在系統架構設計上并沒有考慮擴容問題，因此擴容這個方案對于系統架構來說可能很難。

二、崩潰的解決方案

如果要解決上一小節的問題，可以從三個方面來解決。

1. 采用讀寫分離

將一碼通業務按照訪問頻率進行拆分：常用模塊和非常用模塊。常用模塊流量較大，將“讀”單獨處理出來，在數據庫前端加入緩存中間件，優先讀取緩存中的信息，這樣即使數據庫掛了，業務系統也能從緩存中讀取數據。非常用模塊流量較小，比如核酸信息和疫苗接種信息的更新，直接對數據庫進行操作。

2. 分庫分表和服務拆分

利用用戶 ID 取模后的值確定需要拆分成多少個庫或表，每個庫或表對應一個或多個服務子系統，接口將流量分配到不同的服務子系統上，這樣就減輕了單庫或單表以及服務系統的壓力，并且也能在流量暴增的時候快速地進行擴容。

3. 容災備份

使用異地多機房部署服務，提前做好的容災備份方案，避免出現前述的問題。

總結

西安一碼通明顯是在系統沒有嚴格測試的情況下，就發布到了生產環境，并發一高就崩潰。本文所述的這些問題只是根據目前可見的情況進行的分析，所提出的解決方案也是比較常見的解決方案。但是根據這些解決方案幾乎可以處理掉西安一碼通崩潰的問題。

作者介紹

朱鋼，51CTO社區編輯，2019年CSDN博客專家20強，2020年騰訊云+社區優秀作者，10年一線開發經驗，曾參與獵頭服務網站架構設計，企業智能客服以及大型電子政務系統開發，主導某大型央企內部防泄密和電子文檔安全監控系統的建設，目前在BIM頭部企業從事招投標軟件開發。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】