???

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

一、崩潰的原因分析

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

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

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

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

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

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

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

一般來(lái)說(shuō)，產(chǎn)生這種問(wèn)題的原因無(wú)非就是系統(tǒng)架構(gòu)的問(wèn)題，解決這個(gè)問(wèn)題有兩種方法，擴(kuò)容和限流：

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

2. 通過(guò)增加服務(wù)器數(shù)量、增加數(shù)據(jù)庫(kù)數(shù)量來(lái)提升系統(tǒng)的承載能力，這個(gè)是擴(kuò)容。因?yàn)橐淮a通在出現(xiàn)問(wèn)題后進(jìn)行了回滾，并沒(méi)有進(jìn)行擴(kuò)容。因此大概率他們?cè)谙到y(tǒng)架構(gòu)設(shè)計(jì)上并沒(méi)有考慮擴(kuò)容問(wèn)題，因此擴(kuò)容這個(gè)方案對(duì)于系統(tǒng)架構(gòu)來(lái)說(shuō)可能很難。

二、崩潰的解決方案

如果要解決上一小節(jié)的問(wèn)題，可以從三個(gè)方面來(lái)解決。

1. 采用讀寫(xiě)分離

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

2. 分庫(kù)分表和服務(wù)拆分

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

3. 容災(zāi)備份

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

總結(jié)

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

作者介紹

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

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