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

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

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

快速回顧

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

運(yùn)行效果如何？

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

Riot的DevOps現(xiàn)狀

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

---

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

---

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

---

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

迭代解決方案

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

---

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

---

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

---

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

---

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

反思錯(cuò)誤之處

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

---

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

---

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

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

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

---

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

---

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

---

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

---

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

最后的話

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

---

網(wǎng)頁(yè)名稱：揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨產(chǎn)品而非服務(wù)-創(chuàng)新互聯(lián)
分享路徑：http://weahome.cn/article/cdhhgc.html