我们有一个基于web的客户端服务器产品。客户端预计将用于超过100万用户(一家著名的公司将使用它)。
我们的服务器是在云中设置的。设计过程中的主要问题之一是如何使整个程序成为未来的证明。可以这样说:
到目前为止,我们考虑的选择如下:
。
既然这应该是一个常见的问题,那么对于同样的问题,哪一个是最好的解决方案呢?由于我们的公司规模很小,我们正在寻找技术上和财务上最便宜的解决方案(比如选项3等)。
有人能为同样的问题提供一些指点吗?
K
发布于 2010-04-25 18:26:47
我会选择目录服务器选项。它是最灵活的,并给你最控制发生在一个给定的静坐。
为了避免目录本身成为一个单一的故障点,我将让其中的三、四个目录使用不同的提供者运行不同的位置。让客户端应用程序在启动时随机选择一个directoy,并在所有这些urls中运行,直到找到一个工作的urls为止。
要真正证明这一点,您可能需要一个简单的协议来动态更新目录服务器列表--但是如果实现得不好,那么您的客户端将面临各种各样的恶意欺骗攻击。
发布于 2010-04-25 18:50:30
Re.DNS:请求可以缓存,更改可能需要一段时间才能自我传播(小时到几天)。
我会选择一个优先的I列表,这些I可以在客户端上更新。如果一个IP失败,客户端将重试第2、3等。
发布于 2010-04-26 08:05:01
我不确定我100%理解你的问题,但如果我这么做了,归结为:如果我的服务器移动,我的客户怎么能找到它?
这正是DNS在过去30年中所做的。
您可以选择的每个可能的系统都需要使用初始工作数据进行引导:目录服务器的地址,获得更新地址列表的工作服务器的地址,等等。这就是根dns服务器的用途,而OS供应商将为您提供引导部分。
当然,DNS查询可以被缓存,这就是它应该如何工作,它是如何扩展到互联网大小的。您可以控制缓存(阅读有关TTL的信息),并且通常可以将缓存保持在正常的值上(将缓存保持在其他地方重新部署服务器所需的绝对最短时间是没有意义的)。
https://stackoverflow.com/questions/2710759
复制相似问题