辩论：为什么多数大型网站不是用Java写的？

向右看齐 2022-05-25 07:47 96阅读 0赞

转自：

[![icon-close.png][]][icon-close.png 1]![icon-notifications.svg][]

亲爱的读者：我们最近添加了一些个人消息定制功能，您只需选择感兴趣的技术主题，即可获取重要资讯的[邮件和网页通知][icon-close.png 1]。

[GigaSpaces][]的[Nati Shalom][]最近问到[为什么多数大型网站是用非Java语言编写的][Java]。这个问题在Java社区引发了一场大辩论，InfoQ抓住机会了解到更多围绕这个问题的主要观点。

Shalom在他的帖子中指出，他所知道的许多站点使用了LAMP（Linux, Apache, MySQL, PHP/Perl）组合，有几个网站还开发了自定义的文件系统（如[Google's GFS][Google_s GFS]）或利用了缓存技术（如 [memcached][]）。Shalom指出了为大型Web应用和大型财务应用开发的各种可伸缩性解决方案的相似之处：

> 在数据层我们看到如下特征：
> 
> 1.  增加一个缓存层以利用可用内存资源并减少I/O开销
> 2.  从中央数据库方式转向分区方式，也称为shards（注：[shards][] 是google贡献给hibernate的一个项目，目标是通过hibernate在多重数据库上提供一个统一的视图。）
> 
> 在业务逻辑层：
> 
> 1.  给应用层增加并行语义[（如MapReduce）][MapReduce]
> 2.  转向向外扩展（scale-out）应用模型以达到线性可伸缩性
> 3.  远离经典的两阶段提交和XA事务处理（参见：[来自Pat Helland的教训：生命超越于分布式事务][Pat Helland]）

Shalom接着质疑这些相似的解决方案怎样能有这么不同的应用组合数量。Shalom指出一个可能的原因是[由Todd Hoff提出的][Todd Hoff]——LAMP组合强大且免费，Java是被使用了，但是作为一个辅助组件而非核心来使用。

其他一些观点：

*  [Justin Sher][] [迅速指出][Link 1] eBay、GMail、Amazon、hi5.com 和 Google AdWords 是构建在Java上的
 *  [Shane Isbell][] 谈及了 [文化差异][Link 2]，怀疑是不是墨守陈规的Web开发者比刻板的Java开发者对社交网络站点和“eye candy”更感兴趣，并且还[评论说][Link 3]金融公司有大量预算并倾向于扩展硬件，而Web公司倾向于扩展软件。
 *  另一个人暗示Java解决方案在财务应用方面的流行与[大的Java EE厂商和金融机构的合作关系][Java EE]有关
 *  [Angelo Andreetto][]，提到几年前在金融公司的经历， [相信][Link 4]对潜在风险的保守做法导致了选择基于Java的解决方案，而不是异类的软件套件
 *  [其他人评论][Link 5]说其结果是金融机构的宕机时间通常大于Web公司
 *  George Coller 说[这种质疑是错误的][Link 6]，而真正的问题应该是为什么不更多使用Java EE

GigaSpaces的Mickey Ohayon有一个更细致的回应：

> 从技术的角度看：
> 
>  *  用Php / Perl 开发快且简单，而用JEE更复杂
>  *  从历史上讲有更多可用的知识、主机服务和开发者
>  *  LAMP被证明是稳定且流行的，而JEE更多的是一个基础架构
>  *  JEE需要应用服务器，而这对Web系统来说有时过于有杀伤力了
>  *  从短期看，轻量级Web语言（Php/Perl）应对变化更加灵活（作为基于非MVC的糟糕架构，当然从长期看任何改变的花销都非常高）
>  *  部署和测试Java应用很慢而且需要相对性能更强的机器
> 
> 从财务的角度看：
> 
>  *  JEE开发者比 Perl / Php更昂贵
>  *  学习曲线和上市时间更长
>  *  托管JEE应用服务器更昂贵

诺基亚的[Jilles Van Gurp][]评论说Java EE是对企业领域来说是最优的，这一领域需求集合不同于面向消费者大型网站：

> 这些网站有相对简单的数据基础结构；对诸如事务和持久层（mysql + 非事务ACID后端大多数情况下就足够好了）的需求不严格；实际上没有对重型Web服务栈的需求；等等。基本上所有J2EE素材都是优秀的，大部分只是对面向消费者网站实现具有过度杀伤力。在这里你不需要迷人的IDE；灵活的消息传递总线；难忍复杂的事务逻辑等等。  
>   
> 取而代之，焦点集中于极度可伸缩性；内存使用；cpu使用；缓存；等等。那些事情可由现货供应组件如squid、apache、分布式linux文件系统等等来解决。他们也可由Java组件解决，但是这需要你有J2EE方面的专家去整合它们。这并不容易招募到，因为当前劳务市场缺乏，而且这些人倾向于从事报酬很好的企业类型的工作。

Van Gurp 也认为Java占据了今后的有利位置：

> 最终，我认为所有这些都正在改变。运行ruby或php的Java实现可以给你的php或rails应用给出一个好的安全性、性能、可伸缩性及可管理性推进。如果你正在运作这些大型系统部署却不尝试这一点是愚蠢的。这对php和ruby开发者来说仍是相对未知的，相当多的人没有对完成事情的效率给予足够的关心，相反它们宁愿在硬件上投资。但是一旦他们转而使用Java应用服务器上的php或ruby，他们将发现一个额外组件的世界，可以进一步增强他们的应用。作为证据，Google的Web开发工具链（部分开源）代表了极端大型和快速原型Web开发的技术发展水平。而且从Web开发者的视角看，应用逻辑100%用Java书写。据我了解，Google在它们的Web UI 层没有大规模部署php或类似架构 （如果不是这样，我很有兴趣去学习学习）。

看到辩论展开之后，Shalom表示他与 [Michael O'Keefe的观点][Michael O_Keefe][一致][Link 7]，该观点囊括了上面表述的几个观点。Shalom还提及，伴随诸如 [Spring on Rails][] 和 [Caucho的基于Java的PHP实现 ][Caucho_Java_PHP]的出现，市场出现了集中的趋势，而且开发可伸缩站点的挑战将使LAMP套件和Java在将来日趋靠拢。

你怎么认为？

查看英文原文：[Debate: Why are most large-scale websites not written in Java?][Debate_ Why are most large-scale websites not written in Java]

[icon-close.png]: http://cdn4.infoqstatic.com/statics_s1_20180508-0315/images/icon-close.png
[icon-close.png 1]: http://www.infoq.com/cn/news/2007/11/big-java/#
[icon-notifications.svg]: http://cdn4.infoqstatic.com/statics_s1_20180508-0315/images/icon-notifications.svg
[GigaSpaces]: http://www.gigaspaces.com/
[Nati Shalom]: http://natishalom.typepad.com/
[Java]: http://natishalom.typepad.com/nati_shaloms_blog/2007/10/why-most-scalab.html
[Google_s GFS]: http://labs.google.com/papers/gfs.html
[memcached]: http://www.infoq.com/memcache
[shards]: http://www.hibernate.org/hib_docs/shards/reference/en/html/preface.html
[MapReduce]: http://labs.google.com/papers/mapreduce.html
[Pat Helland]: http://natishalom.typepad.com/nati_shaloms_blog/2007/08/lessons-from-am.html
[Todd Hoff]: http://www.highscalability.com/why-doesnt-anyone-use-j2ee
[Justin Sher]: http://www.xclu.com/blojsom/blog/default/
[Link 1]: http://natishalom.typepad.com/nati_shaloms_blog/2007/10/why-most-scalab.html#comment-85017920
[Shane Isbell]: http://jroller.com/random7/
[Link 2]: http://natishalom.typepad.com/nati_shaloms_blog/2007/10/why-most-scalab.html#comment-85040472
[Link 3]: http://natishalom.typepad.com/nati_shaloms_blog/2007/10/why-most-scalab.html#comment-85141688
[Java EE]: http://natishalom.typepad.com/nati_shaloms_blog/2007/10/why-most-scalab.html#comment-85108934
[Angelo Andreetto]: http://surf.freeflux.net/
[Link 4]: http://natishalom.typepad.com/nati_shaloms_blog/2007/10/why-most-scalab.html#comment-85210714
[Link 5]: http://natishalom.typepad.com/nati_shaloms_blog/2007/10/why-most-scalab.html#comment-85777748
[Link 6]: http://www.theserverside.com/news/thread.tss?thread_id=47135#240680
[Jilles Van Gurp]: http://www.jillesvangurp.com/
[Michael O_Keefe]: http://www.artima.com/forums/flat.jsp?forum=276&thread=216351#283805
[Link 7]: http://natishalom.typepad.com/nati_shaloms_blog/2007/10/why-most-large-.html
[Spring on Rails]: http://thebogles.com/blog/2005/09/spring-on-rails/
[Caucho_Java_PHP]: http://www.caucho.com/
[Debate_ Why are most large-scale websites not written in Java]: http://www.infoq.com/news/2007/10/big-java