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

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

问题…

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

缩放类型

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

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

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

高可用性！=可扩展性

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

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

对扩展的集群进行

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

我的应用程序是

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

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

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

您好粘性会话 ！

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

输入

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

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

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

有状态组件的

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

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

最后的领域：

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

这种体系结构设置意味着应用程序服务器重新启动不会影响现有的用户会话-在不停机和最终用户停机的情况下对系统进行修补总是很不错的（虽然听起来并不那么容易，但肯定是可以选择的！）。 通常，此想法是应用程序层和Web会话缓存层可以独立工作和扩展，并且不会相互干扰。

已分发！=已复制

这些词之间有很大的差异，因此了解缓存层的差异至关重要。 两者各有利弊

• 分布式 ：缓存成员共享数据，即数据集在缓存集群节点之间分区（使用特定于产品的算法）
• 复制的 ：所有缓存节点都具有所有数据，即每个缓存服务器都包含整个数据集的副本。

进一步阅读（主要针对Weblogic）

• 集群配置
• 用于会话持久性的RDBMS配置
• 分布式Web会话复制– Oracle Coherence ， Hazelcast
• 高可扩展性 –巨大的资源！

在我退出之前...

• 并非每个Java EE应用程序都要求高/极端可伸缩性。 但是，如果您打算构建互联网/面向公众的应用程序，将其纳入设计绝对是有用的
• 对于希望利用云平台（主要是PaaS）（例如自动弹性（经济可行！）和HA）的应用程序，可伸缩设计是必须的
• 不难发现有状态应用程序在扩展方面通常更具挑战性。 完全的“无国籍”可能是不可能的，但人们应该为此努力

随时分享用于扩展Java EE应用程序的技巧和技术。

干杯!

翻译自: https://www.javacodegeeks.com/2015/10/basics-of-scaling-java-ee-applications.html