请教系统可伸缩性的架构和技术方向

在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,这些基本原则肯定是一致的,与平台应该没什么太大的关系,

6个回答

只要你不是做每天动态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

Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问