服务器架构 Server Architect¶
简介¶
一个魔兽世界游戏服务器有两个主要组件
游戏服务器. 包括 auth server 用于验证登录, world server 用于处理游戏内容相关的逻辑, 比如打怪, 做任务, 打副本等.
游戏数据库, 里面存储了游戏中的各种状态. 比如人物登录状态, 身上的装备, 任务进行到什么程度了, 哪些副本有进度了等等.
这里的游戏服务器本身不储存任何数据, 数据都在内存里. 服务器定期会将数据写入数据库做持久化保存. 而为了防止崩溃导致丢数据, 服务器还有将数据落盘但不写入数据库的机制. 如果崩溃重启后检测到还未写入数据库的数据, 那么会从磁盘上读取这些数据并将其写入. 该机制不适用于容器的情况, 应为容器一般没有磁盘. 而数据库则是保存着服务器上所有事情的状态. 数据库上的数据没了那么这个服务器也就完了.
游戏服务器可以是单机, 也可以是集群, 可以是虚拟机, 也可以是容器. 集群比较适合随着玩家的增加和减少扩容, 以提高游戏体验. 而由哪个节点来处理某个具体玩家的数据是由 Load Balancer 来决定的, 也就是负载均衡器. 但是游戏服务器比较复杂, 例如在同一个副本中的玩家需要由同一台服务器来处理. 具体调度机制还未知. auth 服务器虽然由于不处理复杂逻辑, 是可以用集群部署的, 但因为它的负载并不高, 所以集群部署也意义不大. 而 world 服务器由于比较复杂, 而且在私服生产环境里, 由于没有暴雪那强大的团队把属于 公共世界, 位面, 副本 等流量分散到不同的机器上的技术, 所以通常 world 服务器是由性能强大的单机来部署, 并且通常使用虚拟机, 而不使用容器.
游戏数据库往往是性能的瓶颈, 在玩家人数达到 1000 以上, 动辄 1000 每秒的写入是最大的挑战. 而如果把数据库和服务器在一起部署, 资源的占用也会很大, 并且两者一个挂掉也会影响另一个. 所以在生产环境中数据库要和服务器分开部署. 而数据库是你的服务器的命脉, 里面的数据是一定不能丢的. 所以有财力的情况下建议使用 AWS RDS 这一类的云数据库, 以获得更强大的性能, 扩容可能性, 网络安全 和 数据安全.
基于单机的架构¶
游戏服务器 和 游戏数据库 都在你玩魔兽世界的电脑上部署. 游戏服务器和数据库都会占用性能, 并且会占用网卡带宽. 这样留给真正游戏客户端的性能就不多了. 如果你玩多开的话, 你要至少 32G 内存的电脑, 而且单机多开虽然是 localhost, 但依然要走网卡, 而个人电脑的本地网络带宽一般不太行, 结果就会导致严重的网络延迟.
该架构适合于你自己玩, 或者和 3-5 个小伙伴在局域网中玩.
单台云服务器架构¶
游戏服务器 和 游戏数据库 都在云服务器上部署. 云服务器由于不运行其他系统软件, 性能会比较好也比较稳定. 你可以选择你需要的 CPU 数量, 内存 和 网络带宽. 云服务器的网络一般是虚拟网卡, 带宽要远远高于你的个人电脑. 缺点是如果云服务器崩溃, 两个服务全部都崩溃, 容错较低. 而且由于游戏数据库也在云服务器上. 如果云服务器挂了, 你不修复云服务器的话是无法把数据库中的数据导出. 也就是你的系统如果坏了, 你无法用云运维中常用的 “自动启动一个新的” 的方式来快速修复.
游戏服务器 和 游戏数据库 分离的的架构¶
我们这里以用 AWS 来部署为例. 该架构是用于商用生产环境的最终选择, 当然你也可以选择其他云服务提供商, 原理类似.
一个 VPC, 有 Public Subnet 和 Private Subnet, 并且提供一个 EIP 作为固定私服 IP 地址.
一个 Ubuntu EC2 作为游戏服务器, 位于 Public Subnet, 可以从公网用特定端口访问.
一个 AWS RDS MySQL 8.0 作为游戏数据库, 位于 Private Subnet, 只能从 Public Subnet 上的游戏服务器访问.
每次构建后定期将 EC2 的 Image 打包成 AMI 备份到 S3, 以供以后重建一个一摸一样的 EC2.
定期将数据库快照备份并保存在 S3 上, 以供随时将数据恢复到某个时间节点.
该架构除了要花钱, 没有别的缺点.