您正在查看 Apigee 和 Apigee Hybrid 文档。
查看 Apigee Edge 文档。
Apigee 提供许多不同类型的资源，每种类型都有不同的用途。某些资源只能通过 Apigee 界面、Apigee API 或使用 API 的工具以及由具有必备角色和权限的用户进行配置（即创建、更新和/或删除）。例如，只有属于特定组织的组织管理员才能配置这些资源。这意味着，最终用户无法通过开发者门户配置这些资源，也无法通过任何其他方式配置这些资源。这些资源包括：
- API 代理
- 共享流
- API 产品
- 缓存
- KVM
- 密钥库和信任库
- 虚拟主机
- 目标服务器
- 资源文件
虽然这些资源确实具有受限访问权限，但即使由授权用户对其进行任何修改，历史数据也不会被新数据覆盖。这是因为这些资源仅按当前状态存储在 Apigee 中。此规则的主要例外是 API 代理和共享流。
进行修订版本控制的 API 代理和共享流
API 代理和共享流可通过修订版本进行管理，即创建、更新和部署。修订版本按顺序编号，这样您就可以添加新更改并将其保存为新修订版本，或者通过部署 API 代理/共享流的先前修订版本来还原更改。在任何时候，环境中都只能部署 API 代理/共享流的一个修订版本，除非修订版本具有不同的基本路径。
虽然 API 代理和共享流可通过修订版本进行管理，但如果对现有修订版本进行任何修改，则无法回滚，因为会覆盖旧更改。
审核和历史记录
Apigee 提供了“审核”功能，其有助于问题排查场景。借助这些功能，您可以查看执行特定操作（创建、读取、更新、删除、部署、取消部署）的人员以及在 Apigee 资源上执行操作的时间等信息。但是，如果对任何 Apigee 资源执行任何更新或删除操作，则审核无法向您提供旧数据。
反模式
直接通过 Apigee 界面或 API 管理 Apigee 资源（如上所列），而不使用源代码控制系统
存在一个误解，即修改或删除后 Apigee 能够将资源恢复到之前的状态。但是，Apigee 不会将资源恢复到之前的状态。因此，用户有责任确保与 Apigee 资源相关的所有数据都通过源代码控制管理系统来管理，这样，即使意外删除或需要回滚任何更改，也能快速恢复旧数据。这对于运行时流量需要此类数据的生产环境来说尤其重要。
我们通过几个示例来解释这一点，以及在未通过源代码控制系统管理数据并蓄意或无意修改了/删除了数据时可能导致的影响类型：
示例 1：删除或修改 API 代理
删除 API 代理或在现有修订版本上部署更改时，以前的代码将不可恢复。如果 API 代理包含未在 Apigee 以外的源代码控制管理 (SCM) 系统中管理的 Java、JavaScript 或 Python 代码，则可能会丢失大量开发工作和努力。
示例 2：使用特定虚拟主机确定 API 代理
虚拟主机上的证书即将过期，且该虚拟主机需要更新。如果有许多 API 代理，确定哪个 API 代理使用该虚拟主机进行测试可能很困难。如果 API 代理在 Apigee 外部的 SCM 系统中管理，则可以轻松搜索代码库。
示例 3：删除密钥库/信任库
如果虚拟主机或目标服务器配置使用的密钥库/信任库已被删除，则除非将密钥库/信任库（包括证书和/或私钥）的配置详细信息存储在源代码控制系统中，否则无法恢复密钥库/信任库。
影响
- 如果任何 Apigee 资源被删除，则无法从 Apigee 恢复该资源及其内容。
- 在将资源恢复到之前的状态之前，API 请求可能会失败，并出现导致中断的意外错误。
- 很难搜索 API 代理与 Apigee 中的其他资源之间的相互依赖性。
最佳做法
- 搭配使用任何标准 SCM 以及持续集成和持续部署 (CICD) 流水线来管理 API 代理和共享流。
- 使用任何标准 SCM 来管理其他 Apigee 资源，包括 API 产品、缓存、KVM、目标服务器、虚拟主机和密钥库。
- 如果存在任何现有 Apigee 资源，则使用 Apigee API 以 JSON/XML 载荷的形式获取这些资源的配置详细信息，并将其存储在源代码控制管理系统中。
- 在源代码控制管理系统中管理对这些资源的任何新更新。
- 如果需要创建新的 Apigee 资源或更新现有资源，则使用存储在源代码控制管理系统中的相应 JSON/XML 载荷，并使用 API 在 Apigee 中更新配置。
* 不能在 API 中以纯文本形式导出加密 KVM。用户有责任记录保存在加密 KVM 中的值。