假设我有一个在 Windows 服务器机器上运行的独立 Windows 服务。如何确保它是高可用的?
1)。您可以提出哪些设计级别指南?
2)。如何让它像primary/secondary一样高可用,例如目前市场上可用的集群解决方案
3)。在任何故障转移情况下如何处理横切关注点
如果还有其他你能想到的,请在此处添加..
注意: 该问题仅与windows和windows服务有关,请尽量遵守此规则:)
假设我有一个在 Windows 服务器机器上运行的独立 Windows 服务。如何确保它是高可用的?
1)。您可以提出哪些设计级别指南?
2)。如何让它像primary/secondary一样高可用,例如目前市场上可用的集群解决方案
3)。在任何故障转移情况下如何处理横切关注点
如果还有其他你能想到的,请在此处添加..
注意: 该问题仅与windows和windows服务有关,请尽量遵守此规则:)
为了使服务至少保持运行,您可以安排 Windows 服务管理器在服务崩溃时自动重新启动服务(请参阅服务属性上的“恢复”选项卡。)此处提供了更多详细信息,包括用于设置这些属性的批处理脚本 -重新启动Windows 服务(如果它崩溃)
高可用性不仅仅是从外部保持服务 - 服务本身需要在构建时考虑到高可用性(即在整个过程中使用良好的编程实践,适当的数据结构,配对资源获取和释放),以及整个压力 -测试以确保它会在预期负载下保持稳定。
对于幂等命令,可以通过重新调用命令一定次数来容忍间歇性故障(例如锁定资源)。这允许服务保护客户端免受故障(在一定程度上)。客户端也应该被编码以预测故障。客户端可以通过多种方式处理服务故障 - 记录、提示用户、重试 X 次、记录致命错误和退出都是可能的处理程序 - 哪种方式适合您取决于您的要求。如果服务有“会话状态”,当服务严重失败(即进程重新启动)时,客户端应该意识到并处理这种情况,因为这通常意味着当前的会话状态已经丢失。
单台机器容易受到硬件故障的影响,因此如果您要使用单台机器,请确保它具有冗余组件。HDD 特别容易发生故障,因此至少要有镜像驱动器或 RAID 阵列。PSU 是下一个弱点,因此冗余 PSU 和 UPS 也是值得的。
至于集群,Windows 支持服务集群,并使用网络名称而不是单个计算机名称来管理服务。这允许您的客户端连接到运行该服务的任何机器,而不是硬编码的名称。但除非您采取额外措施,否则这就是资源故障转移——将请求从一个服务实例定向到另一个实例。会话状态通常会丢失。如果您的服务正在写入数据库,那么也应该将其集群化以确保可靠性并确保整个集群都可以使用更改,而不仅仅是本地节点。
这真的只是冰山一角,但我希望它能给你一些想法,让你开始进一步的研究。
如果你分解你试图解决的问题,我想你自己可能会想出一些答案。正如贾斯汀在评论中提到的,没有一个答案。这完全取决于您的服务做什么以及客户如何使用它。您也没有指定有关客户端-服务器交互性的任何详细信息。HTTP?TCP?UDP?其他?
这里有一些事情要考虑让你开始。
1)如果服务或服务器宕机了怎么办?
2) 好的,但是现在客户如何知道多项服务?
3) 那么如果一项服务出现故障怎么办?
这应该让您了解如何开始使用高可用性的基本概念。如果您提供有关您的架构的具体细节,您可能会得到更好的响应。
如果该服务没有为客户端连接公开任何接口,您可以:
广播或公开“我还活着”的消息或向数据库/注册表/tcp/任何你还活着的信号发送信号
有第二个服务(监视器)检查这些“我还活着”信号,并尝试重新启动服务以防它关闭
但是如果你有一个客户端通过 namedpipes/tcp/etc 连接到这个服务,客户端必须检查运行在数据库中的服务的机器的地址,或者有一些更高级的东西,比如智能开关来重定向流量。