游戏服务架构(一)

这里按照多年在中小游戏公司的经验衍生出来的相关架构思路和应该规避的问题, 以此游戏项目在立项的时候提前规避好问题处理.

立项选型

根据在游戏公司这么多年总结, 基本上游戏公司集中于:

• 传奇类: 大部分都是当年 传奇 相关类似这种滚服战力相关类.
• 轻度休闲: 偏向个人数值类, 内部没有和其他玩家做交互( 最多 排行榜 这种非实时 ).
• 重度游戏: 这种以 MMORPG 这种居多, 相对数值繁多且游戏要素很泛( 玩家间交互更多且玩法更复杂 ).
• 存档同步: 单机级游戏, 把存档放置与服务端同步( 客户端做业务主要处理 ), 服务端不做太多业务仅仅作为云存档类似功能.
• FPS同步: 没接触过的游戏项目, 中小公司可能相对比较少接触到.

传奇类这种实际上要么是 祖传代码 要么是立项的其他类似更加偏重 轻度休闲类 这种, 其实说的是那些单独从公司 ‘拿’ 出来的公用传奇源码之后需要做维护的情况.

这里开发复杂度比较麻烦的是重度游戏相关( 业务重心依赖服务端同步 ), 而最简单就是存档同步( 服务端同步状态存档文档 ).

刚开始确定立项的时候必须知道游戏项目类型, 从而能够针对性选型, 但是基本上日常方面就我在广州这边工作时间都是 skynet 一把梭处理.

基本上广州游戏公司都是 skyent, 而且底层上不需要接触导致只需要处理好 Lua 编写业务就行了, 更像是 Lua 开发者

相对轻度的 H5 平台游戏, 不考虑扩展的处理甚至看过直接采用 php(swoole) 做的简单游戏服务端功能, 只需要涵盖游戏推送邮件消息和奖励发放/排行榜等.

服务端分层

就目前游戏项目当中基本上分为:

• Web层: 第三方登录尽量采用简单, 基本上需要登录/服务器列表/公告基础接口.
• Server层: 游戏交互层, 这种常见的是 Protobuf + Lua, 总之是必须要挂载脚本写业务支持热重启.
• Admin层: 后台管理层, 后台推送客户端邮件/公告/服务器列表, 日活/月活/流水统计等相关.
• DB层: 这里实际上总的委托给成品云服务数据库厂商, 经过多年实践发现自己维护和备份数据成本支出太高不如委托第三方定时备份存储.

这里建议 Web 初期刚开始不要采用 Java 这种需要编译提交的, 这种编译项目初期频繁改动打包十分麻烦只有项目后期业务固定且有性能问题的时候才需要采用.

其实这里更多建议 PHP + FPM 这种可以修改下就能同步修改业务的语言, 无需打包所见即所得的处理方式频繁修改也没有太麻烦的地方, 之前也看过主要业务 H5 相关业务当中喜欢全部采用 NodeJs 技术栈去涵盖 Web + Admin, 主要是方便小程序上架/官网搭建等扩展操作( 其实就是一个人当N个人用负载更多功能 ).

这里千万记得架构分成, 把 SDK/API 相关那些提取出来, 以前看过最坑的就是服务端集成所有功能, 后期维护简直是灾难而且SDK接入是十分频繁导致重启也一样.

这里先大概说明下这些, 因为游戏架构相对来说采用的技术栈十分复杂, 但是基本上都有约定俗成的 套用公式 可以直接在前期立项处理好.