windows - 开发集群感知的非基于 Web 的企业应用程序的常见问题

Question

我必须将基于 Windows 的多线程应用程序(使用全局变量和 RDBMS 进行存储)移动到 NLB(即网络负载平衡器)集群。立即想到的常见架构问题是

全局变量(都是读/写的)必须移动到共享存储中。这里的最佳做法是什么？ Windows Clustering API 中是否有任何可用的东西来管理这些东西？

我的应用程序使用套接字，持久连接是我工作领域的规范。我相信持久连接不能负载平衡。同样，在这方面有哪些架构建议？

Answer 1

我将首先回答问题的持久连接部分，因为它更容易。所有优秀的网络负载平衡解决方案(包括 Microsoft 内置于 Windows Server 的 NLB 服务，还包括像 F5 BigIP 这样的负载平衡设备)都能够在连接期间“坚持”从客户端到特定集群节点的各个连接。在 Microsoft 的 NLB 中，这称为“Single Affinity”，而其他负载均衡器将其称为“Sticky Sessions”。有时会有一些警告(例如，如果向集群添加新成员，Microsoft 的 NLB 会中断连接，尽管单个连接永远不会从一台主机移动到另一台主机)。

回复:全局变量，它们是负载平衡系统的祸根。大多数负载平衡应用程序的设计者会进行大量重新架构以尽量减少对共享状态的依赖，因为它会阻碍负载平衡应用程序的可扩展性和可用性。大多数这些方法归结为两步策略:首先，将共享状态移动到高度可用的位置，其次，更改应用程序以最大限度地减少必须访问共享状态的次数。

我见过的大多数集群应用程序都会在 RDBMS 中存储共享状态(甚至是共享的、易失的状态，如全局变量)。这主要是为了方便。您也可以使用 in-memory database以获得最佳性能。但是，将 RDBMS 用于所有共享状态( transient 和持久)的简单性，加上使用现有数据库工具实现高可用性，往往适用于许多服务。 RDBMS 的性能当然比内存中的全局变量慢几个数量级，但是如果共享状态很小，您无论如何都会读取 RDBMS 的缓存，并且如果您要进行网络跳跃来读取/写入数据差异相对较小。您还可以通过优化数据库架构以实现快速读取/写入，例如通过删除不需要的索引并使用 NOLOCK 对所有不需要精确、高达毫秒级精度的读取查询产生重大影响。

我并不是说 RDBMS 永远是共享状态的最佳解决方案，只是改善共享状态访问时间通常不是负载平衡应用程序获得性能的方式——相反，它们通过消除对共享状态的需要来获得性能在每个请求上同步访问(尤其是写入)共享状态。这是我上面提到的第二件事:更改您的应用程序以减少对共享状态的依赖。

例如，对于简单的“计数器”和类似的指标，应用程序通常会将它们的更新排队，并有一个线程负责从队列中异步更新共享状态。

对于更复杂的情况，应用程序可能会从悲观并发(预先检查资源是否可用)切换到 Optimistic Concurrency (假设它是可用的，然后如果您最终完成工作，例如，将相同的项目出售给两个不同的客户!)。

Net-net，在负载平衡的情况下，蛮力解决方案通常不能像创造性地思考您对共享状态的依赖并提出创造性的方法来防止在每个请求上都必须等待同步读取或写入共享状态.

我不会在你的场景中使用 MSCS(微软集群服务)。 MSCS 是一种故障转移解决方案，这意味着即使其中一个集群节点出现故障，它也能很好地保持单服务器应用程序的高可用性，但您将无法从真正的负载平衡服务中获得可扩展性和简单性。我怀疑 MSCS 确实有共享状态的方法(在共享磁盘上)，但它们需要设置一个 MSCS 集群，其中涉及设置故障转移、使用共享磁盘以及其他不适合大多数负载平衡应用程序的复杂性。最好使用数据库或专门的内存解决方案来存储共享状态。