在 Amazon Route 53 中更好地使用加权循环路由

Question

这个问题可能没有你想象的那么基本。首先，感谢您的阅读。我是一名计算机科学专业的学生。我刚开始学习 AWS，尤其是 Route 53 所以如果有什么伤害你的眼睛，请原谅我:)

我们都知道 Amazon Route 53 为客户提供了跨多个可用区和区域将用户路由到 EC2 实例、S3 存储桶和弹性负载均衡器的能力，并且有不同形式的 DNS 负载均衡，包括：

• LBR/Latency Based Routing，路由到延迟最低的区域
• WRR/加权循环，为不同的目标分配权重

此外，用户指定的配置可以结合两者（LBR+WRR）。

Route 53 的灵活性使用户能够节省成本，但对于最终用户而言，手动配置可能会变得越来越复杂。寻找最佳的非概率策略（例如 WRR 权重）是 NP 完全的。

我们需要给服务器 ip 地址赋予不同的权重有哪些可能的情况？鉴于可以有跨多个可用区和实例的 EC2 服务器可以同时包含前端和后端，或者仅包含应用程序层或数据库？是否有任何想法可以更好地将 Route 53 与其他 AWS 服务结合使用，以提高交互式多层云应用程序的性能？

抱歉问了这么长的问题。我正在寻找关于最佳方式/起点的想法和想法，以试验更好地使用 Route 53 以及与其他 AWS 服务结合用于多层云应用程序。不一定是 100% 正确的答案。欢迎任何想法或建议。提前谢谢了 ！

更新：

我可能应该重新表述这个问题：在 Route 53 中设置加权记录的目的是什么，即在 DNS 服务中？显然，DNS 中的 WRR 可以控制部分流量，但如果我们仅仅依赖于这种 DNS 负载平衡（或负载分配），我们将在许多其他 DNS 服务器上放置大量工作负载。我能想到的一种情况是，像 google 或 Facebook 这样的网站可能会获得大量的域名查询，WRR DNS 负载平衡可能很有用，并且必须存在某种会话粘性，因为跨服务器共享会话似乎是一种馊主意。

在 Route 53 中使用加权记录是否有任何其他方式/目的。

非常感谢您考虑我的问题！

Answer 1

另一个需要考虑的用例是前端或后端服务的 A/B 测试。让我举例说明：假设我们刚刚对 Web 应用程序的 1.0.1 版进行了 CI 测试（在 Docker 容器中运行），并且我们已经部署了容器，但尚未将流量路由到它。我们不想拨动开关并立即将我们的 100 万每日活跃用户（哇哦！）转储到 v1.0.1，直到我们可以对其进行一些实际测试。因此，我们决定使用 Route 53 中可用的加权循环负载平衡将 0.25% 的用户发送到 v1.0.1 容器，让我们在切换开关之前与真实世界的用户一起感受新版本。我们几乎可以对任何使用主机名查找来查找资源的服务执行相同的操作。