直播云平臺(tái)架構(gòu)如何構(gòu)建？【 附PPT】

本文根據(jù)4月26日 UCloud流媒體研發(fā)總監(jiān)曾凱源于〖KVM社區(qū)&UCloud技術(shù)微信群〗線上分享內(nèi)容整理而成。歡迎關(guān)注〖KVM社區(qū) & UCloud〗線上系列分享

注：每一種架構(gòu)在一定程度上都有參考的意義。UCloud 將邀請(qǐng)到了在直播、抱抱直播、Shou.tv和一起玩?？萍嫉募夹g(shù)專家，分享他們?cè)诤Ａ糠?wù)架構(gòu)探索過(guò)程中的技術(shù)實(shí)踐。

如感興趣，您可以點(diǎn)擊文末“閱讀原文”，或?qū)⑷缦骆溄訌?fù)制到瀏覽器打開了解并報(bào)名參加活動(dòng)。

http://form.mikecrm.com/0Whn1K#rd

講師介紹

曾凱源

UCloud流媒體研發(fā)總監(jiān)

主要負(fù)責(zé)UCloud視頻云和 CDN 產(chǎn)品的研發(fā)工作。擁有近十年的互聯(lián)網(wǎng)研發(fā)經(jīng)驗(yàn)，在云計(jì)算領(lǐng)域具有豐富的經(jīng)驗(yàn)。此前，曾任職于騰訊，分別負(fù)責(zé)海量云存儲(chǔ)系統(tǒng)、海量CDN系統(tǒng)以及微信支付、彩票系統(tǒng)的性能優(yōu)化等工作。

演講提綱

本次主要為大家解析UCloud自有直播云平臺(tái)架構(gòu)，分析平臺(tái)架構(gòu)短板以及在用戶規(guī)?？焖僭鲩L(zhǎng)下的架構(gòu)演進(jìn)過(guò)程。

直播場(chǎng)景簡(jiǎn)介

直播云架構(gòu)

核心架構(gòu)演進(jìn)

容災(zāi)及故障處理

直播場(chǎng)景&直播服務(wù)架構(gòu)

直播場(chǎng)景

首先，介紹當(dāng)下很火的直播場(chǎng)景。目前對(duì)直播場(chǎng)景的基本分類主要有媒體&活動(dòng)直播、游戲直播、秀場(chǎng)直播和社交直播。

媒體&活動(dòng)直播

特點(diǎn)：?jiǎn)蜗颍瑹o(wú)交互，流數(shù)少，延遲容忍度高 >10s；包含電視轉(zhuǎn)流、演唱會(huì)直播等。

這類目前對(duì)于直播的技術(shù)要求較低，低上行，高下行。

游戲直播

特點(diǎn)：?jiǎn)蜗?，無(wú)交互，流數(shù)多，延遲容忍度高 >5s；目前國(guó)內(nèi)CDN產(chǎn)商搶得最激烈的一塊。

本身的業(yè)務(wù)場(chǎng)景其實(shí)并不需要那么低的延遲。延遲是2秒、5秒還是10秒其實(shí)對(duì)體驗(yàn)的影響不是十分大。不過(guò)由于競(jìng)爭(zhēng)激烈，拉高了延遲門檻。

秀場(chǎng)直播

特點(diǎn)：?jiǎn)蜗?，文字交互，流?shù)量多，延遲容忍度低 2~5s；這個(gè)是目前大家都能看得到盈利模式的一種。除了主播在播外，觀眾可以點(diǎn)贊，文字，送禮物，有一定的交互性。所以對(duì)直播的延遲要求苛刻，越低越好。推流主要是專業(yè)主播PC端，流數(shù)量多。

此類直播也稱為美女秀場(chǎng)，市場(chǎng)上存在大大小小公司，基本帶寬在1~5G。 秀場(chǎng)平臺(tái)非常多。

社交直播

特點(diǎn)：?jiǎn)蜗颍淖纸换?，流?shù)量非常多，延遲容忍度低 2~5s；社交直播和秀場(chǎng)直播，在交互上類似，區(qū)別比較大有兩點(diǎn)：1. 秀場(chǎng)一般都是有限的主播把內(nèi)容運(yùn)營(yíng)起來(lái)，推流的數(shù)量較少，一般是<100路；2. 社交直播是路人即可產(chǎn)生內(nèi)容，所以直播的流數(shù)會(huì)上升到1000，甚至10000。

目前最火的一塊，有映客，在直播，花椒等。整體直播云的設(shè)計(jì)是以滿足技術(shù)及并發(fā)要求最高的社交直播需求為主要目標(biāo)。

直播服務(wù)架構(gòu)解析

要完成這類直播產(chǎn)品，需要有哪些模塊支撐？通常包括直播內(nèi)容采集、直播后臺(tái)系統(tǒng)和直播內(nèi)容播放三個(gè)模塊。

內(nèi)容采集：采集的方式有很多，從一般幾十塊PC攝像頭到幾十萬(wàn)的專業(yè)錄制編碼設(shè)備，還有移動(dòng)端的手機(jī)前后置攝像頭；分布式推流：這里是比較成熟的架構(gòu)，用戶在推流之前會(huì)通過(guò)名字服務(wù)，一般是DNS智能解析或是自有按IP調(diào)度系統(tǒng)獲取最靠譜的推流節(jié)點(diǎn)，然后把流上傳到服務(wù)器。

直播后臺(tái)系統(tǒng)：在分布式推流節(jié)點(diǎn)“接入”了用戶流之后，后續(xù)一系列的分發(fā)、轉(zhuǎn)碼、截圖、錄制、存儲(chǔ)等構(gòu)成了直播后臺(tái)系統(tǒng)；這里根據(jù)不同的業(yè)務(wù)需求，需要有不同的后臺(tái)服務(wù)來(lái)支撐。

直播內(nèi)容播放：這個(gè)就比較好理解了，一般輸出是PC屏幕、手機(jī)、現(xiàn)在還有VR頭盔。

直播云的云化，主要是解決了視頻流 上傳、處理和分發(fā) 的一系列問(wèn)題。用戶只需要實(shí)現(xiàn)采集和播放即可。

直播云架構(gòu)

直播云最核心、難度最大的部分是直播的流分發(fā)網(wǎng)絡(luò)的架構(gòu)和分發(fā)算法設(shè)計(jì)，直接決定了整套服務(wù)可支撐的并發(fā)數(shù)和質(zhì)量以及服務(wù)成本。

以下重點(diǎn)分析UCloud核心分發(fā)網(wǎng)絡(luò)這塊的設(shè)計(jì)和演進(jìn)。直播云架構(gòu)主要有核心的流分發(fā)網(wǎng)絡(luò)、運(yùn)營(yíng)子系統(tǒng)和業(yè)務(wù)邏輯子系統(tǒng)三大部分構(gòu)成。

運(yùn)營(yíng)子系統(tǒng)包括了調(diào)度系統(tǒng)、監(jiān)控系統(tǒng)和故障處理系統(tǒng)。

調(diào)度系統(tǒng)：實(shí)現(xiàn)直播索引及調(diào)度的能力，主要解決三個(gè)問(wèn)題：用戶去哪個(gè)IP推流？流如何分發(fā)？用戶去哪個(gè)IP觀看？

監(jiān)控系統(tǒng)：實(shí)時(shí)監(jiān)控整套分發(fā)體系的上行壓力、下行壓力、中間網(wǎng)絡(luò)質(zhì)量及服務(wù)狀態(tài)等。

故障處理系統(tǒng)：負(fù)責(zé)IP、機(jī)房、片區(qū)網(wǎng)絡(luò)不可用時(shí)的處理。

業(yè)務(wù)子系統(tǒng)包含了非常多的系統(tǒng)，這里列舉幾個(gè)常見(jiàn)的。

實(shí)時(shí)轉(zhuǎn)碼：是一個(gè)集群，作用是在用戶推流碼率較高（比如720P）、但是會(huì)有移動(dòng)端觀看的用戶時(shí)，需要實(shí)時(shí)轉(zhuǎn)成360P低清晰度的流；這個(gè)子系統(tǒng)實(shí)際服務(wù)能力非常有限，一臺(tái)8核設(shè)備只能實(shí)時(shí)轉(zhuǎn)10 路流，如果來(lái)1000路，就需要100臺(tái)。這里給一個(gè)重要經(jīng)驗(yàn)：如果做不到按流的按需實(shí)時(shí)轉(zhuǎn)碼，建議不要搭建實(shí)時(shí)轉(zhuǎn)碼集群。因?yàn)槌杀緲O高！

實(shí)時(shí)截圖：架構(gòu)和實(shí)時(shí)轉(zhuǎn)碼類似，一般單機(jī)可處理100 流。

實(shí)時(shí)錄制：即將直播內(nèi)容實(shí)時(shí)保存下來(lái)存儲(chǔ)成點(diǎn)播文件。

核心架構(gòu)演進(jìn)

那么，龐大復(fù)雜的直播云背后，核心架構(gòu)的挑戰(zhàn)到底有哪些呢？以下介紹一下UCloud直播云最核心直播流的分發(fā)網(wǎng)絡(luò)架構(gòu)的演進(jìn)。

直播流的分發(fā)網(wǎng)絡(luò)主要挑戰(zhàn)：

高并發(fā)，高上行，高在線。

5億中國(guó)人已經(jīng)離不開在線娛樂(lè)，2006年-2015年，月度覆蓋人數(shù)增長(zhǎng)5倍 ，每人每天花近一個(gè)小時(shí)用于在線娛樂(lè)，2007年到2014年，有效使用時(shí)長(zhǎng)更是增長(zhǎng)15倍 ；不同于傳統(tǒng)的CDN分發(fā)模型，直播是流式的數(shù)據(jù)，主播產(chǎn)生內(nèi)容、云服務(wù)進(jìn)行實(shí)時(shí)的處理和分發(fā)，對(duì)上行的帶寬和質(zhì)量要求也非常高。以最近融資的映客為例，同時(shí)在線主播10000 ，觀眾50000 。

對(duì)比于傳統(tǒng)的CDN，這里有個(gè)重要的架構(gòu)考慮是需要支撐高上行的帶寬。

熱點(diǎn)時(shí)間集中直播流的分發(fā)網(wǎng)絡(luò)。

透過(guò)我們對(duì)大量直播客戶的帶寬觀察發(fā)現(xiàn)，直播的高峰期集中在晚上22點(diǎn)~0點(diǎn)，產(chǎn)品以“你丑你先睡，我美我直播”為宣言，在此期間的帶寬是平時(shí)的5~10倍。

帶寬成本高。

上行帶寬，下行帶寬，中間轉(zhuǎn)發(fā)的帶寬，總體帶寬成本非常高。

分發(fā)質(zhì)量要求高。

傳統(tǒng)的視頻點(diǎn)播，有一個(gè)源站，一份文件可以在發(fā)布的前一天把文件分發(fā)到離觀眾最近的節(jié)點(diǎn)，上行哪怕再慢些也無(wú)所謂，在直播的場(chǎng)景，越來(lái)越多的交互形式，需要實(shí)時(shí)把直播內(nèi)容盡可能快且穩(wěn)定的傳輸?shù)接^眾端。

總結(jié)：這可能是迄今為止最難設(shè)計(jì)的分發(fā)網(wǎng)絡(luò)。

核心架構(gòu)演進(jìn)

直播云最核心的架構(gòu)－直播流的分發(fā)網(wǎng)絡(luò)經(jīng)歷了三次大演進(jìn)。

V1.0 版本——一級(jí)DC

使用多線BGP進(jìn)行全國(guó)覆蓋，憑借BGP技術(shù)解決解決了多運(yùn)營(yíng)商間轉(zhuǎn)播的問(wèn)題，電信主播、移動(dòng)觀看也流暢，同時(shí)也能兼顧到一些小運(yùn)營(yíng)商。

全國(guó)延遲區(qū)間在40ms~100ms；部分地區(qū)用戶網(wǎng)離BGP距離長(zhǎng)，路由極易不穩(wěn)定，高峰期容易卡頓。

由于成本較高，在最初期僅支持4000路上下行，能滿足較小規(guī)模的直播客戶，并且需要設(shè)置較大的播放緩存來(lái)對(duì)抗網(wǎng)絡(luò)丟包和延遲，直播內(nèi)容延遲高。

容災(zāi)方面，單機(jī)房無(wú)異地容災(zāi)，遇到光纖挖斷，機(jī)房變更等會(huì)是致命打擊。

V1.5版本——高突發(fā)架構(gòu)

高突發(fā)架構(gòu)：引入了CDN供應(yīng)商到架構(gòu)中，快速優(yōu)化下行瓶頸的問(wèn)題，下行容量增大N倍，基本不成為瓶頸；

流轉(zhuǎn)推：將熱門主播推流到合作CDN進(jìn)行分發(fā)，從架構(gòu)層面看，是同一分出流量進(jìn)行了多份的復(fù)制；

DNS智能解析：使用智能解析DNS按運(yùn)營(yíng)商、省份、用戶比例將播放帶寬切到CDN供應(yīng)商。

對(duì)于中小型的UGC 產(chǎn)品來(lái)說(shuō)，帶寬上已夠用了。但是BGP的瓶頸仍然存在，并且合作CDN的質(zhì)量不可控。下行的延遲起到了一定的優(yōu)化，但和行業(yè)最優(yōu)還有不小的距離。于是又誕生了V2.0。

V2.0 版本——兩級(jí)DC＋OC架構(gòu)

架構(gòu)優(yōu)化：引入離用戶最近的OC小機(jī)房，推流端也通過(guò)DNS智能解析的方式，將上行分散到各個(gè)OC點(diǎn)。

質(zhì)量上，OC到BGP機(jī)房的路由是可控的，進(jìn)行針對(duì)優(yōu)化，拉城域或區(qū)域?qū)＞€，流分發(fā)穩(wěn)定性非常高，已可支持1秒播放buffer，整體的直播延遲最低可以做到1秒。

瓶頸：由于仍要通過(guò)BGP對(duì)跨運(yùn)營(yíng)商的流做中轉(zhuǎn)，所以上行瓶頸問(wèn)題沒(méi)有得到解決。

缺點(diǎn)：BGP的分發(fā)帶寬上升，對(duì)于不活躍的主播，從BGP 1 to N 的形式， 演變成 1 to M to N，在調(diào)度上需要算法來(lái)決策是否要下行放到OC上。

容災(zāi)能力：BGP機(jī)房仍然是鏈路單點(diǎn)。

架構(gòu)V2.0 對(duì)于架構(gòu)V1.5 來(lái)說(shuō)， 單路流的成本其實(shí)是有上漲，但是質(zhì)量上起到不小的優(yōu)化。在V2.0 中我們也對(duì)BGP進(jìn)行了帶寬擴(kuò)容以應(yīng)對(duì)業(yè)務(wù)增長(zhǎng)。

V3.0 版本

目前最新的架構(gòu)V3.0，引入了區(qū)域三通點(diǎn)，為BGP機(jī)房做容災(zāi)，對(duì)于同一區(qū)域如都在華東的推流和分發(fā)，直接走區(qū)域三通機(jī)房，BGP機(jī)房和三通機(jī)房部署多個(gè)，故障是只要調(diào)整路由即可。

三級(jí)多通架構(gòu)

架構(gòu)優(yōu)化：引入?yún)^(qū)域三通點(diǎn)，為BGP機(jī)房做容災(zāi)，對(duì)于同一區(qū)域如都在華東的推流和分發(fā)，直接走區(qū)域三通機(jī)房，BGP機(jī)房和三通機(jī)房部署多個(gè)，故障是只要調(diào)整路由即可。

分發(fā)策略：對(duì)同區(qū)域的同運(yùn)營(yíng)商的OC先進(jìn)行分發(fā)，如廣東電信有10個(gè)OC機(jī)房，如果推流和播放是發(fā)生在這10份機(jī)房?jī)?nèi)，就可以完全不經(jīng)過(guò)BGP和三通點(diǎn)，降低了BGP和三通架構(gòu)上的帶寬瓶頸。

整套架構(gòu)由BGP、三通機(jī)房、OC機(jī)房和合作CDN構(gòu)成，中間的轉(zhuǎn)發(fā)策略和鏈路非常多，需要通過(guò)主播所在地域、觀眾所在地域，熱度、質(zhì)量、成本的折中來(lái)實(shí)時(shí)調(diào)整分發(fā)的路由。

兩級(jí)多路由回源容災(zāi)

除了引入三通點(diǎn)外，還做了一些容災(zāi)設(shè)計(jì)，這里介紹一個(gè)典型的多路由容災(zāi)。

客戶端到接入OC：使用DNS做負(fù)載均衡，同時(shí)配置多個(gè)OC節(jié)點(diǎn)的IP，降低單點(diǎn)故障影響，同時(shí)監(jiān)控單線路如廣東電信配置是否存在單點(diǎn)。

OC回源：使用自有索引體系管理路由，為每個(gè)OC節(jié)點(diǎn)至少分配兩個(gè)以上的回源路由，并實(shí)時(shí)監(jiān)控上報(bào)各個(gè)oc回源質(zhì)量與各中轉(zhuǎn)節(jié)點(diǎn)負(fù)載信息。

前期靜態(tài)純?nèi)斯ぢ酚删S護(hù)，運(yùn)維壓力非常大，多路由容災(zāi)后起碼節(jié)省了30%的故障處理人力。

故障自動(dòng)處理

對(duì)于龐大數(shù)量的機(jī)房，故障的處理也不容易，比如一個(gè)機(jī)房IP down了，人工判斷如何遷移 IP的帶寬 是可以的，如果是一個(gè)OC機(jī)房或三通機(jī)房，純靠人工計(jì)算帶寬和配置，就很容易出錯(cuò)。

所以有了直播云非常重要的一個(gè)故障處理模塊： 帶寬、負(fù)載動(dòng)態(tài)路由規(guī)劃系統(tǒng)。

分級(jí)：?jiǎn)蜪P、單OC、三通點(diǎn)、BGP、合作CDN 的故障處理算法略有區(qū)別，通過(guò)對(duì)負(fù)載數(shù)據(jù)的線性規(guī)劃算法，可以求出成本和負(fù)載最優(yōu)，風(fēng)險(xiǎn)最低的負(fù)載均攤調(diào)度算法。

故障負(fù)載均攤優(yōu)先級(jí)：

均攤負(fù)載到 同一OC機(jī)房，這樣負(fù)載均攤就控制在機(jī)房?jī)?nèi)；

將負(fù)載均攤到相鄰?fù)》輽C(jī)房，負(fù)載問(wèn)題控制在省內(nèi)消化；

將負(fù)載均攤到區(qū)域機(jī)房，區(qū)域內(nèi)消化；

將負(fù)載均攤到合作CDN；

將負(fù)載均攤到三通、BGP中轉(zhuǎn)點(diǎn).

這里優(yōu)先級(jí)也不是必然，需要根據(jù)實(shí)際情況來(lái)動(dòng)態(tài)調(diào)整。

Q&A

Q1:UCloud的多路推送怎么做的負(fù)載均衡，轉(zhuǎn)碼過(guò)后怎么推送出去的，另外集群調(diào)度是怎么實(shí)現(xiàn)的？

答：多路推送靠DNS配置多IP輪轉(zhuǎn)來(lái)做負(fù)載均衡，轉(zhuǎn)碼過(guò)后不需要推出去，當(dāng)有觀眾的時(shí)候再主動(dòng)回來(lái)拉取。集群以DNS就近接入的方式調(diào)度。

Q2:負(fù)載均衡跨機(jī)房分?jǐn)傆袥](méi)有什么具體指標(biāo)呢？動(dòng)態(tài)變化多嗎？如果發(fā)生動(dòng)態(tài)變化，一般需要多少時(shí)間去處理？

答：1. 帶寬，基于直播場(chǎng)景，其實(shí)CPU,內(nèi)存不是瓶頸。2. 第二是根據(jù)實(shí)際用戶直播的延遲上報(bào)數(shù)據(jù)。

動(dòng)態(tài)變化不算特別多。IP 級(jí)別的容災(zāi)是自動(dòng)化，5分鐘左右。 OC機(jī)房的自動(dòng)處理要看規(guī)模， 2G左右的機(jī)房一般能在10分鐘內(nèi)容完成帶寬遷移。20G帶寬的機(jī)房就需要人工介入，可以優(yōu)先切到合作CDN 再二次決策更優(yōu)的方案。

Q3:不同網(wǎng)絡(luò)環(huán)境網(wǎng)絡(luò)不一樣的時(shí)候碼率，和幀數(shù)怎樣控制？

答：目前直播很少做動(dòng)態(tài)碼率幀率調(diào)整，一般是固定的碼率和幀率。 網(wǎng)絡(luò)質(zhì)量差的情況下做動(dòng)態(tài)碼率，幀率的調(diào)整效果不佳，難以使直播流暢，最終用戶還是會(huì)放棄。

Q4:云CDN和傳統(tǒng)CDN方式什么區(qū)別？

答：云CDN，最大的特點(diǎn)是 和其他云產(chǎn)品如主機(jī)、存儲(chǔ)、計(jì)算等能有機(jī)的結(jié)合起來(lái)。傳統(tǒng)的CDN，僅負(fù)責(zé)對(duì)內(nèi)容進(jìn)行分發(fā)。

Q5:CDN方面目前有沒(méi)有API接口，支持腳本調(diào)用不？

答：有API接口的，詳細(xì)的刻可以瀏覽：https://docs.ucloud.cn/api-docs/ucdn-api/index.html

Q6:OC回源鏈路是什么？什么情況/場(chǎng)景下需要回源？怎么回源？

答：回源鏈路就是決定OC去什么地方拉直播流。OC機(jī)房當(dāng)前沒(méi)有用戶要看的直播流時(shí)，需要往上拉流。

Q7:直播后臺(tái)系統(tǒng)內(nèi)部，底層使用什么協(xié)議？

答：上行RTMP，內(nèi)部轉(zhuǎn)發(fā)有RTMP協(xié)議，也有自研UDP協(xié)議，播放走RTMP/HTTP協(xié)議。

Q8:實(shí)時(shí)轉(zhuǎn)碼：一臺(tái)8核設(shè)備只能實(shí)時(shí)轉(zhuǎn)10 路流，這里是用的cpu核？實(shí)時(shí)轉(zhuǎn)碼需求大嗎？

答：用的CPU核。要看具體場(chǎng)景，如果是PC推流，有手機(jī)觀察的用戶，轉(zhuǎn)碼就有需求，大屏錄制轉(zhuǎn)小屏觀看的情況。

Q9: 目前我知道的CDN延遲都在5s左右，厲害的到2s。既然這是使用了CDN，如何做到40-100ms的延遲的？

答：這里說(shuō)的40-100ms的延遲是指純網(wǎng)絡(luò)時(shí)間，CDN延時(shí)在5s是指的直播內(nèi)容級(jí)別的延遲，是由于在不同設(shè)備上的轉(zhuǎn)發(fā)，各層級(jí)加上了不同大小的緩存造成，另外還有客戶端錄制和播放的消耗。

Q10:關(guān)于推流。如果客戶端源從攝像頭到如ppt類的切換，那么推流方式有在技術(shù)上何不同？如何完成從攝像頭到個(gè)人PC桌面內(nèi)容的切換推流。

答：攝像頭和PPT只是采集方式不一樣，出來(lái)的兩路流在播放的時(shí)候進(jìn)行切換即可。 個(gè)人PC桌面內(nèi)容的推流及合并可以用OBS，可以做串流處理，同時(shí)展示攝像頭和屏幕內(nèi)容。

Q11: 關(guān)于播放。如果不是m3u8（不知道有沒(méi)有記錯(cuò)），安卓客戶端要如何播放？

答：使用內(nèi)嵌瀏覽器的方式即可，一般安卓都會(huì)使用librtmp之類的播放RTMP，不會(huì)播m3u8.

Q12:如果通過(guò)微信公眾號(hào)接入直播服務(wù)，是否需要特定的頁(yè)面與cdn推流及播放對(duì)接？這是否需要寫一個(gè)播放頁(yè)出來(lái)？

答：需要寫一個(gè)簡(jiǎn)單的播放也面，只要直播服務(wù)支持HLS格式就行，公眾號(hào)里面可以直接播放。

Q13: 客戶端接入那個(gè)服務(wù)端是怎么做的？需要測(cè)速么？

答：從DNS或其他方式獲取到具體的IP后，進(jìn)行基本的PING測(cè)速選定服務(wù)器IP。

Q14: 推上來(lái)的流只有一路，怎么做到雙路由回到bgp 或者三通？

答：雙路由僅指在播放的時(shí)候。

下期預(yù)告

參與方式詳見(jiàn)：

30天四場(chǎng)技術(shù)分享，我賭上程序員的尊嚴(yán)解析UCloud產(chǎn)品技術(shù)實(shí)踐

歡迎報(bào)名：云計(jì)算存儲(chǔ)技術(shù)峰會(huì).成都站

更多詳情請(qǐng)掃描活動(dòng)下方二維碼參與報(bào)名！

加速會(huì)：加速你對(duì)世界的理解，內(nèi)幕全在這里！請(qǐng)關(guān)注加速會(huì)微信公號(hào)：jiasuhuihao

加速會(huì)主編微信：leaderweb

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。