您正在查看 Apigee 和 Apigee Hybrid 文档。
查看 Apigee Edge 文档。
后端系统运行 API 代理访问的服务。换句话说，它们是 API 和 API 管理代理层存在的基本原因。
任何通过 Apigee 平台路由的 API 请求在到达后端之前都会遍历一个典型路径：
- 请求源自客户端，客户端可以是浏览器、应用等。
- 然后 Apigee 网关收到请求，
- 请求在网关内处理。在此处理过程中，请求被传递给多个分布式组件。
- 然后，网关将请求路由到响应该请求的后端。
- 后端的响应随后会通过 Apigee 网关遍历确切的反向路径，返回到客户端。
实际上，通过 Apigee 路由的 API 请求的性能同时取决于 Apigee 和后端系统。在这种反面模式中，我们将重点关注由于后端系统性能不佳而对 API 请求的影响。
反模式
让我们以有问题的后端为例。可能的情况如下：
后端容量不足
通过 API 在这些后端系统上公开服务所面临的挑战在于，大量最终用户可以访问它们。从业务角度来看，这是一个值得面对的挑战，但也是需要解决的问题。
很多后端系统尚未使其服务准备好满足这种额外需求，因此其容量不足或未进行调整以实现高效响应。
后端“容量不足”的问题在于，如果 API 请求数量激增，则会使后端系统上的 CPU、负载和内存等资源承受压力。这最终会导致 API 请求失败。
后端速度缓慢
后端调整不当的问题在于，对收到的任何请求的响应都非常慢，从而导致延迟时间增加、过早超时和客户体验受损。
Apigee 平台提供了一些可调性选项来规避和管理后端速度缓慢的问题。但这些选项也具有局限性。
影响
- 如果后端容量不足，则流量增加可能会导致请求失败。
- 在后端速度缓慢的情况下，请求的延迟时间将会增加。
最佳做法
- 使用缓存来存储响应，以缩短 API 响应时间并减少后端服务器的负载。
- 解决后端服务器速度慢的根本问题。