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

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

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

不一般的投票

【投票】是一個很簡單的功能，但是《創造營》的投票不一樣，

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

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

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

Serverless

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

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

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

高可用之道

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

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

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

1. 小程式通過外網訪問 API 網關，API 作為接入層
2. 為每個業務創建 restful API，轉發到后端的不同業務
3. 掃碼服務用于跳轉到該小程式
4. 為小姐姐撐腰的功能是由投票服務提供
5. 抽獎和兌獎服務則分別提供抽獎以及兌換獎品的功能

在云 API 網關創建的 API 如下圖所示：

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

分析

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

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

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

高可用之術

壓測

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

1. 做業務壓力測驗時，最好使用線上的資料和線上的環境，因為測驗環境和線上環境往往存在各種各樣的差異，影響壓力測驗結果，另一方面，為了不影響正常業務，壓測時往往需要在業務低峰期壓測，比如22點以后或者早上9點以前，
2. 壓測測驗時盡量使用線上流量或者模擬線上流量，因為線上業務的訪問模型并不是平均的，無差別壓測和模擬線上流量的模型的壓測他們兩者的結果往往會差異很大，
3. 不要從單一的服務器發起流量，一是壓測時容易達到壓測機器的瓶頸，影響壓測結果；另一方面，由于網路鏈路中負載均衡、會話保持等功能的存在，單臺機器壓測往往會負載不均，也會影響壓測結果，

那么該選用哪個壓測工具呢？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 網關配額概念，該功能當前主要提供給云市場使用，用于精確計算呼叫次數，

限流演算法

限流演算法分為單機限流和全域限流，對于業界常見的單機限流的演算法對比如下：

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

實際接入層網關業務往往是分布式的，單機限流并不能滿足需要，往往需要分布式限流，雖然可以通過預設，將限流值平均到每臺機器上，但若負載流量不均勻、機器宕機或者臨時擴容，均會嚴重影響分布式限流功能，

通常，當前的生產級分布式限流均是集中式限流方案：

1. 全域限流狀態在一個集中式節點/集群維護（比如redis等），定期向這個中心計數或者取令牌
2. 集中式節點/集群也存在可能性不可用，若不可用，則通常辦法是將分布式限流退化成單機限流，

云 API 網關當前是基于滑動視窗演算法實作的單機限流，通過一個集中式節點維護全域限流狀態（跟CLB的全域限流方案一致，后續會在TAPISIX的實踐中優化掉）實作分布式限流，

配置方法

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

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

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

服務降級

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

服務降級分類

顧名思義，服務降級需要犧牲一些功能，通常有如下幾種：

對于創造營小程式，是通過對次要 API 進行限流（調低限流值或者將限流值調0），限制次要業務，實作服務降級，

配置方法

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

1. 區分核心和次要業務，創造營小程式的核心業務是投票以及掃碼，次要業務是抽獎和兌獎功能，
2. 針對次要業務，使用 API 限流功能，對次要介面進行限流，故決賽當晚，對抽獎和兌獎 API 設定較低的 API 限流，保障投票等業務的資源不被搶占，

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

（如果請求被云 API 網關限流，會回傳429錯誤碼，客戶端側需要對該錯誤碼作一定優化處理，例如，優化提示“投票業務繁忙，請稍后再試”或者內部重試）

結語

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

Serverless 作為云計算的新技術、新趨勢，在越來越多的技術場景中，依靠其自身優勢，充當著重要的角色，本文中的 API 網關就是承載著 Serverless 應用的 HTTP 服務接入層，除此之外，Serverless 還包括云函式、Serverless Framework 等眾多重要組成部分，如果您對 Serverless 技術感興趣，可以訪問騰訊云 Serverless 了解更多資訊，

One More Thing

3 秒你能做什么？喝一口水，看一封郵件，還是 —— 部署一個完整的 Serverless 應用？

復制鏈接至 PC 瀏覽器訪問：https://serverless.cloud.tencent.com/deploy/express

3 秒極速部署，立即體驗史上最快的 Serverless HTTP 實戰開發！

傳送門：

• GitHub: github.com/serverless
• 官網：serverless.com

歡迎訪問：Serverless 中文網，您可以在 最佳實踐 里體驗更多關于 Serverless 應用的開發！

推薦閱讀：《Serverless 架構：從原理、設計到專案實戰》

標籤：其他

上一篇：matlab的多目標遺傳演算法

下一篇：Nginx服務器端到端CPS（連接數）滿負載情況下提升