扩展Java EE应用程序的基础

老实说，“可扩展性”是一个详尽的主题，并且通常没有被很好地理解。通常，它被假定与高可用性相同。我已经看到新手程序员和“经验丰富”的建筑师都建议将“ 集群 ”作为可伸缩性和HA的解决方案。它实际上没有任何问题，但是问题在于，它通常是通过谷歌搜索来完成的，而不是实际了解应用程序本身;-)

我只是写这篇文章并不声称自己是“专家” ；-)它只是简要地提出了一些用于扩展Java EE应用程序的策略。

问题…

可伸缩性不是Java EE平台规范中的标准化组件。相关技术大多是特定于供应商（应用程序服务器）的，通常涉及使用多个产品（除了应用程序服务器本身）。这就是为什么将Java EE应用程序设计为可伸缩的可能会有些棘手。没有“菜谱”可以帮您实现成功。真正需要从内而外了解应用程序。

缩放类型

我相信这不是您第一次阅读本文。通常，扩展分为两大类–向上扩展，向外扩展

扩大规模的第一步自然就是扩大规模

向上扩展 ：这涉及向服务器中添加更多资源，例如RAM，磁盘空间，处理器等。在某些情况下这很有用，但在特定时间点之后会变得昂贵，您会发现最好采用向外扩展
向外扩展 ：在此过程中，将添加更多计算机或其他服务器实例/节点。这也称为群集，因为所有服务器都应该协同工作（作为一个组或群集），并且对客户端是透明的。

高可用性！=可扩展性

是! 仅仅因为系统具有高可用性（通过让多个服务器节点进行故障转移），并不意味着它也具有可伸缩性。 HA只是意味着，如果当前的处理节点崩溃，该请求将被传递或故障转移到集群中的另一个节点，以便它可以从其开始的地方继续进行–差不多！可伸缩性是通过增加可用资源（RAM，处理器等）来改善系统特定特性（例如，用户数量，吞吐量，性能）的能力。即使失败的请求被传递到另一个节点，您也不能保证应用程序在这种情况下将正常运行（继续阅读以了解原因）

让我们看一些选项和相关讨论

对扩展的集群进行

假设您已扩展到最大容量，现在通过让多个节点组成集群来扩展系统。现在，您要做的就是将负载均衡器放在群集基础结构的前面，以便您可以在群集成员之间分配负载。由于除基本知识之外我没有太多的见识，因此未详细介绍负载平衡 ：-)但是知道这一点对于本文足够了

带有lb-pptx的简单集群

我的应用程序是

好了，现在您可以横向扩展了–够了吗？如果您的应用程序是无状态的，则可以进行横向扩展，即您的应用程序逻辑不依赖于现有服务器状态来处理请求，例如JAX-RS上的RESTful API后端，基于消息的应用程序将远程EJB作为入口，在后面使用JMS地面等

如果您的应用程序包含HTTP会话对象，有状态EJB，会话范围的Bean（CDI，JSF）等组件，该怎么办？这些特定于客户端（更具体地讲，是调用线程），存储特定状态，并依赖于该状态存在以便能够执行请求，例如HTTP会话对象可能存储用户的身份验证状态，购物车信息等

在横向扩展或群集应用程序中，节点中的任何群集都可以满足后续请求。 在没有第一个请求传递到的实例的JVM中创建的状态数据的情况下，另一个节点将如何处理请求？

有状态或无状态1

有状态或无状态21

您好粘性会话！

可以在负载均衡器级别上完成粘性会话配置，以确保始终将来自特定客户端/最终用户的请求转发到同一实例/应用程序服务器节点，即保持服务器亲和力 。因此，我们缓解了所需状态不存在的问题。但是这里有一个陷阱- 如果该节点崩溃怎么办？ 该状态将被破坏，并且用户将被转发到服务器端请求处理所不依赖的现有状态的实例。

粘性1

黏性21

输入

为了解决上述问题，您可以配置应用程序服务器群集机制以支持有状态组件的复制。这样，您可以确保所有服务器实例上都存在HTTP会话数据（和其他有状态对象）。因此，最终用户请求现在可以转发到任何服务器节点。即使服务器实例崩溃或不可用，群集中的任何其他节点也可以处理该请求。现在，您的群集不是普通群集，而是一个复制群集

复制集群1

群集复制特定于您的Java EE容器/应用服务器，最好参考其相关文档以了解具体操作。通常，大多数应用服务器支持Java EE组件的集群，例如有状态和无状态EJB，HTTP会话，JMS队列等。

但是，这带来了另一个问题 –现在，应用程序服务器中的每个节点都处理会话数据，从而导致更多的JVM堆存储并因此产生了更多的垃圾回收。而且，复制中也花费了很多处理能力

有状态组件的

通过将会话数据和有状态对象存储在另一层中，可以避免这种情况。您可以使用RDBMS进行操作。同样，大多数应用服务器都对此提供了内置支持。

rdms-as-cluster-store2

如果您注意到了，我们已经将存储从内存层转移到了持久层–最终，由于数据库的原因，您可能最终会面临可扩展性问题。我并不是说肯定会发生这种情况，但是在某些情况下（例如在发生故障转移的情况下），您的数据库可能会过载，并且延迟可能会增加，具体取决于您的应用程序，请考虑从该数据库重新创建整个用户会话状态，以便在另一个数据库中使用群集实例–这可能会花费一些时间，并在高峰负载期间影响最终用户的体验。

最后的领域：

这是最后的领域-至少在我看来，因为这使我们回到了内存中方法。 than，没有比这更好的了！可以使用诸如Oracle Coherence，Hazelcast或任何其他分布式缓存/内存网格产品之类的产品来卸载状态存储和复制/分发的状态–这不过是缓存层而已。好消息是，其中大多数产品都将HTTP会话存储作为默认功能支持

分布式缓存群集存储1