所謂可伸縮性
是指在小型規模單台服務器情況下
應用系統可以良好運轉
系統的訪問量或功能增加後
整個系統只需通過增加服務器硬件就可以實現性能擴展
無需修改太多軟件
對於可伸縮性平台（如JBoss）來說
理論上
沒有最大負載或最多在線人數這樣的概念
重/輕量其實是使用難易程度
從根本上說
重/輕量應該和可伸縮性不矛盾的
特別是EJB
推出以後
這個問題應該得到比較好的解決
但是
在目前情況下
編寫一個JavaBeans要比編寫一個EJB容易多
那麼
是重/輕量還是可伸縮性應該成為系統架構的主要依據呢？ 在這個問題背後
還隱藏了目前在開源領域兩個架構技術選擇
重量
基於JBoss/EJB的完整J
EE系統架構 （具有可伸縮性
目前不易於學習）
輕量
基於Tomcat的Struts+Hibernate/Spring+Hibernate （目前無太大可伸縮性
但是易於學習使用）
因為輕量解決方案易於學習新技術
容易使用
選中率比較高
但是讓人產生對系統的可伸縮性擔憂
鑒於這種情況
我認為有必要強調一下可伸縮性的重要性
切不能因為要跟進新的設計思想和技術
而盲目地采用一個無可伸縮性的設計方案
其實
輕量
應該是一個中性詞
但是因為大量新的設計思想比較容易通過輕量方案獲得成型軟件
如（Spring/Naning/Hibernate）等
逐漸的
輕量
好像變成了一個褒義詞
如果從可伸縮性的標准看
輕量還可能是一個貶義詞
輕量意味著喪失重量系統中的分布式網絡計算的設計考量
那麼可伸縮性就要打問號
從這次JavaOne大會以及從長遠來看
隨著EJB
中間件輕量化
SOA架構理念普及
輕量/重量的區別已經模糊
如果還是以輕量/重量作為架構選擇的標准
甚至標榜自己的系統
無疑是不明智的
可伸縮性應該依然是實用企業系統架構的主選
可伸縮性是站在軟件公司的客戶企業立場
為這些客戶企業考慮的
但是他們經常因為被認為是外行
擋在了軟件系統架構選擇的門外
From:http://tw.wingwit.com/Article/program/Java/hx/201311/26876.html
