分佈式的幾件小事（一）爲何要把系統拆分紅分佈式的

1.爲何進行拆分

①項目過於龐大維護困難。
若是系統過去龐大，那麼代碼會有不少，達到幾十萬行上百行，這樣就須要不少人一塊兒來維護一份代碼，這樣就很容易形成各類衝突，這樣光合並代碼就會浪費大量的時間在上面。

②項目發佈複雜。
一個小bug的修改發佈須要整個系統所有進行從新發布，這樣就很麻煩，不但發佈後須要大量的測試，無論這個bug和本身負責的模塊是否有關係，上線以後都要去檢查，防止本身的模塊被改出bug或者由於對方修改某個配置致使本身處錯。

③項目技術升級變動麻煩。
必須本身須要升級某個依賴的版本，那麼就須要考慮到其餘全部模塊的依賴版本問題，幾乎成爲災難。

④上線以後bug定位麻煩。
因爲全部的模塊都在一塊兒，bug排除會比較麻煩。

⑤系統沒法承受高併發。
系統單塊部署，高併發沒法支撐。

2.如何進行拆分

大部分的系統，是要進行多輪拆分的，第一次拆分，可能就是將之前的多個模塊該拆分開來了，好比說將電商系統拆分紅訂單系統、商品系統、採購系統、倉儲系統、用戶系統，等等。

可是後面可能每一個系統又變得愈來愈複雜了，好比說採購系統裏面又分紅了供應商管理系統、採購單管理系統，訂單系統又拆分紅了購物車系統、價格系統、訂單管理系統。

核心意思就是根據狀況，先拆分一輪，後面若是系統更復雜了，能夠繼續分拆。

3.拆分後怎麼通訊

①直接基於spring mvc，純http接口通訊。

②使用dubbo這種rpc框架