天美J3工作室伺服器主程：我們怎麼避免上線即炸服？

炸服，是近兩年頻繁發生、遊戲廠商聞之色變的運營事故。

雖然從某種意義上來說，炸服意味著遊戲很受歡迎，但由於炸服會致使玩家無法登入、頻繁卡頓、反覆重連，甚至出現資料丟失和回檔，導致遊戲口碑暴跌。一旦處理不好，可能會使一個原本的爆款喪失第一波爆發的機會。

從伺服器架構設計的角度，如何避免上線即「炸服」的事故發生？

上週六，在騰訊遊戲學院主辦的GWB騰訊遊戲品鑑會上，天美J3工作室《使命召喚手遊》伺服器主程Jerry分享了他對於伺服器架構設計的心得。

其分享的要點如下：

• 從伺服器設計角度看，出現炸服往往和架構設計不到位、平行擴容或負載均衡能力欠缺、單點容災問題考慮不完善等問題有關。
• 伺服器部署方式的選擇要從實際業務要求出發，建議優先考慮全區全服。
• 設計分割槽分服模型時，也可以吸取全區全服的設計經驗，避免原本存在的一些問題。
• 程式模型設計中，建議根據業務情況，將大功能解耦、拆分成多個程式，程式拆分原則：「大系統小做」
• 選擇後臺路由策略的通用原則：一般情況下，無狀態服務使用隨機分配的方式，有狀態服務使用取模或一次性雜湊的方式，單點服務使用主備或備份方式。
• 和故障隔離、線上更新/異常處理、削峰、第三方系統設計相關的架構設計注意事項
  

看完這篇技術乾貨，說不定能幫助你的產品避開炸服雷區。


以下為分享內容，經葡萄君整理，有調整和刪節。

大家好，我是Jerry，來自天美J3工作室，現在擔任《使命召喚手遊》伺服器主程。很高興有機會和大家聊一聊有關伺服器架構設計的話題。

今天這個話題，想必大家都會有所關注：遊戲上線後出現炸服，可能是因為哪些原因？在遊戲設計之初，我們需要注意哪些問題，才能避免或減少炸服發生？

那什麼是炸服？我相信大家都聽說或經歷過這樣的情況，遊戲剛開服的時候，由於玩家特別熱情，可能出現登入不上、頻繁卡頓，甚至反覆重連的情況，嚴重時可能會出現資料丟失、回檔，而且這些問題往往不能快速得到解決。

從伺服器設計的角度看，這些問題一般和下面這些因素有關：伺服器架構設計不到位、平行擴容和負載均衡有缺陷、單點容災考慮得不是特別完善。


一個伺服器架構設計不當的案例

我們先從一個案例講起。這是某款遊戲的伺服器架構圖，我們做了適當的簡化。


這款遊戲採用了分割槽分服的部署方式，架構圖左邊其實是一個區，主要包含登入授權服務，以及連線管理和遊戲邏輯。同時，它有一個所有分割槽公用的對局管理模組，而它的遊戲邏輯放在了戰鬥邏輯程式中，也是各個分割槽共同使用。

在功能層面，這款遊戲的連線管理主要負責玩家的連線登入，遊戲邏輯裡包含了資料管理，角色養成等業務邏輯，而對局管理包含組隊、匹配、開局邏輯等等，戰鬥邏輯主要負責局內戰鬥。

這款遊戲在部署上有一個很有意思的點，開發團隊認為這款遊戲單區承載能力足夠，因此打算一個大區用一臺高效能物理機、主遊戲邏輯用一個程式就搞定了。

這樣的架構設計存在什麼問題？首先業務耦合度特別高。他們在架構圖裡雖然把連線管理和遊戲邏輯分開了，但實際上這兩塊在同一個程式中。連線管理和遊戲邏輯放在一起可能會導致什麼問題？

對於這款遊戲來說，遊戲邏輯裡包含了很多遊戲，所以業務邏輯會特別重，出現Bug的概率特別高，如果線上上運營，遊戲邏輯可能需要頻繁更新，如果將其和連線管理放在一起，會導致更新出現各種掣肘，一旦處理不當，就有可能導致玩家掉線。


其次，他們的對局管理模組包含了很多功能，比如匹配、開局、負載管理等等，由於全域性只有一個對局邏輯，所以可能會存在單點容災的問題。而對局管理和遊戲邏輯放在一起，平行擴容方面也會存在問題。同時，由於他們把負載管理和匹配之類的功能放在同一個程式裡面，在負載管理上可能也存在一些缺陷。

擴充一點說，在分割槽分服部署模式中經常會碰到另外一個問題：由於開發者認為遊戲是分割槽分服的，每個區的玩家數量相對會比較少，所以他們只部署一個程式來搞定，從單區的角度來看形成了事實上的單點。


而這款遊戲全服共享的「對局管理」只有一個程式，我們認為如果單程式能支撐所有的請求，那麼至少應該設計成主備部署的架構。但在遊戲上線前，你拿不準使用者量會達到什麼樣的程度。萬一你的遊戲成了爆款，這種單純的主備方式有可能滿足不了實際的需求。因此，我們推薦將其設計成可以平行擴容的方案。

說到平行擴容，剛才那種事實單點是無法支援平行擴容的。對於這個專案，他們負責伺服器設計的同學說，單區承載目標是5K-6K，但隨著開發推進，遊戲業務邏輯越來越複雜，通過壓力測試發現，在這種邏輯架構下，遊戲邏輯程式承載的極限只有3K。由於這種架構不支援平行擴容，遊戲上線時很有可能發生炸服。


這款遊戲的對局管理為什麼不支援平行擴容？因為對局管理程式中包含的功能太多了，這些功能在同樣的業務邏輯下，對效能的要求可能不一樣。如果想要對其中某個功能進行擴容，在這種把所有功能都整合在一起的設計中顯然做不到。

除此之外，這款遊戲還存在負載均衡的問題，這個和架構設計可能沒有太大關係，我們發現，這款遊戲的對局管理存在演算法缺陷。因為他們沒有考慮到一臺機器的瞬間負載能力，在新加入「戰鬥模組」機器時，可能發生雪崩。


因此我們設計負載均衡排程演算法時，除了定時上報負載外，一定要設計異常上報機制，負載均衡演算法必須能及時處理異常情況，並且例項——對於這款遊戲就是戰鬥模組——必須要有主動熔斷機制，避免出現負載本身已經承受不住時，負載排程模組還不斷髮送開局請求，當然這需要負載排程模組和例項之間互相配合。

同時，我們還需要設計提前預判機制。舉個例子，目前我只剩下10%的負載，下一次上報時間可能在3秒以後，如果這3秒內排程模組傳送了過多請求，很有可能會導致雪崩。

總體看下來，如果這款遊戲以這樣的伺服器架構上線，萬一玩家特別熱情，剛才提到的任何一個問題爆發，都有可能引發「炸服」。

在這個案例中，我們指出了很多問題，也相應提供瞭解決方案，但專案組反饋說，可能沒有辦法做這樣的修改，因為他們在設計之初就把伺服器架構限死了，並且伺服器底層架構缺乏相關的支援。

那我們在架構設計之初，能不能做一些預見性的設計，規避這樣的問題？

伺服器架構設計和技術選型怎麼做？

接下來我想談談遊戲伺服器架構設計和技術選型要怎麼做。

如何選擇區服模型？

先看區服模型。一般來說，遊戲部署方式分兩種，分割槽分服和全區全服。下圖左側是分割槽分服的簡化模型，右邊是全區全服的簡化模型。


分割槽分服模型一般在前端會有一個導航模組，用於區服選擇；區與區之間隔離，它們會有各自的DB。區與區之間如果需要通訊的話，往往會使用跨服模組。對於一些需要跨服的功能，比如包含所有區的排行榜，可能還會為此增加一個公共DB。這些是分割槽分服的主要特徵。

而全區全服沒有分割槽的概念，但它會有一箇中心通訊模組，並且整個大區在邏輯上只有一個DB。

這兩種部署方式對比下來有一個很特別的現象。從業務邏輯來看，分割槽分服架構裡每個區只畫了一個「World」，而全區全服畫出了很多業務程式。

也就是說，由於分割槽分服架構下，大家認為每個區玩家數量比較少，也有可能受限於開發時間、開發資源、技術儲備等原因，沒有把業務邏輯拆分得足夠細，因此一般只有一個「World」，或者把遊戲邏輯放在少數幾個程式當中。

其實這兩個模型並沒有明顯的高下之分，在實際選擇的時候，主要是從業務需求角度出發來選擇。如果業務本身存在合服的需求，那採用分割槽分服的模型自然更加合適。


不過我們看了很多采用分割槽分服模型的遊戲之後，有一些建議：

作為分割槽分服，其實也可以吸取全區全服的設計經驗，避免分割槽分服原本存在的一些問題。

比如分割槽分服中單機容量可能受限，我們建議要適當考慮平行擴容相關的設計。像剛才說的單個「world」做平行擴容比較困難，是不是可以把核心邏輯拆分出來？

很多時候，我們會看到分割槽分服採用真實的物理分割槽，DB也做了分隔，在合服遷移的時候，成本就相當高，那是不是能採用虛擬分割槽的方式來處理？在虛擬分割槽下，我們可以採用組合key，即用玩家的分割槽ID和Player ID組合，區分他們所屬的區服，這樣合服時不需要做物理上的資料遷移。

另外，我們需要完善自動化工具，因為分割槽分服必然會遇到合服的問題，合服可能需要處理資料上的、運營策略上的各種各樣的問題，而在設計方案之初完善自動化工具，能夠避免早期的架構設計或資料結構的設計，沒辦法很好地支援自動化的問題。

從遊戲伺服器設計角度來說，我們建議，如果有可能的話，儘量採取全區全服的設計方式，雖然這對於整個架構設計要求更高，但它有以下幾點好處：

首先，後續運營運維成本會比較低，因為它物理上只有一個環境，我們投入的運維人力更可控。

其次，全區全服可以共享機器。我們知道，遊戲後臺會有很多程式，但每個程式的資源消耗其實不一樣。而我們雖然會有很多區，但做運營活動時，每個區參與的使用者數量可能會有所區別。如果採用全區全服的方式，我們就可以共享機器資源。

當然，這也會導致對資源排程、動態擴縮容和容災備份的要求較高。

如何設計全區全服的程式模型？

既然我們建議採用全區全服，那麼在全區全服下，程式模型有什麼特點？首先是Kiss原則，說白了就是讓每個模組負責的功能儘可能單一，讓各種模組互相配合，完成一個複雜的系統功能。

因此，在程式模型設計中，我們建議大家根據業務情況，將大功能解耦、拆分成多個程式。在拆分成多程式之後，需要設計一個統一的訊息通訊。

拆分成多程式有哪些好處？我們先看看如果不拆程式，會出現什麼問題。


首先，不拆程式不利於協同開發，因為系統耦合度太高。

現在一款遊戲大作，開發團隊動輒幾十人，多則上百人，其中負責後臺開發的團隊也有大幾十人，這麼一個系統，大家都在同一個程式裡面寫，責任不明晰，出了問題很難判斷問題在哪。

其次，後臺很多系統、子系統之間效能有差異。比如登入模組在10萬PCU下所需的程式數、機器數，可能跟負責對局的模組不一樣，聊天模組、活動子系統之間也存在效能差異。如果不拆分程式，就不能做到按需部署，只能很暴力地把程式按某種倍數擴容，這必然會浪費機器資源，甚至有可能增加機器、部署更多程式，都解決不了效能瓶頸。

第三，現在很多遊戲都會尋求出海，出海必然會存在地域差異，如果想要提供好的遊戲體驗，就必須考慮就近部署的問題，如果程式不拆開的話，就近部署其實比較難做。

第四，在容災上會受到一定限制。因為我們沒有把關鍵子系統拆分出來，而人力成本、機器資源、專案資源都有限，只有將這些有限的資源投放到關鍵子系統上，才能讓我們獲得更大的收益。

那麼要怎麼拆分程式呢？在騰訊內部，有個原則叫「大系統小做」。一個大系統具體要怎麼拆分？標準有很多，我們通常會從功能需求、處理流程和通用元件這幾塊來拆分，比如功能可以拆分成好友、公會、郵件、聊天這幾個部分。


如何解決拆分程式可能帶來的問題？

同時要注意，拆分可能會帶來一些問題。如果我不拆分，就只有幾個程式，拆分完以後，可能部署上又使用了全區全服，系統就會變得非常龐大，用到的機器也會非常多，那麼監控要怎麼做？

我們原來在一個程式內，通過函式呼叫就解決的通訊問題，變成多程式之後，要用什麼方式進行通訊，協議要怎麼定？

在部署方面，原來只有幾個程式，我們把物理機拉過來往上面一丟就可以了，現在這麼多的程式，哪些程式應該部署在同一臺機器上？它們的數量配比應該是什麼關係？系統之間要怎麼協作？出了問題要怎麼定位？這些都成了問題。


今天我打算就前兩個問題和大家進行探討。

系統之間要怎麼樣進行通訊？在設計之初，我們要有一個比較好的底層設計框架，也就是剛才架構圖裡面的Router模組。這個底層框架要負責做系統功能解耦，還要作為各個子系統之間的路由器，並且為容災和擴容提供基礎，所以它本身必須是無狀態的。如果它存在太多有狀態的資料，那它本身的平行擴容就會成為問題。

同時，因為我們知道不同的業務邏輯、業務特性、效能要求會導致不同業務模組在路由策略方面會有各自的選擇，所以它還要支援多種路由策略，這對於我們的平行擴容、容災備份非常關鍵。


如何選擇後臺的路由策略？

接下來我們看看後臺的路由策略有哪些？應該如何選擇？

我們經常用到的路由方式可能就下面這5種，取模、一致性雜湊、隨機分配、主備和備份。這些路由方式應該怎麼選？


通用原則是對於無狀態服務，就是說它只是處理流程，處理完以後不需要儲存玩家資料的，我們一般使用隨機分配的方式。隨機分配有什麼好處？如果某臺機器掛掉了或網路出現故障，它對後續流程的處理其實不會有太大影響，最多隻影響當前處理的邏輯。

取模和一次性雜湊一般在有狀態服務中使用，因為它需要保持一些資料，這些資料可能在下一步操作中用到，或者某個處理流程可能需要二步或者三步，或者有兩、三個協議的請求才能完成，那我們肯定希望這兩三個請求放到同一個程式中處理，不然可能會發生問題。比如說對特定的玩家，從結算來說可能是對特定的房間，它們必須要能夠路由到一個固定的程式上。

此外，其實還有一種情況，我們工作中發現它有需要在同一個程式中處理，比如對同一個玩家的同一張表進行寫DB操作的時候，放在同一個程式中能避免出現寫衝突。

而對於「單點」服務——為什麼會出現單點？可能是為了避免出現決策困難。比如進行全域性負載管理的模組，它本身的效能要求並不是問題，因為它的整體請求數（比如開局請求數）存在一定上限，用一個程式就可以搞定。同時，如果這個程式中做負載管理和分配策略都非常好做，那我們就希望在全服中用一個程式去搞定。

對於這種情況，如果這個程式掛了，或這臺機器掛了，我們就不能正常進行下去，這時候就需要用到主備方式或備份方式進行處理。

這裡的主備方式和備份方式有什麼區別？在主備方式中，兩臺機器都會接到請求，但同一時間只有主機器進行服務，而對於備份方式，一般只有主機器掛掉以後，備份機器才會進行服務，平時它可能完全不接受這種請求。

這是有關路由的選擇，那路由還需要具備哪些特性？


從業務層面來說，我們儘量希望它無感知。這有點難度，但儘量做到。

舉個例項，我們寫DB時，DB的代理程式通常用的是隨機分配的路由策略，因為它是無狀態的。但後來我們發現某一段時間裡的超時請求特別多，為了查問題，我們臨時把DB的路由方式改成了一次性雜湊，來定位資料傳送到了哪一臺DB的代理伺服器上。

由於我們在開發的時候，沒有假設伺服器採取的路由策略，在設計業務邏輯時沒有施加限制，因此在實際運營中，我們可以比較容易切換路由策略，處理一些特殊場景。

同時，路由模組還要能夠自動處理網路異常，並能識別業務的通訊異常，這才能實現容災的功能。

上面說的是底層通訊的模組，那部署的時候要怎麼做？我們開發時受機器資源的限制，可能用一臺機器搞定所有的問題，但遊戲實際上線時，我們可能會使用了幾十臺、上百臺甚至上千臺機器，怎樣把平時的開發和上線部署統一起來？這對於自動化部署能力要求比較高。

要做到自動化部署，我們要設計自動化部署指令碼。而從實際經驗來看，我們在架構設計方面要有一些先期的考慮。

我們比較推薦大家採用集裝箱式的部署。怎麼理解這個概念？


不同業務程式的功能和效能可能不一樣，有些業務程式是CPU消耗型的，有些業務程式則是記憶體消耗型的，如果把它們搭配在一起，就能最大程度地利用到機器資源。

我們上線時一般會對同時線上人數進行預測，比如我們認為遊戲能做到同時線上100萬，但上線之後我們發現同時線上可能要到200萬，甚至250萬，這時你臨時計算程式要擴容多少，是不是簡單地按100萬到200萬去翻倍？這種簡單粗暴的方法不一定能解決不了問題，還有可能會浪費掉更多的資源。

因此，在設計之初，我們就要計算不同業務程式的負載能力，區分繁忙的服務和相對空閒的服務，再根據資源消耗情況分配成各種組別，判斷不同組別能支撐的使用者量，比如這一組能夠支撐2萬人，那一組可能支援5萬人，在實際操作中根據使用者量進行擴容。

同時，我們希望做到邏輯部署和物理部署分離，這樣遊戲上線時可以在實體機器和雲上機器中靈活選擇。另外，我們還會把實際的IP地址轉換成抽象化的業務IP地址，在騰訊內部會採用一種叫做 tbusid 的方式。

平行擴容和容災要怎麼做？

接下來看看平行擴容和容災具體要怎麼操作。

下面這個案例採用了分割槽分服的架構，評論服全區共享，開發團隊認為評論量可控，所以評論服只部署了一個評論模組。在這個架構中，每個大區的玩家都通過公共的路由模組登入評論服進行評論和聊天。值得一提的是，這款遊戲計劃在海外市場上線。


這種架構有什麼問題？首先容災怎麼做？如果評論服掛掉怎麼辦？其次，開發團隊先期認為評論量很少，萬一實際評論量太大呢？再然後，這款遊戲計劃在海外部署，那不同國家和地區的輿論風險怎麼控制？因此，這個架構不滿足業務發展的需求。

這裡有一些用來參考的解決方案，我們認為要允許平行擴容，並且風險要可控，就必須做分頻道管理，所以增加一個頻道的管理叢集，這個頻道的管理一般就是採用我們說的主備部署的方式，根據不同國家、地區或者主題分成不同的頻道或評論區。


這種方式是不是真正解決了獨立擴縮容的問題呢？看上去是，如果頻道不夠可以加頻道嘛。但大家可能沒有想到一個問題：

在這種架構下，玩家所有評論和聊天都通過各自大區，經過跨服路由到達各個頻道，如果聊天的資料量特別多，對核心玩法和核心模組在訊息和包量上存在衝擊，如果後期要做運營活動，像以前的大喇叭、小喇叭、全服廣播，以及現在可能會用聊天頻道做「飛機票」（組隊），就可能會遇到問題。

基於上面這些需求，我們希望伺服器架構能更進一步。比如像下面這個架構一樣，把玩家聊天的訊息資料和信令分開，讓玩家直接和頻道相連，而玩傢俱體連到哪一個頻道通過頻道管理的方式去做。這樣不管玩家訊息量多大，都可以通過擴頻道的方式解決。如果使用者訊息量太大，最多隻會導致某個頻道掛了或關掉，不會對整個遊戲產生影響。


故障隔離要怎麼做？

接下來講講故障隔離。一款遊戲上線時，如果因為某些原因出現了一個Bug，一時半會還定位不出來，這種情況要怎麼辦？怎樣快速遮蔽故障模組，不影響核心功能，故障恢復時還能及時通知到玩家？

我們希望在前端設計一個支援協議路由的模組，同時根據協議或者模組，區分關鍵流程和非核心流程，再進行區別對待。這樣如果在某個請求或模組出現異常，而且短期得不到解決，我們能夠儘快線上遮蔽，並知會到玩家，同時模組恢復之後也可以通知到玩家。


線上更新的異常處理怎麼做？

還有線上更新的異常處理。此前我關注到有些專案採用了容器部署，更新方式是直接停掉舊的容器，將其替換成新容器，還有些專案更新大廳模組時，會導致部分玩家掉線。如果我們想保證玩家體驗，這些都是不能容忍的。那在設計遊戲的時候，要怎樣避免這些問題？


一般來說，我們認為可以使用共享記憶體解決。不過，我們之前評審過一些專案，儘管它們使用了共享記憶體，但使用方式存在一些問題，比如有時把一些絕對指標地址直接存到共享記憶體裡，一旦程式重啟，共享記憶體就會失效。

現在遊戲的線上更新，一般是做一些策劃配置或活動配置的更新，所以我們希望程式能夠有一個通用的支援reload操作的框架，不重啟程式，只通過發一個訊號的方式通知有些資源需要更新。

對於一些無狀態的服務，我們可以考慮支援disable操作，也就是單獨禁掉某些程式，比如現在同時有10個服務程式，在承載量允許的情況下，我們可以先禁掉三分之一，對其進行更新再進行灰度釋出，這樣可以做到不影響玩家的情況下做到線上更新。

削峰的兩種常見情況

有時候，我們還需要考慮削峰。有些遊戲會做準點線上的活動，特別是端遊時代做得比較多一些，就是給線上玩家傳送道具，鼓勵玩家在某個時間點保持線上。

這對伺服器內部的路由包量和流量影響非常大。我們接到這種需求要進行評估，系統能不能扛住？如果系統扛不住，可不可以考慮採用離線發放的方式？如果不能用離線，能不能使用旁路的方式？或者能不能將自動到賬改成手動領取？這都可以變相進行削峰。


還有一種情況和配置相關，比如遊戲運營會有很多活動配置，玩家也會有很多活動進度相關的資料。很多遊戲希望在玩家登入的時候，為其展現各種資訊，比如紅點提示、活動完成進度什麼的。他們希望玩家一登入就做大量的配置拉取，這可能會導致玩家登入流程過長，還會使得伺服器的下行流量過大。

對此我們建議客戶端採用快取+指紋的方式，減少對於不變配置資訊的拉取。從伺服器和客戶端互動的協議設計角度來說，我們希望把動態和靜態的資料進行分離。

何為動態和靜態？比如活動配置其實相對來說是靜態的，可能在某個賽季或某個活動期間配置保持不變，而玩家的活動進度是動態的，這塊資料其實相對會比較少。我們可以把這兩塊配置分離，在玩家登入的時候，如果活動配置沒有發生變化，就只拉取他們的活動進度。

此外遊戲經常會有一些更新，有時為了方便我們會希望直接通過伺服器帶下去，但其實可以考慮採用CDN來降低成本。

需接入第三方系統時怎麼處理？

最後說一下第三方系統。遊戲上線時不可避免要接入一些第三方系統，其中可能包括給運營、客服使用的業務受理模組，以及線上廣告、支付等第三方系統。


接入第三方系統會存在一些問題，比如它的訪問量不可控，比如我們不知道客服呼叫的頻次，也不清楚如果用業務受理系統做web頁面的互動，它的量級會有多少。而且第三方系統的協議有可能跟我們的協議不相容的，在訪問許可權上也需要進行控制。

從我們的經驗來看，建議大家用一個模組對第三方系統集中進行包裝，做獨立的部署和流控。同時，這個模組還負責做協議的轉換及隔離。

這樣相當於為遊戲系統和第三方模組之間建立一道防火牆。如果第三方系統的流量突破上限，我們可以及時擴容，甚至一定程度地根據實際情況來遮蔽或停止第三方系統的服務。

當然，第三方系統有時會做一些升級的活動，或者效能有可能出現一些問題，如果我們有獨立部署的模組，在這個模組做一些針對性的適配，就能避免第三方系統的問題衝擊遊戲的後臺系統。

這些就是我今天分享的內容，謝謝大家。

分享/Jerry
整理/迪亞菠蘿包
來源：遊戲葡萄
原文：https://mp.weixin.qq.com/s/RY3l8clLtWhTymoUDtIA5w