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

作者：子矜

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

​

直播的架构

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

1. 单人直播，例如淘宝直播,通常伴随着秒杀，弹幕，送火箭等业务逻辑；

2. 多人同时直播，例如连麦，会议；

3. 录播，对于部分直播场景如培训、会议等，需要将现场直播视频保存以进行传播、留存等使用，有对直播进行录制的需求。这种往往对实时性要求不高。

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

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

​

1. 视频流推拉逻辑，如蓝色线所示

2. 常规的业务逻辑，如黄色线所示

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



1. 推流端：主要的作用在于采集主播的音视频数据推送到流媒体服务端；

2. 流媒体服务端：主要作用在于把推流端传递过来的数据转换成指定格式，同时推送到播放端方便不同播放端用户观看，当然目前云产商也流媒体服务端的一整套解决方案；

3. 业务服务端：主要处理一些常见的业务逻辑，如秒杀，弹幕等等；

4. 播放端：播放端简而言之就是拉取音视频进行播放，把相应的内容呈现给用户。

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

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

直播中的挑战

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

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

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

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

1. 即使开源软件 srs_bench，以及 JMeter 都提供了一些插件来使用。但是这些开源软件需要用户对视频协议有比较深入的理解，使用门槛会略微偏高；

2. 视频压测本身对带宽的要求非常高，这就意味压测机器成本比较高；

3. 视频压测需要考虑到地域对传输质量的影响。

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

​

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

和传统的大促不一样，直播往往追求和线下客户的互动。例如弹幕，评论，聊天，秒杀等等。主持人聊的 热火朝天，用户毫无反应，这就是一次失败的直播了。而普通的 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 等基本配置、出参设置、检查点设置等几个简单参数，就能够把复杂协议玩起来。

​

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

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

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

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

最后

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

原文链接

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

​