整体框架示意图
-
image
- 版本说明
- 1.0.0 初始版本 2017.3.13
平台服务器
- 和业务相关的http功能服务器抽象
- 主要包括账号相关、支付相关、devops相关，线上需要独立部署，均可水平扩展
- 账号相关
- SDK登陆验证
- Dev注册登陆（REST/OAuth 2.0）
- 玩家账号基础信息
- 游戏服务器列表（按照渠道划分大区）
- 客户端版本校验、更新等（线上需要考虑安卓和iOS渠道更新时间的不同）
- 登陆公告、用户协议、新功能通知等
- 支付相关
- 支付回调（支付失败，会发起重试）
- 订单校验
- 对账
- DevOps相关
- 运营相关接口，如配置运营活动、礼包码等
- 客服相关接口，如查询玩家信息、查询玩家日志等
- 运维相关接口，如新建服务器等
- 研发相关接口，如热更新等
- 管理线上其他服务器
- CDN相关
- 用于客户端更新资源等
游戏服务器
- 网关服务
- 消息转发
- 协议加解密、解压缩
- 防洪水等
- 场景服务
- 负责游戏主要业务逻辑
- 战斗、副本等逻辑可根据业务逻辑考虑可扩展
日志服务器
- 统计日志
- 写入mongodb
- 程序运行日志、业务逻辑日志（查bug）
- 通过log4j2写入rsyslog或者kafka，统一用elk进行可视化日志管理
- 即统一进行日志管理
跨服服务器
- 提供跨服逻辑
其他服务器
- 可提供公共的聊天服务器，支持跨服聊天
服务器相关技术调研
- 对于账号服务器、支付服务器采用Vert.x框架，轻量级且性能高
- 对于devops服务器，因为有前端逻辑(可使用Thymeleaf模板引擎)，所以采用Spring-Boot，集成大量工具，快速开发
- 游戏服务器，采用Netty作为网络层，Disruptor作为消息队列，Redis作为缓存服务器，逻辑层多线程处理，io密集型操作全部异步
- 游戏进程内缓存可采用lru算法
- 跨服服务器和游戏服务器之间可使用RPC进行调用
- Gradle进行项目整体构建
用例流程举例
- 登陆
- 客户端连接平台服务器，进行版本校验，如果有更新则去CDN下载资源更新
- 更新完毕，自动登陆（SDK），去SDK服务器进行登陆验证
- 验证完毕拿到access-token，去平台服务器再次验证，通过返回游戏服务器列表+uid
- 客户端选择某个服务器，建立连接，登陆游戏
- 支付
- 客户端发起支付请求，调用SDK支付
- SDK服务器创建订单号并调用渠道支付
- SDK服务器异步通知支付服务器支付信息
- 支付服务器直接回调游戏服务器进行游戏内支付并依次返回
- 注：订单号可以自己生成，方便对账
- 客服查询
- 客服通过客服工具访问devops，获取大区列表和游戏服务器列表
- 选择某一个游戏服务器，输入查询项如玩家id发送至devops
- devpos将请求转发至对应的游戏服务器
- 游戏服务器根据玩家id查询玩家信息并依次返回
- 运营操作
- 运营通过运营工具访问devops，获取大区列表和游戏服务器列表
- 选择部分游戏服务器进行运营活动配置并发送至devops
- devpos将请求转发至对应的游戏服务器
- 游戏服务器根据逻辑处理活动配置
- 研发操作
- 直接访问devops服务器，选择某个游戏服务器
- 在web页面内选择向对应的游戏服务器发送关服指令
- 游戏服务器收到消息后，执行关服操作，依次关闭服务
- 运维操作
- 搭建新服，初始化新服环境并启动
- 访问devops服务器，在对应大区添加新服，指定相关信息
- 将新服信息依次同步到账号服（服务器列表）、支付服（用于支付回调）
其他说明
- 目前游戏服务器只有两个进程，一个网关进程，一个场景进程，场景进程管理所有逻辑操作，因考虑到非mmo游戏类型，所以未采用传统的多场景进程+中心进程(跨场景通讯)的方案
- 网关进程可以考虑开放多个端口用于acceptor（需要测试性能，单端口和多端口）
- 必须要进行压力测试来反馈单组服务器承载压力（吞吐量、延迟等）从而进行设计调整
网友评论