转载

领先足球流媒体服务商fuboTV利用MogoDB、Docker容器与Kubernetes实现业务规模扩展

经历了媒体的一轮又一轮宣传轰炸，如今几乎每位行业关注者都会将容器与非关系数据库作为2016年IT行业的“热门市场技术”，而新一代市场领导者也在积极利用这些成果实现创新并借此击溃各传统竞争对手。总部位于纽约的fuboTV就是其中的典型代表。为了能够及时与业务发展保持同步并尽可能加快软件发布计划，fuboTV已经将其MongoDB数据库迁移至由Kubernetes编排系统于谷歌Cloud Platform之上负责管理的Docker容器环境当中。

抱着对其项目的高度关注，我与fuboTV工程技术主管Dan Worth以及云运营首席顾问Brian McNamara进行了面对面交流，旨在深入探讨与之相关的各项议题。

您能否首先向我们简要介绍您的这家企业？

fuboTV旨在为客户随时随地提供最出色的足球直播服务。我们提供为北美市场的各位订阅客户提供一项流媒体服务，其中包括赛事直播、娱乐频道、纪录片、新闻以及更多与世界各地足球联赛的资讯。

MognoDB在fuboTV当中扮演着怎样的角色？

MongoDB是负责支撑我们业务的核心数据库。我们利用它管理自己的客户数据; 它存储着节目指南以及内容目录元数据; 另外还承载着用于处理验证、订阅服务管理、赛事与频道调度乃至用户设备数据在内的一切相关服务API调用。

领先足球流媒体服务商fuboTV利用MogoDB、Docker容器与Kubernetes实现业务规模扩展

图一：顶级足球赛事直播

您是否在业务起步阶段就一直在使用MongoDB？

我们的CTO可以说是MongoDB的忠实拥趸，因此我们自公司建立之初就一直在使用这套数据库方案。

MongoDB对开发与运营流程的简化作用使得我们能够将精力集中在构建功能身上，从而快速扩展客户群体，而非被底层数据库所拖累。

我们最初在Compose.io平台上使用MongoDB，但如今则开始着手将自身管理集群迁移至谷歌Container Engine（作为谷歌Cloud Platform之组成部分）之上，而这套云引擎则以Kubernetes编排系统与Docker容器为基础。

面向谷歌Container Engine迁移主要源自以下几项因素的推动：

我们已经将自身剩余堆栈迁移至Docker与Kubernetes，同时也希望我们的MongoDB数据库能够充分发挥由此带来的各项优势。
我们跨越多个地理区域进行服务规模扩展，同时亦希望能够立足于谷歌云实现部署灵活性，并保持未来面向其它公有云平台的可移植能力。
我们希望能够对MongoDB的日常运营与管理工作保持控制能力，从而更好地支持我们快速演进的业务需求。

为什么选择Docker与Kubernetes？

二者能够为我们的服务带来无与伦比的灵活性、执行效率与正常运行时间水平。纵观以往的业务流程，我们发现其中存在大量资源浪费状况。而利用由Kubernetes管理的容器系统，我们能够将环境中的全部机制——包括开发、测试、质量保证以及生产流程——交付给单一物理主机集群。我们利用Kubernetes调度程序的优势以精确控制资源配额，从而保证自身最大程度提升利用率并降低运营成本。

MongoDB能够与Docker容器及Kubernetes实现无缝化集成，进而支持我们的DevOps工作流程。

我们运行有一套持续集成与交付流程，从而保证自身能够开发、测试、发布并在必要时以最快速度轻松回滚至原有版本。

我们确保业务体系在应用程序部署与升级过程中不会出现任何停机时间。我们能够在实例发生故障时自动进行容器重新调度，而Kubernetes复制控制器的存在确保系统中始终存在必要数量的实例处于正常运行状态——这就让持续可用性拥有了强大的容错性。数据冗余机制则由这套副本集中的MongoDB副本负责实现。

MongoDB是如何被部署在谷歌Container Engine之上的？

我们在每个谷歌云区域内跨越多个Kubernetes pod进行MongoDB副本集配置。其中每个实例都配置有32个CPU、28 GB内存以及SSD存储资源。

这些副本集由四种具备完整弹性的部分共同构成：其中三者专门用于处理运营流量，另一部分则被配置为隐藏副本集成员，专门用于对备份分卷进行快照保存。

领先足球流媒体服务商fuboTV利用MogoDB、Docker容器与Kubernetes实现业务规模扩展

图二：fuboTV的Kubernetes平台跨越多个谷歌Container Engine区域分布。

您是如何将MongoDB与Kubernetes加以结合的？

相较于其它常见应用场景，在Kubernetes之上运行MOngoDB需要额外考虑以下几项因素：

MongoDB数据库节点具备状态性特征。一旦某一容器发生故障并进行重新调度，其中的数据将出现无法接受的丢失状况（我们可以利用副本集中的其它节点实现数据恢复，但这会拖慢整体弹性副本集的恢复速度）。为了解决这项难题，我们利用Kubernetes分卷并以抽象化方式将容器中ephemera1 MongoDB数据目录映射至持久性网络连接存储资源，并借此保证故障容器内数据的完整性及重新调度。
副本集内的MongoDB数据库节点必须有能力随时实现彼此间通信。单一副本集内的全部节点都必须相互了解对方地址，但当某一容器进行重新调度，其很可能在Kubernetes Pod中重新启动并被分配一个不同于原本的IP地址。在这种情况下，该MongoDB节点将无法重新加入对应副本集。我们采取的解决办法是将一项Kubernetes服务同每个MongoDB节点相关联——在这里，Kubernetes DNS服务负责在重新调度过程中为该服务提供一个固定不变的主机名称。
一旦各个MongoDB节点全部处于运行状态（每个节点立足于自己的容器当中），该副本集必须进行初始化并将各个节点添加进来。我们已经利用CircleCI实现了一套持续交付工作流，其与Kubernetes及Docker相结合以检索必要配置，而后执行MongoDB初始化步骤。

您是如何对fuboTV服务进行规模扩展的？

我们流媒体服务的流量配置需要充分考虑“突发”因素这一条件。我们的站点往往在大型赛事开始前的十分钟起应对达到平均水平百倍的峰值访问请求。为了解决如此庞大的负载，我们将数据库操作分布在全部副本集成员当中。我们的用户遍布北美各地，为了为每位用户提供理想的延迟效果，我们利用最近原则作为线路首选项，从而保证用户能够始终接入到与之地理位置最接近的副本当中。MongoDB的数据中心识别机制在确保服务质量方面发挥着巨大作用。