问题描述
在使用 AWS 服务时，遇到了一个流量路由的问题。他们目前在核心业务中广泛使用 Google 距离矩阵（GDM）API 来帮助处理业务功能。由于 GDM 的成本上升，他们决定寻找更便宜的替代方案。他们选择了 OpenStreetMap（OSM）作为替代方案，并将 OSM 托管在 AWS 的弹性容器服务（ECS）中。
然而，由于某些原因，OSM 服务有时会失败或超时。他们在应用程序代码中添加了逻辑，如果 OSM 服务失败（或超时，超时时间为1秒），则切换回备用的 GDM 服务。问题是，如果突然出现大量请求，使用 ECS 架构，这些请求会积累起来。例如，如果有20,000个请求，总的潜在延迟时间可能达到20,000秒，这可能导致系统崩溃。
他们希望解决这个问题的一种方法是，在应用程序代码中添加逻辑，跟踪在时间 T 内 OSM 超时的次数 TOs（将该数字持久化到 Redis 或其他地方）。一旦超过一定数量的超时次数，就切换回备用的 GDM 服务。而在经过一段时间 Z 后，他们希望再次尝试使用 OSM 服务，即认为服务器已经恢复正常。
解决方案
使用 AWS APP MESH 实现流量路由
AWS 提供了一种名为 AWS App Mesh 的服务，可以帮助解决这种基于简单逻辑的流量路由问题。
创建 VirtualRouter： 使用 AWS App Mesh 中的
VirtualRouter对象来实现流量路由。将所有的流量先发送到OSM，并通过VirtualRouter进行路由。设置 K8S 服务： 在
VirtualRouter中，将一个服务指向托管在 ECS 中的OSM服务，另一个服务指向备用的GDM服务（这可以是一个外部服务）。定时任务监控： 创建一个定时任务（CronJob），在一个 Pod 中运行，定期从 ElasticCache 中获取与超时相关的指标。如果满足条件，Pod 中运行的代码会修改
VirtualRouter的配置，实现动态的流量路由切换。
以下是具体的操作步骤：
创建一个
VirtualRouter，将流量路由到OSM和备用的GDM服务。在定时任务中，通过访问 ElasticCache 获取超时相关的指标，判断是否需要切换路由。
如果超时次数达到阈值，使用 AWS SDK 或 AWS CLI 修改
VirtualRouter的配置，将流量切换回备用的GDM服务。
需要注意的是，这种方案需要对 AWS App Mesh 和相关服务有一定的了解。同时，定时任务和流量切换的逻辑需要在应用程序中进行实现，确保流量切换的准确性和稳定性。
结论
通过使用 AWS App Mesh 的 VirtualRouter 对象和定时任务，你可以实现基于简单逻辑的流量路由。这将允许你在 OSM 服务出现问题时，自动切换到备用的 GDM 服务，从而提高系统的稳定性和可用性。
请注意，以上方案涉及 AWS 的多个服务，具体的实施步骤可能会受到版本变化或其他因素的影响。在进行操作之前，请确保先熟悉相关文档和指南，以便正确地配置和管理所需的服务。