## 第一篇: 概述
## 第一章: 大型網站的演化
### 1.1 大型網站軟件系統的特點
高并發, 大流量
高可用
海量數據
用戶分布廣泛, 網絡情況復雜
安全環境惡劣
需求快速變更, 發布頻繁
漸進式發展
### 2.3 大型網站架構演化發展歷程
1) 初始階段的網站架構
一臺服務器搞定一切
2) 應用服務和數據服務分離
分出了應用, 數據, 文件三臺服務器. 應用服務器要處理大量的業務, 所以需要更快更強的CPU. 數據服務器快速磁盤檢索和數據緩存, 需要更快的硬盤和大內存; 文件服務器用于存儲用戶的文件, 需要更大的硬盤
3) 使用緩存改善網站性能
遵循2/8定律. 80%的業務訪問集中在20%的數據上.
只要緩存住了這20%的數據, 就可以大大減少服務器的讀
4) 使用應用服務器集群改善網站的并發處理能力
通過持續增加應用服務器的方式來改善負載壓力, 實現系統的可伸縮性.
而不是采購更強的服務器.
5) 數據庫的讀寫分離
配置主從數據庫. 應用服務器要寫數據時, 訪問主數據庫. 主數據庫通過主從復制機制將數據更新同步到從數據庫.
6) 使用反向代理和CDN加速網站響應
基本原理都是緩存. 區別在于CDN部署在網絡提供商機房中. 而反向代理部署在網站機房中.
7) 使用分布式文件系統和分布式數據庫系統
使用分布式數據庫是數據庫拆分的最后手段. 更常使用的是業務分庫.
8) 使用NoSQL和搜索引擎
通過一個統一的數據層訪問各種數據, 減輕應用程序管理諸多數據庫的麻煩
9) 業務拆分
將整個網站業務拆分成不同的產品線
10) 分布式服務
### 1.3 大型網站架構演化的價值觀
1) 核心價值是隨網站所需靈活應對
2) 驅動技術發展的主要力量是業務發展
### 1.4 網站架構設計誤區
1) 一味追求大公司的解決方案
2) 為了技術而技術
3) 企圖用技術解決所有問題
技術是用來解決業務問題的, 而業務問題, 也可以通過業務的手段去解決
## 第二章: 大型網站架構模式
模式: 問題和場景的可重復帶來了解決方案的可重復性
### 2.1 架構模式
1) 分層
將系統在橫向緯度上切分成幾個部分, 每個部分負責一部分比較單一的職責, 然后通過上層對下層的依賴和調用組成一個完整的系統.
分層架構的挑戰: 必須合理規劃層次邊界和接口, 在開發過程中, 嚴格遵循分層架構約束, 禁止跨層次的調用以及逆向調用(如數據層調用應用層)
2) 分割
在縱向方面對軟件進行切分. 將不同的功能和服務分割開來, 包裝成高內聚低耦合的模塊單元.
一方面有助于軟件的開發和維護; 另一方面, 便于同步模塊的分布式部署, 提供網站的并發處理能力和功能擴展能力
分布式
分層和分割的一個主要目的就是為了分布式部署.
### 分布式會帶來以下問題:
a. 必須通過網絡, 對性能造成影響
b. 服務器越多, 宕機的可能性越大, 使網站的可用性降低
c. 在分布式環境下保證數據的一致性很困難, 分布式事務也難以保證, 對業務正確性和業務流程造成影響
d. 導致網站依賴復雜, 開發管理維護困難
### 常用的分布式:
a. 分布式用用和服務
b. 分布式靜態資源
減輕應用服務器負載; 通過獨立域名加快瀏覽器并發加載速度; 由專門用戶體驗團隊維護, 分工更加明確.
c. 分布式數據和存儲
d. 分布式計算
Hodoop和MapReduce. 特點是移動計算而不是移動數據, 將計算程序分發到數據所在的位置以加速計算和分布式計算
e. 分布式配置
f. 分布式鎖
g. 分布式文件系統
### 集群
使用分布式雖然將分層和分割后的模塊獨立部署, 但對于用戶訪問集中的模塊(比如首頁), 還需要將獨立部署的服務器集群化, 即多臺服務器部署相同的應用構成一個集群, 通過負載均衡服務器共同對外提供服務.
### 緩存
緩存就是將數據存放在距離計算最近的位置以加快處理速度, 緩存是改善軟件性能的第一手段
### 緩存的分類:
CDN: 內容分發網絡
反向代理
本地緩存
分布式緩存: Redis Memcached
使用緩存的2個條件:
a. 數據訪問熱點不均衡, 將熱點數據緩存起來
b. 數據在某個時間段內有效, 不會很快過期. 否則緩存的數據會因為失效而產生臟讀.
緩存的作用:
a. 加速數據訪問速度
b. 減輕后端應用和數據存儲應用的負載壓力, 這一點對網站數據庫架構至關重要. 網站數據庫幾乎都是按照有緩存的前提進行負載能力設計的
異步
通過消息隊列, 將同步的操作編程異步的.
如下特性:
a. 提供系統的可用性
b. 加速網站響應速度
c. 消除并發訪問高峰
可能對用戶體驗和業務流程造成影響.
冗余
### 自動化
a. 發布過程自動化
b. 自動化代碼管理
c. 自動化測試
d. 自動化安全檢測
e. 自動化部署
f. 自動化監控
g. 自動化報警
h. 自動化失效轉移: 將失效的服務器從集群中隔離除去, 不再處理系統中的應用請求
i. 自動化失效恢復: 重新啟動服務, 同步數據保證數據一致性
j. 自動化降級: 通過拒絕部分請求及關閉部分不重要的業務將系統負載降至一個安全的水平
k. 自動化分配資源: 將空閑資源分配給重要的服務, 擴大其部署規模
安全
身份認證: 密碼, 手機短信
登錄,交易等操作需要對網絡通信加密
網站存儲的敏感數據要加密
使用驗證碼防止機器人攻擊
對于XSS攻擊, SQL注入進行編碼轉換
對垃圾信息和敏感信息進行過濾
對交易轉賬等重要操作進行風險控制
### 2.2 架構模式在新浪微博中的應用
小結: 好的設計絕不是模范, 不是生搬硬套某個模式, 而是對問題深刻理解之上的創造和創新
山寨和創新的最大區別不是是否抄襲和模范, 而在于對問題和需求是否真正理解和把握
## 第三章: 大型網站核心架構要素
軟件架構: 有關軟件整體結構與組件的抽象描述, 用于指導大型軟件系統各個方面的設計
系統的各個重要組成部分及其關系構成了系統的架構. 這些組成部分可以是具體的功能模塊, 也可以是非功能的設計和決策, 如性能/可用性/伸縮性/擴展性/安全性, 它們相互關系組成一個整體, 共同構成了軟件系統的架構
### 3.1 性能
衡量性能的指標: 響應時間, TPS, 系統性能計數器
對于網站而言, 性能符合預期僅僅是必要條件, 因為無法預知網站可能面臨的訪問壓力, 所以必須考察系統在高并發情況下, 超出負載設計能力時可能出現的問題. 網站需要長時間運行, 還必須保證在持續運行且訪問壓力不均勻時保持問題的性能特征.
### 3.2 可用性
高可用的目標就是當服務器宕機時, 服務依然可用. 主要手段是集群, 冗余. 關鍵在于服務器中不能保存用戶會話狀態.
### 3.3 伸縮性
定義: 通過不斷想服務器集群中添加服務器的手段來緩解不斷上漲的用戶并發訪問壓力和不斷增長的數據存儲需求
### 3.4 擴展性
擴展性直接關注網站的功能需求.
目的: 在網站快速發展, 功能不斷擴展時, 網站架構能夠快速響應需求變化.
主要手段:
a. 事件驅動架構: 利用消息隊列實現
b. 分布式服務: 將業務和可復用服務分離開來, 通過分布式服務框架調用
### 3.5 安全性
小結:
## 第二篇: 架構
## 第四章: 瞬時響應, 網站的高性能架構
### 4.1 網站性能測試
不同視角下的網站性能
性能測試指標
性能測試方法
性能優化策略
### 4.2 Web前端性能優化
瀏覽器訪問優化
CDN加速
反向代理
### 4.3 應用服務器性能優化
分布式緩存
異步操作
使用集群
代碼優化
### 4.5 存儲性能優化
機械硬盤 vs. 固態硬盤
B+樹 vs. LSM樹
RAID vs. HDFS
小結:
- 職業生涯
- 如何提升你的能力?給年輕程序員的幾條建議
- 那些年,那些事
- 阿里巴巴離職DBA 35歲總結的職業生涯
- 人生的四種選擇
- 程序人生的四個象限和兩條主線
- 幾縷代碼與閑思
- 張小龍-學習筆記
- Web前端
- 移動Web手冊
- 精通CSS: 高級Web標準解決方案
- 悟透JavaScript
- 架構設計
- 大型網站技術架構
- 周愛民-大道至簡
- RESTful Web Services Cookbook - 讀書筆記
- 大話設計模式
- Unix編程藝術
- 把程序員修煉之道讀薄
- 學習能力
- 奇特的一生:讀書筆記
- zhh-看源碼那些事
- 一個創業者怎么看待讀書和寫作
- 程序員修煉之道
- 2015/1/5 頭腦風暴
- 書單計劃
- 2014年我讀過的那些書
- 我的后端開發書架2015
- 別人的書單
- 讀書筆記
- 浪潮之巔
- 達內時期自己筆記整理
- Effective Java
- 打造facebook: 讀書筆記
- 面試整理
- 阿里面試的一點感受
- 騰訊的三輪面試
- 三十之惑–面霸
- 前端面試問題匯總
- 八爪網絡面試總結
- 2015面試總結總結
- 找工作流程梳理
- 最全前端面試問題及答案總結
- 前端開發面試題收集
- 百度web前端--2015一面
- 百度web前端--2015二面