分佈式架構——分佈式架構的演進過程（下）

上一篇博客簡單介紹了分佈式的發展歷史和基本概念

本篇博客則將以電商系統爲例，詳細介紹分佈式發展的過程 

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

階段一：單應用架構

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

階段二：應用服務器和數據庫服務器分離

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

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

第三階段：應用服務器集羣

然而隨着訪問量的持續增加，單臺服務器已經無法滿足需求。假設數據庫服務器的還未遇到性能問題

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

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

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

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

1、session同步

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

3、跳過容器對象

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

階段四：數據庫讀寫分離

隨着業務量進一步增加，數據庫服務器的I/O能力會存在瓶頸。

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

基於電商系統數據庫讀多寫少的特點，可以將一個服務器作爲寫庫，另一個庫設爲讀庫，

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

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

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

階段五：引入緩存機制 

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

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

階段六：數據庫的水平、垂直拆分

數據庫永遠是最容易造成瓶頸的地方之一，例如阿里巴巴09年「去IOE運動」就是爲了解決數據庫擴展性瓶頸問題。

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

其中：

垂直拆分就是把不同業務的數據拆分到不同的數據庫中

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

階段七：應用拆分階段

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

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

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

分佈式：

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

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

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

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