干货分享:细说双 11 直播背后的压测保障技术

简介: 阿里云 PTS 站在双 11 巨人的肩膀上,是阿里全链路压测的延伸。PTS 通过伸缩弹性,轻松发起用户百万级别的流量,免去机器、人力成本;PTS 对流量的控制,能够实时脉冲,精准控制; 是应对视频直播快速攀升的流量脉冲的优秀方案。

作者:子矜

“今年 1 月到现在,淘宝直播的用户超过了 5 亿,到 8 月份流量也增长了 59%,在最核心的商家 GMV 上增长了 55%。双 11 是从 10 月 20 日晚开始的,我们希望淘宝直播作为主场去承接这件事情。”日前,淘宝事业群直播事业部负责人程道放在接受 21 世纪经济报道记者采访时透露,过去一年的直播可谓热闹,今年会更加专业化。

干货分享:细说双 11 直播背后的压测保障技术_第1张图片

如此大的用户体量下,直播类应用给后端服务带来了一些什么不一样的挑战呢?我们今天来介绍一些直播的架构,以及针对这个架构,给我们的应用架构带来的挑战。

直播的架构

我们通常看到的有下面几种直播:

  1. 单人直播,例如淘宝直播,通常伴随着秒杀,弹幕,送火箭等业务逻辑;
  1. 多人同时直播,例如连麦,会议;
  1. 录播,对于部分直播场景如培训、会议等,需要将现场直播视频保存以进行传播、留存等使用,有对直播进行录制的需求。这种往往对实时性要求不高。

而当用户观看直播时,如果服务接入了 CDN,若接入 CDN,播放端选择就近的 CDN 节点进行拉流播放,此时拉流压力在 CDN;若未接入 CDN,播放端从直播源站进行拉流。

下图是一个比较常见的视频流的架构和两条数据走向:

干货分享:细说双 11 直播背后的压测保障技术_第2张图片

  1. 视频流推拉逻辑,如蓝色线所示
  1. 常规的业务逻辑,如黄色线所示

可以看到有四个主要模块:

  1. 推流端:主要的作用在于采集主播的音视频数据推送到流媒体服务端;
  1. 流媒体服务端:主要作用在于把推流端传递过来的数据转换成指定格式,同时推送到播放端方便不同播放端用户观看,当然目前云产商也流媒体服务端的一整套解决方案;
  1. 业务服务端:主要处理一些常见的业务逻辑,如秒杀,弹幕等等;
  1. 播放端:播放端简而言之就是拉取音视频进行播放,把相应的内容呈现给用户。

四个关键的模块的协议其实就是流媒体传输协议。大部分直播的结构都采取上图的格式,较大的区别是是否引入 CDN。一般来说,我们建议客户引入 CDN 来减少直播流量对服务器的冲击。四个模块之间的协议并不着重强调一致性。

接下来,我们沿着这个架构来讨论一下,在这其中比较脆弱的风险有哪些,以及我们如何提早通过压测来排查这些风险点。

直播中的挑战

挑战一:视频流给流媒体服务端的压力

在这个推拉的逻辑中,由于涉及视频的流量较大,经过的路线较长,对流媒体服务器都会造成冲击;通场的做法是引入 CDN,当用户开始收看视频的时候,会先就近去 CDN 拉取流,如果这个时候视频内容还没有缓存在 CDN 的时候,CDN 就回源到流媒体服务端。

但是,风险就存在在瞬间大量用户同时收看 CDN,CDN 大量回源的时候;这种脉冲流量,会给流服务端带来不可预计的效果。

我们通常通过压测来提前验证链路的有效性,甚至可以通过压测,提前把视频在 CDN 预热。然而,传统的 HTTP 请求协议是无法支持这种场景的,因为:

  1. 即使开源软件 srs_bench,以及 JMeter 都提供了一些插件来使用。但是这些开源软件需要用户对视频协议有比较深入的理解,使用门槛会略微偏高;
  1. 视频压测本身对带宽的要求非常高,这就意味压测机器成本比较高;
  1. 视频压测需要考虑到地域对传输质量的影响。

针对以上问题,PTS 加入了 RTMP/HLS 协议,并且结合压测场景做了抽象,让用户可以界面化的使用不同协议的压测。

干货分享:细说双 11 直播背后的压测保障技术_第3张图片

除此以外,PTS 还提供丰富的编排模式,可以方便自如的对场景进行编排;更重要的是,还可以利用 PTS 全国定制的模式,模拟客户从不同的地方发起请求,更快捷的探测出问题。

挑战二:低延时的互动协议

和传统的大促不一样,直播往往追求和线下客户的互动。例如弹幕,评论,聊天,秒杀等等。主持人聊的 热火朝天,用户毫无反应,这就是一次失败的直播了。而普通的 HTTP 请求无法满足对时效的需求;因此,通常这些功能用WebSocket来实现的。因为 HTTP 是一种无状态的、无连接的协议,WebSocket 则通过服务端/客户端建立长链,来保证消息的实时性、以及降低性能开销。

每建立一个 WebSocket 连接时,在握手阶段都会发起 HTTP 请求。通过 HTTP 协议协定好 WebSocket 支持的版本号、协议的字版本号、原始地址,主机地址等内容给服务端。报文的关键地方在于 Upgrade 的首部,用于告诉服务端把当前的 HTTP 请求升级到 WebSocket 协议,如果服务端支持,则返回的状态码必须是 101:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept:xxxxxxxxxxxxxxxxxxxx

有了上述返回,Websocket 连接才建立成功,接下来就是完全按照 Websocket 协议进行了数据传输了。

针对 WebSocket 的通信过程,JMeter 提供了插件来模拟整个过程,但是它也需要用户理解协议的玩法,使用起来相对晦涩。PTS 通过抽象业务含义,用户通过场景配置和施压配置,仅需要配置压测 url 等基本配置、出参设置、检查点设置等几个简单参数,就能够把复杂协议玩起来。

干货分享:细说双 11 直播背后的压测保障技术_第4张图片

除了在直播中使用,Websocket 也广泛应用于在线游戏、股票基金、体育实况更新、聊天室、弹幕、在线教育等实时性要求非常高的场景。

挑战三: 高并发的脉冲流量

不同于普通应用,直播类应用的使用时间段非常的集中,因此在这短短几小时之间,会涌入大量的用户,一次大 V 的直播通常就会造成百万级的用户登录,故直播系统对应脉冲流量的能力要求也变得很高。而且在抢货的时候,和传统的秒杀不同,往往是主播进行到某个时间突然发起秒杀的--这个时间往往无法非常精确--同时脉冲流量对系统的要求极高,很多平时不会出现的问题,例如懒加载,jit 预热,冷热数据切换等传统大流量不会出现的问题,都会出现。

这两点特性,要求压测工具能够瞬间发起大流量。这除了需要较多的机器引擎,还需要对流量的有精准控制--满足流量快速攀升的诉求。

而这两点,正是阿里云 PTS 的强项。阿里云 PTS 站在双 11 巨人的肩膀上,是阿里全链路压测的延伸。PTS 通过伸缩弹性,轻松发起用户百万级别的流量,免去机器、人力成本;PTS 对流量的控制,能够实时脉冲,精准控制; 是应对视频直播快速攀升的流量脉冲的优秀方案。

最后

PTS 针对视频、直播行业的变化,对 PTS 支持的协议做了全面升级。它不光支持传统的 HTTP 请求,更是引入了 HTTP 2、流媒体、MQTT 等多种协议,让用户可以 Test Anywhere!

原文链接
本文为阿里云原创内容,未经允许不得转载。

你可能感兴趣的:(devops运维)