第六章开发者生态系统

2018-02-27 薛命灯
在上一章结尾部分，我向大家展示了用来访问我们微服务生态系统的 Web 工具。我们之前已经介绍过其中的一些应用：用于保存容器镜像的 JFrog Artifactory、发现服务、度量指标系统以及用于自动化和持续交付的 Jenkins。除了这些，还有其他很多工具。
因为时间的关系，我没办法逐一介绍它们，不过我会集中介绍几个在管理生态系统关键部分给我们带来巨大帮助的工具。我们借助这些工具来：
可视化和检视全球的容器集群（Toolbox）
简化软件网络规则的处理（network.rcluster）
在全球范围内查找服务（服务发现）
对构建和部署过程进行跟踪（Build Tracker）
可视化集群下面是 Toolbox 的截图，也就是我们的容器可视化工具。在之前的章节中，我们介绍了 Admiral 调度器，这张图片所显示的就是从这个调度器的 REST API 返回的数据可视化结果。我们可以从图中看到全球集群的状态（可以看到总共有 16 个集群），并根据部署区域分开显示。Riot 的集群分布在世界各地，包括台北、雅加达、迈阿密、阿姆斯特丹、韩国和日本。
我们运行了 2400 多个应用程序实例，并将这些实例叫作 Pack。这些实例需要 5000 多个 Docker 容器来运行。在过去一两年中，这些 Pack 一直处于运行状态。不过，上图只显示了运行在容器当中的服务，Riot 还有其他很多服务并没有在张图上显示出来。
Toolbox 不仅提供了一个全局视图，我们还可以点进去查看各个数据中心的详细信息。
一张截图无法显示所有的内容，不过从这张阿姆斯特丹系统的简单视图中，我们可以看到运行中的应用程序的数量。我们可以看到底层的叠加网络服务，还能看到节点应用程序、Pack 的状态，以及哪些应用程序注册到了发现服务上。开发人员和运维人员可以基于这些视图更好地了解服务的运行情况。
如 果 要 查 看 服 务 的 细 节 ， 可 以 继 续 点 进 去 。 下 面 以 我 负 责 的 Summoner（召唤者）服务为例。该服务负责处理来自 Riot Chat 和 Developer API Portal 的流量。
我们基于命名空间和作用域系统来管理应用程序。如下图所示，Toolbox 根据应用程序命名空间和作用域进行过滤，在这张图中，我们查看的应用程序叫作“platform.summonercore”。我们可以看到应用程序实例是如何分布的，包括它在 AMS1 中使用了多种部署作用域进行部署。比如，“lolriot.ams1.rusummoner”和“lotriot.ams1.tr1summoner”分别用来支持俄罗斯和土耳其。
右边的侧边栏包含了额外的信息，如 Pack 中包含的容器数量、IP 地址、基本状态、日期信息，等等。我们还能在上面查看容器日志。
这张图展示的是我最喜欢的一个功能。在加载日志过程中，我们可以看到一张 GIF 图片——跳舞的 Katarina（游戏中的一个角色）。没错，她会出现在我们内部各种工具的加载屏幕上。
Toolbox 中的度量指标系统为我们提供了一站式的核心服务信息查看功能，如查看服务状态和服务位置。在发生问题时，我们可以立即进行问题诊断。我们还能进行截屏，如下图所示。
管理复杂的网络规则在之前的章节中，我们介绍了我们是如何通过 Contrail 和 JSON 配置文件来管理网络的。JSON 很不错，但如果文件太长，阅读起来十分不方便。为了方便工程师查看 JSON 文件，我们开发了一个可视化工具，
并把它叫作“network.rcluster”。
在登录系统之后，可以看到一行一行的部件，它们表示不同集群的网路规则。每一个部件都是通过一个 JSON 文件来生成的。现在让我们仔细看一下之前提到的 Summonercore。
初一看好像没有什么，它只不过是一个部署作用域清单而已。我们可以看到 Summoner 有很多部署作用域网络规则。因为在有《英雄联盟》的地方，都会有 Summoner，所以这些网络规则是必需的。
如果选择其中一条规则，我们可以看到 Summoner 的访问权限设置。
这里有非常多的路由规则，我们可以查看端口信息和流进流出的网络连接。从这张图中，我们可以看到 Summoner 可以与“rtp.collector”和“infrastructurous.discoverous”发生交互，后者是我们的发现服务。这张截图是从 QA 环境中获取的，所以还能从中看到一些测试应用程序。
全局搜索运行如此多的服务，如何跟踪这些服务就会成为一个问题。我们可以使用 Toolbox 来查看每个集群，但它只显示了运行中的 Pack 和容器。Riot 还有很多遗留的系统部署在物理机上，我们希望能够把它们也管理起来。
于是，我们开发了查询服务，或者叫做信息聚合器。我们把这个工具叫作“services.rcluster”，它为我们提供了各种基于上下文的搜索服务。下图展示了我们使用这个工具在全球范围内查找 Summoner 服务。
这里需要澄清的是，查询服务与服务发现是不一样的。它提供的是基于上下文的搜索，用于
查找未注册的服务。例如，它会扫描 Admiral 调度器，返回匹配的结果。如果你只记得“platform.summonercore”中的“summoner”，那么就可以用这个字符串来查找这个服务。
在这张图上可以看到“Location”列，它显示了命名空间作用域。服务名称显示的是应用程序作用域。
构建跟踪器我们已经介绍了我们是如何管理生产环境服务的。不过，这些服务在进入生产环境之前还有很长的路要走。我们每年要进行一百万次构建，如果没有一个跟踪系统，事情会变得一团糟。
Buildtracker 是另一个基于 API 和 Web 驱动的工具，开发团队可以通过自动或手动的方式提交或查询数据。他们通过这个工具来跟踪他们的代码和构建过程。
我可以为这个写一本书，这也是第一次公开介绍这个工具，但其实我们已经用这个工具 3、4 年时间了——早在使用微服务之前就开始使用它。
因为要构建的服务太多了，我们不希望开发团队通过无数的构建管道日志来
跟踪服务的构建过程。Buildtracker 提供了一组干净的 API，可与持续集成系统（或任何自动化部署系统）集成起来，进行构建、打标签、查询。
如果某个团队决定要开发一个微服务，就可以先生成一个微服务构建管道。他们也可以自己搭建构建管道，然后使用这组 API 进行跟踪。他们可以使用 API 来查询构建结果，如下图所示：
这张图显示的是我们的配置服务。我们添加了很多种过滤器，如变更列表、在构建时使用的版本和其他各种标签。标签可用于跟踪多种行为，如应用文件的部署环境（红色部分）和 QA 传入的事件（灰色部分）。开发团队可以使用 Buildtracker 标签来标记各个构建是否已经通过测试，然后过滤出已经通过测试的构建。团队因此可以创建出可信任的持续交付管道，确保只部署已经经过严格测试的项目。
即使团队不会完全采用这个流程，他们仍然可以查看构建历史的详细信息。
上图中包含了部署文件的路径、构建作业的链接和各个事件的时间线。我们可以从 Buildtracker 的 Release Management 视图中看到个多元数据信息。
这张图片展示了我们的一个发布团队在管理《英雄联盟》版本发布时的内容。其中包含了客户端、服务器、音效包和服务信息。从中还能看到很多标签，如补丁标签、环境标签、QA 流程标签等。
在开发大量的服务和应用时，有这样的一个聚合器将会为你带来很大的帮助。
在这一章中介绍的大部分工具都是自动化运行的。有一些是可选择的，团队可以根据需要决定要不要使用它们。我们的策略是，如果一个工具很有用，那么团队就会用它，而不是自己再去开发。这种灵活、敏捷的氛围让我们可以集中精力为团队创建最有价值的工具，真正给他们带来帮助。而借助这些工具，产品团队就可以快速地将新的功能交付给玩家。
更多内容，请点击《英雄联盟 | 在线服务运维之道》阅读专题全部文章。