???

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

一、崩潰的原因分析

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

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

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

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

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

2. 判斷問題出現(xiàn)在網(wǎng)絡接口側。

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

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

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

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

二、崩潰的解決方案

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

1. 采用讀寫分離

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

2. 分庫分表和服務拆分

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

3. 容災備份

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

總結

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

作者介紹

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

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