面試題
為什麼要進行系統拆分？如何進行系統拆分？拆分後不用 dubbo 可以嗎？
面試官心理分析
從這個問題開始就進行分佈式系統環節了，現在出去面試分佈式都成標配了，沒有哪個公司不問問你分佈式的事兒。你要是不會分佈式的東西，簡直這簡歷沒法看，沒人會讓你去面試。
其實為啥會這樣呢？這就是因為整個大行業技術發展的原因。
早些年，印象中在 2010 年初的時候，整個 IT 行業，很少有人談分佈式，更不用說微服務，雖然很多 BAT 等大型公司，因為系統的複雜性，很早就是分佈式架構，大量的服務，只不過微服務大多基於自己搞的一套框架來實現而已。
但是確實，那個年代，大家很重視 ssh2，很多中小型公司幾乎大部分都是玩兒 struts2、spring、hibernate，稍晚一些，才進入了spring mvc、spring、mybatis 的組合。那個時候整個行業的技術水平就是那樣，當年 oracle 很火，oracle 管理員很吃香，oracle 性能優化啥的都是 IT 男的大殺招啊。連大數據都沒人提，當年 OCP、OCM 等認證培訓機構，火的不行。
但是確實隨著時代的發展，慢慢的，很多公司開始接受分佈式系統架構了，這裡面尤為對行業有至關重要影響的，是阿里的 dubbo，某種程度上而言，阿里在這裡推動了行業技術的前進。
正是因為有阿里的 dubbo，很多中小型公司才可以基於 dubbo，來把系統拆分成很多的服務，每個人負責一個服務，大家的代碼都沒有衝突，服務可以自治，自己選用什麼技術都可以，每次發佈如果就改動一個服務那就上線一個服務好了，不用所有人一起聯調，每次發佈都是幾十萬行代碼，甚至幾百萬行代碼了。
直到今日，很高興看到分佈式系統都成行業面試標配了，任何一個普通的程序員都該掌握這個東西，其實這是行業的進步，也是所有 IT 碼農的技術進步。所以既然分佈式都成標配了，那麼面試官當然會問了，因為很多公司現在都是分佈式、微服務的架構，那面試官當然得考察考察你了。
如何進行系統拆分？
這個問題說大可以很大，可以扯到領域驅動模型設計上去，說小了也很小，我不太想給大家太過於學術的說法，因為你也不可能背這個答案，過去了直接說吧。還是說的簡單一點，大家自己到時候知道怎麼回答就行了。
系統拆分為分佈式系統，拆成多個服務，拆成微服務的架構，是需要拆很多輪的。並不是說上來一個架構師一次就給拆好了，而以後都不用拆。
第一輪；團隊繼續擴大，拆好的某個服務，剛開始是 1 個人維護 1 萬行代碼，後來業務系統越來越複雜，這個服務是 10 萬行代碼，5 個人；第二輪，1個服務 -> 5個服務，每個服務 2 萬行代碼，每人負責一個服務。
如果是多人維護一個服務，最理想的情況下，幾十個人，1 個人負責 1 個或 2~3 個服務；某個服務工作量變大了，代碼量越來越多，某個同學，負責一個服務，代碼量變成了 10 萬行了，他自己不堪重負，他現在一個人拆開，5 個服務，1 個人頂著，負責 5 個人，接著招人，2 個人，給那個同學帶著，3 個人負責 5 個服務，其中 2 個人每個人負責 2 個服務，1 個人負責 1 個服務。
個人建議，一個服務的代碼不要太多，1萬行左右，兩三萬撐死了吧。
大部分的系統，是要進行多輪拆分的，第一次拆分，可能就是將以前的多個模塊該拆分開來了，比如說將電商系統拆分成訂單系統、商品系統、採購系統、倉儲系統、用戶系統，等等吧。
但是後面可能每個系統又變得越來越複雜了，比如說採購系統裡面又分成了供應商管理系統、採購單管理系統，訂單系統又拆分成了購物車系統、價格系統、訂單管理系統。
扯深了實在很深，所以這裡先給大家舉個例子，你自己感受一下，核心意思就是根據情況，先拆分一輪，後面如果系統更復雜了，可以繼續分拆。你根據自己負責系統的例子，來考慮一下就好了。
拆分後不用 dubbo 可以嗎？
當然可以了，大不了最次，就是各個系統之間，直接基於 spring mvc，就純 http 接口互相通信唄，還能咋樣。但是這個肯定是有問題的，因為 http 接口通信維護起來成本很高，你要考慮超時重試、負載均衡等等各種亂七八糟的問題，比如說你的訂單系統調用商品系統，商品系統部署了 5 臺機器，你怎麼把請求均勻地甩給那 5 臺機器？這不就是負載均衡？你要是都自己搞那是可以的，但是確實很痛苦。
所以 dubbo 說白了，是一種 rpc 框架，就是說本地就是進行接口調用，但是 dubbo 會代理這個調用請求，跟遠程機器網絡通信，給你處理掉負載均衡了、服務實例上下線自動感知了、超時重試了，等等亂七八糟的問題。那你就不用自己做了，用 dubbo 就可以了。
閱讀更多 程序員界的彭于晏 的文章
