【IT168 专稿】
作为一个Java程序员，我们常常会颇感自豪地说：金融行业的大系统一般都是用Java写的。有太多理由让我们相信，Java在企业级应用这块，起着举足轻重的作用。
然而，事实果真如此吗？金融行业或许是那样，可是像Google、Amazon这样的大型网站呢？
面对这样的疑问，在分布式应用、CORBA、JINI、J2EE、网格和SOA领域，有着10多年经验的Nati Shalom，根据事实，得出了“大多数大型网站不是用Java写的”结论，并且分析了形成的原因。
原文一经发表，便引起了极大的关注。笔者希望本文可以对开发者如何选择适合自己的架构，起到一定的借鉴作用。
在过去的几周里，我和我的同事Geva Perry就“为什么大多数大型网站不是用Java写的”这一问题进行了讨论。
在blogosphere上，有大量信息用于描述Google、Amazon、eBay、LinkedIn、TypePad、WikiPedia之类受欢迎的网站的架构。
Pingdom上的人们收集了一些这样的信息，这些信息基于High-Scalability上的一些资料：
图1
在看这些架构的过程中，一些发现，进入脑海：大多数这些站点使用LAMP（译者注：LAMP指Linux、Apache、MySQL和PHP的组合）作为核心运行期栈。
一些甚至于开发了他们自己的文件系统（Google，Google文件系统）；一些则使用缓存来解决数据库的瓶颈问题（memcached之类）；大多数则是被迫由他们自己来开发这些解决方案，因为那个时候，没有能够满足他们需求的现成的选择对象。
这些Web程序的应用栈与构建金融领域的关键性任务程序的应用栈有很大不同。
在金融领域里，Java——较小程度上的J2EE——被广泛地使用。
近年来，资本市场对可伸缩性的需求导致了中间件栈的快速转换。为了虚拟化CPU资源，引入了计算网格，它使得批应用程序并行化。为了虚拟化内存资源，数据网格也被引入。Spring变成当今世界上常用的开发框架。在GigaSpaces上，我们看到，Spring在越来越多的项目中成为J2EE应用的不二选择。
如果我们仔细观察两者（Web和金融领域），我们会发现，双方都在面临与可伸缩性有关的类似挑战。不要惊讶，两者没有引入相似的解决方案，其实都是为了迎接可伸缩性带来的挑战：
在数据层，我们看到：
1. 添加一个缓存层以充分利用内存资源和减少I/O开销。
2. 将以数据库为中心的方式移到分区（又名碎片）的方式。
在业务逻辑层：
3. 为应用层添加并行化语义（例如，MapReduce）。
4. 为了实现线性可伸缩性，移至向外扩展（scale-out）应用模型。
5. 为了事务处理，迁移典型的两阶段提交（two-phase）和扩充体系结构（XA）（参见：http://natishalom.typepad.com/nati_shaloms_blog/2007/08/lessons-from-am.html）。
虽然有许多类似的挑战，并且在一定程度上，有类似的架构，但是似乎两者（Web和金融领域）采取了不同的路线，因为它涉及到应用栈。
透过这些高可伸缩性网站，有人提出了这样的问题：为什么没人使用j2ee？
以下可以作为这个问题答案的总结：
1. LAMP提供了一个有成本效益的解决方案（其中的大部分依赖于免费的开源产品）。
2. Java仍然被使用，只是没有被作为主要语言，例如，它被当作后台或者前台（例如，servlets）的一个组件使用。
【译者序】抛开Nati Shalom的一些观点，笔者也有几点个人看法：
1. 从目前大多数网站的架构来看，在发展初期，大多会选择PHP、ASP.NET或者RoR之类轻、快的开发平台，而到了后期，只有当网站达到较大规模的时候，才可能开始考虑Java平台。毕竟，Java在Web开发这块，目前还做不到轻、快。选用Java平台，同时也意味着开发难度的增大，这无疑会增加开发成本。开发成本的增加，这在网站发展初期，是不大容易被接受的。
2. 在金融领域，稳定、安全是首先需要考虑的因素。就语言层面而言，Java相对于PHP、RoR来说，要成熟也稳定许多。再有，Java平台有大量的优秀的应用服务器可供选择，这对保证程序的稳定性和安全性，起着至关重要的作用。
所以，网站首先需要考虑的是成本，无疑LAMP会降低成本；而金融领域的应用，成本问题倒是其次了，在这种情况下，Java平台“好”的优势就发挥了出来。
