為什麼要把系統拆分成分散式的，為啥要用Dubbo？

1、面試題

為什麼要進行系統拆分?如何進行系統拆分?拆分後不用 dubbo 可以嗎?

2、面試官心裡分析

從這個問題開始就進行分散式系統環節了，好多同學給我反饋說，現在出去分散式成標配了，沒有哪個公司不問問你分散式的事兒。

你要是不會分散式的東西，簡直這簡歷沒法看，沒人會讓你去面試。

其實為啥會這樣呢?

這就是因為整個大行業技術發展的原因。

早些年，我印象中在 2010 年初的時候，整個 IT 行業，很少有人談分散式，更不用說微服務。

雖然很多 BAT 等大型公司，因為系統的複雜性，很早就是分散式架構，大量的服務，只不過微服務大多基於自己搞的一套框架來實現而已。

但是確實，那個年代，大家很重視 ssh2，很多中小型公司幾乎大部分都是玩兒 struts2、spring、hibernate，稍晚一些，才進入了 spring mvc、spring、mybatis 的組合。

那個時候整個行業的技術水平就是那樣，當年 oracle 很火，oracle 管理員很吃香，oracle 性能優化啥的都是 IT 男的大殺招啊。

連大數據都沒人提，當年 OCP、OCM 等認證培訓機構，火的不行。

但是確實隨著時代的發展，慢慢的，很多公司開始接受分散式系統架構了，這裡面尤為對行業有至關重要影響的，是阿里的 dubbo，某種程度上而言，阿里在這裡推動了行業技術的前進。

正是因為有阿里的 dubbo，很多中小型公司才可以基於 dubbo，來把系統拆分成很多的服務，每個人負責一個服務，大家的代碼都沒有衝突，服務可以自治，自己選用什麼技術都可以。

每次發布如果就改動一個服務那就上線一個服務好了，不用所有人一起聯調，每次發布都是幾十萬行代碼，甚至幾百萬行代碼了。

直到今日，我很高興的看到分散式系統都成行業面試標配了，任何一個普通的程序員都該掌握這個東西，其實這是行業的進步，也是所有 IT 碼農的技術進步。

所以既然分散式都成標配了，那麼面試官當然會問了，因為很多公司現在都是分散式、微服務的架構，那面試官當然得考察考察你了。

3、友情提示

如果有個同學看到這裡說，我天，我不知道啥是分散式系統?我也不知道啥是 dubbo?

那你趕緊百度啊，搜個 dubbo 入門，去裡面體驗一下。

分散式系統，我用一句話給你解釋一下，就是原來 20 萬行代碼的系統，現在拆分成 20 個小系統，每個小系統 1 萬行代碼。

原本代碼之間直接就是基於 spring 調用，現在拆分開來了，20 個小系統部署在不同的機器上，得基於 dubbo 搞一個 rpc 調用，介面與介面之間通過網路通信來請求和響應。

就這個意思。

4、面試題剖析

(1)為什麼要將系統進行拆分?

網上查查，答案極度零散和複雜，很瑣碎，原因一大坨。但是我這裡給大家直觀的感受：

1)要是不拆分，一個大系統幾十萬行代碼，20 個人維護一份代碼，簡直是悲劇啊。

代碼經常改著改著就衝突了，各種代碼衝突和合併要處理，非常耗費時間;

經常我改動了我的代碼，你調用了我，導致你的代碼也得重新測試，麻煩的要死;

然後每次發布都是幾十萬行代碼的系統一起發布，大家得一起提心弔膽準備上線，幾十萬行代碼的上線，可能每次上線都要做很多的檢查，很多異常問題的處理，簡直是又麻煩又痛苦;

而且如果我現在打算把技術升級到最新的 spring 版本，還不行，因為這可能導致你的代碼報錯，我不敢隨意亂改技術。

假設一個系統是 20 萬行代碼，其中小 A 在裡面改了 1000 行代碼，但是此時發布的時候是這個 20 萬行代碼的大系統一塊兒發布。

就意味著 20 萬上代碼在線上就可能出現各種變化，20 個人，每個人都要緊張地等在電腦面前，上線之後，檢查日誌，看自己負責的那一塊兒有沒有什麼問題。

小 A 就檢查了自己負責的 1 萬行代碼對應的功能，確保 ok 就閃人了;

結果不巧的是，小 A 上線的時候不小心修改了線上機器的某個配置，導致另外小 B 和小 C 負責的 2 萬行代碼對應的一些功能，出錯了。

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

最近從 2013 年到現在，5 年的時間裡，2013 年以前，基本上都是BAT的天下;

2013 年開始，有幾個小巨頭開始快速的發展，上市，幾百億美金，估值都幾百億美金;

2015 年，出現了除了 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 就可以了。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！