騰訊游戲服務器引擎（Game Server Engine，縮寫GSE），支持有狀態的游戲服務部署和擴縮容，實現服務發現、高效靈活的服務器伸縮和就近調度的能力，幫助開發者快速構建穩定、低延時的多人游戲的部署環境，并節約大量的運維成本。

一、聯機對戰類游戲的需要保證什么？
1. 游戲低延時，保障更多玩家流暢的體驗
全球玩家分布廣泛，服務器集中部署，使部分地區網絡體驗差，游戲體驗受到影響，這可能是部分地區玩家數量相對較少的一個原因。
通常就近調度，或者全球加速（集中部署在一個點，各個區域到此點進行加速）可以讓網絡延時達到一個優化。對于實時性非常敏感的游戲來說，就近調度效果更明顯。不過就近調度有幾個棘手的問題：
方案一：業務部署在多個區域，玩家就近在一個區域完成匹配和對戰
問題：某個區域的玩家相對較少，可能匹配不到相應等級的人，最后所有玩家都集中到某個大區去了，實際上又變成了集中部署。
方案二：匹配在一個大區進行，集中匹配，對戰的時候就近分配到不同的地區。
問題：匹配時哪些區域會被匹配在一起是不確定的，而且也存在大量邀請好友一起玩的行為，每一天被分配到各個大區的玩家數量可能會非常不一樣，各個大區的服務器需求量不能提前準確預估。準備少了不夠，準備多了浪費資源。為了實時滿足就近調度，可能每個區域都要最大量的準備服務器，致使服務器成本暴增。
最后實際方案：可能變成集中調度了，對于中國區來說，所有的服務部署到上海。
2. 服務穩定，保障玩家體驗和多創營收
（1）爆發式增長，不能及時擴容承接更多玩家
為了響應爆發式增長，研發和運維都需要提前做很多工作，確保服務能平行擴展，通過添加服務器，可以讓游戲無上限的支撐玩家。
這是一個有狀態的擴縮容場景：對于游戲服務，尤其是對戰服務來說，不能是簡單添加一個clb(負載均衡)就能搞定。在游戲服務里需要斷線重連，能找到之前連接的服務器；另外游戲過程不能因為縮容中斷游戲。
研發側：服務注冊、服務發現、服務調度，服務管理等工作，以確保服務能自動化的平行擴容，否則只能靠手工配置。為了保障穩定性需要檢查服務健康狀況，屏蔽不健康服務，以及服務保護工作避免游戲中的服務被中斷。
運維側：需要寫一些腳本去添加更多服務器，需要寫一些工具讓服務器自動伸縮。自動化進行，需要制定服務器伸縮策略、研發服務器自動購買、故障服務器排除等工具。
即使上面做好準備工作的情況下，還會出現異常情況：在服務器分配過程中，調度指標一般以服務器的指標cpu、內存作為參考，這樣可能導致一些低cpu、低內存的服務短時間被大量分配出去，服務器訪問量瞬間爆發式上漲而掛掉。為了避免這種情況，通常CPU的利用率會維持在不高的狀態。
這件事，無論是研發還是運維，都不是一件簡單的事。工作量比較大，前期不確定游戲是否會爆發式增長，一般中小開發者不會提前做這些準備。
（2）地域/服務器發生故障
服務器發生故障比較常見，通常做法就是監控服務器，出現故障立即剔除掉。
地域或整個機房發生故障不常見，但造成的影響面積非常寬廣，一般游戲開發者不太會考慮這個點，因為要做服務器跨地域或者跨機房容災，至少要2倍的服務器，投入產出相對較低。
那么有方案讓游戲服務0成本跨地容災嗎？
3. 成本節約
服務器空閑導致的成本，如以下這些情況：
· 每日&周末&節假日的高峰波谷
· 游戲穩定運營及下降期，服務器空閑資源
· 活動期間，爆發增長，活動過后需資源空閑
比起游戲運營成本來說，服務器成本算不了什么，但是，能省一點是一點，對不？
二、聯機對戰類游戲對研發和運維的挑戰
如前文所述，為了提升游戲的一點體驗，研發工作量大、運維工作量大、服務器成本大。
1. 研發工作量大：服務管理、就近調度、跨地容災、不停服更新、自動伸縮，工作量大，大廠已經逐步在完善這些配套工具，對于一些創新工作室，或者創業者，會把更多精力放在打造游戲業務上，做這些工作是一種負擔。
2. 運維工作量大：反復去做擴容、縮容、發布版本。如果不反復去做這些事，需要開發一些工具/腳本，是需要前期較大投入的事情。
3. 服務器成本大：一是空閑資源成本，二是按照傳統方式就近調度、跨地容災至少增加1倍服務器成本。