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

Question

这个问题可能不像你想象的那么重要。首先，感谢您的阅读。我是一名计算机科学专业的学生。我刚刚开始了解 AWS，尤其是 Route 53，所以如果有任何伤害您的眼睛，请见谅 :)

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

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

另外，用户指定的配置结合两者是可能的 (LBR+WRR)。

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

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

很抱歉这个冗长的问题。我正在寻找关于最佳方式/起点的想法和想法，以试验更好地使用 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 容器，让我们在切换之前与真实用户一起感受新版本。我们几乎可以对任何使用主机名查找来查找资源的服务执行相同的操作。

Answer 2

一个用例可以是，使用它来负载平衡无法使用弹性负载平衡器平衡的内部服务，例如 rds 或弹性缓存只读副本，而不是使用 haproxy 创建 ec2 实例要对您的服务进行负载平衡，您可以根据权重或延迟创建一个 Route 53 级别的平衡器。

我的猜测是，在内部，他们在 dns 服务器上使用自定义负载平衡器，根据域别名和所选平衡策略平衡请求。