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

作者:Jonathan McCaffrey

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

我叫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服务器
1) feapp在“服务发现”中查找Loot服务,以寻找其IP和端口信息。
2) feapp对Loot服务进行HTTP GET调用。
3) Loot服务会检查Loot缓存,以查看玩家的库存物品是否存在。
4) 库存物品不在缓存中,因此,Loot服务调用Loot数据库以查看玩家当前拥有的物品,并把该结果填充到缓存。
5) 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进行联网,以及运行动态应用程序。
如果你正处于类似的“旅程”中,或者想参与讨论,非常欢迎与我们取得联系。


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/23939.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于20-03-20
0