揭祕LOL背後的IT基礎架構丨開發者“打野”工具能做什麼?

歡迎來到Tungsten Fabric用戶案例系列文章,一起發現TF的更多應用場景。“揭祕LOL”系列的主人公是Tungsten
Fabric用戶Riot Games遊戲公司,作爲LOL《英雄聯盟》的開發和運營商,Riot Games面臨全球範圍複雜部署的挑戰,讓我們一起揭祕LOL背後的“英雄們”,看他們是如何運行在線服務的吧。
作者:Maxfield Stewart(文章來源:Riot Games)譯者:TF編譯組

在這裏插入圖片描述
在上一篇文章中,我們討論了支持服務的生態系統,使我們能夠在生產環境中運行微服務。如果說微服務是我們的“核心”,那些工具是“輔助”,那我們的“打野”呢?這就要介紹我們用於集羣管理的開發者生態系統了。在過去的文章中,我們已經討論了一些工具,例如build farm和使用容器來構建容器的策略,這裏就不再過多介紹細節了。

還記得上篇文章那個Web小部件嗎?它可以輔助引導工程師們使用工具生態系統:
在這裏插入圖片描述
我們已經介紹了其中的一些應用程序:JFrog的Artifactory,用於圖像存儲和全局複製;Discovery用於發現服務;Metrics和Jenkins用於自動化和連續交付需求。當然,裏面還有更多應用程序可以探索!

我沒時間去覆蓋所有內容,但是這個小部件是個不錯的起點。現在,我們來看看在生態系統管理的其他關鍵領域提供幫助的工具。這些工具使我們能夠:

  • 檢查和可視化全局容器集羣上正在運行的內容(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,但選擇在構建時靜態配置其應用程序,或者從不存儲機密信息,或者使用我們提供的幾乎所有內容但構建自己的解決方案來跟蹤構建。

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

更多“揭祕LOL”系列文章
揭祕LOL背後的IT基礎架構丨踏上部署多樣性的征程
揭祕LOL背後的IT基礎設施丨關鍵角色“調度”
揭祕LOL背後的IT基礎架構丨SDN解鎖新基礎架構
揭祕LOL背後的IT基礎架構丨基礎設施即代碼
揭祕LOL背後的IT基礎架構丨微服務生態系統

在這裏插入圖片描述
在這裏插入圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章