这个问题可能没有您想象的那么重要。首先，感谢阅读它。我是计算机科学专业的学生。我刚刚开始了解AWS，尤其是53号公路，所以请原谅我，如果有任何伤害你的眼睛：）
我们都知道Amazon Route 53为客户提供了这种能力 将用户路由到EC2实例，S3存储桶和弹性负载 跨越多个可用区域和区域的平衡器 不同形式的DNS负载均衡包括：
- 基于LBR /延迟的路由，路由到延迟最低的区域
- WRR /加权循环，为不同目标分配权重
此外，可以组合两者的用户指定配置 （LBR + WRR）。
Route 53灵活性允许用户节省成本，无论手动如何 配置对于最终用户来说会变得越来越复杂看着 对于最好的非概率性政策（例如WRR权重）是 NP完全问题。
我们需要为服务器ip地址提供不同权重的可能情况有哪些？鉴于可以有多个可用区域和实例的EC2服务器可以包含前端和后端，或者只包含应用程序层或数据库？是否有任何想法可以更好地使用Route 53与其他AWS服务结合使用，以提高交互式多层云应用程序的性能？
很抱歉这个冗长的问题。我正在寻找关于最佳方式/ 起点的想法和想法，以试验更好地使用Route 53以及与多层云的其他AWS服务结合使用应用。不一定是100％正确的答案。欢迎任何想法或建议。非常感谢提前！
更新
我应该重新解释一个问题：在Route 53中设置加权记录的目的是什么，即在DNS服务中？显然，DNS中的WRR可以控制流量，但如果我们只依靠这种DNS负载平衡（或负载分配），我们就会在很多其他DNS服务器上投入大量工作量。我可以想到的一个案例是谷歌或Facebook这样的网站可能会获得大量的域名查询，WRR DNS负载平衡可能很有用，并且必须存在某种会话粘性，因为跨服务器的共享会话似乎是一个坏主意。
在Route 53中使用加权记录是否还有其他方式/目的。
非常感谢您考虑我的问题！
答案 0 :(得分：4)
要考虑的另一个用例是前端或后端服务的A / B测试。让我举例说明：假设我们只是CI测试的1.0.1版本的Web应用程序（在Docker容器中运行），我们已经部署了容器，但我们尚未将流量路由到它。我们不想翻转开关并立即将我们每天100万活跃用户（woohoo！）转储到v1.0.1上，直到我们可以进行一些真实的测试。因此，我们决定使用Route 53中提供的加权循环负载平衡将0.25％的用户发送到v1.0.1容器，这样我们就可以在翻转交换机之前感受真实用户的新版本。几乎所有使用主机名查找来查找资源的服务都可以做同样的事情。
答案 1 :(得分：0)
一个用例可以是，使用它来负载平衡使用弹性负载均衡器无法平衡的内部服务，如rds或弹性缓存读取副本，因此不是创建带有haproxy的ec2实例，例如要对服务进行负载平衡，您可以根据权重或延迟创建Route 53级别平衡器。
我的猜测是，在内部，他们在dns服务器上使用自定义负载均衡器，根据域别名和选定的平衡策略平衡请求。