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

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

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

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

待定

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

反模式

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

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

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

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

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

    后端速度缓慢

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

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

    影响

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

    最佳做法

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

    更多详情