面試官們「愛不釋手」的分佈式系統架構究竟是個什麼鬼？

目錄：

1、什麼是分佈式系統？       

2、爲何要走分佈式系統架構？

3、系統如何進行拆分？

4、分佈式以後帶來的技術挑戰？

 

1、什麼是分佈式系統？

 

在談分佈式系統架構前，咱們先來看看，什麼是分佈式系統？

假設原來咱們有一個系統，代碼量30多萬行。如今拆分紅20個小系統，每一個小系統1萬多行代碼。

本來代碼之間都是直接基於Spring框架走JVM內存調用，如今拆開來，將20個小系統部署在不一樣的機器上，而後基於分佈式服務框架（好比dubbo）搞一個rpc調用，接口與接口之間經過網絡通訊來進行請求和響應。

 

因此分佈式系統很重要的特色就是服務間要跨網絡進行調用，咱們來看下面的圖：

 

此外，分佈式系統能夠大概能夠分紅兩類。

 

1. 底層的分佈式系統。

好比hadoop hdfs（分佈式存儲系統）、spark（分佈式計算系統）、storm（分佈式流式計算系統）、elasticsearch（分佈式搜索系統）、kafka（分佈式發佈訂閱消息系統）等。

 

2. 分佈式業務系統

分佈式業務系統，把原來用java開發的一個大塊系統，給拆分紅多個子系統，多個子系統之間互相調用，造成一個大系統的總體。

 

舉個例子，假設原來你作了一個OA系統，裏面包含了權限模塊、員工模塊、請假模塊、財務模塊，一個工程，裏面包含了一堆模塊，模塊與模塊之間會互相去調用，1臺機器部署。

如今若是你把他這個系統給拆開，權限系統，員工系統，請假系統，財務系統，4個系統，4個工程，分別在4臺機器上部署。

而後一個請求過來，完成這個請求，員工系統去調用權限系統，調用請假系統，調用財務系統，4個系統分別完成了一部分的事情。

 

最後4個系統都幹完了之後，才認爲是這個請求已經完成了。這就是所謂的分佈式業務系統。

 

一樣，咱們來一張圖，感覺一下上述過程：

 

 

2、爲何要走分佈式系統架構？

 

有的同窗可能要問了，我一臺服務器跑的好好的，全部系統一個工程所有搞定，多好。爲啥必定要去搞什麼分佈式系統架構，互相調用還要走遠程，彷佛還增長了很多工做量？

這裏我就以我曾經待過的一個公司的血淚經歷爲例，來聊聊這個問題。

不少年前，在沒有走分佈式架構的時候，我待的這家公司的各個業務線都是垂直的 「煙囪式」 項目。

隨着互聯網的快速發展，公司的業務也在不斷的發展，註冊用戶增長、網站應用的功能、規模不斷擴大，特別是移動互聯網的發展，APP、微信、自助終端機等訪問渠道的增長，各類新業務，新需求不斷涌入，系統遇到了各類各樣的問題。

首先是項目工程無節制的變得臃腫龐大，系統複雜度增長，大幾十萬行代碼，幾十個開發人員，service層，dao層代碼大量被copy使用，常常各類代碼合併衝突問題要處理，很是耗費時間。

常常是我改動了個人代碼，別人調用了個人接口，致使他的代碼也出現問題，須要從新測試，麻煩的要死。

而後每次發佈都是幾十萬行代碼的系統一塊兒發佈，你們得一塊兒提心吊膽準備上線，幾十萬行代碼的上線，每次上線都要作不少的檢查，不少異常問題的處理，每一個人都高度緊張，被搞得幾乎崩潰。

並且若是我如今有個新業務，打算把相關依賴升級一下，好比升級到最新的spring版本，還不行，由於這可能致使別人的代碼報錯，不敢隨意亂改技術。而且一個web工程每次啓動都須要好分鐘的時間，本地IDE裏面調試一次代碼都很痛苦。

其次，隨着用戶訪問流量的增長，系統負載壓力變大，變得不堪重負，經過增長實例數，增長硬件擴容可以帶來的效果已微乎其微，故障頻發，效率低下。系統質量也愈來愈難以保證，測試周期也變得愈來愈長，沒法知足公司業務發展的須要。

以上就是之前待過的公司一些 「不堪回首」 的往事，總得來講，問題主要體如今如下幾個方面：

1. 應用代碼耦合嚴重，功能擴展難
2. 新需求開發交互週期長，測試工做量大
3. 新加入的開發同事須要很長時間才能熟悉系統
4. 升級維護也很困難（改動任何一點地方都要升級整個系統）
5. 系統性能提高艱難，可用性低，不穩定。

 

好，既然咱們已經深入體會到了系統耦合的痛苦，那麼如今就來看看，系統拆分後帶來的好處：

首先，系統拆分了之後，會感受整個世界都清爽了。

 

幾十萬行代碼的系統，假設拆分紅20個服務，平均每一個服務就1-3萬行代碼，每一個服務部署到單獨的機器上。20個工程，就用20個git倉庫代碼，20個開發人員，每一個人維護本身的那個服務就能夠了。

 

• 由於是本身獨立的代碼，跟別人不要緊。再也沒有代碼衝突了，爽！
• 每次就測試我本身的代碼就能夠了，爽！
• 每次就發佈我本身的一個小服務就能夠了，爽！
• 技術上想怎麼升級就怎麼升級，保持接口定義不變，輸入輸出內容不變就能夠了，爽！

 

總結起來一句話，分佈式系統拆分以後，能夠大幅度提高複雜系統大型團隊的開發效率。

 

3、系統如何進行拆分？

 

通常來講，將系統進行拆分，首先須要對系統總體比較熟悉。能夠走多輪拆分的思路，第一次拆分就是將之前的各個大的模塊粗粒度的拆分開來。

 

好比一個電商系統能夠拆分紅訂單系統、商品系統、店鋪系統、會員系統、促銷系統、支付系統等等。

後面可能每一個系統又變得愈來愈複雜了，好比說訂單系統又能夠進一步拆分出來購物車系統，庫存系統，價格系統等。

總得來講就是基於領域驅動設計的思想以及實戰經驗總結，同時參考業界一些常規作法，你們討論着來進行拆分，逐步優化，多輪拆分，小步快跑，最終達到一個比較好的狀態。

4、分佈式以後帶來的技術挑戰？

 

首先就是分佈式服務框架的選用，目前國內來說主流的仍是dubbo與spring cloud。

咱們來思考一下，使用服務框架主要用來解決什麼問題呢？若是不用dubbo或者spring cloud是否能夠作分佈式架構呢？

不用dubbo或者spring cloud等服務框架固然也是能夠的，可是這就須要本身處理不少事情了。

 

好比，各個子系統走restful接口調用，那麼就是http調用，這時好比傳送過去一個對象，就要本身搞成一個json，而後一次調用失敗後重試怎麼作？

另外，通常來講都是集羣部署，目標系統有多個實例，那麼本身還要寫一個負載均衡算法，如何每次隨機從多個目標機器中挑選一個來調用？

 

還有，若是目標系統擴容新部署了一個實例，或者服務器故障下線了一個實例，如何動態讓調用方感知到呢？ 諸如此類的不少問題，若是不用服務框架的話，本身這麼瞎搞，會遇到各類各樣的問題。

上述過程，用一張圖給你們呈現一下：

 

 

若是選用了某一個分佈式服務框架，就須要深刻的掌握這個框架的使用與底層原理，好比 dubbo 就須要搞明白如下的一些問題：

1. dubbo的工做原理？
2. dubbo支持的序列化協議？
3. dubbo的負載均衡和高可用策略？動態代理策略？
5. dubbo的SPI思想？
7. 如何基於dubbo進行服務治理、服務降級、失敗重試以及超時重試？
9. dubbo服務接口的冪等性如何設計（好比不能重複扣款，不能重複生成訂單，不能重複建立卡號）？
11. dubbo服務接口請求的順序性如何保證？
13. 如何本身設計一個相似dubbo的rpc框架？

 

使用spring cloud也是同樣，好比eureka的工做原理？feign聲明式調用的原理？等等各類底層原理要搞懂。

 

還有其它一些走分佈式架構後常見的要解決的技術問題：

 

1. 分佈式會話
3. 分佈式鎖
5. 分佈式事務
7. 分佈式搜索
9. 分佈式緩存
11. 分佈式消息隊列
13. 統一配置中心
15. 分佈式存儲，數據庫分庫分表
17. 限流、熔斷、降級等。

 

以上這些問題，往深了說，每個點都須要可能 N 篇文章來詳細闡述，這裏無法逐一展開，後面咱們會繼續經過一些文章，聊一聊這些分佈式架構下的各類技術問題。