请教系统可伸缩性的架构和技术方向
在java方面，我算个新手。目前需要设计一个系统，需要较好的可伸缩性，因此咨询一下可以采取怎样的框架和技术。
对于架构方向：
一种是ejb，通常系统的可伸缩性总和分布式计算有关了，这是ejb的目标。但我不清楚使用ejb来实现web应用的可伸缩性是否会代价太大，太复杂。
另一种可选择的主流架构就是ssh了
对于技术方向，我的理解
web框架，对伸缩性的影响看来不大。struts, spring mvc等应该都可以吧
我对数据访问层的疑问最大。如果数据的存储是分布式的，又想对领域层或其他更上层透明。ejb的实现我完全不了解，但hibernate好象就很困难。有一个hibernate.sharding的项目，是google贡献的，但查了一下资料，应该不是很成熟。通常数据的分布存储是需要手工制定策略的，现在看起来sharding对领域层的影响是比较大的。
我曾经看到一种我认为比较极端的方案，将关系数据库只做为存储，所有业务层所需要的数据都以领域对象的形式存在于内存中，业务层通过统一的数据管理组件来获取数据。但我觉得这样的数据管理组件的开发应该会很复杂，感觉上比hibernate这一类的都要复杂得多。
我很想知道，有没有比较成熟的解决方案。只要能提供一个方向即可。如果能更进一步地说明方案所涉及的大的技术，将不胜感激。
[b]问题补充：[/b]
@ 1楼 bohemia
谢谢回答。
这倒的确可行，将伸缩性都交给第3方应用。但这样的方案应该还没有达到高度的伸缩性，只是提高了一定的程度。从已知的大多数高负载web应用来看，比如myspace，alibaba等，都应该是从应用程序架构上直接入手。
虽然从应用程序上考虑伸缩性，一定会带来复杂性，但我想业界应该在这一方面已有所努力，我问题中提到的hibernate.sharding就是其一。我所想了解的也的确是在应用程序范围内考虑伸缩性所需要的技术。
[b]问题补充：[/b]
谢谢各位的回答，让我了解了很多知识，给了我很多帮助。
基本同意各位的观点，考虑到大型系统的独特性，我也觉得如果从应用程序的架构考虑，那么架构师的经验应该是成败的关键因素之一了。我对.net相对熟悉，在java领域并不是很熟悉，本意是想也是想知道在java中是否会有较成熟的通用方案。
@ 3楼 lewhwa
google的分布式应用是挺多的
@ 4楼 Lucas Lee
您很注重投入产出比，赞一个。
@ 5，6楼 sdh5724
很赞同您的观点。多谢您提供的一些数据。
帖子看了，大的原则基本了解，无论.net或java，这些基本原则肯定是一致的，与平台应该没什么太大的关系，
只要你不是做每天动态PAGE 5000W以上， 可伸缩的意义基本不大。 现代的硬件能力太强大了。 基本来说来， 没有成熟的公开方案， 这些都是大型站点的才会有东西， 几乎没有open source现成方案。 还有没有多年经验的架构师， 也很难实现这样的系统， 这个需要很全面的考虑问题， 还有根据业务需求设计， 没有什么固定的法则， 或者路可以让你走。 如果一个公司让新手来搞有伸缩性的系统， 那是不负责任的， 也就是那些认为技术不是问题的人才说出来的话。
当然， 我说上面这些， 估计很多人是不服气的， 仅供您参考:
目前， 根据现有硬件条件，无状态的web server群集＋比较强大的数据库硬件, 配合ORACLE的 RAC， 支撑2－5个亿PV不是问题， 如果再增加CACHE支持， 应该能到10亿PV这个规模， 数据库硬件上的投资应该是1000－2000W之间， ORACLE每年的费用估计在500W以上。 当然， 一个公司到了这个规模的访问， 在怎么也能有钱招聘到很好的架构师， 也能设计更好的系统了。 这是我的粗浅看法。
我个人感觉,单套应用程序应该简单,支持扩展;而不是考虑应用程序中做扩展;
比如数据库可以做RAC;
应用服务器可以集群;
WEB服务器可以负载均衡;
我们不是在架构上做的， 哈。
[url]这倒的确可行，将伸缩性都交给第3方应用。但这样的方案应该还没有达到高度的伸缩性，只是提高了一定的程度。从已知的大多数高负载web应用来看，比如myspace，alibaba等，都应该是从应用程序架构上直接入手。[/url]
应该是两方面入手，但是一般的应用或者一般的公司不具备这样的实力。用好3rd Party都不错了。
[quote]虽然从应用程序上考虑伸缩性，一定会带来复杂性，但我想业界应该在这一方面已有所努力，我问题中提到的hibernate.sharding就是其一。我所想了解的也的确是在应用程序范围内考虑伸缩性所需要的技术。[/quote]
Google在这方面绝对走在前面，譬如它的搜搜引擎底层操作系统是Linux，加上了自己的分布式通信组件，同时，其数据表现形式采用了Protocol Buffer（据自称其数据尺寸大大减少，parser性能大大提高），从多个方面提高应用的伸缩性。去google code上面去看看吧，看看是否有启发?
这个跟你要达到的目标很相关。
你不妨说说你的软件特点，要达到的可伸缩性范围。
泛泛的说伸缩性是没有重点的。
Oracle的RAC是不便宜的。
不考虑成本（都盗版？）那也没法考虑了。
继续说下技术上的：
写了半天， 发现自己blog曾经写过 你去看看吧。 没有那么多神秘的东西， 越简单越好： http://sdh5724.iteye.com/admin/blogs/247506