您目前查看的是 Apigee 和 Apigee Hybrid 說明文件。
查看
Apigee Edge 說明文件。
後端系統會執行 API Proxy 存取的服務。換句話說，這些是 API 和 API 管理 Proxy 層存在的基本原因。
透過 Apigee 平台傳送的任何 API 要求，都會先經過一般路徑，然後才會到達後端：
- 要求來自用戶端，可能是瀏覽器或應用程式。
- Apigee 閘道隨即會收到要求。
- 並在閘道內處理。在處理過程中，要求會傳遞至多個分散式元件。
- 接著，閘道會將要求轉送至回應要求的後端。
- 後端的回應會透過 Apigee 閘道，沿著原路徑返回用戶端。
因此，透過 Apigee 路由傳送的 API 要求效能，取決於 Apigee 和後端系統。在本反模式中，我們將著重於後端系統效能不佳對 API 要求的影響。
反模式
讓我們考慮後端有問題的情況。可能原因如下：
後端大小不足
透過 API 公開這些後端系統上的服務時，會面臨的挑戰是這些服務可供大量使用者存取。從業務角度來看，這是值得挑戰的目標，但必須妥善處理。
許多時候，後端系統並未準備好因應服務的額外需求，因此容量不足或未經過調整，無法有效率地回應。
如果後端「大小不足」，API 要求量暴增時，後端系統的 CPU、負載和記憶體等資源就會受到壓力。這最終會導致 API 要求失敗。
後端速度緩慢
如果後端調整不當，回應任何傳入的要求時就會非常緩慢，導致延遲時間增加、逾時過早，以及客戶體驗不佳。
Apigee 平台提供幾項可調整的選項，可規避及管理緩慢的後端。但這些選項有其限制。
影響
- 如果後端大小不足，流量增加可能會導致要求失敗。
- 如果後端速度緩慢，要求的延遲時間就會增加。
最佳做法
- 使用快取儲存回應，縮短 API 回應時間，並減少後端伺服器的負載。
- 解決後端伺服器速度緩慢的根本問題。