腾讯云 Serverless 保障《创造营》硬糖少女 C 位出道

腾讯云serverless团队 • 2023-01-02 • 云技术社区 • 287 阅读

立即点击-> 选择您最喜爱的框架，免费体验 Serverless Demo

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 网关配额概念，该功能当前主要提供给云市场使用，用于精确计算调用次数。

限流算法

限流算法分为单机限流和全局限流，对于业界常见的单机限流的算法对比如下：

限流算法	优点	缺点	参考库
固定窗口	实现简单	临界问题，不适合周期长的限流
滑动窗口	实现简单，解决限流临界跳变	限流算法精度有限、不够平滑（触发限流只能丢包）
漏桶算法	平滑流量，限流后通过流量恒定	无法应对突发流量	ngx_http_limit_req_module 模块
令牌桶算法	可以应对突发流量	流量不平滑

（当前业界主流应用层限流方法是令牌桶算法或漏桶算法。）

实际接入层网关业务往往是分布式的，单机限流并不能满足需要，往往需要分布式限流。虽然可以通过预设，将限流值平均到每台机器上，但若负载流量不均匀、机器宕机或者临时扩容，均会严重影响分布式限流功能。

通常，当前的生产级分布式限流均是集中式限流方案：

全局限流状态在一个集中式节点/集群维护（比如redis等），定期向这个中心计数或者取令牌
集中式节点/集群也存在可能性不可用，若不可用，则通常办法是将分布式限流退化成单机限流。

云 API 网关当前是基于滑动窗口算法实现的单机限流，通过一个集中式节点维护全局限流状态（跟CLB的全局限流方案一致，后续会在TAPISIX的实践中优化掉）实现分布式限流。

配置方法

该如何使用云 API 网关配置限流呢？

上面压测表明业务整体容量在 58K 的 TPS上下，故按照后端50%最高负载保证业务稳定性，设置该整体业务的 API 组限流（或者说是服务限流）为 30K

参考下图设置 API 组限流（服务限流）

Serverless

服务降级

服务降级本质是解决访问量过大与资源有限的矛盾，通过将一部分不重要的业务禁掉，来给核心业务分配更多的资源，保障核心业务以及整个系统平稳运行。

服务降级分类

顾名思义，服务降级需要牺牲一些功能，通常有如下几种：

类型	简介
次要功能禁用	通过限流或者停止次要业务，保障核心业务更多的资源
功能降级	功能或业务本身简化处理逻辑或者简化返回内容
一致性	强一致性降级为最终一致性

对于创造营小程序，是通过对次要 API 进行限流（调低限流值或者将限流值调0），限制次要业务，实现服务降级。

配置方法

那么如何使用云 API 网关配置服务降级呢？

区分核心和次要业务。创造营小程序的核心业务是投票以及扫码，次要业务是抽奖和兑奖功能。
针对次要业务，使用 API 限流功能，对次要接口进行限流。故决赛当晚，对抽奖和兑奖 API 设置较低的 API 限流，保障投票等业务的资源不被抢占。

参考下图对次要业务的 API 进行限流

（如果请求被云 API 网关限流，会返回429错误码，客户端侧需要对该错误码作一定优化处理。例如，优化提示「投票业务繁忙，请稍后再试」或者内部重试）

结语

经过如上一系列高可用准备，《创造营2020》决赛之夜中创造营小程序平稳度过多轮投票小高峰，顺利保障小姐姐 C 位出道。

Serverless 作为云计算的新技术、新趋势，在越来越多的技术场景中，依靠其自身优势，充当着重要的角色。本文中的 API 网关就是承载着 Serverless 应用的 HTTP 服务接入层。除此之外，Serverless 还包括云函数、Serverless Framework 等众多重要组成部分，如果您对 Serverless 技术感兴趣，可以访问腾讯云 Serverless 了解更多信息：https://cloud.tencent.com/product/serverless-catalog