系統架構都經歷了怎樣的演變?

大快搜尋DKH發表於2018-11-07

當今技術的發展日新月異,系統架構也跟隨技術的發展不斷升級和改進,從傳統的單一架構演變為如今的微服務分散式架構,我們來看看技術架構的演變過程。

NO.1 初期網站架構

網站建設初期,訪問人數有限,資料量不大,只需要一臺伺服器足矣,這時應用程式、檔案、資料庫等所有資源全部集中在這臺伺服器上,網站架構請看下圖:

NO.2 應用和資料分離

隨著網站業務的不斷髮展,一臺伺服器已經不能滿足要求,使用者訪問量越來越大,資料量也越來越大,此時對網站的要求也逐漸變大,這就需要將應用和資料分離,變成應用伺服器、檔案伺服器和資料庫伺服器。架構圖如下:

NO.3 快取資料以改善網站效能

隨著使用者逐漸的不斷增加,資料庫訪問壓力變大,導致訪問延遲,效能較低,這時就需要快取技術,將查詢較多或者改動不大的資料快取起來,以加快應用訪問速度,下面是基本的架構圖:

NO.4 應用叢集

在網站訪問高峰,併發量大的情況下,應用伺服器就成為了整個網站的瓶頸,單一的應用伺服器資源有限,高併發情況下連線很快就會超限,這時,我們就需要部署應用伺服器叢集,利用負載均衡器分散訪問流量,減少單臺伺服器的壓力,網站架構圖如下:

NO.5 資料庫讀寫分離

這個階段,資料繼續增加,請求數量繼續加大,單個資料庫已然不能滿足要求,這個時候需要部署多個資料庫進行讀寫分離,請看架構圖:

NO.6 部署 CDN 節點

使用者訪問量的增加意味著使用者地域的分散請求,如果所有請求都直接傳送中心伺服器的話,距離越遠,響應速度越差,這時就需要用到 CDN 技術,透過 CDN 加速,保證使用者訪問每次都從最近的伺服器獲取資料,架構圖如下:

NO.7 分散式資料庫

分散式資料庫是網站資料庫拆分的最後手段,只有在單表資料規模非常龐大的時候才使用。

不到不得已時,網站更常用的資料庫拆分手段是業務分庫,將不同業務的資料庫部署在不同的物理伺服器上,如下圖所示:

NO.8 使用非關係型資料庫

當網站資料足夠龐大,達到 PB甚至更高時,關係型資料庫已經達到瓶頸,這時就需要考慮採用非關係型資料庫了,請看下圖:

NO.9 微服務架構

隨著網站業務的不斷擴大,我們需要將各個業務進行拆分,形成不能的產品線,每個產品線由不同的業務團隊負責,各個產品之間需要通訊,這時就要用到微服務架構,請看下圖:

目前,最流行的 JavaEE 框架就是 Spring 框架,該框架是最古老也就是最成熟的 Java 技術框架之一。為了適應技術的高速發展,Spring Cloud 出現了,它的出現帶給了我們微服務的解決方案。透過 Spring Cloud,我們很容易部署一套高效能高可用的微服務架構。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31555587/viewspace-2219093/,如需轉載,請註明出處,否則將追究法律責任。

相關文章