更新策略

更新策略决定运行副本如何替换。Operator 或 Admin 在应用配置中设置这些字段；它会影响配置更新和重启等需要重新创建容器的操作。

字段与默认值

观察时间不是两批更新之间固定等待的延迟，也不是业务就绪检查。应用需要业务响应验证时配置 XHealth 或 Guardian。

选择更新顺序

StopFirst 先停止旧实例，额外容量需求较低，但单副本应用可能中断服务。

StartFirst 先启动新实例，新旧副本可能短暂重叠。它需要足够资源和可用调度位置，应用本身也必须允许并行运行。仅选择 StartFirst 并不能保证零停机，尤其当进程运行后仍需要较长初始化时间时。

使用本地数据的数据库应特别注意同一数据目录的并发访问。不要未经确认让新旧数据库进程同时操作同一份数据。

选择并行度与失败动作

多个无状态副本可使用较小并行度，逐批替换并观察业务。并行处理全部副本会扩大一次变更的影响范围。

回滚不恢复业务数据，也不提供任意历史版本选择。当前回滚执行时并行处理全部副本，失败动作是继续，继承更新顺序、观察时间和失败比例；不能假定回滚与正向更新的并行度完全相同。

修改策略前检查

1. 当前应用是否有足够副本承担业务。
2. 服务器是否能容纳新旧实例重叠。
3. 每台服务器副本上限和标签是否允许更新。
4. 应用启动、连接排空和数据兼容是否满足所选方式。
5. 是否需要启用发布验证。

保存后先在可控环境验证一次版本更新，观察副本替换、请求错误和日志。出现等待时检查资源与调度，不要只修改并行度。