自托管 ServiceStack 3.x 服务的冗余 [关闭]

Question

我们正在使用 ServiceStack 3.x 运行自托管 AppService

如果当前作为主服务器运行的服务出现故障，我们希望在客户端上有一个自动故障转移机制。

目前的客户端是使用默认 SS JSONClient 的强类型 C#，但我们将在未来添加基于 Web 的客户端 (AngularJS)。

有没有人有想法，怎么做？

Answer 1

服务器端冗余和故障转移：

这是一个非常广泛的问题。 ServiceStack 自托管应用程序与任何其他面向 Web 的资源没有什么不同。所以你可以把它当作一个网站。

网站正常运行时间监控服务：

您可以使用常规网站监控工具对其进行监控。这些工具可以像正常运行时间监控站点一样简单，它只是定期 ping 您的 Web 服务以确定它是否启动，如果没有采取措施，例如触发您的服务器重新启动，或者只是给您发送一封电子邮件说它不工作。

云服务提供商：

如果您使用的是 Amazon EC2 等云提供商，他们会提供 CloudWatch 服务，这些服务可以配置为监控您的主机和服务的运行状况。如果发生故障，它可能会重新启动您的实例，或启动另一个实例。其他提供商也提供类似的工具。

DNS 故障转移：

您还可以考虑 DNS 故障转移。许多 DNS 提供商可以监控服务的正常运行时间，并且在发生故障转移时，他们的服务将更改 DNS 路由以指向另一个备用服务。所以故障转移对客户端是透明的。

负载均衡器：

另一种选择是将您的服务置于负载均衡器之后，并让多个实例运行您的服务。负载均衡器背后的所有节点发生故障的可能性通常很低，除非您的服务设计出现灾难性的错误。

看门狗应用程序：

当您使用自托管应用程序时，您可以考虑在您的系统上创建另一个应用程序来简单地检查您的服务应用程序主机是否正在运行，如果没有则重新启动它。这将处理异常导致您的应用意外终止的情况 - 当然这不是长期解决方案，您需要修复异常。

高可用性代理（HAProxy、NGINX 等）：

如果您在 Linux 平台上使用 Mono 运行 ServiceStack 应用程序，则有许多高可用性解决方案，包括 HAProxy 或 NGINX。如果您在 Windows Server 上运行，它们会提供failover mechanisms。

注意事项：

正确的解决方案取决于您的环境、您的项目预算以及您需要多快解决故障转移问题。最终的考虑应该是服务故障转移到哪里？

• 您是否会有另一台服务器运行您的服务，只是处于待机状态 - 以防万一？
• 您会使用云按需启动另一个实例吗？
• 您会尝试恢复现有的应用服务器吗？

资源：

那里有很多关于网站故障转移的文章，因为您的网络服务像网站一样使用 HTTP，它们也适用于这里。您应该研究高可用性。

Amazon AWS 有很多解决方案来帮助进行故障转移。他们的Route 53 service 在这方面非常出色，他们的负载均衡器也是如此。

客户端故障转移：

客户端故障转移很少实用。在您的客户端中，您最终只能测试连接性。

连接检查：

当您的服务连接失败时，您会收到异常。收到异常后，唯一的解决方案是更改目标服务 URL，然后重试请求。但是这样做有很多问题：

• 它可能与服务器端故障转移一样昂贵，因为您必须始终保持故障转移服务在线以防万一。 一些服务器端解决方案允许您按需启动故障转移服务，从而显着降低成本。

• 所有客户端也必须知道要进行故障转移的 URL。 如果您在 DNS（即服务器端）管理故障转移，那么客户端就不必担心这种复杂性。

• 您的客户端只能看到连接失败，服务器可能没有问题，可能是他们的连接。 想象一下客户端 wifi 在为您的主要服务服务器提供服务时出现了几秒钟的中断。在此期间，客户端收到连接异常，您尝试将请求发送到故障转移辅助服务服务器，此时他们的 wifi 上线。现在您的客户同时使用主要和次要服务。所以他们的网络连接问题变成了你的数据一致性问题。

• 如果您正在规划基于 Web 的客户端，那么您必须在服务器上设置 CORS 支持，并且所有客户端都需要兼容的浏览器，以便他们可以更改目标服务 URL。 CORS 请求的缺点是开销比常规请求更多，因为客户端也必须发送 OPTIONS 请求。

• 客户端中的连接错误检测很少很快。有时，可能需要超过 30 秒的时间，客户端才会因请求失败而超时。

• 如果您的服务 API 是公开的，那么您需要依赖最终用户实施故障转移机制。您不能保证他们会这样做，或者他们会正确地这样做，或者他们不会利用知道您的其他服务 URL 并在那里发送请求。而且看起来很不专业。

• 您不能保证故障转移会在需要时工作。很难保证对于任何系统，即使是大公司也存在故障转移问题。服务器端故障转移解决方案有时无法正常工作，但对于客户端解决方案更是如此，因为您可以在所有不同的客户端环境因素下提前测试故障转移解决方案。仅仅因为您在客户端中实现的故障转移在您的部署中有效，它会在所有部署中有效吗？毕竟，故障转移解决方案的重点是最大限度地降低风险。服务器端故障转移不工作的风险远小于客户端，因为它是一个较小的可控环境，您可以对其进行测试。

总结：

因此，尽管我的考虑可能不利于客户端故障转移，但如果您打算这样做，则需要捕获连接异常并决定如何处理它们。您可能需要等待几秒钟，然后重试对主服务器的请求，然后再立即切换到辅助服务器，以防出现间歇性错误。

所以：

1. 捕获连接异常
2. 重试请求（可能会稍有延迟）
3. 仍然失败，更改目标主机并重试
4. 如果失败，则可能是客户端连接问题。