以電商為例 讀懂分散式架構的前世今生

【本文轉自部落格園，作者：阿豪聊乾貨  原標題：分散式架構的前世今生... 原文連結：https://www.cnblogs.com/hafiz/p/9222973.html】
一、前言

隨著社會的發展，技術的進步，以前的大型機架構很顯然由於高成本、難維護等原因漸漸地變得不再那麼主流了，替代它的就是當下最火的分散式架構，從大型機到分散式，經歷了好幾個階段，我們弄明白各個階段的架構，才能更好地理解和體會分散式架構的好處，那麼本文我們就來聊聊分散式架構的演進過程，希望能給大家帶來眼前一亮的感覺。

二、背景說明

我們都知道一個成熟的大型網站的系統架構並非一開始就設計的非常完美，也沒有一開始就具備高效能、高併發、高可用、安全性等特性，而是隨著使用者量的增加、業務功能的擴充套件逐步演變過來的，慢慢的完善的。 在這個過程中，開發模式、技術架構等都會隨著迭代發生非常大的變化。 而針對不同業務特徵的系統，各自都會有自己的側重點，例如像淘寶這類的網站，要解決的重點問題就是海量商品搜尋、下單、支付等問題; 像騰訊這類的網站，要解決的是數億級別使用者的實時訊息傳輸;而像百度這類的公司所要解決的又是海量資料的搜尋。每一個種類的業務都有自己不同的系統架構。

下面我們來簡單模擬一個架構演變過程。 我們以 javaweb 為例，來搭建一個簡單的電商系統，從這個系統中來看系統的演變過程。要注意的是接下來的演示模型， 關注的是資料量、訪問量提升，網站結構的變化， 而不關注具體業務的功能點。其次，這個過程是為了讓大家能更好的瞭解網站演進過程中的一些問題和應對策略。

假如我們系統具備以下功能:

使用者模組:使用者註冊和管理。

商品模組:商品展示和管理。

交易模組:建立交易及支付結算。

三、階段一：單應用架構

這個階段是網站的初期，也可以認為是網際網路發展的早期，系統架構如上圖所示。我們經常會在單臺伺服器上執行我們所有的程式和軟體。 把所有軟體和應用都部署在一臺機器上，這樣就完成一個簡單系統的搭建，這個階段的講究的是效率。效率決定生死。

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

隨著網站的上線，訪問量逐步上升，伺服器的負載慢慢提高，我們應該在伺服器還沒有超載的時候就做好規劃、提升網站的負載能力。假若此時已經沒辦法在程式碼層面繼續最佳化提高，那麼在單臺機器的效能遇到瓶頸的時候，增加機器是一個比較簡單好用的方式，投入產出比相當高。這個階段增加機器的主要目的是將 web 伺服器和 資料庫伺服器拆分開來，這樣做的話不僅提高了單機的負載能力，也提高了整個系統的容災能力。

這個階段的系統架構如上圖所示，應用伺服器和資料庫伺服器完全隔離開來，相互互不影響，大大減少了網站當機的風險，此階段我們已經開始關注到應用伺服器的管理了。

五、階段三：應用伺服器叢集

這個階段，隨著訪問量的繼續不斷增加，單臺應用伺服器已經無法滿足我們的需求。 假設我的資料庫伺服器還沒有遇到效能問題，那我們可以透過增加應用伺服器的方式來將應用伺服器叢集化，這樣就可以將使用者請求分流到各個伺服器中，從而達到繼續提升系統負載能力的目的。此時各個應用伺服器之間沒有直接的互動，他們都是依賴資料庫各自對外提供服務。

系統架構發展到這個階段，各種問題也會接踵而至：

使用者請求交由誰來轉發到具體的應用伺服器上(誰來負責負載均衡)

使用者如果每次訪問到的伺服器不一樣，那麼如何維護

session，達到session共享的目的。

那麼此時，系統架構又會變成如下方式：

　　

負載均衡又可以分為軟負載和硬負載。軟負載我們可以選擇Nginx、Apache等，硬負載我們可以選擇F5等。而session共享問題我們可以透過配置tomcat的session共享解決。

六、階段四：資料庫壓力變大，資料庫讀寫分離

架構演變到上面的階段，並不是終點。透過上面的設計，應用層的效能被我們拉上來了， 但資料庫的負載也在逐漸增大，那如何去提高資料庫層面的效能呢?有了前面的設計思路以後，我們自然也會想到透過增加伺服器來提高效能。但假如我們單純的把資料庫一分為二，然後對於資料庫的請求，分別負載到兩臺資料庫伺服器上，那必定會造成資料庫資料不統一的問題。 所以我們一般先考慮將資料庫讀寫分離。

這個架構設計的變化會帶來如下幾個問題：

主從資料庫之間的資料需要同步(可以使用 mysql 自帶的 master-slave 方式實現主從複製 )

應用中需要根據業務進行對應資料來源的選擇( 採用第三方資料庫中介軟體，例如 mycat )

七、階段五：使用搜尋引擎緩解讀庫的壓力

我們都知道資料庫常常對模糊查詢效率不是很高，像電商類的網站，搜尋是非常核心的功能，即使是做了讀寫分離，這個問題也不能得到有效解決。那麼這個時候我們就需要引入搜尋引擎了，使用搜尋引擎能夠大大提升我們系統的查詢速度，但同時也會帶來一 些附加的問題，比如維護索引的構建、資料同步到搜尋引擎等。

八、階段六：引入快取機制緩解資料庫的壓力

然後，隨著訪問量的持續不斷增加，逐漸會出現許多使用者訪問同一內容的情況，那麼對於這些熱點資料，沒必要每次都從資料庫重讀取，這時我們可以使用到快取技術，比如 redis、memcache 來作為我們應用層的快取。另外在某些場景下，如我們對使用者的某些 IP 的訪問頻率做限制， 那這個放記憶體中就又不合適，放資料庫又太麻煩了，那這個時候可以使用 Nosql 的方式比如 mongDB 來代替傳統的關係型資料庫。

九、階段七：資料庫的水平/垂直拆分

我們的網站演進的變化過程，交易、商品、使用者的資料都還在同一 個資料庫中，儘管採取了增加快取，讀寫分離的方式，但是隨著數 據庫的壓力持續增加，資料庫的瓶頸仍然是個最大的問題。因此我 們可以考慮對資料的垂直拆分和水平拆分。

垂直拆分:把資料庫中不同業務資料拆分到不同的資料庫。

水平拆分:把同一個表中的資料拆分到兩個甚至更多的資料庫中，水平拆分的原因是某些業務資料量已經達到了單個資料庫的瓶頸，這時可以採取將表拆分到多個資料庫中。

十、階段八：應用的拆分

隨著業務的發展，業務量越來越大，應用的壓力越來越大。工程規模也越來越龐大。這個時候就可以考慮將應用拆分，按照領域模型將我們的使用者、商品、交易拆分成多個子系統。

這樣拆分以後，可能會有一些相同的程式碼，比如使用者操作，在商品和交易都需要查詢，所以會導致每個系統都會有使用者查詢訪問相關操作。這些相同的操作一定是要抽象出來，否則就是一個坑。所以透過走服務化路線的方式來解決。

那麼服務拆分以後，各個服務之間如何進行遠端通訊呢? 透過 RPC 技術，比較典型的有:dubbo、webservice、hessian、http、RMI 等等。前期透過這些技術能夠很好的解決各個服務之間通訊問題，但是， 網際網路的發展是持續的，所以架構的演變和最佳化也還在持續。

十一、總結

透過本文，我們透過一個電商的案例，就瞭解到了分散式架構的演進過程，一環套一環，環環緊密相扣。都是透過業務量和訪問量的提升來考慮重構架構設計，以便能夠適應當前的環境。不可一蹴而就，也急不來，初創企業必須穩紮穩打，一步一個腳印的走出一條專屬自己的路。加油，everybody!