*作者：子矜*

*稽核&校對：風雲*

*編輯&排版：酒圓*

“今年 1 月到現在，淘寶直播的使用者超過了 5 億，到 8 月份流量也增長了 59%，在最核心的商家 GMV 上增長了 55%。雙 11 是從 10 月 20 日晚開始的，我們希望淘寶直播作為主場去承接這件事情。”日前，淘寶事業群直播事業部負責人程道放在接受 21 世紀經濟報導記者採訪時透露，過去一年的直播可謂熱鬧，今年會更加專業化。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4516a119de58407285b68fe1dc305677~tplv-k3u1fbpfcp-zoom-1.image)

如此大的使用者體量下，直播類應用給後端服務帶來了一些什麼不一樣的挑戰呢？

我們今天來介紹一些直播的架構，以及針對這個架構，給我們的應用架構帶來的挑戰。

# 直播的架構

我們通常看到的有下面幾種直播:

1. 單人直播，例如淘寶直播,通常伴隨著秒殺，彈幕，送火箭等業務邏輯；
2. 多人同時直播，例如連麥，會議；
3. 錄播，對於部分直播場景如培訓、會議等，需要將現場直播影片儲存以進行傳播、留存等使用，有對直播進行錄製的需求。這種往往對實時性要求不高。

而當使用者觀看直播時，如果服務接入了 CDN，若接入 CDN，播放端選擇就近的 CDN 節點進行拉流播放，此時拉流壓力在 CDN；若未接入 CDN，播放端從直播源站進行拉流。

下圖是一個比較常見的影片流的架構和兩條資料走向：

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d441884675374793bd19fb258b9e0157~tplv-k3u1fbpfcp-zoom-1.image)

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 協議，並且結合壓測場景做了抽象，讓使用者可以介面化的使用不同協議的壓測。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5091b655b6374252947e0e24606df0d5~tplv-k3u1fbpfcp-zoom-1.image)

除此以外，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 等基本配置、出參設定、檢查點設定等幾個簡單引數，就能夠把複雜協議玩起來。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9cfa791e08d24a569298c0acf8ab01e3~tplv-k3u1fbpfcp-zoom-1.image)

除了在直播中使用，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/#/overviewpage
2)PTS資源包購買
https://common-buy.aliyun.com/?commodityCode=ptsbag#/buy

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f85216fe448c4036858a10721d62e719~tplv-k3u1fbpfcp-zoom-1.image)

乾貨分享：細說雙 11 直播背後的壓測保障技術

相關文章