一個大的java項目架構演進過程（淘寶爲例）：

一：總架構

二、演進過程

1. 小型網站所有服務都在一臺服務器上，俗稱All in One

但隨着用戶越來越多，訪問量越來越大，硬盤，CPU，內存等資源開始吃緊，性能滿足不了，開始演進：

開始配置文件服務器，數據服務器（配置更好更快更大的硬盤），應用服務器（配置好的CPU、內存），如果文件服務器服務器掛了，還是可以訪問數據和應用服務器。繼續演進

很多業務數據不用每次都從數據庫獲取，所以加入緩存（遠程單機緩存，遠程分佈式緩存等），80%的業務訪問都集中在20%的業務數據上，俗稱二八原則。緩存大大提升了性能。應用緩存的時候需要考慮幾個問題：

a.具有哪種業務特點的數據使用緩存  b.具有哪種業務特點的數據使用遠程緩存  c.分佈式緩存在擴容時會遇到什麼問題，如何解決  d.分佈式緩存的算法有哪幾種，各有什麼優缺點

隨着訪問的qps不斷提高，繼續演進：

系統加入一個負責均衡服務器，應用服務器配置成了一個集羣（cluster），使用各種負載均衡策略解決系統瓶頸；應用負載均衡時需要考慮問題：

a.負載均衡的策略各有哪些，各有什麼優缺點,各適合什麼場景  

當用戶達到一定量時，數據庫又會成爲一個瓶頸，如何解決？繼續演進：

使用數據庫的讀寫分離，應用接入多數據源，Master主庫，Slave從庫，應用服務加入數據訪問模塊，寫代碼的人不會知道數據庫的讀寫分離，那接下來又會引出問題：

a.如何接入多數據源    b.如何完成主從分離  c.數據庫訪問量大，IO頻繁，主從複製，跨機房傳輸問題，d.應用路由問題等

用戶訪問持續增多，爲了更好的提高服務器的訪問性能，架構繼續演進：

引入CDN和反向代理服務器，CDN可以很好的解決不同地區訪問速度問題，反向代理可以在機房中緩存用戶資源，此時用戶上傳下載文件性能（文件服務器）出現瓶頸，繼續演進：

文件服務器演進爲分佈式文件服務器

a.如何不影響已部署線上的業務訪問 （比如如何做到訪問一個圖片突然訪問不到）  b.是否需要備份服務器  c.是否需要域名解析

高大上的項目都是一點一點演進的，這只是一個大題的概念，做一個入門引領還是很不錯的！