[[323257]]

1. 寫在前面

疫情期間，隨著返崗復工人員大幅流動，疫情擴散傳播風險巨大，疫情防控也面臨新的嚴峻挑戰(zhàn)。為了更好地統(tǒng)計流動人口信息，云南省公安廳面向社會公共場所推出“云南抗疫情”小程序，對公共場所的流動人口進行信息登記。具體措施是：每個場所都事先申請場所進出二維碼，人員在進入某公共場所時，掃描“進場”二維碼進入場所；離開時則需掃描“離場”二維碼離開場所。二維碼里面有單位及相關(guān)負責人的關(guān)聯(lián)信息，人員進出公共場所都需要掃碼。

上線不到一個月，截至 3 月 12 日，“云南抗疫情”掃碼小程序公共場所累計注冊 103 萬余個，掃碼登記 3.65 億人次，掃碼用戶數(shù)達 1755 萬余人。各個公共場所登記生成二維碼的請求量超過 10w/min，掃碼登記請求量超過 80W/min。云開發(fā)服務的高效穩(wěn)定將直接影響廣大人民群眾進出各個場所的效率。

那么，如何應對短時間的流量洪峰，確保小程序功能的正常使用？如何優(yōu)化小程序響應速度，在高并發(fā)下仍舊保持快速響應？

2. 高并發(fā)，不可忽視的業(yè)務技術(shù)挑戰(zhàn)

高并發(fā)對于任何服務來說都具有不小的技術(shù)挑戰(zhàn)。

在傳統(tǒng)模式下，一方面，要求業(yè)務的研發(fā)人員有一定的業(yè)務預見性，能夠提前對業(yè)務峰值做相對準確的預估，過多則造成資源浪費，過少則影響業(yè)務效果。另一方面，要求研發(fā)人員對業(yè)務架構(gòu)進行合理設計，提前部署大量資源，甚至要進行大量壓測以確?？煽啃?。不僅如此，還需要開發(fā)運維等人員參與?？梢哉f，應對高并發(fā)問題，在傳統(tǒng)開發(fā)模式下，需要耗費很多的人力物力，成本昂貴。

然而，這些高并發(fā)問題，在云開發(fā)模式下，相對確簡單了很多。云開發(fā)作為一個支持多端開發(fā)的云 + 端一體化解決方案，采用 serverless 架構(gòu)，架構(gòu)具備足夠的輕量和彈性，可以無限自動水平擴容，支持海量并發(fā)請求。對開發(fā)者來說，使用云開發(fā)就是典型的 NoOps 實踐。隨著請求量的不斷增長，云開發(fā)可以進行自動擴縮容量，確保允許在云開發(fā)上面的業(yè)務高性能、高可用，按需使用資源使得開發(fā)者不需要為了應對高并發(fā)而提前部署大量資源，這大大節(jié)約了資源成本。

此外，通過云開發(fā)各類端側(cè) SDK 就可以輕松實現(xiàn)包括微信小程序、QQ 小程序、WEB 端、移動應用等多端開發(fā)，僅需專注于開發(fā)者自身的業(yè)務實現(xiàn)，而無需關(guān)心傳統(tǒng) C/S 架構(gòu)中的服務端基礎(chǔ)架構(gòu)，業(yè)務可以快速開發(fā)上線，極大地提高開發(fā)效率，降低研發(fā)成本。

當前，云開發(fā)日均調(diào)用超過七億次，其中微信讀書、拼多多等客戶單個環(huán)境的請求量已經(jīng)達到過億級別。

3. 云開發(fā)的高性能高可用架構(gòu)設計

云開發(fā)作為一個公有云服務，不僅要能為開發(fā)者提供各類能力支持，更重要的是能為客戶業(yè)務提供連續(xù)不間斷的服務。這里，云開發(fā)的高可用就包括兩個方面：一是確保云開發(fā)自身服務的高可用，可以不間斷提供服務；二是為客戶提供支持高并發(fā)的能力支持，確?？蛻魳I(yè)務不斷上漲過程中，客戶業(yè)務高可用。

而云開發(fā)服務調(diào)用鏈路上有非常多的功能模塊，這就要求云開發(fā)內(nèi)部的所有功能模塊都是高性能和高可用的，目前云開服務內(nèi)部依賴模塊，日常均達到遠超過 99.99% 的服務可用性和極低的響應時間。

那么云開發(fā)如何保證高可用高性能呢？

下面先來看一下云開發(fā)整體架構(gòu)：

從圖中可以看到用戶的一次服務調(diào)用需經(jīng)過多個中間層服務，最終到的客戶資源層，所以云開發(fā)服務的高可用高性能從大的層面上可分為 “數(shù)據(jù)鏈路” 和 “底層資源” 兩個方面。目前，云開發(fā)系統(tǒng) “數(shù)據(jù)鏈路” 和 “底層資源” 均超過 99.99% 以上的可用性。

數(shù)據(jù)鏈路

應用從端側(cè) SDK 開始訪問云資源（云函數(shù)、數(shù)據(jù)庫、文件存儲）需經(jīng)過的一系列服務模塊最終到的資源層，這一調(diào)用鏈路對開發(fā)者來說是透明無感知的，所以這里將這一部分統(tǒng)稱為 “數(shù)據(jù)鏈路”。

數(shù)據(jù)鏈路為用戶提供 端側(cè) 和 云資源側(cè) 的連通能力，數(shù)據(jù)鏈路也并不僅僅進行數(shù)據(jù)轉(zhuǎn)發(fā)和傳輸，還包括一系列的處理邏輯，如微信登錄鑒權(quán)、票據(jù)生成與校驗、數(shù)據(jù)編解碼、云賬戶身份鑒權(quán)、集群路由、云資源信息綁定、安全規(guī)則、數(shù)據(jù)簽名與校驗、上下文環(huán)境信息注入、訪問記數(shù)、并發(fā)控制等多方面的能力支持模塊。

云開發(fā)服務各層服務模塊均按多集群進行部署，集群內(nèi)各層及各服務模塊也均進行了跨多機房的冗余部署，提供充分的冗余，并且自動發(fā)現(xiàn)和剔除故障主機，確保在服務故障時能夠進行快速屏蔽，保證云開發(fā)服務的高可用性。另外數(shù)據(jù)管道在資源部署上也提供了充足的容量支持，并備有一定量的 Buffer，當有用容量需求時，可進行快速擴容。部分模塊也開始嘗試容器化部署，能夠更快速彈性擴容。

鏈路是用戶請求能否成功到達客戶資源的關(guān)鍵，鏈路耗時也會對用戶請求總耗時產(chǎn)生直接影響。所以保證鏈路的高可用性和高性能非常關(guān)鍵，云開發(fā)團隊在性能和可用性方面也做了很多的設計優(yōu)化，以下為部分設計和優(yōu)化點：

1. 盡可能簡單，不引入不必要的依賴，盡可能減少依賴；
2. 無狀態(tài)設計，各個模塊均是無狀態(tài)的，便于在系統(tǒng)請求量上升時快速進行橫向擴容；
3. 可降級設計，鏈路中各個模塊均進行可降級設計，在單個模塊出現(xiàn)問題時，可自動或手動降級到備用方案，并且有兜底方案；
4. 多級緩存設計，在系統(tǒng)內(nèi)部存在多級別的緩存設計，提升系統(tǒng)性能；
5. 自動故障轉(zhuǎn)移，鏈路上下游主機可以自動發(fā)現(xiàn)和剔除故障主機，快速恢復服務；
6. 多集群部署，鏈路中各個模塊均進行了跨機房的多集群部署，在故障時能夠進行切換；
7. 重試策略，針對系統(tǒng)中可重試的場景設計重試機制，保證成功率；
8. 網(wǎng)絡策略優(yōu)化，長連接優(yōu)化，部分模塊內(nèi)部采用更高效的 RPC 調(diào)用；
9. 采用更高性能的實現(xiàn)方式，減少耗時；
10. 快慢請求分離，快請求同步慢請求異步的方式提高性能。

底層資源

底層資源的高可用是云開發(fā)服務高可用的關(guān)鍵一環(huán)，這一部分將對 “云函數(shù) ”和 “云數(shù)據(jù)庫” 進行分別介紹。

云函數(shù)優(yōu)化

云函數(shù)在高可用性方面進行了充分的架構(gòu)考量，在部署上做了充分的冗余，下圖為云函數(shù)高可用的部署架構(gòu)。

從圖中可以看到，云函數(shù)從接入層到資源層，各層均進行了多集群的部署，每個集群都按跨機房的方式部署。集群內(nèi)單機或單機房故障系統(tǒng)能夠自動發(fā)現(xiàn)并且快速剔除，這種部署方式可以應對單機故障、機房網(wǎng)絡故障等設施類故障。集群故障也能夠快速的切換用戶集群來快速恢復服務，縮短故障時間，保證高可用性。另外這種部署上的設計，也便于進行更大范圍的橫向擴容，提供更大的系統(tǒng)并發(fā)容量，以滿足客戶不斷上漲的業(yè)務需求。

在云函數(shù)資源底層，面多高并發(fā)請求，首先就需要有充足的能夠承擔高并發(fā)的計算資源，云開發(fā)的云函數(shù)底層建立了規(guī)模非常大的資源池，同時也預留的大量的 Buffer 資源，云函數(shù)系統(tǒng)從資源池分配資源給函數(shù)實例，在資源池消耗到一定程度時，系統(tǒng)可以自動化申請云上 VM 資源，快速擴容資源池，實現(xiàn)多層次的水平彈性伸縮，以應對開發(fā)者可能的海量業(yè)務需求。

同時，在發(fā)布策略上，按集群進行逐步的灰度，如果出現(xiàn)系統(tǒng) Bug，能夠只影響少量請求。

目前，云函數(shù)已經(jīng)完成了新一輪的系統(tǒng)架構(gòu)升級，以更高的可用性和性能，應對未來更大并發(fā)的挑戰(zhàn)。

云函數(shù)在執(zhí)行性能方面，也做了非常多的優(yōu)化。熟悉云開發(fā)的開發(fā)者應該了解，函數(shù)在一次調(diào)用中會涉及到函數(shù)的啟動，啟動又可以分為冷啟動和熱啟動，熱啟動是非?？焖俚?，而冷啟動則相對較慢。

冷啟動的過程如圖所示，對比可以看出，冷啟動需要創(chuàng)建函數(shù)實例，創(chuàng)建過程又包含多個子任務，如下載函數(shù)代碼、部署函數(shù)等，通常需要幾百毫秒的耗時。

啟動耗時對于云函數(shù)性能來說是非常關(guān)鍵的，所以云函數(shù)性能的優(yōu)化重點之一就在于減少冷啟動率和冷啟動耗時。云函數(shù)在啟動耗時方面也做了諸多優(yōu)化：

1. 優(yōu)化代碼下載耗時，在虛擬機內(nèi)和可用區(qū)內(nèi)建立多級緩存，提升下載云函數(shù)代碼包下載速度；
2. 優(yōu)化函數(shù)網(wǎng)絡部署策略，降低部署耗時；
3. 優(yōu)化容器啟動，降低啟動時間；
4. 基于用戶請求量變化趨勢和周期性的請求量變化規(guī)律，對云函數(shù)并發(fā)量進行準實時預測，提前進行擴縮容量；
5. 支持版本別名，用戶更新代碼， 以 Rolling Update 方式進行新舊版本替換，保證熱啟動率；
6. 優(yōu)化函數(shù)實例預留時間，保證整體的低冷啟動率。

云函數(shù)底層也采用了騰訊云自研的輕量級虛擬化技術(shù)，MicroVm 啟動時間縮短至 90 毫秒，函數(shù)冷啟動減低至 200 毫秒，并且支持上萬臺計算節(jié)點同時擴容；

目前，經(jīng)過函數(shù)底架構(gòu)上和性能上的不斷優(yōu)化，部署云函數(shù)實例的各階段耗時也在不斷減少，進而云函數(shù)的冷啟動時間不斷降低。為客戶提供更高的可用性和性能支持。

云開發(fā)目前為開發(fā)者提供單個云函數(shù) 1000 并發(fā)的能力支持，假設云函數(shù)的執(zhí)行時間為 100ms，單個云函數(shù)可以達到 10000 QPS，這已經(jīng)可以滿足大部分用戶場景的需求了，50 個云函數(shù)的總 QPS 將可以達到 50W QPS。

云數(shù)據(jù)庫優(yōu)化

云數(shù)據(jù)庫在接入層和數(shù)據(jù)庫底層也做了非常多的專項優(yōu)化，同時也在部署方面進行了諸多方面的設計。云數(shù)據(jù)庫的部署架構(gòu)如圖所示。

從架構(gòu)圖中可以看到，云數(shù)據(jù)庫接入層進行了分層設計并支持水平橫向擴容，所有用戶請求會被分配到不同的主機上，每個主機都獨立的維護用戶數(shù)據(jù)庫連接，這種方式保證了數(shù)據(jù)庫接入層能夠大規(guī)模進行水平擴展。另外，在部署上也進行了多集群的策略部署，集群內(nèi)部能夠自動發(fā)現(xiàn)故障主機并剔除。不同用戶分配到不同的接入集群，用戶請求可在多集群上進行靈活調(diào)度，以應對可能出現(xiàn)的服務故障，提供更高的可用性和更短的恢復時間。

在發(fā)布策略上也能做到更加可靠，按集群進行進行灰度，影響范圍小。

數(shù)據(jù)庫引擎實例也均進行了跨主機的多數(shù)據(jù)庫實例的部署，在單數(shù)據(jù)庫實例故障時能夠進行自動化的轉(zhuǎn)移。

數(shù)據(jù)為每個數(shù)據(jù)實例進行每日的全量備份并保存到對象存儲中，以保證用戶數(shù)據(jù)安全，當用戶數(shù)據(jù)出現(xiàn)問題時，可進行數(shù)據(jù)回檔，也間接的為用戶提供了一定的業(yè)務可用性支持。

數(shù)據(jù)底層也將支持在線熱遷移，在出現(xiàn)主機負載過較高時，自動在線熱遷移用戶實例到負載低的主機，此過程用戶幾乎是無感知的。熱遷移同時也能夠支持全局的數(shù)據(jù)庫主機間的負載均衡。

數(shù)據(jù)庫目前也已經(jīng)提供自動加索引能力，自動化的分析用戶慢查詢請求并針對性的進行自動索引優(yōu)化，能夠在用戶無感知的情況下優(yōu)化用戶查詢性能，使開發(fā)者可以更少的關(guān)心數(shù)據(jù)庫性能優(yōu)化就可以有優(yōu)良的性能體驗，降低客戶負擔，更加專注于自身的業(yè)務邏輯。

4. 高并發(fā)業(yè)務如何利用云開發(fā)進行優(yōu)化？

雖然云開發(fā)為開發(fā)者提供便利的云服務能力，同時也期望能夠盡可能的解決開發(fā)者在使用過程中遇到的所有問題，但顯然，這是一個永無止境的長期追求。

其實開發(fā)者在這方面也可以有很大的想象和發(fā)揮空間。開發(fā)者在面對高并發(fā)需求時，可以通過云開發(fā)做哪些優(yōu)化呢？

通常高并發(fā)業(yè)務按并發(fā)量上漲模型來劃分，可以分為以下兩種形式：

1. 業(yè)務量相對平緩上漲，并發(fā)量逐步上升，上升速度平緩，系統(tǒng)有充足的預熱時間；
2. 業(yè)務并發(fā)量爆發(fā)上漲，并發(fā)量瞬間上升，上升速度很快，例如常見的秒殺類業(yè)務。

對于第一種并發(fā)量以較均勻的速度上漲的業(yè)務，直接使用云開發(fā)就可以輕松應對。對于第二種呈爆發(fā)式上漲的業(yè)務，通過一定的策略和技術(shù)上的優(yōu)化，也能較輕松應對。

云函數(shù)在應對高并發(fā)請求的難點在于彈性，彈性支持了服務資源的按需部署，因此可以為開發(fā)者節(jié)省了大量資源花費。但也是因為彈性，在面對瞬時高并發(fā)需求時，服務瞬間面對比上之前大幾十倍甚至上百倍的并發(fā)請求，云函數(shù)伸縮系統(tǒng)難以預料這種爆發(fā)性上漲，因為冷啟動耗時相對較長，彈性擴容機制難以在秒級時間內(nèi)實現(xiàn)大量云函數(shù)實例部署，無法跟上并發(fā)上漲的速度，熱啟動率降低，啟動時間變長，進而導致部分請求超時，甚至出現(xiàn)超并發(fā)的情況，進而導致活動參與者因參與失敗而放棄，活動效果達不到預期。如何解決這個問題呢？

策略上的優(yōu)化方案

1. 提前評估活動并發(fā)量及 QPS 等指標；
2. 充分進行活動預熱，在活動越熱階段統(tǒng)計和再評估參與人數(shù)及并發(fā)量；
3. 在活動預熱頁面通過埋點代碼的方式對業(yè)務云函數(shù)進行預熱，通過參數(shù)控制不執(zhí)行業(yè)務邏輯即可，也可以通過其他方式或多種方式進行預熱；
4. 在評估并發(fā)量之后也別忘記評估套餐是否能滿足業(yè)務需求，云開發(fā)提供按量計費和包年包月兩種計費模式，業(yè)務方可以根據(jù)實際情況調(diào)整套餐，或者切換為按量計費，避免因套餐限制影響業(yè)務。

技術(shù)上的優(yōu)化方案

技術(shù)上的優(yōu)化核心就一點：降低耗時。

云函數(shù)方面，可通過以下方式進行優(yōu)化：

1. 減少調(diào)用依賴服務的次數(shù)，如進行請求合并；
2. 降低依賴服務的響應時間，如數(shù)據(jù)查詢耗時，其他接口調(diào)用耗時等；
3. 并發(fā)調(diào)用依賴服務；
4. 根據(jù)業(yè)務邏輯合并多個函數(shù)到單個函數(shù)、或拆分單云函數(shù)到多個云函數(shù)；
5. 精簡代碼、減少依賴、降低函數(shù)體積，縮短冷啟動時間。

數(shù)據(jù)庫方面，盡管云開發(fā)已經(jīng)針對數(shù)據(jù)庫查詢進行了自動化的索引優(yōu)化，但是系統(tǒng)對于用戶業(yè)務邏輯和數(shù)據(jù)的設計是遠遠不能及業(yè)務方的，所以業(yè)務方研發(fā)團隊可以在查詢性能等多方面進行優(yōu)化。針對高并發(fā)的場景，一些優(yōu)化建議如下：

1. 通過創(chuàng)建高效索引，提升數(shù)據(jù)庫查詢效率；
2. 通過優(yōu)化設計，減少數(shù)據(jù)庫查詢；
3. 采用高效的查詢條件；
4. 減少返回數(shù)據(jù)的條數(shù)以及字段數(shù)，降低數(shù)據(jù)庫的查詢時間以及網(wǎng)絡數(shù)據(jù)傳輸時間；
5. 減少事務的使用，盡量用替代方式；
6. 聚合類需求如排行榜等，可保存中間結(jié)果到數(shù)據(jù)庫或緩存，避免每次進行統(tǒng)計計算；
7. 數(shù)據(jù)量較大，可對集合水平拆分，降低單集合數(shù)據(jù)量，提升查詢效率。

實際上，盡管云開發(fā)數(shù)據(jù)庫資源層從云服務的角度來說是海量的，但是單個數(shù)據(jù)庫實例計算能力是有硬件上限的，當出現(xiàn)較多慢查詢時，數(shù)據(jù)庫系統(tǒng)將會大打折扣，將會影響大量數(shù)據(jù)庫操作，整體上會拖慢開發(fā)者自身業(yè)務響應時間，影響業(yè)務能力。云開發(fā)也計劃推出慢查詢?nèi)罩?、慢查詢告警等方面的能力，提供?shù)據(jù)庫優(yōu)化最佳實踐。

其他建議：

1. 對系統(tǒng)進行一定程度的實際壓測，驗證設計實現(xiàn)是否符合預期，并提前解決，避免活動上線之后達不到效果；
2. 獨立活動業(yè)務實現(xiàn)，避免活動影響現(xiàn)有業(yè)務。

5. 作者介紹

艷杰，騰訊高級前端開發(fā)工程師，云開發(fā)團隊核心開發(fā)專注于中后臺系統(tǒng)開發(fā)以及系統(tǒng)架構(gòu)設計。