當今技術(shù)的發(fā)展日新月異逻澳，系統(tǒng)架構(gòu)也跟隨技術(shù)的發(fā)展不斷升級和改進，從傳統(tǒng)的單一架構(gòu)演變?yōu)槿缃竦奈⒎?wù)分布式架構(gòu)暖呕，我們來看看技術(shù)架構(gòu)的演變過程斜做。

NO.1 初期網(wǎng)站架構(gòu)

網(wǎng)站建設(shè)初期，訪問人數(shù)有限湾揽，數(shù)據(jù)量不大陨享，只需要一臺服務(wù)器足矣，這時應(yīng)用程序钝腺、文件抛姑、數(shù)據(jù)庫等所有資源全部集中在這臺服務(wù)器上，網(wǎng)站架構(gòu)請看下圖：?

NO.2 應(yīng)用和數(shù)據(jù)分離

隨著網(wǎng)站業(yè)務(wù)的不斷發(fā)展艳狐，一臺服務(wù)器已經(jīng)不能滿足要求定硝，用戶訪問量越來越大，數(shù)據(jù)量也越來越大毫目，此時對網(wǎng)站的要求也逐漸變大蔬啡，這就需要將應(yīng)用和數(shù)據(jù)分離，變成應(yīng)用服務(wù)器镀虐、文件服務(wù)器和數(shù)據(jù)庫服務(wù)器箱蟆。架構(gòu)圖如下：?

NO.3 緩存數(shù)據(jù)以改善網(wǎng)站性能

隨著用戶逐漸的不斷增加，數(shù)據(jù)庫訪問壓力變大刮便，導(dǎo)致訪問延遲空猜，性能較低，這時就需要緩存技術(shù)，將查詢較多或者改動不大的數(shù)據(jù)緩存起來辈毯，以加快應(yīng)用訪問速度坝疼，下面是基本的架構(gòu)圖：?

NO.4 應(yīng)用集群

在網(wǎng)站訪問高峰，并發(fā)量大的情況下谆沃，應(yīng)用服務(wù)器就成為了整個網(wǎng)站的瓶頸钝凶，單一的應(yīng)用服務(wù)器資源有限，高并發(fā)情況下連接很快就會超限唁影，這時耕陷，我們就需要部署應(yīng)用服務(wù)器集群，利用負載均衡器分散訪問流量据沈，減少單臺服務(wù)器的壓力哟沫，網(wǎng)站架構(gòu)圖如下：?

NO.5 數(shù)據(jù)庫讀寫分離

這個階段，數(shù)據(jù)繼續(xù)增加卓舵，請求數(shù)量繼續(xù)加大南用，單個數(shù)據(jù)庫已然不能滿足要求膀钠，這個時候需要部署多個數(shù)據(jù)庫進行讀寫分離掏湾，請看架構(gòu)圖：?

NO.6 部署 CDN 節(jié)點

用戶訪問量的增加意味著用戶地域的分散請求，如果所有請求都直接發(fā)送中心服務(wù)器的話肿嘲，距離越遠融击，響應(yīng)速度越差，這時就需要用到 CDN 技術(shù)雳窟，通過 CDN 加速尊浪，保證用戶訪問每次都從最近的服務(wù)器獲取數(shù)據(jù)，架構(gòu)圖如下：?

NO.7 分布式數(shù)據(jù)庫

分布式數(shù)據(jù)庫是網(wǎng)站數(shù)據(jù)庫拆分的最后手段封救，只有在單表數(shù)據(jù)規(guī)模非常龐大的時候才使用拇涤。

不到不得已時，網(wǎng)站更常用的數(shù)據(jù)庫拆分手段是業(yè)務(wù)分庫誉结，將不同業(yè)務(wù)的數(shù)據(jù)庫部署在不同的物理服務(wù)器上鹅士，如下圖所示：?

NO.8 使用非關(guān)系型數(shù)據(jù)庫

當網(wǎng)站數(shù)據(jù)足夠龐大，達到PB甚至更高時惩坑，關(guān)系型數(shù)據(jù)庫已經(jīng)達到瓶頸掉盅，這時就需要考慮采用非關(guān)系型數(shù)據(jù)庫了，請看下圖：?

NO.9 微服務(wù)架構(gòu)

隨著網(wǎng)站業(yè)務(wù)的不斷擴大以舒，我們需要將各個業(yè)務(wù)進行拆分趾痘，形成不能的產(chǎn)品線，每個產(chǎn)品線由不同的業(yè)務(wù)團隊負責蔓钟，各個產(chǎn)品之間需要通信永票，這時就要用到微服務(wù)架構(gòu)，請看下圖：?

最流行的 JavaEE 框架就是 Spring 框架，該框架是最古老也就是最成熟的 Java 技術(shù)框架之一瓦侮。

為了適應(yīng)技術(shù)的高速發(fā)展艰赞，Spring Cloud 出現(xiàn)了，它的出現(xiàn)帶給了我們微服務(wù)的解決方案肚吏。

通過 Spring Cloud方妖，我們很容易部署一套高性能高可用的微服務(wù)架構(gòu)。