一 . 常规跨服玩法对服务器的需求
服务器的需求：负载均衡，固定路由算法，rpc
-
异步消息中间件
-
中转服务器
-
gof（直连）
二 . 战斗玩法对服务器的需求
服务器的战斗选择：帧同步和状态同步都可以实现雷神的战斗，选择帧同步是为了更高效。
战斗跳过，战斗回放，战斗观战，这种需求在实现上客户端和服务器的战斗部分最好是一套代码，但是客户端需要表现和逻辑分离，所以代码实现上客户端写战斗更适合。
状态同步：
- 战斗跳过等需求，单机客户端跑，多人实时战斗服务器跑。
- 雷神同屏的英雄数基本都超过10个甚至超过30个，绝大部分都是跑ai，服务器运算ai部分需要更多的资源，每次心跳需要的时间会比较长，同步状态会有延迟，同一时间点多个客户端看见的动作效果完全一致略有难度。
帧同步:
-
天然支持战斗回放，跳过，快进，观战
-
在同步问题上有更大的优势
-
客户端和服务器端一套代码，开发效率高，推进速度快
-
雷神同屏英雄多，但是操作少，省流量
类帧同步：
- 玩蟹现有的游戏一拳，拳皇，英雄学院类型的游戏，战斗和传统的回合游戏比较类似，战斗中存在战斗等待，多人玩法按照回合走，只需要控制好回合收集指令就可以。但是雷神游戏是及时的，不能有战斗等待，所以需要用帧号来记录出手技能和顺序。
三. 帧同步实践
-
网络部分使用了公司现在有的方案kcp
-
服务器4核 16g 1500人kcp初步压力测试没问题，服务器承载仍有较大的空间【内存res 1.5g，cpu100左右，load（3~7)】
四. 战斗验证技术方案
-
C#服务器--->C#战斗代码
-
java--->jni--->mono--->C#战斗代码
-
java--->jni--->.netcore--->C#战斗代码(集团的方案比较成熟)
五. 战斗验证服务器方案
- 战斗验证分优先级：
-
缓存队列：根据战斗的优先级分为同步队列和异步队列，队列预设长度，超过队列长度时，同步队列收到的协议按验证超时处理，直接返回，异步队列直接丢弃
-
同步验证：优先级高，验证时间有超时限制，验证结果需及时返回，通常是客户端进入战斗前就需要知道战斗结果。验证前需要检查一下在队列中等待的时间，如果已经超时，不验证，直接按照验证超时处理。当前主要是竞技场玩法
-
异步验证：优先级低，验证没有超时限制，玩家正常都能通过的战斗，战斗结束不需要等待验证结果，临时相信客户端，直接发奖。异步队列缓存战斗消息，线程拿不到同步战斗时，开始拿异步战斗，战斗验证结果和预期结果不一致时，通知游戏服务器玩家作弊
- 战斗验证效率
- 普通的pve，主线，竞技场玩法，战斗基本上50~120ms左右跑完
- 大战场GVE，30个英雄一个boss，战斗时长10分钟，验证时长约3s
- 对于多人玩法pvp，gve，战场英雄数量多，本身战斗时间特别长，不适合战斗验证服务器去验证，通过抽帧对比和战斗结果对比的方式验证
六. gof修改
在odin的基础上redis和mongo引入了异步方案
-
jedis 换成 lettuce，天然支持集群，性能提升1倍左右
-
mongo同步驱动换成异步驱动，性能上提升20%左右，虽然性能上没有太大的提升，原有基础上可以节省一步序列化和反序列化
七 . vms和global
公司原有的php版本的vms和global换成java版本，本亮后面会持续的维护和升级，满足后面的项目组使用
-
vms单点压测试： 内网机4c 16g 单台vms的qps建议为1200为参考点
-
global单点压力测试：
内网机4c16g，mongo 8g
无sdk校验时，qps建议为800-900为参考点
有sdk校验(异步延迟20-50ms)，qps建议为400为参考点
八 . 服务器结构图
九 . 当前服务器框架的问题以及需要改进的地方
问题：
- 帧同步服务器和战斗验证服务器需要部署好多台，只能按照最大需求开起，平时利用率低，但是却不能随便减少
改进：
-
线上集群节点增减对有状态的业务有一定的影响，需要想办法规避。
-
弱网问题后面需要处理一下