相比互聯(lián)網(wǎng)公司，傳統(tǒng)媒體的開發(fā)模式更追求穩(wěn)定
彭哲夫之前在豆瓣工作多年，負(fù)責(zé)Douban App Engine的研發(fā)，深諳互聯(lián)網(wǎng)領(lǐng)域的技術(shù)發(fā)展規(guī)則。而芒果TV的平臺(tái)建設(shè)，也是隨他進(jìn)入而起，從典型的互聯(lián)網(wǎng)公司到傳統(tǒng)行業(yè)的互聯(lián)網(wǎng)部門，這其中的差別，他可謂深有體會(huì)。
經(jīng)彭哲夫介紹，從全局來(lái)看，目前芒果TV的主要業(yè)務(wù)包含三個(gè)方面，均由芒果TV的技術(shù)平臺(tái)部門來(lái)支撐。
第一條線是湖南本地的 IPTV 內(nèi)容。
第二條是OTT 線，這一條線擁有千萬(wàn)級(jí)別的真金白銀的付費(fèi)用戶。
第三條線是網(wǎng)站內(nèi)容，這也是芒果TV的技術(shù)平臺(tái)部門主要支撐的業(yè)務(wù)。因?yàn)楠?dú)播策略內(nèi)容為王，芒果TV現(xiàn)在要承擔(dān)湖南衛(wèi)視所有節(jié)目的互聯(lián)網(wǎng)渠道轉(zhuǎn)播工作。同時(shí)，芒果TV另辟蹊徑，在互聯(lián)網(wǎng)直播技術(shù)上也往前走了一大步，例如前幾天的 Billboard，全球同步直播；跨年晚會(huì)，五機(jī)位自由選擇視角互聯(lián)網(wǎng)直播等。
公司性質(zhì)、所處領(lǐng)域與業(yè)務(wù)線的不同也帶來(lái)了工作方式的不同，因此當(dāng)談到與前東家豆瓣的對(duì)比時(shí)，彭哲夫說(shuō)到，“我認(rèn)為，互聯(lián)網(wǎng)企業(yè)講究短平快，國(guó)企下的互聯(lián)網(wǎng)產(chǎn)品機(jī)構(gòu)尤其是媒體領(lǐng)域會(huì)更加謹(jǐn)慎一些。這樣帶來(lái)的結(jié)果就是迭代速度會(huì)變慢，周期會(huì)拉長(zhǎng)，但相應(yīng)的穩(wěn)定性會(huì)更高。另外，在技術(shù)選型上也比較保守。”
芒果TV平臺(tái)架構(gòu)的演變
雖然領(lǐng)域存在差異，但技術(shù)上的追求則是共通的，更由于有錢任性，芒果TV甚至可以比互聯(lián)網(wǎng)圈子大多數(shù)求“活下去”的公司更能在自己領(lǐng)域和技術(shù)的某些方面冒進(jìn)。“對(duì)于內(nèi)部方案而言，目前我們也在做改進(jìn)，將好的新的技術(shù)逐步引入到公司工作流當(dāng)中。例如，從SVN切換到GIT，再比如大規(guī)模使用Redis-Cluster和Docker技術(shù)來(lái)簡(jiǎn)化線上基礎(chǔ)設(shè)施等。”彭哲夫一直在盡自己最大的努力，引入業(yè)界優(yōu)秀的解決方案來(lái)提升芒果TV的系統(tǒng)性能，降低運(yùn)維成本。由他的負(fù)責(zé)平臺(tái)部核心技術(shù)團(tuán)隊(duì)，目前主要是在做基于Docker的調(diào)度平臺(tái)以及整個(gè)公司的基礎(chǔ)設(shè)施。他們?cè)跊](méi)有參考任何其他調(diào)度編排系統(tǒng)的情況下自行研發(fā)了調(diào)度編排系統(tǒng)，現(xiàn)在這個(gè)系統(tǒng)驅(qū)動(dòng)了芒果TV的Redis集群，實(shí)現(xiàn)了毫秒級(jí)的擴(kuò)容和縮容，保證4個(gè)9的可用性和6個(gè)9的數(shù)據(jù)可靠性。
在訪談中，彭哲夫向我們?cè)敿?xì)揭示了芒果TV的技術(shù)架構(gòu)演變。
自建系統(tǒng)平臺(tái)，支撐核心業(yè)務(wù)
在加入芒果TV之后，彭哲夫結(jié)合以往在豆瓣的經(jīng)驗(yàn)，實(shí)現(xiàn)了類似 DAE 架構(gòu)的一個(gè)新 PaaS —— Nebulium Engine（NBE），其基于兩級(jí)Nginx結(jié)構(gòu)，服務(wù)發(fā)現(xiàn)基于Skydns，配置存儲(chǔ)在etcd。在運(yùn)行時(shí)完全用 Docker 來(lái)進(jìn)行隔離，并將控制層移到了 Container 之外。
但在這個(gè)過(guò)程中，出現(xiàn)了一個(gè)讓人很頭疼的問(wèn)題——那就是在芒果 TV 內(nèi)部并沒(méi)有一個(gè)大一統(tǒng)的強(qiáng)勢(shì)語(yǔ)言，作為系統(tǒng)開發(fā)方，他們只能把 Runtime 的控制權(quán)完全交給業(yè)務(wù)方去決定。因此，綜合大半年線上運(yùn)行結(jié)果來(lái)看，在資源管理和工作流整合上，NBE 做得并不是很好。
原因有很多，一方面是基礎(chǔ)設(shè)施和之前豆瓣比實(shí)在太糟糕，如果說(shuō)豆瓣是21世紀(jì)的互聯(lián)網(wǎng)公司的話，那么當(dāng)時(shí)的芒果TV還停留在19世紀(jì)的傳聲筒時(shí)代；另一方面，各種各樣的語(yǔ)言都需要支持，在放開 Runtime 之后，平臺(tái)部門對(duì)于資源競(jìng)爭(zhēng)和預(yù)估是完全沒(méi)有任何能力去做的，恰恰業(yè)務(wù)方又希望平臺(tái)部能完全解決這些問(wèn)題。舉個(gè)例子，Python GIL 限定在非多進(jìn)程模式下最多吃死一個(gè)核，但是隔壁組上了個(gè) Java 的中間件。這時(shí)就只能看著 Python 業(yè)務(wù)方過(guò)來(lái)哭天喊地了。
這時(shí)期的系統(tǒng)架構(gòu)如下圖所示。
于是在2014 年底，開發(fā)者們重新回顧了一遍 Borg 和 Omega 相關(guān)的信息，開始了第二代NBE，也就是今天的主角——Project Eru——的開發(fā)。這一次他們拋棄了以前做一個(gè)PaaS的思路，而是決定去實(shí)現(xiàn)一個(gè)類似于Borg的服務(wù)編排和調(diào)度平臺(tái)。
第二代NBE——Project Eru
到目前為止，Eru平臺(tái)可以混編Offline和Online的服務(wù)（binary/script），對(duì)于資源尤其是CPU資源實(shí)現(xiàn)了自由維度（0.1、0.01、0.001等）的彈性分配，使用 Redis 作為數(shù)據(jù)總線對(duì)外進(jìn)行消息發(fā)布，動(dòng)態(tài)感知集群所有的 Containers 狀態(tài)并監(jiān)控其各項(xiàng)數(shù)據(jù)等。此外，把基于Docker的Image Layer特性和Git version結(jié)合起來(lái)，實(shí)現(xiàn)了自動(dòng)化的 build/test 流程，統(tǒng)一了線上部署環(huán)境。同時(shí)解決了 Runtime 的污染問(wèn)題，使得業(yè)務(wù)能快速地?cái)U(kuò)容和縮容。系統(tǒng)架構(gòu)如下圖所示。
看上去變化不大，實(shí)際上內(nèi)部的設(shè)計(jì)和反饋回路等與第一代截然不同。業(yè)務(wù)層方面，在邏輯上使用了類似于Kubernetes的Pod來(lái)描述一組資源，使得Eru有了Container的組資源控制的能力。但是和 Kubernetes 不同的是，Pod 僅僅是邏輯上的隔離，主要用于業(yè)務(wù)的區(qū)分，而實(shí)際的隔離則基于網(wǎng)絡(luò)層。對(duì)于 Dockefile，這里不允許業(yè)務(wù)方自行寫Dockerfile，而是通過(guò)標(biāo)準(zhǔn)化的 App.yaml統(tǒng)一Dockerfile的生成，通用化的 Entrypoint 則滿足了業(yè)務(wù)一份代碼多個(gè)角色的復(fù)用和切換，使得任何業(yè)務(wù)幾乎都可以完全無(wú)痛地遷移上來(lái)。
另外，第一代NBE是個(gè)完整的閉環(huán)，一個(gè)業(yè)務(wù)由生到死都有NBE本身各個(gè)組件的身影。但在Eru中放棄了以前考慮的完整閉環(huán)設(shè)計(jì)。由于第一代NBE打通了項(xiàng)目整個(gè)生命周期的每一個(gè)環(huán)節(jié)，但實(shí)際上落地起來(lái)困難重重，并且使得Dot（Master）的狀態(tài)太重沒(méi)法 Scale Out，因?yàn)樗菃吸c(diǎn)部署，可靠性上會(huì)糟糕一些。所以Eru中每一個(gè)Core都是一個(gè)完整的無(wú)狀態(tài)的邏輯核心，使其在能夠Scale Out的同時(shí)可靠性也比 NBE 第一代要健壯得多。
因此，在這個(gè)體系下，業(yè)務(wù)推薦會(huì)根據(jù)自身業(yè)務(wù)特性，通過(guò)監(jiān)控自身數(shù)據(jù)、訂閱 Eru 廣播、調(diào)用Eru-Core的API ，實(shí)現(xiàn)復(fù)雜的自定義的部署擴(kuò)容等操作。在系統(tǒng)中，并會(huì)去強(qiáng)行干涉或者建立一系列規(guī)則去限定這些事情，這也是它不屬于PaaS的原因。
總的來(lái)說(shuō)，Eru平臺(tái)項(xiàng)目的設(shè)計(jì)思路是以組合為主，依托于現(xiàn)有的 Redis 解決方案，通過(guò)“消息”將各個(gè)組件串起來(lái)，從而使得整個(gè)平臺(tái)的擴(kuò)展性和自由度達(dá)到業(yè)務(wù)的需求。除了一些特定的方法，比如構(gòu)建 Image，其他的諸如構(gòu)建 Dockerfile，如何啟動(dòng)應(yīng)用等，均不做強(qiáng)一致性的范式去規(guī)范業(yè)務(wù)方/服務(wù)方怎么去做，當(dāng)然這和芒果TV本身體系架構(gòu)有關(guān)，但主要還是為了減少落地成本。
引入公有云服務(wù)，構(gòu)建360度方案
為了同時(shí)抓住核心業(yè)務(wù)外和邊緣性業(yè)務(wù)，又不能讓突發(fā)業(yè)務(wù)影響到核心業(yè)務(wù)的發(fā)展，芒果TV目前選擇的是私有云加公有云的混合云解決方案。彭哲夫所負(fù)責(zé)的平臺(tái)部門核心技術(shù)團(tuán)隊(duì)，已經(jīng)圍繞核心業(yè)務(wù)打造了屬于自己的私有云業(yè)務(wù)平臺(tái)，以確保業(yè)務(wù)的正常運(yùn)行。而隨著業(yè)務(wù)量的增加，以及突發(fā)事件的頻起，芒果TV本地私有平臺(tái)已經(jīng)不能滿足全部業(yè)務(wù)的需求，但自建數(shù)據(jù)中心來(lái)處理并發(fā)流量，又會(huì)造成資源浪費(fèi)、增加成本負(fù)載。基于這些情況，芒果TV開始積極尋找公有云服務(wù)提供商，而七牛作為候選方案提供商，針對(duì)轉(zhuǎn)播和直播兩類業(yè)務(wù)分別提出了360度的解決方案，以備具體場(chǎng)景的需求。
首先，七牛采用優(yōu)化的EC技術(shù)，使單位存儲(chǔ)的冗余度從傳統(tǒng)3副本降到1.125，并率先達(dá)到了16個(gè)9的可靠性。由于廣電屬于受到監(jiān)管比較嚴(yán)格的傳統(tǒng)行業(yè)，客戶也會(huì)對(duì)云存儲(chǔ)存在的傳輸性能和隱秘性等方面感到擔(dān)憂。對(duì)此，一份數(shù)據(jù)在上傳時(shí)，七牛先將其打散，每一臺(tái)服務(wù)器都是子因素，分批量將這些文件存在對(duì)應(yīng)的服務(wù)器上，從而使任何一臺(tái)服務(wù)器的宕機(jī)都不會(huì)影響其他備份服務(wù)器的正常運(yùn)轉(zhuǎn)。
同時(shí)，將媒體文件進(jìn)行切片加密保存，最大程度保證了數(shù)據(jù)的私密性。在音視頻處理方面，七牛有快速轉(zhuǎn)碼、視頻水印、打點(diǎn)、快速轉(zhuǎn)格式等在線應(yīng)用，并且將計(jì)算資源作為一個(gè)池，可以進(jìn)行動(dòng)態(tài)擴(kuò)張和縮小。在內(nèi)容分發(fā)方面，七牛推出了自研的多CDN管理平臺(tái)，能夠幫助用戶透明并自助式地監(jiān)控和管理各個(gè)CDN節(jié)點(diǎn)，在上傳、存儲(chǔ)、下載、分發(fā)等各個(gè)環(huán)節(jié)做好健康管理，實(shí)現(xiàn)一站式服務(wù)。
結(jié)語(yǔ)
強(qiáng)有力的技術(shù)支撐平臺(tái)是保障業(yè)務(wù)得以快步發(fā)展的堅(jiān)實(shí)后盾，這一事實(shí)無(wú)疑在芒果TV得到了更深刻的印證。同時(shí)，芒果TV引入云服務(wù)打造360度技術(shù)方案，不僅節(jié)約了大量的時(shí)間和成本，更幫芒果TV在上線一年半的時(shí)間內(nèi)迅速實(shí)現(xiàn)業(yè)務(wù)擴(kuò)展，搶占了時(shí)間優(yōu)勢(shì)和發(fā)展先機(jī)。相信在互聯(lián)網(wǎng)+風(fēng)口下，謀求突破和轉(zhuǎn)型的廣電機(jī)構(gòu)/企業(yè)還有很多，云服務(wù)勢(shì)必會(huì)為這次優(yōu)雅轉(zhuǎn)身起到相當(dāng)大的助推作用。
京公網(wǎng)安備 11010502049343號(hào)