乾貨！分佈式架構演進總結

1、前言

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

2、背景說明

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

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

假如咱們系統具有如下功能:

• 用戶模塊:用戶註冊和管理。
• 商品模塊:商品展現和管理。
• 交易模塊:建立交易及支付結算。

3、階段一：單應用架構

這個階段是網站的初期，也能夠認爲是互聯網發展的早期，系統架構如上圖所示。咱們常常會在單臺服務器上運行咱們全部的程序和軟件。把全部軟件和應用都部署在一臺機器上，這樣就完成一個簡單系統的搭建，這個階段的講究的是效率。效率決定生死。

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

隨着網站的上線，訪問量逐步上升，服務器的負載慢慢提升，咱們應該在服務器尚未超載的時候就作好規劃、提高網站的負載能力。倘若此時已經沒辦法在代碼層面繼續優化提升，那麼在單臺機器的性能遇到瓶頸的時候，增長機器是一個比較簡單好用的方式，投入產出比至關高。這個階段增長機器的主要目的是將 web 服務器和 數據庫服務器拆分開來，這樣作的話不只提升了單機的負載能力，也提升了整個系統的容災能力。

這個階段的系統架構如上圖所示，應用服務器和數據庫服務器徹底隔離開來，相互互不影響，大大減小了網站宕機的風險，此階段咱們已經開始關注到應用服務器的管理了。

5、階段三：應用服務器集羣

這個階段，隨着訪問量的繼續不斷增長，單臺應用服務器已經沒法知足咱們的需求。假設個人數據庫服務器尚未遇到性能問題，那咱們能夠經過增長應用服務器的方式來將應用服務器集羣化，這樣就能夠將用戶請求分流到各個服務器中，從而達到繼續提高系統負載能力的目的。此時各個應用服務器之間沒有直接的交互，他們都是依賴數據庫各自對外提供服務。

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

• 用戶請求交由誰來轉發到具體的應用服務器上(誰來負責負載均衡)
• 用戶若是每次訪問到的服務器不同，那麼如何維護

  session，達到session共享的目的。

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

負載均衡又能夠分爲軟負載和硬負載。軟負載咱們能夠選擇Nginx、Apache等，硬負載咱們能夠選擇F5等。而session共享問題咱們能夠經過配置tomcat的session共享解決。

6、階段四：數據庫壓力變大，數據庫讀寫分離

架構演變到上面的階段，並非終點。經過上面的設計，應用層的性能被咱們拉上來了， 但數據庫的負載也在逐漸增大，那如何去提升數據庫層面的性能呢？有了前面的設計思路之後，咱們天然也會想到經過增長服務器來提升性能。但假如咱們單純的把數據庫一分爲二，而後對於數據庫的請求，分別負載到兩臺數據庫服務器上，那一定會形成數據庫數據不統一的問題。因此咱們通常先考慮將數據庫讀寫分離。

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

• 主從數據庫之間的數據須要同步(可使用 mysql 自帶的 master-slave 方式實現主從複製 )
• 應用中須要根據業務進行對應數據源的選擇( 採用第三方數據庫中間件，例如 mycat )

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

咱們都知道數據庫經常對模糊查找效率不是很高，像電商類的網站，搜索是很是核心的功能，即便是作了讀寫分離，這個問題也不能獲得有效解決。那麼這個時候咱們就須要引入搜索引擎了，使用搜索引擎可以大大提高咱們系統的查詢速度，但同時也會帶來一 些附加的問題，好比維護索引的構建、數據同步到搜索引擎等。

8、階段六：引入緩存機制緩解數據庫的壓力

而後，隨着訪問量的持續不斷增長，逐漸會出現許多用戶訪問同一內容的狀況，那麼對於這些熱點數據，不必每次都從數據庫重讀取，這時咱們可使用到緩存技術，好比 redis、memcache 來做爲咱們應用層的緩存。另外在某些場景下，如咱們對用戶的某些 IP 的訪問頻率作限制， 那這個放內存中就又不合適，放數據庫又太麻煩了，那這個時候可使用 Nosql 的方式好比 mongDB 來代替傳統的關係型數據庫。

9、階段七：數據庫的水平/垂直拆分

咱們的網站演進的變化過程，交易、商品、用戶的數據都還在同一 個數據庫中，儘管採起了增長緩存，讀寫分離的方式，可是隨着數 據庫的壓力持續增長，數據庫的瓶頸仍然是個最大的問題。所以我 們能夠考慮對數據的垂直拆分和水平拆分。

垂直拆分:把數據庫中不一樣業務數據拆分到不一樣的數據庫。

水平拆分:把同一個表中的數據拆分到兩個甚至更多的數據庫中，水平拆分的緣由是某些業務數據量已經達到了單個數據庫的瓶頸，這時能夠採起將表拆分到多個數據庫中。

10、階段八：應用的拆分

隨着業務的發展，業務量愈來愈大，應用的壓力愈來愈大。工程規模也愈來愈龐大。這個時候就能夠考慮將應用拆分，按照領域模型將咱們的用戶、商品、交易拆分紅多個子系統。

這樣拆分之後，可能會有一些相同的代碼，好比用戶操做，在商品和交易都須要查詢，因此會致使每一個系統都會有用戶查詢訪問相關操做。這些相同的操做必定是要抽象出來，不然就是一個坑。因此經過走服務化路線的方式來解決。

那麼服務拆分之後，各個服務之間如何進行遠程通訊呢? 經過 RPC 技術，比較典型的有:dubbo、webservice、hessian、http、RMI 等等。前期經過這些技術可以很好的解決各個服務之間通訊問題，可是， 互聯網的發展是持續的，因此架構的演變和優化也還在持續。

原文：https://www.cnblogs.com/logsh...
做者：在途中#