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

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 网关的缘由。小程序

上图是创造营小程序的简化架构图:

  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 实战开发!

传送门:

欢迎访问:Serverless 中文网,您能够在 最佳实践 里体验更多关于 Serverless 应用的开发!


推荐阅读:《Serverless 架构:从原理、设计到项目实战》

相关文章
相关标签/搜索