講師介紹

林香鑫，網易游戲團隊負責人。2014年加入網易游戲，目前任網易游戲技術中心平臺服務組團隊負責人、技術專家，長期負責運維開發方向的工作，當前主要負責 CMDB 和配置管理、流程引擎、交付平臺、基礎組件和工具等研發管理工作。

一、應用交付形態

1、應用交付

大家對應用交付都很熟悉，游戲應用交付簡單來說就是將游戲代碼分發到服務器上對外提供服務，然后玩家通過客戶端連接，使玩家能夠順利進入體驗游戲。

應用交付這一過程說起來簡單，但在準備過程中，需要運維同學完成許多工作。例如資源管理、配置管理、多環境需求、面向游戲的業務運維。游戲的業務運維與其它類型應用的業務運維有很大區別，這也是我們在設計整套機制時遇到的問題，下文中的許多案例也會圍繞這一點展開。

游戲的發布和運維具有特殊性，例如游戲會強調開服、關服時間，可能會對整個資源的交付時間以及開服時效有較高的要求。除此之外，游戲本身是一個交互式的服務，它可能會影響玩家的體驗，所以對于日常服務運維過程中的問題排查，也會有較高的時間要求。

2、應用交付形態

在服務交付的過程中，我們都用什么工具或者手段來解決上文中提到的問題呢？

首先，shell腳本大家都很熟悉，在早期，運維同學會用這種方式完成比較簡單的部署。之后逐漸用較為規范化的流程工具將日常的運維流程串聯起來。在這一過程中，我們內部誕生了一個被稱為Aladdin的自動化系統，它滿足了現階段大量游戲的自動化運維需要。后來隨著云原生的演進，業界也逐漸出現了一些資源編排技術，這一階段我們做過一些簡單的嘗試，但并未持續太久。

最后我們直接使用了以應用為中心的編排方式，在多環境下實現快速應用交付。在社區中，比較有代表性的是叫KubeVela的開源產品，在我們內部則是通過一個叫Atlasx的產品實現了一套應用編排機制。

在上圖整個過程中，自動化程度是逐步提高的。前兩個階段自動化程度提高體現在工具或技術上，步入資源編排或應用編排之后，自動化體現在了基礎設施是否可編程，甚至業務邏輯是否可編程。與前面兩個階段相比，后面兩個階段更強調整個應用編排的可編程能力，下面的分享我將圍繞這一內容展開。

二、問題和解決方案

1、面臨的挑戰

上文中提到我們內部已經有一個大型的系統去承載標準化的流程運轉，那么我們為什么還要去實現可編程能力呢？

如果大家經常玩游戲或進入過網易游戲官網的話，可以關注到僅頁面展示的可能就有近百個游戲，雖然這些游戲看上去大同小異，但其實不然。例如有的游戲可能走國內IDC部署，也有可能走海外發行， 有可能是滾服，也有可能是單一服，甚至還有之前某一階段出現的全球服，這些差別使我們的游戲運維存在很大差別。

這些差別首先體現在異構性上，一個游戲會因為引擎的不同導致其架構甚至業務類型的不同，例如制作頁游經常選擇滾服這一類型，這就意味它的管理模式也會不同。

上文中提到有的游戲走國內IDC部署，有的則走海外發行，我們除了自身私有云的構建，海外發行的游戲還會用上公有云，例如AWS、GCP等，這導致了我們的運維人員在資源準備或游戲部署的過程中，會面臨基礎設施的異構性問題。

除異構性外，管理的多樣性也是一個問題。我們每天面對的資源數量極其龐大，僅僅一個計算資源、網絡資源、存儲資源拆分出來，我們就需要面對許多的實體，其中還未包括一些服務本身系統配置的維護。再回到運維操作本身，游戲運維操作會更復雜，這也是上文中提到游戲運維可能比傳統業務運維更復雜的原因。根據我們的不完全統計，每個SRE在完成一些日常工作的過程中可能會涉及到100多個操作，這給運維工作帶來了許多問題。

于是，我們開始思考一個問題，如果圍繞像圖中這樣一個游戲架構，人工重復部署100次，能保證這100次部署出的游戲服是等價的嗎？

在過去我們無法回答，因為我們在一個游戲服交付過程中，不可避免會出現問題，那么原因是什么呢？因為這些事情都是人為進行的，人的能力、狀態、知識背景等都會影響人的行為，導致其最終的交付成果不同。

2、應用交付的目標

人無法像函數式編程一樣，在接收同樣的輸入后，執行固定的步驟，輸出同樣的結果。但是業務層面又要求不論何人在何時何地部署、部署多少次，都能得到同樣的游戲服。因為對玩家來講，他感受的是游戲服務的體驗，我們不可能給玩家提供一個差異性非常高的游戲服務，導致可能玩家在體驗時出現非常卡頓這種不好的體驗。

我們的目標是消除這種差異性，所以我們最終要通過一些技術化手段提供標準化、統一化的應用，我們將這一過程稱為一致性交付。

為實現這一過程，我們需要解決三方面的問題。

• 不同的環境能夠一致定義。我們需要解決環境的差異性問題。
• 不同的游戲類型能夠一致定義。我們需要有一個模型框架，能夠把我們現在所有的游戲類型以這種模型框架定義出來。
• 運維能力可描述、可管理、可插拔。上文中提到交付結果可能與人的能力、狀態有關，我們應該把這種運維經驗通過技術化或者工程化的手段積累、沉淀下來，最終做到知識驅動代替人工驅動，這也是我們整個項目的目標。

為達到上述目標，目前有兩種方案可供選擇。

3、解決方案

• 基于命令式的交付。上圖左側是我們內部的流程，這些流程都是靠人工驅動，過往經驗表明人為驅動不可能實現一致性交付。
• 基于聲明式編排交付。這一方式也更適合如今業界的發展。根據規范編寫編排文件，通過提交編排啟動服務。

但是聲明式編排的底層邏輯是整個業務可編程。那么我們是怎么做的呢？

上文中提到的人為驅動模式不僅復雜，而且多種內容交叉。我們需要通過分層將各類內容進行區分，為了使用戶得到一致性體驗，我們需要達到每一層的一致性交互。

首先我們從底層的基礎設施入手，現在不論是國內外研發，都有相應的基礎設施，它能夠為我們提供一些等價的環境能力，但是它暴露出的API服務對我們來說不一定一致，所以我們需要提供一個統一的資源訪問層，不論是對底層資源還是系統編排進行操作，它都能提供一致的資源訪問行為。

解決了基礎設施的異構性問題，面對業務架構層面的不一致，我們又是怎么做的呢？

首先我們需要識別區分現在有多少種類型或多少種架構的游戲，通過上文中提到的模型框架將其組織起來，最終體現為一份編排。有了這份編排后，基本上就可以描述定義我們需要一致性定義的內容。

而到了業務層面，不論是開發階段、測試階段，還是生產階段的任何一個操作，我們都可以基于這種編排實現它的變更，從而實現面向用戶的一致性交付體驗。

我們通過這一方式進行封裝與交付之后，不論是SRE還是游戲研發的同學，都能夠在最上層得到比較一致的體驗。

有了上述模式后，我們重塑了整個游戲服的交付過程（如下圖所示）。

首先我們要先完成游戲架構的定義，其次基于這樣的定義實現整個游戲集群的編排，然后通過上文中提到的集群創建與交付模式，完成整個游戲集群的一致性交付，最終通過拓撲圖的方式呈現整個集群的狀態信息。

4、具體實踐

接下來介紹這個過程中我們進行了哪些實踐。

1）應用可定義

首先我們對架構進行分析，到底要有哪些組成部分才能夠完成一個游戲集群的組裝。

如上圖所示，我們一個游戲集群運轉起來可能需要mongo服務，可能需要etcd服務。游戲服務本身可能有這樣一些進程，例如commander、game、world、gate。對于一個游戲集群，我們能夠把它拆解成一個個比較獨立的個體，在這一階段我們要完成對這些單一個體的定義。

2）資源可定義

以MongoDB為例，我們聲明它需要使用多少CPU，需要什么類型的、多大的磁盤，也包括它要部署在哪里，可能的shard數量、版本，通過這種方式，我們就把一個資源的定義固化。今后所有人對資源的需求都以這樣的方式去聲明，其他內容也是一樣。

大家接觸過k8s、Docker等聲明式的語言，制定一個聲明式的邏輯并不難，但其背后邏輯還是整個基礎設施的可編程能力。

那么我們整個基礎設施的可編程能力處于什么樣的階段呢？得益于網易游戲過去幾年云化與SaaS化的發展，我們內部有了一整套比較成熟的基礎設施體系，同時它又能以API的方式去提供服務，這為我們提供了很大便利。不論是云網絡、容器，還是MongoDB、MySQL、Etcd等服務，我們都實現了云化或SaaS化，所以能夠較好地對接這部分內容。

看起來所有的定義都不難，但是背后整個可編程的能力才是重點。

3）架構可定義

有了這些個體，隨意將它們組裝到一起并不能形成一個架構。從上文中的架構中我們可以看出，服務間會互相調用，底層的資源間可能也有一些固化的調用關系。

上圖中是我們實現的一個簡單的游戲架構，從中可以發現，整個游戲架構驅動起來包括許多內容，例如基礎環境、項目配置、可對外開放的端口范圍，以及網絡資源的使用與容量，這些東西也是我們在架構定義中需要去思考補齊的一部分。這背后體現出的是我們對一個應用架構模型的定義。

大家使用 K8S、Docker、Compose的定義時會發現不同，造成這種不同的原因是它們的模型定義不同，即它們的模型框架不同。所以我們為了適應自己內部的體系，我們也自己定義了一套應用聲明的模型，下圖中是架構部分。

4）運維可定義

對游戲來說，在運維工作上會遇到一些簡單的Web類服務不會遇到的問題。

例如有些游戲會開關服，這里涉及到開關網絡的動作，我們內部其實能夠把它收斂下來。通常來說，開關網絡包括幾種動作，首先是公網全部開放訪問，然后面向玩家開放連接，其次僅開放辦公網，QA可以連接游戲服做當次版本的驗證。而在close狀態下，QA和玩家都無法訪問。

但歷史經驗告訴我們，這看起來是簡單的幾個狀態之間的轉換，但要實現這些狀態背后可能會有一些關注不到的點。例如我們要求在limit狀態下禁止玩家連接，但可能因為是從open的狀態切換到limit狀態，這時外部玩家的連接狀態是沒有斷掉的。我們在這方面是踩過坑的，即我們以為進入了limit狀態，但其實這個時候玩家還在玩，對一些沒有注意到這一情況的人員，如果他是用另外一種方式，例如上文提到的命令式的方式，他可能調用API實現了狀態的切換，保證新的玩家進不來，但是原來處于連接狀態的外部玩家還可以繼續玩，這可能就導致了一個故障。

但如果我們通過聲明式的方式把這些東西收斂，將上文中提到的運維策略定義出來，例如進去limit狀態就一定會清除剩余的連接流量，這就實現了我們在運維操作上一致性。我們也已經實現了這一點。

游戲還有另一個特殊點，它是有狀態的，這導致一個進程會啟動多個端口，除了本身要去對玩家提供服務的端口外，調試代碼、進行運營操作還需要額外提供端口。如果我們像之前一樣通過人工規劃端口，其實很難保證一致性。但如果我們把它面向端口的分配定義成一個可聲明的運維操作，其實很簡單，即聲明周圍有哪些端口，可能要開多少個，通過系統本身的實現，就可以成功分配好這些端口，包括端口是否連續等都可以在這樣的運維策略中實現。

以上就是前文中提到的應用可定義、架構可定義以及運維可定義，我們是通過上述方式逐步實現的，但是我們真的把一個應用定義出來就夠了嗎？

大概在一年半前我們實現過第一版，定義出來的編排文件大概有1000多行。大家都知道一個代碼文件如果行數過多是很難維護的，改動它也容易出問題。當你面對一個1000多行編排的時候，你可能是崩潰的，所以這一版本就無法繼續了。

接下來我們進行了一些參考和調研，例如AWS針對用戶使用方面有一些原則，這里我們重點考慮一點，用戶應該考慮的是架構，而不是基礎設施。我們原來那份1000多行的版本中，包括了許多內容，這是比較繁雜的。

我們進一步了解到阿里和微軟也在推進OAM即應用開發模型，其中一個關鍵點就是區分使用者，關注點分離，另外是其運維能力能夠模塊化封裝、可管理，這與我們的目標適配，這個東西我們到底如何去實現呢？

上圖模型我們可以借鑒，但是無法套用，這與我們內部一些基礎設施的狀態有關。在這基礎上我們對該模型進行了擴展。首先是環境，還有Stack以及全局trait。擴展后，我們的游戲基本架構大約如上圖右側所示。

我們的應用實現流程如上圖，其中最復雜是OAM解釋器邏輯以及整個provider的執行邏輯，這里我們會根據前文中的架構定義，對整個編排模型做解析，然后形成后續要去執行的工作計劃。之前定義的所有組件的執行流程都會體現在里面，最終通過這種有向無環圖的方式實現整個業務流程的交付。

這種關注點分離可以給我們帶來什么呢？如果我們在Istio微服務這樣的路由轉發需求下，如果按以前我們要去理解那些純概念的話，我們需要知道gateway、VS、destinationrule怎么配置，這部分內容對于大多同學來說較難上手，但如果我們把這些內容封裝抽象形成一個基本的路由定義， 則容易很多。

還有一個更復雜的問題就是我們怎樣實現運維能力的可管理，不同環境下要求不同。

研測環境下，我們是可以直連的。我們開放了 Gate端口讓客戶端可以直連，這時候不需要配任何的端口轉發策略。但是對于某種游戲的線上環境，它可能要求集群獨享一個EIP，并通過DNAT 的方式實現訪問。有的模式可能更加特殊，例如在滾服機制下，假設我們這個量級是1萬個服務的話，IP資源肯定是不夠的。所以在這個情況下，我們要實現多集群共享EIP。

上述僅僅是運維能力上的不同，但事實上對Gate的管理是比較一致的。通過這樣一種能力的管控，我們可以明確是否需要EIP，EIP的管理模式、分配模式是什么樣子的，通過這種方式把運維能力定義出來，并且讓它能夠在這樣的配置中去管理。

最后我們將這些內容匯總，以前信息是圍繞人的，現在我們通過一份編排把這些內容都驅動了。因為所有信息都是自包含的，這就很好地跟我們整個內部的運維配置數據體系 （CMDB）實現了聯動。

其中最有價值的是關系數據。游戲群組交付之后，形成了這樣的一個業務拓撲，但是把它放到整個架構中，它僅僅是其中的一小部分。這時我們可以做許多事，例如我們通過這種方式明確我與外部依賴的MongoDB是否連通的、一個宿主如果出現數組故障是否會影響到我，還有一些報警收斂，我們都可以基于這樣的整套機制實現，目前我們在十幾二十個場景進行了落地。

三、當前成果

接下來分享一下當前的成果。

我們這套機制開始使用了近一年，當前重點項目也在逐步交接，我們能夠適應多種游戲的架構與微服務。按最保守的評估方式，我們也能夠將交付效率提高到10倍。例如從之前一個多小時，現在我們控制在5分鐘或3分鐘之內。整體的使用規模也在不斷擴張，現在達到了千級別。上圖提到的每天的發布操作頻率也證明這套機制一直在使用狀態。

四、未來展望

上文中提到的許多內容都離不開業務架構、應用模型、基礎設施及代碼這三個核心的因素。對我們來說，游戲引擎決定了業務架構。整個游戲行業在發展，引擎本身的能力也在發展，引擎發展之后，就會影響業務架構。

例如我們在做一些游戲微服務化的工作，微服務化的結果就是架構的調整或改變，架構的改變需要在應用模型上進一步拓展，但是整個應用模型離不開底層的基礎設施，依賴于整個基礎設施的可編程能力，所以這三個部分是不可分割的。這決定了我們在不同層的工作人員要聯動才能解決問題，未來我們也都會圍繞這一方面不斷去發展，從而促進我們整個游戲的發展。

這套平臺的發布，是我們針對基于OAM以及游戲上云應用管理交付使用場景的實踐。在這個過程中，我們也迭代出了一套怎么面向游戲定義模型架構的方式，目前也在持續使用中。

整個游戲運維有兩大難點，一個是狀態，一個是復雜的運維邏輯，借助整個云化與基礎設施能力的結合，我相信我們未來可以做得更好，能夠讓整個應用的開發與發布更加令人享受。?