随着暴雪大概率推出国内市场,将会有很多外服MMO网游填补市场空缺,那么要建立完全满足用户流畅访问的游戏,对在线游戏服务器有哪些要求,需要注意什么?下面就来简单介绍一下
由于大型多人在线游戏服务器理论上需要支持无限多的玩家,所以对服务器端是一个非常大的考验。服务器必须是安全的,可维护性高的,可伸缩性高的,可负载均衡的,支持高并发请求的。面对这些需求,我们在设计服务器的时候就需要慎重考虑,特别是架构的设计,如果前期设计不好,最后面临的很可能是重构。
序列号 | CPU | RAM | HDD | 带宽 | 售价(美元) | 免费试用 |
---|---|---|---|---|---|---|
香港服务器1 | E5-2620 | 32G | 1T HDD | 50M/无限流量 | $196.00 | 立即申请 |
香港服务器2 | E5-2650 | 32G | 1T HDD | 50M/无限流量 | $256.00 | 立即申请 |
香港服务器3 | E5-2680 | 32G | 1T HDD | 50M/无限流量 | $316.00 | 立即申请 |
香港服务器4 | E5-2690 | 32G | 1T HDD | 50M/无限流量 | $336.00 | 立即申请 |
香港服务器5 | E5-2697 | 32G | 1T HDD | 50M/无限流量 | $376.00 | 立即申请 |
香港服务器6 | E5-2620*2 | 32G | 1T HDD | 50M/无限流量 | $376.00 | 立即申请 |
香港服务器7 | E5-2650*2 | 32G | 1T HDD | 50M/无限流量 | $436.00 | 立即申请 |
香港服务器8 | E5-2680*2 | 32G | 1T HDD | 50M/无限流量 | $476.00 | 立即申请 |
香港服务器9 | E5-2690*2 | 32G | 1T HDD | 50M/无限流量 | $556.00 | 立即申请 |
香港服务器10 | E5-2697*2 | 32G | 1T HDD | 50M/无限流量 | $596.00 | 立即申请 |
香港服务器11 | E5-2680v4*2 | 32G | 1T HDD | 50M/无限流量 | $696.00 | 立即申请 |
香港服务器12 | E5-2698v4*2 | 32G | 1T HDD | 50M/无限流量 | $796.00 | 立即申请 |
一款游戏服务器的架构都是慢慢从小变大的,不可能一下子就上来一个完善的服务器构架,目前流行的说法是游戏先上线,再扩展。所以说我们在做架构的时候,一定要把底层的基础组件做好,方便以后扩展,但是刚开始的时候留出一些接口,并不实现它,将来游戏业务的发展,再慢慢扩展。当然,如果前期设计的不好,后期业务扩展了,但架构没办法扩展,只能加班加点搞了。
面对庞大的数据量我们想到的唯一个解决方案就是分而治之,即采用分布式的方式去解决它。把紧凑独立的功能单独拿出来做。分担到不同的物理服务器上面去运行。而且做到可以动态扩展。这就需要我们考虑好模块的划分,尽量要业务独立,关联性低。
前期,由于游戏需要尽快上线,开发周期短,我们需要把服务尽快的跑起来,这个时候的目标应该是尽快完成测试版本开发,单台服务器支持的人数可以稍微低一些,但是当人数暴涨时,我们可以能过多开几组服务来支持新增涨的用户量,即可以平衡扩展就可以了。到后期我们再把具体的模块单独拿出来支持,比如前期逻辑服务器上包括:活动,关卡,背包,技能,好友管理等。后期我们可以把好友,背包管理或其它的单独做一个服务进程,部署在不同的物理服务器上面。我们先按分区的服务进行设计,后面在部署的时候可以部署为世界服务器,下面是一个前期的架构图,下面我们从每个服务器的功能说起:
1,登陆管理服务
负责用户的登陆验证,如果有注册功能的话,也可以放在这里。一般手机游戏直接走sdk验证。网页游戏和客户端游戏会有注册功能,也可以叫用户管理服务。
1.1 用户登陆验证 负责接收客户端的用户登陆请求,验证账号的合法性,是否在黑名单(被封号的用户),是否在白名单(一般是测试账号,服务未开启时也可以进入)。如果是sdk登陆,此服务向第三方服务发起回调请求。
1.2 登陆安全加密 使用加密的传输协议,见通信协议部分。
1.3 是否在白名单内 白名单是给内部测试人员使用的,在服务器未开启的状态下,白名单的用户可以提前进入游戏进行游戏测试。
1.4 判断是否在黑名单 黑名单的用户是禁止登陆的,一般这是一些被封号的用户,拒绝登陆。
1.5 登陆验证 服务器使用私钥解密密码,进行验证,如果是sdk登陆,则直接向第三方服务发起回调。
1.6 登陆令牌(token)生成 当用户登陆验证成功之后,服务器端需要生成一个登陆令牌token,这个token具有时效性,当用户客户端拿到这个token之后,如果在一定时间内没有登陆游戏成功,那么这个token将失败,用户需要重新申请token,token存储在登陆服务这,向外提供用户是否已登陆的接口,其它服务器想验证如果是否登陆,就拿那个服务收到的token来此验证。
1.7 显示用户角色信息 当用户登陆成功之后,显示最近登陆的角色信息。
2,显示公告
用户登陆成功之后,请求公告服务器,获取最新的公告,公告服务先根据token和Userid验证用户是否已登陆,公告有可能根据渠道的不同,显示不同的公告。所以 公告一定是要可以根据渠道编辑的。
3,选区服务
当用户登陆成功之后,请求服务器分区列表服务器,显示当前所有的大区列表。
3.1 验证用户是否已登陆 向登陆服务器请求验证是否已登陆。
3.2 大区列表显示 大区列表信息中只显示大区id和大区名称。这样做是为了安全考虑,不一次性把大区对应的网关ip和端口暴露出来,也可以减少网络的传输量。
3.3 用户点击选择某个大区,客户端拿到大区id再向选区服务请求获取此大区对应的网关ip地址和端口。根据负载算法计算得出。
3.4 网关的选择 选区服务会维护一份网关的配置列表。一个大区对应一到多个网关,当配置有多个网关时,需要定时检测各个网关是否连接正常,如果发现有网关连接不上,需要把大区对应的网关信息设置为无效,不再参与网关的分配,并发出报警。 一般对于网关的选择,可以使用用户id求余法加虚网关节点法。这样在网关节点数量固定的情况下,一个用户总是会被分配到同一个网关上面。但是如果只是使用求余法的话,可能会造成用户分布不均衡,这里可以通过增加网关的虚拟节点(其它就是增加某个网关的权重,让用户多来一些到这个网关上面),这个可以参考哈稀一致性算法。包括后面说到的一个网关对应多个逻辑服务器,也可以使用同样的方法。这部分可以抽象出来一个模块使用。
3.5 选区服务对内要提供修改服务器状态的接口,比如维护中…
4,登陆网关
4.1 建立连接 收到客户端的建立连接请求之后,记录此channel和对应的连接建立时间。并设置如果在一定时间内未收到登陆请求,则断开连接。返回给客户端登陆超时。