揭秘LOL背后的IT基础架构丨踏上部署多样性的征程

本期开始，我们将陆续分享Tungsten Fabric用户案例文章，一起发现TF的更多应用场景。“揭秘LOL”系列的主人公是TF用户Riot Games游戏公司，作为LOL《英雄联盟》的开发和运营商，Riot Games面临全球范围复杂部署的挑战，让我们一起揭秘LOL背后的“英雄们”，看他们是如何运行在线服务的吧。
作者：Jonathan McCaffrey（文章来源：Riot Games）译者：TF中文社区

我叫Jonathan McCaffrey，在Riot的基础架构团队工作。这是该系列文章中的第一篇，我们将深入探讨如何在全球范围内部署和操作后端功能。在深入探讨技术细节之前，重要的是要了解Rioters（Riot人）如何考虑功能开发。在Riot，玩家的价值至高无上，开发团队通常直接与玩家社区合作，以提供功能和改进信息。为了提供最佳的玩家体验，我们需要快速行动，并具备可以根据反馈保持快速更改计划的能力。基础架构团队的任务，就是为我们的开发人员能做到这一点铺平道路——越是加强Riot团队的能力，就可以越快地将功能交付给玩家使用。

当然，说起来容易做起来难！鉴于我们在部署上的多样性，因此出现了许多挑战：我们的服务器遍布在公共云、私有数据中心，以及腾讯和Garena这样的合作伙伴环境当中，所有这些环境在地理位置和技术上都各不相同。

当功能团队准备好交付组件时，这种复杂性给他们带来了巨大的负担。那就是基础架构团队的职责所在——我们通过基于容器的内部云环境（我们称为“rCluster”）消除了一些部署障碍。在本文中，我将讨论Riot从手动部署到使用rCluster启动功能的历程。为了说明rCluster的产品和技术，我将逐步介绍Hextech Crafting系统的发布（Hextech Crafting是英雄联盟的开箱系统的名字）。

一点历史

7年前，当我刚开始在Riot工作时，我们并没有太多的部署或服务器管理流程，Riot当时是一家具有远见卓识，但预算少并且需要快速发展的初创公司。当为《英雄联盟》构建生产环境基础架构时，我们匆忙的满足游戏的需求、从开发人员带来的更多功能的需求，来自区域团队的在全球开设新区的需求。我们手动启用服务器和应用，很少考虑原则或战略规划。

在此过程中，我们转向利用Chef完成许多常见的部署和基础设施任务。同时，开始将越来越多的公共云用于大数据和Web工作。这些变革也多次触发了我们的网络设计、供应商选择和团队结构的变化。

我们的数据中心容纳了数千台服务器，并且几乎为每个新应用程序都安装了新的服务器。新服务器将存在于自己手动创建的VLAN中，并具备路由和防火墙规则，以实现网络之间的安全访问。尽管此过程可以帮助我们提高安全性并明确定义故障域，但它既费时又费力。更麻烦的是，当时的大多数新功能都被设计为小型Web服务，这使得我们的LoL（英雄联盟）的生态系统，独立应用的数量激增。

最重要的是，开发团队对他们的应用程序测试能力缺乏信心，尤其是在涉及诸如配置和网络连接之类的部署问题时。将应用程序与物理环境紧密联系在一起，意味着生产数据中心环境之间的差异不会在QA（测试）、Staging（上线前）和PBE（基于模式开发）中复制。每个环境都是手工制作的、独特的，到最后始终也不能一致。（注释：本文主要想描述的两个问题，第一是客户的应用和环境紧密相关，但是由于不同的团队或者部门的应用环境不同，因此可能出现因为不一致对应用上线带来问题）

当我们在应用程序数量不断增加的生态系统中，应对手动服务器和网络配置的挑战时，Docker开始在我们的开发团队中获得普及，作为解决配置一致性和开发环境问题的方法。一旦开始使用，我们能明显感觉到Docker可以做更多的事情，并且可以在处理基础架构的过程中发挥关键作用。

2016年及以后

当时基础架构团队设定了一个目标，为2016赛季的玩家，开发人员和Riot公司解决这些问题。到2015年底，我们已经从手动部署功能，转变为以自动化且一致的方式在Riot地区部署类似Hextech Crafting等功能。我们的解决方案是用rCluster这一全新的系统，该系统在微服务架构中利用了Docker和SDN软件定义网络。切换到rCluster可以弥补我们在环境和部署过程中的不一致之处，并使产品团队可以专注于他们的产品开发。

让我们深入研究一下这项技术，以了解rCluster如何在后台支持Hextech Crafting等功能。解释一下，Hextech Crafting是《英雄联盟》的一项功能，可为玩家提供一种解锁游戏内物品的新方法。

该功能内部称为“Loot”，由3个核心组件组成：

• Loot服务 -通过HTTP/JSON ReST API提供Loot请求的Java应用程序。
• Loot缓存 -使用Memcached和小型golang sidecar进行监控、配置，以及启动/停止操作的缓存集群。
• Loot数据库 -具有一个主服务器和多个从属服务器的MySQL数据库集群。

当你打开crafting屏幕时，将发生以下情况：

1.玩家在客户端中打开crafting屏幕。

2.客户端对前端应用程序（也称为“feapp”）进行RPC调用，以代理玩家和内部后端服务之间的调用。

3.feapp调用Loot服务器

• feapp在“服务发现”中查找Loot服务，以寻找其IP和端口信息。
• feapp对Loot服务进行HTTP GET调用。
• Loot服务会检查Loot缓存，以查看玩家的库存物品是否存在。
• 库存物品不在缓存中，因此，Loot服务调用Loot数据库以查看玩家当前拥有的物品，并把该结果填充到缓存。
• Loot服务答复GET调用。

4.feapp将RPC响应发送回客户端。

与Loot团队合作，我们能够将Server和Cache层内置到Docker容器中，并且它们的部署配置在JSON文件中定义，如下所示：

Loot服务器JSON示例：

Loot缓存JSON示例：

但是，要实际部署此功能，并在减少前述的问题方面取得真正的进展——我们需要在北美、南美、欧洲和亚洲等地创建可以支持Docker的集群。这需要我们解决一堆难题，例如：

• 调度容器
• 与Docker网络联网
• 持续交付
• 运行动态应用程序

随后的文章将更详细地介绍rCluster系统的这些组件，在这里我简要概述一下每个组件。

调度（SCHEDULING）

我们使用编写的Admiral软件在rCluster生态系统中实现了容器调度。Admiral跨过一系列物理机器与Docker守护进程（daemons）进行对话，以了解其当前的运行状态。用户通过HTTPS发送上述JSON（Admiral用来更新了解对相关容器所需的状态）来发出请求，然后，它会连续扫描集群的活动状态和所需状态，以找出需要采取的措施。最后，Admiral再次调用Docker守护程序来启动和停止容器，以收敛于所需的状态。

如果某个容器崩溃，Admiral可以发现实时状态与期望状态间的差异，并在另一台主机上启动该容器以对其进行纠正。这种灵活性使管理服务器变得更加容易，因为我们可以无缝地“榨干”它们，加以维护，或者重新启用它们以处理工作负载。

Admiral与开源工具Marathon相似，因此我们正在研究移植工作以利用Mesos、Marathon和DC/OS。如果这项工作取得成果，我们将在以后的文章中讨论。

与DOCKER进行联网

容器运行后，我们需要在Loot应用程序和生态系统的其他部分之间提供网络连接。为此，我们利用OpenContrail为每个应用程序提供了专用网络，并让我们的开发团队使用GitHub中的JSON文件自己管理其策略。

Loot服务器网络：

Loot缓存网络：

当工程师在GitHub中更改此配置时，将运行一个转换作业，并在Contrail中进行API调用，为其应用程序的专用网络创建和更新策略。

Contrail使用一种称为“Overlay Networking”的技术来实现这些专用网络。在我们的案例中，Contrail 在计算主机之间使用GRE隧道，并使用网关路由器来管理进入和离开overlay隧道并前往网络其余部分的流量。OpenContrail系统的灵感来自于标准MPLS L3VPN，并且在概念上与标准MPLS L3VPN非常相似。可以在这里找到更深入的架构细节。（附注：opencontrail现在已经改名为TF）

在实施此系统时，我们必须解决一些关键挑战：

• Contrail和Docker之间的集成
• 允许网络的其他部分（rCluster外部）无缝访问新的overlay网络
• 允许一个集群中的应用程序与另一个集群进行通信
• 在AWS上运行overlay网络
• 在overlay中构建面向边缘的应用程序HA负载均衡

持续交付

对于Loot应用程序，CI流程如下所示：

此处的总体目标是，当更改主仓库（Master repo）时，将创建一个新的应用程序容器并将其部署到QA环境。有了这个工作流程，团队可以快速迭代他们的代码，并查看实际游戏中反映的更改。紧密的反馈回路，使得迅速改善体验成为可能，这是Riot“专注于玩家”工程的主要目标。

运行动态应用程序

至此，我们已经讨论了如何构建和部署Hextech Crafting之类的功能，但是，如果你花了很多时间在这样的容器环境上工作，那便不是问题所在。

在rCluster模型中，容器具有动态IP地址，并且不断跳转。这与我们以前的静态服务器和部署方法完全不同，因此需要有效的新工具和流程。

其中一些关键问题如下：

• 如果应用程序的容量和端点一直在变化，我们该如何监视它？
• 如果一个应用程序一直在变化，那么它如何知道另一个应用程序的端点？
• 如果你无法ssh进入容器并且每次启动新容器时都重置日志，那么如何分类应用程序的问题？
• 如果在构建时baking容器，如何配置数据库密码之类的东西，或者在“土耳其”与“北美”之间都切换了哪些选项？

为了解决这些问题，我们必须构建一个微服务平台，来处理诸如服务发现、配置管理和监视之类的事情。在本系列的最后一部分中，我们将深入探讨该系统及其解决问题的更多细节。

结论

希望本文能为你提供一个概览，了解我们正在尝试解决的各种问题，以使Riot更加轻松地传递玩家价值。如前所述，我们将在后续文章中重点介绍rCluster对调度的使用、与Docker进行联网，以及运行动态应用程序。

如果你正处于类似的“旅程”中，或者想参与讨论，非常欢迎与我们取得联系。

关注微信：TF中文社区