要是不拆分，乙個大系統幾十萬行**，20 個人維護乙份**，簡直是悲劇啊。**經常改著改著就衝突了，各種**衝突和合併要處理，非常耗費時間；經常我改動了我的**，你呼叫了我的，導致你的**也得重新測試，麻煩的要死；然後每次發布都是幾十萬行**的系統一起發布，大家得一起提心吊膽準備上線，幾十萬行**的上線，可能每次上線都要做很多的檢查，很多異常問題的處理，簡直是又麻煩又痛苦；而且如果我現在打算把技術公升級到最新的 spring 版本，還不行，因為這可能導致你的**報錯，我不敢隨意亂改技術。
a 就檢查了自己負責的 1 萬行**對應的功能，確保 ok 就閃人了；結果不巧的是，a 上線的時候不小心修改了線上機器的某個配置，導致另外 b 和 c 負責的 2 萬行**對應的一些功能，出錯了。
幾十個人負責維護乙個幾十萬行**的單塊應用，每次上線，準備幾個禮拜，上線 -> 部署 -> 檢查自己負責的功能。
拆分了以後，整個世界清爽了，幾十萬行**的系統，拆分成 20 個服務，平均每個服務就 1~2 萬行**，每個服務部署到單獨的機器上。20 個工程，20 個 git **倉庫，20 個開發人員，每個人維護自己的那個服務就可以了，是自己獨立的**，跟別人沒關係。再也沒有**衝突了，爽。每次就測試我自己的**就可以了，爽。每次就發布我自己的乙個小服務就可以了，爽。技術上想怎麼公升級就怎麼公升級，保持介面不變就可以了，真爽。
所以簡單來說，一句話總結，如果是那種**量多達幾十萬行的中大型專案，團隊裡有幾十個人，那麼如果不拆分系統，開發效率極其低下，問題很多。但是拆分系統之後，每個人就負責自己的一小部分就好了，可以隨便玩兒隨便弄。分布式系統拆分之後，可以大幅度提公升複雜系統大型團隊的開發效率。
但是同時，也要提醒的一點是，系統拆分成分布式系統之後，大量的分布式系統面臨的問題也是接踵而來，所以後面的問題都是在圍繞分布式系統帶來的複雜技術挑戰在說。
這個問題說大可以很大，可以扯到領域驅動模型設計上去，說小了也很小，我不太想給大家太過於學術的說法，因為你也不可能背這個答案，過去了直接說吧。還是說的簡單一點，大家自己到時候知道怎麼回答就行了。
系統拆分為分布式系統，拆成多個服務，拆成微服務的架構，是需要拆很多輪的。並不是說上來乙個架構師一次就給拆好了，而以後都不用拆。
第一輪；團隊繼續擴大，拆好的某個服務，剛開始是 1 個人維護 1 萬行**，後來業務系統越來越複雜，這個服務是 10 萬行**，5 個人；第二輪，1個服務 -> 5個服務，每個服務 2 萬行**，每人負責乙個服務。
如果是多人維護乙個服務，最理想的情況下，幾十個人，1 個人負責 1 個或 2~3 個服務；某個服務工作量變大了，**量越來越多，某個同學，負責乙個服務，**量變成了 10 萬行了，他自己不堪重負，他現在乙個人拆開，5 個服務，1 個人頂著，負責 5 個人，接著招人，2 個人，給那個同學帶著，3 個人負責 5 個服務，其中 2 個人每個人負責 2 個服務，1 個人負責 1 個服務。
個人建議，乙個服務的**不要太多，1 萬行左右，兩三萬撐死了吧。
大部分的系統，是要進行多輪拆分的，第一次拆分，可能就是將以前的多個模組該拆分開來了，比如說將電商系統拆分成訂單系統、商品系統、採購系統、倉儲系統、使用者系統，等等吧。
但是後面可能每個系統又變得越來越複雜了，比如說採購系統裡面又分成了**商管理系統、採購單管理系統，訂單系統又拆分成了購物車系統、**系統、訂單管理系統。
扯深了實在很深，所以這裡先給大家舉個例子，你自己感受一下，核心意思就是根據情況，先拆分一輪，後面如果系統更複雜了，可以繼續分拆。你根據自己負責系統的例子，來考慮一下就好了。
當然可以了，大不了最次，就是各個系統之間，直接基於 spring mvc，就純 http 介面互相通訊唄，還能咋樣。但是這個肯定是有問題的，因為 http 介面通訊維護起來成本很高，你要考慮超時重試、負載均衡等等各種亂七八糟的問題，比如說你的訂單系統呼叫商品系統，商品系統部署了 5 臺機器，你怎麼把請求均勻地甩給那 5 臺機器？這不就是負載均衡？你要是都自己搞那是可以的，但是確實很痛苦。
所以 dubbo 說白了，是一種 rpc 框架，就是說本地就是進行介面呼叫，但是 dubbo 會**這個呼叫請求，跟遠端機器網路通訊，給你處理掉負載均衡、服務例項上下線自動感知、超時重試等等亂七八糟的問題。那你就不用自己做了，用 dubbo 就可以了。
為什麼要進行認知公升級？
我們生活在乙個最好的時代，也生活在乙個最壞的時代。最好，是因為機會無限多。最壞，是因為到處人才擁擠。可是 只要你足夠好，上天就眷顧你。而我們作為乙個個體，想要獲得上天的垂憐，除了選擇去撞概率買彩票一夜暴富之外，唯一的方式有且只有一條 通過不斷成長，變得足夠好。一兩年前，我追女孩子琢磨出乙個真理，與某...
為什麼要進行介面測試？
1，什麼是介面？可以簡單理解成用來連線而開放的入口，比如前端和後端的連續需要用介面，移動端和後台的鏈結也需要用到介面。連線前端後端和移動端。2，介面都有哪些型別？介面一般分為兩種 1 程式內部的介面 2 系統對外的介面 系統對外的介面 比如你要從別的 或伺服器上獲取資源或資訊，別人肯定不會把資料庫共...
為什麼要進行版本控制
上圖是乙個cad設計師的施工 件夾，他需要修改原來的施工圖，但是他又不想把修改前的檔案狀態和內容給破壞掉，因為如果直接修改，萬一修改的有問題，或者後悔修改了，如果以前的檔案狀態還在的話，大不了把修改糟糕了的刪除了就是了，所以他其實就用到了最簡單的版本控制方法，那就是複製重新命名 具體寫程式的過程也是...