MeteorCat / 游戏服务架构(三)

Created Sat, 07 Oct 2023 13:26:54 +0800 Modified Wed, 29 Oct 2025 23:24:54 +0800
1667 Words
游戏架构

游戏服务架构(三)

这里从基础的服务端开始, 主要是服务端选型和要点说明, 在广州这里我见过基本上这几种:

  • Skyent: 最广泛的的游戏服务端, 基本上采用 Lua 编写业务
  • Golang/Java: 这种最近兴起相对简单服务端架构, 之前看都是不做热更而让客户端在断线重连做更新( 之前在家公司见过 Java-NIO 感觉有过度设计和启动服务直接带个2G内存占用确实吃不消 ).
  • NodeJs/PHP: 这种 2020 年那时候兴起以 NodeJs(pomelo )/PHP( swoole/workman ) 其实差不多, 业务比较单一都是断线也是直接采用客户端连接.
  • C++/C#无头服务器: 高性能所需的纯 C/C++ 代码编写业务, 目前看的比较多的是 Unity 无头服务让服务端挂载个游戏客户端当作主机监听转发逻辑消息.

我个人感觉 Java-Nio 这套调试最容易, 但是性能消耗及其严重 (在单机上配个 16GB 内存的时候, IDE 占用甚至开单个都卡的无比心酸, 更别说加个 Linux 虚拟机 ), 且不带 Lua 做业务编写热更新带来的麻烦导致必须重启服务.

还有我觉得Java最大问题没有像Lua/Js这种业务脚本,在做客户端业务对接没办法做到多端共用, 之前最完美的方案是客户端主程编写好 Lua 逻辑之后可以达到服务端共用地步( 有时候客户端和策划做主要对接的时候, 需要沟通策划先出大概玩法逻辑其中会直接Lua做功能演示, 后续服务端和客户端对下功能直接用就行了 )

在我个人开来, 游戏服务端基本上可以直接集中于 Linux 端上( 基本上最后平台也只会在Linux平台 ), 无须为跨平台考虑. 而且最好比较有支持寄宿脚本语言做业务开发( Lua/Js 都行 ), 无法支持脚本业务热更新的方案在我个人看来是不合格的.

这里说下 常规语言热更新 和 游戏热更新 是两种完全不一样的概念, 常规语言热更新是监听 Linux 信号量之后做二进制覆盖启动重载, 这种情况下的程序覆盖的时候会造成中断且业务没办法无损切换, 可以思考下 socket 推送给服务端计数器 N+1 函数怎么无损不修改切换成 N+2, 并且追加 logger 打印展示( 这种情况很常见, 有些时候需要现在数据本身有问题需要动态热更新追加打印 ).

服务器没有热更新在线上排查问题真的极其难受, 没办法动态热更查看玩家数据在哪一步出现问题.

传输协议

以前基本上都是采用 TCP 做处理 ( 听说实时要求高的会自己构建 UDP 做高级协议传输, 但是我没实践过 ), 而在现在除了 TCP/UDP 还追加 Websocket 做游戏传输方式.

Websocket 是基于 TCP 更高层 HTTP 包装传输方式, 好处是全方面支持 H5 规范浏览器平台, 坏处就是携带大量附加数据体可能更加冗余.

如果立项的时候是以 H5 游戏为主且没有跨平台考虑( 后续需要包装app应用不走网页端 ), 则采用编程语言没什么要求( 中轻度游戏不需要热更新也行 ), 甚至直接 Websocket+JSON 传输都可以, 不需要做什么多余处理直接一把梭都行.

但是如果需要多平台且项目偏中型, 那么首先采用 Skyent+Protobuf 处理, 事实上所有游戏都建议采用 Skynet+Protobuf 处理, 因为在广州可能最多实践的游戏游戏服务端就是 skynet, 而且积累大量工作经验和集成许多社区方案, 内嵌的 lua 也是直接就能对业务不停机热更.

服务分层

注意, 对于游戏服务端来说不止是要单单面对客户端, 除了客户端还需要面对 SDK(登录转发)/ Admin(后台推送):

  • SDK: 做登录服务器开服的先导网关, 可以通过推送 Redis 消息队列, 然后服务端监听队列也行.
  • Admin: 做运营后台推送通知调用服务, 运营也是需要处理服务端配合架构的业务( 基本上也是配通用活动配置/邮件推送/物品发放等 ).

运营推送也是比较核心同时也是前期容易被忽略的一环, 需要定制化处理才能让游戏运营根据日活指数和活动热度调整调整( 还有拉黑非法玩家等 :) )

可以说游戏出了初版demo 决定了游戏是否可以游玩, 而运营推广决定网络游戏 是否可以细水长流运行, 我见过不少完全照搬国内表层玩法但是运营做的一塌糊涂的.

话扯远了, 这里所需要的游戏服务分层说的是, 除了给服务端留下客户端交互接口还需要给运营后台留下对应接口从而实现：

  • 资源发放推送
  • 封禁黑|白名单
  • 违禁词同步
  • 邮件推送
  • 强制下线
  • 服务器列表
  • ……(其他)

这里都是想运营游戏所必须要有的东西, 服务端都要做好备用方案处理, 基本上方案包含有:

  • 游戏服务端监听Redis队列指令, 运营端负责推送指令到队列
  • 直接通过另外监听端口来接收指令, 运营端推送直接实时端口

这里先说明下大概的服务端架构, 需要在构建游戏服务端之前所需要考虑的问题基本上就上面那些.