一、什么是分布式系統(tǒng)?
在談分布式系統(tǒng)架構(gòu)前，我們先來看看，什么是分布式系統(tǒng)?
假設(shè)原來我們有一個系統(tǒng)，代碼量30多萬行?，F(xiàn)在拆分成20個小系統(tǒng)，每個小系統(tǒng)1萬多行代碼。
原本代碼之間都是直接基于Spring框架走JVM內(nèi)存調(diào)用，現(xiàn)在拆開來，將20個小系統(tǒng)部署在不同的機器上，然后基于分布式服務(wù)框架(比如dubbo)搞一個rpc調(diào)用，接口與接口之間通過網(wǎng)絡(luò)通信來進行請求和響應(yīng)。
所以分布式系統(tǒng)很重要的特點就是服務(wù)間要跨網(wǎng)絡(luò)進行調(diào)用，我們來看下面的圖：
此外，分布式系統(tǒng)可以大概可以分成兩類。
- 底層的分布式系統(tǒng)。
比如hadoop hdfs(分布式存儲系統(tǒng))、spark(分布式計算系統(tǒng))、storm(分布式流式計算系統(tǒng))、elasticsearch(分布式搜索系統(tǒng))、kafka(分布式發(fā)布訂閱消息系統(tǒng))等。
- 分布式業(yè)務(wù)系統(tǒng)
分布式業(yè)務(wù)系統(tǒng)，把原來用java開發(fā)的一個大塊系統(tǒng)，給拆分成多個子系統(tǒng)，多個子系統(tǒng)之間互相調(diào)用，形成一個大系統(tǒng)的整體。
舉個例子，假設(shè)原來你做了一個OA系統(tǒng)，里面包含了權(quán)限模塊、員工模塊、請假模塊、財務(wù)模塊，一個工程，里面包含了一堆模塊，模塊與模塊之間會互相去調(diào)用，1臺機器部署。
現(xiàn)在如果你把他這個系統(tǒng)給拆開，權(quán)限系統(tǒng)，員工系統(tǒng)，請假系統(tǒng)，財務(wù)系統(tǒng)，4個系統(tǒng)，4個工程，分別在4臺機器上部署。
然后一個請求過來，完成這個請求，員工系統(tǒng)去調(diào)用權(quán)限系統(tǒng)，調(diào)用請假系統(tǒng)，調(diào)用財務(wù)系統(tǒng)，4個系統(tǒng)分別完成了一部分的事情。
最后4個系統(tǒng)都干完了以后，才認為是這個請求已經(jīng)完成了。這就是所謂的分布式業(yè)務(wù)系統(tǒng)。
同樣，我們來一張圖，感受一下上述過程：
二、為什么要走分布式系統(tǒng)架構(gòu)?
有的同學(xué)可能要問了，我一臺服務(wù)器跑的好好的，所有系統(tǒng)一個工程全部搞定，多好。為啥一定要去搞什么分布式系統(tǒng)架構(gòu)，互相調(diào)用還要走遠程，似乎還增加了不少工作量?
這里我就以我曾經(jīng)待過的一個公司的血淚經(jīng)歷為例，來聊聊這個問題。
很多年前，在沒有走分布式架構(gòu)的時候，我待的這家公司的各個業(yè)務(wù)線都是垂直的 “煙囪式” 項目。
隨著互聯(lián)網(wǎng)的快速發(fā)展，公司的業(yè)務(wù)也在不斷的發(fā)展，注冊用戶增加、網(wǎng)站應(yīng)用的功能、規(guī)模不斷擴大，特別是移動互聯(lián)網(wǎng)的發(fā)展，APP、微信、自助終端機等訪問渠道的增加，各種新業(yè)務(wù)，新需求不斷涌入，系統(tǒng)遇到了各種各樣的問題。
首先是項目工程無節(jié)制的變得臃腫龐大，系統(tǒng)復(fù)雜度增加，大幾十萬行代碼，幾十個開發(fā)人員，service層，dao層代碼大量被copy使用，經(jīng)常各種代碼合并沖突問題要處理，非常耗費時間。
經(jīng)常是我改動了我的代碼，別人調(diào)用了我的接口，導(dǎo)致他的代碼也出現(xiàn)問題，需要重新測試，麻煩的要死。
然后每次發(fā)布都是幾十萬行代碼的系統(tǒng)一起發(fā)布，大家得一起提心吊膽準備上線，幾十萬行代碼的上線，每次上線都要做很多的檢查，很多異常問題的處理，每個人都高度緊張，被搞得幾乎崩潰。
而且如果我現(xiàn)在有個新業(yè)務(wù)，打算把相關(guān)依賴升級一下，比如升級到最新的spring版本，還不行，因為這可能導(dǎo)致別人的代碼報錯，不敢隨意亂改技術(shù)。并且一個web工程每次啟動都需要好分鐘的時間，本地IDE里面調(diào)試一次代碼都很痛苦。
其次，隨著用戶訪問流量的增加，系統(tǒng)負載壓力變大，變得不堪重負，通過增加實例數(shù)，增加硬件擴容能夠帶來的效果已微乎其微，故障頻發(fā)，效率低下。系統(tǒng)質(zhì)量也越來越難以保證，測試周期也變得越來越長，無法滿足公司業(yè)務(wù)發(fā)展的需要。
以上就是以前待過的公司一些 “不堪回首” 的往事，總得來說，問題主要體現(xiàn)在以下幾個方面：
- 應(yīng)用代碼耦合嚴重，功能擴展難
- 新需求開發(fā)交互周期長，測試工作量大
- 新加入的開發(fā)同事需要很長時間才能熟悉系統(tǒng)
- 升級維護也很困難(改動任何一點地方都要升級整個系統(tǒng))
- 系統(tǒng)性能提升艱難，可用性低，不穩(wěn)定。
好，既然我們已經(jīng)深刻體會到了系統(tǒng)耦合的痛苦，那么現(xiàn)在就來看看，系統(tǒng)拆分后帶來的好處：
首先，系統(tǒng)拆分了以后，會感覺整個世界都清爽了。
幾十萬行代碼的系統(tǒng)，假設(shè)拆分成20個服務(wù)，平均每個服務(wù)就1-3萬行代碼，每個服務(wù)部署到單獨的機器上。20個工程，就用20個git倉庫代碼，20個開發(fā)人員，每個人維護自己的那個服務(wù)就可以了。
- 因為是自己獨立的代碼，跟別人沒關(guān)系。再也沒有代碼沖突了，爽!
- 每次就測試我自己的代碼就可以了，爽!
- 每次就發(fā)布我自己的一個小服務(wù)就可以了，爽!
- 技術(shù)上想怎么升級就怎么升級，保持接口定義不變，輸入輸出內(nèi)容不變就可以了，爽!
總結(jié)起來一句話，分布式系統(tǒng)拆分之后，可以大幅度提升復(fù)雜系統(tǒng)大型團隊的開發(fā)效率。
三、系統(tǒng)如何進行拆分?
一般來說，將系統(tǒng)進行拆分，首先需要對系統(tǒng)整體比較熟悉?？梢宰叨噍啿鸱值乃悸罚谝淮尾鸱志褪菍⒁郧暗母鱾€大的模塊粗粒度的拆分開來。
比如一個電商系統(tǒng)可以拆分成訂單系統(tǒng)、商品系統(tǒng)、店鋪系統(tǒng)、會員系統(tǒng)、促銷系統(tǒng)、支付系統(tǒng)等等。
后面可能每個系統(tǒng)又變得越來越復(fù)雜了，比如說訂單系統(tǒng)又可以進一步拆分出來購物車系統(tǒng)，庫存系統(tǒng)，價格系統(tǒng)等。
總得來說就是基于領(lǐng)域驅(qū)動設(shè)計的思想以及實戰(zhàn)經(jīng)驗總結(jié)，同時參考業(yè)界一些常規(guī)做法，大家討論著來進行拆分，逐步優(yōu)化，多輪拆分，小步快跑，最終達到一個比較好的狀態(tài)。
四、分布式之后帶來的技術(shù)挑戰(zhàn)?
首先就是分布式服務(wù)框架的選用，目前國內(nèi)來講主流的還是dubbo與spring cloud。
我們來思考一下，使用服務(wù)框架主要用來解決什么問題呢?如果不用dubbo或者spring cloud是否可以做分布式架構(gòu)呢?
不用dubbo或者spring cloud等服務(wù)框架當(dāng)然也是可以的，但是這就需要自己處理很多事情了。
比如，各個子系統(tǒng)走restful接口調(diào)用，那么就是http調(diào)用，這時比如傳送過去一個對象，就要自己搞成一個json，然后一次調(diào)用失敗后重試怎么做?
另外，一般來說都是集群部署，目標系統(tǒng)有多個實例，那么自己還要寫一個負載均衡算法，如何每次隨機從多個目標機器中挑選一個來調(diào)用?
還有，如果目標系統(tǒng)擴容新部署了一個實例，或者服務(wù)器故障下線了一個實例，如何動態(tài)讓調(diào)用方感知到呢? 諸如此類的很多問題，如果不用服務(wù)框架的話，自己這么瞎搞，會遇到各種各樣的問題。
上述過程，用一張圖給大家呈現(xiàn)一下：
如果選用了某一個分布式服務(wù)框架，就需要深入的掌握這個框架的使用與底層原理，比如 dubbo 就需要搞明白以下的一些問題：
dubbo的工作原理?
dubbo支持的序列化協(xié)議?
dubbo的負載均衡和高可用策略?動態(tài)代理策略?
dubbo的SPI思想?
如何基于dubbo進行服務(wù)治理、服務(wù)降級、失敗重試以及超時重試?
dubbo服務(wù)接口的冪等性如何設(shè)計(比如不能重復(fù)扣款，不能重復(fù)生成訂單，不能重復(fù)創(chuàng)建卡號)?
dubbo服務(wù)接口請求的順序性如何保證?
如何自己設(shè)計一個類似dubbo的rpc框架?
使用spring cloud也是一樣，比如eureka的工作原理?feign聲明式調(diào)用的原理?等等各種底層原理要搞懂。
還有其它一些走分布式架構(gòu)后常見的要解決的技術(shù)問題：
- 分布式會話
- 分布式鎖
- 分布式事務(wù)
- 分布式搜索
- 分布式緩存
- 分布式消息隊列
- 統(tǒng)一配置中心
- 分布式存儲，數(shù)據(jù)庫分庫分表
- 限流、熔斷、降級等。
以上這些問題，往深了說，每一個點都需要可能N篇文章來詳細闡述，這里沒法逐一展開，后面我們會繼續(xù)通過一些文章，聊一聊這些分布式架構(gòu)下的各種技術(shù)問題。
