騰訊雲 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 閘道器的原因。
上圖是創造營小程式的簡化架構圖：
- 小程式通過外網訪問 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 瞭解更多資訊。
One More Thing
3 秒你能做什麼？喝一口水，看一封郵件，還是 —— 部署一個完整的 Serverless 應用？
複製連結至 PC 瀏覽器訪問：https://serverless.cloud.tencent.com/deploy/express
3 秒極速部署，立即體驗史上最快的 Serverless HTTP 實戰開發！
傳送門：
- GitHub: github.com/serverless
- 官網：serverless.com
歡迎訪問：Serverless 中文網，您可以在 最佳實踐 裡體驗更多關於 Serverless 應用的開發！