Java为什么不能动态部署，为什么没有PHP/RoR简单

我也有这样的疑惑。我学Java之前，用ASP/PHP做叻至少3年的WEB开发，深感动态“部署”带来的便利，而事实上像ASP/PHP这样的架构根本也没有“部署”这一步，文件放上去就行叻，简单地狠。

可是学Java之后，一直到现在，也有一个遗憾，就是无法找到一个比较完满的支持动态部署的方案。而在实际Internet应用中，经常要对程序改来改去。。。

我是否可以这样总结，ASP/PHP对于Internet应用支持的狠好，而J2EE则似乎有那么一种天生的Intranet应用的基因。

JSP不是一样可以动态部署吗？一旦涉及的组件开发和部署，动态性就必须考虑组件的状态，rails和PHP一样，都是进程模型，每次请求启动ruby，执行完毕关闭ruby，就好像每次请求你启动一个Java VM，执行完毕关闭Java VM，如果这样去做，Java一样可以动态部署。

所以ASP/PHP/RoR并没有提供真正意义上的动态部署，要说动态部署，也就JSP那叫做真正的动态部署。然而涉及到组件级别动态部署，Java在VM级别没有提供完善的基础设施，当然你也可以通过对classloading机制的编程来实现这一点，例如Atlassian的Confluence和JIRA的plugin框架就是这样做到的，可以实现插件的动态部署，这东西现在开源出来了，叫做tonic，值得好好研究。

robbin误会我的意思叻。。。我并不是说人家ASP/PHP/Rails动态部署好，我也说叻，它们根本就没有部署这一环节。而基于classloading实现的插件机制，最古老的jive就有，并不能算是解决“动态部署”的良方妙药阿。至于JSP，缺点就不说叻，跟ASP/PHP没有什么两样。在体系架构良好的项目里，velocity/freemarker这样的模板语言可以实现任意的更改，但是这也只是页面级的。真正深入到.class文件中，还是只能对jvm做restart或者用类似于tomcat reload的方式。

我觉得Tomcat可以reload应用这一点还是狠方便的，但就是怕它在unload class的时候留下尾巴，比如数据库连接池没有关闭等等。如果这一点没问题，那就真的太好叻。

也不能说ASP/PHP就不需要部署这一环节，准确的来说，ASP/PHP把部署这一环节留给硬件或者操作系统去做了，而Java则是把部署这一环节放在应用服务器内部来实现。

举个例子来说吧，如果要做群集，对于Java来说只不过是配置AppServer，但是对于PHP/RoR，那么就必须寻求操作系统或者硬件方案；
再例如，实现HttpSession，AppServer自己就搞定了，如果PHP/RoR，就必须自己去管理留在硬盘的session临时文件；
再例如，如果你想增加对象缓存，对于Java来说，很好搞定，但是对于PHP/RoR，就没有办法了，必须寻求一些非常偏门的解决方案，例如寻找某些可以使用操作系统共享内存的memory cache，这部署起来的难度远远超乎Java。
再例如，数据库连接池，Java配置起来那也是超乎简单，但是PHP/RoR要实现同样的机制，我还不知道有什么理想的解决方案。

这么说起来，你觉得Java部署简单，还是PHP/RoR部署简单呢？

而实际上呢？排除session的原因，我发现操作系统级的群集最简单、效率最高、最可管理。



而实际上呢？将内存ram作为存放该session临时文件的文件系统，效率一点不差。



而实际上呢？它们根本没有真正OO意义上的对象。:wink: 缓存的目的是什么呢？如果将提升网站响应时间作为最终目的，那么应该缓存的是HTML页面，而不是对象。



这一点我无话可说。事实上我也经常跟我的同学/朋友说，如果PHP有基于Apache的数据库连接池module，我能基于J2EE思想用PHP实现一个比WebWork2+Spring+Hibernate+FreeMarker更简单灵活轻便的WEB开发框架。而这样的框架有叻，就是Ruby On Rails。基于Apache2 API的PHP的数据库连接池module其实也不难开发，但是我还没看到一个广泛使用的、成熟的。



我还是觉得PHP简单。。。    

即使这样，还是要通过操作系统的文件系统API，效率和JVM内部API调用差距还是有很大的。不过这种方式最大的问题在于可移植性。 如果不是在Linux上面运行，你怎么办呢？更何况在内存设置RAMDisk，是不能够动态伸缩的，多了太浪费，少了又不够用，你怎么办呢？



老实说，情况并不完全如此。操作系统群集的配置想对比应用服务器级别来说粗略的多。比如某银行应用，在三台机器上面部署了8个Websphere实例，如何实现根据权重的负载分配，如何实现Session的粘着访问，如何根据不同的应用负载公式分配到不同的实例去等等，操作系统群集控制不到这么细。如果是一个群集负载方案设计的比较复杂的情况下，操作系统群集经常是很难满足需要的。


对象缓存的主要目的是减少对数据库的访问，因为大部分web应用瓶颈都是数据库数据存取。对于一个高点击率的数据库型web网站，使用对象缓存是提升性能最有效的途径，俗话说缓存才是王道！对于PHP/RoR来说，这个级别的缓存是没有的，所以同样负载的吞吐量，Java要高得不止一个数量级。

而PHP/RoR缓存页面的能力必须在前端放置sqiud proxy来实现，那么整个网络的拓扑也相当复杂，自然没有Java的OSCache在web.xml里面配一下就搞定来得爽了。


Apache运行mod的方式基本上是来了请求就创建/预创建进程，用完了就释放，因此无法持有一个全局共享实例来提供所有的进程来访问。因此从原理上来说，就无法实现连接池机制。(PHP的长连接那不是连接池，也有严重的问题)

这个问题引申一下，就是Java服务器端很多能力都来自于有一个应用服务器的概念，从应用服务器一启动，就有一个JVM进程一直在跑，因此可以在JVM的生命周期范围内持有全局共享实例，这个JVM范围内的任何线程都可以访问和存取共享实例，因此诸如数据库连接池、HTTPSession，对象缓存等等功能都可以支持的很好。不过他的一个负面影响就是极大的增加了开发和部署的难度。

但是我认为，对于性能要求比较高，或者应用比较复杂的项目来说，这种应用服务器机制是非常必要的，他提供了在这种情况下所必须的所有的基础设施，如上面列举的这些。

事实上PHP/RoR正好反过来，在抛弃应用服务器概念的同时，也放弃了高端应用的可能性，因为应用服务器概念的缺失导致各个请求之间无法共享全局实例，请求之间无法直接通讯，因此很多基础设施都不具备。

举个最简单的例子来说，我要做一个网页计数器，每个页面被访问的时候加1。就这么个简单的功能，你用PHP/RoR就做不好！

如果是Java那很简单，定义一个类的public static 属性，每个JSP页面都可以访问到它，加1就是了，最多在加1的时候同步一下，就搞定了。分析一下背后的原理，这是因为JVM一直在跑，这个计数器全局实例可以被所有的请求线程访问到。

但是换了PHP/RoR你就没辙！他没有一个应用服务器概念，所以你没有办法定义保持住状态的全局共享实例，每个请求进程执行完就销毁了。你要实现计数器，就必须考虑如何实现进程间通讯，而且还要考虑如何开辟一块操作系统共享内存去存放计数器，最后又怎么释放操作系统共享内存的问题，搞不好，内存就溢出了。我以前做PHP的时候就面临过这样的困扰，不得以，就只能把计数器保存到一个硬盘文件中，所有的访问进程都去存取这个硬盘文件，这效率就可想而知了。

其实RoR的一个重大缺陷也就在于此，RoR是没有数据库连接池的。像这种PHP/RoR的运行方式一旦系统的负载到一定的程度，你往往找不到理想的解决方式，而J2EE就可以有各种手段来很方便的扩展。这方面一个活生生的例子就是eachnet，开始用PHP，后来撑不住了，用Java给它做了页面缓存，还在后端使用BEA的Tuexdo中间件，不过最后还是全部迁移到J2EE平台。

BTW:虽然用PHP跑的网站也很多，有些负载也相当不俗，不过你可以发现一个现象，一旦负载上去了，PHP网站的性能就一落千丈，最后往往不得不依靠动态页面静态化来解决问题。

跟robbin这样讨论狠爽，我想继续讨论。



三大主流平台，Windows/Linux/Unix，全都可以做Ram Disk。另外，你应用服务器里的Session占用的大小更不能动态伸缩啊，总共JVM的堆大小就是启动时指定的。一个PHP的session文件只有几十个字节，1000个session也就几十k。这点内存算不了什么吧。。。

在session管理这一点上，我认为PHP/RoR不吃亏。



嘿嘿，我说叻啊，我那种是最简单的，适合一般性需求。你拿个特殊的复杂的来压我，不公平啊。。。假如PHP也有这样的需求，我想可以这样：

用iptables的NAT做负载均衡，前台Apache用mod_proxy_balancer做权重分配，session问题暂不考虑（要stikcy也可以，不过那就扯远叻）。不同的应用负载公式我不太理解，也是这是最复杂的吧。



对于这个问题，我个人理解是这样的，如果有错误robbin请一定指正我。

方式                           效率数量级
数据库select                        1
数据库select+二级缓存               100
直接页面缓存                        10000

我始终是这样认为的。所以我一直以来的做法也是直接用最后一种方式，将压力放心地丢给前端的Apache，后台的Tomcat只做尽量少的事情。对象的缓存失效和页面的重新生成实际上是一个问题，那何不直接做页面的缓存，减少app server的压力。本来app server抗压就不如apache http server那样的纯httpd。



这个的确是有实现的可能性的，你可以联想一下firebird那样的BBS系统（就是教育网内普遍使用的telnet方式的BBS），它也是每个用户一个进程，大家看的也都是一样的东西。原理是借用linux/unix下的shm（共享内存）。



这段没有意见，除叻最后“极大”那两个字，其它的都同意



PHP我忘叻，ASP可以用application对象轻松实现。



情况的确是这样。



一旦负载上去，J2EE的杀手锏是什么？App Server做cluster？

Unix/Windows平台的RAMDisk实现我确实不知道，孤陋寡闻了。

应用服务器的JVM堆大小当然可以伸缩，如果你不指定最大值，就可以扩展到平台允许的最大值。而且HTTPSession使用的空间在JVM堆里面可以任意伸缩，不存在不够或者浪费的问题。


负载均衡的问题一般不会用到那么复杂，不过高端的企业应用确实就会设计非常复杂的方案，所以说PHP/RoR无法进入高端的企业应用领域。




如果严重依赖用户信息生成的页面，你是无法使用页面缓存的。就拿论坛为例，每个人登陆以后，他没有浏览过的主题前面会有黄色图标显示出来。如果对该页面缓存，那么我登陆以后缓存该页面，然后你登陆，拿出来缓存页面给你，这样你看到的页面其实是给我看的页面，而不是给你看的页面，这样就错了。(现在很多PHP论坛采用这种缓存确实普遍出现了这类问题，要你强制刷新一遍，强迫服务器重新生成你要的页面，才能看到正确的页面)

因此页面缓存只适用于那种不依赖用户定制信息的情况，例如新闻发布什么的。对于动态网站来说，页面缓存往往并不适合，我注意到著名的wiki产品confluence也默认配置了页面缓存，不过他只缓存了CSS文件，没有去缓存xxx.action。

所以动态网站的性能提升之道还是在于对象缓存，降低对数据库的访问次数。

另外值得注意的一个问题是，httpd server抗压能力强不代表它执行速度快，由于apache httpd server是进程加线程的模型，所以执行动态内容并没有纯线程模型例如Java应用服务器快。这个其实你可以很简单的做一下PHP和Java的压力测试就知道了。


这种实现的原理就是利用操作系统共享内存来实现进程间通讯。实际上对于PHP/RoR来说也可以利用这种方式把Session信息放入操作系统共享内存。不过对操作系统共享内存进行编程可并不那么容易，搞好不好操作系统内存都无法回收了，资源管理是一个大问题。如果上面提到的种种问题，如session，缓存，数据库连接池全部都准备采用操作系统共享内存的方式去解决的话，你最后就会发现，你实际上已经实现了一个PHP/RoR版本的应用服务器的早期雏形。


ASP运行在IIS上面，而IIS是一个标准的应用服务器实现。PHP/RoR实现不了高效的网页计数器。


除了那些大家都可以采用的动态页面静态化，页面proxy等等方式(这种方式局限性很大，不适合用户定制化的动态网站)，J2EE提升性能有几个方面：

1、线程模型本身比apache mod的进程方式运行要高效很多；
2、可以使用数据库连接池消除建立数据库物理连接的开销；
3、可以使用对象缓存极大降低对数据库的访问；

RoR没有做过测试，就PHP来说，同样的应用和软件硬件条件，Java的版本负载能力比PHP的版本高出至少一个数量级。

全局共享实例这个问题就是PHP/RoR的致命死穴，从最简单的网页计数器，到企业应用提升性能很关键的数据库连接池和对象缓存，PHP/RoR都做不到，即使能够做到，其代价也远远高于Java。所以PHP/RoR只能用在中小型项目，无法应用于大型企业应用中。

确实有些大网站用PHP也不错，例如Yahoo!，不过我相信Yahoo本身对PHP功能肯定做了必要的扩展，例如很可能使用C++中间件来处理真正的业务逻辑，而PHP仅仅充当View模版的作用。前几天一个在某比价购物网站工作的朋友也提到，他们网站也是这样用的，后台逻辑全部都是C++的中间件，前台用PHP做View。

补充一点，用操作系统共享内存来实现全局共享实例，除了编程很困难之外(必须用操作系统平台API去操纵)，共享内存也是不能动态伸缩的！当你分配了一段共享内存之后，这段内存空间大小就不能再变了，万一你程序负载高了，缓存和连接池，session越用越多，共享内存不够了，你就没办法了，只能重起Apache了。

PHP一个session临时文件30字节，就算有10万个session也仅仅是3M内存，对于这个内存是否浪费的问题似乎并不重要吧。。。



这个我同意。顺便问一句，高端的企业应用方案会复杂到什么程度？能举个例子说明并且说明为什么一定要那么复杂吗？



像你说的论坛这种情况，我会对象缓存+页面缓存一起上。首先将页面生成为HTML（页面缓存），然后内部再去下载一次用户个人信息（对象缓存），最后用javascript将页面最终个性化。这样，表面上app server端的点击量虽然没有减少，甚至还多叻http server那一个点击，但是压力的确是会大大降低。拿JavaEye论坛帖子列表来说，变的是什么？是用户名和帖子旁边的那个是否阅读的小黄图标。而不变的是什么？是帖子列表。数据库里哪张表最大？当然是帖子表叻。与其每次都select三次，包括任务最终还要分页的帖子表，倒不如页面也缓存，只select用户个人信息。而且从数据库查询速度上看，带有用户id的select查询总比分页查询一张大帖子表来的快吧。再深入一点，帖子浏览页面，就更是页面缓存大显身手的时候叻，因为用户的个性化信息更少。


我可从来没说/想/认为/感觉http server执行动态内容快：）不过说到这，我倒是想总结一下，希望robbin能指出我说的不对的地方。有关执行速度，最上面最快，最下面最慢：

http server + 静态内容
app server + 静态内容
http server + 静态内容 + SSI
app server + 静态内容 + SSI
http server + C/C++ fastcgi
app server + 动态内容（即J2EE servlet）
http server + php module / mod_perl
http server + php cgi / perl cgi


实际上，单纯针对linux操作系统的shm进行正确地操纵的话，对于一个合格linux C程序员来讲是基本功，只要控制好各种同步间的信号量。不过话说回来，这个代价的确是狠高。


其实要高效地实现也不是绝对不可以，比如它可以往系统环境变量里写。只不过PHP的确是有这个问题，即使想方设法绕路而行，到最后还是自己给自己找麻烦啊。



第一，线程是否真的高效取决于操作系统。起码在linux 2.4内核上体现不出来这一点。2.6上面线程模型改善狠多，这也是为什么搞J2EE的我们发现内核升级为2.6后JVM性能提升那么多的原因。但即使是这样，2.6内核实现的线程也远不如人们的预期，虽然线程的确比进程快狠多，但是还不够。据说Solaris的线程模型最棒，也许solaris上这一点体现的最明显。

第二，apache并不是只能用进程方式啊，这一点robbin千万千万不要误倒大家啊。apache在linux上倾向于prefork process我个人认为有两大原因：1是经过这么多年的实践，在linux上面用进程模型是最稳定的；2就是linux上线程的实现本身就狠笨重，没有效率上的太大优势。



这个绝对是好东西，也是非app server架构拿不去抢不走的。



这个也是好东西，我倾向于跟页面缓存结合起来用，以发挥更大的威力。


这个我绝对同意，当年就是冲着这一点才使劲学Java的。



这个我也是完全同意并且深有感触的。不过，只能应用J2EE的大型项目所占比例并不大，这也是PHP立足的根本。



关于这个robbin就不必用“相信”这种猜测性字眼叻，我敢肯定它们就是那么干的。之所以这么肯定是因为我知道水木清华BBS就是那么干的。之所以水木负载能力那么强，就是因为它底层代码全部是C，只有web层的view是用php做的，并且代码在一帮linux牛人的强力压榨下已经是最大程度地攫取叻机器资源。



您老咋还想这事呢。。。不就那几兆内存吗大哥。。。

apache在Unix平台采用的是进程加线程的混合模型。apache赖以成名的还是其稳定性，到不是速度。是否在Linux平台Java线程执行效率比apache进程加线程要高，这个我只是一种直观感觉，未经测试证明。

session的问题是这样，如果你往session里面放很多东西，session占用的空间就会大很多。

有时候企业应用部署方案会比较复杂更多的是来自具体业务上面的要求。

确实现在来说，一定要高端的企业项目并不是那么多，所以很多小型的，对执行效率要求很低的项目用J2EE显得大而无当。这个时候用RoR就很合适。所以我把RoR看成是Web开发领域的VB。不过PHP/RoR连数据库连接池都不支持，确实让人感觉很土