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

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

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

階段一：單應用架構

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

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

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

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

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

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

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

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

（2）如果使用者每次請求的機器不同，那麼session如何維護？

1、session同步

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

3、跳過容器物件

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

階段四：資料庫讀寫分離

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

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

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

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

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

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

階段五：引入快取機制 

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

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

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

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

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

其中：

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

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

階段七：應用拆分階段

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

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

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

分散式：

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

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

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

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