开发流程与 Apollo 框架
准备工作做完，正式进入 Apollo 开发前，先建立两个全局认知：从入驻到上线的四个阶段，以及 Apollo 集群的六大服务。理解了这两点，后面的开发才不会迷路。
四个阶段
从入驻到上线，分四个阶段：
准备阶段 ──▶ 开发阶段 ──▶ 审核阶段 ──▶ 上线阶段
成为开发者 开发机上开发 发放正式物理机 正式物理机运营
入驻+开发机 提审(10工作日) 搭建+提审通过 维护+申请推荐| 阶段 | 做什么 | 机器 |
|---|---|---|
| 准备 | 成为开发者、入驻申请、提供固定 IP + 公钥获取开发机 | — |
| 开发 | 在开发机上部署、开发游戏内容；完成后在平台发布游戏提审 | 开发机 |
| 审核 | 提审通过后官方发正式物理机，在其上搭建正式环境再提审 | 正式物理机 |
| 上线 | 用正式物理机保证性能，日常维护，可申请上新/推荐增加曝光 | 正式物理机 |
两个审核周期
开发阶段提审后官方 10 个工作日内给结果。审核通过发正式物理机，正式环境搭好再提审、通过即上线。
Apollo 框架：六大服务
Apollo 是多进程集群，六类服务各司其职。理解每类服务的职责，才知道自己的功能该写在哪：
| 服务 | 全称 | 职责 | 开发者能开发吗 |
|---|---|---|---|
| DB | 数据库 | 全局存储，所有游戏服共享（Redis/MySQL/MongoDB） | 配置选型 |
| proxy | 代理服 | 加解密、压缩、登录认证、消息转发、维持连接 | ❌ 不可开发 |
| game | 游戏服 | 承载具体玩法，一个玩家同时只在一个 game 或 lobby | ✅ 玩法开发 |
| lobby | 大厅服 | 大厅功能（选服 NPC、副本入口等） | ✅ 大厅开发 |
| master | 控制服 | 管理其他服，全服单点，对外提供 HTTP（GM 指令入口） | ✅ 运营指令 |
| service | 功能服 | 分布式单点服务（公会、全服 boss、全服匹配） | ✅ 全局功能 |
DB 怎么选
- Redis：缓存临时数据，如玩家在线状态、当日在线时长
- MySQL / MongoDB：持久化存储游戏数据
按需求自选，可组合使用。
master 的 HTTP 与 GM 指令
master 对外提供 HTTP 服务，是运营指令（GM 指令）入口。以禁言为例：
- 开发者用 HTTP 给 master 发禁言请求
- master 把禁言信息记录到 DB，再通知玩家所在服禁止发言
- 玩家下次登录时从 DB 读禁言信息，判断能否聊天
service 的分布式单点
service 处理跨服的全局逻辑。以全服匹配为例：
- lobby1 / lobby2 的玩家申请匹配 → 向 service 提交
- service 维护匹配队列，定时按等级、战力匹配
- 匹配成功后把玩家分配到指定的 pvp game 服
一个完整需求示例
需求：玩家在大厅签到领奖，可玩「起床战争」和「对战 PvP」（一场最多 2 人、等级差 ≤ 2），并提供禁言指令。开发者要写的 Mod 分工：
| 服 | 开发内容 |
|---|---|
| master mod | 禁言指令：记录到 MySQL，通知玩家所在服 |
| service mod | 全服匹配：维护队列，按等级匹配，分配到 pvp 服 |
| lobby mod | 签到（MySQL 记录）、两个选服 NPC（进起床战争 / 申请匹配）、禁言生效 |
| game mod | 起床战争、对战 PvP 玩法；接收禁言消息；登录读数据判断禁言 |
引擎做什么、你做什么
玩家分配到哪个 lobby、HTTP 请求接收转发、切服底层——这些引擎（Apollo 框架）自动完成；签到逻辑、匹配算法、玩法、禁言处理——这些你的 Mod来实现。分清边界，只写业务逻辑。
理解了框架，下一篇服务器 Mod 结构——网络游戏 Mod 的目录到底长什么样。回到基岩版网络游戏首页。