业务架构 实用系统的架构主选：可伸缩性和重/轻量

实用系统的架构主选：可伸缩性和重/轻量  

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