反面模式：允许运行缓慢的后端

您正在查看 Apigee 和 Apigee Hybrid 文档。
查看 Apigee Edge 文档。

后端系统运行 API 代理访问的服务。换句话说，它们是 API 和 API 管理代理层存在的基本原因。

任何通过 Apigee 平台路由的 API 请求在到达后端之前都会遍历一个典型路径：

  • 请求源自客户端，客户端可以是浏览器、应用等。
  • 然后 Apigee 网关收到请求，
  • 请求在网关内处理。在此处理过程中，请求被传递给多个分布式组件。
  • 然后，网关将请求路由到响应该请求的后端。
  • 后端的响应随后会通过 Apigee 网关遍历确切的反向路径，返回到客户端。

待定

实际上，通过 Apigee 路由的 API 请求的性能同时取决于 Apigee 和后端系统。在这种反面模式中，我们将重点关注由于后端系统性能不佳而对 API 请求的影响。

反模式

让我们以有问题的后端为例。可能的情况如下：

  • 后端容量不足
  • 后端速度缓慢

    • 后端容量不足

    通过 API 在这些后端系统上公开服务所面临的挑战在于，大量最终用户可以访问它们。从业务角度来看，这是一个值得面对的挑战，但也是需要解决的问题。

    很多后端系统尚未使其服务准备好满足这种额外需求，因此其容量不足或未进行调整以实现高效响应。

    后端“容量不足”的问题在于，如果 API 请求数量激增，则会使后端系统上的 CPU、负载和内存等资源承受压力。这最终会导致 API 请求失败。

    后端速度缓慢

    后端调整不当的问题在于，对收到的任何请求的响应都非常慢，从而导致延迟时间增加、过早超时和客户体验受损。

    Apigee 平台提供了一些可调性选项来规避和管理后端速度缓慢的问题。但这些选项也具有局限性。

    影响

    • 如果后端容量不足，则流量增加可能会导致请求失败。
    • 在后端速度缓慢的情况下，请求的延迟时间将会增加。

    最佳做法

    • 使用缓存来存储响应，以缩短 API 响应时间并减少后端服务器的负载。
    • 解决后端服务器速度慢的根本问题。

    更多详情