为什么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(和其他框架)带来的是预先编写的样板,以满足制作可伸缩应用程序的常见要求.当然,编写我的应用程序并不能保证它们具有可扩展性,但框架使得编写可扩展应用程序变得更加容易.