每个 ECS 服务的 AWS ALB 与微服务架构的每个 ALB 的多个服务答案

【问题标题】：AWS ALB per ECS Service vs. multiple services per ALB for a microservices architecture每个 ECS 服务的 AWS ALB 与微服务架构的每个 ALB 的多个服务
【发布时间】：2018-07-09 23:01:27
【问题描述】：

最初，我认为每个 ALB 侦听器使用不同路径模式的多个服务来适当地分发 API 调用是显而易见的选择。不过，就健康检查而言（如果其中一项服务出现故障），我不知道有一种聪明的方法可以将该服务的流量转移到不同的区域。

如果我有一个带有加权路由 53 记录的活动设置，它将在运行状况检查时进行故障转移，我看不到任何其他解决方案，只能切断整个 ALB 流量并转移到另一个区域，或者忽略 1关闭服务并继续向部分失败的 ALB 发送流量。

将 ALB 与服务进行一对一映射修复了此解决方案，但在成本和复杂性方面增加了额外开销。

对于活跃的活跃微服务架构，推荐遵循的模式是什么？

【问题讨论】：

当我们决定将我们的服务迁移到基于 ALB 路径的路由时，我们为此苦苦挣扎了一段时间。对于主动-主动，我们在 ALB 后面运行多个 ECS 集群。 OAuth2.0 等支持服务驻留在一个集群中，多个任务分布在 ec2 实例中。另一个集群处理大多数轻量级服务，同样每个服务的多个任务一次分布在至少 2 个 ec2 上。对于故障转移到另一个区域，我们现在使用温站点。如果声明了一个事件，我们会在那个时候切断 DNS。如果发生故障，您对正常运行时间和 RTB 有什么要求？
当您说您切断了 DNS 时，您是说您将流量从该 ALB 完全切换到另一个区域的 ALB 吗？我的场景涉及大约 10 个服务大量流量的服务，并且将所有服务流量完全切断到另一个“温暖”区域确实是我想避免的事情。正常运行时间的要求应该尽可能接近 100%。
每个 AWS 支持：“从我的测试中我可以看到，对于与 ALB 侦听器关联的服务，R53 不可能在每个服务的基础上使流量失败。您只能实施故障转移对于整个 ALB，这将导致与 ALB 关联的所有服务发生故障转移。”
是的，确切地说，当事件发生时，我们会故障转移到温站点。这是我们行业监管机构的业务连续性要求。 100% 的正常运行时间始终是我们的目标，但您受制于您的云提供商。我们温暖的网站是为诸如去年 S3 和 lambda 宕机之类的事件而存在的。在主要区域内，我们利用在不同机器上运行的冗余任务，最好是在不同的 az 上。我们使用多个较小的集群，运行类似流量的服务。我们发现这是最具成本效益的。抱歉，我无法提供更多帮助。

标签： amazon-web-services microservices amazon-elb amazon-route53 amazon-alb

【解决方案1】：

如果所有服务都在一个主机名下访问，那么 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 响应。

【讨论】：