任何一件事情在完成之前，都需要做一个checklist，从而检查错误，规避风险
对于游戏发行流程中，除了前期的渠道接入/测试等，首发上线是最后一公里的保障：
- 版本验收
- 渠道工作凑备
- 服务器策略
- 社区运营
- 其他内容（游戏公告/游戏资源等）
抛开业务层面来看，其实游戏的首发，对发行后端影响最深的，就是伴随而来的突发首发流量对系统的冲击。
我们先来分析下游戏首发时的流量情况： 不管是游戏首发，还是游戏活动，都会有三个关键词：
- 瞬时流量
- 热点接口
- 核心路径
首发/活动 的一般形态是集中在当天的某个时间节点（比如首发是早上的9/10点），这个时候玩家会打开游戏，完成登陆进服，给用户系统带来一个瞬间流量高峰。在首发这个场景之中，核心的路径，也就是核心的场景就是“激活-登陆-进服”，热点接口包括：激活、登陆、游戏进服
针对游戏发行的一个模型如下：
首发前准备
应对首发带来的瞬时流量，最需要做的，就是机器容量的扩容。未上云之前，机器的单位更多是服务器的数量，上K8s之后，单位用容器来计算更加贴切，大致的公式：
机器/容器数量 = （峰值流量 x 冗余系数）/ 单机器/单容器容量
可以看出，怎么做好容量预估，需要留意两个指标：
- 流量预算：瞬时流量有多少，对应的峰值流量大概会是多大，首发相对简单一些，用户量跟运营推广的曝光导量计划有直接的关系，根据以往的转化率可以得出各个节点的数据情况，以此数据推算出各个节点的峰值流量
- 容量评估：每个机器/容器 能够承载的容量是多少，这个就需要前置对系统有做压力测试，知道每个节点单机容量的极限
针对这两个指标，我们主要做的事情就会汇总成两个：
- 分析当前场景下的流量模型，通过流量预算得到我们所需要承受的峰值流量以及作为扩容的依据，这个过程是自上而下的
- 制定符合场景的压测策略并执行、输出压测报告，得到每个服务、容器的容量极限，从而得到需要扩容的机器/容器数量，这个过程是自下而上的
流量预算
流量预算离不开对应业务的流量模型分析：
在首发场景中，用户首次下载游戏，需要对游戏资源做一定的初始化，然后通过SDK注册/登陆成功之后，进行选服进服操作，完成进入游戏的流程。
这一整个流程对应的业务核心路径的系统架构图整合如下，做个简单的分析描述：
- 下载并打开游戏，SDK初始化，做一定的配置初始化
- 在SDK初始化完成之后，因为是刚下载的游戏，还会有一个比较重要的中间流程：游戏资源加载，虽然不涉及到API的调用，但是也实实在在影响后续的游戏运行
- 初始化工作完成之后，玩家开始与SDK做交互，国内海外用户习惯不同，会有不同登入方式，但是都是这两个行为：register 、login ，当然可能会涉及到一些非核心模块的接口请求，包括但不仅限于 绑定登陆方式、绑定手机/邮箱等，但是不是必须的，当然这些入口本身是已经有开关控制的，极端情况下也能提供降级策略
- SDK登陆完成之后，玩家可以开始选服进入游戏，之后会更多涉及到与游戏本身交互的过程
上面梳理了游戏首发的不同子场景下的接口调用情况以及调用顺序，不同于其他电商 / 社交场景，在大多数情况下，子场景的关系会是： 激活 ≈ 登陆(三方+自营) ≈ CP交互 ≈ 1/2 数据上报 （可以通过一些更准确的分析工具/代码，梳理接口依赖的服务以及服务调用次数：github.com/dianping/ca…
有了上面的数据，就可以输出对应的调用模型了，可以分为服务 / 接口两个维度：
接口调用模型（基于架构，调用次数作为权重的图）/ 服务调用模型
| 服务 | API | 访问次数 |
|---|---|---|
| 业务网关 | 1k | |
| A服务 | /aa | 300 |
| 日志上报 | /report | 400 |
| B服务 | /b1 | 200 |
| /b2 | 200 | |
| /b3 | 200 |
缓存/DB 调用模型
当进来的峰值流量为1，此时的流量构成如下：
| cache | 访问次数 |
|---|---|
| cache | 访问次数 |
| cache1 | 2k |
| cache2 | 3k |
| 数据库 | 访问次数 |
|---|---|
| database1 | 3k |
扩容计划汇总
此时，结合运营提供的导量数据分析，可以推算出首发场景下每一个应用节点可能会达到的最高流量。
最终能提供给到运维的扩容计划表会是这个样子：
| 场景 | 服务 | 单机/Pod容量 | 峰值流量 | 需要提供的集群容量 | 当前机器/Pod数量 | 需要扩容的机器/Pod数量 |
|---|
容量评估
要知道在当前流量下，系统怎么更精准进行扩容，那就离不开对各个应用 / 服务进行容量评估 —- 压力测试，以此来获取单机/ 单Pod的容量
压测之前，有几个点你需要知道：
-
压测策略
- 压测目的 ：与常规压测不同的是，特殊场景下进行压测的目的，是找到系统针对混合场景的最大处理能力，但是在常规压测情况中，主要是查看系统各个指标是否符合预期以及在高并发场景下功能/数据是否正确
- 压测环境：选择一个符合场景的压测环境很重要，但是很多情况下，我们本身的测试用的BETA 环境 、预发布PRE环境或者是线上PROD环境，都或多或少存在不适用的情况，比如测试环境跟线上环境所依赖的服务差异，预发布环境是比较理想的，但是压测产生的数据会影响数据分析，线上环境是用户使用的环境，存在风险。
-
压测过程
- 压测方法
- 压测场景：场景是很重要的，需要将首发场景各个接口/服务按照实际发生的比例进行组合捆绑，才能得到首发场景下的相对真实的数据表现
- 压测数据：压测的数据来源可以是利用TCPDump去做流量的重放，或者根据线上的nginx access log 来做日志回放，甚至可以是相关同事提前编写符合要求的数据
-
压测结论
- 数据采集
- 监控告警
