阿里云：2022泛娛樂行業技術服務白皮書（127頁）.pdf

《阿里云：2022泛娛樂行業技術服務白皮書（127頁）.pdf》由會員分享，可在線閱讀，更多相關《阿里云：2022泛娛樂行業技術服務白皮書（127頁）.pdf（127頁珍藏版）》請在三個皮匠報告上搜索。

1、目錄CATALOG一、引言2.1 泛娛樂行業的構成 2.2 直播業務類型、應用、及趨勢 2.2.1 游戲業務IP打造三種模式理念 2.2.2 數字文化產業的開拓 2.3 行業競爭格局 2.4 行業合規性 030304040506二、什么是泛娛樂3.1 直播類泛娛樂 3.1.1 直播類泛娛樂定義 3.1.2 直播類業務場景與架構 3.1.3 直播類泛娛樂技術服務 09091315三、泛娛樂典型業務架構與場景 3.1.4 直播電競賽事場景 3.1.5 通用直播場景 3.1.6 出海業務直播場景 3.2 游戲類泛娛樂 3.2.1 游戲泛娛樂定義 3.2.2 游戲泛娛樂技術服務 3.2.3 游戲泛娛樂

2、場景與架構 3.2.4 游戲技術服務演進 3742566262651101134.1 游戲運維SRE實踐 4.1.1 制定SRE黃金準則 4.1.2 游戲自動化運維體系構成 4.1.3 游戲部署的自動化實踐 4.2 游戲穩定和安全的具體案例 116116117117120四、泛娛樂業務保障與調優最佳實踐 五、未來趨勢 引言近年來，泛娛樂這個概念伴隨著視頻直播和游戲行業的繁榮不斷被提及。簡單來說，泛娛樂行業的核心特點是基于移動互聯網與在線內容生成這兩個領域的共生，圍繞IP(Intellectual1Property，知識產權)來產生實時流量和互動訪問，這個IP可以是一個特色人物、一個故事、一個角

3、色或者任何能獲得大量用戶喜愛的事物。不同于以影視、音像、游戲、體育為代表的傳統文化娛樂行業，泛娛樂往往通過直播等互動性顯著的互聯網傳播方式，將內容輸出方與用戶緊密連接，并且讓用戶本身也是內容生產的一份子。這就從更多維度上滿足了用戶的娛樂核心需求，包括嘗鮮、有趣、陪伴圍觀、零距離、隨時隨地這6個維度上的訴求分解，使得泛娛樂能擁有更為廣泛的用戶群，付費率更高但同時使用門檻更低，為這一行業的發展無疑帶來了廣闊的前景。本作圍繞泛娛樂行業的定位和構成，從淺入深地對泛娛樂的競爭格局和發展驅動力進行分析。對這一行業的重點產業直播、游戲、數字文化進行逐一解構。從產業構成的角度來說，獨立運營的直播平臺和依據成熟

4、的產品擴充而來的直播視頻生態，為泛娛樂行業傳播提供重要渠道。游戲直播又是直播視頻行業的重要分支，也是通過游戲的IP塑造與娛樂直播結合形成網狀產業鏈的典型。通過直播視頻行業的傳播力和兩種游戲IP塑造的源動力，進而形成一種數字產業文化。從競爭格局的角度來說，從直播視頻產品與文學、漫畫、電影、游戲等進行聯動，到游戲產品與體育電競、文學小說、連載動漫等進行延伸，再到新舊文化由直播視頻、游戲產品等進行傳播，泛娛樂行業的競爭格局體現出具有生態型的特色。從行業發展的角度來說，當代多元化的消費觀下更多人愿意為價值認同和文化符號買單是促進這一行業發展的內在動力。同時需求又激發了市場，5G、VR、云技術、大數據等

5、越來越多的新技術率先與這一產業結合落地，助力行業產品更廣、更迅速的傳播和帶來更真實的線上體驗，這形成了產業發展的外在動力。最后，我們在看到泛娛樂行業高速發展的同時，也不能忽視潛在的風險問題。世界各國政府都對數字經濟下的數據安全、隱私保護等主題紛紛立法，越筑越高的監管防護線勢必影響泛娛樂行業所匯聚的大量數據場景和產品01 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書紛紛立法，越筑越高的監管防護線勢必影響泛娛樂行業所匯聚的大量數據場景和產品的野蠻生長。企業需要時刻以法規為基線，將數據保護和隱私合規中形成體系化，才能擁有泛娛樂行業中可持續發展的堅實基礎。同時本作為讀者展開基于行業視角講述泛娛樂行

6、業，考慮到面向讀者均為在技術領域有所沉淀，將重點講述技術服務中涉及到泛娛樂業務場景、架構以及相關活動形態，在泛娛樂典型業務架構與場景一章中，以多個泛娛樂行業業務場景組成，在直播方面包含了通用直播、電競直播、出海等等場景，游戲方面不僅在游戲技術服務本身，還包含了新興業務形態陪玩業務的技術服務等，力求以真實的客戶案例來為讀者展開一幅生動形象的“穩定性畫像”。主編團隊阿里云王超、李斯達、王海忠、陳陽、陳慶康、張醫博、周建平、林萬境、孫鴻杰、羅世杰、陶博偉、劉清龍、姚陽、陳幸達、胡政安永(中國)企業咨詢有限公司張楠馳、周亮宏顧問組團隊阿里云萬誼平、袁浩鈞、解航、鮑遠松、李昶、李彬、鄭園、鄭雯、顧鑫 安

7、永(中國)企業咨詢有限公司高軼峰泛娛樂行業技術服務白皮書 02二、什么是泛娛樂2.1 泛娛樂行業的構成泛娛樂行業以線性、網狀價值鏈連通各產業，構造娛樂產業的大融合。在現代數字技術的快速發展前提下，信息技術推動傳統產業進行數字化轉型傳統產業與現代信息平臺融合，從而產生泛娛樂產業融合的現象。從行業整體來看，創新創意一直是社會不斷進步發展的前提。利用數字化技術的快速發展，以娛樂為核心的產業采用AI視覺、高質量影像、智能語音等跨界技術，以信息技術為橋梁，形成各娛樂產業的網狀式鏈接。從縱向的產業功能分工角度來看，結合音像效果和快速迭代的通信技術而發展起來的新媒體、結合3D動畫和硬件設備的快速發展而興起的

8、虛擬現實游戲、結合文化創意產業發展而興起的周邊產品制作與傳播等環節同樣具有價值增值功能，它們表現為娛樂產業的線性價值鏈，涉及供應鏈、技術開發、設計、生產制作、推廣等環節。泛娛樂是在直播、游戲、文化等領域，以IP為核心，多種文創業務領域均有涉及的一種互動娛樂新生態。泛娛樂的使命就是讓文化以契合時代的創意形態，走進生活。2.2 直播業務類型、應用、及趨勢在近兩年疫情環境下，“宅家”生活越來越成為生活常態，這就給長、短視頻和直播行業帶來巨大機會與增長。泛娛樂直播從大方向分為以下兩種類型：03 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書在獨立型直播產品用戶不斷增長的情況下，很多大型企業依托于自身

9、龐大的用戶群體來發展導流型直播產品。根據后疫情時代中國泛娛樂市場展望報告顯示，超八成的被訪談者表示會在后疫情時代繼續觀看網絡直播。直播給用戶帶來的“心理負擔”較弱，符合直播隨開隨看、不用過于集中注意力的特性。同時也說明直播平臺對用戶的粘性與其是否滿足用戶對內容上的需求息息相關。游戲直播隨著龐大的游戲群體和電競行業興起而不斷發展起來，用戶在游戲直播區的觀眾數量和觀眾活躍度在整個直播市場都占據絕對優勢。而游戲直播就是娛樂直播與游戲產業結合形成網狀產業鏈的典型。用戶通過在游戲中體驗和游戲自身IP的塑造，并可通過游戲直播連接起更寬廣的市場。2.2.1 游戲業務IP打造三種模式理念2021年，受益于科技

10、發展的成熟，元宇宙的概念備受矚目，國際知名社交軟件公司Facebook甚至更名為Meta。元宇宙概念與泛娛樂概念相輔相成，它主要以游戲為基石打造的虛擬現實發展而來。IP在游戲領域重中之重，它通常依據下面兩種模式理念運行。經典游戲IP打造模式：經典游戲往往會營造出一個經典的世界觀，采用虛構的或是基于神話傳說歷史等文化元素，塑造被大眾廣泛認同的價值觀。其他IP源拓展到游戲領域：一些體育類競技有著龐大的用戶基礎，而推出該領域的直播產品類型獨立型直播產品導流型直播產品直播產品特點盈利方式通過獨立運行的公司，產品首先發布，用戶和主播通過該產品鏈接。依賴成熟的產品，該產品有固定用戶群，通過增添直播功能，打

11、通產業鏈。獨立運營盈利流量內部變現泛娛樂行業技術服務白皮書 04游戲是對基礎IP進行游戲領域的擴充，讓用戶體驗虛擬競技的樂趣。泛娛樂IP以多領域共同發展，利用原始IP在文化領域上的不斷深耕，打造直播、游戲領域的成熟運營，向文化領域發展，建立整個泛娛樂IP的布局。2.2.2 數字文化產業的開拓在泛娛樂IP中，中國文化傳遞下來的IP各式各樣。在數字發展的大環境下通過泛娛樂文化領域，我們可以將數字文化產業以如下兩種特點進行開拓。雙核心并發：以互聯網和傳統文化為雙核心，互聯網提供技術和用戶群，傳統文化提供IP，在雙核心基礎上進行創意創新，打造新時代的數字文化。世界格局：不僅僅將眼界局限于歷史文化，還可

12、以在未來科技和太空等領域，接入世界各領域體系，以世界的觀念進行匹配發展，在全球市場中開拓一條獨有的數字文化泛娛樂領域。2.3 行業競爭格局泛娛樂行業競爭已由單體型競爭轉為生態型競爭。以直播產品為例，獨立型直播產品就是典型的單體競爭，他們根據獨立的產品各自競爭拉攏各自的用戶群體。而導播型就是一個生態型競爭的雛形，根據其他產品的龐大的用戶群體為基石，嵌入直播等功能，比如戶外旅游直播、體育直播、游戲直播、財經直播、教育直播、資訊類直播、媒體類直播，從而形成初步的產品生態，下圖是中國直播類APP的競爭格局。05 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書2021年，國內視頻用戶直播用戶躍升到6.

13、1億，而游戲用戶規模6.66億。中國游戲市場實際銷售收入突破2900億元，直播行業收入突破1500億元。導播型直播導播型直播導播型直播導播型直播圖2.1 直播類APP競爭格局泛娛樂行業技術服務白皮書 06泛娛樂行業以直播領域、游戲領域和文化領域進行融合，形成整個生態性的競爭格局。如長視頻領域的生態競爭，長視頻產品與文學、漫畫、電影、游戲等進行聯動，用戶根據不同喜好對特定的企業泛娛樂生態進行選擇，企業通過擴展自身泛娛樂生態而吸引更大的客群，獲取更高的利潤。在整個全球數字市場中，頭部娛樂類APP下載熱度始終居高不下。根據數據顯示，南美，東南亞和中東等新興市場的娛樂類App下載量持續增長，增速遠超中

14、國，2021用戶總量直播行業游戲行業5.866.26.46.66.82021用戶總量總體營收直播行業游戲行業01500290020004000游戲行業直播行業圖2.2 2021中國游戲和直播行業用戶量和總體營收07 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書例如南非和菲律賓的APP下載增速都超過10%，如圖2.3所示。中國不僅僅可以針對美歐等發達國家市場，在新興市場上也可以進行提早布局。再以游戲領域舉例，從過去五年發展走勢看，我國游戲出海呈現平穩上升態勢，用戶下載量，使用時長和付費額度三方面均保持了穩定增長。2021年自主研發游戲海外市場銷售收入180.13億美元，較去年增收25.63億

15、美元，同比增長16.59%。2021年上半年，中國移動游戲在各國份額增長如圖2.4所示，在德國的市場份額增長率飆升至28%，在韓國市場，中國移動游戲發行商繼去年經歷較大突破后今年市場份額增長有所放緩，目前所占份額接近23%在其他一些市場。2.4 行業合規性在黨的十九大報告中指出要“健全現代文化產業體系和市場體系，創新生產經營機制，完善文化經濟政策，培育新型文化業態”。按照我國法制建設的步伐，泛娛樂行業結合直播、游戲、文化等涉及的數據隱私問題也將會是一個非常值得企業關注的話題。無論是我國出臺的網絡安全法、數據安全法、近期施行的個人信息保護法，還是歐盟的歐盟數據保護條例（GDPR）、美國的加州消費

16、者隱私 圖2.4 中國2021發行商各國份額 圖2.3 各國APP下載總量增長率 2019各國APP下載總量增長單位：%南非菲律賓沙特阿拉伯巴西05102015增長百分比2021中國發行商在各國份額單位：10億美元美國韓國加拿大澳大利亞051015增長份額市場份額泛娛樂行業技術服務白皮書 08法(CCPA)等都對存儲、傳輸、處理個人信息都有著嚴格的條款。在泛娛樂行業中直播視頻、游戲、文化等產業整合、出海的過程中，都要特別注意行業的法律法規，遵循泛娛樂產業政策和行業監督。三、泛娛樂典型業務架構與場景3.1 直播類泛娛樂3.1.1 直播類泛娛樂定義直播在泛娛樂行業中屬于對最終用戶有直觀感受且最終用

17、戶受用成本最低的一種方式，直播從場景屬性來分類有：電競直播、通用直播、移動直播等，根據不同的直播屬性在面向不同的技術服務場景中各有不同，且面向的監控指標與評價體系不同，在我們所面向的技術服務用戶中，對于直播類泛娛樂的定義為，使用終端設備通過直播平臺進行多元化娛樂的實時展示在最終用戶的顯示終端上，其中包含了觀看、互動(包含彈幕、禮物、小游戲等場景)、會員制、排名等，通過這種方式實現以平臺為中心的各供應鏈資源、服務的整合并最終實現流量收益或者其他更明確的商業盈利邏輯。而對于技術領域，特別是技術服務領域，在不同的直播場景有不同的方式進行保障，一般由以下幾個維度：業務品類：直播從傳統秀場直播發展到如今

18、的頂流直播、電商直播、電競直播、戶外直播等等多種品類。業務指標：對于直播技術的要求也越來越高，包含不僅限于直播質量、切換速度、交互體驗、多視角功能等。09 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書技術指標：這些直播的要求指標來自于不同場景之間的要求，比如卡頓指標、延遲指標、碼率指標、幀率指標、秒開率指標、首包指標等，具體的場景將在接下來幾章進行闡述。2016-2022直播行業從當初的藍海走向紅海期間遇到了新的機遇與挑戰一方面，直播行業相關政策密集出臺，秀場、游戲、房間直播行業將在政策監管下愈加規范化，未成年人保護、內容版權保護等法規持續落實；另一方面，直播相關企業積極踐行企業社會責任，

19、以“直播+”的方式傳播社會公益，讓直播為社會發展貢獻力量。在未來，直播將在更嚴格的行業監管和更多元的市場競爭中繼續穩步發展。早期萌芽資本涌入穩定增長激發增長泛娛樂行業技術服務白皮書 10廣義來講，直播包含：直播平臺提供PAAS層的接入，以SAAS層面的內容處理，這部分廠商不關心基礎的IAAS資源，選擇多云廠商備份的方式進行災備冗余，平臺方專心做好自己的調度策略，保證切換自由；直播內容展現內容從主播PK、才藝秀、游戲賽事、體育賽事等多豐富內容的視頻服務推流/publisher在直播平臺上注冊的個體主播用戶，或者現場的直播信息采集、轉播等渠道連麥需要定義一下參與的角色，按用戶在連麥直播中的角色差異

20、分別定義為：主播、連麥者(粉絲)、觀眾。直播技術的不斷突破引入了多種方式，如粉絲連麥、主播PK；彈幕在直播過程中用戶的實時評論，支持文字、圖片彈幕等。截止至2021年6月，我國網民規模達10.11億，其中，約9.44億人看網絡視頻(含短視頻)，6.38億人看視頻直播。所以視頻相關的泛娛樂活動，已經成為互聯網的主流。而泛娛樂的視頻直播，更是占據了半壁江山。泛娛樂直播指主要業務為傳播泛娛樂直播內容，并提供用戶與主播進行實時互動功能的直播活動。泛娛樂直播起源于秀場社區，自2008年上線后，在PC端擁有一定量的用戶基礎。2016年開始，移動直播迅速崛起，用戶流量迅速趕超PC端用戶規模，并逐漸拉開差距。

21、移動直播的興起，除降低了直播的門檻、拓展了傳播渠道外，也激發了直播的社交屬性，激活了直播的潛在用戶。隨著直播“百家爭鳴”的亂象逐漸消失，泛娛樂直播逐漸開始細分化，向游戲、綜藝、體育等場景下沉。同時，一些頭部短視頻的平臺，借助自身的流量優勢，大力發展直播業務。同時借助直播的社交屬性，讓用戶的互動形式更加豐富，為其他業務帶來活力。11 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書視頻直播業務市場需求互動社交已經成為互聯網年輕用戶的強需求：90、95后用戶習慣于通過網絡來釋放自己的壓力，交友需求更強烈。而語音、視頻、直播三者結合，產生了實時直播、語音電臺、語音聊天室等多種娛樂形式，解決了用戶交友

22、痛點，為用戶打造更真實高效的交友場景。更新鮮的社交玩法具有高度吸引力：線上心理解壓需求增多，以及二次元聲優的普及，社交平臺的分類版塊逐漸豐富，不僅可以開發單人多人聊天室，還能在線上進行游戲，同時直播功能的加入，使得語音聊天與直播聊天雙管齊下。對于看慣了秀場2021年6月我國網絡用戶規律和網民使用率用戶規律網絡視頻(含短視頻)93.40%80.30%67.40%63.10%46.40%9438481208680986376946859網絡購物網絡音樂網絡直播網絡外賣網民使用率泛娛樂行業技術服務白皮書 12直播的用戶來說，這種多人互動、雙人互動的形式，更加擁有私密感，成為了絕大多數用戶新的寄托。3

23、.1.2 直播類業務場景與架構近些年隨著移動網絡及客戶端能力的不斷提升，直播業務場景得到進一步拓展，越來越豐富，從傳統傳媒、體育賽事擴展到在線教育、游戲、娛樂帶貨等領域；涌現出一批直播平臺依托云廠商的直播產品構建直播業務，提供由主播發起直播供海量觀眾觀看的服務；本節內容將介紹常見的直播業務邏輯及其特征：一次完整的直播過程，從邏輯上來講可以分為三個部分：3.1.2.1 流接入流接入是指將直播推流數據，推送到云平臺(如阿里云視頻直播服務)由云平臺進行后續的處理及分發；最常見的接入方案，一般分為兩種：1）主播推流到全球的分布式流媒體分發網絡，并且把流存儲在里面，作為直播源站，當有觀眾播放時，通過全球

24、的分布式流媒體分發網絡接入和收斂找到源流，完成直播；2）推流端推流到直播平臺自建源站，當有觀眾播放時，先經過全球分布式流媒體分發網絡接入和收斂，然后回源站拉流，無人播放就斷開回源拉流；直播流接入直播流處理直播流分發主播推流GRTN流媒體分發觀眾13 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書3.1.2.2 流處理直播流接入到云平臺后，往往還需要對直播流進行后續的處理以滿足業務需求：轉碼：通過轉碼處理可以將原始流轉換為不同的碼率/分辨率/幀率的視頻流，因而提供不同規格的視頻流供不同網絡環境下有著不同播放需求的觀眾自由選擇；錄制：直播是實時的流媒體數據，提供實時畫面，直播結束后則無法繼續觀看

25、直播內容；錄制處理是指在直播過程中將實時流媒體數據保存為flv/mp4/hls切片等形式，用于后續進行點播回看直播畫面；截圖：截圖是指將直播過程中的畫面按指定的時間間隔保存為圖片，以滿足特定業務需求，例如將截圖作為直播間封面展示，以吸引終端用戶預覽實時直播畫面進入直播間觀看；智能檢測(涉黃、涉恐、涉暴)：直播截圖除了作為封面展示外，還有另外一個重要的用途，即違規檢測；可以利用只能審核服務等自動檢測截圖內容是否違規(例主流的推流協議一般為RTMP，主要的推流客戶端有ffmpeg、obs等，部分直播平臺由主播通過私有協議直接推流至自建源站；觀眾拉流GRTN拉流用戶源站泛娛樂行業技術服務白皮書 14

26、如涉黃等)，及時的發現違規直播內容，并由直播平臺關停直播，避免造成違規內容傳播，擴大影響；對于直接推流到云平臺的場景，流處理由云平臺進行；對于部分主播直接推流到自建源站的場景，流處理(轉碼/截圖/審核等)也可由自建源站進行；3.1.2.3 流分發主流直播平臺往往針在全球范圍內提供服務，一次熱門的直播可能有海量的觀眾同時觀看，這些觀眾可能來自于全球不通的國家地區、不同的運營商網絡；為數量眾多分布廣泛的用戶提供穩定穩定流暢的直播服務，必須依賴內容分發網絡(CDN)；因此直播服務往往和CDN緊密結合，依托廣泛分布的CDN節點承接海量的用戶播放請求；主流的播放協議有 RTMP、HTTP-FLV、HLS

27、。3.1.3 直播類泛娛樂技術服務3.1.3.1 技術服務前半段收集業務需求溝通業務目標/業務范圍工作項目 狀態阿里跟進人進度備注必要性活動日程峰值帶寬預估業務目標范圍觀眾分布客戶端信息精確到日期、活動時間、重要場次等 帶寬 或 最高同時在線人數*碼率全球、海外、國內，國內是否集中在特定地區必要必要必要15 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書工作項目狀態阿里跟進人進度備注必要性拉流協議直播架構直播域名直播流直播中心推流app_name碼率確認錄制需求確認轉碼需求確認截圖需求確認水印需求確認安全策略點播回看域名轉推需求確認主站附帶CDN資源 rtmp/flv/hls主動推流、回源拉

28、流、中心/邊緣合流等方案確認 url鑒權、防盜鏈、https 域名、量級、OSS源站是否轉推第三方廠商，轉推方案CDN/DCDN域名需求，如主站、圖片等，量級、資源評估；所有推拉流域名，及其映射關系 詳細的流名推流碼率/播放碼率必要必要必要必要必要必要必要必要必要必要必要必要必要必要泛娛樂行業技術服務白皮書 163.1.3.2 技術服務后半段3.1.3.2.1 制定直播方案可靠健壯的推流方案，是直播全程推拉流穩定的重要保障；制定推流方案，主要從容災、高可用的角度考慮，通過推流端依賴公網、專線分別進行主備推流、根據推流環境適當采取“邊緣推流”或“中心推流”、服務端合流自動切換等手段，保障整個推流

29、鏈路的穩定可控，避免因為單一設備或鏈路的質量問題而導致直播斷流、幀率波動等情況影響直播穩定；3.1.3.2.2 業務容災策略客戶只使用阿里云的情況(一般客戶或集團內部的活動直播，如云棲大會)直播中心容災，即在不同直播中心配置備用域名；當出現直播中心故障時，推流端切換備用推流域名，客戶端切換備用拉流域名；(直播中心出現故障的幾率較低，且需要客戶端具備切換域名的能力，因此這種方式一般不會采用，只有極為重要的活動直播才會采用）客戶同時使用多家CDN廠商的情況(業內成熟的直播平臺都這么做)多廠商容災，客戶通過直推、轉推、回源拉流等方式，同時使用多家CDN廠商(不同廠商域名不同，在播放器層面按比例下發不

30、同廠商的播放地址)，當其中一家CDN廠商出現故障時，客戶端支持自動或手動切換到其他廠商的線路，保障用戶側可以正常觀看直播；3.1.3.2.3 現場容災策略指直播攝像設備、推流設備以及推流上行網絡鏈路層面的容災；現場通過“公網+專線”或“公網不同運營商”分別推主流和備流，不同推流采用獨立的攝像、推流設備；設備：推流設備一般采用硬件編碼器(直播視頻終端，這貨長啥樣見文末)或筆記本電腦(對性能要求較高，有定制的推流專用筆記本)；17 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書移動網絡：一般現場推流的硬件編碼器還支持4/5G移動網絡，作為公網/專線的備份，進一步保障了網絡鏈路的可靠性；硬件編碼器

31、的“坑”：硬件編碼器有一個容易踩坑的功能，即聚合功能(如下圖)，開啟聚合功能的時候，編碼器會往“聚合服務器”推流，“聚合服務器”是硬件廠商維護的，例如可能位于深圳；假設直播活動現場在杭州，從杭州通過CDN推流到上海直播中心，如果開啟直播聚合功能，推流會先從杭州繞到深圳，再從深圳經由CDN到上海直播中心，顯然繞了一大圈，同時引入了一段不穩定的公網鏈路；因此這種情況下需要關閉編碼器聚合功能；通過直播全鏈路可以發現該現象，例如：本應該是杭州客戶端IP推流到杭州CDN節點，結果卻是非活動現場的IP(例如深圳IP)推流到廣東CDN節點(甚至硬件廠商恰好將聚合服務器部署在阿里云，則可以看到是推流客戶端是阿

32、里云的IP)出現這種情況，讓現場推流老師關閉硬件編碼器聚合功能即可；3.1.3.2.4 云上容災策略推薦使用“合流”方案，即直播中心配置合流功能，將stream_a、stream_b主備兩路流在中心合并為stream_c，stream_c下發給終端播放器播放；這樣的好處，中心合并為stream_c；假設stream_a為先推上來的一路，則使用stream_a生成合流stream_c，當stream_a發生異常時，stream_c立即自動切換為stream_b；以此實現單路流異常時自動切換，不影響stream_c觀看；泛娛樂行業技術服務白皮書 18異常切換的觸發條件：(假設當前stream_a先

33、推上來)1）斷流，當stream_a斷流時，則合流stream_c立即自動切換到stream_b；幀率不穩定，當前流stream_a持續6秒沒有數據，則合流stream_c也會自動切換到stream_b；默認是6s可調整為3s，建議調整；防止出現以下幀率波動周期在6s內的情況無法觸發切換；3.1.3.2.5 客戶端優化這部分內部涉及客戶端改造，需要提前很久規劃當同時使用多家CDN廠商提供服務時，播放器需要具備自動或手動切換線路的能力，例如當A廠商服務異常(如卡頓、無法播放、花屏等)時，播放器不再默認調度到A廠商，切換到B廠商線路；播放器播放&彈幕&點贊等功能解耦，防止彈幕觸發性能瓶頸影響基礎播

34、放功能；(一般不需要關注這一點，不過有些客戶的活動頁面委托第三方開發，不是很健壯，可能存在這個風險）對于直播APP，客戶端需要具備錯誤日志上報的能力，例如出現直播播放失敗、卡頓的情況，主動上報“異常時間、直播流、客戶端IP、服務端IP、錯誤詳情”等信息，用于快速發現和定位問題；3.1.3.2.6 服務端優化3.1 直播類泛娛樂 3.1.1 直播類泛娛樂定義 3.1.2 直播類業務場景與架構 3.1.3 直播類泛娛樂技術服務 19 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書工作項目優化項阿里跟進人備注拉流域名覆蓋節點調優推流并發數限制保障推流節點穩定性重要尤其是預估帶寬量大的時候，例如超過

35、300Gbps，需要評估當前調度資源是否能承接；根據預估帶寬峰值調整域名調度域或補充節點；重要如果推流客戶端在阿里云云上，例如為ECS，可以采用ABTN節點覆蓋，走ABTN鏈路推流以提升穩定性；針對CDN邊緣推流域名，根據推流客戶端所在地區運營商，補充優質推流節點，觀察節點近期服務質量穩定可靠；和PE報備活動期間推流節點不會人為下線改造；一般不需要，除非客戶有特殊要求；正式直播開播后，提交邊緣預熱；將直播流預熱到邊緣節點拉流節點推流限制轉碼限制推流節點重要對于新增域名，默認推流并發限制20，轉碼限制10，回源拉流限制10，尤其需要關注調整；對于現有業務域名，需要關注quota用量，保障直播期間

36、不會耗盡Quota影響推流/轉碼；調整推流/轉碼限制，保障活動期間充足可用；邊緣節點中心節點優化轉碼模板域名突增上量報備加白重要尤其是預估帶寬量大的時候，例如超過300Gbps，需要評估當前調度資源是否能承接；如：rtmp鏈路協議棧優化重要性一般限流策略：直播限流策略：1分鐘內的突增帶寬達到50 Gbps，服務端進行限流CDN限流策略：1分鐘內的突增帶寬達到10 Gbps，服務端進行限流域名突發需向工單報備協議棧優化轉碼優化上量報備重要性一般一般不需要；如有需要得和客戶提前協商，配置并使用專用的轉碼模板；集團直播活動如云棲大會等可以考慮；配置窄帶高清轉碼泛娛樂行業技術服務白皮書 203.1.3

37、.2.7 制定推流方案下面提供幾個典型直播活動案例的推流方案供參考；不同客戶有不同的用法，往往自己有很強的業務容災能力；2021云棲大會直播架構：3.1.3.2.8 方案實施直播方案明確后，接下來就是方案實施了；理論上我們只負責云上的穩定性即可(包括資源優化容災調優配置等)，諸如專線施工、場館網絡穩定性由客戶及其供應商負責；但有些注意點可以提醒客戶重點關注；客戶：創建直播域名、配置推拉流域名關聯、URL鑒權、HTTPS證書等；阿里云：進行資源調整、限額調整、服務端合流、調優等配置；3.1.3.2.9 網絡環境實施高速通道專線施工：流程繁雜進度慢，要把控施工進度，在活動前期完成，同時預留充足的調

38、試和演練時間；根據并發推流路數和碼率計算采購專線帶寬，保留充足的Buffer，防止專線上行帶寬被占用影響推流；專線施工完成后可以通過Iperf3來壓測，確保專線上行帶寬能力符合預期；針對專線上行帶寬使用情況配置監控，實時檢測專線用量；21 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書現場公網施工：如果是臨時搭建的場館，如云棲大會的很多分會場，往往現場網絡穩定性存在很大的風險(如水晶頭接觸不良、光纖折彎、交換機端口插錯、IP沖突等)，需要安排充分的網絡連通性測試，每個會場至少準備2根網線以作備份；同時需要盡可能地從方案架構上規避單點網絡問題；如果是已有場館，如XX國際會展中心等，往往已經具備

39、成熟穩定的網絡環境；直播演練，演練主要是為在所有環境ready后，進行各項功能的驗證(例如合流切換、錄制等)，模擬真實直播場景測試；演練項演練方式通過標準各場館同時推流，所有流質量穩定；所有直播流合流切換正常；所有場館演練同時推流，觀察所有流質量穩定驗證并發推流能力（專線和公網的上行能力）合流功能測試并發推流測試聲音畫面正常，幀率碼率符合約定（如30幀 3Mbps）在所有直播場館進行推流測試，查看聲音、畫面、流幀率、碼率符合預期；流質量測試錄制、轉碼、截圖、水印等效果效果正常；推流查看錄制、轉碼、截圖、水印等效果是否符合預期媒體功能測試上行推流鏈路符合預期，包括出口IP，調度節點等；各場館/設

40、備推流，查看所有直播設備CDN推流調度符合預期（或可以正常通過高速通道直推中心）；上行鏈路測試所有場館網絡測試正常；在所有直播場館進行推流測試，驗證各場館網絡可用性，包括公網和專線；場館網絡測試對所有直播流進行合流切換測試，驗證合流功能正常；1）依次推流Stream_a、Stream_b，觀察合流Stream_c播放是否正常；2）斷開Stream_a，觀察合流Stream_c是否正常切換到Stream_b；3）恢復Stream_a，斷開stream_b，觀察合流Stream_c是否正常切換到Stream_a；泛娛樂行業技術服務白皮書 223.1.3.2.10 部署監控方案客戶側監控不同客戶應對

41、不同規模的直播活動各自的監控能力、監控方案也有所不同；系統監控 諸如字節、快手、虎牙這樣業內非常成熟的直播平臺，客戶擁有完備的客戶端直播質量監控體系可以及時準確的監控客戶端不同線路(廠商)、地區、運營商的播放質量，并根據質量結果，自動或手動的進行線路切換，從而實現質量監控和治理恢復的目標；依賴客戶完備的直播監控系統，在出現質量問題時(例如單節點跑滿影響單地區直播質量)，客戶往往也可以提供更詳細的信息，包括卡頓流、地區運營商、客戶端IP、服務端節點IP等，幫助我們快速的定位、排除服務端問題；人工監控有很多直播場景，不具備客戶端自動化的監控能力，客戶側通常會安排人工盯屏的方式，監控直播畫面質量；例

42、如2021年云棲大會，除了現場同學全程盯屏觀看每個直播會場的畫面、聲音之外，遠程安排多位運營同學負責觀看真實直播間畫面，如有問題及時人工上報；阿里云側監控服務端監控，目前依賴的監控平臺(渠道)主要有：陸吾平臺重保大屏、廣目系統、告警機器人、天眼全鏈路等，不同平臺各有優勢，往往結合使用，下面逐一介紹：流媒體陸吾平臺-直播重保流大屏示例：2021云棲大會，主論壇&分論壇共107場，主備合流的架構，同時在線流數多；重保大屏在多場館推斷流協調、幀率/碼率等指標監控等場景，提供了很大的便利；23 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書阿里云監控功能可以將多路直播流合成統一路畫面，當其中的有流出

43、現異常時(例如幀率連續波動超過30%左右)，通過畫面(綠色變紅色)和聲音(嘀聲)的方式進行告警；https:/ 24工作項目備注原流卡頓、花屏原流有雜音、聲音小、音畫不同步轉碼流卡頓、花屏、音畫不同步、雜音推流客戶端IP非現場網絡并調度至別處（例如杭州直播到全鏈路顯示推流IP為深圳）推流客戶端正確但調度節點不準部分用戶拉流卡頓集團活動直播，外部觀看正常，部分園區觀看卡頓如果是全局問題，重推當前主流，使合流自動切換至備流；如收流節點各項指標正常，一般是現場網絡問題，建議檢查現場網絡，例如上行是否穩定；檢查拉流節點狀態，及時調整異常節點；檢查拉流節點如無異常，建議內部集中觀看，或通過移動網絡觀看，

44、同時可聯系IT保障園區網絡；重推當前主流，使合流自動切換至備流；通知推流現場檢查并調整收音（一般通過現場導播接入音頻信號）如原流穩定轉碼流異常，聯系阿里重啟轉碼，一般重啟轉碼可恢復；有條件的話可以將原流和轉碼流Dump下來，便于后續分析原因：Rtmpdump-i rtmp:/xxxxx-o xx.flv檢查是否硬件編碼器推流且開啟了聚合功能，關閉聚合功能重新推流；檢查客戶端DNS配置是否準確（如不準，調整客戶端DNS重新推流）；檢查調度策略是否符合預期（如不符合預期，調整調度節點，Dns ttl時間后重新推流）；3.1.3.3.1 整體系統架構2020年11月4日，國家網信辦正式發布互聯網直播

45、服務管理規定，對互聯網直播服務提供者互聯網直播發布者和用戶的相關行為作出規范，對一些不合法的直播行為做出了約束。新規要求：互聯網直播服務，要“先審后發、即時阻斷”。該規定自2020年12月1日起施行。下圖的架構設計，囊括了直播內容的產生、存儲和消費的整個生命周期，每個階段都有相應的措施，通過“防、控、封、堵”等多種方式，來確保直播安全。25 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書第1塊橙色部分是內容生產安全模塊。這個模塊主要是對內容生產者進行身份驗證，以確保內容生產者的合法性，盡可能從源頭上規避非法發布者產生非法內容。是直播安全的第一道防線。第2塊是審核及管控模塊，對應架構圖中的黃色

46、部分。這個模塊是整個直播安全體系的核心，這個模塊主要對內容生產后進行檢查審核，并對非法內容的播放進行管控。第3塊是播放安全模塊，對應架構圖中淺藍色部分。這個模塊主要是對觀眾身份進行驗證，以確保直播內容不被別人所用，保障內容的安全性，同時，有效解決盜鏈問題，確保資產安全，避免資損。上面3個模塊是傳統直播安全體系必備的模塊，主要解決內容的安全問題，契合了互聯網直播服務管理規定中先審后發、即時阻斷的要求。我們在實際的業務運維中發現，直播基礎架構與直播的質量和穩定性息息相關，基礎架構的安全也至關重泛娛樂行業技術服務白皮書 26要。因此，我們把架構安全也納入直播安全體系里面來圖中金色部分是架構安全模塊，

47、在這里面有一些特殊的設計，我們后面會講到。3.1.3.3.2 內容生產安全我們知道，直播是一種實時性、互動性顯著的互聯網傳播內容的形式。不同于傳統的文字、圖片視頻等傳播形式，直播緊密的將用戶與直播內容交互在一起，用戶本身也是內容生產的一份子。因此很有必要對生產內容的用戶進行嚴格管控，進行有效的身份驗證。要對身份進行驗證，最有效的手段就是進行鑒權。鑒權有多種方式。通常是通過時間戳管控有效期，通過加密算法驗證身份合法性。傳統方案的做法是：用戶與平臺協商一個密鑰，將用戶推流的url、時間戳、密鑰等信息構成一個字符串，按照約定的算法將字符串轉化成相應的鑒權信息；相關信息發送到CDN節點后，由CDN進行

48、比對；如果時間戳在約定范圍內，且鑒權值正確，則正常服務；反之，則拒絕。這種方案，需要把密鑰部署到CDN。這樣，除了平臺內部以外，多了一個鑒權key泄露的風險。所以，在我們設計的方案里，我們推薦對內容安全有要求的用戶，使用遠程鑒權。推流鑒權通過推流遠程鑒權CDN直播中心同步鑒權鑒權回調主播推流推流放行27 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書3.1.3.3.3 審核及管控安全近些年來，由于視頻業務爆發，對視頻監管及審核提出了更高的要求，視頻直播的識別及審核規格要升級。審核規格的升級，往往意味著技術難度和成本的增加。如何在滿足業務需求的情況下，選擇成本最優的智能審核方案，是每個直播平臺

49、面對的難題。一般情況，要做嚴格的審核，采用1s一張的非關鍵幀的截圖，是一個比較穩妥的做法。但非關鍵幀的截圖，對截圖服務的機器開銷會比較大，即客戶的使用成本會比較高。如果是大平臺，流的數量非常大，全量走非關鍵幀截圖，成本開銷會非常大。因此，考慮采用差異化的截圖策略，在成本和收益上，做到一個平衡，以期通過技術手段，在避免成本的浪費的同時，最大程度上做到識別不遺漏。比如：核心大主播，這類主播數量少，但重要性高，容易被人關注及攻擊，走非關鍵幀截圖；敏感高危類目走非關鍵幀截圖；游戲直播和賽事直播走關鍵幀截圖。這里說的非關鍵幀截圖，是指強制1s一張截圖；關鍵幀截圖，是根據用戶推流的gop每個gop截一張。

50、直播中心錄制服務截圖決策服務非關鍵幀截圖阿里云截圖服務阿里云內容審核服務鍵幀截圖人工內容審核存儲服務CDN斷流&封禁人工審核安全截圖策略調整內容安全策略阿里云封禁服務是否違禁關鍵截圖是否疑似違禁是是否主播推流泛娛樂行業技術服務白皮書 283.1.3.3.4 播放安全內容生產安全和內容審核管控是從內容的產生和管理角度去解決安全問題，這兩個是直播內容安全的基礎。但是在一些一旦犯錯就會產生巨大影響的場景下，需要有更嚴格的管控措施。這就要求我們在播放側，也需要有一些安全措施來加以保障。比如一些敏感內容或者大型活動的直播，這類內容的關注度超高，一旦內容審核有所遺漏，哪怕只是一幀畫面，也會產生巨大的輿論影

51、響，造成播出事故。對于這種場景，推薦使用阿里云直播產品延遲播放的能力，給審核以足夠的時間進行逐幀確認，確保播出安全。延遲播放在日常一些需要確保時效性的場景下是不適用的，因而延遲播放的能力需要能細化到對直播流粒度的管理。當然，有一些業務場景，比如部分用戶需要實時，而部分用戶需要延遲，也可以采用延遲播放來滿足。播放遠程鑒權異步鑒權鑒權回調主播推流推流放行是CDN斷流&封禁阿里云封禁服務直播中心播放放行是否是播放拉流延遲播放拉流CDNCDN關鍵截圖業務關播CDN關播流在線29 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書3.1.3.3.5 內容安全阿里云視頻加密方案包含兩部分：加密轉碼+解密播放

52、。加密轉碼：流程13。主播推流到直播中心后，直播服務負責通過密鑰管理服務KMS生成明文Key和密文Key。通過直播轉碼服務，使用明文密鑰對音視頻進行對稱加密，并將密文Key存入視頻封裝。解密播放：流程411。播放終端如需播放此直播流，需向應用服務器AppServ-er發起播放請求，獲取播流URL。使用播流URL向直播服務請求視頻流。直播服務將經過轉碼的加密視頻和密文Key傳輸到播放器SDK。播放終端用密文Key向直播服務獲取二次加密后的明文Key，直播服務再通過密文Key向密鑰管理服務KMS獲取明文Key。播放終端將解密得到的明文Key傳給播放器SDK，播放器SDK解密視頻進行播放。3.1.3

53、.4 技術摸索帶來的收益協議分類層面RTMP協議工作在TCP之上，是應用層協議，默認的端口是1935。RTMPE在RTMP的基礎上增加了加密功能。泛娛樂行業技術服務白皮書 30RTMPT工作在HTTP之上，默認端口是80或443，可穿透防火墻。RTMPS類似RTMPT，增加了TLS/SSL的安全功能。RTMFP為RTMP協議的UDP版本。SRT是基于UDT的協議(UDT協議是基于UDP的傳輸協議，在IETF已經提交了4個版本）RTC(Real1time1communication)實時通信，是實時音視頻的一個簡稱，我們常說的RTC技術一般指的是WebRTC技術，已經被W3C和IETF發布為正式

54、標準。傳統RTMPRTMP的交互流程可以分為握手過程、控制命令傳輸與數據傳輸。握手過程控制命令傳輸數據傳輸RTMP連接以握手開始，RTMP握手由三個固定長度的塊組成?？蛻舳?發起連接請求的終端)和服務器端各自發送相同的三塊。便于演示，本文將從客戶端發送的這些塊指定為C0、C1 和 C2；將從服務器端發送的這些塊分別指定為 S0、S1 和 S2。RTMP握手以客戶端發送C0和C1塊開始，客戶端要等收到S1之后才能發送C2，客戶端要等收到S2之后才能發送其他信息(控制信息和真實音視頻等數據)，服務端要等到收到C0之后發送S1，服務端必須等到收到C1之后才能發送S2，服務端必須等到收到C2之后才能發

55、送其他信息(控制信息和真實音視頻等數據)。以下為RTMP握手的時序圖介紹。31 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書服務器TCP網絡客戶端C0C0S0S1S2C1C2C1S0S1C2S2末初始化版本已發送確認已發送握手結束版本已發送確認已發送握手結束末初始化RTMP協議太老，且最后一次更新是在2012年；同時HEVC/H.265/AV1等視頻格式都沒有官方定義以至于需要國內CDN廠商自行定義。RTMP連接過程較長，由于RTMP基于TCP(TCP存在三次握手)除此之外，其本身又存在c0/s0到c2/s2的三次握手，再加上Connection，Createstream，Play/Pub

56、lish，總地來說RTMP完成一次建連需要進行9次會話，用于PC端勉強能夠接受，對于移動端網絡質量的要求則很高。RTMP的擁塞控制完全依賴傳輸層，即完全依賴于TCP傳輸層的擁塞控制算法來進行擁塞管理，幾乎沒有什么優化；RTMP本身基于TCP傳輸，無法提供帶寬自適應的算法。在此背景下眾多廠商開始著手提供一些新的直播協議供行業參考。如QUIC、SRT等 SRT泛娛樂行業技術服務白皮書 32SRT 優勢具有非常良好的丟包重傳機制，丟包重傳的控制消息非常豐富，同時支持ACK、ACKACK、NACK我們都知道音視頻對于時間這一點非常在意，而SRT基于時間的報文發送，使其具有良好的防止流量突發的能力。SR

57、T對上層提供了豐富的擁塞控制統計信息，包括RTT、丟包率、Inflight、Send/ReCeive1Bitrate等。利用這些豐富的信息，我們可以實現帶寬預測，并根據帶寬的變化在編碼層去做自適應動態編碼與擁塞控制。SRT 收益數據這是一個編碼后的TS流信號(VBR)，固定幀間隔40毫秒，經過了有損網絡傳輸之后，碼流特性改變，幀間隔也變得不固定。實際上，這樣的信號是幾乎無法解碼出來的。這是SRT協議的效果圖，可以看到SRT在解碼端重新恢復了原有的碼率特性和幀間隔。如圖所示，SRT有一個發送端緩沖區、接收端緩沖區，在發送信號的同時會有一些控制信息或者說反饋信息來實現ARQ糾錯，并且SRT包頭中有

58、精確的時間戳。33 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書SRT應用生產-雙11貓晚會雙路SRT回傳技術，確保如主路信號源發生異常，切換到備路后能夠繼續保持前后畫面同步，真正做到無縫切換，較RTMP傳輸減少30%的延時SRT通過AXP(Application1Exchange1Platform，阿里云視頻云的高性能多UDP協議傳輸平臺)快速集成到TENGINE/NGINX和直播CDN系統中，這也是業內首次將SRT完美集成在TENGINE/NGINX系統中。SRT推流已經支持了H265推流。泛娛樂行業技術服務白皮書 34 QUIC收益QUIC和TCP對比特性你好，服務器你好，客戶端請把

59、url1.jpg給我好的，url1.jpgg給你TCP你好，服務器您好，客戶端，這是我的SSL證書公鑰A和隨機生成的密碼B返回密鑰B的加密信息TCP+TLS你好，服務器（加密）你好，客戶端（加密）請把url1.jpg給我（加密）好的，url1.jpgg給你（加密）QUIC請把url1.jpg給我好的，url1.jpgg給你快速建連O-RTT的握手減少TCP3次握手和TLS的握手時間提升首屏效率多路復用相比于HTTP/2真正的單通道并行傳輸徹底解決TCP協議、中隊頭阻塞問題擁塞算法場景化量打造擁塞算法靈活，不需要基于內核或操作系統，可直接在應用層改造持續在線網絡切換時，持續在線頻繁切換網絡的情況

60、下，不會斷線，不需要重連，用戶無任何感知卡頓與完播率成正相關關系，卡頓與差評成正相關關系，多數卡頓用戶存在退出行為，卡頓會直接影響我轉化率、復購率等核心業務指標,而卡頓通常與網絡傳輸是有關系的。握手次數多 握手延遲增大尤其是對短鏈接的場景，TCP的機制決定了延遲的影響無法消除第一次訪問。握手一次成功后，直接傳輸數據，實現ORTT35 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書阿里云對接各協議支持自由度全稱推出者傳輸層協議目標改進對象主要特性標準化已完成1.0進行中無，聯盟推廣mssms終端廣泛支持，瀏覽器支持較好終端廣泛支持，瀏覽器僅chrome設備圈內、OBS支持，瀏覽器無高，從采集編

61、碼到渲染媒體數據區分優先級多種音視頻特殊傳輸策略低，僅提供傳輸優化音視頻透明傳輸中，擁塞控制簡單音視頻編解碼器不限原生SRT不支持連接遷移延遲支持方案完整性SRTQUICWEBRTCSecure Reliable TransportQuick UDP Internet ConnectionGoogleUDPHTTPWeb Real-Time CommunicationGoogleUDPRTMP完整的端低延遲方案服務端方案缺失弱網對抗模塊豐富媒體傳輸使用RTP協議，媒體協商采用SDP協議，信令控制自主選擇兼具TCP、TLS、HTTP/2等協議的可靠性與安全性UDP建連低延遲低延遲，不依賴編解碼器

62、安全，與QUIC一樣使用TLS1.3基于硬件的方案較多任何類型的視頻或音頻媒體Haivision聯手Wowza UDPRTMP泛娛樂行業技術服務白皮書 36阿里云提供的直播服務能力隨著直播生態日益發展，很多客戶依托阿里云視頻直播、CDN等產品舉辦大型直播活動，如外部客戶英雄聯盟全球總決賽、抖音年度盛典、集團云棲大會等，往往都是客戶極為關鍵的業務活動，其重要性不言而喻，因而對直播穩定、畫面質量有著極高要求，同時諸如英雄聯盟全球總決賽這樣的超大型直播業務，對CDN廠商的帶寬資源也帶來巨大的挑戰；歷次活動直播保障中，服務團隊作為技術服務專家參與全程保障，本文旨在總結分享歷史經驗，共同學習交流，期待更

63、多的同學可以參與到此類項目中，一起建設更加完備的直播保障服務體系和能力；通過下圖快速了解活動直播業務流程：3.1.4 直播電競賽事場景3.1.4.1 電競場景下的挑戰隨著電競逐漸融入年輕人的生活之中，電競對應的大型活動帶來的流量和關注也與之前不可同日而語。而對于云廠商而言，我們需要面對的是一個電競界的“雙十一”。電競賽事會帶來什么樣的考驗呢？如何處理巨幅增長的帶寬37 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書在頂級賽事周期中，每天會有幾個小時突發大量的帶寬，突發帶寬量與游戲的受眾數量、賽事重要程度等相關。但電競還有一些其他行業沒有的獨特影響項，如賽事精彩程度、賽事中出現選手復出或話題時

64、刻等；這些偶發的不可預期的事件，會給賽事活動帶來無法預料的突發，這就要求云廠商有應對突發流量的能力。這些措施不只包括突發時對流量的調度能力、計算能力的橫向擴容，還包括突發前的大量準備動作。關于資源突發的壓力我們可以關注以下幾點：賽事前是否能通過擴容加固的方式應對突發思考活動中是否有不可控的觸發點賽事中突然有增量是否有應急機制直播架構是否完善在大型賽事舉辦之前，客戶通常會針對直播推流、錄制的可靠性進行提升，這里考驗各個廠商的服務能力和產品架構的優劣(這里服務能力是指需求落地的速度和準確性，底層架構的優劣指對定制化需求的兼容)。而廠商本身也需考慮如何去存在一場狂歡帶來的流量，如何將精彩是瞬間順利送

65、達全國乃至全球的觀眾，還需要注意在保障賽事進行的，不影響其他用戶。這就考驗廠商的資源調度和擴容能力，更深一層的諸如日志處理能力等。3.1.4.2 核心衡量指標當我們理清電競賽事活動帶來的挑戰后，我們就需要指標去衡量我們是否已經準備好應對這個挑戰了。當然，各個廠商的服務能力不同，因此這里不會提到標準。帶寬：最明顯的增量，帶寬增量為賽事流碼率X播流數，因此碼率增加(如增加4K頻道或人數增加都會反映到帶寬的增加)。帶寬冗余量受限于各個地區節點機房的出口帶寬，需提前一月甚至數月開始協調準備。QPS：每秒請求數，QPS的瓶頸來源于算力及部分后端模塊處理性能，如日志模塊等。秒開率：該指標為客戶端指標，秒開

66、的定義用戶可自定義，如3s，5s等，超過泛娛樂行業技術服務白皮書 38時長未能返回內容即視為未達到“秒開”效果。秒開通常與網絡掛鉤，廠商可以通過分配合理的節點或做其他優化配置來解決。延時：延遲是指直播推流到用戶收到流之間的時長，這個時間除了網絡側原因和播放端策略外，用戶還可讓廠商提高啟播延遲。更多的延遲意味著更高的buffer，可以減少卡頓的幾率。更低的延遲意味著用戶接收到最新內容的時間較短。如何考量還需要根據廠商能力和用戶要求去決定。錯誤碼：用于標示錯誤信息，通常直播會有另外一套錯誤碼，這與廠商的定義也有關系。從域名日常運行的錯誤碼可以知道是否需要在賽前做檢查優化。節點調度：節點是用于在推流

67、端-直播中心或拉流端-直播中心間做中轉優化，合理的調度能減少推流或拉流的延遲。調度的效果依賴于良好的節點容量、全面的IP庫、合理的調度策略，在這一塊，可能是廠商角力的重點。39 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書3.1.4.3 保障動作&流程泛娛樂行業技術服務白皮書 40賽前準備階段是排除風險，減少后續問題的重要階段，準備階段圍繞以下幾個方面進行：1、信息收集，用于理解客戶需要用到什么產品，在保障時需要關注哪些方面。信息包括：賽事所用的域名/流名、預計突發帶寬和QOS情況(如無，可通過此前類似活動評估）客戶是否有特殊的推/拉流架構，是否有特殊的錄制架構，可與架構師了解哪個環節易出

68、問題，或通過過往工單分析2、此次活動中，有幾種產品參與，哪些存在隱藏的擴容需求。直播通常圍繞視頻直播和CDN產品，若客戶有自建的直播架構，可能還依賴于ECS/ENS等資源。提前了解資源存量，也可拉通各個產品一同保障。主動監控若有較長的準備時間，可主動監控客戶域名數據，針對錯誤碼增高的時刻進行排查和優化，可以提前發現調度不合理或節點異常的問題，減少在賽事活動期間發生問題的概率。若無提前優化的時間，則主要是在賽事期間出現問題時能夠主動發現，快速處理。保障通道疏通在準備期間需要設想風險點，針對不同的問題先準備好對應方案，當后續遇到問題時，有順暢的升級/恢復/擴容手段。賽事活動期間主要考驗對問題的快速

69、發現解決的能力，此時發現的問題已經產生對應后果，需要優先止血，再細查問題。此時也考驗在賽前準備階段的三個方面是否完善。那此時，技術服務的決定性因素在哪里？利用過往對客服務的經驗，對重復問題或相似問題快速識別并解決，或者提供41 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書對應信息給到產研側。站在客戶和業務側的方面，去判斷一個止血方案是否合適，是否需要添加或刪除哪些內容。分配人手負責溝通，讓負責排查的同學無需分心擔負溝通成本。當經歷過重保期間的緊急問題后，我們可以發現，我們前期準備好的升級通道、客戶信息、應對方案是非常有效的。重保期間更側重的是讓事態沿著預想的情況發展，越少的變數和意外情況，

70、說明重保的效果越好。賽事結束后，便是一些收尾階段，通常是由商務對接臨時擴容的退費減容事務。服務團隊需要再關注下業務指標是否有異常，至少業務流量下跌趨于穩定后才能結束重保。此后，便是將重保的整個過程梳理一遍，將賽前準備/賽中情況/賽后分析整理為可復制可沿用的方案留存，后續其他團隊接手時，可通過該方案快速上手，避免因為團隊變換給用戶帶來服務體驗的缺失。3.1.5 通用直播場景3.1.5.1 通用直播架構淺析面對多直播平臺，每日志上億次的請求量，如果對標打造一個高可用高性能架構尤為重要。設計直播架構支持要考慮平臺的日常流量以及激增流量的彈性資源擴容，這些都是在運營期間的不斷數據摸索反饋得到，一臺平臺

71、的橫向快速庫容要求可能是分鐘級，甚至是秒級，如果做不到對彈性的實時要求，很可能會出現平臺崩潰的嚴重情況；首先我們會考慮將直播進行問題，如視頻直播、語音直播。視頻直播里面又劃分了賽事類直播、秀場才藝類，前者需要高清的直播動作畫面，對機器的計算要求較高，如阿里云彈性計算提供的高主頻HFC系列對視頻的支持的高清視頻編解碼的浮點運算；但語音類的直播沒有畫面參與，對視圖計算的要求不高，音頻報文的傳遞實時泛娛樂行業技術服務白皮書 42性要求沒有視頻高，故而可以單獨分離設計；傳統的服務端架構采用的 LVS、Nginx、PHP、MySQL，數據庫和PHP程序之前還會加一層Memcache，除了視頻直播服務端外

72、，直播間的在線用戶、禮物、評論、點贊、排行榜等數據信息時效性高，互動性強，對系統時延有著非常高的要求，也經常用到Redis緩存服務來處理。下面是根據很多我們服務的客戶，綜合彼此的經驗沉淀的一套直播平臺通用的分布式開發的架構，從底層的數據庫，緩存Redismemcache，中間的服務實際服務層?？v向上是煙囪模式，但橫向的每個模塊是獨立解耦，多個服務平行設置后成為一個集群。這里的服務指，從用戶側推流的管理，到直播流服務，以及禮物支付、游戲充值等等，每個都是相對獨立的。43 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書這樣設計的好處：圖中每個服務都可以由不同的Teams完成獨立的迭代開發，對組件

73、的升級互不影響在數據安全性上，部署時不會相互影響；不同功能機器隔離開后防宕機，避免多個服務部署到同臺機器上雪崩，服務在運行過程中可能會出現異常，Java1JVM錯誤或者運行時宕機，網絡異常，經常會遇到的這種情況，一個服務出現了故障不要影響其他的服務。3.1.5.2 典型問題與風險大部分的CDN客戶都希望在上云過程中一切操作配置均由廠商完成，具體涉及到業務方一般也默認在上量前期接受此非標性的配置需求，在實際的技術服務中為配合業務線同學的工作和滿足某客戶的需求，技術服務側在強調風險的情況也承擔了部分運維角色的工作。類“全托管”的技術服務風險點泛娛樂行業技術服務白皮書 44（1）CDN域名配置均由廠

74、商操作，某客戶對業務域名的配置均不知悉，容易出現雙方需求沒有對齊，理解有偏差從而導致達不到某客戶預期，甚至引起業務受損。（2）某客戶側提配置需求和域名上云測試的人非同一個，某客戶內部信息未對齊時，出現信息偏差，容易出現某個域名雖然已經配置但測試人員尚未測試，某客戶的業務側同學就已經直接上云上線，出現業務受損。（3）廠商廠商人員人工配置，由于域名較多，每個域名的配置項過多，出現配置缺漏的情況，影響業務。所以從對內運維的角度看，CDN配置自動化是減少人工失誤的重要運維工具，此需求已反饋至廠商人員側，自動化配置需求已經在跟進處理中。為規避上述風險，需求對接過程，經過多次的交互，沉淀流程如下：45 泛

75、娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書從角色分工來看流程如下：新域名切量量確認相關信息切量保障完成業務測試TAM側與客戶聯調測試TAM側響應并處理灰度切量業務異常匯總復盤不符合預期符合預期域名配置cheklist故障處理完成是否CDN+OSS(對象存儲)場景在處于上云的初步階段的客戶，在此階段架構師一般會為客戶制定了定制化的業務架構方案，部分客戶的架構為CDN+OSS形式，其中還會用到OSS鏡像回源技術回源到某客戶源站。在具體實踐中，某些客戶的運維部門提出上云的一切數據配置類操作均由云廠商負責配置之類的需求，介于業界友商基本存在這種模式，為更好配合業務人員的工作和加快某客戶上量的節奏，

76、所以在確認風險以及相關團隊的支持下，泛娛樂行業技術服務白皮書 46用戶點播APPL1節點L2節點L3節點OSS點播客戶源站請求服務CCN服務請求服務回源請求回源回源請求回源回源請求服務回源CDN+OSS方案中，關于OSS鏡像回源域名是由廠商產研負責維護并進行配置，具體涉及架構如下：需求對接過程沉淀如下：（1）某客戶新增bucket時會提供對應的bucket名稱，和回源的IP，技術服務側側收集整理相關信息后，提產品需求單給OSS研發人員進行配置，OSS研發會給某客戶分配OSS鏡像回源域名（此域名未備案，僅用于OSS的鏡像回源域名解析），用以解析某客戶源站IP。（2）配置完成后技術服務側側會測試鏡

77、像回源域名是否正常解析到了某客戶的源站IP地址，并觀察CDN加速域名的回源狀態碼是否正常，同時同步某客戶側雙向測試確認，某客戶側確認無異常后，此配置需求正常交付。3.1.5.3 活動重保方法論3.1.5.3.1 全量監控某客戶域名出現多次5XX狀態碼異常波動，最終確認是某客戶調度域下的節點集群的設備性能較差，引起的多次5XX異常，因某客戶目前處于上量階段，為保障某客戶業務穩定運行，使用天眼哨兵系統主動監控某客戶全量域名業務指標，優化措施如下:（1）某客戶調度域下更換硬件設備性能較優的節點，提升節點穩定性。此專項優化為期1個月，已將設備性能節點較差的vcache節點全部剔除，并替換成設備性能節點

78、較優的imagehost的節點類型；（2）目前某客戶CDN域名分為大流量域名，小流量域名，未上量域名三個維度47 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書設置不同的閾值進行監控；（3）在釘釘告警群關注監控告警，根據告警排查原因；（4）若告警屬于偶發，未持續，且看各項業務指標均正常，可觀察一段時間，無需通知某客戶；若告警一直持續，且判斷已影響正常的業務，則主動告知某客戶，讓某客戶確認業務是否有異常，并配合某客戶一起排查。3.1.5.3.2 重保動作與流程為保障客戶業務在重大活動中穩定運行，業務異常及時處理，TAM對客戶重大活動全程跟進護航，流程如下：活動資源報備確認相關信息活動結束活動前

79、測試TAM側聯調測試TAM側響應并處理活動護航業務異常匯總復盤不符合預期符合預期直播護航cheklist故障處理完成是否泛娛樂行業技術服務白皮書 48序號檢查項確認事項010203040506客戶信息我方負責人員活動時間主站地址推流域名拉流域名客戶名/群名/UID商務/架構師/技術服務工程師/產研核對活動具體時間核對主站地址推流配置測試是否符合預期拉流配置測試是否符合預期07080910111213推流流并發數限制直播架構AppNameStreamName碼率轉碼模板錄制配置直播中心觀眾分布峰值預估播流協議拉流節點資源附帶靜態資源確認流數水位安全主動推流/觸發拉流/L2回源/中心回源核對app

80、name核對流名評估碼率轉碼模板配置/測試正常轉碼模板配置/測試正常確認所在直播中心region匹配域名加速范圍所需帶寬和在線人數Rtmp/flv/hls根據觀眾分布和預估量級，準備節點資源靜態CDN/DCDN域名，量級、資源評估141516171819（1）重大活動提前一周報備，TAM確定好推拉流域名、流名、碼率、轉碼模板觀眾分布、預估峰值帶寬、播流協議和活動時間等，及時向PDSA確定資源是否滿足條件；直播護航checklist49 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書（2）根據客戶需求配置主備推流，轉碼流，配置完成后交付客戶測試驗收；（3）TAM使用天眼直播大盤全程跟進直播流的

81、業務指標，出現異常告警及時反饋排查處理；（4）活動結束后，匯總活動數據并進行護航總結，并對活動護航遇到的問題進行沉淀。避免再次出現類似的情況。3.1.5.4 移動直播案例直播是某客戶的主要業務之一。某客戶的直播用戶規模大，且場景豐富，包括戶外直播、游戲直播、才藝直播、自拍直播等等。與傳統的一些直播平臺相比，某客戶主播直播時的物理和網絡環境更加多樣化且不可控。此外，某客戶的直播玩法多樣，雖然都屬于直播的范疇，對傳輸的具體要求卻有很大的差異。主播的推流質量，直接影響成千上萬粉絲的觀看體驗。因此，在各種異構且不可控的網絡環境下，保證某客戶內容生產源頭的服務質量，對于提升某客戶的總體用戶體驗至關重要。

82、主播/媒體直播推流SDKSRS流集群推流轉推轉推觸發回源拉流拉流API集群推薦集群轉碼集群錄制/截圖集群內容審核集群數據存儲集群轉碼集群鑒權集群客戶側播放器直播中心CON分發主播直播工具-直播伴侶某客戶直播伴侶降低了某客戶直播的技術準入門檻，使主播可以以最小的學習成本開始直播。泛娛樂行業技術服務白皮書 50直播伴侶直播伴侶豐富直播內容生態，為主播提供清晰流暢的直播工具支持多終端和外設PC直播伴侶手機直播伴侶外接采集卡多協議投屏高清直播支持超清、高清和標清多檔位推流支持hevc推流支持硬件編碼播放端自適應碼率豐富的主播工具語音播報直播間主題和掛件直播間榜單直播競自助可控的KxP協議為了滿足多樣的

83、業務需求，同時能進行深度的優化，某客戶建立了自己的音視頻云端服務，開發了某客戶多媒體傳輸協議KxP(某客戶傳輸協議)，從內容產生的源頭優化用戶體驗。據介紹，某客戶KTP的設計，涵蓋網絡狀態估計、網絡傳輸控制、信源信道聯合優化等多個維度，支持動態碼率自適應幀率自適應、混合FEC/ARQ、非對稱差錯保護等。目前某客戶的主播端均已通過KTP協議將編碼壓縮后的視頻流推流到某客戶的直播源站。源站收流主播/媒體直播在推流到某客戶源站后，源站通過SRS進行收流，SRS是一個簡單高效的實時視頻服務器，支持RTMP/WebRTC/HLS/HTTP-FLV/SRT/GB28181直播伴侶支持多累終端設備（PC，i

84、OS，Android），以及多種模式的投屏。支持超清、高清和標清多檔位的推流。并在直播過程中，將主播采集的視頻進行一系列的處理，例如：水印、美顏和特效濾鏡等。將處理后的視頻經過編碼和壓縮，通過公網推流到源站的推流地址。51 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書自建源站某客戶的自建源站，一部分部署在自建的IDC，一部分部署在阿里云及其他友商的公共云品臺上。通過自建源站，某客戶實現了可以自研推流協議的優勢。且擁有了CDN調度的能力，增強了源站及整個直播平臺容災的能力。使用公共云可以增強平臺的彈性能力，并且在多云策略的舉措下，可以避免被一家云廠商鎖定某客戶對源站的要求非常高，必須有高可靠

85、、高并發和易遷移的特性。高可靠：源站資源和系統要具有冗余的能力，在線上資源出現異常時，保持業務的可持續性；高并發：在面臨突發流量時，源站可以快速擴展一倍以上，對房間的支撐能力和分發能力都有高并發的擴展；易遷移：某客戶業務部署在多個IDC和公共云上。出現服務質量風險或商務風險時，可以實現快速轉移；自建源站賦予了某客戶CDN調度的能力，即各家CDN都需要來某客戶自建源站進行回源拉流。某客戶源站通過控制各CDN的流量比例，在質量和成本間取得最好的折衷。然而，某客戶體量龐大，需要同時使用多家CDN，而各家CDN的質量、價格參差不齊，以及經常有一些不可預知的突發狀況，因此，通過人工調度的方式，顯泛娛樂行

86、業技術服務白皮書 52然是無法接受的。某客戶通過自研智能CDN調度系統，精確捕捉CDN與用戶的動態變化，從而更合理地利用CDN資源，且大大降低觀看故障時長，節約大量人力監控和維護成本。多碼率轉碼某客戶直播的業務場景，尤其是游戲直播，原始推流碼率一般比較高，分辨率要求達到1080p60fps。但每個觀眾由于自身所處的網絡環境或客戶端設備性能問題，使用如此高的分辨率，很容易造成播放卡頓。且帶寬成本非常高。在充分了調研和對比了多種方案后，某客戶選擇基于GPU的轉碼集群方案?；贕PU的方案，雖然畫質比軟件略差，但有高密度、低成本、產品方案成熟的優點?；谏鲜鯣PU轉碼的方案，某客戶可以在端上實現多碼

87、率自適應技術?；谟脩舻慕K端設備、網絡狀態等條件，動態選擇最佳適配的碼率檔位，在觀看流暢度和清晰度之間做好平衡。某客戶的專屬服務體系某客戶實行的是多云戰略，且對供應商的技術水平和服務能力要求非常高。尤其是直播業務，對阿里云平臺的質量和服務人員的效率都提出了比較嚴格的要求。為了滿足客戶的要求，在多家服務商之間脫穎而出，阿里云服務團隊走出了一條定制化服務體系的道路。在某客戶的服務體系中，CBM/SA對整體客戶滿意度負責、PDSA對各自產品的質量穩定性負責；TAM對需求/故障的閉環負責。同時協同產品運營、AES、PE和產研共同處理客戶的問題和需求。TAM需求/故障的閉環負責PDSA質量穩定性負責SA

88、/商務對整體客戶滿意度負責1、產品運營服務穩定性負責，與SA/商務進行互補位。2、二線AES CDN專家接入協助提升一線問題排查、信息收集效率。3、PE、研發一號位明確問題直接負責人，明確直接上升渠道。53 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書在某客戶的服務過程中，L1響應客戶問題的機制多次被客戶挑戰?？蛻艟芙^和L1的小二做溝通，只需要能夠在拋出問題后，快速拿到想要的結果。對中間的處理過程沒有耐心進行跟進和響應。所以在日常服務中，需要TAM同學能夠第一時間響應客戶的問題和需求。并作出準確的判斷，將問題進行閉環或升級。尤其在對客同步問題結論時，TAM編輯好的口徑，要經過內部SA和PD

89、SA的確認，再進行外發。針對某客戶的重大活動，TAM需要牽頭帶動整個服務團隊進行保障。主動收集客戶活動的信息、時間、資源需求、管理實例等。在重保前固化Checklist，并予以逐項的檢查和確認，及時上報潛在的風險。在護航過程中確保人員都能到崗，且進入重保服務的狀態。角色定位角色定位角色定位角色定位角色定位快手CDN服務角色職責劃分服務類客戶問答響應問題排查、日常需求對接監控報警處理服務穩定性及調優類TAMTAMTAMPDSASA;PDSA緊急問題上升；PDSA、SA、PE、研發PTAM TAMPTAM TAMPTAM TAMPDSA;SASA、研發、PEPDSA一號位輔助類一號位團隊組成職責1

90、、第一時間應答應客戶需求2、對于問題進行判斷整理。3、特殊問題和需求及時上升1、跟進整個問題處理環節，并形成問題閉環把握問題處理時間2、階段性同步客戶進展3、對外口徑內部提前確認4、明確問題上升渠道及時推動問題上升1、跟進監控報警數據要求相應2、持續報警行為需要有敏感的意識及時上升并推動排查3、定期梳理，歸納共性區域和現象1、質量調優類（非報警類）quic調優，ipv6調優等2、協調拉通內部資源，推進調優進隊3、階段同步進展和后續規劃日常服務泛娛樂行業技術服務白皮書 54快手CDN服務角色職責劃分啄木鳥需求跟進定制化需求溝通及推動新需求挖掘重大活動周期沉淀和拉通客戶側定期溝通TAMPDSA;S

91、ASASAPDSA;SA運營；TAM運營PTAM、TAM SA、PDSACBMPTAM、TAM PDSASA CBMTAMCBM、SACBM TAM PDSA1、時效性保障2、更新維護3、同步內部進展跟進。1、明確客戶需求背景、預期、場景2、把控開發周期與客戶要求對齊3、充分內部驗證避免半成品1、關注客戶動向在新的場景、新的區域挖掘合作契機2、內部產品、運營拉通反饋有價值的市場信息1、明確重保信息：包括時間、資源要求數據上報要求等2、固化，重保前完成各項準備工作的核驗3、確認現場、線上人員狀態。4、整理信息，并及時復盤1、定期拉通TAMPDSA運營對客戶服務需求進行梳理2、形成紀要并對其下一步

92、Action跟進落地1、從季度會議到周 的維度進行交流需求挖掘及落地為了保障某客戶問題和需求能夠在最短時間內得到有效的處理，針對告警群的問題和客戶群的問題，我們制定了問題快速升級的流程。TAM、SA、PDSA、運營和值班，都可以根據問題的緊急程度做出判斷，確認是否需要進行升級處理。尤其是客戶核心人員提出的問題，無論是工作時間或是非工作時間，都需要得到及時的響應。在當前的服務流程上，某客戶的服務團隊又不斷固化一些常規問題的處理流程，并通過雙周復盤的機制，不斷的查漏補缺，優化服務的節點和流程。55 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書通過推行某客戶的專屬服務體系，來自客戶的投訴和抱怨的

93、聲音大量減少。整個服務團隊通過明確分工和職責劃分，并相互補位，形成了比較和諧的團隊氛圍。在某客戶直播業務服務商評分的體系中，多次取得了服務評分第一名的優異成績。3.1.6 出海業務直播場景3.1.6.1 概述在移動互聯網的下半場，出海業務逐步從傳統IT輸出轉變為文化輸出，其中泛娛樂直播行業近年來尤為突出，從行業角度看，主要有兩方面原因，一方面是目前國內泛娛樂在直播方面的新增長點達到一定規模級，導致很多直播廠商的第二增長曲線探索艱難，另外一方面在海外線下娛樂面臨巨大沖擊(主要受政策、疫情因素影響)下，線上泛娛樂生態的千億市場逐步顯現。出海業務的海外直播場景在業務品類上基本與國內保持一致，通過整套

94、的直播服務(包含用戶管理、風控、審核、運營、數據分析、推薦、大數據等)來實現直播時的各種交互，相較于國內，海外直播對于技術服務或行業技術屬性來說更注重兩點，泛娛樂行業技術服務白皮書 56一是內容、數據合規性，二是直播質量中關于網絡的因素，作為基礎設施廠商方阿里云提供了覆蓋全球的加速節點，以及更貼合客戶業務需求的產。從行業層面來講，直播行業出海的原因很多，a)中國互聯網發展速度全球領先，優勢產業向全球輸出大勢所趨。b)中國人口紅利消退，流量向印度、巴西、東南亞和中東等新興互聯網市場轉移。c)資本的強力支持，推動優質中國互聯網企業出海。(典型的 Tiktok）3.1.6.2 架構與策略視頻直播，社

95、交類直播是出海的熱門，技術上考慮點：第一用戶體驗，第二是成本?？梢赃x擇用低成本實現高性價比的產品服務體感，也可以用高成本換取穩定的優質服務；如下圖是分為用戶自搭建海外回源架構，另外一種采用公網CDN分發的方式回源；在跨國實時網絡傳輸策略上，主流的服務提供上，或者平臺自己采取的策略包括區域化邊緣部署就近雅原則、負載均衡等、傳輸協議上目前占比最多的還是Rtmp，但基于UDP的傳輸、以及網絡實時探測數據的動態調度才是趨勢；調度平臺路由策略海外代理節點Anvcast+GA海外ECS國內ECS國內CDNplayer智能選路動態回源最后一公里中心節點國內節點深圳美國57 泛娛樂行業技術服務白皮書泛娛樂行業

96、技術服務白皮書其中路由策略是很多公網CDN廠商尤為重要；通過節點之間交叉探測，以及真實用戶模擬數據，評估回源節點質量，可以做到動態調度規劃回源路徑，降低延遲。edge1edge2鏈路探探測數據調度中心上報詢問返回決策決策中心信息流edgeNedgeN3.1.6.3 核心指標探測指標的測試up_node_zone：上層節點接入的的運營商線路；lower_node_zone：下層節點接入的的運營商線路；lossrate：丟包率；Avg_rt：探測周期內的平均rtt；Max_rt：探測周期內的max延時；Min_rt：探測周期內的min延時；Merge_time：合并時間；回源協議優化目前很多業務方

97、也會采用UDP回源的方式進行私有優化，如果RTMP推流后，可以采用RTC(UDP)在內部進行轉推。如果采用傳統的TCP/IP傳，在kernel層面也有一些優化，如升級版的TCP優化協議。泛娛樂行業技術服務白皮書 58Abstract一種基于TCP協議的自適應網絡控制傳輸方法，通過在網絡傳統的TCP/IP協議體系結構中的發送端和接收端的傳輸層和網絡層中間分別添加網絡編碼層，在網絡編碼層中給編碼包和ACK應答包添加包含特定變量的網絡編碼包頭，利用編碼包和ACK應答包將這些變量在接收端和發送端之間傳遞并更新，并利用這些變量在發送端網絡編碼層調整冗余系數R。這種動態調整冗余系數的方法，可以增強協議對突

98、發丟失的抵抗力，并在丟失率不斷變化的網絡環境中，使冗余系數R盡可能維持在最優值，提高網絡吞吐率和鏈路利用率。BBRGoogle官方對TCP-BBR的測試展示比較局限。多是單流測試，場景單調。TCP-BBR在Google跨越DC的B4網絡測試中取得了較好的成績。Facebook的Law-rence對TCP-BBR做了更詳盡的對比測試Google官方已經很詳細地描述了BBR算法的機制，這里再取其精華下。TCP-BBR基于測量，脫離了原先的tcp窗口調節框架，實現了一套自己的速率調節機制，這種調節機制對丟包不敏感。TCP-BBR實際上繼承了長久以來的可靠傳輸協議設計思想。它的難得之處，在于比以往的協

99、議更進一步。小的改變會有大的不同。它關注兩個測量值：Btlbw和propRTT，即瓶頸帶寬和傳播時延。Btlbw和PropRTT無法同時測量。網絡利用程度高的時候，才能測帶寬。網絡空載的時候，才能測延時。因此它的測量算法可以分為兩部分看。以下是官方測試的收益數據，優勢在跨國的長瘦網絡的窄帶丟包有出奇的效果，具體數據這里不詳細贅述，可以自行Google官方查找；59 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書3.1.6.4 海外直播與國內直播的區別海外直播與中國內地直播的區別主要體現在以下三個方面：直播域名的加速區域、直播中心和上下行監控。選擇合適的直播中心、加速區域能解決跨境鏈路傳輸不穩

100、定，直播卡頓率高等問題。上行幀率、碼率監控實時查看主播推流情況，下行播放統計及時感知用戶觀看情況。域名備案等資質。無論主播在中國內地還是海外，只要出現在中國內地播放的場景，域名就必須進行備案。針對海外直播場景的直播能力。海外直播尤其是直播推流、播放純海外直播場景，對直播加密有更高的要求，需要對直播流進行加密。同時因為海外鏈路長，不同網絡情況下對動態多碼率直播播放有更強需求。泛娛樂行業技術服務白皮書 60針對海外直播場景的直播能力。海外直播尤其是直播推流、播放純海外直播場景，對直播加密有更高的要求，需要對直播流進行加密。同時因為海外鏈路長，不同網絡情況下對動態多碼率直播播放有更強需求。針對跨國廣

101、電級活動、賽事、音樂直播，還提供了SRT直播整體解決方案。我們知道，各個國家對于文娛、社交等平臺的政策是不同的，因此此類平臺出海時通常需要注意其他國家的政策，直播平臺也是如此。在直播業務出海通常是讓國內外平臺徹底隔離，使用不同的APP和數據。這種方法可以讓平臺在國內外政策有差異時無需兼顧雙方，僅需在各自的平臺注意當地的合法合規政策即可。這種方法在云上很容易就能得到支持，僅需一套海外的加速節點和直播中心即可。而成熟的云廠商早已支持海外的直播服務。解決了數據合法合規的問題了，我們需要關注的就是直播的質量。海外直播的痛點在于用戶分布范圍極廣，邊緣節點無法覆蓋每一個國家或地區，即使推流到邊緣節點也有可

102、能出現跨國的情況。首先介紹兩種通用的優化方法：動態多碼率直播用戶在上行網絡允許的前提下，為了較高清晰度，常常會選擇較高的參數，如較高碼率。而網絡情況復雜多變，為了適應多種環境下都能正常觀看，下行播放支持多種碼率，根據觀眾的網絡情況，選擇合適的碼率進行觀看。開啟后在播放時自動選擇最高清晰度，檢測用戶網絡情況不佳時切換到更低碼率進行觀看。超低延時直播RTS超低延時直播方案，端到端直播延時1.5秒。支持不改變直播上行原有的RTMP推流，在下行原有的RTMP、FLV、HLS播放協議基礎上，通過新增子播放域名，在子域名使用ARTC(基本開源WebRTC開放協議演進)進行超低延時播放。支持使用阿里云播放S

103、DK、RTSnetSDK、自對接開放協議的方式對接。秒開、卡頓效果可以與RTMP播放持平或更好。61 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書除此之外還有一些特殊的場景，如主播在海外，但是他面向的是中國國內的直播平臺，這就必須面對跨國鏈路帶來的延遲和不穩定。這種情況下我們有另一種方案，通過GA加速轉推。其架構如下圖。GA加速是阿里云的加速專線，在海外主播推流到邊緣節點后，經過GA加速(上車點海外，下車點國內)轉推到一個國內的轉推域名。這是為了能夠適用國內的調度策略。這個方案可以結合阿里兩種產品的優勢，完美地為國外大主播入駐國內平臺做保障。具有極高的實用價值。3.2 游戲類泛娛樂3.2.

104、1 游戲泛娛樂定義游戲是目前泛娛樂行業中用戶群體非常大的一個行業，根據2021最新的全球游戲行業市場報告，2021年全球游戲市場將獲得1758億美元收入。移動游戲市場的收入將增長4.4%至907億美元，占總收入的一半以上，從游戲玩家的分布情況來看，推流端海外L1未經加速前鏈路，由于跨國容易產生鏈路不穩定經GA加速后，轉推到國內域名，以國內域名的調度策略轉發到直播中心或客戶功能節點海外L2國內L2國內L1推流端海外L1GA加速鏈路國內轉推域名國內直播中心或客戶直播功能節點國內直播中心或客戶直播功能節點泛娛樂行業技術服務白皮書 62亞太地區擁有全世界最多的玩家，16.15 億玩家占全球玩家總數的

105、55%(該地區的網民人數占全球網民總數的54%)，并且亞太地區玩家對移動游戲表現出了明顯偏愛，而在全球30億玩家中，有28億玩家通過移動設備玩游戲，可以看出全球游戲玩家體量巨大，而且有繼續進一步增長的巨大潛力，同時。PC和主機游戲市場萎縮，是全球游戲市場收入下滑的主要原因。Newzoo預計本年度全球PC、主機游戲市場收入將達到359億和492億美元，同比分別下降2.8%和8.9%，移動手游進一步夯實在游戲領域的主賽道定位。預估到2024年，全球游戲市場的年收入規模將增長至2187億美元。從2019年到2021年，全球游戲市場的年均復合增長率約為8.7%，年收入將于2023年首次突破2000億美

106、元。在游戲行業蓬勃發展的趨勢下，也衍生了云游戲、元宇宙、VR等新興游戲發展模式與玩法，對很多玩家來說，游戲不僅僅是一種娛樂媒介，還變成了現實世界的延伸。這些玩家熱衷于在游戲中表達自我，組織社交聚會，或者慶?，F實生活里的各種重大事件。與其他媒介相比，游戲世界能夠提供更為豐富的個性化社交體驗。最讓我們有體感的還是中國網游，在早期大家耳熟能詳的還是金山西山居旗下仙劍奇緣，盛大旗下的傳奇，巨人網絡旗下征途等客戶端游戲，這些游戲屬于先行者，在PC還不是非常普及的階段紅遍了大江南北的網吧，成為80后這一代人的記憶，也是因為這些游戲讓網絡游戲在中國普及。同時，而隨著計算機的普及，2008年圍繞社交場景版的網

107、頁游戲鼻祖開心農場的問世帶動了一個新的“游戲瘦身”時代，從而帶來了頁游的井噴，包括了千軍破、傲視天地等一系列注重游戲策劃、游戲數值設計的優秀精品，而隨著這塊蛋糕凸顯，頁游百家爭鳴逐步從“策劃為先”走向了“運營為先”，也因此出現了后面的平臺發行模式。在經歷了幾年沉淀，移動互聯網開始成為主流，碎片化時間的強占成為游戲市場紅海，手游也就應運而生，市場競爭進入白熱化。在運營模式+畫面要求的雙輪驅動下，中國網游新時代頭部玩家凸顯，刀塔傳奇、我叫MT、開心消消樂、王者榮耀、原神、劍與遠征、明日方舟、戀與制作人等優質游戲琳瑯滿目，這里的廠商包括了北京的搜狐暢游、完美世界、紫龍游戲，上海的四小天鵝：米63 泛

108、娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書哈游、莉莉絲、疊紙、鷹角，杭州的網易游戲，廈門吉比特，廣州的游戲運營公司37互娛、efun，還有大廠騰訊等等。截至2022年，游戲進入了IP時代、精品時代。針對不同類型的游戲，對于技術的要求也不太一樣，例如RPG類型的游戲普遍對網絡延遲與穩定性要求較高，SLG類型的游戲對于可擴展性要求更高，從游戲運維視角，游戲架構大多架構復雜，為了應對海量的用戶，架構上都是高度集群以及分布式，隨著游戲生命周期的不斷延續，其運營的過程中，會隨著運營的發展不斷增加模塊來支持不同的玩法和活動，我fps手游就多達100以上的游戲進程模塊，因此也會帶來頻繁的版更發布，為了保

109、障用戶的良好體驗，越來越多的游戲都開始建設了不停服發布的發布流程，就是為了保證玩家體驗不中斷。但是不停服就給游戲架構和運維帶來了挑戰，如何建設一個穩定的不停服發布流程是需要運維和開發需要不斷溝通設計的。游戲根據時代主流，區分為端游、頁游、手游三大形態，也完成了從大客戶端時代向小客戶端演進，用戶操作更容易、娛樂性覆蓋更全面，產品也越來越注重游戲畫面，極致的用戶操作體驗，游戲數值設計的苛刻要求，IP場景共鳴化，網絡延時低等特性，也對游戲技術解決方案，技術服務模式提出了更高的要求。從開服的第一天到導流推廣、活躍運營、合服乃至玩家消耗至盡的全生命周期，技術挑戰始終伴隨，主要包括了：業務不間斷：故障期間

110、的玩家影響重，比如無法充值、重要節點的游戲無法進行游戲架構存在不合理：因為游戲有風口效應，為了快速上線往往犧牲規范，怎么快速怎么來導致了很多設計的不合理，在故障場景的影響放大或在玩家量級翻番的情況下代碼重寫對游戲來說基本不可能基礎設施不完善：在端游、頁游的早期還是以IDC托管支撐為主，運維人員即要做機器選型，又要上架、配置網絡、部署系統等復雜的過程，在游戲快速增長的背景下太低效泛娛樂行業技術服務白皮書 643.2.2 游戲泛娛樂技術服務3.2.2.1 通用游戲重保技術服務進入到云上時代后，從游戲客戶運維視角，用了云后基礎設施對用戶來說是黑盒，客戶只用了一臺簡單的ECS主機，并不了解背后的虛擬化

111、架構、宿主、網絡、共享情況和隱患；而從云技術服務視角，只交付給客戶的產品并不了解客戶單體使用場景，多體的行業技術，產品穩定用戶業務穩定性。特別對于使用公共云的用戶來說，一旦業務出現問題更顯得手足無措，因為并了解狀況，不知道是自己的問題還是云廠商的問題，也不知道怎么恢復業務，焦慮、不可控，這是對運維的新挑戰。也因為游戲導流運營節奏，可以毫不夸張的說，開服前7天的數據決定了一款游戲的成敗，游戲護航成為最最重要的技術話題。日常運維工作繁雜：服務器上線后的運營階段工作非常繁雜，開服、清檔、合服、運營查詢這一些列的維護工作反復、易錯。65 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書3.2.2.1.

112、1 服務護航流程護航目標分析制定：游戲業務背景了解，將業務語言翻譯為技術語言，明確技術要求掉和目標，保障開服前期業務穩定；業務現狀分析：對現狀的業務架構做梳理，了解資源資源分布情況、業務歸屬情況，對潛在風險做巡檢和掃描手機，做目前性能的量化分析。制定保障方案：明確資源預留情況，對潛在風險掃描、識別，對不滿足預期的模塊做系統評估，并擴容，通過性能壓測、高可用建設、準備預案、進行演練等形成全面的保障方案。執行保障計劃：通過清晰的保障方案執行，增派技術服務專家進行客戶現場駐場，對護航期間的問題進行及時處理，通過實時監控和高頻巡檢，即時識別問題、閉環問題；復盤總結：事后的護航總結報告輸出并和客戶組織復

113、盤會議，不斷實踐循環保障并迭代方案。3.2.2.1.2 云產品巡檢參考產品分類產品分類產品巡檢項驗證結果否否巡檢建議推薦部署外網網絡質量監測系統，掌握網絡波動情況，及時告警。1、對網絡帶寬進行周期性巡檢，掌握波動規律；2、推薦調用api接口對EIP帶寬動態調整設置；核心業務EIP是否部署了網絡質量監測？帶寬是否能滿足客戶業務峰值的需要？EIP泛娛樂行業技術服務白皮書 66EIP是否存在突發流量占滿帶寬導致訪問超時問題？SLB產品是否受到外網波動導致無法訪問？SLB產品就帶寬/連接數等是否設置了告警？告警值是否合理？SLB產品所在集群是否存在性能瓶頸？單個SLB實例是否超出性能瓶頸？機房核心入口

114、設備存在斷鏈風險？傳統網絡EIP等共享帶寬被占滿，導致SLB EIP等訪問不通或者嚴重丟包1、建議設置共享帶寬的監控告警；2、采用API接口腳本對共享帶寬 EIP進行動態調整；同業務多建立SLB做負載，規避單點eip大網影響推薦對SLB實例核心參數做合理設置安排用戶資源升配建議：1、做好監控，設置合理告警閾值；2、核心組件做好多實例分散壓力；1、風險的產生，有如下幾點：1）大網不能保證7*24 100%可用2）交換機重啟引起下聯設備斷連3）異常流量，比如ddos in導致鏈路擁塞2、機房通信光纜斷開，物理故障的風險規避：1）雙線上聯（可用區-pop點）-2N+12）交換機堆疊，同時服務器雙線上

115、聯3）主動監控，做好容量監控，及時擴容是是否是是是67 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書用戶自建/托管第三方IDC是否因為大網抖動導致公有云/阿里云托管區之間調用延遲不穩定？用戶業務主機調用第三方業務API接口是否因為解析到跨地域節點導致延遲?使用OSS文件存儲是否出現負載變高問題引起的上傳下載延遲問題？OSS存儲產品Redis是否采用短鏈接使用方式?Redis是否設置了產品告警？Redis的QPS是否存在性能瓶頸問題？1、推薦專線互聯；2、采用ipsec+跨域專線方案，阿里云優質跨域專線提供高穩定性方案機房公共服務中的DNS服務，代理DNs 上聯用的dns是public，會導

116、致解析地域出現偏差，導致用戶第三方調用產生超時的可能建議：此類涉及業務主機，建議host綁定PUBLIC DNS解決。如阿里/NDSPOD公共DNS地址異常流量，或者異常飆升請求使得后端集群負載過高，導致用戶讀取文件時候延遲比較高，經常報錯1、引導用戶評估業務的延遲容忍度，對于密集型訪問，以及小文件等并發場景，建議用戶采用本地部署分布式存儲系統；2、建議用戶對業務的延遲和錯誤碼占比做監控，同時做好存儲容災方案。通過修改代碼方式切換接入存儲服務商，實現容災；采用sdk下載因為線程并發過小。導致下載文件速度過小建議用戶加大并發線程緩存不建議用短連接，請求并發太大，很容易導致proxy連接（針對分布

117、式版本）回收不過來，引起性能瓶頸問題是是是是是是Redis是否設置了產品告警？推薦就核心指標做告警設置否Redis的QPS是否存在性能瓶頸問題？評估業務需求，總體擴容是redis是否存在凌晨時段的io波動問題？默認數據做AOF落地，磁盤的波動性能問題可能會影響用戶使用。非核心業務（重啟kv數據丟失），建議關閉aof是是否設置了RDS產品告警？推薦盡快就核心指數設置告警，及時感知實例性能變化；否RDS的搜索引擎是否采用了非Innodb引擎？存儲引擎建議全部使用InnoDB，InnoDB適用于絕大部分業務場景；是泛娛樂行業技術服務白皮書 68RDS的磁盤使用率是否超限，存在空間不足風險？執行大事務

118、時間過長，導致主從同步延遲，主備同步延遲業務是否足夠重要，將存量標準版SLB升級到高可用RDS實例來提高可用性？RDS業務場景是否采用了緩存架構/連接池技術架構？RDS業務場景中是否存在批量任務和長任務（大事務）？建議用戶持續關注磁盤容量監控，并保證磁盤空間使用率控制在80%以內。解決方案：建議大事務拆分，優化sql；存量數據庫存在基礎版數據庫實例?，F有購買數據庫均為高可用RDS實例。對于存量的基礎版數據庫，建議依據業務重要與否，盡快做升級處理；1、對于高并發業務，建議使用連接池技術；2、對于高可用版RDS，建議使用長連接，應用層建議使用連接池。長事務：RDS建議在數據庫中不要存在長事務，長事

119、務在執行過程中，若造成長時間持有鎖，可能會導致性能問題和備份失敗等情況，建議控制每個事務的執行時間，檢查代碼中沒有commit的事務，并保證開啟自動提交（auto_commit=1）。批量任務：容易導致復制長時間延遲等情況，SLB建議配置從庫延遲告警，并將批量任務拆分成粒度更小的子任務，代碼中控制從庫延遲情況，從而避免影響讀寫分離等功能。是否否是推薦合理為MySQL數據庫的表建立合適的索引，可以讓MySQL在性能方面有更好的體現1、為每一個表都配置一個自增id作為主鍵；2、在頻繁查詢的字段上建立索引；3、在基數大的列建立索引（如重復值多的列），而不是在基數小的列上建立（如性別）；4、在GROU

120、P BYORDER BY后未使用函數的字段上建立索引；5、單表不宜建立過多索引，盡量控制在6個左右；6、定期登錄控制臺，下載慢查詢分析日志（下載的慢日志是pt-digest工具分析處理后的日志），找到業務中的慢SQL，針對慢SQL設置合適的索引。RDS是否針對表進行了索引設置？否69 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書針對讀寫壓力比較大場景，是否開啟了讀寫分離功能？用戶業務是否存在直連RDS實例ip場景？ECS部署業務是否考慮了高可用架構及解決方案？是否存在核心的或同業務的云主機位于同一臺宿主機的情況？安全安全是否存在老化嚴重或多次宕機過的宿主機？針對讀壓力比較大的業務場景，建議

121、用戶開啟讀寫分離分擔主庫實例壓力。阿里云提供高可用SLB的讀寫分離功能一鍵開啟故障是否不方便剔除或者切換，建議啟用讀寫分離組件或者第三方分布式集群（MyCat方案），屏蔽后端db變化對業務對影響推薦高可用方案部署，規避單點風險標準：1、不同業務主機數量大于等于32、同等業務主機數量大于等于2符合以上條件之一判定為同宿指數情況嚴重。1、盡快做主機遷移打散操作2、相同業務可以建立硬件隔離組等特性創建時候設置為打散隔離狀態宿主機器老化問題，定期巡檢，做風險預警，安排遷移處理否是是是是客戶是否對云主機的cpu磁盤IO、包量等指標有特殊要求？主機所在宿主機器是否發生宕機問題？1、針對重點活動臨時保障，重

122、點實例做性能保證，比如遷移加鎖獨享等；2、針對長期使用，要求性能有保障場景，建議采用私有專區、神龍服務器來獨享性能；宿主機器物理層面該風險建議通過應用層面高可用來規避。如業務集群高可用架構，主備架構實現高可用。是1、定期健康巡檢 一周巡檢一次的頻率；2、發現隱患及時同步到客戶，依據隱患情況決定是否遷移 是泛娛樂行業技術服務白皮書 70用戶所用架構中登錄密碼是否過于簡單？用戶所用架構中主機資源是否采用了鏡像快照功能？用戶所用架構中業務是否采用了https訪問方式，部署ssl加密？用戶所用架構中云產品關聯firewall是否合理設置？用戶所用架構中是否使用了入口審計產品？用戶所用架構中是否經常遭受

123、ddos攻擊？推薦密碼加固，采用數字+字母+特殊符號方式設置；內部管控推薦使用跳板機+密鑰登錄推薦定期對操作系統等數據做鏡像制作備份操作，快速回滾；推薦核心業務開啟https訪問，防止數據流量劫持風險；firewall策略過粗或者過細都可能影響業務正常的開展。建議進行針對性安全過濾設置；推薦堡壘機產品，權限細分+運維動作回溯管控；1、推薦部署高防類產品進行有效防護；2、付費提升核心業務EIP的攻擊防御值是否否否否是用戶所用架構中登錄密碼是否集中管控，或者所有資源都是一套密碼？1、推薦資源采用不相同的密碼登錄不同主機，或者定期更新密碼；2、對于采用秘鑰登錄方式，推薦阿里云堡壘機產品；是用戶賬戶余

124、額是否充足？是否足夠在下一個續費周期內滿足續費需求？賬戶賬戶1、客戶賬戶金額保持充足，規避在下一個續費周期內因為金額不足導致的部分機器續費失敗問題，影響到業務運行或者釋放；2、依據情況開通信用賬戶；否71 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書用戶自建/托管第三方IDC是否因為大網抖動導致公有云/阿里云托管區之間調用延遲不穩定？用戶業務主機調用第三方業務API接口是否因為解析到跨地域節點導致延遲?使用OSS文件存儲是否出現負載變高問題引起的上傳下載延遲問題？Redis是否采用短鏈接使用方式?Redis是否設置了產品告警？Redis的QPS是否存在性能瓶頸問題？1、推薦專線互聯；2、采

125、用ipsec+跨域專線方案，阿里云優質跨域專線提供高穩定性方案機房公共服務中的DNS服務，代理DNs 上聯用的dns是public，會導致解析地域出現偏差，導致用戶第三方調用產生超時的可能建議：此類涉及業務主機，建議host綁定PUBLIC DNS解決。如阿里/NDSPOD公共DNS地址異常流量，或者異常飆升請求使得后端集群負載過高，導致用戶讀取文件時候延遲比較高，經常報錯1、引導用戶評估業務的延遲容忍度，對于密集型訪問，以及小文件等并發場景，建議用戶采用本地部署分布式存儲系統；2、建議用戶對業務的延遲和錯誤碼占比做監控，同時做好存儲容災方案。通過修改代碼方式切換接入存儲服務商，實現容災；采用

126、sdk下載因為線程并發過小。導致下載文件速度過小建議用戶加大并發線程緩存不建議用短連接，請求并發太大，很容易導致proxy連接（針對分布式版本）回收不過來，引起性能瓶頸問題是是是是是是Redis是否設置了產品告警？推薦就核心指標做告警設置否Redis的QPS是否存在性能瓶頸問題？評估業務需求，總體擴容是redis是否存在凌晨時段的io波動問題？默認數據做AOF落地，磁盤的波動性能問題可能會影響用戶使用。非核心業務（重啟kv數據丟失），建議關閉aof是是否設置了RDS產品告警？推薦盡快就核心指數設置告警，及時感知實例性能變化；否RDS的搜索引擎是否采用了非Innodb引擎？存儲引擎建議全部使用I

127、nnoDB，InnoDB適用于絕大部分業務場景；是泛娛樂行業技術服務白皮書 723.2.2.2 通用游戲發版技術服務隨著國內游戲版號控制逐步嚴格，每款新游戲是否可以平穩上線發布對于游戲公司都變得愈發重要。開服即炸是每個游戲廠商的噩夢，OB首日玩家數量和7天玩家留存率往往決定一款游戲是否成功拋開游戲自身質量，游戲發布初期業務本身的穩定性也是直接影響玩家數量和留存率的重要因素之一。游戲發布重保護航服務是阿里云針對頭部客戶的深度增值服務，提供阿里云游戲行業專業能力、規范的技術保障流程來協助客戶業務穩定度過峰值和關鍵期，保障業務線上環境穩定可用，助力其順利完成業務目標。本節對整個游戲發布重保護航服務規

128、范和流程進行詳細介紹。3.2.2.2.1 核心流程規范3.2.2.2.2 整體工作階段護航kickoff準備階段一般需要提前15個工作啟動規劃實施階段此部分占整個服務周期的80%總結復盤復盤經驗教訓，內部沉淀對齊護航目標資源評估&報備全鏈路壓測支持性能優化完成擴容駐場護航73 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書3.2.2.2.3 信息收集階段泛娛樂行業技術服務白皮書 743.2.2.2.4 重保團隊組建根據前期信息收集和客戶需求進行護航團隊組建，護航項目總負責人(PM)：需要深入了解項目整體業務架構，能夠全局拉通各條技術線，全產品問題的初步定位和任務分發，可以維系好和前線團隊、客

129、戶核心人員的關系。一般由客戶TAM擔任。護航團隊：護航團隊人數根據項目規模、成本進行配置，盡量覆蓋客戶關鍵云產品垂直線。角色角色分類職責業務線售后PDSA組GTS AES產研CBM商務對接人技術和方案對接人資源報備、賬務支持售后問題對接人專項產品架構師專項產品架構師專項產品架構師專項產品架構師專項產品架構師SACAMTAM彈性計算安全網絡數據庫CDMPM護航PM專項產品護航技術專項產品護航技術專項產品護航技術專項產品護航技術專項產品護航技術穩定性護航技術熱遷移護航技術彈性計算安全網絡數據庫CDN穩定性熱遷移75 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書3.2.2.2.5 重保措施列表全

130、鏈路壓測游戲壓測計劃和業務場景強關聯，需要結合業務目標設計，一般通過客戶編寫全鏈路壓測機器人或腳本，模擬真實的用戶行為(如游戲對戰、聊天)。通過機器人壓測評估單服PCU承載能力。建議客戶有專門的QA來負責壓測與壓測機器人的構建、部署。針對平臺服務或web服務接口，可結合阿里云PTS服務快速高效地在線上構造出真實的超大規模的訪問流量。全鏈路壓測是發現系統瓶頸和驗證系統能力的最有效方法。常見的游戲場景壓測關注點舉例：網關服務器負責所有網絡數據包的轉發，通常是網絡負載較集中的點，壓測需關注網絡吞吐能力。場景服務器包含游戲邏輯，壓測需關注CPU處理能力以及一定的網絡吞吐能力。數據中心服務器負責緩存玩家

131、數據并異步入庫，保障玩家客戶快速獲取和寫入數據，對于可用性要求較高，需要配合應用層實現數據容錯機制;日志服務器承載了大區所有業務行為的日志收集及處理的壓力，壓測需關注磁盤寫入性能。通常采用多臺分組方式實現。全鏈路壓測實施流程樣例。泛娛樂行業技術服務白皮書 76客戶和阿里云客戶和阿里云客戶和阿里云根據壓測過程做梳理和調整根據壓測過程中出現的核心問題理順并做優化改進確認壓測目標梳理壓測鏈路架構梳理業務模型 壓測機器人或腳本壓測checklist記錄問題壓測其他優化改進客戶和阿里云客戶客戶客戶全鏈路壓測實施流程階段梳理步驟說明負責人1、摸底業務吞吐極限，驗證架構，探測性能瓶頸，確定目標壓測值梳理清楚

132、各個應用從端到端的請求鏈路、技術架構、分層結構模塊劃分，分析潛在的瓶頸點，并針對性的增加監控指標、制定應急預案根據實際的業務場景，確認各個接口范圍，接口餓的壓測目標，接口出入參數。根據實際的業務場景編寫壓測機器人或腳本和壓測模型1、搭建和生產環境一致的測試環境2、根據梳理的各個業務接口相關的參數，配置PTS壓測場景。根據業務目標，設定機器人壓測數量。3、測試壓測跑通業務鏈路。1、壓測場景目標是否都達到，是否需要單鏈路補壓滿足流量要求。2、大盤是否有毛刺和異常下跌情況。3、上下游流量是否對齊，是否在相同的時間段到達流量峰值。4、業務成功率是否滿足預期。5、是否有觸發限流，是否屬于正常限流場景。6

133、、是否有系統問題，集群fgc，load偏高，rt偏高7、是否有數據庫熱點，數據庫異常，rt偏高，連接池滿問題8、是否有緩存擊穿，緩存滿足率底問題9、是否觸發異常監控保健 10、其他2、梳理壓測鏈路3、其他風險評估架構評估：主要從健壯性、安全性、聚合度方面對系統業務架構進行評估，一般需要從玩家注冊登陸，使用游戲內各項功能的整個過程進行全鏈路評估，主要基于系統架構圖和數據流轉圖，其評估結果用于反向驅動研發、產品側的架構優化改進。技術評估：主要關注線上系統的性能、容量、可用性、安全性等方面，其核心是保障線上系統中各節點可以滿足產品設計指標及業務需求指標，因此需要基于業務目標，結合用戶系統模塊閾值、云

134、產品上線等，最終使用性能壓測方法來進行驗證評估。77 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書常見風險以上文架構圖示例中的分區分服架構圖為例：全 局 服：端 到 端 全 鏈 路 性 能 瓶 頸。全 局 服 一 般 走 典 型 的 網 站 架 構：LB+ECS+Redis+RDS，這里需要考慮的相關因素包括LB的并發連接數和新建連接數要求，LB的DDos防護能力要求，ECS規格匹配度，Redis/RDS的連接數、QPS、是否有數據傾斜、是否有大key、大value情況。游戲服：要考慮ECS的CPU處理能力、磁盤的讀寫帶寬、單服的帶寬上限等因素。同時，一般采用帶寬包來提升帶寬峰值，這里需要

135、考慮帶寬包可容納的EIP數量、單UID下可創建的EIP/帶寬包數量等指標。CDN：游戲CDN一般包含游戲各渠道的游戲首包、更新包，serverlist文件、其他靜態文件。由于現在游戲包體越來越大，一般手游都在3、4G左右，因此在游戲OB前一般會先開放預下載，同時也會配合運營活動宣傳。因此對于預下載的CDN帶寬評估非常重要。CDN產品團隊會根據客戶評估的CDN峰值帶寬做資源預留、避免CDN資源不足導致的卡頓和下載失敗。安全：一般指DDos安全防護，這里要考慮的因素包括業務帶寬、防護帶寬、端口數量等。此外，大型項目往往會存在產品閾值超額的風險，需要提前結合業務目標做各云產品的梳理。泛娛樂行業技術服

136、務白皮書 78風險評估checklist樣例容災限流方案和演練游戲業務雖然為在線業務，但出于對游戲生命周期、架構復雜度、成本等因素考慮，一般從架構上沒有高可用的容災設計，主要依賴云產品穩定性和熱遷移能力。因此容災演練需重點關注高壓力下游戲服熱遷移的性能和影響情況，業務服務模塊間的79 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書隔離性和健壯性、單點故障后的恢復速度等。尤其在使用大規格ECS實例的分服場景下，需要確定熱遷移時TCP連接?；?、時鐘跳變可在預計時間內完成補償、機器人無掉線、真人無感知。編號檢查項概述不同服務模塊之間隔離服務模塊健壯性單點故障異常場景下關鍵玩家數據不丟失服務平滑擴（

137、縮）容服務限流能力可靠的停服版更、公告能力單個服務模塊異?；蛘哒{用超時。玩家與該模塊無關操作可以需要有獨立且高可用的公告；玩家游戲時能給客戶推送服務器公告停服后公告服務持續發布在服務進程異常結束或者服務器異常重啟場景下可被檢測都并自動拉起相同服務不同服務節點負載壓力應該均衡當底層DB節點出現異常，例如發生HA切換服務具備重連機制，仍可正常訪問DB當中心服master節點故障后，slave節點能夠平滑切換接管服務服務進程異常后自動恢復能力服務負載均衡能力讀寫DB服務具備重連機制中心服故障切換演練1234567891011單個服務模塊進程異常掛掉不影響整個服務模塊正常訪問所有模塊不能有單點風險，任

138、何一個服務所在ECS客機不影響玩家正常訪問，每個服務都有多個節點進行應用容錯單個服務進程異常結束或者單個服務重啟均不能導致玩家關鍵數據丟失玩家關鍵數據必須寫日志，以便特殊情況下回淵查詢每個服務具備在日常運營情況下平滑擴（縮）容能力，擴（縮）容期間對玩家正常訪問無影響，且不因服務節點的變化導致正常業務邏輯受損與訪問不均等情況具備限流能力，提供過載保護能力，可預設防護閥值并且備動態調整能力，超過預設PCU值?？删芙^連接且不影響登陸連接玩家的正常訪問，例如在網關層進行最大在線玩家數限制泛娛樂行業技術服務白皮書 80檢查項用例操作步驟1、登錄并進行游戲2、殺死所在的邏輯服務進程1、登錄并進行游戲2、殺

139、死所在的戰斗服進程1、登錄并進行游戲2、殺死所在的認證服進程1、登錄并進行游戲2、殺死所在的認證服進程其他服務同理其他服務同理1、停服2、發布停服公告3、啟動客戶端殺死單個小區的邏輯服務其他服務同理1、隨機選擇某些小區2、按隨機順序重啟小區的單個服務進程、redis、mysqi進程1、關閉所有sdk平臺非登錄、支付服務模塊（防沉迷、敏感詞等模塊）超過當前服務支持最大支持在線玩家數1、手機客戶端進游戲2、手機斷開網絡1、啟動壓測機器人1、啟動壓測機器人1、客戶端登錄進游戲2、客戶端使用添加貨幣、一級物品、二級物品3、重啟單個小區的戰斗服1、客戶端登錄進游戲2、客戶端使用添加貨幣、一級物品、二級物

140、品3、重啟單個小區的DBGate和對應的RedisPolarDB邏輯服異常戰斗服異常認證服異常網關服異常其他服務同理服務可向玩家發送停服公告邏輯服異常其他服務同理邏輯服異常Dbgate 異常和對應的Redis,PolarDB異常與重啟其他服務同理服務進程異常、db進程異常sdk平臺服務異常最大在線玩家數閥值控制登錄一個玩家后斷網服務器負載均衡sdk平臺負載均衡單個后臺服務異常不能導致客戶端不相關邏輯不可用可靠的停服公告機制不能有單點故障或單點故障時間少于xx分鐘影響小于x%的用戶單個服務進程異常結束不能導致玩家關鍵數據丟失服務器模塊隔離：單個服務支持獨立重啟、單個服務進程異常結束不能引發其他服

141、務進程異常服務器過載保護：接入層需要有閥值控制服務器過載保護：服務器對一段時間內不活躍連接要強制斷開服務器負載均衡：同等服務和數據是動態負載均衡的81 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書期待結果1、其他邏輯服上的玩家不受影響2、異常殺死的邏輯服進程可被自動拉起，或者新的玩家請求能被轉發到其他正常的邏輯服節點3、影響時間小于xx分鐘，影響的玩家數量小于x%1、其他邏輯服上的玩家不受影響2、異常殺死的戰斗進程可被自動拉起，或者新的玩家請求能被轉發到其他正常的戰斗服節點3、影響時間小于xx分鐘，影響的玩家數量小于x%1、其他認證服上的的玩家不受影響2、異常殺死的認證進程可被自動拉起，或

142、者新的玩家請求能被轉發到其他正常的認證服節點3、影響時間小于xx分鐘，影響的玩家數量小于x%1、其他網關服上的的玩家不受影響2、異常殺死的網關服進程可被自動拉起，或者新的玩家請求能被轉發到其他正常的網關服節點3、影響時間小于xx分鐘，影響的玩家數量小于x%1、等待邏輯服自動拉起2、啟動壓測機器人3、壓測數據成功率大于xx%，xx%請求響應時間小于xx%秒1、等待重啟完成2、啟動壓測機器人 3、壓測數據正常1、手機客戶端登錄，并能進行所有玩法操作2、啟動壓測機器人3、壓測數據正常 4、敏感詞、防沉迷糊模塊全部異常，游戲服務器能否讓玩家正常登錄、創建角色1、等待修改生效2、啟動壓測機器人3、觀察在

143、線人數是否正確1、登錄、支付等各個服務的進程負載情況應該接近1、各個服務的進程負載情況應該接近1、客戶端會被動下線1、客戶端不能嘗試登錄2、停服會自動把在線玩家踢下線其他服務同理其他服務同理其他服務同理1、客戶端重新登錄2、查看貨幣，一級物品，二級物品是否正常1、客戶端重新登錄2、查看貨幣，一級物品，二級物品是否正常泛娛樂行業技術服務白皮書 82監控大盤配置針對游戲業務，一般關心的監控指標包括：網絡帶寬：網絡帶寬水位過高或打滿會直接導致玩家掉線或無法進入游戲，同時也可輔助發現網絡攻擊行為，因此網絡帶寬的實時監控是必須的。一般包括共享帶寬包流入帶寬總和、流出帶寬總和每個共享帶寬的流入帶寬和流出帶

144、寬等。如下圖：CDN：重點關注CDN下行流量監控(邊緣網絡總帶寬)、回源帶寬監控、命中率，4xx，5xx等指標，如下：83 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書游戲服ECS：游戲服需關注總連接數，反映總體在線玩家數量情況。熱門區服所在ECS的Cpu內存負載監控，關注高負載時的性能波動，如下圖：泛娛樂行業技術服務白皮書 84安全：包括對IP出入流量、連接數、QPS、狀態碼、黑洞事件、清洗事件的告警監控等。負載均衡、OSS、數據庫等監控大盤可按需配置，不做示例。以上監控圖都來自企業云監控大盤，護航團隊可以根據客戶需求進行定制化配置。告警策略參考應急處理流程3.2.2.2.6 重保應急與

145、故障預案85 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書故障預案樣例泛娛樂行業技術服務白皮書 86!3.2.2.2.7 總結本節介紹了游戲發布重保護航中的完整流程和其中的關鍵環節。實際護航中還需要根據實際介入時間、游戲規模、業務要求等因素進行靈活調整。但總結來說一方面是通過架構圖進行架構評估優化，保障安全防護、網絡延遲、單點容量等指標可以滿足業務目標，另一方面通過壓力測試發現適配性、產品bug、性能瓶頸、參數配置等隱藏問題并進行優化解決。同時結合風險評估checklist查漏補缺，企業云監控大盤發現實時問題。通過該護航流程可以最大限度的將問題、風險提前排除，保障OB當天可以順利穩定上線。

146、3.2.2.3 云游戲技術服務3.2.2.3.1 業務場景與核心技術首先，云游戲涉及底層技術主要是vGPU，雖然vGPU的發展形態大部分為可控的，但是最核心的GPU本身的源碼依舊在相關GPU廠商手上，特別是當客戶采用的自研PaaS平臺時，調度相關vGPU資源中涉及了大量關鍵鏈路，都需要與廠商交互，作為技術服務的角色進入到一個vGPU場景中大部分時間會感到非常無力，會感覺是在一層層做Proxy，但是實際真的是這樣嗎？這也是本篇想說明的一些技術點，但是單純得去講技術點，可能很多看官并不能理解這里面的深水區究竟在哪里，可以簡單看下這張圖：87 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書其次，云

147、游戲的技術維度跟視頻直播產品有“異曲同工”之妙：一個是云游戲從具體渲染能力的計算底層(VGPU1IaaS1VM)捕獲畫面(這個畫面來自于VGPU1VM運行真實游戲所產生的)，這就類似于直播“推流”，相關平臺通過GPU廠商或系統廠商提供的渲染類API進行捕獲的動作，相當于視頻直播的相關畫面往“視頻直播中心”推送的過程；另外一個是，在捕獲完成后做的封裝動作也與視頻直播產品轉視頻格式再合成(比如M3U8切片TS合成MP4)類似；最終decode到enduser的最后一屏上，這個最后一屏一般需要由云游戲客戶端進行拉取展示，其上的FPS值越高則代表游戲顯示層面的順暢度越高，那與視頻直播產品的幀率幾乎一致

148、。3.2.2.3.2 技術服務關鍵角色渲染計算角色核心渲染算力提供者，一般為超算(HPC)、GPU(物理GPU能力)、vGPU(虛擬化GPU能力)等機型提供，會出現問題主要捕獲階段、落Log階段與封裝(encode階段)，同時由于與云平臺耦合，所以在管控層面(裝箱、調度、計算資源分配等)、虛擬化性能分配(CPU算力分配、0進程爭搶等)、GPU切分(如有)、前后端驅動(特別是host端驅動)等方面也會經常出現問題，這次某云游戲專項中遇到的核心問題就聚焦在捕泛娛樂行業技術服務白皮書 88到的核心問題就聚焦在捕獲階段、落Log階段、前端驅動、虛擬化性能、管控這幾個方面，在后面正餐中會具體提到。平臺調

149、度角色核心PaaS能力提供者，一般分為自研與非自研，非自研領域屬某手指、海某云為代表的一些平臺本次云游戲專項PaaS平臺是由客戶與某獨立開發商配合一同研制，所以在該角色上我們的沉淀并不多僅在排障渲染計算角色時了解到該角色主要用在調度相關渲染計算節點并最終提供給玩家使用。最終玩家如名所示，最終玩家指的是客戶ToC部分的末端，在玩家與平臺調度角色中還穿插著一些網絡角色比如加速節點調度、專線、圖像傳輸等，最終玩家一般采用PC終端進行游戲業務體驗(部分廠商支持移動端）。這三個角色是云游戲技術服務中體感最強的，同時也是日常排障中涉及最多的角色(特別是渲染計算角色)，由于本次專項涉及主要是端游，所以接下來

150、講的相關排障技術點主要聚焦在端游上，對于手游，阿里云某某游客戶會比較深的積累與沉淀，筆者也很期待這次云游戲的客戶能夠衍生到手游云游戲，這樣對于后續移動端云游戲就有更深厚的積累。3.2.2.3.3 典型異常場景黑屏比如某客戶渲染黑屏比例在30%+(即測試樣例的170臺中有50臺+存在黑屏情況)，Top10黑屏次數臺均1k+，最高的一臺黑屏次數達到4k+，對于最終玩家來說，偶現的卡頓次數對于實時性要求較低的游戲影響不大，但是大量的黑屏特別是連續黑屏的情況1，對于大部分游戲都是災難，玩家會明顯感知到掉幀、卡頓、回退等，進而退游導致平臺PCU下降，來自客戶的某次黑屏監控數據(優化前）：89 泛娛樂行業

151、技術服務白皮書泛娛樂行業技術服務白皮書渲染日志落地慢由于云游戲涉及的鏈路較長加上Windows1Server(大部分3A云游戲采用的os類型)相對閉源的特性，要實時感知玩家的體驗以及相關鏈路是否存在異常就重度依賴Log的寫入，當出現Log寫慢的情況就很可能出現“云游戲之眼”失明以及相關依賴于日志的運維、業務調度策略失效，下圖為客戶提供的相關Log慢日志：vGPU掉線、聲卡掉線等問題此類問題的出現對于云游戲來說都是致命的，不過好在這類問題出現在平臺方的原因比較單一，相對于前面三個問題比較好排查，所以單獨列在了一起。泛娛樂行業技術服務白皮書 90采集編碼慢問題此類問題也會一般比較明確，但是排查時會

152、使用到相關GPU廠商的GPU-LogView工具，所以相對于前面幾個問題要更具備GPU本身的排查代表性。91 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書3.2.2.3.4 排障思路采集編碼慢問題(圖2 黑屏問題的原因腦爆)上圖是黑屏中做的所有排查方向，核心的主線分為三類：-OS內部問題系統(Guest OS)態-平臺側問題底層(包含宿主機)相關-應用態問題客戶自身實現的應用或最終玩家等其他平臺不可控因素黑屏問題的難度在于造成黑屏的原因太多了，或者說任一類問題造成的表象都可能包含渲染黑屏，要解決黑屏問題首先的理解，黑屏是怎么產生的，屏幕畫像的產生泛娛樂行業技術服務白皮書 92來源于底層渲染

153、計算生成的畫面通過解碼、封裝、捕獲等方式呈現出來，一旦出現異常，最先懷疑的就是渲染計算的情況，所以對于黑屏：系統態排查我們首先確認了當時系統內相關資源的使用率情況，發現都比較高，特別是CPU資源與GPU資源方面，因為GPU的調度是需要利用CPU資源的(比如隊列處理等)，而游戲本身占用的CPU可能會很高(特別是3A大作)，所以當CPU負載較高時會導致GPU調度不了，形成了成像失敗，最典型的情況就是CPU負載很高，GPU負載不高，通過渲染類連接(比如調用了GPU的VNC界面)看是黑屏狀態，但是通過RDP協議訪問卻只是卡頓(因為CPU分配不足)，這就是第一個系統態異常的懷疑點，下圖為GPU滿是最終玩

154、家感覺到黑屏時的任務管理器界面：93 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書通過ProcessExplorer可以看到更具體占用GPU的情況：通過對應進程獲取相關堆棧信息，下圖為CPU滿時導致的黑屏與RDP卡頓(關于RDP卡頓將在RDP卡頓中詳講)問題可以看到前面9core(客戶使用的VM為定制版的9 core)全部被對應游戲進程占了80%左右：泛娛樂行業技術服務白皮書 94針對這種情況，建議根據排查出的游戲進程進行優化即可。平臺側排查關于第二點，前面說過，CPU使用率是云游戲場景中比較重要的指標，若有其他非主觀因素影響了CPU的使用也會導致黑屏幾率上升，通過分析宿主機記錄的Cach

155、e-line相關計數情況，我們發現該客戶云游戲VM的cacheline(當執行原子操作地址未對齊時就會跨越兩個cacheline進行傳輸，在Intel架構中將這種現象的量級定義為split-lock，而原子地址沒對齊的場景，在Intel架構下是允許的，在諸如ARM架構下則是禁止的；cacheline即CPU在處理數據時與內存映射地址進行通訊時的緩存通道，該通道起到預存數據的作用，同一個cache1line的傳輸時延會下降)產生得特別多，Cacheline問題的不斷上升觸發了Cacheline一些限制措施，從而使得CPU使用被”壓住“，導致無法充分發揮CPU性能調度GPU資源來實現渲染，關于該問

156、題對于技術服務側來說有更加方便的方式判斷，也得益于眾多阿里云先驅前輩的白屏化進程，使用內部系統可以直接將具體時間線輸出明確對比黑屏時間：從底層宿主機看下是否存在一些基于Cacheline問題的限制，我們從當前case發現確實存在Cacheline問題的限制，所以就進行了一些限制解除的實驗，最終確認了與Cacheline強相關，但是游戲廠商進程無法通過去殼手段來進行分析（也不在平臺分析范圍內），所以對于游戲進程產生的cacheline交由客戶與游戲廠商繼續分析，不過整體解除Cacheline限制后黑屏情況相較于優化性能后又再下一城。這一點同時也是Log慢的核心原因在某個案例可以看到經過兩輪的優化

157、，從一開始平均1k+下降到600+，再到400+：95 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書兼容性類排查在解答這一點前，我們需要確認幾個基礎概念：視頻相關API：主要用于捕獲、加速渲染等作用的API，N卡常見的有：微軟提供的DDA(Desktop Duplication API)以及NV提供的NVFBC(NVIDIA Frame Buffer Capture API）GRID：N卡的核心虛擬化技術，由NV開發與提供，也是N卡虛擬化主流的實現方式，包含前后端驅動，GRID11、12均為GRID的版本TDR：Timeout Detection&Recovery，GPU的調度超時相關指標

158、，默認應用程序請求GPU資源超過2s(可調)就會在日志中記錄一條warning級的TDR，NVIDIA對此也有相關解釋，從GPU配置程序入手配置的話可見鏈接。3.2.2.3.5 驗證思路黑屏與TDR驗證了解完基礎概念，這一點也是本次解決黑屏最重要的一點，如圖2所示，驅動的兼容性是否有問題，這一點其實在專項介入早期就已經發現客戶在使用解碼、編碼接口上用了較為老舊的NVFBC接口(NVFBC接口是NVIDIA提供的相關渲染接口，是廠商提供的特定功能接口，具體可點擊鏈接查看，偏視頻渲染領域)，而在最新的Win-dows Server 2012+開始NV明確表示了不再支持?？蛻羰褂肍BC接口方式也從客

159、戶的業務日志中有所發現泛娛樂行業技術服務白皮書 96其次，在客戶反饋的黑屏時間段里存在大量的TDR：事件管理器中類型為Warning的Display事件，EventID為4101，所以接下來的排查重點就聚焦在：TDR與黑屏是否有直接關系DDA與FBC是否為黑屏的突破點TDR Delay驗證驗證第一個問題并不困難，通過對比沒有黑屏的機器可以明確的看到沒有TDR信息，同時客戶自身采集的邏輯也包含了TDR數量的檢測，在TDR數量少的情況下同等黑屏次數也很少，所以第一個問題基本得到驗證，在第一part的圖里也可以看到關于云游戲底層的IaaS邏輯是這樣的：97 泛娛樂行業技術服務白皮書泛娛樂行業技術服務

160、白皮書當出現TDR時，意味著兩種可能性，預期內的可能性是當時游戲負載較高，導致顯卡響應不過來了，在3A類型的游戲大作中渲染超2s的情況不算多見，但是也會有，量級一般可控，量級大到導致黑屏的確實少見，而另外一種預期外的可能就是在運行時遇到了驅動級或者不可用的函數導致等待不到GPU控制器的回復產生的超時，為了驗證這個理論，我們與GPU研發討論后，進行了TDR Delay驗證，即把TDR的閾值從2s調整為10s，可以參考以下指引：切換DDA驗證調整TDRDelay后發現黑屏次數確實有兩位數的下降，但總量依舊是在千級別，證明了客戶業務確實存在TDR預期內的問題，但是不是黑屏的主因，很可能是因為預期外問

161、題導致這些預期內的問題被放大，那么做了這個實驗后就基本確認TDR問題聚焦在預期外問題，預期外問題剛好與排查重點2有重合，因為DDA與FBC模式且好是驅動層面中Rendering階段核心的接口因素，基于此，我們開始了第二輪實驗：對接泛娛樂行業技術服務白皮書 98口進行切換，從FBC切換成DDA觀察，非常有幸的是，本來我們都準備拉齊研發資源幫客戶做好切換的相關測試與驗證，沒想到客戶集成了切換模式，切換成DDA成本很低，所以僅用時1天就完成了50%量從FBC切換DDA的操作，下圖是完成后觀察兩天的結果，可以看到相對于FBC無論是次數還是發生頻率都大幅下降了，基本上證明FBC為核心問題，而TDR為判斷

162、該問題是否解決的標志：3.2.2.3.6 解決之道現在我們經過多輪的驗證與排查、觀察，可以發現FBC，降低TDR是完成單臺VM100次黑屏的解決之道，但是解決僅僅是切換DDA即可嗎？答案顯然不是，雖然黑屏情況有了大幅提升，但是離客戶的核心訴求依舊有一定差距(平均200+，目標 匹配的驅動版本 新版本驅動，特別是NV廠商，坑坑洼洼很多，很多問題換個前端驅動(所謂的后端驅動就是宿主機層面泛娛樂行業技術服務白皮書 100層面的虛擬化驅動)可能就解決了o游戲核心鏈路協議：DDA在某些特定游戲場景下有坑，采集慢，同時鏈路耦合度太高，不便于排查，但是對于新Guest1OS版本友好(雖然在GRID112上有

163、坑），FBC是NV老牌接口，目前已確認廢棄(對特定客戶開放持續支持，比如本篇中的客戶就是NV單向承諾了，所以才敢繼續使用)，但是其相關鏈路分開，不同鏈路間可打點位置多，對于游戲業務比較友好。o設備層面：從設備管理器看可以確認映射的虛擬顯卡是否有被注冊到OS內的PCI接口上，若有顯示但是未能被正確識別則很可能是驅動問題；系統外：oGPU硬件(更建議找虛擬化團隊、AIS團隊)：從從業經歷來講，GPU硬件應該是為數不多能夠與內存故障相匹敵(如果相同基數的情況)的部件了，在本次專項中筆者做得最多的就是上NC、VM打nvidia-smi(VM內部看到得更多是進程對應的GPU損耗)，這個可以確認GPU是否

164、存在掉卡以及顯性的UCE錯誤，而對于GPU硬件故障也可以看對應NC或CN的具體message，看看是否有XID之類(有XID不一定是硬件故障，具體可參閱NV的XID列表)的報錯：101 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書 102o軟件層面(更建議找虛擬化團隊、管控團隊)：可以重點檢查下vmem分配情況以及相關xml對應的pci設備是否正常，還有后端版本是否符合預期。3.2.2.4 游戲陪練場景與架構3.2.2.4.1 游戲陪練簡介游戲陪練是指陪客戶玩指定的網絡游戲，并提供隨程語音、文字聊天服務。陪練服務也分為有償和無償兩種。有償陪練是指玩家個人主動提出需求

165、，并需要支付一定的報酬才能夠獲得陪練服務；無償陪練通常是游戲廠商為推廣游戲而安排人員在網吧陪伴玩家。當然，也有一些游戲公司讓員工在游戲里陪玩家玩，借機圈錢。其中，有償陪練是一種被游戲玩家逐漸關注的全新游戲服務形式。之前報道的魔獸VIP會所便是專門為有錢人提供的線下陪練服務，但這樣高規格游戲陪玩服務屬于鳳毛麟角，網上討論比較多的還是線上游戲陪練。有償游戲陪練分為兩種：1）第一種是游戲陪練江湖中的自由派，個人單個和用戶陪練，不愿意加入任何游戲組織公會，他們的生意有時候會很冷淡，需要自己在各個社交平臺上推銷自己。2）第二種是加入一定游戲組織公會，價格收取就高很多，有時候游戲公會組織會給派一些比較好的

166、陪練單，這樣的陪練費會更高。對于游戲陪練服務，有評論稱這可以滿足部分玩家追求熱鬧的游戲需求。但也要謹防陪練過程中產生的利益糾紛或詐騙行為，以及警惕借游戲陪練之名進行色情活動等違法情況的出現。3.2.2.4.2 陪練業務行業定位客戶APP介紹客戶APP201X年正式上線，平臺注冊用戶已超6000萬，匯聚了超過800萬電競大神。覆蓋王者榮耀、英雄聯盟、英雄聯盟手游、絕地求生、和平精英、永劫無間、守望先鋒、刀塔2、第五人格、堡壘之夜等各種主流游戲娛樂。更有超過6000萬的游戲玩家注冊成為大神，解鎖全新游戲體驗?？蛻暨€有10余支明星戰隊入駐：可參加iG、DYG等各大明星選手水友賽，也可參與多個戰隊官方

167、青訓招募晉升職業賽場。103 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書客戶APP特點基于時間+LBS定位,匹配技能玩家在APP中，用戶除了可以通過”大神”榜單排名進行選擇外，還可以根據自身的需求，進行精準條件篩選。技能分類：根據用戶需求找到各品類的玩家。匹配：基于LBS定位搜索到附近玩家。玩家動態的算法推薦：在App首頁“推薦“功能下，用戶會接受到匹配自身喜好的玩家動態。游戲連麥玩法多樣眾多熱門游戲(英雄聯盟LOL、英雄聯盟手游、王者榮耀、和平精英、永劫無間、絕地求生PUBG、刀塔2、守望先鋒、Apex英雄、第五人格、穿越火線等)，由經過嚴苛考核的游戲大神領頭，帶來全新游戲體驗。除了玩

168、家大神，更有各大明星戰泛娛樂行業技術服務白皮書 104客戶APP特點基于時間+LBS定位,匹配技能玩家在APP中，用戶除了可以通過”大神”榜單排名進行選擇外，還可以根據自身的需求，進行精準條件篩選。技能分類：根據用戶需求找到各品類的玩家。匹配：基于LBS定位搜索到附近玩家。游戲連麥玩法多樣眾多熱門游戲(英雄聯盟LOL、英雄聯盟手游、王者榮耀、和平精英、永劫無間、絕地求生PUBG刀塔2、守望先鋒、Apex英雄、第五人格、穿越火線等)，由經過嚴苛考核的游戲大神領頭，帶來全新游戲體驗。除了玩家大神，更有各大明星戰隊、熱門主播與玩家一起打游戲。APP主要功能首頁首頁的“關注“”推薦“”附近“以算法推薦

169、將大神動態推薦到更匹配的用戶首頁，讓同類用戶更容易找到自己感興趣的內容和玩家。并且，App依托算法技術，精準推送4個用戶喜好的品類在首頁并通過“更多”鏈接全品類。娛樂在“發現”板塊更有客戶的特色品類：直播、聊天室、活動中心等。廣場用戶可以自己發布文字、圖片、視頻等動態，與其他用戶評論、點贊等互動，讓用戶之間從技能交易成為技能社交。聊天用戶將在這里完成在線溝通，除了常規的交流外，還可以贈送豐富的鉆石小禮物，增加用戶之間的默契度。我的【個人主頁】編輯豐富個人形象。105 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書3.2.2.4.3 陪練云上架構客戶在阿里云上資源主要分布在華東地域，部分出海資

170、源在東南亞。作為阿里云的早期用戶，客戶伴隨著阿里云一起成長，使用產品種類涵蓋了阿里云絕大部分主流產品，是阿里云數據庫產品的重要客戶之一。隨著公司業務的快速發展，尤其自2020年至今，客戶APP注冊用戶和平臺數據量呈現爆發式增長，給企業整體IT成本，業務系統穩定性以及業務擴展性帶來了極大挑戰。經過細致的市場調研，客戶陪練技術團隊決定與阿里云展開合作，通過引入多款阿里云自研數據庫產品，包括云原生關系型數據庫PolarDB、云原生內存數據庫Tair、云原生多模數據庫Lindorm、圖數據庫GDB等，有效支撐了核心業務數據爆發式增長，以及高并發業務場景，保障了用戶的流暢體驗?？蛻魯祿旒夹g負責人表示，

171、阿里云自研數據庫良好的擴展性和高性能，幫助他們構建了堅實穩定的基礎數據架構；基于阿里云自研數據庫體系，他們在IT基礎上實現了40%的降本，同時在阿里云數據庫生態基礎上，自研了一套DB智能平臺，提升了100%DB治理效率。泛娛樂行業技術服務白皮書 1063.2.2.4.4 業務場景與案例圖數據庫GDB助力客戶完成多場景方案構建：數億級關聯關系數據查詢毫秒級響應 業務挑戰 客戶本身是帶著社交屬性并且擁有千萬級用戶的龐大組織關系網絡，光社交關系達到4億多的數據量，在用戶的多層關系查找中(尤其是3層及以上)，傳統關系型數據庫的讀取性能及SQL復雜度遠遠超出業務的預期;因為信安部門對全局安全的把控，需要

172、全鏈路監測黑產的流動，因此需要建立跟蹤全局的網絡關聯關系;需要基于各種游戲、普通用戶、游戲大神及LBS構建知識圖譜，提升用戶接受推薦和使用的體驗;解決方案 圖數據庫GDB自動構建索引的特性為客戶帶來良好的查詢性能，高度兼容Grem-lin圖查詢語言可以快速進行關系查詢開發;圖數據庫GDB在客戶5000萬用戶的基礎上構建了知識圖譜和社交關系網絡，提供了基于用戶關系和知識圖譜的數據準確推薦和數據挖掘分析的能力;圖數據庫GDB在客戶進行社交推薦場景下快速匹配人群，并且通過GDB查找關注列表中正在進行直播的主播，以及在關注的人群和粉絲列表中篩選在線的用戶。107 泛娛樂行業技術服務白皮書泛娛樂行業技術

173、服務白皮書用戶價值阿里云圖數據庫GDB支撐了客戶千萬級用戶和眾多游戲品類的知識圖譜安全風控、社交關系的構建，為客戶在眾多業務場景下帶來了高效，安全，便捷的體驗?；谥R圖譜和社交關系的構建，大幅提升了一鍵找人，玩一玩等功能的推薦效率，數億級數據量多層查詢毫秒級響應。ECS產品支撐客戶互娛業務快速增長 客戶痛點客戶業務的計算、網絡和存儲都非常密集，且概率性發生過網絡與存儲抖動問題，影響終端用戶體驗的流暢性，運維團隊也深受困擾。由于缺少體系化的方式對ECS實例規格進行標準化管理，原ECS實例規格零散；隨著客戶業務持續快速增長，運維管理成本和潛在業務風險也持續變高。解決方案阿里云為客戶提供電商場景容

174、器化改造與部署方案：結合客戶的業務場景，選用VCPU:MEM=1:2的c6e系列實例，依托第三代神龍最新架構，通過芯片快速路徑加速，大幅提升實例存儲、網絡通路性能。搭載使用ESSD存儲，提供業界第一的IO能力。對存量ECS實例規格進行系統化評估，提供實例規格升級引導，從無到有協助客戶建設ECS實例規格選型體系。泛娛樂行業技術服務白皮書 108客戶價值借助第六代增強型實例的強勁性能，貼合滿足互娛行業對計算、網絡和存儲的密集需求，減少抖動毛刺，提升端用戶娛樂體驗。ECS實例規格選型體系化，場景化選型從根本上解決實例規格零散帶來的運維管理成本和潛在業務風險，增強整體系統穩定性。利用第六代增強實例的技

175、術紅利，單實例性價比提升，支撐業務快速增長的同時，節省單用戶IT成本用云健康監控共建專項加速抖動問題定位專項背景抖動問題一直是影響客戶業務的主要因素，影響業務抖動問題原因較多且出現問題時都很難快速定位，有時一個抖動問題定位時長甚至長達2個月都沒確定抖動來自于哪個環節，各組件當前自證清白能力比較弱，解決抖動問題的效率亟需提升。在之前Pingtrace解決了當下可復現的抖動問題基礎上，進一步針對歷史某一時刻出現的不再復現的抖動問題，增加各種監控手段，抓取相關信息，達到解決抖動問題的目的。目前抖動監控系統，已經部署在客戶400+實例上客戶反饋效果甚佳。109 泛娛樂行業技術服務白皮書泛娛樂行業技術服

176、務白皮書業務價值從0到1建設客戶業務側到阿里云底層的全鏈路監控系統。通過精細化指標，快速發現和定位問題并實現告警和應急處置聯動。提升客戶用云異常事件處置效率，提用云體驗。服務展望在做好底層云產品服務支持的基礎上，需要深入了解客戶業務架構、業務場景，加深行業了解，結合對客戶業務的了解匹配更優的解決方案，從被動響應到主動出擊，基于服務海量客戶的最佳實踐，更好地協助客戶做好產品選型，進一步提升云服務在客戶業務發展上的價值。3.2.3 游戲泛娛樂場景與架構游戲場景屬于泛娛樂場景中一個重要的環節，進入21世紀伴隨著互聯網技術的普及的紅利各大游戲公司如雨后春筍般增長起來，一批又一批高質游戲被打造出來。隨著

177、云技術的發展，游戲業務已經在傳統機房逐漸暴露瓶頸，具備快速彈性擴容特點的云計算也收到了大量開發者的青睞。本節將重點為大家介紹云計算背景下的游戲泛娛樂場景與架構。3.2.3 游戲泛娛樂場景與架構超快增速較長開發周期生命周期兩極化快速迭代收益迭代投入周期泛娛樂行業技術服務白皮書 110較長開發周期泛互娛場景下的游戲通常來講一款高質量的游戲，通常上線前要經歷大量的時間來進行開發打磨精品游戲通常開發周期都需要一年以上的周期，有的甚至四五年以上的努力打造一款游戲，所以整體看下來泛互娛場景下的優質游戲通常前期的開發成本，運營成本和開發周期相對都會比較長快速增長眾所周知，一款精心打造的游戲上線前通常都需要經

178、過大量的時長調研，大量的時長運營，各大平臺引流宣傳，確保有足夠的熱度形成一個良好游戲氛圍。所以對于很多游戲來說剛上線就會接近巔峰，增速極快。所以很多游戲推出的時候即使做了大量的市場調研，但是也會有很多爆款游戲超出預估的情況，所以為了滿足大部分玩家的游戲體驗通常會提前規劃好快速擴容措施和限流方案，保持游戲的持續增長?？焖俚捎谑忻嫔系挠螒驅映霾桓F，所以要想維持一款游戲的熱度和玩家的粘度，就必然需要快速的進行游戲的迭代以滿足玩家不同階段的新鮮感與游戲體驗。反之，如果缺少對應的快速迭代那么玩家的熱度將會很快褪去，對應游戲也將逐步被替代。所以基本一般的優質游戲都會有每周一小更，每月一大更，不斷迭代游

179、戲內的劇情和玩法使游戲保持熱度。生命周期兩極化游戲的開發在當下的環境可以理解為是一次豪賭，如果賭贏了，獲得了市場認可，造就一款爆款游戲，發行團隊嘗到甜頭將會持續丟帶，一款優質游戲可以持續幾年保持熱度，生命周期相對來說很有可能就會和一家互聯網公司的生命周期保持同步。但是也有非常多的情況，有些游戲推出后沒有得到市場很好的反饋，后續投入乏力將也會很快被淘汰掉。所以對于生命周期來講是會有明顯的兩級分化情況。3.2.3.2 游戲泛娛樂架構隨著游戲行業的快速發展，泛娛樂場景的游戲架構也非常多，這邊大致整理幾種架構提供大家做下參考。111 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書常規單機類游戲架構通

180、過登錄認證支付服務獲取token進入到游戲，通過高防來抵御DDOS攻擊，玩家數據存儲在redis中，redis作為存儲來記錄玩家信息。中型劇情闖關類游戲架構圖經過CDN來提速提升玩家體驗，前端通過高防來防護DDOS攻擊，通過SLB后端掛載RS的方式來實現橫向擴展，玩家數據存儲在MongoDB中，通過redis作為cache來加速訪問提升玩家體驗。泛娛樂行業技術服務白皮書 1123.2.4 游戲技術服務演進3.2.3.3 原始架構時代從典型互聯網的BS架構向游戲CS架構轉變從游戲形態來看，客戶端游戲早期以CS架構為主，而不用BS架構。CS框架的好處是將游戲數據存儲在本地，能夠充分發揮主機性能，使

181、得玩家能夠獲得流暢的游戲體驗，個大型的網落游戲服務器應該包含幾個模塊：網絡通訊，業務邏輯，數據存儲，守護監控(不是必須)，其中業務邏輯可能根據具體需要，又劃分為好幾個子模塊，運維階段面臨的問題更多是游戲內多模塊的調用，所以核心要做到Server端的細化服務運維。113 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書3.2.3.4 石器架構時代從傳統IT“All in one”架構至云上穩定性架構轉變而在頁游、手游形態階段，架構較為通用，這階段以弱交互游戲為主，這種服務器架構和我們常用的web服務器架構差不多，也是采用nginx負載集群支持服務器的水平擴展，多以LNMP/LAMP架構為主，且大

182、部分未做高可用?？蛻舳送ㄟ^入口到游戲大區列表，根據選服務訪問對應系統，web層面多用Nginx或apache，結合php-fpm或tomcat，數據層落單點mysql存儲，這樣單游戲在一臺服務器上的架構我們形象的稱之為“All1in1one”架構。這個架構最大的問題無疑就是故障場景往往無法快速恢復，在極端的硬件損壞場景影響往往很大，所以非常依賴運維工作，這也是最早刀耕火種模式，運維需要建設數據庫備份模式、異?？焖倮鹉芰?、服務進程穩定性等。瀏覽器BrowserWebseverDatabaseserverClientServer客戶端程序服務器（業務邏輯服務器和數據庫服務器）服務器數據庫訪問返回

183、結果查詢返回結果訪問返回結果典型互聯網的BS架構向游戲CS架構轉變傳統IT“All in one”架構 云化架構泛娛樂行業技術服務白皮書 1143.2.3.5 黃金架構時代多游戲場景的精細架構演進 隨著游戲業務場景多樣化，云產品更加豐富，架構使用上更加精細化。就有了云原生游戲架構，通過云產品能力等組合打出場景支撐組合拳，讓運維更簡單。當后期國內游戲受到政策影響，及國產化游戲出海成為趨勢，海外加速也不斷的涌現，更加劇了全球同服架構進化。同時，面對游戲運維、運營的各種業務需求，也派生了多場景大規模數據存儲、數據分析等架構，時至今日，架構還在不斷精進。某游戲云原生游戲架構某游戲海外加速架構115 泛

184、娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書四、泛娛樂業務保障與調優最佳實踐4.1 游戲運維SRE實踐4.1.1 制定SRE黃金準則架構設計準則-我們認為所有的架構都是不完美的，都存在缺陷，因此我們在做業務架構設計時都必須要考慮服務穩定性保障，如負載均衡、多點容災、集群化服務、數據多活等能力；SRE前置準則-在業務立項之初，SRE角色需要提前介入，將運營階段可能出現的問題或風險提前在架構設計、編碼階段暴露，提前準備好解決方案，甚至規避問題與風險；混沌實驗準則-故障不可避免，為何不讓其在測試或預發布環境提前到來，通過模擬現網真實故障來驗證服務的“韌性”，找出系統的弱點，同時驗證我們的監控告警的

185、有效性，在MTBF階段實施最好不過，也是我們其中一把利器；可觀測性準則-通過采集業務指標、日志、追蹤等數據，快速分析與定位問題，同時發現復雜系統的瓶頸點，在很長一段時間內，業務指標、日志、追蹤的采集與應用，都是獨立存在并分開建設，隨著時間的推移，發現這三者是相互關聯，相輔相成的，是我們的第二把利器；全鏈路壓測準則-通過與可觀測性、混沌實驗能力的深度整合，實現模擬真實業務環境全鏈路壓測，達到業務上線前的精準資源評估，主動發現潛在性能、版本缺陷等問題，是我們的第三把利器；DevOps交付準則-通過打造高效的價值交付鏈，覆蓋CI、CD、CO服務全生命周期運營管理，CI我們采用ODP封裝藍盾方案，CD

186、 與 CO 采用藍鯨運維編排及監控告警等能力，SRE會將大分部精力聚焦在CO環節；故障應急準則-故障不可避免，我們能做的是不斷去提升MTBF，降低 泛娛樂行業技術服務白皮書 116自動化運維體系自動化安裝系統自動化運維平臺自動化安檢系統自動化客戶端更新系統自動化服務器端更新系統自動化數據分析系統自動化數據備份系統自動化監控報警系統自動化運維體系構成及結構關系圖圖例順序關系關聯關系支撐關系MTTR，包括事前的實施大量混沌實驗、故障預案；事中采用打造的工具鏈，快速發現、分析、定位與解決問題；事后組織總結復盤，沉淀案例經驗；SRE學習準則-營造學習的文化，目的是實現多個不同職能團隊的有機融合，相互了

187、解大家面臨的問題或挑戰，形成一致的目標，達到有效的協同，解決業務。4.1.2 游戲自動化運維體系構成4.1.3 游戲部署的自動化實踐傳統IT模式的“半人肉”部署實踐 游戲運維的早期開服以人肉為主，分區分服務階拆解的最原始動作包括：游戲服務端打包-解壓游戲包-變更配置修改區服務-初始化數據庫(清檔)-qa測試-對外開放入口。如果今天的服務器只有一臺兩臺沒有問題，隨著服務器數量增多，實踐117 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書自動化運維體系構成及結構關系圖多，實踐中經常遇到游戲火爆的突發開服事件，而且在2011年后游戲聯合運營模式出現，人肉模式會涌現了很多問題，而且隨著開服時間拉長

188、，到一定生命周期后也面臨著繁復的合服工作，游戲運維對開服、合服做了腳本化工作，那也是自動化的早期雛形，可勉強應對數千臺規模的服務部署。早期的版本部署/變更腳本示例：基于shell半自動化工作，基本可以應對百至千服的常規工作，隨著虛擬化普及，游戲上云后ECS鏡像功能。游戲運維會建立每個游戲服角色鏡像：這個操作會讓你快速啟動另一組服務器，例如你搭建完一組，共三臺，游戲服1，游戲服2，游戲服3，調試完畢后，為每個服做一個鏡像，這樣你就可以快速啟動1組新服，很快就可以完成上百組服務器的配置，在需要開新服時，你基本5分鐘就可以開一組，所以為每個不同角色的游戲服留鏡像是很有必要的，同時也可以使用跨區復制功

189、能，快速在另一個region搭建新服，快速完成多region部署，這些工作通過api是可以做到完全自動化的，基本實現了數千臺規模的服務部署。泛娛樂行業技術服務白皮書 118基于Ansible的自動化部署實踐最早我們用SSH寫很多腳本，要用SSH連過去，也是在某一臺機器上執行，不用在目標機上登陸。這種做法在相當一段時間內是我們實際使用的手段，它實際上比 Puppet有效。但是它有一些問題：管理成本高、腳本會越來越多。部署的過程有很多的基礎部件需要反復部署，幾乎是沒法管理。后來我們用了RunDeck，它有界面、有一定的管理能力。我們還用過Fabric，即批量執行命令，能做到類似部署的事情。但是，目

190、標機規模大了之后僅有管理的能力是不夠的。后來我們又調研過 Salt，不認為有太大的差別。選擇Ansible主要因為豐富的相關支持，包括很多現有的組件和模塊和開源的Ansible部署和腳本。我們的團隊不喜歡糾結。我們發現Ansible沒有太本質的區別，就開始用起來。它可以配置系統，部署軟件以及協調更高級的IT任務，例如持續部署，滾動更新。Ansible適用于管理企業IT基礎設施，從具有少數主機的小規模到數千個實例的企業環境。具備了簡單、強大、無代理的三大優勢。簡單的說底層就是pssh的批量邏輯，上層封裝playbook執行，語法非常接近shell，從歷史的部署模式進行改造非常方便，基本實現了數萬

191、臺規模的服務部署。119 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書4.2 游戲穩定和安全的具體案例對于一些全球同服的游戲來說，穩定性問題如何解決？阿里云提供的全球同服解決方案，大概分三個層面。第一個層面，解決跨國骨干網絡的傳輸問題。游戲產品需要一條穩定、低延時、幾乎無丟包的通信線路，才有可能去構建一個所謂的全球同服架構。在使用云服務前，用戶需要去花極高價格去租借跨國通訊線路，整體流程也非常冗長，而且當業務臨時發生變化，變更成本會非常高。如今，用戶點幾下鼠標就可以了。第二層，全球數據的交互和同步。在分布式緩存時，很多數據會送往唯一決策的地方記錄和計算?？梢哉f，數據同步是一件難度不低的事情

192、，除了要求穩定的網絡鏈路外，還需要有很好的同步機制。當同步出故障時，未完成任務如何繼續處理，如何避免“腦裂問題”(兩邊數據對不上)，在此基礎上如何保證數據同步服務的高穩定性。針對數據同步，阿里云提供了一個很專業的數據同步服務，除Oracle以外，它幾乎已經支持所有關系型數據庫的數據同步內容，包括緩存的數據同步。第三層，全球范圍流量調度能力。你可以把這部分理解為最后一公里，在前面都已經部署完成后，這個最后一公里顯得尤為重要。就算此前的骨干網絡效果再好，如果最后一公里接錯了位置、或者經常抖動，整體效果也不會很好。具體來說，全球調動能力主要通過幾點。其中一點是阿里云這邊的智能DNS解析，這個功能會根

193、據用戶所在IP地址，提供相應的訪問接入點。針對安全防護，游戲運維怎么辦？通過阿里云DDoS高防、風險識別等安全產品，幫助游戲行業客戶構建全面的安全防護體系，滿足抵御攻擊、合規運行、提高業務風險等級等不同場景的安全需求，保障游戲業務運行的穩定、安全。應用場景DDoS攻擊防御：通過DDoS高防或游戲盾有效抵御各類流量攻擊，避免流量攻擊造成游戲業務卡頓甚至癱瘓影響玩家游戲體驗。泛娛樂行業技術服務白皮書 120擊造成游戲業務卡頓甚至癱瘓影響玩家游戲體驗。游戲防沉迷：對玩家身份信息真實性進行核驗，驗證用戶為真人且為本人，防止未成年人沉迷游戲，同時有效避免未成年人冒用賬號問題。游戲風控：通過游戲風控，解決

194、羊毛黨、機器人、賬戶資金的異常提取、盜號等安全風險，避免灰產工作室惡意注冊、撞庫、垃圾賬戶等業務風險引發的平臺資損及品牌影響。等保合規：通過等保套餐幫助客戶具備等保要求的安全能力，快速幫助企業滿足國家合規監管政策要求。方案優勢快速構建基礎安全能力：通過DDoS防護、云防火墻和云安全中心，即開即用，幫助客戶快速建立基礎安全能力保障業務連續性，能夠防御典型網絡攻擊和入侵檢測，保障游戲登錄等平臺穩定性。整體縱深防御體系：通過阿里云最完整的安全技術產品，幫助客戶實現網絡、主機、應用、數據、業務五大維度防護能力，構建完整的云上縱深防護體系，在抵御攻擊提升安全能力的同時，能夠滿足安全合規要求。特色游戲場景

195、化風控：針對游戲打金工作室、虛假注冊、游戲小號、薅羊毛、盜號、虛假點擊等黑產行為，通過風險識別產品，幫助客戶構建風險畫像，結合智能算法先進技術進行精準識別，可大幅減少黑產對游戲運營、經濟系統、玩家體驗等造成的傷害及影響，實現降本增效。121 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書安全方案架構泛娛樂行業技術服務白皮書 122五、未來趨勢泛娛樂行業契合現代消費通過泛娛樂IP的視頻、游戲和文化聯合的方式，整合更大的用戶群體，帶動更多的就業并且有更多的其他行業人士加入。在消費領域上，泛娛樂行業消費不僅僅局限于傳統的直播廣告和游戲內充值的消費，它依據短視頻和直播的傳播能力、游戲打造經典IP的能

196、力，配合文化上的打磨，形成線上線下提供更加多元化的消費模式。多元化消費模式更符合當代的消費觀，從而宏觀上刺激消費升級。泛娛樂行業快速適應新興技術 最近幾年隨著大數據、云計算、物聯網、人工智能等新一代技術的廣泛落地，使得新技術、新商業模式快速普及。從科技技術在游戲領域的落地，例如VR、AR等虛擬現實，泛娛樂行業打造強有力的IP基礎，帶動新興文化的發展。同時新興技術在視頻直播中快速普及，使得泛娛樂全民化，并形成超級IP的知識體系。泛娛樂行業出海擴張更容易占據市場 不斷擴大的用戶群體和高留存率，讓中國泛娛樂企業在出海擴張中更容易在市場中扎根立足。企業通過在中國市場基數龐大、技術先進、傳播力量強等特點而建立的堅實基礎，會在海外市場打造出更加龐大的泛娛樂產業。如今，各類游戲已經深深嵌入人類文化之中，因此它們總是緊跟時代精神的發展趨勢。直接影響游戲產業的數字技術領域將有所發展，但不僅如此，從更廣泛意義上來，我們將迎來一場革命性的技術變革。AR和VR引來更蓬勃的發展，機器學習和人工智能在App領域深耕，區塊鏈游戲、云游戲、元宇宙更多的新技術接踵而至，而圍繞游戲技術的行業服務也將越來越成熟。123 泛娛樂行業技術服務白皮書泛娛樂行業技術服務白皮書