如果一個軟體系統很複雜，可不可以將其分離成獨立的N個模塊，用網路通訊來整合？

01-09

每個系統都在不停更新，增加功能。比如我們熟知的SSH框架，如果上面不停要求加功能，在系統龐大到一定程度就很難維護了。
如果我們把 S 和 SH分開，web方面，Struts只負責界面和簡單的功能邏輯，把spring，Hibernate 獨立成一個單獨進程，然後用socket通訊進行數據傳遞。每次新加功能或者新加模塊，再開發一個spring和hibernate的單獨的進程。
我感覺這樣維護會好一點，每次遇到問題，比較容易單獨處理，即使掛掉一個模塊，在前台也只是幾個頁面刷不出來而已，而不會整個系統down掉。
大家覺得這樣的設計有什麼問題么？

可以，最後複雜度和瓶頸就成功轉移給運維部門了。

哦耶！！

這種模式在幾十年前Erlang/OTP 就已經內置了，天生的。

這個概念十幾年前SOA已經炒過了

我上一個系統就是這麼做的，從一開始就這麼設計。

請參看EJB

十幾年前的企業級應用（也就是複雜的軟體系統）第一版的標準就是題主說的這種「分離成獨立的N個模塊，用網路通訊來整合」

然後再參考《expert one-on-one J2EE Development without EJB》，了解下為什麼後來不用這種方式了。想知道詳細的就去看這本書前幾章。

這裡簡單提一下吧：一是太重量，網路和相關配套的組件佔資源多而且慢，代碼複雜度也高，得不償失。二是分散式，既麻煩又不可靠，也不如集群方便擴容。

目前就是這麼乾的呀。

你可以看看zeroICE,

國內的dobbo

註冊中心+ RPC +負載均衡。

這條路已經走得很遠了。

我們正在嘗試把業務邏輯都封裝成獨立的restful介面，不過感覺介面調用的地方還是挺耦合的，正在繼續尋找方法。

你說的這個是按層劃分，spring和hibernate不建議這樣獨立，很多業務邏輯和資料庫是緊耦合的，需要在資料庫的事務里完成。還有如果新增個欄位，幾個應用都要響應，重新發布、測試。

原則就是不要從技術角度拆分應用。

目前業內都是按模塊劃分的。

舉個簡單電商的例子。

可能是這樣分模塊：電商portal、訂單、會員、商品、優惠、支付。

每個模塊都只負責自己的一塊業務，同時對其他模塊開放必要的介面。

這種情況下，哪個模塊有變動，只要介面不變完全不影響其他應用。

運維的同事看到後往往想砍死你

JNDI的EJB，REST，webservice，soa……應該這些很久以前就在用了……

複雜的系統，最好先按業務領域橫向拆分成可獨立部署的子系統，每個子系統內部再按技術（主要是業務層和Web層）縱向拆分成不同的模塊。

子系統之間，前台通過SSO集成，後台通過SOA（Dubbo之類）集成。

現在的時髦說法不就是「微服務」架構嗎？

可以啊，不過模塊間通信還需要鑒權

可以，SOA就是這樣的概念。

缺點是：

需要一個額外的單點登錄模塊，對安全性有要求可能得搞一套oauth服務；

用戶許可權控制的粒度比較粗。

優點：

也許只有比較穩定吧。

另：

還真不一定便於維護，因為功能和模塊都增加了，而且還引入了在原有設計中不需要的技術(比如oauth和MQ)。

更容易劃分責任(踢皮球)倒是真的。

思而不學則怠
-- 論語

共勉

企業服務匯流排？

話說現在我們有個項目就準備這麼干

如果你有錢任性，就多雇幾個保姆，一個做飯，一個看娃，再來一個打掃衛生的，各干各的，專業！絕不會因為一個辭職了，所有家務都落下了。不過，如果您沒錢，呵呵，那您自己就全包了干吧。牛逼的玩意，花銷也大呀，這個道理不能不懂吧？

可以啊，我司就是這樣的架構，計算和數據層獨立，數據間交換使用專用的過濾設備確保安全性，everythings is apps

你這不是分散式系統嗎？網路相當於匯流排。

depends吧，正好重溫google chubby的文章講了點為毛當初不設計成庫。