一、架構演進過程
1、初生
發展問題
隨着網站業務的發展，越來越多的用戶訪問，面臨的問題：
- 性能越來越差
- 越來越多的數據導致存儲空間不足
2、應用程序與數據服務分離
發展問題
隨着用戶增多，網站再次面臨挑戰：
- 數據庫壓力太大導致訪問延遲，進而影響整個網站的性能，用戶體驗受到影響
3、使用緩存改善性能
本地緩存：
- 優點：速度快
- 缺點：內存有限，只能緩存少量數據會和應用程序爭用內存，應用程序能用內存就降低了
遠程分佈式緩存
- 優點：按需擴展，可以搭建集羣
- 缺點：由於要通過網絡訪問，所以性能可能會相對於本地緩存差一點
常用緩存組件：memcache，redis
發展問題
隨着用戶增多，單一服務器面臨新的問題：
能夠處理的請求連接有限，網站訪問高峯期，會出現拒絕服務，響應時間過長，應用服務器成爲整個網站的瓶頸
4、應用服務集羣
應用服務器之所以不用更強的服務器而是採用集羣的方式是因爲再強的服務器都有天花板，如果是集羣的形式，可以按需不斷地擴充。
負載均衡的實現方式：
硬件負載均衡要優於軟件，但是要花錢
發展問題
上邊解決了請求問題，但是使用緩存後，雖然大大減輕了數據庫的讀壓力，面臨了新的問題：
- 有一部分讀操作（緩存訪問不命中，緩存過期）和全部的寫操作要訪問數據庫，當用戶達到一定規模後，數據庫因爲負載壓力過高而成爲整個系統的瓶頸
5、數據庫讀寫分離
這裏除了數據庫進行了讀寫分離，應用服務器中多了一個數據訪問模塊，用於對不同的數據庫的訪問
數據訪問模塊可用技術
發展問題
用戶規模越來越大，發佈地域越來越廣，地域網絡環境差別很大，面臨問題：
- 如何保證用戶的訪問體驗，不至於因訪問慢而流失用戶
6、反向代理和CDN加速
CDN是內容分發網絡，必須要部署到電信運營商的數據中心裏邊，適用於靜態資源，把資源提前緩存到當地的電信運營商那裏，當用戶通過電信網絡發送請求時，一定會走到電信運營商的數據中心裏邊進行路由分發，如果發現請求地址對應的資源在數據中心有，就直接返回，通俗來講相當於一個代理商，比如說某個商品只有A城市有，但是我要是在B城市買該商品就必須到A城市去買，這個CDN就相當於代理商，B城市的代理商存了一些商品，B城市的消費者直接去該城市的代理商那裏買商品就行了，不需要再去A城市消費了。
反向代理也是用來緩存靜態資源的，和CDN的區別就是地點不一樣，反向代理服務器部署在我們的數據中心的最外層，是我們整個應用程序的最外層，甚至可能和負載均衡是用一個組件，和CDN原理都是緩存。
這種架構的優勢：加快用戶訪問速度，減輕後端服務器的負載壓力
發展問題
單文件服務器，但數據庫服務器面臨問題：
存不下日益增長的數據
7、分佈式文件系統和分佈式數據庫系統
發展問題
隨着業務的發展，數據的存儲需求和檢索需求越來越複雜，面臨的問題：
- 存儲的字段差異較大
- 複雜的文本檢索
8、使用NOSQL和搜索引擎
lucene是一個開源的搜索引擎開發工具包，如果需要可以導入jar包，調用api，solr是一個做好的系統，是lucene的子項目，開箱即用，elasticsearch也是基於lucene開發，直接拿出來使用。
發展問題
網站越做越好，業務不斷擴大，越來越複雜，面臨的問題:
應用程序變得無比龐大，迭代週期越來越快，牽一髮而動全身，怎麼應對快速的業務發展需要？
9、業務拆分
發展問題
10、分佈式服務（服務化）
圖中出現了服務的共用，不需要每個應用中都要有相同的服務了，通過配置中心來進行服務化
服務化的兩種架構方式
齒輪相當於服務提供者或者服務調用者
SOA的缺點，所有服務都需要連接中間的服務總線（ESB），服務總線也會有瓶頸，好處就是服務的相關管理和治理都可以在ESB上做。
微服務就不需要有中間的ESB，而是直接兩個服務進行通信。
發展問題
11、大數據技術，監控，日誌分析系統
左下角的三個系統只需要把數據拿到進行分析就行了，是獨立的系統
二、架構思想總結
三、架構設計誤區
