1. 程式人生 > >分散式架構——分散式架構的演進過程(下)

分散式架構——分散式架構的演進過程(下)

上一篇部落格簡單介紹了分散式的發展歷史和基本概念

本篇部落格則將以電商系統為例,詳細介紹分散式發展的過程 

假設我們的電商系統中只有三個模組:使用者模組,交易模組和商品模組

階段一:單應用架構

在網站建立初期,經常把所有的東西都在一臺機器上部署,這個時候的架構是單應用架構,優點是效率非常高


階段二:應用伺服器和資料庫伺服器分離

網站上線了,隨著時間推移,訪問量開始逐漸增大,伺服器逐漸的就扛不住了,這個時候就要考慮加機器了,這就進入了第二階段。

這個階段增加機器的主要目的是將web伺服器和資料庫伺服器進行拆分,這樣不僅提高了單機的負載能力,也提高了容災能力


第三階段:應用伺服器叢集

然而隨著訪問量的持續增加,單臺伺服器已經無法滿足需求。假設資料庫伺服器的還未遇到效能問題

此時可以增加應用伺服器,這就進入第三階段——應用伺服器叢集。


在這個階段有些問題就逐漸顯現出來了,比如:

(1)使用者的請求該由哪一臺機器進行處理? ——負載均衡(F5/apache/nginx)

(2)如果使用者每次請求的機器不同,那麼session如何維護?

1、session同步


2、通過第三方儲存(redis等)儲存session

3、跳過容器物件

這樣架構就變為了以下模式。


階段四:資料庫讀寫分離

隨著業務量進一步增加,資料庫伺服器的I/O能力會存在瓶頸。

首先考慮的是加機器,但是如果直接一分為二,每次讀寫還要額外判斷資料應該在哪臺機器上。

基於電商系統資料庫讀多寫少的特點,可以將一個伺服器作為寫庫,另一個庫設為讀庫,

並設定主從同步進行複製。

這樣也會帶來資料庫不一致的問題,這個問題後期有時間會單獨討論。

實際上,如果讀庫的量遠大於寫庫的訪問量,需要設定多個讀庫時,可以採取以下的結構


階段五:引入快取機制 

對於熱點資料,沒必要每次都去資料庫中讀取,應該使用 redis、memcache等將這些資料快取起來


至此,分散式架構的基本框架已經形成。

階段六:資料庫的水平、垂直拆分

資料庫永遠是最容易造成瓶頸的地方之一,例如阿里巴巴09年“去IOE運動”就是為了解決資料庫擴充套件性瓶頸問題。

在整個架構的編號過程中,所有的資料還是在同一個資料庫中的,因此我們可以考慮對資料進行拆分

其中:

垂直拆分就是把不同業務的資料拆分到不同的資料庫中


水平拆分則是把同一個表中的資料拆分到兩個甚至更多的資料庫中,有些公司的資料庫是按照日期分為31*N個數據庫


階段七:應用拆分階段

隨著需求的不斷提出,應用的體量也越來越大,因此需要按照領域對業務進行拆分


至此,完整的分散式架構演進過程結束


tips:分散式架構和微服務架構

分散式:

    • 不同模組部署在不同伺服器上
    • 作用:分散式解決網站高併發帶來問題

而微服務是一種架構風格,一個大型複雜軟體應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署,各個微服務之間是鬆耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下,每個任務代表著一個小的業務能力。

微服務是可以部署在一臺伺服器上的。

如果有興趣,可以加群一起學習。