相比互联网公司，传统媒体的开发模式更追求稳定
彭哲夫之前在豆瓣工作多年，负责Douban App Engine的研发，深谙互联网领域的技术发展规则。而芒果TV的平台建设，也是随他进入而起，从典型的互联网公司到传统行业的互联网部门，这其中的差别，他可谓深有体会。
经彭哲夫介绍，从全局来看，目前芒果TV的主要业务包含三个方面，均由芒果TV的技术平台部门来支撑。
第一条线是湖南本地的 IPTV 内容。
第二条是OTT 线，这一条线拥有千万级别的真金白银的付费用户。
第三条线是网站内容，这也是芒果TV的技术平台部门主要支撑的业务。因为独播策略内容为王，芒果TV现在要承担湖南卫视所有节目的互联网渠道转播工作。同时，芒果TV另辟蹊径，在互联网直播技术上也往前走了一大步，例如前几天的 Billboard，全球同步直播；跨年晚会，五机位自由选择视角互联网直播等。
公司性质、所处领域与业务线的不同也带来了工作方式的不同，因此当谈到与前东家豆瓣的对比时，彭哲夫说到，“我认为，互联网企业讲究短平快，国企下的互联网产品机构尤其是媒体领域会更加谨慎一些。这样带来的结果就是迭代速度会变慢，周期会拉长，但相应的稳定性会更高。另外，在技术选型上也比较保守。”
芒果TV平台架构的演变
虽然领域存在差异，但技术上的追求则是共通的，更由于有钱任性，芒果TV甚至可以比互联网圈子大多数求“活下去”的公司更能在自己领域和技术的某些方面冒进。“对于内部方案而言，目前我们也在做改进，将好的新的技术逐步引入到公司工作流当中。例如，从SVN切换到GIT，再比如大规模使用Redis-Cluster和Docker技术来简化线上基础设施等。”彭哲夫一直在尽自己最大的努力，引入业界优秀的解决方案来提升芒果TV的系统性能，降低运维成本。由他的负责平台部核心技术团队，目前主要是在做基于Docker的调度平台以及整个公司的基础设施。他们在没有参考任何其他调度编排系统的情况下自行研发了调度编排系统，现在这个系统驱动了芒果TV的Redis集群，实现了毫秒级的扩容和缩容，保证4个9的可用性和6个9的数据可靠性。
在访谈中，彭哲夫向我们详细揭示了芒果TV的技术架构演变。
自建系统平台，支撑核心业务
在加入芒果TV之后，彭哲夫结合以往在豆瓣的经验，实现了类似 DAE 架构的一个新 PaaS —— Nebulium Engine（NBE），其基于两级Nginx结构，服务发现基于Skydns，配置存储在etcd。在运行时完全用 Docker 来进行隔离，并将控制层移到了 Container 之外。
但在这个过程中，出现了一个让人很头疼的问题——那就是在芒果 TV 内部并没有一个大一统的强势语言，作为系统开发方，他们只能把 Runtime 的控制权完全交给业务方去决定。因此，综合大半年线上运行结果来看，在资源管理和工作流整合上，NBE 做得并不是很好。
原因有很多，一方面是基础设施和之前豆瓣比实在太糟糕，如果说豆瓣是21世纪的互联网公司的话，那么当时的芒果TV还停留在19世纪的传声筒时代；另一方面，各种各样的语言都需要支持，在放开 Runtime 之后，平台部门对于资源竞争和预估是完全没有任何能力去做的，恰恰业务方又希望平台部能完全解决这些问题。举个例子，Python GIL 限定在非多进程模式下最多吃死一个核，但是隔壁组上了个 Java 的中间件。这时就只能看着 Python 业务方过来哭天喊地了。
这时期的系统架构如下图所示。
于是在2014 年底，开发者们重新回顾了一遍 Borg 和 Omega 相关的信息，开始了第二代NBE，也就是今天的主角——Project Eru——的开发。这一次他们抛弃了以前做一个PaaS的思路，而是决定去实现一个类似于Borg的服务编排和调度平台。
第二代NBE——Project Eru
到目前为止，Eru平台可以混编Offline和Online的服务（binary/script），对于资源尤其是CPU资源实现了自由维度（0.1、0.01、0.001等）的弹性分配，使用 Redis 作为数据总线对外进行消息发布，动态感知集群所有的 Containers 状态并监控其各项数据等。此外，把基于Docker的Image Layer特性和Git version结合起来，实现了自动化的 build/test 流程，统一了线上部署环境。同时解决了 Runtime 的污染问题，使得业务能快速地扩容和缩容。系统架构如下图所示。
看上去变化不大，实际上内部的设计和反馈回路等与第一代截然不同。业务层方面，在逻辑上使用了类似于Kubernetes的Pod来描述一组资源，使得Eru有了Container的组资源控制的能力。但是和 Kubernetes 不同的是，Pod 仅仅是逻辑上的隔离，主要用于业务的区分，而实际的隔离则基于网络层。对于 Dockefile，这里不允许业务方自行写Dockerfile，而是通过标准化的 App.yaml统一Dockerfile的生成，通用化的 Entrypoint 则满足了业务一份代码多个角色的复用和切换，使得任何业务几乎都可以完全无痛地迁移上来。
另外，第一代NBE是个完整的闭环，一个业务由生到死都有NBE本身各个组件的身影。但在Eru中放弃了以前考虑的完整闭环设计。由于第一代NBE打通了项目整个生命周期的每一个环节，但实际上落地起来困难重重，并且使得Dot（Master）的状态太重没法 Scale Out，因为它是单点部署，可靠性上会糟糕一些。所以Eru中每一个Core都是一个完整的无状态的逻辑核心，使其在能够Scale Out的同时可靠性也比 NBE 第一代要健壮得多。
因此，在这个体系下，业务推荐会根据自身业务特性，通过监控自身数据、订阅 Eru 广播、调用Eru-Core的API ，实现复杂的自定义的部署扩容等操作。在系统中，并会去强行干涉或者建立一系列规则去限定这些事情，这也是它不属于PaaS的原因。
总的来说，Eru平台项目的设计思路是以组合为主，依托于现有的 Redis 解决方案，通过“消息”将各个组件串起来，从而使得整个平台的扩展性和自由度达到业务的需求。除了一些特定的方法，比如构建 Image，其他的诸如构建 Dockerfile，如何启动应用等，均不做强一致性的范式去规范业务方/服务方怎么去做，当然这和芒果TV本身体系架构有关，但主要还是为了减少落地成本。
引入公有云服务，构建360度方案
为了同时抓住核心业务外和边缘性业务，又不能让突发业务影响到核心业务的发展，芒果TV目前选择的是私有云加公有云的混合云解决方案。彭哲夫所负责的平台部门核心技术团队，已经围绕核心业务打造了属于自己的私有云业务平台，以确保业务的正常运行。而随着业务量的增加，以及突发事件的频起，芒果TV本地私有平台已经不能满足全部业务的需求，但自建数据中心来处理并发流量，又会造成资源浪费、增加成本负载。基于这些情况，芒果TV开始积极寻找公有云服务提供商，而七牛作为候选方案提供商，针对转播和直播两类业务分别提出了360度的解决方案，以备具体场景的需求。
首先，七牛采用优化的EC技术，使单位存储的冗余度从传统3副本降到1.125，并率先达到了16个9的可靠性。由于广电属于受到监管比较严格的传统行业，客户也会对云存储存在的传输性能和隐秘性等方面感到担忧。对此，一份数据在上传时，七牛先将其打散，每一台服务器都是子因素，分批量将这些文件存在对应的服务器上，从而使任何一台服务器的宕机都不会影响其他备份服务器的正常运转。
同时，将媒体文件进行切片加密保存，最大程度保证了数据的私密性。在音视频处理方面，七牛有快速转码、视频水印、打点、快速转格式等在线应用，并且将计算资源作为一个池，可以进行动态扩张和缩小。在内容分发方面，七牛推出了自研的多CDN管理平台，能够帮助用户透明并自助式地监控和管理各个CDN节点，在上传、存储、下载、分发等各个环节做好健康管理，实现一站式服务。
结语
强有力的技术支撑平台是保障业务得以快步发展的坚实后盾，这一事实无疑在芒果TV得到了更深刻的印证。同时，芒果TV引入云服务打造360度技术方案，不仅节约了大量的时间和成本，更帮芒果TV在上线一年半的时间内迅速实现业务扩展，抢占了时间优势和发展先机。相信在互联网+风口下，谋求突破和转型的广电机构/企业还有很多，云服务势必会为这次优雅转身起到相当大的助推作用。
