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