當今技術的發展日新月異，系統架構也跟隨技術的發展不斷升級和改進，從傳統的單一架構演變為如今的微服務分佈式架構，我們來看看技術架構的演變過程。
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，我們很容易部署一套高性能高可用的微服務架構。
閱讀更多 Java架構進階 的文章
