這些年,系統架構都經歷了怎樣的演變?

當今技術的發展突飛猛進,系統架構也跟隨技術的發展不斷升級和改進,從傳統的單一架構演變爲現在的微服務分佈式架構,咱們來看看技術架構的演變過程。數據庫

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,咱們很容易部署一套高性能高可用的微服務架構。

相關文章
相關標籤/搜索