应用云平台的可用性——从新浪SAE看云平台设计
云计算平台的可用性，相比传统互联网服务而言，更加复杂和困难，也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台，以及对云计算的用户提出了建议。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
辩论：为什么多数大型网站不是用Java写的？
作者 Ryan Slobojan 译者 宋玮 发布于 2007年11月1日
GigaSpaces的Nati Shalom最近问到为什么多数大型网站是用非Java语言编写的。这个问题在Java社区引发了一场大辩论，InfoQ抓住机会了解到更多围绕这个问题的主要观点。
Shalom在他的帖子中指出，他所知道的许多站点使用了LAMP（Linux, Apache, MySQL, PHP/Perl）组合，有几个网站还开发了自定义的文件系统（如Google's GFS）或利用了缓存技术（如 memcached）。Shalom指出了为大型Web应用和大型财务应用开发的各种可伸缩性解决方案的相似之处：
在数据层我们看到如下特征：在业务逻辑层：
- 增加一个缓存层以利用可用内存资源并减少I/O开销
- 从中央数据库方式转向分区方式，也称为shards（注：shards 是google贡献给hibernate的一个项目，目标是通过hibernate在多重数据库上提供一个统一的视图。）
- 给应用层增加并行语义（如MapReduce）
- 转向向外扩展（scale-out）应用模型以达到线性可伸缩性
- 远离经典的两阶段提交和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 Rails 和 Caucho的基于Java的PHP实现 的出现，市场出现了集中的趋势，而且开发可伸缩站点的挑战将使LAMP套件和Java在将来日趋靠拢。
你怎么认为？
查看英文原文：Debate: Why are most large-scale websites not written in Java?
译者 宋玮 有多年软件开发经验，长期担任技术管理和项目管理工作，一直关心开源软件的发展动态以及软件过程和敏捷开发的实践探索。
变化
发表人
hello hello
发表于
Re: 变化
发表人
田 乐
发表于
JEE更像是天罡北斗阵，LAMP则是左右互搏术
发表人
Xie Fengbo
发表于
Re: JEE更像是天罡北斗阵，LAMP则是左右互搏术
发表人
Li Cao
发表于
或许5年后，你会问为什么大多数的网站为什么是Java开发，而不是XX语言开发的。
发表人
Pang Wing
发表于
Re: 或许5年后，你会问为什么大多数的网站为什么是Java开发，而不是XX语言开发的。
发表人
杨 理帆
发表于
效益成本比为第一考量
发表人
Zhao Jay
发表于
快速构建的基础
发表人
Yao Gang
发表于
Re: 快速构建的基础
发表人
haidong wang
发表于
这论题本身就奇怪了
发表人
liu xidong
发表于
-
Java体系比较严谨，严谨到太复杂的时候，就成了几座“大山”了。
而大型网站要常常响应新的变化，对于实际写网页的弟兄们，宁可抢时间也不太会去读之前那个异常复杂的Java类型系统。
不一定要像愚公那样移山，为了看海绕过去不可以么？ -
规范严格，接口定义严格，才能更好的实现团队开发。
而脚本则更多时候是个人hack起来很惬意。 -
每个大型网站的开发的大多数都有一定的历史，不是所有的开发都可以马上就更换其语言以及开发团队的所熟悉的开发框架。
用什么开发并不代表那种开发框架是最优的。重要的是整个网站的系统设计以及维护。 -
无论哪个，如果想开发地好，都必须遵循“道”
而且那些大型网站的架构并不比所谓企业级应用来得简单
看上去hack地很惬意的高手的技艺，普通人是不会的 -
无论何时，效益成本比都应做为第一考量
-
注意，文章的标题是多数大型网站，不是大多数网站。JAVA 和 轻量Web开发技术各有市场，无论是大型网站还是小型网站。
-
依个人愚见，所谓很多大型的网站都是构建基于非J2EE技术的原因无非以下几种情况：
1.网站创建期早于J2EE技术大肆流行期，此时的J2EE技术还不完整，没有得到更多项目的验证。
2.大型网站从建设初期到成型，大多经历了多个版本的迭代而形成时下看到的“景象”，而很多促成其成为“大型”网站的功能或服务都是从一个小的想法开始，需要快速的推向市场进行验证，并经过不断的提炼和修改，始终保持先前的竞争力，从而立足于竞争大潮的浪尖。而J2EE技术与其他相比，大多情况下，确实存在学习周期长、过程繁杂的问题。
3.任何活动都离不开成本，开办网站更是如此，正如文中所指出的那样，J2EE技术确实存在总支出成本高于其他技术的问题。 -
我也觉得响应变化的能力是动态语言比静态语言的一个很大优势。
Java并非不够好了，也许是它积累的太多，惯性使然造成人家的偏见。从性能和可扩展性角度来说，做一个大型网站需要做的优化思路上是一致的，Java绝对不会比其它语言差。但是也许因为Java能提供的高级功能太多了，很多诱惑造成了人们忘记使用简单的解决方案。而在Lamp这样的架构里面做大应用实现SNA也许是必须的，而Java却不一定，你甚至可以用分布式JVM。所以也许是这种诱惑让一些大型网站戒掉了Java的隐。 -
还有一个问题就是JEE服务托管提供商远远少于LAMP的托管商。很多网站都是从免费的托管服务器起步的。不过这一点随着云计算的普及，可以逐渐忽视。
-
为什么大型网站要用JAVA？JAVA又不是专门为此而生的语言，还问啥为什么，不用很正常啊，如果都用才值得思考了。
10 条回复
关注此讨论 回复