2021-02-10 分類: 網(wǎng)站建設(shè)
面試題
為什么要進(jìn)行系統(tǒng)拆分?如何進(jìn)行系統(tǒng)拆分?拆分后不用 dubbo 可以嗎?
面試官心理分析
從這個問題開始就進(jìn)行分布式系統(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,稍晚一些,才進(jìn)入了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ù)的前進(jìn)。
正是因為有阿里的 dubbo,很多中小型公司才可以基于 dubbo,來把系統(tǒng)拆分成很多的服務(wù),每個人負(fù)責(zé)一個服務(wù),大家的代碼都沒有沖突,服務(wù)可以自治,自己選用什么技術(shù)都可以,每次發(fā)布如果就改動一個服務(wù)那就上線一個服務(wù)好了,不用所有人一起聯(lián)調(diào),每次發(fā)布都是幾十萬行代碼,甚至幾百萬行代碼了。
直到今日,很高興看到分布式系統(tǒng)都成行業(yè)面試標(biāo)配了,任何一個普通的程序員都該掌握這個東西,其實這是行業(yè)的進(jìn)步,也是所有 IT 碼農(nóng)的技術(shù)進(jìn)步。所以既然分布式都成標(biāo)配了,那么面試官當(dāng)然會問了,因為很多公司現(xiàn)在都是分布式、微服務(wù)的架構(gòu),那面試官當(dāng)然得考察考察你了。
如何進(jìn)行系統(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),是要進(jìn)行多輪拆分的,第一次拆分,可能就是將以前的多個模塊該拆分開來了,比如說將電商系統(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 框架,就是說本地就是進(jìn)行接口調(diào)用,但是 dubbo 會代理這個調(diào)用請求,跟遠(yuǎn)程機器網(wǎng)絡(luò)通信,給你處理掉負(fù)載均衡了、服務(wù)實例上下線自動感知了、超時重試了,等等亂七八糟的問題。那你就不用自己做了,用 dubbo 就可以了。
網(wǎng)頁名稱:為什么要系統(tǒng)拆分?如何系統(tǒng)拆分?拆分后不用 dubbo 可以嗎?
本文鏈接:http://jinyejixie.com/news/100112.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站設(shè)計公司、網(wǎng)站策劃、域名注冊、品牌網(wǎng)站制作、企業(yè)網(wǎng)站制作、小程序開發(fā)
聲明:本網(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)
猜你還喜歡下面的內(nèi)容