我正在考虑更改通过 https api 提供服务的“高可用性”网站的选项。
当前设置是：
- 两个独立的虚拟机，来自不同的云提供商（AWS 和 RackSpace）
- 一个 DNS 负载均衡器：这也是 HA 发挥作用的地方，该服务监控两个虚拟机，如果其中一个虚拟机不可用，它会将所有 DNS 查询定向到另一个虚拟机
如果负载平衡不是必需的，我们是否可以不用负载平衡器，只需将 DNS 服务器放在两台机器上，每台机器在 DNS 查询时只回复自己的地址。在这种情况下，如果一台虚拟机停机，将同时删除该服务和指向该服务的 DNS 服务器，因此不会有客户端被定向到停机的服务器，对吗？
为清晰起见进行编辑：
我们对目前不太完美的“HA”感到满意，这个问题具体是关于我正在考虑的改变是否会让事情变得更糟。
答案1
对你的问题的直接回答是“是的”，它会使情况变得更糟。
这是因为您的一个名称服务器没有响应，会导致尝试通过失败的名称服务器进行解析的客户端一直出现解析延迟，而当前技术只会导致 +- 一半的客户端失败，直到您检测到 VM 已关闭 + TTL 秒。
通常，名称服务器会缓存 48 小时，因此，在您的停机时间或名称服务器更新时间 + 48 小时（以较短时间为准）内，您的用户将会遇到随机缓慢的体验。
您当前的实现更好除非您的虚拟机停机检测速度很慢。对于虚拟机停机和您检测到它之间的时间段 + TTL，建议的解决方案实际上会更好。但我假设这段时间太短，可以忽略不计。
答案2
如果我理解正确的话，您建议将两个分布式服务器都作为所讨论域的列出的名称服务器，每个服务器都有一个权威区域文件，其中包含指向运行 HTTPS 服务的主机名的本地服务器的单个 A 记录。
如果这是正确的，那么是的，我希望这能够基于对名称服务器的请求的循环/随机性质而起作用。如果一台服务器发生故障，它将无法响应使用其自身地址的查询，因此客户端应该可以相当快地故障转移到另一台服务器用于 DNS 查找。
您说您理解并接受 DNS 缓存意味着服务器宕机可能会破坏已缓存指向该服务器的查询的客户端，并且可能因为 ISP 不遵守较短的 TTL 而长时间中断。如果真是这样，那么我认为您的提案没有任何明显的漏洞。
我只是不会在一个月的星期天亲自做这件事。
答案3
DNS 负载平衡曾经是值得使用的“东西”，但是随着缓存的广泛使用，它不再那么实用。
在 Windows 中，您可以使用“网络负载均衡器”，它可以通过专用网络上的多播帮助您完成操作。您仍可以通过两家提供商之间的 VPN 跨提供商执行此操作。
在 Linux 中，您需要使用类似haproxy或其他包来实现负载平衡。不过，这本身也带来了挑战。
查看您的选择并决定哪种方案最符合您的需求。除了非常受欢迎的方案之外，我无法进行推测。