相比互聯(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的平臺建設(shè)，也是隨他進(jìn)入而起，從典型的互聯(lián)網(wǎng)公司到傳統(tǒng)行業(yè)的互聯(lián)網(wǎng)部門，這其中的差別，他可謂深有體會。

經(jīng)彭哲夫介紹，從全局來看，目前芒果TV的主要業(yè)務(wù)包含三個方面，均由芒果TV的技術(shù)平臺部門來支撐。

第一條線是湖南本地的 IPTV 內(nèi)容。

第二條是OTT 線，這一條線擁有千萬級別的真金白銀的付費(fèi)用戶。

第三條線是網(wǎng)站內(nèi)容，這也是芒果TV的技術(shù)平臺部門主要支撐的業(yè)務(wù)。因?yàn)楠?dú)播策略內(nèi)容為王，芒果TV現(xiàn)在要承擔(dān)湖南衛(wèi)視所有節(jié)目的互聯(lián)網(wǎng)渠道轉(zhuǎn)播工作。同時，芒果TV另辟蹊徑，在互聯(lián)網(wǎng)直播技術(shù)上也往前走了一大步，例如前幾天的 Billboard，全球同步直播;跨年晚會，五機(jī)位自由選擇視角互聯(lián)網(wǎng)直播等。

公司性質(zhì)、所處領(lǐng)域與業(yè)務(wù)線的不同也帶來了工作方式的不同，因此當(dāng)談到與前東家豆瓣的對比時，彭哲夫說到，“我認(rèn)為，互聯(lián)網(wǎng)企業(yè)講究短平快，國企下的互聯(lián)網(wǎng)產(chǎn)品機(jī)構(gòu)尤其是媒體領(lǐng)域會更加謹(jǐn)慎一些。這樣帶來的結(jié)果就是迭代速度會變慢，周期會拉長，但相應(yīng)的穩(wěn)定性會更高。另外，在技術(shù)選型上也比較保守。”

芒果TV平臺架構(gòu)的演變

雖然領(lǐng)域存在差異，但技術(shù)上的追求則是共通的，更由于有錢任性，芒果TV甚至可以比互聯(lián)網(wǎng)圈子大多數(shù)求“活下去”的公司更能在自己領(lǐng)域和技術(shù)的某些方面冒進(jìn)?！皩τ趦?nèi)部方案而言，目前我們也在做改進(jìn)，將好的新的技術(shù)逐步引入到公司工作流當(dāng)中。例如，從SVN切換到GIT，再比如大規(guī)模使用Redis- Cluster和Docker技術(shù)來簡化線上基礎(chǔ)設(shè)施等?！迸碚芊蛞恢痹诒M自己最大的努力，引入業(yè)界優(yōu)秀的解決方案來提升芒果TV的系統(tǒng)性能，降低運(yùn)維成本。由他的負(fù)責(zé)平臺部核心技術(shù)團(tuán)隊(duì)，目前主要是在做基于Docker的調(diào)度平臺以及整個公司的基礎(chǔ)設(shè)施。他們在沒有參考任何其他調(diào)度編排系統(tǒng)的情況下自行研發(fā)了調(diào)度編排系統(tǒng)，現(xiàn)在這個系統(tǒng)驅(qū)動了芒果TV的Redis集群，實(shí)現(xiàn)了毫秒級的擴(kuò)容和縮容，保證4個9的可用性和6個9的數(shù)據(jù)可靠性。

在訪談中，彭哲夫向我們詳細(xì)揭示了芒果TV的技術(shù)架構(gòu)演變。

自建系統(tǒng)平臺，支撐核心業(yè)務(wù)

在加入芒果TV之后，彭哲夫結(jié)合以往在豆瓣的經(jīng)驗(yàn)，實(shí)現(xiàn)了類似 DAE 架構(gòu)的一個新 PaaS —— Nebulium Engine(NBE)，其基于兩級Nginx結(jié)構(gòu)，服務(wù)發(fā)現(xiàn)基于Skydns，配置存儲在etcd。在運(yùn)行時完全用 Docker 來進(jìn)行隔離，并將控制層移到了 Container 之外。

但在這個過程中，出現(xiàn)了一個讓人很頭疼的問題——那就是在芒果 TV 內(nèi)部并沒有一個大一統(tǒng)的強(qiáng)勢語言，作為系統(tǒng)開發(fā)方，他們只能把 Runtime 的控制權(quán)完全交給業(yè)務(wù)方去決定。因此，綜合大半年線上運(yùn)行結(jié)果來看，在資源管理和工作流整合上，NBE 做得并不是很好。

原因有很多，一方面是基礎(chǔ)設(shè)施和之前豆瓣比實(shí)在太糟糕，如果說豆瓣是21世紀(jì)的互聯(lián)網(wǎng)公司的話，那么當(dāng)時的芒果TV還停留在19世紀(jì)的傳聲筒時代;另一方面，各種各樣的語言都需要支持，在放開 Runtime 之后，平臺部門對于資源競爭和預(yù)估是完全沒有任何能力去做的，恰恰業(yè)務(wù)方又希望平臺部能完全解決這些問題。舉個例子，Python GIL 限定在非多進(jìn)程模式下最多吃死一個核，但是隔壁組上了個 Java 的中間件。這時就只能看著 Python 業(yè)務(wù)方過來哭天喊地了。

這時期的系統(tǒng)架構(gòu)如下圖所示。

于是在2014 年底，開發(fā)者們重新回顧了一遍 Borg 和 Omega 相關(guān)的信息，開始了第二代NBE，也就是今天的主角——Project Eru——的開發(fā)。這一次他們拋棄了以前做一個PaaS的思路，而是決定去實(shí)現(xiàn)一個類似于Borg的服務(wù)編排和調(diào)度平臺。

第二代NBE——Project Eru

到目前為止，Eru平臺可以混編Offline和Online的服務(wù)(binary/script)，對于資源尤其是CPU資源實(shí)現(xiàn)了自由維度(0.1、0.01、0.001等)的彈性分配，使用 Redis 作為數(shù)據(jù)總線對外進(jìn)行消息發(fā)布，動態(tài)感知集群所有的 Containers 狀態(tài)并監(jiān)控其各項(xiàng)數(shù)據(jù)等。此外，把基于Docker的Image Layer特性和Git version結(jié)合起來，實(shí)現(xiàn)了自動化的 build/test 流程，統(tǒng)一了線上部署環(huán)境。同時解決了 Runtime 的污染問題，使得業(yè)務(wù)能快速地擴(kuò)容和縮容。系統(tǒng)架構(gòu)如下圖所示。

看上去變化不大，實(shí)際上內(nèi)部的設(shè)計和反饋回路等與第一代截然不同。業(yè)務(wù)層方面，在邏輯上使用了類似于Kubernetes的Pod來描述一組資源，使得Eru有了Container的組資源控制的能力。但是和 Kubernetes 不同的是，Pod 僅僅是邏輯上的隔離，主要用于業(yè)務(wù)的區(qū)分，而實(shí)際的隔離則基于網(wǎng)絡(luò)層。對于 Dockefile，這里不允許業(yè)務(wù)方自行寫Dockerfile，而是通過標(biāo)準(zhǔn)化的 App.yaml統(tǒng)一Dockerfile的生成，通用化的 Entrypoint 則滿足了業(yè)務(wù)一份代碼多個角色的復(fù)用和切換，使得任何業(yè)務(wù)幾乎都可以完全無痛地遷移上來。

另外，第一代NBE是個完整的閉環(huán)，一個業(yè)務(wù)由生到死都有NBE本身各個組件的身影。但在Eru中放棄了以前考慮的完整閉環(huán)設(shè)計。由于第一代NBE打通了項(xiàng)目整個生命周期的每一個環(huán)節(jié)，但實(shí)際上落地起來困難重重，并且使得Dot(Master)的狀態(tài)太重沒法 Scale Out，因?yàn)樗菃吸c(diǎn)部署，可靠性上會糟糕一些。所以Eru中每一個Core都是一個完整的無狀態(tài)的邏輯核心，使其在能夠Scale Out的同時可靠性也比 NBE 第一代要健壯得多。

因此，在這個體系下，業(yè)務(wù)推薦會根據(jù)自身業(yè)務(wù)特性，通過監(jiān)控自身數(shù)據(jù)、訂閱 Eru 廣播、調(diào)用Eru-Core的API ，實(shí)現(xiàn)復(fù)雜的自定義的部署擴(kuò)容等操作。在系統(tǒng)中，并會去強(qiáng)行干涉或者建立一系列規(guī)則去限定這些事情，這也是它不屬于PaaS的原因。

總的來說，Eru平臺項(xiàng)目的設(shè)計思路是以組合為主，依托于現(xiàn)有的 Redis 解決方案，通過“消息”將各個組件串起來，從而使得整個平臺的擴(kuò)展性和自由度達(dá)到業(yè)務(wù)的需求。除了一些特定的方法，比如構(gòu)建 Image，其他的諸如構(gòu)建 Dockerfile，如何啟動應(yīng)用等，均不做強(qiáng)一致性的范式去規(guī)范業(yè)務(wù)方/服務(wù)方怎么去做，當(dāng)然這和芒果TV本身體系架構(gòu)有關(guān)，但主要還是為了減少落地成本。

引入公有云服務(wù)，構(gòu)建360度方案

為了同時抓住核心業(yè)務(wù)外和邊緣性業(yè)務(wù)，又不能讓突發(fā)業(yè)務(wù)影響到核心業(yè)務(wù)的發(fā)展，芒果TV目前選擇的是私有云加公有云的混合云解決方案。彭哲夫所負(fù)責(zé)的平臺部門核心技術(shù)團(tuán)隊(duì)，已經(jīng)圍繞核心業(yè)務(wù)打造了屬于自己的私有云業(yè)務(wù)平臺，以確保業(yè)務(wù)的正常運(yùn)行。而隨著業(yè)務(wù)量的增加，以及突發(fā)事件的頻起，芒果TV本地私有平臺已經(jīng)不能滿足全部業(yè)務(wù)的需求，但自建數(shù)據(jù)中心來處理并發(fā)流量，又會造成資源浪費(fèi)、增加成本負(fù)載?；谶@些情況，芒果TV開始積極尋找公有云服務(wù)提供商，而七牛作為候選方案提供商，針對轉(zhuǎn)播和直播兩類業(yè)務(wù)分別提出了360度的解決方案，以備具體場景的需求。

首先采用優(yōu)化的EC技術(shù)，使單位存儲的冗余度從傳統(tǒng)3副本降到1.125，并率先達(dá)到了16個9的可靠性。由于廣電屬于受到監(jiān)管比較嚴(yán)格的傳統(tǒng)行業(yè)，客戶也會對云存儲存在的傳輸性能和隱秘性等方面感到擔(dān)憂。對此，一份數(shù)據(jù)在上傳時，七牛先將其打散，每一臺服務(wù)器都是子因素，分批量將這些文件存在對應(yīng)的服務(wù)器上，從而使任何一臺服務(wù)器的宕機(jī)都不會影響其他備份服務(wù)器的正常運(yùn)轉(zhuǎn)。

同時，將媒體文件進(jìn)行切片加密保存，最大程度保證了數(shù)據(jù)的私密性。在音視頻處理方面，七牛有快速轉(zhuǎn)碼、視頻水印、打點(diǎn)、快速轉(zhuǎn)格式等在線應(yīng)用，并且將計算資源作為一個池，可以進(jìn)行動態(tài)擴(kuò)張和縮小。在內(nèi)容分發(fā)方面，七牛推出了自研的多CDN管理平臺，能夠幫助用戶透明并自助式地監(jiān)控和管理各個CDN節(jié)點(diǎn)，在上傳、存儲、下載、分發(fā)等各個環(huán)節(jié)做好健康管理，實(shí)現(xiàn)一站式服務(wù)。

結(jié)語

強(qiáng)有力的技術(shù)支撐平臺是保障業(yè)務(wù)得以快步發(fā)展的堅實(shí)后盾，這一事實(shí)無疑在芒果TV得到了更深刻的印證。同時，芒果TV引入云服務(wù)打造360度技術(shù)方案，不僅節(jié)約了大量的時間和成本，更幫芒果TV在上線一年半的時間內(nèi)迅速實(shí)現(xiàn)業(yè)務(wù)擴(kuò)展，搶占了時間優(yōu)勢和發(fā)展先機(jī)。相信在互聯(lián)網(wǎng)+風(fēng)口下，謀求突破和轉(zhuǎn)型的廣電機(jī)構(gòu)/企業(yè)還有很多，云服務(wù)勢必會為這次優(yōu)雅轉(zhuǎn)身起到相當(dāng)大的助推作用。

原文鏈接：http://cloud.it168.com/a2015/0715/1746/000001746405.shtml

【編輯推薦】