游戏上线标准 v0.1.0(后端、前端、QA)

某游戏正式上线标准0.1.0（Client、Server、QA）

• [x] 后端
  • [x] 服务器性能相关
    • [x] 标准A
      • backend 8C16G
      • 同时在线5000人，各事务90%响应时间<1秒，各事务成功率>99.9%
      • 稳定运行72H，无明显资源不稳定问题（如内存泄露、CPU持续飙高），各事务成功率>99.9%
      • 需要关注关键场景如登录、广播业务、多人并发业务（如世界boss）下游戏表现（不能卡顿逻辑线程）
      • jvm必备参数
    • [x] 标准B
      • 明确一组redis和mongo可同时支撑多少组backend
      • 明确redis/mongo不同部署方式（如单机/集群）的性能差异、限制（如集群不能使用一些批量处理命令）等
      • 连接池相关参数调优#You want a small pool, saturated with threads waiting for connections
      • 关注内网带宽和外网带宽是否出现瓶颈，如backend同时执行世界boss、同时执行存储
      • 明确估算单服内存峰值（计算单玩家内存）
      • 明确redis和mongo业务调优，如redis#pipeline、mongo#bulkOps等
      • 内存在线玩家即使未操作也不设置过期，避免数据库操作
    • [x] 标准C
      • 当游戏系统繁忙时，需在用户登录时给予友好的提示，或设计登录排队系统
        • 清楚的定义‘系统繁忙’，如同时在线N人，业务消息队列排队过多等
      • 在出现故障后，限制频繁登录，防止出现雪崩#客户端
      • 明确关服时间，如大量玩家同时在线，是否会关服失败或者时间过长
      • 明确大量玩家同时定时存储的时间，是否会超过定时
    • [x] 标准D
      • 明确日志不会影响业务性能#异步，耗时的打印如protobuf2json异步
      • 关注日志过大引起的磁盘空间问题
      • 明确性能监控工具接入先行
      • 明确公共global和vms的处理能力（PHP）# 线上一个集群共用一组
      • 明确backend非游戏业务性能，不影响业务，如日志收集程序、快照等
  • [x] 服务器架构相关
    • [x] 避免backend单点（后续优化方向是分布式backend）
      • 拆分battle(验算/luajit[内存、错误等]/分布式)，某些业务可尝试本地复盘
      • 可能的公共业务如聊天等独立出来
      • 跨服、匹配、实时PK等独立出来
    • [x] backend内部线程模型必须清楚
      • 玩家主逻辑单线程（hash/玩家消息队列）
      • 玩家与玩家之前数据交互通过线程队列消息投递交互
      • 耗时业务必须异步（不能阻塞玩家业务）或者在其他线程池处理，最好支持异步callback模型
      • 多人业务处理必须优先保证线程安全，其次性能（避免如锁粒度过大）
      • 数据库存储线程必须保证顺序存储，避免覆盖，优先保证存储正确性能，其次性能（如多线程处理）
      • 其他业务线程池需要明确知道作用、问题等如调度线程池、io线程池
      • ThreadLocal需要仔细检查使用，如其他线程用了threadlocal会报空指针，如A玩家线程修改B玩家数据（用的threadlocal的数据是A）
      • 参考原则#Never block the event loop, reduce context-switching
    • [x] 避免backend#crash引起5分钟以上的回档
      • 性能考虑，建议定时存储（5分钟以内）
      • 建议批量存储、增量存储（玩家数据变化才存储）、数据压缩# 保证数据库存储算法准确、性能高
    • [x] 可快速处理合服
      • redis#key必须要带上serverId，1是因为一组redis是多个backend服务，另外处理合服
      • 合服2种（redis/mongo都合、mongo不合）
    • [x] vms/global可平行扩容
    • [x] redis、mongo扩容需要有明确解决方案
    • [x] 多语言版本需无缝迁移
    • [x] 必须支持热更新，大部分业务bug均可热更解决，需要明确热更限制（如新增属性、内部类等）、问题（如内存泄露等）
    • [x] 必须支持配置表热更、配置热更、开关热更（如日志的开关）等
    • [x] 必须支持动态查询或者修改服务器内存的能力（如bsh等）
    • [x] 需要有弱网解决方案
    • [x] 建议支持动态agent如btrace、jvm-sandbox
    • [x] 必须可防外挂（篡改、重发等）、防攻击（防洪水）
  • [x] 服务器业务设计相关
    • [x] 明确防御式编程/契约式编程#The Server is the Man#CodeReview
      • 客户端请求参数必须’强校验‘
      • 关键逻辑内每个方法都要try/catch，避免一个方法抛出异常影响其他逻辑，如登出各逻辑模块处理、调度各逻辑模块处理#写代码要想’这个方法抛出异常怎么办‘
      • 关键逻辑内的null判断，如不能因为日志打印抛空中断业务逻辑#写代码要想’这个地方为null怎么办‘
      • 必须要兼容老玩家数据，如上线新功能，老玩家无法登录
      • 严格检查循环、递归等业务逻辑，必须时增加’防御式跳出逻辑‘
      • 复杂的代码逻辑必须要拆分多个方法、避免大段、冗长的代码
      • 资源增减逻辑必须遵循’先扣后加、检查负数、避免溢出‘，必须在代码层面避免’刷资源‘问题
      • 非游戏主逻辑（如日志、http上报）问题（异常、超时等）一定不能影响主游戏逻辑
      • 线程池的任务一定要try/catch，避免抛出异常线程终止
    • [x] 需要清楚的熟悉线程模型，当前代码运行在哪个线程下
    • [x] 缓存#redis使用要慎重，规避redis的高CPU占用、慢；要处理过期
    • [x] 数据库#mongo#规避频繁的离线玩家数据库数据修改，也不建议直接修改离线玩家数据（GM除外）
    • [x] 不能滥用事件系统，监听器必须只监听感兴趣的事件
    • [x] 多人业务要注意线程安全问题（加锁、锁粒度、消息队列投递、threadlocal）
    • [x] http三方接口必须要处理超时或者异步，避免阻塞主逻辑线程
    • [x] sdk
      • 确保登录、支付、推送无任何业务、性能问题
      • 登录一定要异步或在单独线程池处理
      • 登录等相关逻辑’顶号、踢人，重连、token过期‘无明显问题
      • 支付逻辑要实现’无丢单 、无刷单，可补单'，详细的充值记录‘、解决ios#黑卡、坏单#退单等
      • 推送一定不要影响阻塞主逻辑，需要确认是否耗时
    • [x] 业务内的唯一id生成算法需要做压测，避免可能的重复#需要检查使用场景
    • [x] uid需要做混淆处理
  • [x] 服务器Devops相关
    • [x] 明确版本管理#分支模型
      • master/develop、pre-release、online、features、hotfix
      • 明确git操作规范（如熟悉运用merge/stash/cherry-pick等、以及各种最佳实践-changelog...）# 正确的代码提交和合并
    • [x] 版本发布
      • 停服更新、不停服更新、前端patch/gsp、后端热更、灰度、审核服、混服等（game、battle、global、vms...）# 通用流程
      • 自动开服、关服、维护
      • 线上正式集群与平台划分#根据channel获取平台
      • 有确定的master/pre-release/online测试集群
    • [x] 支撑接入
      • 日志收集、查询、业务监控
      • 运营GM、BI
  • 运营活动可通过后台配置
    • [x] 要有停服公告机制#global服务不能crash，不能stop/restart
    • [x] 明确全服回档、个人回档的解决方案和处理办法
    • [x] 玩家数据目前数据库存储是压缩，需要明确运营临时需求解决方案（玩家常用字段不压缩、利用BI统计日志查询、单独写工具从库统计#解压，部分需求可bsh内存查询）
  • [x] 服务器线上解决方案相关/事故#需要快速发现和解决
    • [x] 玩家登录超时（尤其是刚上线开服）
    • [x] 玩家卡（如持续转菊花超时）、CPU飚高
    • [x] 刷资源（策划配错表、业务逻辑bug）#回档
    • [x] 账号登录异常、老玩家无法登录
    • [x] 运营临时需求如做一些统计
    • [x] OOM-Killer、内存溢出、内存泄露
    • [x] 宕机#如宿主机挂了(vms/global/game/battle)
    • [x] 机房网络故障
    • [x] 数据库故障、磁盘故障
    • [x] 快速反应工具（如导号、bsh、监控、客户端直接线上等...）
    • [x] 通用buglist、通用checklist、reviewlist
    • [x] 外挂
    • [x] 洪水攻击
• [x] 前端
  • [x] 性能
    • [x] 内存消耗
    • [x] 帧率
    • [x] CPU占用
    • [x] 流量消耗
    • [x] 包体
    • [x] 弱网处理
    • [x] crash率
    • [x] 发热
    • [x] 耗电
    • [x] 适配
    • [x] https/ipv6支持
  • [x] 安全
    • [x] 客户端加密、混淆、无明文
    • [x] 客户端外挂#如修改内存
    • [x] log无输出敏感信息
    • [x] 变速
    • [x] 修改时间
    • [x] 异常上报#symbol
    • [x] 安装包监测
  • [x] 接入
    • [x] 报错、crash接入如bugly
    • [x] 增量、全量、gsp
    • [x] 小包、马甲包
    • [x] 多语言解决方案
    • [x] ios/android审核流程
  • [x] 业务
    • 不能卡死，如收到服务器大量广播消息
    • 不能卡新手引导
    • 不能无法点击
    • reviewlist
      • 如网络层相关check（弱网、重连、切后台、电话...）
      • 切后台/锁屏/Home/网络切换
• [x] QA
  • [x] 版本管理
  • [x] 版本发布流程
  • [x] 版本记录
  • [x] buglist
  • [x] checklist
  • [x] 客户端性能测试、服务器端压力测试、网络测试、安全测试