本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 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)。
为显著减少或消除故障，我们建议您在以下所有实践中实施这些建议。
## 通过重试来检测所有路由
将所有虚拟服务配置为使用虚拟路由器，并为所有路由设置默认重试策略。这可通过重新选择主机并发送新请求来缓解请求失败的情况。对于重试策略，我们建议在支持重试事件类型的每种路径类型中为 `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% 的总任务。部署后，会导致两个高漂移点产生：
+ 在准备完成请求之前，Envoy 可以看到新任务 100% 规模的实例集（有关缓解措施，请参阅 [实施容器运行状况检查](#health-checks)）。
+ 任务终止期间，Envoy 可以看到旧任务 100% 规模的实例集。
配置这些部署限制后，容器编排工具可能会进入一种状态，它们会同时隐藏所有原目标，同时显示所有新目标。由于您的 Envoy 数据面板最终是一致的，这可能会导致数据面板中可见的目标集与编排工具的角度有所不同。为缓解这种情况，我们建议将正常运行的任务比例保持在至少 100%，但将总任务比例降至 125%。这可以减少分歧，提高重试的可靠性。我们建议针对不同的容器运行时系统使用以下设置。
**Amazon ECS**
如果您的服务所需计数为两个或三个，请将 `maximumPercent` 设置为 150%。否则，请将 `maximumPercent` 设置为 125%。
**Kubernetes**
配置您的部署 `update strategy`，设置 `maxUnavailable` 为 0% 和 `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**
[没有，因为在 Kubernet [es 的 App Mesh 控制器中注册和注销实例时，没有考虑 Kubernetes 的 AWS Cloud Map 存活性和就绪](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)性探针。](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\$1PRE** FERRED — 这是默认设置。Envoy 首先对 IPv6 地址执行 DNS 查找，`IPv4`如果找不到`IPv6`地址，则回退到。如果您的基础架构主要支持`IPv6`但需要`IPv4`兼容性，则这是有益的。
+ **IPv4\$1PRE** FERRED — Envoy 首先查找`IPv4`地址，`IPv6`如果没有可用`IPv4`地址，则回退到。如果您的基础架构主要支持`IPv4`但具有一定的`IPv6`兼容性，请使用此设置。
+ **IPv6\$1ONLY — 如果您的服务仅**支持`IPv6`流量，请选择此选项。Envoy 仅对`IPv6`地址执行 DNS 查找，确保所有流量都经过路由。`IPv6`
+ **IPv4\$1ONLY — 如果您的服务仅**支持`IPv4`流量，请选择此设置。Envoy 仅对`IPv4`地址执行 DNS 查找，确保所有流量都经过路由。`IPv4`
您可以在网格级别和虚拟节点级别设置 IP 版本首选项，虚拟节点设置会覆盖网格级别的设置。
有关更多信息，请参阅[服务网格](https://docs.aws.amazon.com/app-mesh/latest/userguide/meshes.html)和[虚拟节点](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html)。