为什么Java EE可扩展？
我从各种渠道获悉Java EE具有高度可扩展性，但对我来说，似乎永远无法将Java EE应用程序扩展到谷歌搜索引擎或任何其他大型网站的水平。
我想听听它为什么如此可扩展的技术原因。
Java EE被认为是可伸缩的，因为如果您考虑EJB体系结构并在适当的应用程序服务器上运行，它将包括透明地集群并允许使用EJB的多个实例来提供请求的工具。
如果你在普通的java中手动管理事物，你必须自己弄清楚所有这些，例如打开端口，同步状态等。
我不确定您是否可以将Google定义为“大型网站”。 这就像将互联网比作办公室局域网一样。 Java EE并不意味着扩展到全球级别，这就是亚马逊和谷歌等网站使用自己的技术（例如，使用MapReduce）的原因。
有很多论文讨论了Java EE可伸缩性的效率。 例如这个
Java EE的可扩展性使得任何可扩展的东西 ：关注点的分离。 随着您的处理或IO需求的增加，您可以添加新硬件并半透明地重新分配负载（对应用程序来说大部分都是透明的，对于配置猴子来说显然更少）因为分离的，孤立的问题不知道或不关心它们是否’重新使用相同的物理硬件或群集中的不同处理器。
您可以在任何语言或执行平台中创建可伸缩的应用程序 （是的，甚至是古老的System 370大型机上的COBOL。）像Java EE这样的应用程序框架（以及其他应用程序框架，当然Java EE在这方面并不是独一无二的！）让你能够通过这样做轻松 （相对而言）这样做对你来说很重要。
当我的Web应用程序使用EJB来执行某些业务逻辑时，EJB可能位于同一CPU内核上，位于同一CPU中的不同内核上，完全位于不同的CPU上，或者在极端情况下，甚至可能位于行星。 我不知道，并且，在大多数情况下，提供的表现是存在的，我不在乎。 类似地，当我在消息总线上发送消息以进行处理时，我不知道也不关心消息的去向，处理过程中的哪个组件以及处理发生的位置，只要性能属于我的范围内需要。 这就是配置猴子能够解决的问题。 该技术允许这样做，并且工具已经到位，以评估随着系统尺寸的扩大，哪些部件必须去哪里以获得可接受的性能。
现在，当我尝试手动滚动所有这些时，我立即开始解决问题。 如果我没有提前考虑所有的代理，调度和分发，当我的应用扩展超出单个机器处理的范围时，我现在有了重大的重写，因为我将一些应用程序转移到另一个盒子。 然后，每次我的能力增长，我必须一次又一次地这样做。
如果我事先考虑所有这些，我会为每个应用程序编写大量样板代码，这些代码会对所有相同的东西进行微小的变化。 我可以以可扩展的方式编写代码，但我是否希望每次都这样做。 该死的。 时间。 我写了一个应用程序？
因此，Java EE（和其他框架）带来的是预先编写的样板，以满足制作可伸缩应用程序的常见要求。 当然，编写我的应用程序并不能保证它们具有可扩展性，但框架使得编写可扩展应用程序变得更加容易。
从基础框架（如Java EE）提供的角度来看，可以看一个可扩展的架构。 但那只是一个开始。
设计可扩展的基础设施是一种建筑艺术。 这就像投影的艺术……当它被炸成真正大的时候它将如何表现。 基本问题是：
- 我在哪里保留常用的东西，以便当有这么多人要求它时，我不需要这么多时间（缓存）？
- 我在哪里保留每个人的东西，以便当有这么多个人需要保存的东西时，我不会遇到管理它们的麻烦。
- 我怎么能记住一个人上次来这里所做的事情，因为他们可能不会回到他们最后一次访问的同一个节点。
- 如果有这么多人要求，我需要等多久（阻止）长时间运行的程序？
……那种东西超出了框架可以包装的范围。 换句话说，该框架可以扩展，但产品连线太紧，无法扩展。
Java EE作为一个框架具有很强的可扩展性，就像大多数现代微处理器目标企业框架一样。 但是我已经看到了令人惊讶的（不是很好的方式）甚至是最好的东西。
如需大量参考资料，请在Google上搜索“设计可扩展性”
“可伸缩性”的事情谈到“当你的应用程序不再适合单个计算机时你会做什么？”。
可扩展的应用程序可以在更多计算机上增长。
请注意，大型服务器可能拥有大量内存和大量CPU的大型应用程序 – 请参阅http://www.sun.com/servers/highend/m9000/或http://www-03.ibm.com/systems/ i / hardware / 595 / index.html – 但它通常比拥有大量小型服务器并且应用程序遍布它们更昂贵。