GameLook - 《火箭聯盟》首席工程師：如何實現100萬同時在線、服務器不崩？－鑽石舞台

「點擊上方"GameLook"↑↑↑，訂閱微信」

如今，免費模式已經成為了遊戲業最主流的變現模式，它可以降低遊戲門檻，大幅提升用戶量。然而對於很多的主機來說，從付費轉向免費並不容易，除了遊戲運營方式的變化外，同樣需要大量的後端支持工作。

在此前的GDC演講中，Psyonix工作室首席在線服務工程師 Matthew Sanders講述了《火箭聯盟》從付費轉向免費之後突破100萬同時在線背後的後端支持，並詳細談到了Psyonix團隊為此做出的努力。

以下是GameLook聽譯的完整內容：

Matthew Sanders：

我是Matthew Sanders，在Psyonix工作室擔任首席在線服務工程師，之所以給出今天的分享，主要是因為我負責遊戲轉向免費模式的後端準備工作。

先來說說團隊並快速了解我們遇到的問題到有多大，Psyonix的在線服務團隊主要是做什麼的？我們負責遊戲相關的數據庫、網頁服務和一些網站，這包括一些研發活動和在線活動的執行。

什麼是免費？就和聽起來一樣，《火箭聯盟》要降價，目的是降低遊戲門檻，讓那些不想要付費玩遊戲或者支付不起遊戲購買費用的人能夠體驗到。

那麼，對後端擴容支持更多玩家就可以了，不是嗎？這個改變可能要求我們的後端支持更多的流量，自從2015年發布以來我們就很熟悉後端工作，所以免費模式的決策出來之後，我們就知道需要很大的工作量。

在今天分享的最後，我們會知道，經過了一年多的準備之後，用戶流量的確出現了大幅增加，我們已經為此做好了準備，因此保證了比較成功的重新發布。

今天的內容主要分為3個部分，我們會提到規劃和準備，其中包括新的合作關係、需要做的分析以及負載測試，第二部分我們會更細節了解規模化提升，最後，我們會分享發布經驗以及自此之後的新常態。

一、規劃與準備

我們做了大量的規劃和準備，它們占據了我們大量的時間，但這裡只分享其中一些部分。

首先，我們的分析主要是圍繞我們可以預期的是什麼，我們用了一些時間研究負載預計以了解可能會見到多大的用戶規模，還對架構進行了分析，以支持潛在問題。

接下來的合作關係部分更值得討論，我們有一些支持外包，從簡單的票務支持到與更緊密的發布支持工作，最後我們會談到負載測試以及它是如何適應這個項目的。

1.分析

通過轉向免費，我們會帶來多少新玩家？看起來似乎很難用占卜的方式得到結果，但有些技巧可以預測，最好的方式之一就是找一個與你類似的遊戲發布之後的情況。不幸的是，《火箭聯盟》是一個跨多個主機平台的火箭主題遊戲，所以想找到參照物很難。

最後，我們決定把支持的玩家數定到現有用戶的3-5倍，我們將預測數據的上限作為負載測試標準，對於負載測試，我們稍後會提及更多。

接下來是架構評估，我們該如何預測架構需求呢？我們將不同部分進行拆分，然後看每一個部分做擴容設計之後的風險，然後為這些風險做backlog，做表單的時候，我們主要針對連貫性和預覽設計，這個文檔實際上成為了復用性很高的材料，我們還給每個表單增加了peer review，我們給大多數的應用商店DLC都做了peer review，包括文檔也沒例外，我們還對源控制做了審核，以便讓我們所有的產品都可以做預覽。

每個部件的評估都是非常直接的，但我們用了一些時間才把架構評估做完，因為有很多的組件。

2.合作關係

一開始的時候，我們就確定想要最好的外部支持，我們內部並不沒有大量的工程師員工，所以我們希望尋找這方面的專家。我們發現外部專家的成本比內部員工高很多，但我們的想法是，如果他們可以讓項目研發不停下來，那麼後來的收入可以彌補這部分的開支。

我們商談的第一家合作廠商就是谷歌，我們的遊戲一直都在谷歌雲平台（Google Cloud Platform，GCP）上運行，所以已經有了支持關係並簽訂了合同，即使如此，我們在做了評估之後還是決定使用他們更多的工具，比如CRE（Customer Reliability Engineering）和GTLA（Game Title Launch Assist）。

接下來，我們希望通過一些專業工具增強內部團隊，PERCONA是MySQL方面的專家，所以用他們的支持服務是有意義的，特別是我們使用了PERCONA服務器。

Redislabs是新工具，我們在運行一些redis cluster，但沒有正式的支持，我們聯繫了Redislabs並寫信請他們報價，這需要額外的支持，但抵消了GCP很多的管理負擔，與這樣的公司合作就像是買保險，可以讓我們在遊戲發布期間最大化降低可能出現的故障率，與此同時，也給規劃和研發階段的提升帶來了珍貴的機會。

我們很快充分利用了既有的支持合作關係，並用不同的合作來解決對應的問題。比如premortem，它類似於postmortem，但更具有預測性，並讓他們分享工具使用技巧。谷歌提供的另一個支持是資源規劃與分配，我們不是一款新遊戲發布，所以在資源使用方面已經有確定的使用數據，包括不同GCP服務使用的CPU核心、內存以及硬盤。

之前提到過，我們預測的發布期間用戶量可能是現有用戶的5倍，這些資源規劃從兩個方面帶來了幫助，首先是提前獲得了配額提升，其次是可以讓GCP為我們的擴容預留足夠的硬件。在雲服務時代，硬件使用同樣是不容忽視的，因為把規模擴容五倍，同樣會給硬件帶來壓力。

除了谷歌之外，我們還與Redis Labs討論了很多，甚至在正式使用他們企業服務之前就進行了多次技術方面的問答，了解他們可以提供的具體優勢，隨後他們還給我們的數據庫遷移提供了支持。

3.負載測試

這是我們發布過程最重要的環節，而且是玩家不會遇到的功能。我們最初的計劃是用它作為一個調研工具，看帶來了什麼提升，但最終它帶來了更多的用途，也是最被低估的功能。

負載測試是比較獨特的，所以我們幾乎沒有使用任何現有的代碼庫，負載測試代價也比較昂貴。最後，負載測試很難做好，因為它既需要大量的研究，還需要很多次迭代才能得到正確的客戶端請求模擬，包括請求頻率和請求等待時間。這些都清楚之後，我們很快將負載測試作為主要聚焦點之一。

我們已經有一些工程師專門做locust，現在為負載測試投入了更多，在眾多的框架當中，我們選擇了web sockets，另外，運行Kubernetes也給我們帶來了很多的幫助。唯一的不便就是，它是用Python寫的，而我們使用的服務很少使用Python。

隨着測試規模的增加，我們在考慮要不要做一個新代碼庫，我們發現最初的壓測並不協調，只是對測試運行生成隨機數據，造成了差異化很大的數據，原因可能在於，每個請求完成的工作可能是完全不同的，比如有些請求甚至不經過我們的數據庫。

我們的解決方案是寫一個新的代碼庫以協調測試數據，locust會自動註冊和一些其他行為，還有些會匹配真實玩家行為。因此我們需要用戶提供ID和其他信息，以更精準提供服務。

另外一個需要說的是，運行負載測試是非常耗時間的，首先是因為測試需要的時間遠超過你的預期，另外一個則是測試運行比例，比如我們需要運行100萬個locus，但穩定運行每秒只有幾千個，簡單計算就需要數分鐘，這對於一次測試來說太耗時間了，我們該怎麼辦？

我們可以確定測試需要的總時間，但這需要更長的工程時間和研發時間，我們願意付出時間成本，因為大多數的locus客戶端運行在雲端，而且也是更真實的，更快速的測試會讓這些結果不那麼真實。

另一個比較耗時的是運行時間（run time），一旦全規模運行測試之後，到底是立即決定是否通過，還是讓它多運行一會兒？考慮到關斷時間，我們更傾向於後者。更長的運行時間可以發現一些不那麼明顯的問題，比如資源使用峰值，更長的運行時間還可以讓我們看到更多的測試組合，擴容時間和運行時間組成了一次測試迭代，隨着多次迭代，需要的時間大幅增加，這對我們的測試帶來了很大的幫助，但也耗費了大量的時間。

談到測試，迭代其中一部分目標就是收集結果，比如HTTP相應代碼、服務日誌。獲得了這些數據之後，我們該如何確定得到的結果是精確的呢？我們對客戶端的模擬有多精準？我們研究了真實的客戶端請求，真正比較大的差異可能是真實客戶端會發出數百個請求，使得我們沒辦法全部模擬，相反，精準模擬讓我們可以看到哪些功能在擴容方面有風險，這導致了大量的後續修補。

Locus負載測試的未來是怎麼樣的？我們決定在發布之前繼續測試，對於服務局限來說，哪怕是最後一分鐘，你知道了也是好的，你至少可以減輕它帶來的影響。除了發布之外，我們覺得負載測試應該拓展到所有的SDLC當中，一旦擴容，我們可以發現所有的性能問題。

遊戲的變化可能會帶來更多的不確定，但持續測試可以讓我們對自己的服務更有信心。

二、擴容改善

這是占據了我們大部分研發時間的地方，第一部分內容談到了我們的規劃和準備工作，這部分主要從細節方面談如何執行。

首先，我們將核心服務從Google AppEngine遷移到了Kubernetes；其次，我們改造了匹配功能；第三，我們將所有的Redis數據都遷移到了Redis Enterprise；第四，對我們的MySQL做了一些提升；第五，我們增加了Web Service速率限制系統；最後，我們會用一些時間做這部分的研發復盤。

1.將核心服務遷移到Kubernetes

前面提到，我們將核心服務從Google AppEngine（GAE）轉移到了Google Kubernetes Engine（GKE）GAE是谷歌的平台即服務，只需要將你的peer傳到平台，服務會接管一切。GKE只是谷歌管理的Kubernetes服務，我們從2015年發布之初就一直在使用GAE，我們遷移到GKE是有一些目標的，可以對PHP runtime有更多的控制，還需要對資源擴容有更多的控制。

另一個目標是更多的部署連貫性，並將更多的組件在Kubernetes運行，它還解決了雲服務器的一些不可知問題。

還有一個部分是將GCP方案分離開來，一個GCP方案是區分GCP資源非常高層次的結構，它在不同環境的使用都是不一樣的，使用分離的GCP方案可以讓每個方案使用的資源更清晰。

最後，負載測試也是不可或缺的。GKE對於我們的小團隊來說依然是新鮮的，因為我們的使用經驗僅包括遷移服務，這時候GCP團隊的幫助非常及時，因為他們可以從平台方面幫助我們做負載測試，並根據他們在Kubernetes方面的經驗給我們建議。

完成到Kubernetes的遷移是將我們的核心服務現代化的基礎工作，也是讓遊戲轉向免費模式擴容的基礎。

2.改造匹配功能

我們做的第二件事是改造匹配功能，最初的匹配有一些已知的性能問題，這些問題並不影響匹配正確性，但會限制性能天花板。為了解決這些問題，我們知道需要做些新東西，而且這會比較複雜，因為《火箭聯盟》的匹配有很多複雜的規則。

我們的匹配服務是單線程.NET應用，已經很接近最大化狀態，離我們需要的擴容目標相差很遠，而且包含大量沒有頭緒的代碼。

那麼，我們該怎麼做？我們要保留所有的基礎功能，但同時要滿足遊戲擴容的需求。最明顯的解決方案似乎是MapReduce，我們從一開始就考慮過它，但我們還發現了OpenMatch，經過大量的調研之後，我們選擇了後者，雖然看起來需要大量的框架研發，但也可以在功能方面帶來大量的自由度，而且它還是開源的。

與我們的匹配服務不同的是，OpenMatch就是為擴容設計的，與原來無頭緒的代碼比起來有了很大的提升，而且它是尖端的技術，至今還在預發布階段。

當然，最後我們也進行了負載測試，對匹配功能進行測試是必要的，我們將OpenMatch在GKE當中調試，就像是核心服務那樣。更重要的是，我們學到了微妙的變化是如何影響整個匹配體驗的。匹配機制的改造耗時一年多，但這個投入是值得的，對我們的免費發布很重要。

3.遷移到Redis Enterprise

在我們看來，Redis Enterprise最好用的地方就是，它是完全自動re-sharding的，這意味着我們可以增加cluster規模，但需要的點擊更少，因為數據庫之間的跳轉是自動的，我們在免費發布的時候使用了這個工具。需要注意的是，這需要犧牲一些性能。

使用Redis Enterprise的過程中，我們還學到了很多東西，尤其是不同的代理設置。最左側是大多數的代理配置，你只需要一個代理，因為這是性能最高的方案。然而，考慮到我們的數據庫很大，我們需要保證性能的連貫性。

我們最初選擇了OSS Cluster模式，這是最簡單的改變，但不幸的是我們最後卻沒能用到它，因為缺乏足夠的支持，而且我們在Redis客戶端library的經驗不多。相反，我們使用了右側的DNS Load Balancer，雖然有一些限制，但它用起來還好。

使用了Enterprise之後，我們知道自己的數據庫有些是不好用的，我們做調整的原因，主要是希望提升指令的可觀察性，衡量Redis性能是多少有些困難的，直接衡量CPU行不通，衡量每秒運營次數也是有誤導性的。

可觀察性的改變，讓我們看到了性能問題的答案，然後對cluster擴容。同樣重要的是可以監控數據庫。搞定了這些之後，它比很多開源項目都更有效率。這張圖右側展示了每秒讀寫讀寫，這是dashboard上眾多的圖表之一。

Redis Enterprise還有一些優勢，它在處理Pub/Sub優化方面比開源工具好很多，但最主要的是它不會把所有publication分配給所有shards。其次，Redis Enterprise可以臨時複製，而且不會幹預production cluster。

最後，我們使用Enterprise做的這一切並不會導致我們被鎖在Redis Labs一家供應商身上，唯一的風險，可能是你不希望離開他們的服務。

3.MySQL提升

除了Redis，我們其他的主要數據庫都是MySQL，很長時間以來，它都是我們的擴容瓶頸，特別是它只能縱向擴容，帶來了很大的性能消耗。

這些年來，我們最好的選擇是Feature Shards，它將一系列的表格遷移到了新服務器上，而且做起來是非常簡單的。不幸的是，它不能解決縱向擴容問題，所以多年的使用之後，很多表單如果不投入大量的努力，幾乎很難分離出來，不過它給我們大量的功能都帶來了幫助。儘管有擴容風險，但我們最後認為沒有足夠的時間最橫向擴容，我們還用它解決了一些新問題，最後實現了負載測試目標。

但這不是我們唯一的MySQL提升，我們還使用了ProxySQL，能夠按照需求擴容，每個ProxySQL都與我們的MySQL數據庫相連，我們還獲得了Instant failovers，我們之前的方案需要50秒鐘，這是不可接受的，所以它只在緊急情況和維護窗口使用。

Proxy SQL給我們帶來了動態化的query routing，是緊急擴容非常好用的工具，而且不需要調整我們的服務。但也有一些不利，比如一些bug會導致停止，而且Proxy SQL有些複雜，學習曲線加上我們的經驗不足，導致在免費發布幾天內出現了一些配置錯誤。這也是儘早做主要功能的原因之一。

總的來說，Proxy SQL絕對是個提升，我們只是在使用了一段時候討論它的不足，但帶來的優勢遠遠更多。

4.速率限制

最後一個是非常小的功能，也就是速率限制。這個功能是怎麼來的？最初，我們希望把它作為一個登陸隊列，這需要大量的工程投入，最後通過理解玩家人數級別、遊戲次數速率和玩家流失之間的關係，我們選擇了一個更簡單的方案。

我不希望投入大量的時間做登陸隊列功能，主要是它很少被使用，所以我們選擇了相對簡單的定製化方案，能夠集成到我們的基礎設施當中，速率限制成為了我們用途最多而且最有用的功能之一，我們可以限制任何服務，還可以對全局或者每個玩家的呼叫作出限制。比如，我們可以將總體遊戲局數限制到每秒500次以控制用戶量的增長，如果我們看到了客戶端bug，還可以限制好友邀請為每秒一次。

5.研發復盤

隨着我們的功能研發進入了尾聲，我們發現並沒有實現想要的那麼多功能，那麼多月的時間都用在哪兒了？不要害怕提這些問題，並且給出答案。

第一個原因是，我們和很多的遊戲研發團隊一樣，因為疫情的影響從全職研發轉向了居家工作。其次，很多主要功能需要大量的投入，但我們團隊並不是所有人都參與了所有SDLC的研發，在線服務是需要回滾計劃的。

需要注意的是，不要過度分析，我們很多的功能都是沒有時間做，然後就是給出合適的截止日期，確定並尊重這個決定，並且根據它來協調研發。確保團隊買賬，如果真實的截止日期是發布當天，如果你把截止日期提前很多會讓人接受不了，轉向免費之後，我們的很多重要功能都是在發布前需要完成的，所以《火箭聯盟》的截止日期安排並不夠好，而且2020年之後的疫情也導致團隊協調不是那麼順暢。

三、發布心得

這部分我們只討論發布本身，首先來看看發布規劃，提前一周發布遊戲更新，為了讓玩家更快速上手，我們選擇將一些功能提前發布，其中一個是Epic賬戶與遊戲帳戶的連接，這是個很複雜的功能，提前發布可以讓我們在大量用戶湧入之前進行測試與監控，也可以幫助免費發布前一天進行熱更新。發布日期選擇的是周三，與平時周末相比不是那麼忙。

接下來是發布，這張圖展示了遊戲更新、熱更新與免費發布之後的用戶量變化，我們是首次看到《火箭聯盟》同時在線用戶超過了100萬人，這是個很大的里程碑記錄，但實現之後更像是提前預測過的結論，因為我們的負載測試顯示，性能天花板比這個數字更高。

周日迎來了用戶峰值，超過了我們五倍用戶量的預測，但還沒有超過我們負載測試實現的最高值，這意味着你在發布之前都需要一直進行測試，也顯示了為什麼在周三發布是非常不錯的選擇。

如果仔細觀察，我們會發現遊戲發布並不是一帆風順的，如圖所示，我們遇到了一些比較嚴重的問題，也經歷過非常大的用戶量下滑。第一個問題出現在發布當天，我們的賬戶鏈接功能出現了問題，主要是因為這個功能處於兩個公司之間，我們在負載測試的時候是無法進行的，需要注意的是，這個功能是提前一周發布的，所以這向我們展示了免費之後的用戶量更大。

第二個問題出現在周四，我們的Redis Enterprise re-sharding原本只是個預防措施，但我們的數據庫承壓很大，導致了一些功能暫時停掉。第三個問題出現在周五，它並沒有出現在圖表上，因為並不影響玩家數量，這就是我之前提到的Proxy SQL問題，主要是配置錯誤。到了周末的時候，雖然用戶量級更大，但我們再沒有遇到特別嚴重的問題。

對於發布首個周末來說，我們實現了非常不錯的結果，但團隊的感覺是怎樣呢？

我們的團隊很緊張但也很有信心，同時在線用戶峰值每天都在刷出新高，達到了我們預測的5倍量級，首周之後，整個團隊都加入了「戰時」視頻會議房間，我們做的準備比之前任何一次發布都重組，但依然在調節方面非常緊張，因為你很難在負載測試階段發現所有問題。最後需要說的是，雖然沒有比較大的故障，並不意味着我們就可以忽略一些小問題。隨着用戶量在周一回落，我們的團隊可以有時間對新常態思考更多。