我不太了解DNSpipe理等，但是我知道应用程序编程的最佳实践。
目前在我公司有6台服务器，分别命名为：
没关系。
但是，系统pipe理员要求我们在应用程序中处理这些随机端点，这意味着我们需要从这个列表中随机select一个服务器。
这对我来说很不好，因为无论何时我们需要添加一个服务器，我们需要编辑我们的应用程序（即使它只是一个configuration文件），但我认为应用程序不应该知道这样的事情，类似于实体不应该知道坚持服务器。
我虽然是使用DNS负载平衡，一个域，指向不同的IP
一个端点：mobile.domain.com
系统pipe理员告诉我这是坏的或类似的东西，但我相信这是最好的解决scheme，更多它将允许以后的地理定位负载平衡，这是很好的。 顺便说一句，从列表中随机select一个服务器不会阻止服务器closures，因为随机的，只是不是随机的，并不看好我的效率。
感谢您的反馈，如果您有我们可以使用的正反两面的论点：）
DNS循环通常被认为是一种非常低成本的负载均衡解决scheme。 确实，在服务器不可用的情况下，需要手动更改DNS。 您的DNS更改也需要时间传播（这取决于中间parsing器）也是如此。
另一方面，与适当的负载平衡器的成本相比，它非常便宜。 还有复杂性的问题。 有负载平衡的开源解决scheme，但它们不易设置，如果出现问题，您（或您的系统pipe理员）需要有专业知识来解决它。 更新DNS区域是相对简单的事情。
除非您遇到服务的可用性绝对至关重要的情况，或者由于DNS延迟导致的请求失败导致严重的收入损失，否则最好的select是DNS循环。
为了解决您需要什么样的负载平衡的问题，您需要确定失败请求的成本。
在任何情况下，对应用程序的更改（无论是代码还是configuration文件）都不是一个好主意，因为这会引入更长的延迟（传播应用程序更改）。
我想你的系统pipe理员想说的是，使用DNS进行负载平衡并不差，但不方便。 您可以将6 IP添加到特定域的DNS，但难以pipe理群集。 如果你想把其中一台机器转出来，你将不得不编辑你的DNSlogging并等待它传播。 这可以通过设置较低的TTL来处理，但是不能解释任何不遵循DNS协议的中间parsing器。
有一个负载均衡器更方便，将域指向LB，而后面的6个服务器。 它允许添加/删除服务器，因为您不必担心DNS传播时间。
虽然Sameer和Wolfgangsz说的是循环的真实情况，但他们已经用真正的无用机制来低估了这些问题，并且错过了会导致你痛苦的几个问题，包括DNS客户端和parsingDNS代理caching和缺乏在从内容DNS服务器到DNS客户端的旅程中保证顺序保存。
如前所述 ， SRV资源logging解决了所有这些问题。 你得到一个优先权和权重，在代理DNS服务器caching不会破坏。 pipe理员可以和他们一起做最后想做的事情，比如设置备用和主服务器组，指定备用顺序以及使用单个服务器组来控制权重。 编写客户端代码来挑选服务器使用给定的权重和优先级来交谈并不是非常困难的。
取决于谁将使用您的应用程序，只是您或整个世界，您可能必须将注册协议名称（在SRV资源logging域名中使用）与registry（如本文 ）一起注册。 正如你所看到的，其他人已经有了。
正如Sameer所说，一个真正的负载平衡器是另一个，也是可取的，可替代无用的循环洗牌。