【问题标题】:Future proofing client-server code?面向未来的客户端-服务器代码?
【发布时间】:2011-02-12 05:41:19
【问题描述】:

我们有一个基于 Web 的客户端-服务器产品。该客户端预计将在100万以上的用户中使用(一家著名的公司将使用它)。

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

  1. 云提供商出现故障,然后自动转移到另一个云中的备份
  2. 完全移动到不同的服务器等

到目前为止我们想到的选项是:

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

既然这应该是一个常见的问题,那么最好的解决方案是什么?由于我们公司很小,我们正在寻找技术和财务成本最低的解决方案(比如选项 3 等)?

有人可以提供一些相同的指针吗?

K

【问题讨论】:

  • 这听起来可能很奇怪,但看看僵尸网络是如何运行的。最近发表了一些关于它们是如何组织以及如何分发新指令的有趣论文。似乎与您要解决的问题类似。
  • 好问题,决定错误处理的责任在哪里 - 服务器,客户端,两者?

标签: dns future-proof


【解决方案1】:

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

为避免目录本身成为单点故障,我将让其中的三到四个在不同的位置运行不同的提供商。让客户端应用程序在启动时随机选择一个目录 url,然后遍历它们,直到找到一个可行的。

要使其真正面向未来,您可能需要一个简单的协议来动态更新目录服务器列表 - 但要小心,如果实施不当,您的客户端可能会遭受各种恶意欺骗攻击。

【讨论】:

    【解决方案2】:

    回复。 DNS:可以缓存请求,更改可能需要一段时间才能自行传播(几小时到几天)。

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

    【讨论】:

      【解决方案3】:

      我不确定我是否 100% 理解了您的问题,但如果我理解了,可以归结为:如果我的服务器移动了,我的客户如何找到它?

      这正是 DNS 在近三年来所做的事情。

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

      当然 DNS 查询可以被缓存,这就是它应该如何工作以及它如何扩展到互联网大小的方式。您可以控制缓存(阅读有关 TTL 的信息),并且通常可以将其保持在合理的值上(将其保持在比在其他地方重新部署服务器所需的绝对最短时间更短是没有意义的)。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2020-05-22
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2016-04-22
        相关资源
        最近更新 更多