騰訊雲 Serverless 保障《創造營》硬糖少女 C 位出道

時間 2020-07-26

標籤騰訊 serverless 保障創造營硬糖出道欄目騰訊简体版

原文原文鏈接

15 位青春洋溢的女團候選成員，百萬次全網觀衆投票，節目播出後迅速霸佔熱搜前十位.....nginx

在這激動人心的決賽之夜，Tencent Serverless 團隊下的雲 API 網關產品做爲幕後英雄，利用其高併發、高可用的技術特性，支撐了節目投票環節順利開展，面對全網粉絲狂熱打 call 投票，順利保障小姐姐們 C 位出道！git

不通常的投票

【投票】是一個很簡單的功能，可是《創造營》的投票不同。github

《創造營》是直播節目，投票時間很是短。海量全網粉絲將在同一時間瞬時涌入，瞬間的大流量和高併發，對系統的高可用性提出了極高的要求。golang

《創造營》投票，將產生本屆總冠軍，是《創造營》決勝之夜的制勝環節，激動人心的時刻。投票系統的任何差池，都會對粉絲心理和節目效果形成重創。redis

在投票的關鍵時刻，爲了保證女團小姐姐順利出道，技術小哥哥採用了什麼樣的技術設計，保證了這種特殊場景下的投票功能高可用呢？算法

Serverless

Serverless 是一種雲計算技術的新趨勢，一方面它使開發者在構建和運行應用時無需管理服務器等基礎設施，將構建應用的成本進一步下降，實現快速迭代、極速部署；同時，Serverless尤爲適用於高併發場景，無需預估流量大小，而會根據流量狀況自動的進行擴縮容，整個過程無需人工干預；值得一提的是，Serverless 仍是按用量付費的模式，避免了無用的資源開銷，大大下降了成本。sql

爲了讓用戶得到這些技術優點，Tencent Serverless 團隊推出了雲函數、API 網關、Serverless Framework、Serverless HTTP 等一系列 Serverless 產品。這些產品在諸多場景中獲得了普遍的應用，例如最近超級火爆的《創造營》節目，背後也是有 Serverless 技術，默默爲其提供支撐和服務。數據庫

一個具體的例子，《創造營》的投票系統高可用的祕訣，就是基於騰訊雲 Serverless 的重要組成部分 —— API 網關產品來打造的。Serverless 雲 API 網關是如何保證投票系統的高可用性呢？接下來，將從這個點進行切入，從技術層面，爲讀者進行深度分析。express

高可用之道

產品策略：輕重邏輯分離、用戶分流、功能簡化
客戶端：重試、失敗提示優化、客戶端隨機丟棄請求
接入層：全侷限流、服務降級、鑑權和 ACL
邏輯層：識別熱點對象和熱點對象預處理、事務一致性以及事務回滾
存儲層：可靠性（主備/異地容災/數據持久化）、一致性
運維：灰度發佈、故障演練、混沌工程

本文主要是站在接入層的角度，淺析如何保障業務高可用。另外一方面，靈活的全侷限流以及服務降級功能，也是客戶選擇 API 網關的緣由。小程序

上圖是創造營小程序的簡化架構圖：

小程序經過外網訪問 API 網關，API 做爲接入層
爲每一個業務建立 restful API，轉發到後端的不一樣業務
掃碼服務用於跳轉到該小程序
爲小姐姐撐腰的功能是由投票服務提供
抽獎和兌獎服務則分別提供抽獎以及兌換獎品的功能

在雲 API 網關建立的 API 以下圖所示：

不一樣業務分別創建相關 API 且配置相應後端
scan、vote、drawGift、getGift 分別對應掃碼、投票、抽獎和領獎業務
一般 restful API 是經過路徑或者路徑加方法進行匹配，不一樣業務建議使用不一樣路徑，也能夠根據須要某些業務 API 再進一步拆分
API 方法建議選擇 ANY方法
不建議只建立一個 / + ANY 的 API，這樣便失去了 API 生命週期管理的意義

分析

服務限流是接入層高可用必備條件，但限流設置爲多少合適呢？普適的方案是須要根據業務場景壓力預估值結合全鏈路壓測得出的業務容量評估而出。

結合上面的內容，本文主要會從如下幾點保障業務高可用：

全鏈路壓測肯定業務容量
根據容量設定限流，避免高負載引發雪崩
區分主次業務，優先保障核心業務，次要業務經過限流進行服務降級

高可用之術

壓測

兵馬未動，糧草先行；業務保障，壓測先行。壓測能夠及時發現業務中的性能問題，也能夠測算出業務容量，是保障業務高可用必不可少的一個環境。但壓測有一些常見的注意點：

作業務壓力測試時，最好使用線上的數據和線上的環境。由於測試環境和線上環境每每存在各類各樣的差別，影響壓力測試結果。另外一方面，爲了避免影響正常業務，壓測時每每須要在業務低峯期壓測，好比22點之後或者早上9點之前。
壓測測試時儘可能使用線上流量或者模擬線上流量。由於線上業務的訪問模型並非平均的，無差異壓測和模擬線上流量的模型的壓測他們二者的結果每每會差別很大。
不要從單一的服務器發起流量。一是壓測時容易達到壓測機器的瓶頸，影響壓測結果；另外一方面，因爲網絡鏈路中負載均衡、會話保持等功能的存在，單臺機器壓測每每會負載不均，也會影響壓測結果。

那麼該選用哪一個壓測工具呢？ab 和 wrk 均是比較經常使用的開源壓測工具。相較於ab，wrk的性能相較於ab性能更好，並且支持經過lua腳本構造特定的壓測請求，因此wrk用的更爲普遍。開源壓測工具雖然勝在簡便和免費，可是使用它們模擬線上流量很是複雜，故不考慮選用。

基於以上壓測注意事項，咱們選用WeTest自研的壓測大師。它能夠很方便的根據線上流量模型模擬壓測請求，讓壓測數據更爲準確。

主要是配合客戶側進行壓測，依據線上流量模型壓測結果以下：

能夠看到：

業務全鏈路容量是 58K TPS，核心投票邏輯拉取榜單、獲取投票狀態以及投票容量分別能夠達到18K、4K、13K TPS。
時延、TPS以及成功率均符合預期（投票是因爲投票業務自己的流控限制）

服務限流

爲了保障投票系統在過載的狀況下不會出問題，咱們須要服務限流。

限流是一個很是常見的功能，好比在 nginx/openresty 等網關中，限流能夠限制併發鏈接數（ngx_http_limit_conn_module 模塊 / resty.limit.conn 庫）或者 QPS （ngx_http_limit_req_module 模塊 / resty.limit.req 庫）；在數據庫中，鏈接池也能夠看做是限流的一種（golang 的 database/sql 庫中 DB 對象維護着鏈接池）。

在本文中討論的是接入層網關，故限流指的是請求限流（好比QPS）。

限流業務場景

接入層限流在不一樣的業務場景下也有不一樣的職責。限流一般用於保護後端服務或者當前服務不被流量沖垮，保障服務的高可用性，常見的好比接入層網關的限流功能或者各類RPC/微服務框架的限流插件（好比 Sentinel 框架），這種狀況下，服務的可用性更爲重要，偶爾的限流不許是能夠接受的；限流也能夠用於調用計費，好比騰訊云云市場會將服務商的 API 以流量包(調用次數)的形式售賣給客戶，針對 API 調用頻次進行計費，由於涉及到錢，這種狀況下 API 的調用次數就要求絕對精確，不容閃失。

雲 API 網關當前針對於這兩種場景的限流場景均有限流策略，前者在 API 網關叫限流，能夠從 API 維度、API 組維度以及用戶維度(須要配合鑑權)對請求進行 QPS 限流；後者對應雲 API 網關配額概念，該功能當前主要提供給雲市場使用，用於精確計算調用次數。

限流算法

限流算法分爲單機限流和全侷限流，對於業界常見的單機限流的算法對好比下：

（當前業界主流應用層限流方法是令牌桶算法或漏桶算法。）

實際接入層網關業務每每是分佈式的，單機限流並不能知足須要，每每須要分佈式限流。雖然能夠經過預設，將限流值平均到每臺機器上，但若負載流量不均勻、機器宕機或者臨時擴容，均會嚴重影響分佈式限流功能。

一般，當前的生產級分佈式限流均是集中式限流方案：

全侷限流狀態在一個集中式節點/集羣維護（好比redis等），按期向這個中心計數或者取令牌
集中式節點/集羣也存在可能性不可用，若不可用，則一般辦法是將分佈式限流退化成單機限流。

雲 API 網關當前是基於滑動窗口算法實現的單機限流，經過一個集中式節點維護全侷限流狀態（跟CLB的全侷限流方案一致，後續會在TAPISIX的實踐中優化掉）實現分佈式限流。

配置方法

該如何使用雲 API 網關配置限流呢？

上面壓測代表業務總體容量在 58K 的 TPS上下，故按照後端50%最高負載保證業務穩定性，設置該總體業務的 API 組限流（或者說是服務限流）爲 30K

參考下圖設置 API 組限流（服務限流）

服務降級

服務降級本質是解決訪問量過大與資源有限的矛盾，經過將一部分不重要的業務禁掉，來給核心業務分配更多的資源，保障核心業務以及整個系統平穩運行。

服務降級分類

顧名思義，服務降級須要犧牲一些功能，一般有以下幾種：

類型	簡介
次要功能禁用	經過限流或者中止次要業務，保障核心業務更多的資源
功能降級	功能或業務自己簡化處理邏輯或者簡化返回內容
一致性	強一致性降級爲最終一致性

對於創造營小程序，是經過對次要 API 進行限流（調低限流值或者將限流值調0），限制次要業務，實現服務降級。

配置方法

那麼如何使用雲 API 網關配置服務降級呢？

區分核心和次要業務。創造營小程序的核心業務是投票以及掃碼，次要業務是抽獎和兌獎功能。
針對次要業務，使用 API 限流功能，對次要接口進行限流。故決賽當晚，對抽獎和兌獎 API 設置較低的 API 限流，保障投票等業務的資源不被搶佔。

參考下圖對次要業務的 API 進行限流

（若是請求被雲 API 網關限流，會返回429錯誤碼，客戶端側須要對該錯誤碼做必定優化處理。例如，優化提示「投票業務繁忙，請稍後再試」或者內部重試）

結語

通過如上一系列高可用準備，《創造營2020》決賽之夜中創造營小程序平穩度過多輪投票小高峯，順利保障小姐姐 C 位出道。

Serverless 做爲雲計算的新技術、新趨勢，在愈來愈多的技術場景中，依靠其自身優點，充當着重要的角色。本文中的 API 網關就是承載着 Serverless 應用的 HTTP 服務接入層。除此以外，Serverless 還包括雲函數、Serverless Framework 等衆多重要組成部分，若是您對 Serverless 技術感興趣，能夠訪問騰訊雲 Serverless 瞭解更多信息。