揭秘LOL背后的IT基礎(chǔ)設(shè)施丨關(guān)鍵角色“調(diào)度”-創(chuàng)新互聯(lián)

歡迎來到Tungsten Fabric用戶案例系列文章，一起發(fā)現(xiàn)TF的更多應(yīng)用場景?！敖颐豅OL”系列的主人公是Tungsten Fabric用戶Riot Games游戲公司，作為LOL《英雄聯(lián)盟》的開發(fā)和運(yùn)營商，Riot Games面臨全球范圍復(fù)雜部署的挑戰(zhàn)，讓我們一起揭秘LOL背后的“英雄們”，看他們是如何運(yùn)行在線服務(wù)的吧。
作者：Kyle Allan和Carl Quinn（文章來源：Riot Games）

十余年的潞城網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。成都全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整潞城建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)公司從事“潞城網(wǎng)站設(shè)計”,“潞城網(wǎng)站推廣”以來，每個客戶項目都認(rèn)真落實(shí)執(zhí)行。

我們是Kyle Allan和Carl Quinn，在Riot的基礎(chǔ)架構(gòu)團(tuán)隊工作。歡迎閱讀這個系列的第二篇文章，詳細(xì)介紹我們?nèi)绾卧谌蚍秶鷥?nèi)部署和操作后端功能。在本文中，我們將深入探討部署生態(tài)系統(tǒng)的第一個核心組件：容器調(diào)度。

在Jonathan的第一篇系列文章中，討論了Riot的部署歷史和我們面臨的挑戰(zhàn)。特別是，他概述了當(dāng)我們?yōu)椤队⑿勐?lián)盟》不斷添加基礎(chǔ)架構(gòu)設(shè)施時，尤其是面對“為每個應(yīng)用程序手動配置服務(wù)器”這樣的場景下，我們軟件部署難度不斷加劇。后來，出現(xiàn)了一個名為Docker的工具，改變了我們的服務(wù)器部署方法——進(jìn)一步在我們內(nèi)部就迭代出來Admiral，它是我們用于集群調(diào)度和管理的內(nèi)部工具。

重要的是，應(yīng)用程序部署的旅程還遠(yuǎn)遠(yuǎn)沒有結(jié)束，它還在不斷發(fā)展，我們正在為下一個階段做準(zhǔn)備（可能采用DC/OS，稍后討論）。本文介紹了如何到達(dá)這一步，以及為什么做出這樣的決定，希望其他人也可以從這個故事中有所收益。

什么是調(diào)度（Scheduling），為什么要調(diào)度

當(dāng)Docker橫空出世，并且Linux容器化成為一種更廣為人知的技術(shù)時，我們意識到，可以通過容器化基礎(chǔ)架構(gòu)的實(shí)施而受益。Docker容器映像提供了一個不變的、可部署的“神器”，它可以一次構(gòu)建并部署在開發(fā)、測試和生產(chǎn)中。此外，它還保證生產(chǎn)環(huán)境中運(yùn)行的映像的依賴性，與測試期間的依賴性完全相同。

另一個好處尤其重要：Docker允許將部署單元（容器）與計算單元（主機(jī)）解耦，它通過利用調(diào)度程序?qū)⑷萜鞣峙浣o主機(jī)（希望以一種智能的方式），從而消除了服務(wù)器與應(yīng)用程序之間的耦合——給定的容器可以在任意數(shù)量的可能的服務(wù)器上運(yùn)行。

通過將后端服務(wù)打包成Docker映像，并且可以隨時將其部署并擴(kuò)展到服務(wù)器集群，我們應(yīng)該能夠迅速適應(yīng)變化。我們可以添加新的玩家功能，當(dāng)流量增加時進(jìn)行擴(kuò)容，并快速推出更新和修復(fù)程序。在考慮將容器內(nèi)的服務(wù)部署到生產(chǎn)環(huán)境時，需要解決三個主要問題：

1. 給定一個主機(jī)集群，如何選擇一組特定的主機(jī)來接收一組容器？
2. 這些容器實(shí)際上是如何在遠(yuǎn)程主機(jī)上啟動的？
3. 容器“死機(jī)（或者關(guān)機(jī)）”時會發(fā)生什么？

這三個問題的答案是，我們需要一個調(diào)度程序——一種在服務(wù)集群層面運(yùn)行并執(zhí)行我們的容器策略的服務(wù)。調(diào)度程序是維護(hù)集群、確保容器在正確的位置運(yùn)行，以及在容器退出時重新啟動它們的關(guān)鍵組件。

例如，我們可能要啟動諸如Hextech Crafting之類的服務(wù)，該服務(wù)需要六個容器實(shí)例來處理其負(fù)載。調(diào)度程序負(fù)責(zé)查找具有足夠內(nèi)存和CPU資源以支持這些容器的主機(jī)，并執(zhí)行使這些容器運(yùn)行所需的任何操作。如果這些服務(wù)器之一發(fā)生故障，調(diào)度程序還負(fù)責(zé)為受影響的容器查找替換主機(jī)。

當(dāng)我們決定使用調(diào)度程序時，就快速進(jìn)行原型設(shè)計，以便了解容器化服務(wù)在生產(chǎn)中是否適合我們。此外，我們需要確保現(xiàn)有的開放源代碼選項可以在目前的環(huán)境中運(yùn)行，或者確保維護(hù)人員愿意接受我們的調(diào)整。

為什么要自己寫

在開始編寫Admiral調(diào)度程序之前，我們調(diào)查了現(xiàn)有集群管理器和調(diào)度程序的狀況。都有誰在Docker主機(jī)集群之間調(diào)度容器，它們是如何做到的？它們的技術(shù)還能解決我們的問題嗎？

在最初的研究中，我們調(diào)研了一些項目：

Mesos + Marathon

• 這些技術(shù)已經(jīng)相當(dāng)成熟并且可以大規(guī)模使用，但是安裝起來卻復(fù)雜且棘手，這使得它們難以進(jìn)行嘗試和評估。
• 當(dāng)時，它們對容器的支持還非常有限，沒有跟蹤Docker的快速發(fā)展，并且在Docker生態(tài)系統(tǒng)中表現(xiàn)不佳。
• 它們不支持容器組（pods）——我們認(rèn)為需要將sidecar容器與許多服務(wù)捆綁在一起（附注：sidecar是容器日志的一種模式）。

LMCTFY => Kubernetes

• Kubernetes剛剛從LMCTFY演變而來，盡管它看起來很有希望，但尚不清楚它的未來發(fā)展是否能滿足我們的需求。
• Kubernetes還沒有一個約束系統(tǒng)可以像我們需要的那樣進(jìn)行容器放置。

Fleet

• Fleet是后來開放源代碼的，當(dāng)時還不夠成熟。
• Fleet似乎更專注于系統(tǒng)服務(wù)的部署，而不是常規(guī)應(yīng)用程序服務(wù)。

我們還原型化了一個小型命令行工具，該工具可通過REST與Docker API進(jìn)行通信，并且成功演示了如何使用此工具來協(xié)調(diào)部署。然后，我們決定繼續(xù)編寫自己的調(diào)度程序。

我們借鑒了研究過的系統(tǒng)的一些最佳功能，包括Kubernetes的Pods和Marathon的約束系統(tǒng)背后的核心思想。我們的愿景是跟蹤這些系統(tǒng)的體系結(jié)構(gòu)和功能，在可能的情況下影響它們，并最終嘗試在將來與其中之一融合。

Admiral概述

在創(chuàng)建了一個基于JSON的基礎(chǔ)部署元數(shù)據(jù)語言（我們稱為CUDL，ClUster描述語言）之后，我們開始編寫Admiral。CUDL成為Admiral在其REST API中使用的語言，兩個主要組成部分如下：

• 集群——一組Docker主機(jī)。
• 打包（Packs）——啟動一組一個或多個容器所需的元數(shù)據(jù)。類似于Kubernetes Pod加Replication控制器。

集群和打包具有兩個不同的方面：spec和live。每個方面都代表對容器生命周期不同階段的描述。

Spec，表示元素所需的狀態(tài)

• 從某些外部事實(shí)來源（如來源控制）發(fā)布到Admiral
• 一經(jīng)交付給Admiral便一成不變
• Spec集群和主機(jī)描述了集群中可用的資源
• Spec打包描述了運(yùn)行服務(wù)所需的資源、約束和元數(shù)據(jù)

Live，表示元素已實(shí)現(xiàn)的狀態(tài)

• 鏡像實(shí)際的運(yùn)行對象
  • Live集群和主機(jī)鏡像正在運(yùn)行的Docker守護(hù)程序
  • Live打包鏡像正在運(yùn)行的Docker容器組
• 通過與Docker守護(hù)進(jìn)程通信，實(shí)現(xiàn)可恢復(fù)性

Admiral用Go編寫，并且在生產(chǎn)數(shù)據(jù)中心中運(yùn)行時，被編譯并打包到Docker容器中。Admiral有幾個內(nèi)部子系統(tǒng)，其中大部分如下圖所示。

從用戶的角度來看，與Admiral的交互是通過其提供的admiralctl命令行工具進(jìn)行的，該工具通過REST API與Admiral進(jìn)行通信。借助admiralctl，用戶可以通過標(biāo)準(zhǔn)指令訪問Admiral的所有功能：POST新的Spec打包以進(jìn)行調(diào)度，DELETE舊包（Packs），以及GET當(dāng)前狀態(tài)。

在生產(chǎn)過程中，Admiral將使用Hashicorp的Consul存儲Spec狀態(tài)，定期對其進(jìn)行備份，以防發(fā)生災(zāi)難性故障。萬一完全丟失數(shù)據(jù)，Admiral還能使用從各個Docker守護(hù)程序檢索到的Live狀態(tài)中的信息，來部分重建其Spec狀態(tài)。

協(xié)調(diào)器（reconciler）屬于Admiral的核心，是驅(qū)動調(diào)度工作流程的關(guān)鍵子系統(tǒng)。協(xié)調(diào)器會周期性地將實(shí)際的Live狀態(tài)與所需的Spec狀態(tài)進(jìn)行比較，并且在出現(xiàn)差異時，調(diào)度所需的操作，以便將Live狀態(tài)恢復(fù)正常。

Live狀態(tài)及其驅(qū)動程序包通過緩存Live主機(jī)和容器狀態(tài)，并通過其REST API提供與集群主機(jī)上所有Docker守護(hù)程序的通信，來支持協(xié)調(diào)器。

深度調(diào)度

Admiral的協(xié)調(diào)器可對Spec打包進(jìn)行操作，有效地將其轉(zhuǎn)換為Live打包。在將Spec打包提交給Admiral時，協(xié)調(diào)器將創(chuàng)建容器并使用Docker守護(hù)程序啟動它們。正是通過這種機(jī)制，協(xié)調(diào)器實(shí)現(xiàn)了我們前面所述的最重要的兩個高級調(diào)度目標(biāo)。當(dāng)協(xié)調(diào)器收到Spec打包時，它將：

1. 評估集群的資源和打包的約束，為容器找到合適的主機(jī)。
2. 知道如何使用Spec中的數(shù)據(jù)在遠(yuǎn)程主機(jī)上啟動容器。

讓我們看一下在Docker主機(jī)上啟動容器的示例。在此示例中，我們將使用本地Docker守護(hù)程序作為Docker主機(jī)，并與Admiral服務(wù)器的本地實(shí)例進(jìn)行交互。

首先，我們使用“admiral pack create <cluster name> <pack file>”命令啟動一個打包。此命令針對特定集群，并將Spec打包的JSON 提交到Admiral服務(wù)器。

你能注意到，幾乎在剛剛運(yùn)行命令后，容器就已經(jīng)在我的機(jī)器上啟動。這個容器是使用我的打包文件中的參數(shù)啟動的，如下所示：

接下來，在調(diào)用“admiral pack create”之后，我們可以使用“show”命令來查看Admiral創(chuàng)建的Live打包。這里的命令是“admiral pack show <cluster name> <pack name>”。

最后，通過點(diǎn)擊容器中的服務(wù)，我們可以驗證打包是否正常工作。使用來自“admiral pack show”命令的信息，我們可以通過一個簡單的curl來拼出我們的服務(wù)：

在Admiral內(nèi)部，協(xié)調(diào)器始終處于運(yùn)行狀態(tài)，以確保集群的Live狀態(tài)始終與所需的Spec狀態(tài)相匹配。這樣，當(dāng)容器由于崩潰而失敗并退出，或者由于硬件故障而導(dǎo)致整個服務(wù)器不可用時，我們還可以進(jìn)行恢復(fù)業(yè)務(wù)。協(xié)調(diào)器努力確保狀態(tài)匹配，以便玩家永遠(yuǎn)不會遇到中斷問題。此功能解決了我們前面提到的第三個，也是最后一個問題：當(dāng)容器意外退出時，我們可以快速恢復(fù)，并且將影響控制到最小。

下面將展示通過“admiral pack create”命令啟動的現(xiàn)有容器。然后，我將終止該容器，并停止其執(zhí)行。在幾秒鐘內(nèi)，協(xié)調(diào)器啟動了一個新的容器（具有不同的ID），因為它意識到Live狀態(tài)與Spec狀態(tài)不匹配。

資源和約束

為了最好地分配容器，調(diào)度程序必須洞悉主機(jī)集群。解決此問題有兩個關(guān)鍵組件：

資源——服務(wù)器可用資源的一種表示形式，包括內(nèi)存、CPU、I/O，以及網(wǎng)絡(luò)等其他資源。

約束——打包隨附的一組條件，可為調(diào)度程序提供有關(guān)可放置打包的限制的詳細(xì)信息。例如，我們可能要放置一個打包實(shí)例：

• 在整個集群中的每個主機(jī)上
• 在名為“myhost.riotgames.com”的特定主機(jī)上
• 在集群里每個標(biāo)記的區(qū)域中

通過在主機(jī)上定義資源，我們使調(diào)度程序可以靈活地決定將容器放置在何處。

通過在打包集（packs）上定義約束，我們可以限制調(diào)度程序的選擇，以便將特定的模式強(qiáng)制應(yīng)用到集群中。

結(jié)論

對于Riot而言，Admiral是我們部署技術(shù)不斷發(fā)展的重要組成部分。通過利用Docker和調(diào)度系統(tǒng)的功能，我們能夠比以前更快地向玩家交付后端功能。

在本文中，我們深入研究了Admiral的一些功能，并展示了如何在一組機(jī)器集群之間調(diào)度容器。就像Jonathan在他的第一篇文章中提到的那樣，開源世界已經(jīng)迅速轉(zhuǎn)向非常相似的模型。展望未來，我們將轉(zhuǎn)移Admiral的工作，并專注于部署DC/OS，它已成為調(diào)度容器工作負(fù)載的領(lǐng)先的開源應(yīng)用程序之一。

如果你經(jīng)歷了類似的旅程，或者覺得自己有話要補(bǔ)充，非常歡迎與我們?nèi)〉寐?lián)系。

---

更多“揭秘LOL”系列文章
● 揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨踏上部署多樣性的征程

---

關(guān)注微信：TF中文社區(qū)

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

當(dāng)前文章：揭秘LOL背后的IT基礎(chǔ)設(shè)施丨關(guān)鍵角色“調(diào)度”-創(chuàng)新互聯(lián)
本文來源：http://muchs.cn/article6/dspoog.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站導(dǎo)航、網(wǎng)站維護(hù)、虛擬主機(jī)、自適應(yīng)網(wǎng)站、網(wǎng)站制作、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)