我的目标是能够使用相对复杂的规则将流量从 Route53 路由到我的自动扩展组。Route 53 必须提供 DNS，我的 EC2 实例必须为请求提供服务，但我愿意接受堆栈中使用的任何其他技术。
以下是我可能使用的规则示例：
- 1% 的 URL 路径中具有特定值的流量应路由至 ASG A
- 正文中具有此值的流量的 0.1% 应路由至 ASG B
- 其余的应该交给 ASG C
考虑到我希望能够更改规则而不必每次都部署新的 CF 模板（我的整个配置都在 CF 中），对我来说最好的解决方案是什么？
主要原因是能够为特定客户运行实验。我希望能够将新功能部署到生产环境中，在特定受众中测试它，然后才将其普遍可用。对于某些客户，我将能够使用查询参数，但对于某些客户，我将需要扫描请求正文。
如果有不同的解决方案（不需要多个 ASG）或者我甚至没有想到的东西，请分享您的想法。
答案1
HAProxy 可以根据请求主体路由流量。
您可以尝试：
- Route53 将所有流量引导至 HAProxy 实例集群。
- HAProxy 会根据你的条件 URL / body / 其他内容，通过 CNAME 将流量路由到各种 AWS 负载均衡器（ELB / ALB 而不是自动扩展组）
- 负载均衡器根据您的自动扩展组更改自动扩展组的大小
这实际上不是云原生的做事方式，它使 HAProxy 实例成为瓶颈和故障点。您至少希望它们位于多个可用区中，理想情况下，如果您有关键应用程序，您会在不同区域拥有几个集群。
在你的情况下，我会考虑使用应用层运行实验，或者根据一些更简单的因素（例如 URL 或 cookie）进行路由。如果你搜索蓝/绿部署技术，可能会给你提供更多有关拆分流量的想法。
我认为这还不是一个完整的答案，但它应该能给你一些想法。我会再考虑一下，也许在接下来的一天左右会给你更多答案。也许在那之前别人能给你更好的答案。
答案2
那里将会是三个负载平衡阶段的序列，第一个馈送到第二个，第二个馈送到第三个：
- “多可用区”阶段：普通的 ELB
- “受众”阶段：每个可用区都包含您自己的自定义负载均衡器（例如 EC2 上的 haproxy）：
- 1% 发送到后端 A
- 0.1% 发送到后端B
- 否则发送到后端 C
- “自动扩展”阶段。A、B、C 都是另一个 ELB。每个都为自己的自动扩展组提供数据。