操作/升级政策
升级政策
v1.2.x · 已更新 2026-08-04
稳定性是产品原则，而不是事后考虑。AiHummer 遵循这一原则 语义化版本，适用 自动前向安全的数据库迁移，并且可以 自我更新 来自CDN — 因此升级是常规操作而非高风险操作。
版本控制（语义化版本）
版本发布遵循语义化版本控制。版本由…报告 /healthz 以及由 aihummer version，因此您可以在升级前后随时确认正在运行的内容。
迁移是向前安全且自动的
在启动时，网关会自动应用待处理的数据库迁移。有两个属性可以保证这一过程的安全：
- 向前安全。 迁移是为了使更新的二进制能够对应
它迁移到的模式，这就是使自动应用和滚动升级安全的原因。
- 通过咨询锁的单一应用者。 迁移在……下运行 PostgreSQL
建议锁所以当几个网关同时启动时，只有一个会应用它们
其他的等待——绝不重复迁移。
[!NOTE]
迁移总是在拥有者数据库池上运行。受限的 RLS 角色
(AIHUMMER_DB_APP_URL) 是用于处理流量的，而不是用于模式更改。
更新
新版本从供应商的发行 CDN 拉取。受支持的更新方式是在服务器上执行一条命令：
aihummer update --check # report whether a newer version is available
aihummer update # download and apply the update
--check 不写入任何内容，因此不需要 root 权限。而应用更新会重写安装根目录并重启服务，所以要通过 sudo 执行。
预期结果： --check 打印当前版本与可用版本，随后退出，不做任何改动。aihummer update 下载构件，校验其 sha256 校验和与 cosign 签名，替换二进制文件并重启服务；之后 aihummer version 会显示新版本。若校验未通过，更新会在替换文件之前中止：正在运行的版本保持不变。
[!NOTE]
自动更新由供应商开启，而不是由您开启。 自动更新的模式与时间安排属于发行版维护的一部分，
由供应商的签名指令设定。无论是在 Web 界面还是在 aihummer settings 中都没有对应的开关；
写进 gateway.env 的自动更新变量网关不会读取——即使您在那里看到它们，也不起任何作用。
若要按自己的节奏更新，请使用上面的 aihummer update 命令。
回滚
逐项来看，哪些内容可以回滚：
- 二进制文件 — 可以退回到上一个版本（先前发行版的构件仍保留在 CDN 上；重新安装您需要的版本即可）。
- 数据库架构 — 迁移是前向安全的，因此旧版二进制文件也能在较新的架构上工作；不存在单独的架构回滚。
- 插件 — 版本按安装实例管理；如有需要，可从目录中把某个插件退回到先前版本。
- 配置 — 更新不会改动它；必要时从备份中恢复。
零停机部署
AiHummer 设计为可在不中断的情况下升级：
- 在代理后运行 2 个以上的网关。 一次投掷一个；准备探针
(
/readyz) 会将正在重启的节点保持在非轮换状态，直到它开始提供服务。
- 调度器是单主节点的。 后台调度选举一个领导者
通过 PostgreSQL 顾问锁，因此运行多个网关不会重复
计划工作
- 交付是幂等的。 可靠的投递加上幂等键意味着
回复永远不会在重启时发送两次，这就是滚动的原因
安全地重新启动您的网关。
接下来去哪儿
稳定性是产品原则，而不是事后考虑。AiHummer 遵循这一原则 **语义化版本**，适用 **自动前向安全的数据库迁移**，并且可以 **自我更新** 来自CDN — 因此升级是常规操作而非高风险操作。
## 版本控制（语义化版本）
版本发布遵循语义化版本控制。版本由...报告 `/healthz` 以及由 `aihummer version`，因此您可以在升级前后随时确认正在运行的内容。
## 迁移是向前安全且自动的
在启动时，网关会自动应用待处理的数据库迁移。有两个属性可以保证这一过程的安全：
- **向前安全。** 迁移是为了使更新的二进制能够对应
它迁移到的模式，这就是使自动应用和滚动升级安全的原因。
- **通过咨询锁的单一应用者。** 迁移在……下运行 **PostgreSQL
建议锁**所以当几个网关同时启动时，只有一个会应用它们
其他的等待——绝不重复迁移。
> [!NOTE]
> 迁移总是在拥有者数据库池上运行。受限的 RLS 角色
> (`AIHUMMER_DB_APP_URL`) 是用于处理流量的，而不是用于模式更改。
## 更新
新版本从供应商的发行 CDN 拉取。受支持的更新方式是在服务器上执行一条命令：
```bash
aihummer update --check # report whether a newer version is available
aihummer update # download and apply the update
```
`--check` 不写入任何内容，因此**不需要 root 权限**。而应用更新会重写安装根目录并重启服务，所以要通过 `sudo` 执行。
**预期结果：** `--check` 打印当前版本与可用版本，随后退出，不做任何改动。`aihummer update` 下载构件，校验其 sha256 校验和与 cosign 签名，替换二进制文件并重启服务；之后 `aihummer version` 会显示新版本。若校验未通过，更新会在替换文件**之前**中止：正在运行的版本保持不变。
> [!NOTE]
> **自动更新由供应商开启，而不是由您开启。** 自动更新的模式与时间安排属于发行版维护的一部分，
> 由供应商的签名指令设定。无论是在 Web 界面还是在 `aihummer settings` 中都没有对应的开关；
> 写进 `gateway.env` 的自动更新变量网关**不会读取**——即使您在那里看到它们，也不起任何作用。
> 若要按自己的节奏更新，请使用上面的 `aihummer update` 命令。
### 回滚
逐项来看，哪些内容可以回滚：
- **二进制文件** — 可以退回到上一个版本（先前发行版的构件仍保留在 CDN 上；重新安装您需要的版本即可）。
- **数据库架构** — 迁移是前向安全的，因此旧版二进制文件也能在较新的架构上工作；不存在单独的架构回滚。
- **插件** — 版本按安装实例管理；如有需要，可从目录中把某个插件退回到先前版本。
- **配置** — 更新不会改动它；必要时从备份中恢复。
## 零停机部署
AiHummer 设计为可在不中断的情况下升级：
- **在代理后运行 2 个以上的网关。** 一次投掷一个；准备探针
(`/readyz`) 会将正在重启的节点保持在非轮换状态，直到它开始提供服务。
- **调度器是单主节点的。** 后台调度选举一个领导者
通过 PostgreSQL 顾问锁，因此运行多个网关不会重复
计划工作
- **交付是幂等的。** 可靠的投递加上幂等键意味着
回复永远不会在重启时发送两次，这就是滚动的原因
安全地重新启动您的网关。
## 接下来去哪儿
- 控制滚动重启的探针：
[systemd 和健康检查](/zh/v1.0/operations/systemd-health).
- 在进行重大升级之前备份：
[备份与灾难恢复](/zh/v1.0/operations/backups-dr).
- 观看推出：
[可观测性](/zh/v1.0/operations/observability).
