本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# App Mesh 缩放疑难解答
扩展

**重要**  
终止支持通知：2026 年 9 月 30 日， Amazon 将停止对的支持。 Amazon App Mesh 2026 年 9 月 30 日之后，您将无法再访问 Amazon App Mesh 控制台或 Amazon App Mesh 资源。有关更多信息，请访问此博客文章[从迁移 Amazon App Mesh 到 Amazon ECS Service Connect](https://www.amazonaws.cn/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)。

本主题详细介绍了您在扩展 App Mesh 时可能遇到的常见问题。

## 将虚拟 node/virtual 网关的副本扩展到 50 个以上时，连接失败且容器运行状况检查失败


**症状**  
当你将虚拟网关的副本数量（例如 Amazon ECS 任务、Kubernetes pod 或 Amazon EC2 实例）扩展到 50 以上的虚拟 node/virtual 网关时，对新的和当前正在运行的 Envoy 的容器运行状况检查开始失败。向虚拟 node/virtual 网关发送流量的下游应用程序开始看到请求失败并显示 HTTP 状态码`503`。

**解决方案**  
App Mesh 对每个虚拟网 node/virtual 关的特使数量的默认配额为 50。当正在运行的 Envoy 数量超过此配额时，新的和当前正在运行的 Envoy 将无法通过 gRPC 状态码 `8`(`RESOURCE_EXHAUSTED`)连接到 App Mesh 的 Envoy 管理服务。这个配额可以提高。有关更多信息，请参阅 [App Mesh 服务限额](service-quotas.md)。

如果您的问题仍未解决，请考虑[GitHub 提出问题](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或联系 Su [Amazon pport](https://www.amazonaws.cn/premiumsupport/)。

## `503`当虚拟服务后端水平向外扩展或向内扩展时，请求会失败


**症状**  
当后端虚拟服务横向扩展或向内扩展时，来自下游应用程序的请求会失败，并 `HTTP 503` 显示状态码。

**解决方案**  
App Mesh 推荐了几种方法来缓解故障情况，同时水平扩展应用程序。有关如何防止这些故障的详细信息，请参阅 [App Mesh 最佳实践](best-practices.md)。

如果您的问题仍未解决，请考虑[GitHub 提出问题](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或联系 Su [Amazon pport](https://www.amazonaws.cn/premiumsupport/)。

## 在负载增加的情况下，Envoy 容器因段错误而崩溃


**症状**  
在高流量负载下，Envoy 代理由于分段错误（Linux 退出代码 `139`）而崩溃。Envoy 进程日志包含如下语句。

```
Caught Segmentation fault, suspect faulting address 0x0"
```

**解决方案**  
Envoy 代理可能违反了操作系统的默认 nofile ulimit，即一个进程一次可以打开的文件数量的限制。这种漏洞是由于流量导致了更多的连接，从而消耗了额外的操作系统插槽。要解决此问题，请增加主机操作系统上的 ulimit nofile 值。如果您使用的是 Amazon ECS，则可以通过任务定义的[资源限制设置](https://docs.amazonaws.cn/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_limits)上的 [Ulimit 设置](https://docs.amazonaws.cn/AmazonECS/latest/APIReference/API_Ulimit.html)来更改此限制。

如果您的问题仍未解决，请考虑[GitHub 提出问题](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或联系 Su [Amazon pport](https://www.amazonaws.cn/premiumsupport/)。

## 默认资源的增加未反映在服务限制中


**症状**  
在增加 App Mesh 资源的默认限制后，当您查看服务限制时，新值不会反映出来。

**解决方案**  
虽然目前未显示新的限制，但客户仍然可以行使这些限制。

如果您的问题仍未解决，请考虑[GitHub 提出问题](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或联系 Su [Amazon pport](https://www.amazonaws.cn/premiumsupport/)。

## 由于大量的运行状况检查调用，应用程序崩溃。


**症状**  
为虚拟节点启用主动运行状况检查后，运行状况检查调用的数量会增加。由于向应用程序发出的运行状况检查调用的数量大大增加，应用程序崩溃。

**解决方案**  
启用主动运行状况检查后，下游（客户端）的每个 Envoy 端点都会向上游集群（服务器）的每个端点发送运行状况请求，以便做出路由决策。因此，运行状况检查请求的总数将为 `number of client Envoys` \$1 `number of server Envoys` \$1 `active health check frequency`。

要解决此问题，请修改运行状况检查探测器的频率，这将减少运行状况检查探测器的总量。除了主动运行状况检查外，App Mesh 还允许将[异常值检测](https://docs.amazonaws.cn/app-mesh/latest/APIReference/API_OutlierDetection.html)配置为被动运行状况检查的手段。使用异常值检测来配置何时根据连续`5xx`响应移除特定主机。

如果您的问题仍未解决，请考虑[GitHub 提出问题](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或联系 Su [Amazon pport](https://www.amazonaws.cn/premiumsupport/)。