未来验证客户端 - 服务器代码？

Question

我们有一个基于Web的客户端 - 服务器产品。预计客户将在超过1M的用户中使用（一家着名的公司将使用它）。

我们的服务器已在云端设置。设计中的一个主要问题是如何使整个程序面向未来。说：

1. 云提供商关闭，然后自动移动到另一个云中备份
2. 完全转移到其他服务器等

我们想到的选择是：

1. DNS：我们自己在云上运行DNS名称服务器。
2. 目录服务器 - 目录服务器也存在于云端
3. 让我们的服务器将未来的动作和未来的URL等返回给客户端 - 其中客户端专门用于处理这些场景

因为这应该是一个常见的问题，哪个是同样的最佳解决方案？由于我们公司规模很小，我们正在考虑技术上和财务上最不昂贵的解决方案（比如选项3等）？

有人可以提供相同的指示吗？

ķ

Answer 1

我会选择目录服务器选项。它是最灵活的，让您可以最大程度地控制给定坐标中发生的事情。

为了避免目录本身成为单点故障，我会让其中三个或四个运行不同的提供商的不同位置。让客户端应用程序在启动时随机选择一个directoy url并通过它们直到它找到有效的方式。

为了让它真正面向未来，您可能需要一个简单的协议来动态更新目录服务器列表 - 但是如果执行得当，请小心，这样您的客户就会受到各种恶意欺骗攻击。

Answer 2

重新。 DNS：请求可以被缓存，并且更改可能需要一段时间才能自行传播（数小时到数天）。

我会查找可在客户端上更新的优先级IP列表。如果一个IP失败，客户端将以第二个，第三个等重试，等等。

Answer 3

我不确定我是否100％理解您的问题，但如果我这样做，可以归结为：如果我的服务器移动，我的客户怎么能找到它？

这正是DNS在过去三十年中所做的。

您可以选择的每个可能的系统都需要使用初始工作数据进行自举：目录服务器的地址，工作服务器的地址以获取更新的地址列表等。这就是root dns服务器的用途和操作系统供应商将为您做引导部分。

当然可以缓存DNS查询，这是它应该如何工作以及它如何扩展到互联网大小。您可以控制缓存（读取有关TTL），并且通常可以将其保持在合理的值上（没有必要使其短于在其他地方重新部署服务器所需的绝对最短时间）。