App Bootstrap 生命周期设计

这篇文档解决的是 Apollo 装配体系里的另一块关键拼图：

一个 app 从读取配置到启动模块，再到关闭回收，这条生命周期应该如何统一。

如果这层不统一，Apollo 很容易继续维持当前这种状态：

每个 app 自己写启动顺序
每个 app 自己写关闭顺序
模块初始化点散落
运维和调试入口接入时序不一致

一、设计目标

这层设计要解决 6 个问题：

app 启动顺序如何统一。
module / starter / profile 何时解析。
runtime、ops、platform、domain 何时初始化。
health / telemetry / console 何时开放。
关闭流程如何统一。
失败回滚如何统一。

二、参考来源

1. 参考 Spring Boot 启动链

参考点：

bootstrap 统一入口
环境准备先于组件装配
生命周期阶段清晰

不照搬点：

不做反射式自动注入
不依赖容器隐式管理全部对象

2. 参考 KBE 的显式宿主初始化

参考点：

宿主初始化顺序很重要
网络、脚本、实体定义、运行时顺序不能乱

不照搬点：

不把全部运行时深度绑死在某一种脚本语言上

三、为什么这样设计

Apollo 后面的 app 已经不只是简单 main 函数：

gateway-app
login-app
base-app 目标语义是 BaseApp(PlayerAnchor Host)，不是数据库服务同义词
world-app 当前仓库阶段可先由 apps/cell-app 承担其装配壳
db-app / persistence-app

都会逐渐依赖：

runtime host
ops host
platform foundation
game foundation
domain components

如果生命周期不统一，starter 再漂亮也没有用。

四、优点

app 启动顺序可预测
模块初始化时机一致
失败回滚可统一处理
运维/调试/遥测接入点清晰
更容易写集成测试

五、代价与风险

bootstrap 设计会变成框架核心之一
初期会比“main 里手写几行初始化”复杂
如果阶段划分过细，会导致接入成本上升

六、为什么不选其他方案

不选“每个 app 自己定义生命周期”

因为这会让同一个框架里的 app 行为越来越不一致。

不选“只有 initialize / shutdown 两阶段”

因为 Apollo 已经有：

config
starter
registry
telemetry
health
runtime
domain

两阶段不够表达。

七、推荐生命周期阶段

建议 Apollo 的 app bootstrap 统一成 9 个阶段。

1. BootstrapArgs
2. EnvironmentPrepare
3. ProfileResolve
4. ModuleResolve
5. HostBuild
6. ModuleInit
7. ReadyExpose
8. Running
9. Shutdown

八、各阶段说明

1. `BootstrapArgs`

职责：

读取命令行参数
读取 app 名称
确定配置目录
确定 profile

2. `EnvironmentPrepare`

职责：

初始化最小日志
初始化配置加载器
初始化基础错误处理
初始化 pidfile / process guardian 的最小能力

3. `ProfileResolve`

职责：

解析 profile
应用环境覆盖
选择 starter
选择脚本后端
选择平台后端

4. `ModuleResolve`

职责：

加载 starter 默认模块
查询 ModuleRegistry
展开依赖
检查冲突
生成拓扑顺序

5. `HostBuild`

职责：

创建 ApplicationHost
创建 RuntimeHost
创建 RuntimeOpsHost
组装基础容器

6. `ModuleInit`

职责：

初始化 platform foundation
初始化 game foundation
初始化 domain components
按拓扑顺序初始化模块

7. `ReadyExpose`

职责：

打开 health check
注册 console 命令
打开 telemetry exporter
标记 systemd/supervisor ready

8. `Running`

职责：

进入主循环
处理信号
处理管理命令
处理热更/调试请求

9. `Shutdown`

职责：

停止接收新请求
下线 domain components
flush 状态和日志
释放 host 和模块
删除 pidfile

九、推荐对象模型

如果后续要把 bootstrap 做成统一标准，还需要同步约束几件事：

base-app 的 bootstrap 必须围绕 PlayerAnchor / SessionLocator / WorldAssignment
world-app 的 bootstrap 必须围绕 WorldHost / MapInstance / WorldSession
db-app / persistence-app 的 bootstrap 必须围绕 Repository / UnitOfWork / SaveCoordinator

也就是说，bootstrap 统一的是生命周期，不是把不同语义的进程又混成一个大壳。

AppBootstrap
    ├── BootstrapContext
    ├── EnvironmentLoader
    ├── ProfileResolver
    ├── ModuleResolver
    ├── HostBuilder
    ├── LifecycleCoordinator
    └── ShutdownCoordinator