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

阅读数:7223 2007 年 11 月 1 日

话题:Java架构语言 & 开发

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?