可伸缩性和重/轻量,谁是实用系统的架构主选?

板桥里人 https://www.jdon.com 2004/08/02

  所谓可伸缩性,是指在小型规模单台服务器情况下,应用系统可以良好运转,系统的访问量或功能增加后,整个系统只需通过增加服务器硬件就可以实现性能扩展,无需修改太多软件。对于可伸缩性平台(如JBoss)来说,理论上,没有最大负载或最多在线人数这样的概念。

   重/轻量其实是使用难易程度,从根本上说,重/轻量应该和可伸缩性不矛盾的,特别是EJB 3.0推出以后,这个问题应该得到比较好的解决。
  
   但是,在目前情况下,编写一个JavaBeans要比编写一个EJB容易多,那么,是重/轻量还是可伸缩性应该成为系统架构的主要依据呢? 在这个问题背后,还隐藏了目前在开源领域两个架构技术选择:
  1. 重量:基于JBoss/EJB的完整J2EE系统架构 (具有可伸缩性,目前不易于学习)
  2. 轻量:基于Tomcat的Struts+Hibernate/Spring+Hibernate (目前无太大可伸缩性,但是易于学习使用)

   因为轻量解决方案易于学习新技术,容易使用,选中率比较高。但是让人产生对系统的可伸缩性担忧。鉴于这种情况,我认为有必要强调一下可伸缩性的重要性,切不能因为要跟进新的设计思想和技术,而盲目地采用一个无可伸缩性的设计方案。
  
   其实,"轻量"应该是一个中性词,但是因为大量新的设计思想比较容易通过轻量方案获得成型软件,如(Spring/Naning/Hibernate)等,逐渐的"轻量"好像变成了一个褒义词。 如果从可伸缩性的标准看,轻量还可能是一个贬义词,轻量意味着丧失重量系统中的分布式网络计算的设计考量,那么可伸缩性就要打问号。

   从这次JavaOne大会以及从长远来看,随着EJB 3.0中间件轻量化、SOA架构理念普及,轻量/重量的区别已经模糊,如果还是以轻量/重量作为架构选择的标准,甚至标榜自己的系统,无疑是不明智的。

   可伸缩性应该依然是实用企业系统架构的主选,可伸缩性是站在软件公司的客户企业立场,为这些客户企业考虑的,但是他们经常因为被认为是外行,挡在了软件系统架构选择的门外。

关于SPING与EJB的胡言乱语--重和轻永恒的话题

伸缩性

分布式计算

进入讨论