检查和可视化全局容器集群上正在运行的内容（Toolbox）
轻松处理复杂的软件网络规则（network.rcluster）
在全球范围内查询我们的服务来弄清楚什么在哪里（Service Discovery）
跟踪构建和部署（Buildtracker）
这些工具使我们能够处理数十个全球容器集群，并帮助我们管理Riot的规模感。要了解这一点，最好的起点是使用Toolbox。
下面是我们的容器可视化工具Toolbox的截图。之前我们讨论过Admiral的调度程序。下图是来自调度程序的API数据的直观结果。可以看到我们的全球集群，数一下，有16个集群，以它们的部署区域命名。Riot的集群遍布全球，分布在中国台北、雅加达、迈阿密、阿姆斯特丹，韩国和日本等地。
你可以一目了然地看到，我们正在运行超过2,400个各种应用程序的实例，我们称这些为“打包”。这在全球范围内转化为超过5,000个Docker容器。这些打包在过去一两年中都变得很活跃，正如我在Riot开发大量软件之前所说的那样。上面这些甚至不代表Riot运行的所有服务，而只是我们选择在容器中运行的服务。
Toolbox不仅提供全局视图，我们还可以深入研究任何一个数据中心并查看其中正在运行的数据。
我无法在一个屏幕快照中向你展示所有内容，但是通过在阿姆斯特丹的系统的简单视图，我们可以看到正在运行的应用程序数量。在这里，我们可以查看underlay和overlay服务，这些服务旨在简化将计算节点与调度程序和生态系统相集成起来。我们还可以轻松地查看诸如节点分配、打包状况的状态灯，以及哪些应用程序正在向Discovery报告的信息。开发人员和运营人员可以使用它轻松访问全局视图，了解其服务的运行方式。
可以通过深入研究基本服务，来找到更多的详细信息。让我们看一看我自己拥有和运营的一项服务：Summoner服务。这有助于处理Riot服务（就像Chat和Developer API门户一样的第三方开放的API）的Summoner API流量。
命名空间和作用域系统决定着我们如何处理应用程序。下图演示了这一点，其中Toolbox按单个应用程序和作用域进行筛选。在这种情况下，我们可以查看应用程序作用域“platform.summonercore”。可以看到该应用程序是如何分发的，包括它如何在AMS1中使用多个部署作用域。比如你可以看到“lolriot.ams1.rusummoner”和“lolriot.ams1.tr1summoner”正在分别支持俄罗斯和土耳其地区的部署。
右边栏包含一些其它信息，例如打包中的容器数量、IP地址、基本状态、日期信息，以及其它详细的信息。用户甚至可以检查容器日志。
在这张图片中可以看到我最喜欢的功能之一。在加载日志的同时，出现了跳舞的卡特琳娜的gif图。是的伙计们，跳舞的卡特琳娜是我们内部的一个梗，她出现在各种内部工具的加载屏幕中。
我们在Toolbox中的指标度量系统是一站式的，可提供诸如服务状态和位置的核心服务信息。如果出现问题，此系统使我们能够立即开始分流。用户还可以获取快照，如下图所示：
在本系列 第一篇文章中，我们讨论了如何使用Tungsten Fabric和JSON配置文件对网络进行基于软件的控制。JSON很酷，但是凝视它足够长的时间，也会使你的眼睛流血。为了帮助我们的工程师，我们构建了一个可视化工具，并选择了非常原始的名称“network.rcluster”。
当你登录时，会看到一排排的小部件，表示我们已在整个集群中全局应用的网络规则。其中的每一个都由JSON配置blob作为支撑。让我们仔细看一下前面提到的Summonercore应用。
乍一看，这并不是什么令人兴奋的东西，只是部署作用域的列表而已。实际上，它是该应用程序作用域的框架。我们可以看到Summoner具有适用于广泛部署作用域的网络规则。考虑到Summoner运行在我们拥有《英雄联盟》的任何一个地方，这是很有道理的。
我们选择其中一个，就应该能够看到Summoner的访问权限。
这里有很多条路由。使用这个工具，我们可以检查正在使用中的端口，并查看所有入站和出站连接。再说一遍，这有我们最喜欢的应用程序作用域的框架。如果你有敏锐的眼光，你会发现Summoner被允许与我们的“rtp.collector”通信，该调用会返回到我之前提到的指标。另一个连接是“infrastructurous.discoverous”，这是我们的发现服务。这个特定的屏幕截图来自于QA环境，因此你可以看到一些测试应用程序。
运行如此多的软件，其中一个挑战是，有时你无法掌握部署的位置。我们可以使用诸如Toolbox之类的工具，来手动遍历每个集群并筛选应用名称，但是Toolbox仅向我们显示正在运行的打包和容器。许多传统的Riot软件都已部署到物理机上（多么传统），我们也希望能够搜索到那些应用程序。
这就是查询服务或信息聚合器能派上用场的地方。我们拥有一个创造性的工具，命名为“services.rcluster”，该工具使我们可以指定各种基于上下文的搜索。这是我使用此工具查找刚才看到的所有全球Summoner服务的截图。
查询服务与服务发现工具是不同的。相反，它使用基于上下文的搜索来查询没有被发现的服务。例如，当你只记得“platform.summonercore”中的字符串“summoner”时，它可以抓取我们的Admiral调度程序的部署，来匹配字符串并返回到相关命令中。它是以人为本的搜索工具，可以适应人为的缺陷。
在这里，你也可以看到“位置”列，该列引用了我们命名作用域的部署部分。列中的服务名称是应用程序作用域。
到目前为止，我们已经研究了如何管理生产环境中运行的东西。但大多数软件的生命周期，在它们投入生产之前就已经开始了。当你每年使用超过一百万种软件构建时，如果没有根据时间查看事件的能力，就会遇到麻烦。
来介绍Buildtracker——这个工具是另一个由API/网络驱动的工具，团队可以选择自动或手动的方式发布和查询数据。当软件从代码转换为服务时，这使他们可以跟踪这个软件。
这是我们第一次公开讨论这个工具，但是使用它已经有大约三、四年的时间了，甚至比我们转向微服务还要早。
我们构建和扩展了大量的软件，真心不希望团队为跟踪这些构建，去抓取数千行的构建和管道日志。Buildtracker为持续集成系统（或任何自动化/部署系统）提供了一个干净的API，用于添加、标记和查询任何内部版本的变更列表和工件。
当团队决定构建一个服务时，可以生成微服务构建管道。团队还可以创建自己的构建管道，并使用此API进行跟踪。然后，他们可以在其构建中搜索如下结果：
上图是在Buildtracker工具中我们的配置服务条目的截图。我们为很多个筛选器构建了不同的风格，例如给定的变更列表，构建时间，使用的版本号以及各种标签。这些标记跟踪几种行为，包括构建工件所部署的环境（红色），以及通过的QA事件（灰色）。团队可以使用Buildtracker标签，将各种版本的构建标记为“QA Passed”。然后，他们可以标记仅检索QA Passed构建的步骤，例如部署作业。通过这个过程，团队可以创建受信任的持续交付管道，以确保它们仅部署已通过质量检查的项目。
即使团队没有完全采用此过程，他们仍然可以通过一目了然的参考信息，来访问有关构建的宝贵历史。
该页面包含到工件存储的路径，到构建作业的链接，以及发生的各种事件的时间表。Buildtracker中的“发布管理”视图使我们能够查看使用此类元数据为团队提供的全部功能：
这张图只是发行团队中用于管理《英雄联盟》发行版本的其中一个存储桶的快照。客户端、游戏服务器、音频包和服务都可以包含在这些列表中。你还可以看到许多标签，它们反映了补丁程序、环境、QA流程等。
当你构建数百个服务和应用程序时，这样的数据聚合器确实可以帮助你理解流程，并提供一些版本管理控制。
我们在文章中介绍的很多生态系统工具，都是自动地为团队工作，另外一些是选择加入的技术，团队可以选择使用它们，或者自己来做。我们的总体策略是，如果工具和技术足够有用，那么团队将使用它们，而不是构建自己的解决方案。这营造了一种灵活、敏捷的氛围，使我们能够专注于为真正渴望或需要它们的团队创建并支持最有价值的工具。例如，一个团队可能使用Service Discovery，但选择在构建时静态配置其应用程序，或者从不存储机密信息，或者使用我们提供的几乎所有内容但构建自己的解决方案来跟踪构建。
最终，这些工具使每个服务创建者和产品团队都能够充分利用他们所需的功能，将其功能尽快交付给玩家，同时又能保持很高的质量。
·END·
更多“揭秘LOL”系列文章揭秘LOL背后的IT基础架构丨踏上部署 多样性的征程
揭秘LOL背后的IT基础设施丨关键角色“调度”
揭秘LOL背后的IT基础架构丨SDN解锁新基础架构
揭秘LOL背后的IT基础架构丨基础设施即代码
重庆分公司
重庆分公司
