InfoQ

新闻

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

作者 Ryan Slobojan译者 宋玮 发布于 2007年11月1日 上午1时49分

社区
Architecture,
Java
主题
设计,
性能和可伸缩性,
企业架构
标签
LAMP,
Java EE

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

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

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

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

其他一些观点:

  • Justin Sher 迅速指出 eBay、GMail、Amazon、hi5.com 和 Google AdWords 是构建在Java上的
  • Shane Isbell 谈及了 文化差异,怀疑是不是墨守陈规的Web开发者比刻板的Java开发者对社交网络站点和“eye candy”更感兴趣,并且还评论说金融公司有大量预算并倾向于扩展硬件,而Web公司倾向于扩展软件。
  • 另一个人暗示Java解决方案在财务应用方面的流行与大的Java EE厂商和金融机构的合作关系有关
  • Angelo Andreetto,提到几年前在金融公司的经历, 相信对潜在风险的保守做法导致了选择基于Java的解决方案,而不是异类的软件套件
  • 其他人评论说其结果是金融机构的宕机时间通常大于Web公司
  • George Coller 说这种质疑是错误的,而真正的问题应该是为什么不更多使用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的观点一致,该观点囊括了上面表述的几个观点。Shalom还提及,伴随诸如 Spring on RailsCaucho的基于Java的PHP实现 的出现,市场出现了集中的趋势,而且开发可伸缩站点的挑战将使LAMP套件和Java在将来日趋靠拢。

你怎么认为?

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

相关赞助商

[[InfoQ中文站架构社区|http://www.infoq.com/cn/architecture/],关注设计、技术趋势以及架构师所感兴趣的话题,通过新闻、文章、视频访谈和演讲以及迷你书等为中国架构社区提供一流资讯。

8 条回复

回复

变化 发表人 hello hello 发表于 2007年11月1日 下午9时9分
Re: 变化 发表人 乐 田 发表于 2007年11月11日 上午8时23分
JEE更像是天罡北斗阵,LAMP则是左右互搏术 发表人 Fengbo Xie 发表于 2007年11月4日 下午12时51分
Re: JEE更像是天罡北斗阵,LAMP则是左右互搏术 发表人 Cao Li 发表于 2007年11月5日 上午6时43分
或许5年后,你会问为什么大多数的网站为什么是Java开发,而不是XX语言开发的。 发表人 Wing Pang 发表于 2007年11月4日 下午10时6分
Re: 或许5年后,你会问为什么大多数的网站为什么是Java开发,而不是XX语言开发的。 发表人 Ali Yang 发表于 2007年11月6日 下午11时40分
效益成本比为第一考量 发表人 Jay Zhao 发表于 2007年11月5日 下午9时56分
快速构建的基础 发表人 Gang Yao 发表于 2007年11月8日 上午3时33分
  1. 返回顶部

    变化

    2007年11月1日 下午9时9分 发表人 hello hello

    Java体系比较严谨,严谨到太复杂的时候,就成了几座“大山”了。 而大型网站要常常响应新的变化,对于实际写网页的弟兄们,宁可抢时间也不太会去读之前那个异常复杂的Java类型系统。 不一定要像愚公那样移山,为了看海绕过去不可以么?

  2. 返回顶部

    JEE更像是天罡北斗阵,LAMP则是左右互搏术

    2007年11月4日 下午12时51分 发表人 Fengbo Xie

    规范严格,接口定义严格,才能更好的实现团队开发。 而脚本则更多时候是个人hack起来很惬意。

  3. 每个大型网站的开发的大多数都有一定的历史,不是所有的开发都可以马上就更换其语言以及开发团队的所熟悉的开发框架。 用什么开发并不代表那种开发框架是最优的。重要的是整个网站的系统设计以及维护。

  4. 返回顶部

    Re: JEE更像是天罡北斗阵,LAMP则是左右互搏术

    2007年11月5日 上午6时43分 发表人 Cao Li

    无论哪个,如果想开发地好,都必须遵循“道” 而且那些大型网站的架构并不比所谓企业级应用来得简单 看上去hack地很惬意的高手的技艺,普通人是不会的

  5. 返回顶部

    效益成本比为第一考量

    2007年11月5日 下午9时56分 发表人 Jay Zhao

    无论何时,效益成本比都应做为第一考量

  6. 注意,文章的标题是多数大型网站,不是大多数网站。JAVA 和 轻量Web开发技术各有市场,无论是大型网站还是小型网站。

  7. 返回顶部

    快速构建的基础

    2007年11月8日 上午3时33分 发表人 Gang Yao

    依个人愚见,所谓很多大型的网站都是构建基于非J2EE技术的原因无非以下几种情况: 1.网站创建期早于J2EE技术大肆流行期,此时的J2EE技术还不完整,没有得到更多项目的验证。 2.大型网站从建设初期到成型,大多经历了多个版本的迭代而形成时下看到的“景象”,而很多促成其成为“大型”网站的功能或服务都是从一个小的想法开始,需要快速的推向市场进行验证,并经过不断的提炼和修改,始终保持先前的竞争力,从而立足于竞争大潮的浪尖。而J2EE技术与其他相比,大多情况下,确实存在学习周期长、过程繁杂的问题。 3.任何活动都离不开成本,开办网站更是如此,正如文中所指出的那样,J2EE技术确实存在总支出成本高于其他技术的问题。

  8. 返回顶部

    Re: 变化

    2007年11月11日 上午8时23分 发表人 乐 田

    我也觉得响应变化的能力是动态语言比静态语言的一个很大优势。 Java并非不够好了,也许是它积累的太多,惯性使然造成人家的偏见。从性能和可扩展性角度来说,做一个大型网站需要做的优化思路上是一致的,Java绝对不会比其它语言差。但是也许因为Java能提供的高级功能太多了,很多诱惑造成了人们忘记使用简单的解决方案。而在Lamp这样的架构里面做大应用实现SNA也许是必须的,而Java却不一定,你甚至可以用分布式JVM。所以也许是这种诱惑让一些大型网站戒掉了Java的隐。

独家内容

虚拟化导论

人们很容易想当然的以为虚拟化技术仅仅应用于服务器。而在现实中,虚拟化这一苏醒的概念正被运用于各个层面,其中包括网络,存储以及应用基础架构。在这篇导论中,InfoQ将深入每个方面,详尽向您描述虚拟化技术的运用以及其优点与不足。

用户故事估算技巧

作为开发者,同时也是ThoughtWorks的咨询师,Jay Fields总结了自己估算用户故事的有效技巧。

InfoQ案例研究:纳斯达克市场回放

在这篇案例研究中,InfoQ对Adobe AIR和Amazon的简单存储服务(Simple Storage Service ,S3)在NASDAQ市场回放程序(NASDAQ Market Replay)中的应用进行了详细的分析。

Hadoop基本流程与应用开发

本文介绍了Hadoop的基本流程、业务场景、代码范例以及集成测试。本文是《分布式计算开源框架Hadoop入门实践》三部曲的最后一部。

SOA在互联网系统中的应用

本视频对SOA在互联网系统中的应用进行了探讨,主要以支付宝在SOA的实践为例,主题从敏捷的应用程序(对象与组件)到敏捷的企业系统(应用集成与面向服务),再到敏捷的生态圈(网关与开放平台)。

用数字沟通——来自敏捷精灵的忠告

因为不知道如何反击,技术人员不得不听从业务人员的要求。这已经是老生常谈了。问题何在?开发人员用数字主要是进行计算的,而业务人员使用数字辅助决策。在下面的故事中,“敏捷精灵”鼓励一个开发人员用数字来描述与计算无关的问题。

Hadoop中的集群配置和使用技巧

本文介绍了Hadoop如何配置分布式框架运行环境,同时特别讲解了其中的一些细节。Hadoop可以单机跑,也可以配置集群跑,这里主要重点说一下集群配置运行的过程。本文是Hadoop入门实践三部曲的第二部。

JavaScript多线程编程简介

虽然有越来越多的网站在采用AJAX技术,但是开发复杂的AJAX应用仍然是个难题。本文探索了如何应用多线程缓解其中一些问题。