|
所谓可伸缩性是指在小型规模单台服务器情况下应用系统可以良好运转系统的访问量或功能增加后整个系统只需通过增加服务器硬件就可以实现性能扩展无需修改太多软件对于可伸缩性平台（如JBoss）来说理论上没有最大负载或最多在线人数这样的概念 重/轻量其实是使用难易程度从根本上说重/轻量应该和可伸缩性不矛盾的特别是EJB 推出以后这个问题应该得到比较好的解决 但是在目前情况下编写一个JavaBeans要比编写一个EJB容易多那么是重/轻量还是可伸缩性应该成为系统架构的主要依据呢？ 在这个问题背后还隐藏了目前在开源领域两个架构技术选择 重量基于JBoss/EJB的完整JEE系统架构 （具有可伸缩性目前不易于学习） 轻量基于Tomcat的Struts+Hibernate/Spring+Hibernate （目前无太大可伸缩性但是易于学习使用） 因为轻量解决方案易于学习新技术容易使用选中率比较高但是让人产生对系统的可伸缩性担忧鑒于这种情况我认为有必要强调一下可伸缩性的重要性切不能因为要跟进新的设计思想和技术而盲目地采用一个无可伸缩性的设计方案 其实轻量应该是一个中性词但是因为大量新的设计思想比较容易通过轻量方案获得成型软件如（Spring/Naning/Hibernate）等逐渐的轻量好像变成了一个褒义词如果从可伸缩性的标准看轻量还可能是一个贬义词轻量意味着丧失重量系统中的分布式网络计算的设计考量那么可伸缩性就要打问号 从这次JavaOne大会以及从长远来看随着EJB 中间件轻量化SOA架构理念普及轻量/重量的区别已经模糊如果还是以轻量/重量作为架构选择的标准甚至标榜自己的系统无疑是不明智的 可伸缩性应该依然是实用企业系统架构的主选可伸缩性是站在软件公司的客户企业立场为这些客户企业考虑的但是他们经常因为被认为是外行挡在了软件系统架构选择的门外 |
