微吼：业务入云是一条不归路

编者按：从 2010 开始，Netflix 一点点把自己的业务迁移到了云端——作为最早 All in 的案例，亚马逊将其树为典范四处推广。在接下来的几年里，凯宾斯基酒店集团、Infor 软件、日本运通、诺特丹大学、卫报传媒等等先后 All in 到 AWS。经过数年的发展，人们不再怀疑云就是未来。美国《连线》杂志的 Kevin Kelly 预言，2020 年时将有 60% 的应用运营在云上。2015 年 10 月，AWS 在赌城召开一年一度的 re:Invent 大会，发布了一系列旨在帮助客户迁移应用和数据的工具，业务入云已成趋势。在发掘这个话题时我发现，国内尚没有鲜明的案例，为此我打算走访一些企业，看看大家对这个问题的看法。以下是我拜访微吼直播时的收获。

InfoQ：微吼是在什么情况下开始考虑往云端迁移的？迁移之前做了哪些调研？

微吼：我们做视频直播有 4、5 年的时间了。那时云计算的态势并不明显，不像现在有这么多云服务可以选择，我们只能自己建设基础设施。大概从 2014 年开始，我们启动了部分业务的迁移，因为这个时候整个云的生态已经起来了。早年的云服务可能只是巨头如华为、阿里在运营，现在除了 BAT 包括青云包括其他一些优秀的云平台的厂商都出来了。

云计算最开始是存储和主机托管方面的业务，这些服务满足了互联网上 80% 的需求；但视频直播比较特殊，对数据传输的稳定性、可靠性、延迟度、编解码等等很多方面的要求比较高，尤其是微吼做的是 to B 的服务，企业级市场对服务质量的要求更为苛刻。最早的云服务都无法满足这些要求。现在云服务生态起来了，我们做了大量的各种性能测试，发现有些云服务质量还可以，有的还不行。但云服务整体的趋势是向好的，所以我们正在慢慢地、越来越多地把业务往云端迁移。

InfoQ：整个迁移过程主要分为几个阶段？应用的迁移和数据的迁移分别是怎么进行的？迁移花了多长时间？

微吼：现在的微吼是一个非常复杂和庞大的系统。首先是富媒体流多种格式的传播，包括 Web 端很多的用户交互、后端负载均衡以及数据交互等等。我们往云端的迁移最初是分步进行的，首先是在云平台上搭建了一个网站的迷你版，用这个微缩的系统原型来做测试。这时的测试用例一般只是我们的工程师利用第三方以及自己的测试工具在全国和全球范围内对其进行压力测试等使用。对于测试效果较好的，我们会迁移一部分边缘的业务过来，对于测试效果不好的，我们就测试其他的云平台。

原来我们的架构是有核心节点的设计，主机房我们现在用的是全国最好的 IDC。原来我们在华南、华北、华东等主要区域部署了很多边缘节点服务器，现在我们已经把一些流媒体边缘节点放在了第三方云平台。此外，我们把一些非核心业务——比如不是跟直播相关的业务系统——迁移到了云端。我们有大量的存储（都是以 TB 为计量单位）也放在了云端，因为云服务商是目前把存储解决的最好的。其实我们不喜欢单一节点这种系统架构，因为这种架构的容错能力不够强。以前没有云的支持，我们必须自建灾备节点，即便不做基础设施建设，在应用层面我们也要做大量的复杂工作。现在大部分的云厂商都提供了很好的解决方案。

存储业务放到云端之后，我们会慢慢地把核心业务，包括视频直播——事实上我们现在的视频直播流的传输已经用了一部分云服务，包括 CDN 以及 IDC 都在混合使用。而且云服务在这里面的占比越来越大——现在很多云厂商也都在提供 CDN 的服务（研发部门正在对比传统 CDN 与云厂商 CDN 的区别）。尽管我们用的都是最好的传统 CDN，但是离我们期望的效果还是有些差距（在流量高峰时段，CDN 资源的分配机制会优先保证重点客户，也许这是 CDN 现有的商业模式），我们的解决方案是接入多家 CDN，对其进行动态调配。

从 2014 年开始，往云端的业务迁移不曾中断过，预计还要迁移几年；微吼往云端迁移的意愿很强，至于说迁移的速度，要看云服务的质量是否满足我们的需求。我们不会特别激进地一下把所有的系统都迁移到云端，这对我们来说风险太大，完全迁移到云端可能还需要一段时间的观察。云服务和我们传统的系统架构可能要并存一段时间，我们会充分利用两者的优势，二者在微吼系统以及业务上的占比会是一个长期动态变化的过程。

最开始并没有视频直播的云解决方案，我们现在也开始在更上一层——接近应用层——给客户提供一些解决方案；在底层上我们已经在用一些视频云的服务。

InfoQ：在迁移的过程中遇到过什么问题？这些问题是怎么解决的？

微吼：迁移过程中遇到的问题很多。具体来说就是，响应时间、业务不可用，或者说负载大的时候出口带宽不足，还有网络抖动，甚至是硬盘 I/O。这与其他互联网业务几乎一致，所不同的是视频直播业务的影响会比较大。因为我们做的是视频直播对性能的要求特别高。比如说，网站和很多应用打开慢很多情况下用户是可以容忍的，但视频直播是不能容忍的；比如我们上下游也有很多供应商，我们对其资源的调配和把控能力远不如自己的那么灵便，如果在直播过程中出现问题，其影响会比较严重。

至少我们目前是不敢把所有的业务放到一个篮子里，而且国内云厂商各有各的优势，很多时候我们需要对业务进行分拆，在经过各种比较和权衡之后，分别迁移到不同的云服务上去。

InfoQ：迁移前后，微吼的系统架构有哪些变化？

微吼：主要表现为从单一节点、传统 IDC 的这种架构，向无节点、分布式系统转型。以前大三层的系统架构变成了分布式的系统架构，包括分布式的文件存储，以前的负载均衡需要我们自己做，现在云服务提供了。另外，我们整个的运维团队也作了一些相应的调整。比如 IDC 时要接触硬件、要去机房现场，现在云端了就不需要做这些工作。除了系统架构的改变，我们运维团队的业务重点也从一些很繁重但基础的工作转移到了我们业务本身。

InfoQ：早期的视频直播服务对跨平台的支持不是很好，一般以 Windows 为主。微吼目前的跨平台、多终端支持情况如何？

微吼：我们是第一家支持全平台的视频直播服务商。在客户端时代我们对这个问题感触很深，最开始我们也开发过客户端，但很快转到了 Web 端。虽然客户端在性能上略有优势，毕竟 Web 端对硬件的访问和调用隔着一个浏览器，但 Web 端跨平台的方便性和易用性的优势是压倒性的。

现在 Web 技术的发展和性能的提升使得客户端与 Web 端的差距正在逐渐缩小。除了 PC 端之外，我们也是最早推出移动端的服务商，全平台是我们追求的目标。用户使用视频直播服务应该是无缝的，无论你使用 PC 还是手机，这一切都是打通的。

InfoQ：随着部分业务迁移的完成，开发和运维工程师对迁移到云平台的反馈如何？

微吼：我们入云的尝试是一定要做的，同时迁移的效果可谓喜忧参半。因为 IDC 的优势很明确，出问题时候的响应会快一些；硬件都是看得见摸得着的，问题的可见性较强，哪怕是这个硬件坏了我热插拔都可以。在云端甚至都没有硬盘的概念了，文件都不知道存放在哪里。但是，往云端迁移是一条不归路，团队也都认可这个理念。

InfoQ：以前微吼用传统的 IDC 机房，为了应付突然增长的并发需求和保障用户体验，可能需要长期冗余设备和带宽，运营成本和灵活性都会受限。迁移到云端之后这方面是否有改善？现在又面临哪些新的问题和挑战？

微吼：即使我们用 IDC 的时候，我们的带宽资源也是灵活的。我们跟 IDC 的签的协议是在一定量的前提下，我们根据业务量的大小可以随时调整带宽。在这一点上我们不同于一代视频网站，他们平时就需要维护大量的冗余设备和带宽资源；我们平时维护的资源是不高的，当访问量高的时候我们还有 CDN 的支持，IDC 并没有承担这个压力。此外，我们跟 CDN 和 IDC 的结算方式是先使用后结算，即，按需使用、按量计费；平时我们追求的也不是成本最优，我们买的都是最好的服务，企业客户要求的就是服务质量最好。

我们也采用一些虚拟主机，不可否认的一点是资源利用率增加了，但性能有一定差别——但是差别在不断缩小。现在唯一的问题是我们对性能的可控力不够强，目前这个问题也正在逐步改善。

InfoQ：迁移到云端之后，微吼的运营成本与之前相比有哪些变化？相应的业务量的变化又是怎样的？

微吼：成本肯定是大幅下降，而且这个趋势也会持续下去。首先，现在的硬件包括带宽资源的价格比之前下降了很多。成本最优不是我们所追求的，所以这不是我们关注的重点。其次，我们的业务也在迅速的扩张的。原来的架构其实是一个很轻的架构，我们的瓶颈只可能是在上行带宽，所以问题也就是部署硬件、开通节点的时间。入云之后我的响应时间会大大缩短，更多底层的工作我们不需要做了，只要去选择更好的云服务即可。

InfoQ：您能简单总结一下微吼迁移到云端的影响吗？

微吼：比如我要在上海部署节点，我要花很多时间去测试、选择合适的机房啊、购买带宽啊。而迁移到云端之后我们不需要去做这些工作了，只需测试一下，然后选择最好的服务。现在，当我们业务拓展的时候，我们只需要考虑性能方面的压力即可。