升级到 API7 Enterprise 3.x.x
本指南介绍了将 API7 Enterprise 从旧版本升级到最新版本的过程。您可以根据 API7 Enterprise 的部署架构确定升级路径。此外，本文档还解释了升级过程中需要考虑的重要因素以及如何备份和恢复数据。
API7 Enterprise v3.x.x 版本之间的升级主要涉及 控制平面 (CP) 和 数据平面 (DP) 的更新。由于所有 v3.x.x 版本都保持架构兼容性，本文档将指导您完成以下升级策略：
升级概述
API7 Enterprise 的升级通常分为两个阶段：准备阶段 和 实施阶段。
准备阶段
执行升级
完成准备阶段并确认一切正确后，您可以按照在测试环境中执行的流程开始升级生产环境。
保证升级路径
API7 Enterprise 版本号遵循标准语义结构，以 a.b.c 为例，表示主版本 (a)、次版本 (b) 和补丁版本 (c)。默认情况下，API7 Enterprise v3 已在以下版本之间进行了升级测试，以确保升级过程顺利进行：
- 同一主版本和次版本内的补丁版本之间的升级，例如 (
3.3.0到3.3.1)。 - 同一主版本内相邻次版本之间的升级，例如 (
3.3.x到3.4.x)。
虽然 API7 Enterprise 已进行了升级测试，但您仍应遵循文档中的步骤，在应用升级之前在您的环境中进行测试。
数据备份策略
在执行升级之前，请确保您已 备份 数据库和声明式配置文件。
- 数据库备份：API7 Enterprise 默认使用 PostgreSQL 数据库。您可以使用 原生导出 (
pg_dump) 和导入 (pg_restore) 命令来备份或恢复数据库。 - 声明式配置文件备份：API7 Enterprise 提供声明式管理工具 ADC，支持通过声明式配置文件管理 API7 Enterprise 的服务、路由、消费者、插件和其他配置。
强烈建议尽可能使用两种方法来备份数据，因为这为数据恢复提供了灵活性。如果您在测试升级过程中遇到任何问题并需要立即回滚，请参考 备份和恢复 指南来恢复您的旧数据。
升级策略
建议按照本指南中描述的升级策略完成升级。
在升级过程中，您应该考虑 API7 Enterprise 的停机时间并制定合理的升级计划，因为在升级过程中您无法通过 API 或 Dashboard 修改或更新数据。
下面的图表解释了整个升级过程的工作原理：
CP 就地升级
在升级 DP 之前，必须先升级 CP。CP 与数据库交互，因此在升级过程中请不要使用 API 或其他方法更改当前数据。下面的图表显示了就地升级策略是如何实现的。
- 当前的
CP A直接替换为CP B，在升级过程中共享同一个数据库。 - 升级完成后，当前
DP A中的节点将自动连接到新的CP B。
在控制平面 (CP) 升级过程中，DP A 中的节点与 CP A 或 CP B 保持连接，如图表所示。API7 Enterprise 确保较新的 CP 次版本与较旧的 DP 次版本之间的兼容性。因此，当运行不同的 CP 和 DP 版本时，请在 CP 的 网关实例 页面上检查每个 DP 节点的状态，并按照提示升级任何标记为不兼容的 DP 节点。
建议在每次升级时保持 CP 和 DP 版本一致，以确保一切正确。
DP 滚动升级
CP 升级完成后，您可以继续升级 DP 节点。对于 DP 升级，建议使用滚动升级方法，因为它可以避免停机时间。下面的图表显示了滚动升级策略是如何实现的。
- 新的
CP B重用当前数据库，当前的DP A继续处理 API 请求。 - 使用滚动升级，逐步将
DP A中的节点替换为DP B中的新节点。新DP B中的节点更新后，它们也处理 API 请求。
检查破坏性变更和变更日志
根据当前版本和升级目标版本，确认版本之间的 所有破坏性变更 和 变更日志。根据变更日志中的提示提前准备和调整您的配置。
升级注意事项
无论您如何部署 API7 Enterprise，都有一些影响升级过程的通用因素。在开始升级之前，请注意：
- 在升级过程中，禁止对数据库进行任何更改。在升级完成之前，请勿通过 API 或 Dashboard UI 修改任何数据。
- 请仔细查看当前版本和升级目标版本之间的 所有变更日志，特别注意 破坏性变更。检查任何潜在的冲突，如功能移除、API 更改等。
- 如果您有自定义插件，请检查 变更日志 中是否有任何核心修改，并在测试环境中使用新版本测试您的自定义插件，以确保它们正常工作。
- 数据库备份 始终是强制性的。请确保在每次升级之前备份您的数据。