Apollo多版本集群混部署

[1121206561]

疑问 1：不同版本集群混部署是否支持？

1.3.0 版本是否支持和 2.4.0 版本的服务端 集群混部署，因为我们在升级的过程中需要有更多的时间进行灰度，以及兼容性验证，我们计划先对数据库进行升级，然后3台1.3.0和3台2.4.0的服务端共同搭建一个apollo集群，可以不考虑portal的前端问题，因为我们有独立的前端平台。

疑问 2：Portal 接口是否有替换/不兼容变更？

从 1.3.0 → 2.4.0：
Portal 管理界面的老api是否有参数、返回结构的变化，因为我们有自己独立管理平台，依赖Portal的接口。

[github-actions]

🤖 感谢提问。

您的两个问题已收到：

1. 混合版本集群部署：1.3.0 与 2.4.0 服务端是否能共同组建一个 Apollo 集群进行灰度升级
2. Portal API 兼容性：从 1.3.0 → 2.4.0 升级后，Portal 管理接口的参数和返回结构是否有变化

这些是关于版本升级策略和 API 兼容性的重要问题。建议关注：

• 混合版本部署通常不推荐，因为不同版本的服务端可能存在数据库 schema、内部协议等不兼容问题
• Portal API 在跨大版本升级时可能有不兼容变更，建议查阅 CHANGES.md 中 1.3.0 → 2.4.0 之间的所有版本变更记录
• 如有自研管理平台依赖 Portal API，建议使用官方 OpenAPI（如有）以获得更好的稳定性保障

维护者会根据经验给出更具体的建议。

AI generated by Apollo Issue Triage

[dosubot]

Hi @1121206561! I'm Dosu and I’m helping the apollo team.

疑问 1：1.3.0 和 2.4.0 混合集群部署 — 不建议，存在根本性不兼容

1.3.0 和 2.4.0 共享同一数据库进行混合部署会遇到严重的兼容性问题，主要原因：

• 软删除机制根本性变化（v2.0.0）：1.3.0 仅使用 IsDeleted 标记删除，而 2.4.0 使用 IsDeleted + DeletedAt 时间戳及复合唯一索引。1.3.0 的代码无法正确处理新的删除模式，会导致数据完整性问题 [1]。
• 字段宽度扩展：AppId 从 32 扩展到 64 字符（v1.7.0-v1.8.0），审计字段也同样扩展 [2] [3]。2.4.0 写入的长值在 1.3.0 节点上会校验失败。
• 新增表和列：ServiceRegistry、AuditLog 等新表，以及 Item.Type、AccessKey.Mode 等新列 [4] [5]，旧版本不会填充这些字段。
• 服务间没有版本校验机制：Portal 和 Admin Service 之间通过 REST API 通信，没有强制版本兼容检查 [6]。

推荐升级策略：

1. 按顺序执行所有中间版本的数据库 delta 脚本（1.3.0 → 1.4.0 → ... → 2.4.0），数据库升级期间不需要停机 [7]
2. 严格按照 Database → Config Service → Admin Service → Portal 的顺序升级各组件 [6]
3. 对于生产环境，建议使用影子环境策略：在独立环境中完成升级和验证，验证通过后再切换 [7]
4. 混合版本的窗口期应尽可能短

好消息是 Java 客户端有较好的向后兼容性，1.x 客户端可以连接 2.4.0 服务端，服务端保留了旧版兼容端点 [7]。

---

疑问 2：Portal API 变更 — 存在多项 Breaking Changes

从 1.3.0 到 2.4.0，Portal API 有以下主要不兼容变更：

1. 权限校验方法参数变化 — 新增 clusterName 参数，从 3 参数变为 4 参数且顺序调整 [8]：

• 旧：hasModifyNamespacePermission(appId, namespaceName, env)
• 新：hasModifyNamespacePermission(appId, env, clusterName, namespaceName)

2. 前端端点迁移至 OpenAPI 路径 [9]：

• /envs → /openapi/v1/envs
• /clusters → /openapi/v1/clusters
• 如果有自定义 SSO 集成，需要确保覆盖新的 /openapi/** 路径

3. 返回类型变化 [10]：

• GET /apps/{appId} 返回从 App 变为 AppDTO（含额外用户信息）
• GET /apps/{appId}/miss_envs 返回从 Env 枚举变为 String

4. Namespace 删除端点路径变更 [11]：

• 旧：DELETE /apps/{appId}/envs/{env}/clusters/{clusterName}/namespaces/{namespaceName}
• 新：DELETE /apps/{appId}/envs/{env}/clusters/{clusterName}/linked-namespaces/{namespaceName}

5. Rollback 接口变更 — 新增 toReleaseId 可选参数，且需要用户上下文 [12]

6. 其他变化：错误消息从中文改为英文、分页参数标准化为统一的 PageRequest [13]、新增了配置导入/导出/AccessKey 管理等控制器 [14]。

---

总结：如果你们有独立管理平台依赖 Portal API，升级到 2.4.0 时需要对接口调用做相应适配。建议在测试环境中先部署 2.4.0，逐一验证你们调用的 API 端点是否有变化。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[nobodyiam]

两个问题都已有较详细的分析，我补充一下实践层面的关键点。

疑问 1：混版本部署

不建议。1.3.0 与 2.4.0 共享同一套 ApolloConfigDB 时，会因为软删除机制（v2.0.0 引入了 DeletedAt 复合唯一索引）、AppId 字段宽度扩展（v1.8.0，32 → 64 字符）等多处 Schema 变更导致数据异常，混跑窗口应尽量压缩到最短。

建议升级顺序：数据库逐版本执行 delta SQL → Config Service → Admin Service → Portal。Java 客户端有向后兼容性，服务端升级后不需要同步升级客户端。

疑问 2：Portal API 兼容性

1.3.0 → 2.4.0 存在多处 breaking change（参数签名调整、部分路径迁移至 /openapi/**、返回类型变更等），自研管理平台在升级后需要逐接口验证。建议参考 CHANGES.md 中各版本的变更说明，在测试环境全量回归后再切换生产。

注：本回复由 AI 自动生成并自动发送，用于初步分诊；如需进一步确认，维护者会继续跟进。