2021-02-10 分類: 網(wǎng)站建設(shè)
面試題
為什么要進(jìn)行系統(tǒng)拆分?如何進(jìn)行系統(tǒng)拆分?拆分后不用 dubbo 可以嗎?
面試官心理分析
從這個(gè)問(wèn)題開始就進(jìn)行分布式系統(tǒng)環(huán)節(jié)了,現(xiàn)在出去面試分布式都成標(biāo)配了,沒(méi)有哪個(gè)公司不問(wèn)問(wèn)你分布式的事兒。你要是不會(huì)分布式的東西,簡(jiǎn)直這簡(jiǎn)歷沒(méi)法看,沒(méi)人會(huì)讓你去面試。
其實(shí)為啥會(huì)這樣呢?這就是因?yàn)檎麄€(gè)大行業(yè)技術(shù)發(fā)展的原因。
早些年,印象中在 2010 年初的時(shí)候,整個(gè) IT 行業(yè),很少有人談分布式,更不用說(shuō)微服務(wù),雖然很多 BAT 等大型公司,因?yàn)橄到y(tǒng)的復(fù)雜性,很早就是分布式架構(gòu),大量的服務(wù),只不過(guò)微服務(wù)大多基于自己搞的一套框架來(lái)實(shí)現(xiàn)而已。
但是確實(shí),那個(gè)年代,大家很重視 ssh2,很多中小型公司幾乎大部分都是玩兒 struts2、spring、hibernate,稍晚一些,才進(jìn)入了spring mvc、spring、mybatis 的組合。那個(gè)時(shí)候整個(gè)行業(yè)的技術(shù)水平就是那樣,當(dāng)年 oracle 很火,oracle 管理員很吃香,oracle 性能優(yōu)化啥的都是 IT 男的大殺招啊。連大數(shù)據(jù)都沒(méi)人提,當(dāng)年 OCP、OCM 等認(rèn)證培訓(xùn)機(jī)構(gòu),火的不行。
但是確實(shí)隨著時(shí)代的發(fā)展,慢慢的,很多公司開始接受分布式系統(tǒng)架構(gòu)了,這里面尤為對(duì)行業(yè)有至關(guān)重要影響的,是阿里的 dubbo,某種程度上而言,阿里在這里推動(dòng)了行業(yè)技術(shù)的前進(jìn)。
正是因?yàn)橛邪⒗锏?dubbo,很多中小型公司才可以基于 dubbo,來(lái)把系統(tǒng)拆分成很多的服務(wù),每個(gè)人負(fù)責(zé)一個(gè)服務(wù),大家的代碼都沒(méi)有沖突,服務(wù)可以自治,自己選用什么技術(shù)都可以,每次發(fā)布如果就改動(dòng)一個(gè)服務(wù)那就上線一個(gè)服務(wù)好了,不用所有人一起聯(lián)調(diào),每次發(fā)布都是幾十萬(wàn)行代碼,甚至幾百萬(wàn)行代碼了。
直到今日,很高興看到分布式系統(tǒng)都成行業(yè)面試標(biāo)配了,任何一個(gè)普通的程序員都該掌握這個(gè)東西,其實(shí)這是行業(yè)的進(jìn)步,也是所有 IT 碼農(nóng)的技術(shù)進(jìn)步。所以既然分布式都成標(biāo)配了,那么面試官當(dāng)然會(huì)問(wèn)了,因?yàn)楹芏喙粳F(xiàn)在都是分布式、微服務(wù)的架構(gòu),那面試官當(dāng)然得考察考察你了。
如何進(jìn)行系統(tǒng)拆分?
這個(gè)問(wèn)題說(shuō)大可以很大,可以扯到領(lǐng)域驅(qū)動(dòng)模型設(shè)計(jì)上去,說(shuō)小了也很小,我不太想給大家太過(guò)于學(xué)術(shù)的說(shuō)法,因?yàn)槟阋膊豢赡鼙尺@個(gè)答案,過(guò)去了直接說(shuō)吧。還是說(shuō)的簡(jiǎn)單一點(diǎn),大家自己到時(shí)候知道怎么回答就行了。
系統(tǒng)拆分為分布式系統(tǒng),拆成多個(gè)服務(wù),拆成微服務(wù)的架構(gòu),是需要拆很多輪的。并不是說(shuō)上來(lái)一個(gè)架構(gòu)師一次就給拆好了,而以后都不用拆。
第一輪;團(tuán)隊(duì)繼續(xù)擴(kuò)大,拆好的某個(gè)服務(wù),剛開始是 1 個(gè)人維護(hù) 1 萬(wàn)行代碼,后來(lái)業(yè)務(wù)系統(tǒng)越來(lái)越復(fù)雜,這個(gè)服務(wù)是 10 萬(wàn)行代碼,5 個(gè)人;第二輪,1個(gè)服務(wù) -> 5個(gè)服務(wù),每個(gè)服務(wù) 2 萬(wàn)行代碼,每人負(fù)責(zé)一個(gè)服務(wù)。
如果是多人維護(hù)一個(gè)服務(wù),最理想的情況下,幾十個(gè)人,1 個(gè)人負(fù)責(zé) 1 個(gè)或 2~3 個(gè)服務(wù);某個(gè)服務(wù)工作量變大了,代碼量越來(lái)越多,某個(gè)同學(xué),負(fù)責(zé)一個(gè)服務(wù),代碼量變成了 10 萬(wàn)行了,他自己不堪重負(fù),他現(xiàn)在一個(gè)人拆開,5 個(gè)服務(wù),1 個(gè)人頂著,負(fù)責(zé) 5 個(gè)人,接著招人,2 個(gè)人,給那個(gè)同學(xué)帶著,3 個(gè)人負(fù)責(zé) 5 個(gè)服務(wù),其中 2 個(gè)人每個(gè)人負(fù)責(zé) 2 個(gè)服務(wù),1 個(gè)人負(fù)責(zé) 1 個(gè)服務(wù)。
個(gè)人建議,一個(gè)服務(wù)的代碼不要太多,1萬(wàn)行左右,兩三萬(wàn)撐死了吧。
大部分的系統(tǒng),是要進(jìn)行多輪拆分的,第一次拆分,可能就是將以前的多個(gè)模塊該拆分開來(lái)了,比如說(shuō)將電商系統(tǒng)拆分成訂單系統(tǒng)、商品系統(tǒng)、采購(gòu)系統(tǒng)、倉(cāng)儲(chǔ)系統(tǒng)、用戶系統(tǒng),等等吧。
但是后面可能每個(gè)系統(tǒng)又變得越來(lái)越復(fù)雜了,比如說(shuō)采購(gòu)系統(tǒng)里面又分成了供應(yīng)商管理系統(tǒng)、采購(gòu)單管理系統(tǒng),訂單系統(tǒng)又拆分成了購(gòu)物車系統(tǒng)、價(jià)格系統(tǒng)、訂單管理系統(tǒng)。
扯深了實(shí)在很深,所以這里先給大家舉個(gè)例子,你自己感受一下,核心意思就是根據(jù)情況,先拆分一輪,后面如果系統(tǒng)更復(fù)雜了,可以繼續(xù)分拆。你根據(jù)自己負(fù)責(zé)系統(tǒng)的例子,來(lái)考慮一下就好了。
拆分后不用 dubbo 可以嗎?
當(dāng)然可以了,大不了最次,就是各個(gè)系統(tǒng)之間,直接基于 spring mvc,就純 http 接口互相通信唄,還能咋樣。但是這個(gè)肯定是有問(wèn)題的,因?yàn)?http 接口通信維護(hù)起來(lái)成本很高,你要考慮超時(shí)重試、負(fù)載均衡等等各種亂七八糟的問(wèn)題,比如說(shuō)你的訂單系統(tǒng)調(diào)用商品系統(tǒng),商品系統(tǒng)部署了 5 臺(tái)機(jī)器,你怎么把請(qǐng)求均勻地甩給那 5 臺(tái)機(jī)器?這不就是負(fù)載均衡?你要是都自己搞那是可以的,但是確實(shí)很痛苦。
所以 dubbo 說(shuō)白了,是一種 rpc 框架,就是說(shuō)本地就是進(jìn)行接口調(diào)用,但是 dubbo 會(huì)代理這個(gè)調(diào)用請(qǐng)求,跟遠(yuǎn)程機(jī)器網(wǎng)絡(luò)通信,給你處理掉負(fù)載均衡了、服務(wù)實(shí)例上下線自動(dòng)感知了、超時(shí)重試了,等等亂七八糟的問(wèn)題。那你就不用自己做了,用 dubbo 就可以了。
當(dāng)前名稱:為什么要系統(tǒng)拆分?如何系統(tǒng)拆分?拆分后不用 dubbo 可以嗎?
鏈接URL:http://redsoil1982.com.cn/news12/100112.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站設(shè)計(jì)公司、網(wǎng)站維護(hù)、標(biāo)簽優(yōu)化、網(wǎng)站營(yíng)銷、營(yíng)銷型網(wǎng)站建設(shè)、定制網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容