java - 在创建高可用性应用程序时最常利用哪些设计模式？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

5年前关闭。




Improve this question




同样，是否有应该避免的设计模式？

Answer 1

我假设您正在编写一个服务器类型的应用程序(让我们暂时离开 Web 应用程序 - 有一些很好的现成解决方案可以帮助那里，所以让我们看看“我有我写的这种很棒的新型服务器"，但我希望它是 HA 问题)。

在服务器实现中，来自客户端的请求通常(以某种形式)转换为某种事件或命令类型模式，然后在一个或多个队列上执行。

所以，第一个问题 - 需要以一种将在集群中存活的方式存储事件/命令(即，当一个新节点作为 master 接管时，它会查看下一个需要执行并开始的命令)。

让我们从单线程服务器实现开始(最简单的 - 和概念仍然适用于多线程，但它有自己的一组问题 0。处理命令时需要某种事务处理。

另一个问题是管理副作用以及如何处理当前命令的失败？在可能的情况下，以事务性的方式处理副作用，以便它们要么全有要么全无。 IE。如果命令更改了状态变量，但在执行过程中崩溃了，那么能够返回到“前一个”状态是很棒的。这允许新的主节点恢复崩溃的命令并重新运行该命令。一个好方法是将副作用分解为可以再次在任何节点上运行的较小任务。 IE。存储主要请求开始和结束任务，有很多小任务处理，每个任务只有一个副作用。

这也引入了会影响您的设计的其他问题。这些状态变量不一定是数据库更新。它们可以是也需要分布在集群中的共享状态(比如内部组件的有限状态机)。因此，管理更改的模式使得主代码必须看到其所需状态的一致版本，然后在整个集群中提交该状态。使用某种形式的不可变(至少来自执行更新的主线程)数据存储很有用。 IE。所有更新都有效地在新副本上完成，这些副本必须通过某种中介或外观，这些副本仅在跨集群更新后使用更新来更新内存中的本地副本(或跨集群的最小成员数量以实现数据一致性)。

其中一些问题也存在于 master worker 系统中。

还需要良好的错误管理，因为状态更新时可能出错的事情的数量会增加(因为现在涉及网络)。

我经常使用状态模式。而不是一行更新，对于副作用，您希望发送请求/响应，并使用特定于对话的 fsm 来跟踪进度。

另一个问题是端点的表示。 IE。连接到主节点的客户端需要能够重新连接到新的主节点，然后监听结果？或者您只是取消所有待处理的结果并让客户重新提交？如果您允许处理挂起的请求，则需要一种识别端点(客户端)的好方法(即，查找中的某种客户端 ID)。

还需要清理代码等(即不希望等待客户端重新连接的数据永远等待)。

使用了很多队列。因此，很多人会使用一些消息总线(对于 Java 来说是 jms)以事务方式推送事件。

兵马俑(再次用于 Java)为您解决了很多问题 - 只需更新内存 - 兵马俑在这里是您的门面/中介。他们刚刚为您注入(inject)了方面。

Terracotta(我不为他们工作) - 引入了“ super 静态”的概念，所以你会得到这些很酷的集群范围的单例，但你只需要知道这将如何影响测试和开发工作流程 - 即。使用大量组合，而不是继承具体实现以实现良好的重用。

对于网络应用程序 - 一个好的应用程序服务器可以帮助 session 变量复制和一个好的负载平衡器工作。在某些方面，通过 REST(或您选择的 Web 服务方法)使用它是编写多线程服务的一种简单方法。但它会对性能产生影响。再次取决于您的问题域。

消息服务(例如 jms)通常用于在不同服务之间引入松散耦合。使用体面的消息服务器，您可以执行很多 msg 路由(同样，apache camel 或类似的工作做得很好)即。比如说一个粘性消费者反对一组 jms 生产者等，这也可以允许良好的故障转移。 Jms 队列等可以提供一种简单的方法来在集群中分发 cmd，独立于主/从。 (同样取决于您是在执行 LOB 还是从头开始编写服务器/产品)。

(如果我以后有时间我会整理一下，也许会在修复拼写语法等方面提供更多细节)