回覆"架構師"獲取資源css
疫情期間，隨着返崗復工人員大幅流動，疫情擴散傳播風險巨大，疫情防控也面臨新的嚴峻挑戰。爲了更好地統計流動人口信息，雲南省公安廳面向社會公共場所推出「雲南抗疫情」小程序，對公共場所的流動人口進行信息登記。具體措施是：每一個場所都事先申請場所進出二維碼，人員在進入某公共場所時，掃描「進場」二維碼進入場所；離開時則需掃描「離場」二維碼離開場所。二維碼裏面有單位及相關負責人的關聯信息，人員進出公共場所都須要掃碼。前端
上線不到一個月，截至 3 月 12 日，「雲南抗疫情」掃碼小程序公共場所累計註冊 103 萬餘個，掃碼登記 3.65 億人次，掃碼用戶數達 1755 萬餘人。各個公共場所登記生成二維碼的請求量超過 10w/min，掃碼登記請求量超過 80W/min。雲開發服務的高效穩定將直接影響廣大人民羣衆進出各個場所的效率。java
那麼，如何應對短期的流量洪峯，確保小程序功能的正常使用？如何優化小程序響應速度，在高併發下仍舊保持快速響應？web
高併發對於任何服務來講都具備不小的技術挑戰。面試
在傳統模式下，一方面，要求業務的研發人員有必定的業務預見性，可以提早對業務峯值作相對準確的預估，過多則形成資源浪費，過少則影響業務效果。另外一方面，要求研發人員對業務架構進行合理設計，提早部署大量資源，甚至要進行大量壓測以確保可靠性。不只如此，還須要開發運維等人員參與。能夠說，應對高併發問題，在傳統開發模式下，須要耗費不少的人力物力，成本昂貴。數據庫
然而，這些高併發問題，在雲開發模式下，相對確簡單了不少。雲開發做爲一個支持多端開發的雲 + 端一體化解決方案，採用 serverless 架構，架構具有足夠的輕量和彈性，能夠無限自動水平擴容，支持海量併發請求。對開發者來講，使用雲開發就是典型的 NoOps 實踐。隨着請求量的不斷增加，雲開發能夠進行自動擴縮容量，確保容許在雲開發上面的業務高性能、高可用，按需使用資源使得開發者不須要爲了應對高併發而提早部署大量資源，這大大節約了資源成本。小程序
此外，經過雲開發各種端側 SDK 就能夠輕鬆實現包括微信小程序、QQ 小程序、WEB 端、移動應用等多端開發，僅需專一於開發者自身的業務實現，而無需關心傳統 C/S 架構中的服務端基礎架構，業務能夠快速開發上線，極大地提升開發效率，下降研發成本。微信小程序
當前，雲開發日均調用超過七億次，其中微信讀書、拼多多等客戶單個環境的請求量已經達到過億級別。緩存
雲開發做爲一個公有云服務，不只要能爲開發者提供各種能力支持，更重要的是能爲客戶業務提供連續不間斷的服務。這裏，雲開發的高可用就包括兩個方面：一是確保雲開發自身服務的高可用，能夠不間斷提供服務；二是爲客戶提供支持高併發的能力支持，確保客戶業務不斷上漲過程當中，客戶業務高可用。安全
而云開發服務調用鏈路上有很是多的功能模塊，這就要求雲開發內部的全部功能模塊都是高性能和高可用的，目前雲開服務內部依賴模塊，平常均達到遠超過 99.99% 的服務可用性和極低的響應時間。
那麼雲開發如何保證高可用高性能呢？
下面先來看一下雲開發總體架構：
從圖中能夠看到用戶的一次服務調用需通過多箇中間層服務，最終到的客戶資源層，因此雲開發服務的高可用高性能從大的層面上可分爲 「數據鏈路」 和 「底層資源」 兩個方面。目前，雲開發系統 「數據鏈路」 和 「底層資源」 均超過 99.99% 以上的可用性。
應用從端側 SDK 開始訪問雲資源（雲函數、數據庫、文件存儲）需通過的一系列服務模塊最終到的資源層，這一調用鏈路對開發者來講是透明無感知的，因此這裏將這一部分統稱爲 「數據鏈路」。
數據鏈路爲用戶提供 端側 和 雲資源側 的連通能力，數據鏈路也並不只僅進行數據轉發和傳輸，還包括一系列的處理邏輯，如微信登陸鑑權、票據生成與校驗、數據編解碼、雲帳戶身份鑑權、集羣路由、雲資源信息綁定、安全規則、數據簽名與校驗、上下文環境信息注入、訪問記數、併發控制等多方面的能力支持模塊。
雲開發服務各層服務模塊均按多集羣進行部署，集羣內各層及各服務模塊也均進行了跨多機房的冗餘部署，提供充分的冗餘，而且自動發現和剔除故障主機，確保在服務故障時可以進行快速屏蔽，保證雲開發服務的高可用性。另外數據管道在資源部署上也提供了充足的容量支持，並備有必定量的 Buffer，當有用容量需求時，可進行快速擴容。部分模塊也開始嘗試容器化部署，可以更快速彈性擴容。
鏈路是用戶請求可否成功到達客戶資源的關鍵，鏈路耗時也會對用戶請求總耗時產生直接影響。因此保證鏈路的高可用性和高性能很是關鍵，雲開發團隊在性能和可用性方面也作了不少的設計優化，如下爲部分設計和優化點：
儘量簡單，不引入沒必要要的依賴，儘量減小依賴；
無狀態設計，各個模塊均是無狀態的，便於在系統請求量上升時快速進行橫向擴容；
可降級設計，鏈路中各個模塊均進行可降級設計，在單個模塊出現問題時，可自動或手動降級到備用方案，而且有兜底方案；
多級緩存設計，在系統內部存在多級別的緩存設計，提高系統性能；
自動故障轉移，鏈路上下游主機能夠自動發現和剔除故障主機，快速恢復服務；
多集羣部署，鏈路中各個模塊均進行了跨機房的多集羣部署，在故障時可以進行切換；
重試策略，針對系統中可重試的場景設計重試機制，保證成功率；
網絡策略優化，長鏈接優化，部分模塊內部採用更高效的 RPC 調用；
採用更高性能的實現方式，減小耗時；
快慢請求分離，快請求同步慢請求異步的方式提升性能。
底層資源的高可用是雲開發服務高可用的關鍵一環，這一部分將對 「雲函數 」和 「雲數據庫」 進行分別介紹。
雲函數在高可用性方面進行了充分的架構考量，在部署上作了充分的冗餘，下圖爲雲函數高可用的部署架構。
從圖中能夠看到，雲函數從接入層到資源層，各層均進行了多集羣的部署，每一個集羣都按跨機房的方式部署。集羣內單機或單機房故障系統可以自動發現而且快速剔除，這種部署方式能夠應對單機故障、機房網絡故障等設施類故障。集羣故障也可以快速的切換用戶集羣來快速恢復服務，縮短故障時間，保證高可用性。另外這種部署上的設計，也便於進行更大範圍的橫向擴容，提供更大的系統併發容量，以知足客戶不斷上漲的業務需求。
在雲函數資源底層，面多高併發請求，首先就須要有充足的可以承擔高併發的計算資源，雲開發的雲函數底層創建了規模很是大的資源池，同時也預留的大量的 Buffer 資源，雲函數系統從資源池分配資源給函數實例，在資源池消耗到必定程度時，系統能夠自動化申請雲上 VM 資源，快速擴容資源池，實現多層次的水平彈性伸縮，以應對開發者可能的海量業務需求。
同時，在發佈策略上，按集羣進行逐步的灰度，若是出現系統 Bug，可以隻影響少許請求。
目前，雲函數已經完成了新一輪的系統架構升級，以更高的可用性和性能，應對將來更大併發的挑戰。
雲函數在執行性能方面，也作了很是多的優化。熟悉雲開發的開發者應該瞭解，函數在一次調用中會涉及到函數的啓動，啓動又能夠分爲冷啓動和熱啓動，熱啓動是很是快速的，而冷啓動則相對較慢。
冷啓動的過程如圖所示，對比能夠看出，冷啓動須要建立函數實例，建立過程又包含多個子任務，以下載函數代碼、部署函數等，一般須要幾百毫秒的耗時。
啓動耗時對於雲函數性能來講是很是關鍵的，因此雲函數性能的優化重點之一就在於減小冷啓動率和冷啓動耗時。雲函數在啓動耗時方面也作了諸多優化：
優化代碼下載耗時，在虛擬機內和可用區內創建多級緩存，提高下載雲函數代碼包下載速度；
優化函數網絡部署策略，下降部署耗時；
優化容器啓動，下降啓動時間；
基於用戶請求量變化趨勢和週期性的請求量變化規律，對雲函數併發量進行準實時預測，提早進行擴縮容量；
支持版本別名，用戶更新代碼， 以 Rolling Update 方式進行新舊版本替換，保證熱啓動率；
優化函數實例預留時間，保證總體的低冷啓動率。
雲函數底層也採用了騰訊雲自研的輕量級虛擬化技術，MicroVm 啓動時間縮短至 90 毫秒，函數冷啓動減低至 200 毫秒，而且支持上萬臺計算節點同時擴容；
目前，通過函數底架構上和性能上的不斷優化，部署雲函數實例的各階段耗時也在不斷減小，進而云函數的冷啓動時間不斷下降。爲客戶提供更高的可用性和性能支持。
雲開發目前爲開發者提供單個雲函數 1000 併發的能力支持，假設雲函數的執行時間爲 100ms，單個雲函數能夠達到 10000 QPS，這已經能夠知足大部分用戶場景的需求了，50 個雲函數的總 QPS 將能夠達到 50W QPS。
雲數據庫在接入層和數據庫底層也作了很是多的專項優化，同時也在部署方面進行了諸多方面的設計。雲數據庫的部署架構如圖所示。
從架構圖中能夠看到，雲數據庫接入層進行了分層設計並支持水平橫向擴容，全部用戶請求會被分配到不一樣的主機上，每一個主機都獨立的維護用戶數據庫鏈接，這種方式保證了數據庫接入層可以大規模進行水平擴展。另外，在部署上也進行了多集羣的策略部署，集羣內部可以自動發現故障主機並剔除。不一樣用戶分配到不一樣的接入集羣，用戶請求可在多集羣上進行靈活調度，以應對可能出現的服務故障，提供更高的可用性和更短的恢復時間。
在發佈策略上也能作到更加可靠，按集羣進行進行灰度，影響範圍小。
數據庫引擎實例也均進行了跨主機的多數據庫實例的部署，在單數據庫實例故障時可以進行自動化的轉移。
數據爲每一個數據實例進行每日的全量備份並保存到對象存儲中，以保證用戶數據安全，當用戶數據出現問題時，可進行數據回檔，也間接的爲用戶提供了必定的業務可用性支持。
數據底層也將支持在線熱遷移，在出現主機負載過較高時，自動在線熱遷移用戶實例到負載低的主機，此過程用戶幾乎是無感知的。熱遷移同時也可以支持全局的數據庫主機間的負載均衡。
數據庫目前也已經提供自動加索引能力，自動化的分析用戶慢查詢請求並針對性的進行自動索引優化，可以在用戶無感知的狀況下優化用戶查詢性能，使開發者能夠更少的關心數據庫性能優化就能夠有優良的性能體驗，下降客戶負擔，更加專一於自身的業務邏輯。
雖然雲開發爲開發者提供便利的雲服務能力，同時也指望可以儘量的解決開發者在使用過程當中遇到的全部問題，但顯然，這是一個永無止境的長期追求。
其實開發者在這方面也能夠有很大的想象和發揮空間。開發者在面對高併發需求時，能夠經過雲開發作哪些優化呢？
一般高併發業務按併發量上漲模型來劃分，能夠分爲如下兩種形式：
業務量相對平緩上漲，併發量逐步上升，上升速度平緩，系統有充足的預熱時間；
業務併發量爆發上漲，併發量瞬間上升，上升速度很快，例如常見的秒殺類業務。
對於第一種併發量以較均勻的速度上漲的業務，直接使用雲開發就能夠輕鬆應對。對於第二種呈爆發式上漲的業務，經過必定的策略和技術上的優化，也能較輕鬆應對。
雲函數在應對高併發請求的難點在於彈性，彈性支持了服務資源的按需部署，所以能夠爲開發者節省了大量資源花費。但也是由於彈性，在面對瞬時高併發需求時，服務瞬間面對比上以前大幾十倍甚至上百倍的併發請求，雲函數伸縮系統難以預料這種爆發性上漲，由於冷啓動耗時相對較長，彈性擴容機制難以在秒級時間內實現大量雲函數實例部署，沒法跟上併發上漲的速度，熱啓動率下降，啓動時間變長，進而致使部分請求超時，甚至出現超併發的狀況，進而致使活動參與者因參與失敗而放棄，活動效果達不到預期。如何解決這個問題呢？
提早評估活動併發量及 QPS 等指標；
充分進行活動預熱，在活動越熱階段統計和再評估參與人數及併發量；
在活動預熱頁面經過埋點代碼的方式對業務雲函數進行預熱，經過參數控制不執行業務邏輯便可，也能夠經過其餘方式或多種方式進行預熱；
在評估併發量以後也別忘記評估套餐是否能知足業務需求，雲開發提供按量計費和包年包月兩種計費模式，業務方能夠根據實際狀況調整套餐，或者切換爲按量計費，避免因套餐限制影響業務。
技術上的優化核心就一點：下降耗時。
雲函數方面，可經過如下方式進行優化：
減小調用依賴服務的次數，如進行請求合併；
下降依賴服務的響應時間，如數據查詢耗時，其餘接口調用耗時等；
併發調用依賴服務；
根據業務邏輯合併多個函數到單個函數、或拆分單雲函數到多個雲函數；
精簡代碼、減小依賴、下降函數體積，縮短冷啓動時間。
數據庫方面，儘管雲開發已經針對數據庫查詢進行了自動化的索引優化，可是系統對於用戶業務邏輯和數據的設計是遠遠不能及業務方的，因此業務方研發團隊能夠在查詢性能等多方面進行優化。針對高併發的場景，一些優化建議以下：
經過建立高效索引，提高數據庫查詢效率；
經過優化設計，減小數據庫查詢；
採用高效的查詢條件；
減小返回數據的條數以及字段數，下降數據庫的查詢時間以及網絡數據傳輸時間；
減小事務的使用，儘可能用替代方式；
聚合類需求如排行榜等，可保存中間結果到數據庫或緩存，避免每次進行統計計算；
數據量較大，可對集合水平拆分，下降單集合數據量，提高查詢效率。
實際上，儘管雲開發數據庫資源層從雲服務的角度來講是海量的，可是單個數據庫實例計算能力是有硬件上限的，當出現較多慢查詢時，數據庫系統將會大打折扣，將會影響大量數據庫操做，總體上會拖慢開發者自身業務響應時間，影響業務能力。雲開發也計劃推出慢查詢日誌、慢查詢告警等方面的能力，提供數據庫優化最佳實踐。
其餘建議：
對系統進行必定程度的實際壓測，驗證設計實現是否符合預期，並提早解決，避免活動上線以後達不到效果；
獨立活動業務實現，避免活動影響現有業務。
豔傑，騰訊高級前端開發工程師，雲開發團隊核心開發專一於中後臺系統開發以及系統架構設計。
另外：小程序送書5本+騰訊視頻VIP月卡已經開始，歡迎打卡學習。
到此文章就結束了。若是今天的文章對你在進階架構師的路上有新的啓發和進步，歡迎轉發給更多人。歡迎加入架構師社區技術交流羣，衆多大咖帶你進階架構師，在後臺回覆「加羣」便可入羣。
這些年小編給你分享過的乾貨
《IDEA 2020.2 最新破解教程，有效期到2089年》
轉發在看就是最大的支持❤️
本文分享自微信公衆號 - Java架構師社區（mush_java_jg）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。