本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# App Mesh 最佳實務
**重要**
支援終止通知：2026 年 9 月 30 日， AWS 將停止支援 AWS App Mesh。2026 年 9 月 30 日之後，您將無法再存取 AWS App Mesh 主控台或 AWS App Mesh 資源。如需詳細資訊，請參閱此部落格文章[從 遷移 AWS App Mesh 至 Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)。
為了實現在計劃部署期間和部分主機意外遺失期間，零失敗請求的目標，本主題的最佳實務會實作下列策略：
+ 使用安全的預設重試策略，從應用程式的角度提高請求成功的可能性。如需詳細資訊，請參閱[使用重試檢測所有路由](#route-retries)。
+ 透過將重試請求傳送至實際目的地的可能性最大化，提高重試請求成功的可能性。如需詳細資訊，請參閱[調整部署速度](#reduce-deployment-velocity)、[在向內擴展之前向外擴展](#scale-out)及[實作容器運作狀態檢查](#health-checks)。
若要大幅減少或消除故障，建議您在下列所有實務中實作建議。
## 使用重試檢測所有路由
將所有虛擬服務設定為使用虛擬路由器，並為所有路由設定預設重試政策。這將透過重新選取主機並傳送新請求來緩解失敗的請求。對於重試政策，我們建議 的值至少為 2`maxRetries`，並為每個支援重試事件類型的路由類型中的每種重試事件類型指定下列選項：
+ **TCP** – `connection-error`
+ **HTTP 和 HTTP/2** – `stream-error`和 `gateway-error`
+ **gRPC** – `cancelled`和 `unavailable`
其他重試事件需要逐case-by-case考慮，因為它們可能不安全，例如請求不等冪。您將需要考慮和測試 `maxRetries`和 的值`perRetryTimeout`，以適當權衡請求的最大延遲 (`maxRetries` \$1 `perRetryTimeout`) 與增加更多重試的成功率。此外，當 Envoy 嘗試連線到不再存在的端點時，您應該預期該請求會使用完整的 `perRetryTimeout`。若要設定重試政策，請參閱 [建立路由](routes.md#create-route)，然後選取您要路由的通訊協定。
**注意**
如果您在 2020 年 7 月 29 日或之後實作路由，但未指定重試政策，則 App Mesh 可能已針對您在 2020 年 7 月 29 日或之後建立的每個路由，自動建立與先前政策類似的預設重試政策。如需詳細資訊，請參閱[預設路由重試政策](envoy-defaults.md#default-retry-policy)。
## 調整部署速度
使用滾動部署時，請降低整體部署速度。根據預設，Amazon ECS 會設定至少 100% 運作狀態良好的任務和 200% 總任務的部署策略。部署時，這會導致兩個高度偏離點：
+ 在準備完成請求之前，Envoys 可能會看到新任務的 100% 機群大小 （請參閱 [實作容器運作狀態檢查](#health-checks) 了解緩解措施）。
+ 在任務終止時，Envoys 可能會看到舊任務的 100% 機群大小。
設定這些部署限制時，容器協調程式可能會進入一個狀態，同時隱藏所有舊目的地並顯示所有新目的地。由於您的 Envoy 資料平面最終一致，這可能會導致資料平面中可見的一組目的地與協調者的觀點不同。若要緩解這種情況，我們建議至少維持 100% 正常運作的任務，但將任務總數降低到 125%。這將減少分歧並改善重試的可靠性。針對不同的容器執行時間，我們建議執行下列設定：
**Amazon ECS**
如果您的服務需要計數為 2 或 3，請將 `maximumPercent`設為 150%。否則，請將 `maximumPercent`設為 125%。
**Kubernetes**
將部署的 設定為 `maxUnavailable` 0% `update strategy`和 `maxSurge` 25%。如需部署的詳細資訊，請參閱 Kubernetes [部署](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)文件。
## 在向內擴展之前向外擴展
向外擴展和向內擴展都可能導致重試中失敗請求的一些可能性。雖然有一些任務建議可以減少橫向擴展，但向內擴展的唯一建議是將任務中的橫向擴展百分比降至最低。我們建議您在擴展舊任務或部署之前，使用擴展新 Amazon ECS 任務或 Kubernetes 部署的部署策略。此擴展策略可讓您在任務或部署中擴展的百分比保持較低，同時維持相同的速度。此實務同時適用於 Amazon ECS 任務和 Kubernetes 部署。
## 實作容器運作狀態檢查
在擴展案例中，Amazon ECS 任務中的容器可能會變得不按順序出現，並且最初可能沒有回應。對於不同的容器執行期，我們建議下列建議：
**Amazon ECS**
為了緩解這種情況，我們建議使用容器運作狀態檢查和容器相依性排序，以確保 Envoy 在需要開始傳出網路連線的任何容器之前，執行正常。若要在任務定義中正確設定應用程式容器和 Envoy 容器，請參閱[容器相依性](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_task_definitions.html#example_task_definition-containerdependency)。
**Kubernetes**
無，因為在 Kubernetes 的 App Mesh 控制器中註冊和取消註冊 AWS Cloud Map 執行個體時，不會考慮 Kubernetes [存活和整備](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)探查。 [https://github.com/aws/aws-app-mesh-controller-for-k8s](https://github.com/aws/aws-app-mesh-controller-for-k8s)如需詳細資訊，請參閱 GitHub 問題 [\$1132](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/132)。
## 最佳化 DNS 解析度
如果您使用 DNS 進行服務探索，則必須選取適當的 IP 通訊協定，以在設定網格時最佳化 DNS 解析度。App Mesh 同時支援 `IPv4`和 `IPv6`，您選擇的 可能會影響服務的效能和相容性。如果您的基礎設施不支援 `IPv6`，我們建議您指定符合基礎設施的 IP 設定，而不是依賴預設`IPv6_PREFERRED`行為。預設`IPv6_PREFERRED`行為可能會降低服務效能。
+ **IPv6\$1PREFERRED** – 這是預設設定。Envoy 會先執行 IPv6 地址的 DNS 查詢，`IPv4`如果找不到`IPv6`地址，則會回到 。如果您的基礎設施主要支援 `IPv6`，但需要`IPv4`相容性，這會很有幫助。
+ **IPv4\$1PREFERRED** – 如果沒有可用的`IPv4`地址`IPv6`，Envoy 會先查詢`IPv4`地址，然後回到 。如果您的基礎設施主要支援 `IPv4`，但有一些`IPv6`相容性，請使用此設定。
+ **IPv6\$1ONLY** – 如果您的服務僅支援`IPv6`流量，請選擇此選項。Envoy 只會對`IPv6`地址執行 DNS 查詢，確保所有流量都透過 路由`IPv6`。
+ **IPv4\$1ONLY** – 如果您的服務僅支援`IPv4`流量，請選擇此設定。Envoy 只會對`IPv4`地址執行 DNS 查詢，確保所有流量都透過 路由`IPv4`。
您可以在網格層級和虛擬節點層級設定 IP 版本偏好設定，虛擬節點設定則會覆寫網格層級的 IP 版本偏好設定。
如需詳細資訊，請參閱[服務網格](https://docs.aws.amazon.com/app-mesh/latest/userguide/meshes.html)和[虛擬節點](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html)。