從去年年底到現(xiàn)在，隨著疫情的反復(fù)，很多城市的一碼通系統(tǒng)出現(xiàn)了故障，這證明一碼通系統(tǒng)在技術(shù)上還存在一些不足，所以本次分享將介紹如何利用 PAST 問題解決框架，從架構(gòu)和設(shè)計(jì)方面研究和解決這些問題。

01 PAST 問題解決框架

PAST 的第一個(gè)單詞 P 是 Problem，代表的是問題。當(dāng)遇到問題的時(shí)候，不要急于進(jìn)入方案階段，應(yīng)該先進(jìn)行調(diào)研和分析，確認(rèn)問題到底是什么。這也是 Eric Evans 的《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》中提到的，理解目標(biāo)領(lǐng)域并將所學(xué)到的知識(shí)融入到軟件中是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）的首要任務(wù)，這強(qiáng)調(diào)了問題的重要性。

第二個(gè)單詞 A 是 Analysis，代表的是分析矛盾。導(dǎo)致問題產(chǎn)生的原因可能有多種，在這個(gè)過程中要先找出主要矛盾和次要矛盾，然后針對(duì)這些原因或者矛盾 找到對(duì)應(yīng)的 Solution，也就是 S 。此時(shí)，可以先列舉方案，然后 在 Tradeoff 階段進(jìn)行權(quán)衡和取舍 。在進(jìn)行軟件或者架構(gòu)設(shè)計(jì)的實(shí)踐中，大多數(shù)時(shí)候都在做權(quán)衡，而不是決策，所以需要對(duì)設(shè)計(jì)進(jìn)行取舍，最終制定出方案。根據(jù)不同的方案，可能要順勢(shì)而為，在最后階段進(jìn)行成效的 review。

02 Problem 問題

下圖為某一城市的一碼通系統(tǒng)。假設(shè)產(chǎn)生地為西虹市，圖 1（左）是正常情況下的一碼通系統(tǒng)，包含姓名、證件號(hào)和二維碼，其中二維碼分為綠碼、紅碼或者黃碼。另外，圖 1（左）的下方還包含疫苗接種信息以及 15 天內(nèi)的核酸檢測(cè)結(jié)果。由圖可知，一碼通的主入口集成了眾多的功能。圖 1（右） 為周一早晨一碼通系統(tǒng)的故障顯示頁面，顯示一碼通系統(tǒng)空白，此外，還出現(xiàn)了核酸檢測(cè)結(jié)果不顯示任何信息等問題。

■圖 1

03 Analysis分析

3.1 主要矛盾

在分析階段需要針對(duì)這些問題嘗試進(jìn)行調(diào)查和分析，找到問題的原因和矛盾。此時(shí)主要是大量市民需要在周一早上從不同場(chǎng)合打開一碼通系統(tǒng)的核酸證明頁面，與一碼通系統(tǒng)不能同時(shí)滿足大并發(fā)量之間的矛盾。一碼通系統(tǒng)無法打開，導(dǎo)致用戶反復(fù)刷新，系統(tǒng)用戶請(qǐng)求飆增。此時(shí)，請(qǐng)求可能直接到達(dá)后臺(tái)甚至服務(wù)層，進(jìn)而進(jìn)入分布式 cache 或者數(shù)據(jù)庫，這造成 后臺(tái)服務(wù)器的流量突增，對(duì)應(yīng)的網(wǎng)絡(luò)帶寬增加。

3.2 架構(gòu)分析

接下來進(jìn)一步分析架構(gòu)和設(shè)計(jì)，從數(shù)據(jù)層面來說，可能沒有形成很好的緩存機(jī)制，很多查詢請(qǐng)求都直接進(jìn)入服務(wù)器甚?數(shù)據(jù)庫，造成了緩存的擊穿，很多流量被“懟”到了數(shù)據(jù)庫。從變化頻率彈性來說，一碼通系統(tǒng)的問題在于， 個(gè)?碼頁?聚合了太多的內(nèi)容，沒有基于容器的集群搭建和熔斷機(jī)制 。從 CFR 跨功能需求來說，問題在于， 開發(fā)人員在進(jìn)行服務(wù)設(shè)計(jì)時(shí)沒有考慮服務(wù)器的峰值限制，在系統(tǒng)測(cè)試設(shè)計(jì)階段沒有做好性能和壓?測(cè)試，導(dǎo)致系統(tǒng)最終超過了負(fù)荷 。從?絡(luò)瓶頸來說，理論上來說 1000M ?卡的傳輸速度是 125MB/s，100M ?卡的傳輸速度是 12.5MB/s，在當(dāng)天出現(xiàn)故障的愿意可能是網(wǎng)絡(luò)帶寬不夠支撐，導(dǎo)致網(wǎng)絡(luò)上的瓶頸。

圖 2

04 Solution 方案枚舉

完成分析之后需要制定問題解決方案，在方案枚舉過程中，不要著急表達(dá)自己的傾向，應(yīng)該先確定備選方案，并對(duì)其進(jìn)行排列和組合。

4.1 基于數(shù)據(jù)分層架構(gòu)

針對(duì)數(shù)據(jù)來說，可以分為 UI 層個(gè)性數(shù)據(jù)、緩存數(shù)據(jù)和 DB 全量數(shù)據(jù)。緩存設(shè)計(jì)遵循就近原則，數(shù)據(jù)離用戶越近越好，這樣性能可能就越好。按照這種原則，基于數(shù)據(jù)的分層架構(gòu)實(shí)際上是一種漏斗型架構(gòu)，它是以對(duì)象和集合為單位的一種緩存策略，能夠減少對(duì)下層系統(tǒng)的訪問。針對(duì)每一層數(shù)據(jù)，可以采用不同的方法進(jìn)行處理。

對(duì)于 UI 層個(gè)性數(shù)據(jù)，就一碼通系統(tǒng)出現(xiàn)的問題而言，當(dāng)用戶點(diǎn)擊查詢核酸結(jié)果時(shí)，可以令按鈕不可用，從功能上禁止重復(fù)提交，比如設(shè)置 15 秒以后才能打開，這樣就會(huì)阻斷流量。對(duì)于緩存數(shù)據(jù)，可以在瀏覽器進(jìn)行緩存，比如把常見的圖片、靜態(tài)文件、腳本緩存起來，這可能只需要有限的資源就可以讓請(qǐng)求進(jìn)入對(duì)應(yīng)的后續(xù)階段。此外，還可以利用 CDN 緩存分發(fā)網(wǎng)絡(luò)。數(shù)據(jù)從 UI 層到達(dá)應(yīng)用層或者服務(wù)端，可以采用 NGINX 或者中間服務(wù)器進(jìn)行代理，比如在服務(wù)器端為頻繁查詢，但修改較少的數(shù)據(jù)建立緩存。

對(duì)于 DB 全量數(shù)據(jù)，主要應(yīng)專注于存儲(chǔ)，而不是進(jìn)行復(fù)雜的運(yùn)算。數(shù)據(jù)庫廠商可以支持?jǐn)?shù)據(jù)庫限流，當(dāng)達(dá)到一定的流量時(shí)。返回對(duì)應(yīng)的異常碼會(huì)告訴用戶不可用，對(duì)應(yīng)的服務(wù)端根據(jù)情況可以進(jìn)行熔斷處理，而不至于讓數(shù)據(jù)庫一直處理信息而不能響應(yīng)，進(jìn)而導(dǎo)致整個(gè)應(yīng)用崩潰。另外，在當(dāng)天一碼通系統(tǒng)出現(xiàn)問題的時(shí)候，建立不同的微服務(wù)對(duì)核酸報(bào)告進(jìn)行動(dòng)態(tài)的彈性擴(kuò)容是一個(gè)不錯(cuò)的選擇，劃分手段就是 DDD。

■圖 3

4.2 業(yè)務(wù)變化頻率和彈性

在創(chuàng)業(yè)過程中或在一些比較復(fù)雜的系統(tǒng)中，可以做一些體驗(yàn)設(shè)計(jì)，對(duì)系統(tǒng)業(yè)務(wù)能力進(jìn)行劃分。要基于上下文，根據(jù)系統(tǒng)業(yè)務(wù)能力判斷是否從單體轉(zhuǎn)為微服務(wù)。另外，還要考慮業(yè)務(wù)變化頻率和彈性，比如核酸檢測(cè)是近期使用非常頻繁的功能，將其放至主頁，進(jìn)入系統(tǒng)后可以直接查詢。事實(shí)也證明，當(dāng)時(shí)西虹市在疫情出現(xiàn)幾天后就把核酸檢測(cè)這個(gè)功能直接放到頁面上，這間接說明了業(yè)務(wù)變化頻率對(duì)系統(tǒng)的設(shè)計(jì)是很重要的。

圖 4

4.3 CFR – 測(cè)試設(shè)計(jì)與性能

針對(duì) CFR 來說，圖 5 展示了有指導(dǎo)意義的測(cè)試四象限。Q1 象限從技術(shù)出發(fā)支撐團(tuán)隊(duì)的整個(gè)測(cè)試，包括單元測(cè)試和組件測(cè)試，可以幫助團(tuán)隊(duì)盡快發(fā)現(xiàn)問題。Q2 象限從業(yè)務(wù)角度支撐團(tuán)隊(duì)測(cè)試，更側(cè)重于發(fā)現(xiàn)功能和業(yè)務(wù)上的問題。Q3 象限從業(yè)務(wù)角度來評(píng)價(jià)產(chǎn)品，主要包括一些探索性測(cè)試。Q4 象限從技術(shù)角度來評(píng)價(jià)產(chǎn)品，包括性能測(cè)試、壓力測(cè)試以及安全測(cè)試。可以將 4 個(gè)象限分為質(zhì)量交付（Q1、Q2、Q3）和運(yùn)維（Q1、Q2、Q3、Q4）兩條指引。隨著 DevOps 的盛行，往往把這四個(gè)象限是結(jié)合起來，制定有效的測(cè)試策略，使測(cè)試和開發(fā)在項(xiàng)目中能夠落地。

圖 5

從性能設(shè)計(jì)方案來說，在并發(fā)量很高的情況下，比如一秒鐘有 100 個(gè)請(qǐng)求，那么是否要把 100 個(gè)請(qǐng)求直接放到服務(wù)端和數(shù)據(jù)庫，進(jìn)行 100 次查詢？顯然不是，解決方案應(yīng)該是把這些請(qǐng)求合并到一起?？梢酝ㄟ^限時(shí)器或者定時(shí)器的形式把請(qǐng)求合到一起，在查詢之后找到對(duì)應(yīng)的 API 對(duì)應(yīng)進(jìn)行返回。這實(shí)際上是批量查詢的變種。但如果請(qǐng)求較少，就沒有必要進(jìn)行請(qǐng)求合并了，應(yīng)根據(jù)情況配置。還有一種方法叫限流，這時(shí)可以采用 令牌桶算法 ，令牌桶的容量是?定的，令牌是以?定的速率加進(jìn)去的，如果桶已經(jīng)滿了，就不再繼續(xù)添加。也可以采用 漏桶算法 ，不管當(dāng)前有多少并發(fā)數(shù)，通過出?速率保證后臺(tái)程序接到的請(qǐng)求數(shù)是?定的，可以達(dá)到限流的?的。這種方法不適用于一碼通系統(tǒng)事件的情況。 中間件限流方法 是 Tomcat 使? maxThreads 來實(shí)現(xiàn)限流，也可以通過 NGINX 的 limit_req_zone 和 burst 來實(shí)現(xiàn)速率限流，NGINX 的 limit_conn_zone 和 limit_conn 兩個(gè)指令可以控制并發(fā)連接的總數(shù)。

4.4 網(wǎng)絡(luò)瓶頸

從網(wǎng)絡(luò)瓶頸來說，為了防止網(wǎng)絡(luò)堵塞情況發(fā)生，可以嘗試把訪問方式由 HTTP 變成 TCP，例如訪問 Redis 緩存，這種情況采? RESP ?式。還可以使?更?檔次的?卡，例如采? DNS 負(fù)載均衡，使多個(gè) IP 對(duì)應(yīng)同?個(gè)域名。

05 Tradeoff 權(quán)衡和取舍

做軟件就是做權(quán)衡。具體來說，前端落地后，客戶端緩存、瀏覽器緩存、CDN 緩存等都可以開始運(yùn)行，首先訪問服務(wù)器，這里的服務(wù)器包含對(duì)應(yīng)的 NGINX 或者負(fù)載均衡器，流量接下來到達(dá)應(yīng)用層和服務(wù)層，如果此階段流量較大，可以多線進(jìn)行性能優(yōu)化或者高性能的 RPC，也可以添加緩存。然后可以進(jìn)入微服務(wù)框架。

回到緩存部分，數(shù)據(jù)訪問層可能包含 Redis 等，一些頻繁訪問但不經(jīng)常變的數(shù)據(jù)就可以緩存到這里，通過請(qǐng)求合并或者查詢減少 I/O。在存儲(chǔ)層，數(shù)據(jù)庫比較注重全量數(shù)據(jù)，如果數(shù)據(jù)庫壓力比較大，可以考慮分庫和分表。根據(jù)不同的數(shù)據(jù)情況，甚至不同的人、不同的區(qū)，都可以建立自己的數(shù)據(jù)庫來進(jìn)行訪問。從基礎(chǔ)設(shè)施來說，系統(tǒng)要能夠支持快速的擴(kuò)容，如果把業(yè)務(wù)變化頻率彈性考慮進(jìn)去，那么云原生是不可缺少的。最后列出一個(gè)方案僅供參考。

答疑環(huán)節(jié)

1、如何帶領(lǐng)和管理初創(chuàng)企業(yè)的技術(shù)團(tuán)隊(duì)？

要想帶領(lǐng)團(tuán)隊(duì)，首先應(yīng)該確定團(tuán)隊(duì)的方向，也就是項(xiàng)目愿景。確定愿景之后才有了目標(biāo)，然后根據(jù)實(shí)際情況，確認(rèn)支撐這些目標(biāo)完成所需要的人員技能要求。其次，團(tuán)隊(duì)要進(jìn)行能力提升，因?yàn)橐瓿蓸I(yè)務(wù)目標(biāo)，需要對(duì)應(yīng)的能力輸出。另外，如果團(tuán)隊(duì)人員比較多，還要有團(tuán)隊(duì)規(guī)范，使公司或者項(xiàng)目的戰(zhàn)略流程化，流程工具化。對(duì)于組織來說，我認(rèn)為還要進(jìn)行不停的學(xué)習(xí)嘗試，應(yīng)該從客戶的角度來解決其痛點(diǎn)。

2、一碼通系統(tǒng)的 CDN 設(shè)計(jì)有什么原則？

一般情況下，在配置的時(shí)候，要明確有哪些是能夠緩存起來的。比如，可以把不經(jīng)常訪問也不經(jīng)常變化的數(shù)據(jù)放到 CDN 緩存中，具體要根據(jù)業(yè)務(wù)數(shù)據(jù)的情況來決定。

3、請(qǐng)求如何合并？

在 Java 中有 feature 功能可以引入請(qǐng)求。比如，1 秒鐘有 100 個(gè)請(qǐng)求，引入請(qǐng)求之后可以將其分為 10 份，通過線程池一秒內(nèi)遍歷 10 次。具體可以把請(qǐng)求分別添加至線程池中，然后線程池定時(shí)觸發(fā)調(diào)用請(qǐng)求。feature 功能使請(qǐng)求從數(shù)據(jù)庫返回之后，能夠找到對(duì)應(yīng)的 request。對(duì)于這些問題，JavaSpring 中已經(jīng)有比較成熟的方案。