面試題

為什么要進行系統(tǒng)拆分？如何進行系統(tǒng)拆分？拆分后不用 dubbo 可以嗎？

面試官心理分析

從這個問題開始就進行分布式系統(tǒng)環(huán)節(jié)了，現(xiàn)在出去面試分布式都成標(biāo)配了，沒有哪個公司不問問你分布式的事兒。你要是不會分布式的東西，簡直這簡歷沒法看，沒人會讓你去面試。

其實為啥會這樣呢？這就是因為整個大行業(yè)技術(shù)發(fā)展的原因。

早些年，印象中在 2010 年初的時候，整個 IT 行業(yè)，很少有人談分布式，更不用說微服務(wù)，雖然很多 BAT 等大型公司，因為系統(tǒng)的復(fù)雜性，很早就是分布式架構(gòu)，大量的服務(wù)，只不過微服務(wù)大多基于自己搞的一套框架來實現(xiàn)而已。

但是確實，那個年代，大家很重視 ssh2，很多中小型公司幾乎大部分都是玩兒 struts2、spring、hibernate，稍晚一些，才進入了spring mvc、spring、mybatis 的組合。那個時候整個行業(yè)的技術(shù)水平就是那樣，當(dāng)年 oracle 很火，oracle 管理員很吃香，oracle 性能優(yōu)化啥的都是 IT 男的大殺招啊。連大數(shù)據(jù)都沒人提，當(dāng)年 OCP、OCM 等認(rèn)證培訓(xùn)機構(gòu)，火的不行。

但是確實隨著時代的發(fā)展，慢慢的，很多公司開始接受分布式系統(tǒng)架構(gòu)了，這里面尤為對行業(yè)有至關(guān)重要影響的，是阿里的 dubbo，某種程度上而言，阿里在這里推動了行業(yè)技術(shù)的前進。

正是因為有阿里的 dubbo，很多中小型公司才可以基于 dubbo，來把系統(tǒng)拆分成很多的服務(wù)，每個人負(fù)責(zé)一個服務(wù)，大家的代碼都沒有沖突，服務(wù)可以自治，自己選用什么技術(shù)都可以，每次發(fā)布如果就改動一個服務(wù)那就上線一個服務(wù)好了，不用所有人一起聯(lián)調(diào)，每次發(fā)布都是幾十萬行代碼，甚至幾百萬行代碼了。

直到今日，很高興看到分布式系統(tǒng)都成行業(yè)面試標(biāo)配了，任何一個普通的程序員都該掌握這個東西，其實這是行業(yè)的進步，也是所有 IT 碼農(nóng)的技術(shù)進步。所以既然分布式都成標(biāo)配了，那么面試官當(dāng)然會問了，因為很多公司現(xiàn)在都是分布式、微服務(wù)的架構(gòu)，那面試官當(dāng)然得考察考察你了。

如何進行系統(tǒng)拆分？

這個問題說大可以很大，可以扯到領(lǐng)域驅(qū)動模型設(shè)計上去，說小了也很小，我不太想給大家太過于學(xué)術(shù)的說法，因為你也不可能背這個答案，過去了直接說吧。還是說的簡單一點，大家自己到時候知道怎么回答就行了。

系統(tǒng)拆分為分布式系統(tǒng)，拆成多個服務(wù)，拆成微服務(wù)的架構(gòu)，是需要拆很多輪的。并不是說上來一個架構(gòu)師一次就給拆好了，而以后都不用拆。

第一輪；團隊繼續(xù)擴大，拆好的某個服務(wù)，剛開始是 1 個人維護 1 萬行代碼，后來業(yè)務(wù)系統(tǒng)越來越復(fù)雜，這個服務(wù)是 10 萬行代碼，5 個人；第二輪，1個服務(wù) -> 5個服務(wù)，每個服務(wù) 2 萬行代碼，每人負(fù)責(zé)一個服務(wù)。

如果是多人維護一個服務(wù)，最理想的情況下，幾十個人，1 個人負(fù)責(zé) 1 個或 2~3 個服務(wù)；某個服務(wù)工作量變大了，代碼量越來越多，某個同學(xué)，負(fù)責(zé)一個服務(wù)，代碼量變成了 10 萬行了，他自己不堪重負(fù)，他現(xiàn)在一個人拆開，5 個服務(wù)，1 個人頂著，負(fù)責(zé) 5 個人，接著招人，2 個人，給那個同學(xué)帶著，3 個人負(fù)責(zé) 5 個服務(wù)，其中 2 個人每個人負(fù)責(zé) 2 個服務(wù)，1 個人負(fù)責(zé) 1 個服務(wù)。

個人建議，一個服務(wù)的代碼不要太多，1萬行左右，兩三萬撐死了吧。

大部分的系統(tǒng)，是要進行多輪拆分的，第一次拆分，可能就是將以前的多個模塊該拆分開來了，比如說將電商系統(tǒng)拆分成訂單系統(tǒng)、商品系統(tǒng)、采購系統(tǒng)、倉儲系統(tǒng)、用戶系統(tǒng)，等等吧。

但是后面可能每個系統(tǒng)又變得越來越復(fù)雜了，比如說采購系統(tǒng)里面又分成了供應(yīng)商管理系統(tǒng)、采購單管理系統(tǒng)，訂單系統(tǒng)又拆分成了購物車系統(tǒng)、價格系統(tǒng)、訂單管理系統(tǒng)。

扯深了實在很深，所以這里先給大家舉個例子，你自己感受一下，核心意思就是根據(jù)情況，先拆分一輪，后面如果系統(tǒng)更復(fù)雜了，可以繼續(xù)分拆。你根據(jù)自己負(fù)責(zé)系統(tǒng)的例子，來考慮一下就好了。

拆分后不用 dubbo 可以嗎？

當(dāng)然可以了，大不了最次，就是各個系統(tǒng)之間，直接基于 spring mvc，就純 http 接口互相通信唄，還能咋樣。但是這個肯定是有問題的，因為 http 接口通信維護起來成本很高，你要考慮超時重試、負(fù)載均衡等等各種亂七八糟的問題，比如說你的訂單系統(tǒng)調(diào)用商品系統(tǒng)，商品系統(tǒng)部署了 5 臺機器，你怎么把請求均勻地甩給那 5 臺機器？這不就是負(fù)載均衡？你要是都自己搞那是可以的，但是確實很痛苦。

所以 dubbo 說白了，是一種 rpc 框架，就是說本地就是進行接口調(diào)用，但是 dubbo 會代理這個調(diào)用請求，跟遠(yuǎn)程機器網(wǎng)絡(luò)通信，給你處理掉負(fù)載均衡了、服務(wù)實例上下線自動感知了、超時重試了，等等亂七八糟的問題。那你就不用自己做了，用 dubbo 就可以了。

當(dāng)前名稱：為什么要系統(tǒng)拆分？如何系統(tǒng)拆分？拆分后不用 dubbo 可以嗎？
鏈接URL：http://chinadenli.net/news12/100112.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計公司、網(wǎng)站維護、標(biāo)簽優(yōu)化、網(wǎng)站營銷、營銷型網(wǎng)站建設(shè)、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)