如果有可能向多个客户提供服务，如果提供此服务的服务器发生故障，另一个服务器就会占用它 - 没有某种集中的“控制”，它会检测主服务器是否已关闭并重定向客户到新服务器？
是否可以不使用集中式接口/网关？
换句话说，它有点像问你可以设计节点平衡器而不需要集中控制来指导客户端吗？
答案 0 :(得分：6)
好吧，您没有提供有关您所询问的“服务”的更多信息，因此我将以通用方式回答。
对于我的答案的第一部分，我假设您正在谈论涉及IP地址的“集中式接口/网关”。为此，引用了wiki引用的CARP（通用地址冗余协议）：
公共地址冗余协议或CARP是一种协议 允许同一本地网络上的多个主机共享一组IP 地址。其主要目的是提供故障转移冗余， 特别是与防火墙和路由器一起使用时。在一些 配置CARP还可以提供负载均衡功能。它 是思科HSRP的免费，非专利保护替代品。 CARP是 主要在BSD操作系统中实现。
引用netbsd的“Introduction to CARP”：
CARP的工作原理是允许同一网段上的一组主机 共享IP地址。这组主机称为a “冗余组”。为冗余组分配IP地址 这是在小组成员之间共享的。在组内，一个主机 被指定为“主”，其余被称为“备份”。主人 是目前“持有”共享IP的那个;它响应任何 针对它的流量或ARP请求。每个主机可能属于 一次不止一个冗余组。
这可以解决您在网络级别的问题，让奴隶按顺序接管IP地址，而不会出现单点故障。
现在，对于答案的第二部分（应用程序级别），使用分布式erlang，您可以拥有几个节点（一个集群），它将为您提供容错和冗余（因此您不会在此处使用IP地址，但是“分布式erlang” - 一个erlang节点集群 - 而不是。
您的Distributed Applciation启动时会有很多节点，您的应用程序资源文件将包含可以运行应用程序的节点列表（已订购）。
Distributed erlang将控制哪些节点是“主节点”，并且会在不同节点中自动启动和停止应用程序，因为它们会上下移动。
从http://www.erlang.org/doc/design_principles/distributed_applications.html引用（尽可能少）：
在具有多个Erlang节点的分布式系统中，可能需要 以分布式方式控制应用程序。如果是节点，那么一个 某些应用程序正在运行，关闭，应用程序应该是 在另一个节点重新启动。
应用程序将在第一个节点启动，由 分布式配置参数，已启动并正在运行。该 申请照常开始。
为了使应用程序控制分配正常，节点 分布式应用程序可以运行的地方必须相互联系 协商从哪里开始申请。
启动时，节点将等待指定的所有节点 sync_nodes_mandatory和sync_nodes_optional出现。什么时候 节点已经出现，或者当所有强制节点都出现了 所有应用程序都已经过了sync_nodes_timeout指定的时间 将开始。如果并非所有必需节点都出现，则节点 将终止。
如果正在运行应用程序的节点出现故障，那么 在第一个应用程序重新启动（在指定的超时后） 节点，由分布式配置参数指定，即 启动并运行。这称为故障转移
distributed = [{Application，[Timeout，] NodeDesc}]
如果某个节点已启动，则根据该节点具有更高的优先级 分布式，比分布式应用程序所在的节点 当前正在运行，应用程序将在新节点重新启动 并停在旧节点。这被称为收购。
好的，这是一般概述，因为它可能是一个很长的话题：）
有关具体细节，强烈建议您阅读Distributed OTP Applications的learnyousomeerlang章节（当然还有上一个链接：http://www.erlang.org/doc/design_principles/distributed_applications.html）
此外，您的“服务”可能依赖于其他外部系统（如数据库），因此您也应考虑容错和冗余。整个架构需要具有容错能力，并以“服务”的方式进行分配。
希望它有所帮助！
答案 1 :(得分：5)
此答案概述了网络应用程序的高可用性，而非Erlang特有的。我不太了解OTP框架中可用的内容，因为我不熟悉该语言。
这里有一些不同的问题：
问题1 - 移动客户端连接
这可以通过许多不同的方式和网络架构的不同层来解决。最简单的方法是将其编码到客户端，这样当连接丢失时，它会重新连接到另一台机器。
如果您需要网络透明性，您可以使用某种技术在不同计算机之间同步TCP状态，然后将所有流量重新路由到新计算机，这可能完全对客户端不可见。这比第一个建议要难得多。
我确信这两者之间有很多事情要做。
问题2 - 州数据
您显然需要将会话状态从崩溃的计算机转移到备份计算机。这很难以可靠的方式进行，并且您可能会丢失最后几个事务，因为崩溃的计算机可能无法在崩溃之前发送最后一个状态。您可以通过这种方式使用同步调用确实确保不会丢失状态：
在某些情况下，这可能很昂贵（或者至少没有足够的响应能力），因为您甚至在向客户端确认任何内容之前依赖备份计算机及其连接，包括延迟。为了使其性能更好，您可以让客户端在连接后检查备份机器，然后重新发送丢失的事务，使客户有责任对工作进行排队。
问题3 - 检测到崩溃
这是一个有趣的问题，因为崩溃并不总是很明确。什么事真的崩溃了？考虑一个关闭客户端和服务器之间连接的网络程序，但它们仍然处于启动状态并连接到网络。或者更糟糕的是，如果服务器没有注意到，客户端会与服务器断开连接。以下是一些需要考虑的问题：
答案 2 :(得分：1)
请参阅Google的论文"Chubby lock server" (PDF)和"Paxos made live" (PDF)以获取相关信息。
简而言之，此解决方案涉及使用共识协议在处理所有请求的一组服务器中选择主服务器。如果主设备发生故障，则再次使用该协议来选择下一个主设备。
另外，请参阅gen_leader，了解领导者选举中的一个例子，该选举适用于检测故障和转移服务所有权。