單體應用到分布式系統演變過程

1、單應用架構

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

?

?

2、應用服務器集群

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

?

?

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

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

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

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

?

?

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

?

3、數據庫讀寫分離

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

?

?

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

?

主庫如何及時將數據同步到讀庫

應用服務器如何知道要調用哪個數據源

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

?

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

4、緩存技術引入

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

?

5、應用拆分

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

?

?

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

6、數據庫垂直拆分

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

?

7、數據庫水平拆分

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

?

?

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

?

?

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

?

最后：

?

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。