最初，我认为每个 ALB 侦听器使用不同路径模式的多个服务来适当地分发 API 调用是显而易见的选择。不过，就健康检查而言（如果其中一项服务出现故障），我不知道有一种聪明的方法可以将该服务的流量转移到不同的区域。
如果我有一个带有加权路由 53 记录的活动设置，它将在运行状况检查时进行故障转移，我看不到任何其他解决方案，只能切断整个 ALB 流量并转移到另一个区域，或者忽略 1 down 服务和继续向部分失败的 ALB 发送流量。
将 ALB 与服务进行一对一的映射可以修复此解决方案，但会在成本和复杂性方面增加额外的开销。
对于主动主动微服务架构，推荐遵循的模式是什么？
如果所有服务都在一个主机名下访问，那么 DNS 当然必须指向一个位置，因此重新路由从根本上来说是一个全有或全无的前景。
但是，有一个有效的解决方法。
为每个服务配置一个“秘密”主机名。（“秘密”是指客户端不需要知道它。）我们将这些称为“服务端点”。这些主机名的目的是将请求路由到每个服务... svc1.api.example.com、svc2.api.example.com 等。
将这些 DNS 记录中的每一个配置为指向主负载均衡器或故障转移负载均衡器，并使用 Route 53 条目和 Route 53 运行状况检查，专门检查每个平衡器上的一项服务的运行状况。
此时您所拥有的是每个服务的主机名，该主机名将具有正确指向首选、健康端点的 DNS 答案。
您还没有一种方法来确保客户请求到达正确的位置。
为此，请创建一个 CloudFront 分配，并将您的公共 API 主机名作为备用域名。为这些服务端点中的每一个定义一个 CloudFront 源（将“源路径”留空），然后使用适当的路径模式为每个服务创建缓存行为，例如/api/svc1*并选择匹配的源。将您的 API 需要查看的所有 HTTP 标头列入白名单。
最后，将主主机名的 DNS 指向 CloudFront。
客户端将自动连接到其最近的 CloudFront 边缘站点，CloudFront 在匹配路径模式以发现将请求发送到何处之后，将检查该服务特定端点的 DNS 并将请求转发到适当的平衡器。
CloudFront，在这个应用程序中本身不是一个“CDN” ，而是一个全球分布的反向代理——从逻辑上讲，是所有流量的单一目的地，因此 API 的主主机名不需要故障转移配置......所以没有更多的全有或全无路由。在 CloudFront 的背面，这些服务终端节点主机名可确保根据 Route 53 运行状况检查将请求路由到运行状况良好的目的地。CloudFront 尊重这些 DNS 记录的 TTL，并且不会缓存不应缓存的 DNS 响应。