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

創(chuàng)新互聯(lián)公司是專業(yè)的愛輝網(wǎng)站建設(shè)公司，愛輝接單;提供網(wǎng)站建設(shè)、網(wǎng)站制作,網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進行愛輝網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作! 作者：Nicolas Tittley和Ala Shiban（文章來源：Riot Games）譯者：TF編譯組

這個長系列的文章，探討并記錄了Riot Games如何開發(fā)、部署和運營后端基礎(chǔ)架構(gòu)的歷程。我們是Riot 開發(fā)體驗團隊的軟件架構(gòu)師兼產(chǎn)品經(jīng)理Nicolas Tittley和Ala Shiban。我們團隊負責幫助Riot開發(fā)人員在玩家所處的任何地方構(gòu)建、部署和運營游戲，同時專注于云無感（cloud-agnostic）平臺，這些平臺使游戲的發(fā)行和運營變得更加輕松。 在過去的兩年前的一篇文章中，Maxfield Stewart介紹了有關(guān)開發(fā)生態(tài)系統(tǒng)，以及當時使用的許多工具。這里我們將更新一些最新的內(nèi)容，包括面臨的新挑戰(zhàn)，如何解決問題，以及我們從中學到的東西。

快速回顧

我們強烈建議您回過頭閱讀以前的文章，但是如果您想直接閱讀本文，這里有一個超級精簡版本來幫您趕上進度。 Riot使用裸金屬和云基礎(chǔ)架構(gòu)的組合來在全球范圍內(nèi)運行后端系統(tǒng)。這些后端系統(tǒng)被分散到不同的地理位置，基于完全不同的部署，運行著允許玩家與LOL《英雄聯(lián)盟》互動的整套服務(wù)。像大多數(shù)游戲的后端系統(tǒng)一樣，LOL后端開始時作為一個整體，由專門的運營團隊來負責運營。隨著時間的推移，Riot逐漸擁抱了DevOps實踐和基于微服務(wù)的體系架構(gòu)。 本系列的第一篇文章做了詳細介紹，為了幫助我們的開發(fā)人員更快地服務(wù)玩家，Riot大量依賴于Docker容器這種打包服務(wù)，并開始在集群調(diào)度程序中運行它們。直到 最近一篇文章，討論了為實現(xiàn)此目的而使用的許多工具。

運行效果如何？

非常牛，但，痛并快樂著。 在上篇文章發(fā)表之時（ 編者按：發(fā)表時間為2017年12月 ），我們運營著5000多個生產(chǎn)容器。這個數(shù)字并沒有停止增長，今天，僅在Riot自主運營的區(qū)域（Riot-operated regions），我們就運行了14,500多個容器。Riot的開發(fā)人員喜歡為玩家創(chuàng)造新事物，當他們越容易編寫、部署和運營服務(wù)，他們就越能創(chuàng)造出令人興奮的新體驗。 開發(fā)團隊以真正的DevOps方式，擁有并負責他們的服務(wù)。他們創(chuàng)建了工作流來部署、監(jiān)視和運營那些服務(wù)，當他們找不到所需的東西時，就干脆自己發(fā)明再造。對于開發(fā)人員來說，這是一個非常自由的時期，他們很少遇到無法自行解決的問題。 但慢慢地，我們開始注意到一些令人擔憂的趨勢。每個月的QA和負載測試環(huán)境變得越來越不穩(wěn)定。我們不得不花費更多的時間，來查找錯誤的配置或過時的依賴關(guān)系。這些孤立的事件并不是關(guān)鍵，但總的來說，它們耗費了團隊很多時間和精力——我們更愿意將其花費在創(chuàng)造玩家價值上。 更糟糕的是，在非Riot自主運營的分片區(qū)域（non-Riot shards），不僅開始出現(xiàn)類似的困難，而且還爆出一系列其它問題。合作伙伴們必須與越來越多的開發(fā)人員進行對接，并采用越來越多的微服務(wù)，每種微服務(wù)都有不同的方式，彼此各不一樣。現(xiàn)在，運營人員必須比以往更加努力，以創(chuàng)造出有效且穩(wěn)定的分片區(qū)域。在這些非Riot自主運營的分片區(qū)域，問題發(fā)生率要高得多，直接原因就是微服務(wù)的實時版本不兼容，或者其它類似的跨界問題。

Riot的DevOps現(xiàn)狀

在討論如何解決打包、部署和運營之前，讓我們花一點時間來探討Riot的運行環(huán)境。這些都不是Riot所獨有的，但所有這些細節(jié)的重疊，都說明了我們是如何組織起來，以便為所有玩家提供價值的。 開發(fā)者模式

---

Riot的工程師們喜歡自己建造東西！為了幫助他們做到這一點，我們采用了強大的DevOps思維方式。團隊建立并擁有了自己的后端服務(wù)，確保對其提供支持，并在服務(wù)表現(xiàn)不如預期時進行分流?？偟膩碚f，Riot工程師很高興能夠?qū)崿F(xiàn)快速迭代，也很樂意對自己的實時服務(wù)負責。這是一個非常標準的DevOps設(shè)置，Riot并沒有在任何方面逆勢而上。 有狀態(tài)分片模式

---

由于歷史原因、規(guī)模性問題，以及法律方面你的因素，Riot產(chǎn)品的后端系統(tǒng)按照分片的方式進行組織。其中，生產(chǎn)分片通常在地理位置上靠近目標受眾。這樣做有許多好處，包括改進的延遲問題，更好的匹配性，有限的故障域，以及清晰的非高峰時間窗口（可在其中執(zhí)行維護操作）。當然，我們還在內(nèi)部和外部運行著許多開發(fā)和QA分片，例如《英雄聯(lián)盟》公開測試服（PBE）。  
運營模式

---

這是事情變得更加復雜的地方。盡管Riot是開發(fā)者，但出于合規(guī)性和專有技術(shù)的原因，我們與一些本地運營商合作以提供一些服務(wù)分片。實際上，這意味著Riot的開發(fā)人員必須打包分片的每個組件，將其交付給運營人員，并指導他們?nèi)绾尾渴?、配置和運營所有分片。Riot的開發(fā)人員不會自己去操作、訪問甚至查看這些分片。（編者按：文中的分片邏輯可以理解成分塊分區(qū)域的定義）

迭代解決方案

嘗試1-新的聯(lián)盟部署工具

---

我們第一次嘗試改善情況，就采取了全新的方法，嘗試利用開源組件和最少Riot定制功能，來推進Riot的部署和運營工作。盡管這項工作成功地部署了完整的《英雄聯(lián)盟》分片，但工具的設(shè)計方式并沒有達到開發(fā)人員和運營人員的期望。團隊表達了對工具的不滿——這種工具被證明對運營來說太難采用，對開發(fā)者來說太受約束。 因此，在第一個分片部署后，我們就做出了痛苦的決定——讓這些工具退役。這看起來好像很激進，但由于所有團隊仍然擁有自己維護的部署系統(tǒng)并且尚未完全過渡，因此我們能夠快速淘汰新的工具。 嘗試2-更多流程

---

由于第一次嘗試并不如預期的成功，我們轉(zhuǎn)向傳統(tǒng)，通過添加流程來達到要求。廣泛的溝通，明確的發(fā)布日期，文檔化的流程，變更管理會議和儀式，以及永遠存在的電子表格，在某種程度上取得了一點點進展，但始終感覺不佳。團隊喜歡他們的自由DevOps，巨大的變化量和變化速度，都使他們的工作更加繁重。盡管合作伙伴的情況有所改善，但我們?nèi)晕催_到所期望的運營水準。 嘗試3-元數(shù)據(jù)

---

我們決定嘗試另一種方法。之前我們一直將開發(fā)人員作為工具的主要受眾，現(xiàn)在則開始研究針對于合作伙伴的運營人員，部署/運營系統(tǒng)將如何工作。我們精心設(shè)計了一種工具，允許開發(fā)人員向其Docker容器的打包微服務(wù)添加標準化元數(shù)據(jù)，例如所需的配置和擴展特性。這帶來了進步，運營人員可以采用更加標準化的方式來理解所需的服務(wù)配置和部署特性，并且在日常運營中減少對開發(fā)人員的依賴。 此時，本地和合作伙伴運營站點的故障率、事件率和額外的停機時間都有所改善，但我們?nèi)匀活l繁遇到部署和運營故障，這些故障本來都是可以避免的。 嘗試4-Riot的應用程序和環(huán)境模式

---

我們最終采用了一種新方法，將關(guān)注點從個人服務(wù)轉(zhuǎn)移到了整個產(chǎn)品。我們創(chuàng)建了一個高級別的聲明性規(guī)范，以及可對其執(zhí)行操作的工具集，讓規(guī)范和工具變得與眾不同。在詳細介紹之前，我們先來看一下前三次的嘗試中出了什么問題。

反思錯誤之處

部署和運營的是產(chǎn)品，而非服務(wù)

---

盡管擁抱DevOps和微服務(wù)給我們帶來了許多好處，但它創(chuàng)建了一個危險的反饋環(huán)路。開發(fā)團隊創(chuàng)建微服務(wù)，對其進行部署、運營，并對其性能負責。這意味著他們?yōu)樽约簝?yōu)化了日志、度量標準和流程，并且通常很少考慮其服務(wù)能否為其他人所理解，包括沒有開發(fā)背景甚至工程能力的人。 隨著開發(fā)人員創(chuàng)建出越來越多的微服務(wù)，運營整體產(chǎn)品變得非常困難，并導致越來越多的失敗。最重要的是，Riot的流動團隊結(jié)構(gòu)，使一些微服務(wù)的所有權(quán)變得不清晰，很難在分流時搞清楚應該與誰聯(lián)系，從而導致出現(xiàn)很多屬性錯誤的頁面。越來越多的異構(gòu)微服務(wù)、部署流程和組織變更，使得合作伙伴地區(qū)的運營團隊不知所措。 搞清楚“為什么”

---

我們檢查了Riot運營區(qū)域和非Riot運營區(qū)域的故障，并將故障頻率的差異提煉為一項關(guān)鍵的觀察結(jié)果： 允許不連續(xù)的變更流進入分布式系統(tǒng)最終將導致可預防的事件。 當團隊希望跨邊界進行協(xié)調(diào)時，就會開始發(fā)生故障，因為依賴關(guān)系需要將發(fā)布與多個更改捆綁在一起。團隊要么使用人工流程來創(chuàng)建發(fā)布周期，通過項目管理儀式協(xié)調(diào)發(fā)布，要么臨時發(fā)布較小規(guī)模的發(fā)布更改，導致團隊在找出兼容版本的過程中陷入混亂。 兩者各有其優(yōu)缺點，但是在大型組織中往往會崩潰。想象一下，數(shù)十個團隊需要以協(xié)調(diào)的方式，連續(xù)交付代表共享產(chǎn)品的數(shù)百個微服務(wù)，并且允許這些微服務(wù)使用不同的開發(fā)實踐。更糟的是，對于合作伙伴來說，嘗試應用這些流程非常困難，他們的操作人員缺乏關(guān)于各個部分如何組合起來的上下文。

新解決方案：Riot的應用程序和環(huán)境模型

鑒于先前的嘗試未能產(chǎn)生預期的結(jié)果，我們決定通過創(chuàng)建一個自用固有對的（opinionated）聲明性規(guī)范來消除部分狀態(tài)操縱，該聲明性規(guī)范可以捕獲整個分布式產(chǎn)品——環(huán)境。環(huán)境包含完全指定、部署、配置、運行和運營一組分布式微服務(wù)所需的所有聲明性元數(shù)據(jù)，這些微服務(wù)共同代表一種產(chǎn)品，并且是完整且不變的版本。我們之所以選擇“環(huán)境”這個名字，是因為它是Riot 最不會過度使用的一個詞。命名實在是一件難事。 隨著游戲《符文之地傳奇》LOR的發(fā)布，我們證明了可以描述整個的微服務(wù)游戲后端（包括游戲服務(wù)器），并使其在Riot自主運營地區(qū)以及全球合作伙伴的數(shù)據(jù)中心中，作為產(chǎn)品進行部署、運行和運營。我們還展示了實現(xiàn)這一目標的能力，同時改善了已經(jīng)廣受喜愛的DevOps方法的優(yōu)勢。 對什么進行規(guī)定描述（OPINIONATED ON WHAT）

---

該規(guī)范描述了服務(wù)捆綁包或環(huán)境之間的層次關(guān)系。  
捆綁到環(huán)境規(guī)范中的應用程序規(guī)范
聲明性與高等級 聲明性規(guī)范的好處之一是它易于操作。對于合作伙伴的運營人員，他們的其中一個困難，就是無法理解、調(diào)整和潛在地自動化整個游戲后端的部署方式。規(guī)范的聲明性性質(zhì)，意味著它不需要工程師具有腳本或編程專業(yè)知識，就可以對規(guī)范中的大多數(shù)內(nèi)容進行更改。 保持規(guī)范的高等級，有助于將游戲后端的定義與基礎(chǔ)實現(xiàn)脫鉤。這使我們能夠在對游戲工作室影響最小的情況下，從名為Admiral的內(nèi)部編排器/調(diào)度程序，遷移到基于Mesos的調(diào)度程序，以及考慮遷移到Kubernetes。它還使我們的合作伙伴運營人員可以在需要時交換其基礎(chǔ)架構(gòu)組件。例如，它允許運營人員可以使用不同的指標聚合系統(tǒng)，而不需要更改微服務(wù)工具。 不可變與版本化 我們發(fā)現(xiàn)，要在快速發(fā)展的DevOps世界中有效部署和運營，使用共享語言來引用服務(wù)和環(huán)境至關(guān)重要。版本控制服務(wù)和環(huán)境及其關(guān)聯(lián)的元數(shù)據(jù)，使我們能夠確保所有位置都部署了正確的版本。它使我們的合作伙伴運營人員可以確定地知道正在運行哪個版本，并且回傳給我們。此外，當應用于整個環(huán)境時，它提供了一組眾所周知的服務(wù)，可以對其進行質(zhì)量檢查并標記為“好”。這種捆綁消除了在向合作伙伴傳達新版本時遺失依賴項的任何可能性。 使這些版本不可變，可以確保我們維持這種通用語言。當相同版本的服務(wù)被部署在兩個不同的分片中，我們現(xiàn)在也可以確定它們是完全相同的。 專注于運營 鑒于我們的目標是提高合作伙伴運營人員服務(wù)玩家的水平，我們很快意識到，部署軟件只是第一步。了解如何對實時系統(tǒng)進行分類、運營和維護，是同樣重要的事情。 從歷史上看，我們非常依賴于運行手冊。手冊由開發(fā)人員維護，并取得了不同程度的成功，他們記錄了從必需的配置值到高等級體系架構(gòu)的所有內(nèi)容。為了使合作伙伴運營人員具備配置和操作每種服務(wù)所需的全部知識，我們決定將這些運行手冊中包含的盡可能多的信息帶到服務(wù)規(guī)范的最前面。這大大減少了合作伙伴地區(qū)投入新服務(wù)的時間，并確保他們在微服務(wù)更新時被告知所有重要變化。 如今，合作伙伴運營人員可以使用該規(guī)范來了解有關(guān)操作元數(shù)據(jù)的信息，包括所需/可選配置、擴展特性、維護操作，重要指標/警報定義、部署策略，服務(wù)間依存關(guān)系，以及越來越多的其它有用信息。 處理分片差異

---

當然，分片不是彼此完全相同的副本。盡管我們希望使它們盡可能地接近，但總有一些配置必須有所不同。數(shù)據(jù)庫密碼、支持的語言、擴展參數(shù)，以及特定的調(diào)整參數(shù)必須隨每個分片而變化。為了支持該模式，我們的工具使用分層的覆蓋系統(tǒng)部署環(huán)境規(guī)范，使運營人員可以專門化特定的部署，同時仍然知道它們都源自已知的良好版本。讓我們看看它是如何工作的！ 應用案例

---

一個簡單的游戲后端可以包括兩個環(huán)境，一個用于游戲服務(wù)器，另一個用于元游戲服務(wù)（排行榜，匹配系統(tǒng)等）。元游戲環(huán)境由多種服務(wù)組成：排行榜、匹配系統(tǒng)、比賽歷史等等。每個服務(wù)都包含一個或多個Docker映像，從概念上講，它們等效于Kubernetes容器。對于所有環(huán)境，相同的層次結(jié)構(gòu)都是正確的，并且從哲學上講，每一個環(huán)境都毫無例外地封裝了在任何受支持的基礎(chǔ)架構(gòu)或云上部署、運行和運營的游戲后端所需的一切，及其所有的依賴項。 該規(guī)范還包括運行和運營整個環(huán)境所需的所有元數(shù)據(jù)。不斷增長的集合包括配置、機密、指標、警報、文檔、部署及rollout策略、入站網(wǎng)絡(luò)限制，以及存儲、數(shù)據(jù)庫和緩存要求。 下面我們有一個示例，演示在兩個區(qū)域中進行兩個假設(shè)的游戲分片部署。您可以看到它們都由元游戲環(huán)境和游戲服務(wù)器環(huán)境組成。在歐洲分片中的游戲服務(wù)器產(chǎn)品環(huán)境，落后于美國分片中的同類游戲環(huán)境。這為游戲和運營團隊提供了描述和比較不同游戲分片部署的通用語言。每個環(huán)境中不斷增加的服務(wù)數(shù)量可以保持簡單性，從而可以可靠地部署數(shù)十個分片。 游戲分片部署示例
我們的下一步：延遲感知調(diào)度

---

我們希望能夠描述服務(wù)之間的預期和可接受的延遲，并使工具針對基礎(chǔ)區(qū)域和較低級別的PaaS服務(wù)進行優(yōu)化，使其能夠滿足這些需求。這將導致某些服務(wù)位于同一個機架、主機或云區(qū)域中，而不是允許它們分布在其它服務(wù)中。 由于游戲服務(wù)器和支持服務(wù)的性能特點，這件事與我們高度相關(guān)。Riot已經(jīng)是一家多云公司，有我們自己的數(shù)據(jù)中心，也有AWS以及合作伙伴的云，但是我們依靠靜態(tài)設(shè)計的拓撲。紙牌游戲和射擊游戲具有不同的配置文件，不必針對一、兩種情況的優(yōu)化進行手工拓撲，從而節(jié)省了工程師們的時間，使他們可以專注在游戲上面。

最后的話

我們在運行游戲過程中面臨著穩(wěn)定性下降的問題，主要是來自合作伙伴經(jīng)營的游戲分片。工具開發(fā)團隊捆綁了開源部署工具，并將元數(shù)據(jù)添加到了容器中，而游戲團隊則實施了集中發(fā)布流程。這些方法可以解決癥狀，但不能解決導致問題的根本原因，這意味著我們未能達到目標水準。 我們最終采用的解決方案引入了一個新規(guī)范，該規(guī)范捕獲了整個游戲后端的所有拓撲、層次結(jié)構(gòu)和元數(shù)據(jù)及其所有依賴項。這種方法之所以有效，是因為它帶來了綁定容器的一致的版本發(fā)布，它們之間交互方式的依賴關(guān)系，以及啟動和操作整個游戲所需的所有支持元數(shù)據(jù)。而不可變性帶來了確定性的部署和可預測的操作。 作為一個平臺團隊，我們的目標是挑選能夠產(chǎn)生良性循環(huán)的系統(tǒng)和構(gòu)建模塊，在這樣的良性循環(huán)中，功能開發(fā)工作自然會帶來易于操作的產(chǎn)品。將DevOps模式的敏捷性與易于操作的整個產(chǎn)品相結(jié)合是長期組織敏捷性的關(guān)鍵。我們的環(huán)境捆綁方法直接改善了運營指標，更重要的是提高了玩家體驗的質(zhì)量。我們很高興看到業(yè)界其他人士如何解決類似的問題。我們已經(jīng)看到了來自CNCF（云原生計算基金會）和大型云供應商（例如Microsoft開放應用程序模式規(guī)范）的想法和項目。希望其中一些項目能夠取代我們自己制定的規(guī)范，并朝著全行業(yè)解決方案邁進。 在以后的文章中，我們還將更詳細地探討Riot規(guī)范，介紹示例，并討論設(shè)計中的權(quán)衡以及Riot特定的快捷方式。 謝謝閱讀！如果您有任何疑問，非常歡迎與我們?nèi)〉寐?lián)系。

---

·END·

更多“揭秘LOL”系列文章

• 揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨踏上部署 多樣性的征程

• 揭秘LOL背后的IT基礎(chǔ)設(shè)施丨關(guān)鍵角色“調(diào)度”

• 揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨SDN解鎖新基礎(chǔ)架構(gòu)

• 揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨基礎(chǔ)設(shè)施即代碼

• 揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨微服務(wù)生態(tài)系統(tǒng)

• 揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨開發(fā)者“打野”工具能做什么？
  

---

分享標題：揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨產(chǎn)品而非服務(wù)-創(chuàng)新互聯(lián)
本文路徑：http://chinadenli.net/article12/cdhhgc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供標簽優(yōu)化、服務(wù)器托管、面包屑導航、網(wǎng)站改版、外貿(mào)建站、ChatGPT

廣告

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