本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 路徑路由模式
<a name="api-routing-path"></a>

依路徑路由是將多個或所有 API 分組在相同主機名稱下的機制，並使用請求 URI 隔離服務；例如，`api.example.com/service-a` 或 `api.example.com/service-b`。

## 一般使用案例
<a name="path-routing-use-case"></a>

大多數團隊選擇這種方法是因為他們想要一個簡單的架構：開發人員只需記住一個 URL，例如與 HTTP API 互動的 `api.example.com`。API 文件通常更容易理解，因為它通常會將資訊集中在一處，而不是分散在不同的入口網站或 PDF。

路徑型路由公認為是共享 HTTP API 的簡單機制。但是，由於多個躍點，它涉及操作開銷，例如組態、授權、整合與其他延遲。它也需要成熟的變更管理程序，以確保設定錯誤不會中斷所有服務。

在 上 AWS，有多種方式可以共用 API 並有效地路由到正確的服務。下列區段將探討三種方法：HTTP 服務反向代理程式、API Gateway 和 Amazon CloudFront。統一 API 服務的建議方法都不依賴於 AWS執行的下游服務。這些服務可以在任何地方執行沒有問題或任何技術，只要它們是 HTTP 相容。

## HTTP 服務反向代理程式
<a name="path-routing-proxy"></a>

您可以使用 HTTP 伺服器 (例如 [NGINX](https://www.f5.com/go/product/welcome-to-nginx)) 來建立動態路由設定。在 [Kubernetes](https://kubernetes.io/) 架構中，您也可以建立傳入規則來比對服務的路徑。(本指南不涵蓋 Kubernetes 傳入；請參閱 [Kubernetes 文件](https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource)以瞭解更多資訊。)

NGINX 的下列組態會動態地將 `api.example.com/my-service/` 的 HTTP 請求對應到 `my-service.internal.api.example.com`。

```
server {
    listen  80;

    location (^/[\w-]+)/(.*) {
        proxy_pass $scheme://$1.internal.api.example.com/$2;
    }
}
```

下列圖表說明了 HTTP 服務反向代理程式方法。



![\[使用 HTTP 服務反向代理程式進行路徑路由。\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/cloud-design-patterns/images/routing-2.png)


對於某些不使用其他配置來開始處理請求的使用案例，這種方法可能已足夠，使下游 API 可以收集指標和日誌。

若要為作業生產準備就緒做好準備，您將希望能夠為堆疊的每個層級加入可觀測性、加入其他組態，或加入指令碼來自訂 API 傳入點，藉此允許更進階的功能，例如速率限制或用量 Token。

### 優點
<a name="path-routing-proxy-pros"></a>

HTTP 服務反向代理程式方法的最終目的是建立可擴充且可管理的方法，將 API 統一成單一網域，使其對任何 API 消費者看起來都是一致的。此方法也可讓您的服務團隊部署和管理自己的 APIs，在 deployment. AWS managed 服務之後以最低的開銷進行追蹤，例如 [AWS X-Ray](https://aws.amazon.com/xray/)或 [AWS WAF](https://aws.amazon.com/waf/)，仍然適用於此處。

### 缺點
<a name="path-routing-proxy-cons"></a>

這種方法的主要缺點是對所需的基礎結構元件進行廣泛的測試和管理，不過如果您有網站可靠性工程 (SRE) 團隊，這可能不會是個問題。

這種方法有一個成本臨界點。在低到中等量的情況下，它比本指南中討論的其他一些方法更昂貴。在量大的情況下，它非常具有成本效益 (每秒約 100K 筆交易或更高)。

## API Gateway
<a name="path-routing-gateway"></a>

[Amazon API Gateway](https://aws.amazon.com/api-gateway/) 服務 (REST API 和 HTTP API) 可以透過類似於 HTTP 服務反向代理程式方法來路由流量。在 HTTP Proxy 模式下使用 API 閘道可提供一種簡單的方法，將許多服務包裝到頂層子網域 `api.example.com` 的進入點中，然後將要求代理至巢狀服務；例如，`billing.internal.api.example.com`。

您可能不希望透過對應根或核心 API 閘道中每個服務中的每個路徑來變得太細微。請改為選擇萬用字元路徑，例如 `/billing/*` 將要求轉寄至帳單服務。如果不對應根或核心 API 閘道中的每個路徑，您就可以在 API 上獲得更大的彈性，因為您不必在每次 API 變更時更新根 API 閘道。

![\[透過 API Gateway 路由路徑。\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/cloud-design-patterns/images/routing-3.png)


### 優點
<a name="path-routing-gateway-pros"></a>

為了控制更複雜的工作流程 (例如變更要求屬性)，REST API 會公開 Apache Velocity 範本語言 (VTL)，讓您修改要求和回應。REST API 可以提供其他好處，例如：
+ [使用 AWS Identity and Access Management (IAM)、Amazon Cognito 或授權方驗證 N/Z](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/authentication.html) [Amazon Cognito](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/cognito.html) [AWS Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)
+ [AWS X-Ray 用於追蹤](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-understanding-xray-traces.html)
+ [與 整合 AWS WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)
+ [基本速率限制](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ 將消費者分組到不同層級的用量 Token (請參閱 API Gateway 文件中的[限流 API 請求以取得更好的輸送量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html))

### 缺點
<a name="path-routing-gateway-cons"></a>

在量大的情況下，成本對部分使用者而言可能是個問題。

## CloudFront
<a name="path-routing-cloudfront"></a>

您可以使用 [Amazon CloudFront](https://aws.amazon.com/cloudfront/) 中的[動態來源選取功能](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html)，有條件地選取要轉寄請求的來源 (服務)。您可以使用此功能，透過單一主機名稱來路由多個服務，例如 `api.example.com`。

### 一般使用案例
<a name="path-routing-cloudfront-usecase"></a>

路由邏輯以程式碼形式存放於 Lambda @Edge 函數中，因此它支援高度可自訂的路由機制，例如 A/B 測試、初期測試版本、功能標記和路徑重新寫入。這會在下列圖表中進行說明。

![\[透過 CloudFront 進行路由的路徑。\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/cloud-design-patterns/images/routing-4.png)


### 優點
<a name="path-routing-cloudfront-pros"></a>

如果您需要快取 API 回應，此方法是在單一端點後方統一服務集合的好方法。這是統一 API 集合的具有成本效益的方法。

此外，CloudFront [支援欄位層級加密](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html)，以及與 整合 AWS WAF ，以實現基本速率限制和基本 ACLs。

### 缺點
<a name="path-routing-cloudfront-cons"></a>

此方法最多支援 250 個可以統一的原始伺服器 (服務)。對於大多數部署而言，此限制已足夠，但隨著服務組合的增加，可能會導致大量 API 發生問題。

目前更新 Lambda @Edge 函數需要幾分鐘的時間。CloudFront 還需要長達 30 分鐘的時間來完成將變更傳播到所有存在點。這最終會阻止進一步更新，直到它們完成。