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