想要游戏火爆，热度经久不衰，联机必不可少。而联机游戏对于游戏低延时、服务稳定、成本控制有很高的要求，对于研发、运维挑战很大。
腾讯游戏服务器引擎（Game Server Engine，缩写GSE），支持有状态的游戏服务部署和扩缩容，实现服务发现、高效灵活的服务器伸缩和就近调度的能力，帮助开发者快速构建稳定、低延时的多人游戏的部署环境，并节约大量的运维成本，下文将为大家全方位讲解和分析。
一、联机对战类游戏的需求
联机对战类包含FPS、MOBA、休闲IO、体育竞技、棋牌、策略等需要与人一起玩，一定时间就结束的游戏。
1. 游戏低延时，保障更多玩家流畅的体验
全球玩家分布广泛，而服务器集中部署，会使部分地区网络体验差，游戏体验受到影响，这也是部分地区玩家数量相对较少的一个原因。
有没什么办法，可以降低延时，尽量让更多玩家加入进来呢？
通常采用就近调度，或者全球加速（集中部署在一个点，各个区域到此点进行加速）的策略，可以让网络延时达到一个优化。对于实时性非常敏感的游戏来说，就近调度效果更明显。
不过就近调度也有几个棘手的问题：
方案一：业务部署在多个区域，玩家就近在一个区域完成匹配和对战。
问题：某个区域的玩家相对较少，可能匹配不到相应等级的人，最后所有玩家都集中到某个大区去了，实际上又变成了集中部署。
方案二：匹配在一个大区进行，集中匹配，对战的时候就近分配到不同的地区。
问题：匹配时哪些区域会被匹配在一起是不确定的，而且也存在大量邀请好友一起玩的行为，每一天被分配到各个大区的玩家数量可能会非常不一样，各个大区的服务器需求量不能提前准确预估。准备少了不够，准备多了浪费资源。为了实时满足就近调度，可能每个区域都要最大量的准备服务器，致使服务器成本暴增。
最后实际方案:可能变成集中调度了，对于中国区来说，所有的服务部署到上海。
2. 服务稳定，保障玩家体验和多创营收
在保障服务稳定和玩家体验方面，也会遇到以下挑战：
（1）爆发式增长，不能及时扩容承接更多玩家
为了响应爆发式增长，研发和运维都需要提前做很多工作：确保服务能平行扩展，通过添加服务器，可以让游戏无上限的支撑玩家。
这是一个有状态的扩缩容场景：对于游戏服务，尤其是对战服务来说，不能是简单添加一个CLB(负载均衡)就能搞定。在游戏服务里需要断线重连，能找到之前连接的服务器；另外游戏过程不能因为缩容中断游戏。
研发侧：服务注册、服务发现、服务调度，服务管理等工作，以确保服务能自动化的平行扩容，否则只能靠手工配置。为了保障稳定性需要检查服务健康状况，屏蔽不健康服务，以及服务保护工作避免游戏中的服务被中断。
运维侧：需要写一些脚本去添加更多服务器，需要写一些工具让服务器自动伸缩。自动化进行，需要制定服务器伸缩策略、研发服务器自动购买、故障服务器排除等工具。
即使做好上面准备工作的情况下，还有可能会出现异常情况：
在服务器分配过程中，调度指标一般以服务器的指标CPU、内存作为参考，这样可能导致一些低CPU、低内存的服务短时间被大量分配出去，服务器访问量瞬间爆发式上涨而挂掉。为了避免这种情况，通常CPU的利用率会维持在不高的状态。
这件事，无论是研发还是运维，都不是一件简单的事。工作量比较大，前期不确定游戏是否会爆发式增长，一般中小开发者也不会提前做这些准备。
（2）地域/服务器发生故障
服务器发生故障比较常见，通常做法就是监控服务器，出现故障立即剔除掉。
地域或整个机房发生故障不常见，但造成的影响面积非常宽广，一般游戏开发者不太会考虑这个点，因为要做服务器跨地域或者跨机房容灾，至少要2倍的服务器，投入产出相对较低。
3. 成本节约
服务器空闲导致的成本，主要有如下这些情况：
每日&周末&节假日的高峰波谷时的资源空闲
游戏稳定运营及下降期，服务器空闲资源
活动期间，爆发增长，活动过后资源空闲
比起游戏运营成本来说，服务器成本算不了什么，但是，能省一点是一点，是不是？
二、对研发和运维的挑战
如前文所述，为了提升游戏的一点体验，会导致研发工作量大、运维工作量大、服务器成本大。
1. 研发工作量大