整体概述参见：StickEngine 架构总览
弹性计算的核心目的
降低成本。要实现弹性计算，至少需要两大块协作：游戏进程侧的自动伸缩和云计算平台的可编程扩展。
本文案例场景：和平精英、王者荣耀这类开房间式游戏，部署在腾讯云。从以下几方面展开：
费用成本分析
➜
方案选型
➜
StickEngine 实践
➜
效果验证
费用成本分析
这本质上是一道数学题。腾讯云的两种计费模式：
| 计费模式 | 规格 | 价格 | 折算时价 |
|---|---|---|---|
| 包月 | 4 核 8G | 385 元/月 | ~0.53 元/小时 |
| 按量（秒级） | 4 核 8G | 0.71 元/小时 | 0.71 元/小时 |
24 小时在线人数曲线（绿色）vs 包月费用线（黄色）
什么时候按量计费更划算？
人数曲线和费用曲线均为连续可导函数。成本对比转化为：包月矩形面积 vs 按量曲线面积之比。按上述单价，若按量计费的曲线面积低于矩形面积的 74%，按量计费才更划算。
实际还需考虑：新申请机器到可用存在分钟级延迟、游戏推广计划等因素。
方案分析
k8s + Docker
- 弹性计算领域成熟组合
- 游戏进程可 docker 化，进程本身无状态
- docker 启动快，但受木桶效应影响，整体仍是分钟级
- 资源池储备充足时，启动速度更有优势
StickEngine 自建
- HTTPS API 与云平台交互
- 游戏战斗包含大量状态和本地计算结果
- 进程迁徙需要精确且复杂的控制逻辑
- 更灵活的自定义伸缩策略
StickEngine 自建方案实践
控制中心是 CenterServer 进程，负责服务发现、进程控制等职能，弹性计算的控制逻辑也在该进程中运行。
CenterServer 控制台 — 全局负载监控、自动伸缩控制、人工控制
三种负载状态
任意一次快照下，系统负载分为三种状态，只有过载或低负载时才触发伸缩控制：
✅ 正常
负载在阈值范围内
不触发任何操作
不触发任何操作
⚠ 过载
负载超过上限
触发扩容
触发扩容
❄ 低负载
负载低于下限
触发缩容
触发缩容
无状态设计
CenterServer 本身不持有历史状态，三个状态仅描述当前快照的操作判断。好处：center 进程可以随时启停，不依赖系统历史状态，灵活性强。
为实现无状态设计，StickEngine 去掉了 DB，简化为云平台与游戏进程之间的二元数据协调。关键做法：将云平台的自定义状态存储在云主机的 name 字段中（腾讯云最长 60 个字符）：
利用云主机 name 字段存储状态信息，省去 DB
过载与低负载处理
❄ 低负载 → 缩容
先屏蔽进程并加入可用资源池
后续根据情况：销毁 / 继续驻留 / 复用
后续根据情况：销毁 / 继续驻留 / 复用
可用资源池
响应速度
新申请机器到可用约需 3 分钟，资源池可实现秒级释放。
成本优化
复用已申请的机器比频繁申请新机器能减少更多固定成本。
单台云主机状态与转换
云主机状态机 — New / Running / Disable / Destroy
四种状态
New
新申请，未初始化
新申请，未初始化
Running
运作中
运作中
Disable
资源池 / 清空中
资源池 / 清空中
Destroy
待退库
待退库
New → Running：初始化完成，连接 CenterServer
Running ⇆ Disable：缩容时进资源池 / 过载时从资源池释放
Disable → Destroy：资源池中决定销毁
实际操作中无法完全严格遵循状态图——宕机、数据异常、网络异常、欠费等情况都会导致逻辑混乱。StickEngine 对此补充了兜底规则：
新申请的云主机 5 分钟后仍未切换到 Running，强制重启若干次
新申请的云主机 10 分钟后仍未切换到 Running，直接销毁
云主机名字不符合规则，直接销毁
云主机的初始化
每个进程启动命令行不同，机器配置和 IP 也各不相同。云主机申请成功后通过启动脚本，HTTP 访问 CenterServer 获取该机器的相关信息完成初始化。虚拟机通过获取自身 IP 作为标识符进行交互。
总结
-51%
弹性计算 vs 包月计费，服务器机器成本降低
核心经验
- 无状态设计和不可靠场景下的健壮性处理贯穿了众多细节，规避常见的故障转移、恢复和一致性事务问题
- 若干实施细节可引入更多数学建模优化：伸缩时机引入机器学习辅助决策、可用资源池的最优性价比、多维度负载一维化度量与降噪
- 还可以引入 docker 等方式进一步加快扩容速度