1. 特點
| 特點 | Challenge |
|---|---|
| 高并發，大流量 , 高可用 | 分布式應用，需保證不宕機，提供穩定服務，安全 |
| 海量數據 | 需要大量服務器，分布式存儲，計算 |
| 網絡情況復雜 | 需要解決全球各地，國內各運營商網絡的差異和時延安全環境惡劣 |
| 需求變更快，發布頻繁 | 需自動化代碼管理，測試，部署，發布 |
網站漸進式發展，業務驅動技術 。
2. 架構演變歷程
大致分為以下6步:
- 物理分離webserver、數據庫和文件
- 增加緩存
- 使用應用服務器集群
- 使用數據庫集群
- 反向代理+CDN加速響應
- 拆分業務+廉價存儲+統一的數據訪問模塊
step 1：物理分離webserver、數據庫和文件
step 2：增加緩存
Motivation：
a.訪問數據庫的操作太多，數據庫連接資源緊張激烈，又不能開太多，否則數據庫機器壓力會很大。
b.二八定律，80%的業務集中訪問20%的數據。
緩存分類：
緩存在應用服務器本地緩存 VS 遠程分布式緩存
緩存內容：
a. 采用 squid 等類似的機制來將系統中相對靜態的頁面（例如一兩天才會有更新的頁面）進行緩存
b. 采用ESI來做動態頁面中相對靜態的片段部分的緩存。
c. 重復獲取的數據信息緩存，如用戶信息等
step 3： 使用應用服務器集群
** Motivation：
a.提高可用性，避免單臺宕機
b.webServer已經成為性能瓶頸
c.提高可擴展性，所以不采取獲得更強服務器策略
** 挑戰
![Uploading webserver集群_348402.png . . .]
a. 如何讓訪問分配到這兩臺機器上，考慮方案負載均衡(Apache自帶的負載均衡方案，或LVS這類的軟件負載均衡方案)
b. 如何保持狀態信息的同步，例如用戶session等。考慮的方案寫入數據庫、寫入存儲、cookie或同步session信息等機制等；
step 4： 使用數據集群
| 方式 | Motivation | challenge |
|---|---|---|
| 分庫，分表 | a.數據庫連接的資源競爭非常激烈，確無法進行分布式式部署 b.表中數據越來越多，增刪改查的開銷也會越來越大 | a. 事務造成的性能問題 b.跨庫跨表的join問題 c.額外的數據管理負擔和數據運算壓力 |
| 主從熱備，讀寫分離 | a. 緩存沒有命中的情況下，數據庫負載成為瓶頸 b.主從熱備是因為需要一個簡單的協議保證“一致性” | a. 主從一致性 b. 對應用保持透明性 |
| 分布式緩存，分布式數據庫，分布式文件系統 | a. 多備份分擔壓力 b.避免單點問題 ，更傾向于選擇分表分庫 | 數據分布和查找協議，數據一致性問題。 |
輔助增加模塊：數據庫訪問管理模塊，原因：需要通用的框架來實現分庫分表的數據訪問
step 5： 反向代理+CDN加速響應
Motivation：訪問延遲和用戶流失率成正比。
相同點：a，基本原理都是緩存，目的都是把數據盡早返回給用戶，并且減輕后端服務器壓力。
區別：
CDN：從距離自己最近的網絡提供商機房獲取數據。
反向代理：部署在數據中心機房，用戶請求到達之后首先安防服務的是反向代理服務器，如果命中，直接返回。
step 6： 拆分業務+廉價存儲+統一的數據訪問模塊
（1） 業務拆分：
Motivation：應用場景復雜，server壓力大，因此分為治之。 模塊與模塊之間的通信方式：超鏈接+消息隊列+訪問同一個數據存儲系統（最常見）
分治的原則：提取可復用業務，拆分松耦合的業務
challenge：
a：需要提供一個高性能、穩定的通信框架，并且需要支持多種不同的通信和遠程調用方式；
b：需要進行業務的整理和系統依賴關系的控制等；
c：如何運維（依賴管理、運行狀況管理、錯誤追蹤、調優、監控和報警等）好這個龐大的分布式應用。
（2） 廉價存儲：
BigTable：分布式數據存儲系統，用來處理海量的數據的一種非關系型的數據庫
NoSQL：關系型數據面臨的挑戰，a：事務導致其在分布式系統中性能很低。b: 聯表，需要在不同服務器中收集數據，效率低，相反實踐證明，冗余帶來的收益高于成本。性能：B樹更新操作性能不如LSM樹
（3）統一的數據訪問模塊：
References
[1] http://www.blogjava.net/BlueDavy/archive/2008/09/03/226749.html
[2] 大型網站技術架構: 核心原理與案例分析[M]. 電子工業出版社, 2013.
