經典面試題：爲何要把系統拆分紅分佈式的，爲啥要用Dubbo？

參考：https://mp.weixin.qq.com/s/HFVlJoBrM9BW9wSCQY0fRw

一、面試題

爲何要進行系統拆分？如何進行系統拆分？拆分後不用dubbo能夠嗎？

二、面試官內心分析

從這個問題開始就進行分佈式系統環節了，好多同窗給我反饋說，如今出去分佈式成標配了，沒有哪一個公司不問問你分佈式的事兒。你要是不會分佈式的東西，簡直這簡歷無法看，沒人會讓你去面試。

其實爲啥會這樣呢？這就是由於整個大行業技術發展的緣由。

早些年，我印象中在2010年初的時候，整個IT行業，不多有人談分佈式，更不用說微服務，雖然不少BAT等大型公司，由於系統的複雜性，很早就是分佈式架構，大量的服務，只不過微服務大多基於本身搞的一套框架來實現而已。

可是確實，那個年代，你們很重視ssh2，不少中小型公司幾乎大部分都是玩兒struts二、spring、hibernate，稍晚一些，才進入了spring mvc、spring、mybatis的組合。那個時候整個行業的技術水平就是那樣，當年oracle很火，oracle管理員很吃香，oracle性能優化啥的都是IT男的大殺招啊。連大數據都沒人提，當年OCP、OCM等認證培訓機構，火的不行。

可是確實隨着時代的發展，慢慢的，不少公司開始接受分佈式系統架構了，這裏面尤其對行業有相當重要影響的，是阿里的dubbo，某種程度上而言，阿里在這裏推進了行業技術的前進。

正是由於有阿里的dubbo，不少中小型公司才能夠基於dubbo，來把系統拆分紅不少的服務，每一個人負責一個服務，你們的代碼都沒有衝突，服務能夠自治，本身選用什麼技術均可以，每次發佈若是就改動一個服務那就上線一個服務好了，不用全部人一塊兒聯調，每次發佈都是幾十萬行代碼，甚至幾百萬行代碼了。

直到今日，我很高興的看到分佈式系統都成行業面試標配了，任何一個普通的程序員都該掌握這個東西，其實這是行業的進步，也是全部IT碼農的技術進步。因此既然分佈式都成標配了，那麼面試官固然會問了，由於不少公司如今都是分佈式、微服務的架構，那面試官固然得考察考察你了。

三、友情提示

若是有個同窗看到這裏說，我天，我不知道啥是分佈式系統？我也不知道啥是dubbo？那你趕忙百度啊，搜個dubbo入門，去裏面體驗一下。

分佈式系統，我用一句話給你解釋一下，就是原來20萬行代碼的系統，如今拆分紅20個小系統，每一個小系統1萬行代碼。本來代碼之間直接就是基於spring調用，如今拆分開來了，20個小系統部署在不一樣的機器上，得基於dubbo搞一個rpc調用，接口與接口之間經過網絡通訊來請求和響應。就這個意思。

四、面試題剖析

（1）爲何要將系統進行拆分？

網上查查，答案極度零散和複雜，很瑣碎，緣由一大坨。可是我這裏給你們直觀的感覺：

1）要是不拆分，一個大系統幾十萬行代碼，20我的維護一份代碼，簡直是悲劇啊。代碼常常改着改着就衝突了，各類代碼衝突和合並要處理，很是耗費時間；常常我改動了個人代碼，你調用了我，致使你的代碼也得從新測試，麻煩的要死；而後每次發佈都是幾十萬行代碼的系統一塊兒發佈，你們得一塊兒提心吊膽準備上線，幾十萬行代碼的上線，可能每次上線都要作不少的檢查，不少異常問題的處理，簡直是又麻煩又痛苦；並且若是我如今打算把技術升級到最新的spring版本，還不行，由於這可能致使你的代碼報錯，我不敢隨意亂改技術。

假設一個系統是20萬行代碼，其中小A在裏面改了1000行代碼，可是此時發佈的時候是這個20萬行代碼的大系統一起發佈。就意味着20萬上代碼在線上就可能出現各類變化，20我的，每一個人都要緊張地等在電腦面前，上線以後，檢查日誌，看本身負責的那一起有沒有什麼問題。

小A就檢查了本身負責的1萬行代碼對應的功能，確保ok就閃人了；結果不巧的是，小A上線的時候不當心修改了線上機器的某個配置，致使另外小B和小C負責的2萬行代碼對應的一些功能，出錯了。

幾十我的負責維護一個幾十萬行代碼的單塊應用，每次上線，準備幾個禮拜，上線 -> 部署 -> 檢查本身負責的功能。

最近從2013年到如今，5年的時間裏，2013年之前，基本上都是BAT的天下；2013年開始，有幾個小巨頭開始快速的發展，上市，幾百億美金，估值都幾百億美金；2015年，出現了除了BAT之外，又有幾個互聯網行業的小巨頭出現。

BAT工做，在市值幾百億美金的小巨頭工做

有某一個小巨頭，如今估值幾百億美金的小巨頭，5年前剛開始搞的時候，核心的業務，幾十我的，維護一個單塊的應用

維護單塊的應用，在從0到1的環節裏，是很合適的，由於那個時候，是系統都沒上線，沒什麼技術挑戰，你們有條不紊的開發。ssh + mysql + tomcat，可能會部署幾臺機器吧。

結果不行了，後來系統上線了，業務快速發展，10萬用戶 -> 100萬用戶 -> 1000萬用戶 -> 上億用戶了。

2）拆分了之後，整個世界清爽了，幾十萬行代碼的系統，拆分紅20個服務，平均每一個服務就1~2萬行代碼，每一個服務部署到單獨的機器上。20個工程，20個git代碼倉庫裏，20個碼農，每一個人維護本身的那個服務就能夠了，是本身獨立的代碼，跟別人不要緊。再也沒有代碼衝突了，爽。每次就測試我本身的代碼就能夠了，爽。每次就發佈我本身的一個小服務就能夠了，爽。技術上想怎麼升級就怎麼升級，保持接口不變就能夠了，爽。

因此簡單來講，一句話總結，若是是那種代碼量多達幾十萬行的中大型項目，團隊裏有幾十我的，那麼若是不拆分系統，開發效率極其低下，問題不少。可是拆分系統以後，每一個人就負責本身的一小部分就行了，能夠隨便玩兒隨便弄。分佈式系統拆分以後，能夠大幅度提高複雜系統大型團隊的開發效率。

可是同時，也要提醒的一點是，系統拆分紅分佈式系統以後，大量的分佈式系統面臨的問題也是接踵而來，因此後面的問題都是在圍繞分佈式系統帶來的複雜技術挑戰在說。

（2）如何進行系統拆分？

這個問題說大能夠很大，能夠扯到領域驅動模型設計上去，說小了也很小，我不太想給你們太過於學術的說法，由於你也不可能背這個答案，過去了直接說吧。仍是說的簡單一點，你們本身到時候知道怎麼回答就好了。

系統拆分分佈式系統，拆成多個服務，拆成微服務的架構，拆不少輪的。上來一個架構師第一輪就給拆好了，第一輪；團隊繼續擴大，拆好的某個服務，剛開始是1我的維護1萬行代碼，後來業務系統愈來愈複雜，這個服務是10萬行代碼，5我的；第二輪，1個服務 -> 5個服務，每一個服務2萬行代碼，每人負責一個服務。

若是是多人維護一個服務，<=3我的維護這個服務；最理想的狀況下，幾十我的，1我的負責1個或2~3個服務；某個服務工做量變大了，代碼量愈來愈多，某個同窗，負責一個服務，代碼量變成了10萬行了，他本身不堪重負，他如今一我的拆開，5個服務，1我的頂着，負責5我的，接着招人，2我的，給那個同窗帶着，3我的負責5個服務，其中2我的每一個人負責2個服務，1我的負責1個服務。

我我的建議，一個服務的代碼不要太多，1萬行左右，兩三萬撐死了吧！

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

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

扯深了實在很深，因此這裏先給你們舉個例子，你本身感覺一下，核心意思就是根據狀況，先拆分一輪，後面若是系統更復雜了，能夠繼續分拆。你根據本身負責系統的例子，來考慮一下就行了。

（3）拆分後不用dubbo能夠嗎？

固然能夠了，大不了最次，就是各個系統之間，直接基於spring mvc，就純http接口互相通訊。可是這個確定是有問題的，由於http接口通訊維護起來成本很高，你要考慮超時重試、負載均衡等等各類亂七八糟的問題，好比說你的訂單系統調用商品系統，商品系統部署了5臺機器，你怎麼把請求均勻地甩給那5臺機器？這不就是負載均衡？你要是都本身搞那是能夠的，可是確實很痛苦。

因此dubbo說白了，是一種rpc框架，就是本地就是進行接口調用，可是dubbo會代理這個調用請求，跟遠程機器網絡通訊，給你處理掉負載均衡了、服務實例上下線自動感知了、超時重試了，等等亂七八糟的問題。那你就不用本身作了，用dubbo就能夠了。