作者：子矜

审核 &校对：风云

编辑 &排版：酒圆

“今年 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 协议，并且结合压测场景做了抽象，让用户可以界面化的使用不同协议的压测。

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

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

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

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

HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept:xxxxxxxxxxxxxxxxxxxx

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

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

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

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

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

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

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

最后

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

另外，PTS 推出了新的资源包售价，以及更低价格的 JMeter 专属资源包，现在正值双十一优惠中，全场 88 折起，最低可到 0.99 元，关于 PTS 的更多问题和产品建议，欢迎大家扫码进群沟通。

相关链接

1)阿里云 PTS:https://pts.console.aliyun.com/#/overviewpage2)PTS资源包购买https://common-buy.aliyun.com/?commodityCode=ptsbag#/buy