這些工具使我們能夠處理數(shù)十個全球容器集群，并幫助我們管理Riot的規(guī)模感。要了解這一點，最好的起點是使用Toolbox。

下面是我們的容器可視化工具Toolbox的截圖。之前我們討論過Admiral的調度程序。下圖是來自調度程序的API數(shù)據(jù)的直觀結果?？梢钥吹轿覀兊娜蚣海瑪?shù)一下，有16個集群，以它們的部署區(qū)域命名。Riot的集群遍布全球，分布在中國臺北、雅加達、邁阿密、阿姆斯特丹，韓國和日本等地。

你可以一目了然地看到，我們正在運行超過2,400個各種應用程序的實例，我們稱這些為“打包”。這在全球范圍內轉化為超過5,000個Docker容器。這些打包在過去一兩年中都變得很活躍，正如我在Riot開發(fā)大量軟件之前所說的那樣。上面這些甚至不代表Riot運行的所有服務，而只是我們選擇在容器中運行的服務。

Toolbox不僅提供全局視圖，我們還可以深入研究任何一個數(shù)據(jù)中心并查看其中正在運行的數(shù)據(jù)。

我無法在一個屏幕快照中向你展示所有內容，但是通過在阿姆斯特丹的系統(tǒng)的簡單視圖，我們可以看到正在運行的應用程序數(shù)量。在這里，我們可以查看underlay和overlay服務，這些服務旨在簡化將計算節(jié)點與調度程序和生態(tài)系統(tǒng)相集成起來。我們還可以輕松地查看諸如節(jié)點分配、打包狀況的狀態(tài)燈，以及哪些應用程序正在向Discovery報告的信息。開發(fā)人員和運營人員可以使用它輕松訪問全局視圖，了解其服務的運行方式。

可以通過深入研究基本服務，來找到更多的詳細信息。讓我們看一看我自己擁有和運營的一項服務：Summoner服務。這有助于處理Riot服務（就像Chat和Developer API門戶一樣的第三方開放的API）的Summoner API流量。

命名空間和作用域系統(tǒng)決定著我們如何處理應用程序。下圖演示了這一點，其中Toolbox按單個應用程序和作用域進行篩選。在這種情況下，我們可以查看應用程序作用域“platform.summonercore”?？梢钥吹皆搼贸绦蚴侨绾畏职l(fā)的，包括它如何在AMS1中使用多個部署作用域。比如你可以看到“l(fā)olriot.ams1.rusummoner”和“l(fā)olriot.ams1.tr1summoner”正在分別支持俄羅斯和土耳其地區(qū)的部署。

右邊欄包含一些其它信息，例如打包中的容器數(shù)量、IP地址、基本狀態(tài)、日期信息，以及其它詳細的信息。用戶甚至可以檢查容器日志。

在這張圖片中可以看到我最喜歡的功能之一。在加載日志的同時，出現(xiàn)了跳舞的卡特琳娜的gif圖。是的伙計們，跳舞的卡特琳娜是我們內部的一個梗，她出現(xiàn)在各種內部工具的加載屏幕中。

我們在Toolbox中的指標度量系統(tǒng)是一站式的，可提供諸如服務狀態(tài)和位置的核心服務信息。如果出現(xiàn)問題，此系統(tǒng)使我們能夠立即開始分流。用戶還可以獲取快照，如下圖所示：

在本系列 第一篇文章中，我們討論了如何使用Tungsten Fabric和JSON配置文件對網絡進行基于軟件的控制。JSON很酷，但是凝視它足夠長的時間，也會使你的眼睛流血。為了幫助我們的工程師，我們構建了一個可視化工具，并選擇了非常原始的名稱“network.rcluster”。

當你登錄時，會看到一排排的小部件，表示我們已在整個集群中全局應用的網絡規(guī)則。其中的每一個都由JSON配置blob作為支撐。讓我們仔細看一下前面提到的Summonercore應用。

乍一看，這并不是什么令人興奮的東西，只是部署作用域的列表而已。實際上，它是該應用程序作用域的框架。我們可以看到Summoner具有適用于廣泛部署作用域的網絡規(guī)則。考慮到Summoner運行在我們擁有《英雄聯(lián)盟》的任何一個地方，這是很有道理的。

我們選擇其中一個，就應該能夠看到Summoner的訪問權限。

這里有很多條路由。使用這個工具，我們可以檢查正在使用中的端口，并查看所有入站和出站連接。再說一遍，這有我們最喜歡的應用程序作用域的框架。如果你有敏銳的眼光，你會發(fā)現(xiàn)Summoner被允許與我們的“rtp.collector”通信，該調用會返回到我之前提到的指標。另一個連接是“infrastructurous.discoverous”，這是我們的發(fā)現(xiàn)服務。這個特定的屏幕截圖來自于QA環(huán)境，因此你可以看到一些測試應用程序。

運行如此多的軟件，其中一個挑戰(zhàn)是，有時你無法掌握部署的位置。我們可以使用諸如Toolbox之類的工具，來手動遍歷每個集群并篩選應用名稱，但是Toolbox僅向我們顯示正在運行的打包和容器。許多傳統(tǒng)的Riot軟件都已部署到物理機上（多么傳統(tǒng)），我們也希望能夠搜索到那些應用程序。

這就是查詢服務或信息聚合器能派上用場的地方。我們擁有一個創(chuàng)造性的工具，命名為“services.rcluster”，該工具使我們可以指定各種基于上下文的搜索。這是我使用此工具查找剛才看到的所有全球Summoner服務的截圖。

查詢服務與服務發(fā)現(xiàn)工具是不同的。相反，它使用基于上下文的搜索來查詢沒有被發(fā)現(xiàn)的服務。例如，當你只記得“platform.summonercore”中的字符串“summoner”時，它可以抓取我們的Admiral調度程序的部署，來匹配字符串并返回到相關命令中。它是以人為本的搜索工具，可以適應人為的缺陷。

在這里，你也可以看到“位置”列，該列引用了我們命名作用域的部署部分。列中的服務名稱是應用程序作用域。

到目前為止，我們已經研究了如何管理生產環(huán)境中運行的東西。但大多數(shù)軟件的生命周期，在它們投入生產之前就已經開始了。當你每年使用超過一百萬種軟件構建時，如果沒有根據(jù)時間查看事件的能力，就會遇到麻煩。

來介紹Buildtracker——這個工具是另一個由API/網絡驅動的工具，團隊可以選擇自動或手動的方式發(fā)布和查詢數(shù)據(jù)。當軟件從代碼轉換為服務時，這使他們可以跟蹤這個軟件。

這是我們第一次公開討論這個工具，但是使用它已經有大約三、四年的時間了，甚至比我們轉向微服務還要早。

我們構建和擴展了大量的軟件，真心不希望團隊為跟蹤這些構建，去抓取數(shù)千行的構建和管道日志。Buildtracker為持續(xù)集成系統(tǒng)（或任何自動化/部署系統(tǒng)）提供了一個干凈的API，用于添加、標記和查詢任何內部版本的變更列表和工件。

當團隊決定構建一個服務時，可以生成微服務構建管道。團隊還可以創(chuàng)建自己的構建管道，并使用此API進行跟蹤。然后，他們可以在其構建中搜索如下結果：

上圖是在Buildtracker工具中我們的配置服務條目的截圖。我們?yōu)楹芏鄠€篩選器構建了不同的風格，例如給定的變更列表，構建時間，使用的版本號以及各種標簽。這些標記跟蹤幾種行為，包括構建工件所部署的環(huán)境（紅色），以及通過的QA事件（灰色）。團隊可以使用Buildtracker標簽，將各種版本的構建標記為“QA Passed”。然后，他們可以標記僅檢索QA Passed構建的步驟，例如部署作業(yè)。通過這個過程，團隊可以創(chuàng)建受信任的持續(xù)交付管道，以確保它們僅部署已通過質量檢查的項目。

即使團隊沒有完全采用此過程，他們仍然可以通過一目了然的參考信息，來訪問有關構建的寶貴歷史。

該頁面包含到工件存儲的路徑，到構建作業(yè)的鏈接，以及發(fā)生的各種事件的時間表。Buildtracker中的“發(fā)布管理”視圖使我們能夠查看使用此類元數(shù)據(jù)為團隊提供的全部功能：

這張圖只是發(fā)行團隊中用于管理《英雄聯(lián)盟》發(fā)行版本的其中一個存儲桶的快照?？蛻舳?、游戲服務器、音頻包和服務都可以包含在這些列表中。你還可以看到許多標簽，它們反映了補丁程序、環(huán)境、QA流程等。

當你構建數(shù)百個服務和應用程序時，這樣的數(shù)據(jù)聚合器確實可以幫助你理解流程，并提供一些版本管理控制。

我們在文章中介紹的很多生態(tài)系統(tǒng)工具，都是自動地為團隊工作，另外一些是選擇加入的技術，團隊可以選擇使用它們，或者自己來做。我們的總體策略是，如果工具和技術足夠有用，那么團隊將使用它們，而不是構建自己的解決方案。這營造了一種靈活、敏捷的氛圍，使我們能夠專注于為真正渴望或需要它們的團隊創(chuàng)建并支持最有價值的工具。例如，一個團隊可能使用Service Discovery，但選擇在構建時靜態(tài)配置其應用程序，或者從不存儲機密信息，或者使用我們提供的幾乎所有內容但構建自己的解決方案來跟蹤構建。

最終，這些工具使每個服務創(chuàng)建者和產品團隊都能夠充分利用他們所需的功能，將其功能盡快交付給玩家，同時又能保持很高的質量。

·END·

• 揭秘LOL背后的IT基礎架構丨踏上部署 多樣性的征程

• 揭秘LOL背后的IT基礎設施丨關鍵角色“調度”

• 揭秘LOL背后的IT基礎架構丨SDN解鎖新基礎架構

• 揭秘LOL背后的IT基礎架構丨基礎設施即代碼

• 揭秘LOL背后的IT基礎架構丨微服務生態(tài)系統(tǒng)