單體應用到分布式系統(tǒng)演變過程

1、單應用架構(gòu)

早期的系統(tǒng)大部分都是單應用架構(gòu)，所有的模塊集成在一個應用里面，只需要一臺應用服務器和一臺數(shù)據(jù)庫服務器，隨著訪問量的增加，服務器負載的慢慢提高，解決性能瓶頸的方案是不斷提高服務器的配置。

?

?

2、應用服務器集群

隨著訪問量的繼續(xù)增加，單臺應用服務器已經(jīng)無法滿足需求，假設我們的數(shù)據(jù)庫服務器還沒遇到性能問題，我們可以通過增加應用服務器的方式來將應用服務器集群化，這樣用戶可以分流到各個應用服務器中，從而達到提升系統(tǒng)負載能力的目的。

?

?

但是應用服務器集群會帶來的問題：

用戶請求如何分流到各個應用服務器？

用戶如果的兩次請求被分配到不同的服務器，如果做到session共享？

為了解決第1個問題，需要在用戶請求和應用服務器中間增加負載均衡，負載均衡分硬負載和軟負載，硬負載可以選擇F5等，軟負載可以選擇nginx、Apache等，增加了負載均衡后系統(tǒng)架構(gòu)便變成下面這樣。

?

?

而第2個關(guān)于session共享問題，我們可以通過配置tomcat的session共享或者緩存服務器來實現(xiàn)。

?

3、數(shù)據(jù)庫讀寫分離

應用服務器集群提升了應用層的負載能力，但是數(shù)據(jù)庫的負載能力并沒有得到提升，那如何去提高數(shù)據(jù)庫的負載能力呢？是不是也能參照應用服務器集群的方式，通過增加數(shù)據(jù)庫服務器來實現(xiàn)呢？數(shù)據(jù)庫讀寫分離被提了出來：

?

?

同樣讀寫分離也會帶來新的問題：

?

主庫如何及時將數(shù)據(jù)同步到讀庫

應用服務器如何知道要調(diào)用哪個數(shù)據(jù)源

針對第1個問題，各數(shù)據(jù)庫都提供了主從復制的解決方案，如mysql自帶master-slave方式實現(xiàn)主從復制。

?

針對第2個問題，可以使用多數(shù)據(jù)源或者引入第三方數(shù)據(jù)庫中間件，例如mycat。

4、緩存技術(shù)引入

隨著訪問量的持續(xù)增加，會出現(xiàn)許多用戶訪問統(tǒng)一內(nèi)容的情況，對于這些數(shù)據(jù)，沒必要每次都去數(shù)據(jù)庫獲取，這個時候引入應用層的緩存技術(shù)是個很好的選擇，例如redis、memcache等。

?

5、應用拆分

隨著業(yè)務的繼續(xù)發(fā)展，應用的壓力再次增大，同時不斷增加的模塊使系統(tǒng)變得越來越臃腫，維護工作量也越來越大。這個時候就可以考慮將應用系統(tǒng)進行拆分，按照領(lǐng)域模型拆分成多個子系統(tǒng)。

?

?

應用拆分后會帶來新的問題，如子系統(tǒng)一中的一個查詢在子系統(tǒng)二中也需要查詢，是不是這些查詢在兩個子系統(tǒng)中都分別寫一套呢？當然是不行的，一定要把這些抽象出來做成一個服務，這樣又生成一個新的問題，多個子系統(tǒng)之間怎么相互訪問呢？為了解決這個問題，RPC技術(shù)是個很好的選擇，比較典型的有：dubbo、webservice、hessian、http、rmi等。

6、數(shù)據(jù)庫垂直拆分

同樣的，應用層面性能瓶頸解決后，又輪到數(shù)據(jù)庫了，我們能將應用按照領(lǐng)域模型拆分成一個個應用子系統(tǒng)，數(shù)據(jù)庫也是一樣，根據(jù)不同的業(yè)務拆分成不用的數(shù)據(jù)庫。拆分后數(shù)據(jù)庫可以和拆分后的應用一一對應。

?

7、數(shù)據(jù)庫水平拆分

數(shù)據(jù)庫進行讀寫分離、垂直拆分后基本上解決了負載的問題，但是隨著業(yè)務量的增加，表的數(shù)據(jù)不斷增長，數(shù)據(jù)查詢性能便成了問題，所以必須要多數(shù)據(jù)庫進行水平拆分。水平拆分是將單個表的數(shù)據(jù)拆分到多個數(shù)據(jù)庫中，如1億數(shù)據(jù)的表拆分到10個數(shù)據(jù)庫后，每個表就只有1000w了。

?

?

數(shù)據(jù)庫水平拆分后，數(shù)據(jù)源就變得非常復雜了，讓業(yè)務系統(tǒng)去控制查詢哪個數(shù)據(jù)源變得不現(xiàn)實，這個時候需要引入第三方的數(shù)據(jù)庫中間件，例如mycat、阿里的drds等。

?

?

最后演變出來的便是上圖這個相對比較全的分布式架構(gòu)了，但并不是說最后這個分布式架構(gòu)一定是最優(yōu)解決方案，具體選擇哪個架構(gòu)還是要結(jié)合業(yè)務系統(tǒng)的業(yè)務需求和業(yè)務量來分析。

?

最后：

?

總結(jié)

以上是生活随笔為你收集整理的SpringCloud 01_单体应用到分布式系统演变过程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。