大型網(wǎng)站技術(shù)架構(gòu)-讀書筆記

更新記錄

  1. 2014/11/30, 添加筆記.
  • 2015/1/7, 將筆記從Github移到簡書

第一篇: 概述

  1. 大型網(wǎng)站的演化
  2. 大型網(wǎng)站架構(gòu)模式
  3. 大型網(wǎng)站核心架構(gòu)元素

第一章: 大型網(wǎng)站的演化

1.1 大型網(wǎng)站軟件系統(tǒng)的特點

  1. 高并發(fā), 大流量
  2. 高可用
  3. 海量數(shù)據(jù)
  4. 用戶分布廣泛, 網(wǎng)絡情況復雜
  5. 安全環(huán)境惡劣
  6. 需求快速變更, 發(fā)布頻繁
  7. 漸進式發(fā)展

1.2 大型網(wǎng)站架構(gòu)演化發(fā)展歷程

  1. 初始階段的網(wǎng)站架構(gòu)

一臺服務器搞定一切

  1. 應用服務和數(shù)據(jù)服務分離

分出了應用, 數(shù)據(jù), 文件三臺服務器. 應用服務器要處理大量的業(yè)務, 所以需要更快更強的CPU. 數(shù)據(jù)服務器快速磁盤檢索和數(shù)據(jù)緩存, 需要更快的硬盤和大內(nèi)存; 文件服務器用于存儲用戶的文件, 需要更大的硬盤

  1. 使用緩存改善網(wǎng)站性能

遵循2/8定律. 80%的業(yè)務訪問集中在20%的數(shù)據(jù)上.
只要緩存住了這20%的數(shù)據(jù), 就可以大大減少服務器的讀

  1. 使用應用服務器集群改善網(wǎng)站的并發(fā)處理能力

通過持續(xù)增加應用服務器的方式來改善負載壓力, 實現(xiàn)系統(tǒng)的可伸縮性.
而不是采購更強的服務器.

  1. 數(shù)據(jù)庫的讀寫分離

配置主從數(shù)據(jù)庫. 應用服務器要寫數(shù)據(jù)時, 訪問主數(shù)據(jù)庫. 主數(shù)據(jù)庫通過主從復制機制將數(shù)據(jù)更新同步到從數(shù)據(jù)庫.

  1. 使用反向代理和CDN加速網(wǎng)站響應

基本原理都是緩存. 區(qū)別在于CDN部署在網(wǎng)絡提供商機房中. 而反向代理部署在網(wǎng)站機房中.

  1. 使用分布式文件系統(tǒng)和分布式數(shù)據(jù)庫系統(tǒng)

使用分布式數(shù)據(jù)庫是數(shù)據(jù)庫拆分的最后手段. 更常使用的是業(yè)務分庫.

  1. 使用NoSQL和搜索引擎

通過一個統(tǒng)一的數(shù)據(jù)層訪問各種數(shù)據(jù), 減輕應用程序管理諸多數(shù)據(jù)庫的麻煩

  1. 業(yè)務拆分

將整個網(wǎng)站業(yè)務拆分成不同的產(chǎn)品線

  1. 分布式服務

1.3 大型網(wǎng)站架構(gòu)演化的價值觀

  1. 核心價值是隨網(wǎng)站所需靈活應對
  2. 驅(qū)動技術(shù)發(fā)展的主要力量是業(yè)務發(fā)展

1.4 網(wǎng)站架構(gòu)設計誤區(qū)

  1. 一味追求大公司的解決方案
  2. 為了技術(shù)而技術(shù)
  3. 企圖用技術(shù)解決所有問題

技術(shù)是用來解決業(yè)務問題的, 而業(yè)務問題, 也可以通過業(yè)務的手段去解決

第二章: 大型網(wǎng)站架構(gòu)模式

模式: 問題和場景的可重復帶來了解決方案的可重復性

2.1 架構(gòu)模式

  1. 分層

將系統(tǒng)在橫向緯度上切分成幾個部分, 每個部分負責一部分比較單一的職責, 然后通過上層對下層的依賴和調(diào)用組成一個完整的系統(tǒng).

分層架構(gòu)的挑戰(zhàn): 必須合理規(guī)劃層次邊界和接口, 在開發(fā)過程中, 嚴格遵循分層架構(gòu)約束, 禁止跨層次的調(diào)用以及逆向調(diào)用(如數(shù)據(jù)層調(diào)用應用層)

  1. 分割

在縱向方面對軟件進行切分. 將不同的功能和服務分割開來, 包裝成高內(nèi)聚低耦合的模塊單元.
一方面有助于軟件的開發(fā)和維護; 另一方面, 便于同步模塊的分布式部署, 提供網(wǎng)站的并發(fā)處理能力和功能擴展能力

  1. 分布式

分層和分割的一個主要目的就是為了分布式部署.

分布式會帶來以下問題:

a. 必須通過網(wǎng)絡, 對性能造成影響
b. 服務器越多, 宕機的可能性越大, 使網(wǎng)站的可用性降低
c. 在分布式環(huán)境下保證數(shù)據(jù)的一致性很困難, 分布式事務也難以保證, 對業(yè)務正確性和業(yè)務流程造成影響
d. 導致網(wǎng)站依賴復雜, 開發(fā)管理維護困難

常用的分布式:

a. 分布式用用和服務
b. 分布式靜態(tài)資源
減輕應用服務器負載; 通過獨立域名加快瀏覽器并發(fā)加載速度; 由專門用戶體驗團隊維護, 分工更加明確.
c. 分布式數(shù)據(jù)和存儲
d. 分布式計算
Hodoop和MapReduce. 特點是移動計算而不是移動數(shù)據(jù), 將計算程序分發(fā)到數(shù)據(jù)所在的位置以加速計算和分布式計算
e. 分布式配置
f. 分布式鎖
g. 分布式文件系統(tǒng)

  1. 集群

使用分布式雖然將分層和分割后的模塊獨立部署, 但對于用戶訪問集中的模塊(比如首頁), 還需要將獨立部署的服務器集群化, 即多臺服務器部署相同的應用構(gòu)成一個集群, 通過負載均衡服務器共同對外提供服務.

  1. 緩存

緩存就是將數(shù)據(jù)存放在距離計算最近的位置以加快處理速度, 緩存是改善軟件性能的第一手段

緩存的分類:

CDN: 內(nèi)容分發(fā)網(wǎng)絡
反向代理
本地緩存
分布式緩存: Redis Memcached

使用緩存的2個條件:

a. 數(shù)據(jù)訪問熱點不均衡, 將熱點數(shù)據(jù)緩存起來
b. 數(shù)據(jù)在某個時間段內(nèi)有效, 不會很快過期. 否則緩存的數(shù)據(jù)會因為失效而產(chǎn)生臟讀.

**緩存的作用: **

a. 加速數(shù)據(jù)訪問速度
b. 減輕后端應用和數(shù)據(jù)存儲應用的負載壓力, 這一點對網(wǎng)站數(shù)據(jù)庫架構(gòu)至關(guān)重要. 網(wǎng)站數(shù)據(jù)庫幾乎都是按照有緩存的前提進行負載能力設計的

  1. 異步

通過消息隊列, 將同步的操作編程異步的.

異步具有如下特性:

a. 提供系統(tǒng)的可用性
b. 加速網(wǎng)站響應速度
c. 消除并發(fā)訪問高峰

可能對用戶體驗和業(yè)務流程造成影響.

  1. 冗余
  2. 自動化

a. 發(fā)布過程自動化
b. 自動化代碼管理
c. 自動化測試
d. 自動化安全檢測
e. 自動化部署
f. 自動化監(jiān)控
g. 自動化報警
h. 自動化失效轉(zhuǎn)移: 將失效的服務器從集群中隔離除去, 不再處理系統(tǒng)中的應用請求
i. 自動化失效恢復: 重新啟動服務, 同步數(shù)據(jù)保證數(shù)據(jù)一致性
j. 自動化降級: 通過拒絕部分請求及關(guān)閉部分不重要的業(yè)務將系統(tǒng)負載降至一個安全的水平
k. 自動化分配資源: 將空閑資源分配給重要的服務, 擴大其部署規(guī)模

  1. 安全
  • 身份認證: 密碼, 手機短信
  • 登錄,交易等操作需要對網(wǎng)絡通信加密
  • 網(wǎng)站存儲的敏感數(shù)據(jù)要加密
  • 使用驗證碼防止機器人攻擊
  • 對于XSS攻擊, SQL注入進行編碼轉(zhuǎn)換
  • 對垃圾信息和敏感信息進行過濾
  • 對交易轉(zhuǎn)賬等重要操作進行風險控制

2.2 架構(gòu)模式在新浪微博中的應用

小結(jié): 好的設計絕不是模范, 不是生搬硬套某個模式, 而是對問題深刻理解之上的創(chuàng)造和創(chuàng)新
山寨和創(chuàng)新的最大區(qū)別不是是否抄襲和模范, 而在于對問題和需求是否真正理解和把握

第三章: 大型網(wǎng)站核心架構(gòu)要素

軟件架構(gòu): 有關(guān)軟件整體結(jié)構(gòu)與組件的抽象描述, 用于指導大型軟件系統(tǒng)各個方面的設計
系統(tǒng)的各個重要組成部分及其關(guān)系構(gòu)成了系統(tǒng)的架構(gòu). 這些組成部分可以是具體的功能模塊, 也可以是非功能的設計和決策, 如性能/可用性/伸縮性/擴展性/安全性, 它們相互關(guān)系組成一個整體, 共同構(gòu)成了軟件系統(tǒng)的架構(gòu)

3.1 性能

衡量性能的指標: 響應時間, TPS, 系統(tǒng)性能計數(shù)器
對于網(wǎng)站而言, 性能符合預期僅僅是必要條件, 因為無法預知網(wǎng)站可能面臨的訪問壓力, 所以必須考察系統(tǒng)在高并發(fā)情況下, 超出負載設計能力時可能出現(xiàn)的問題. 網(wǎng)站需要長時間運行, 還必須保證在持續(xù)運行且訪問壓力不均勻時保持問題的性能特征.

3.2 可用性

高可用的目標就是當服務器宕機時, 服務依然可用. 主要手段是集群, 冗余. 關(guān)鍵在于服務器中不能保存用戶會話狀態(tài).

3.3 伸縮性

定義: 通過不斷想服務器集群中添加服務器的手段來緩解不斷上漲的用戶并發(fā)訪問壓力和不斷增長的數(shù)據(jù)存儲需求

3.4 擴展性

擴展性直接關(guān)注網(wǎng)站的功能需求.

目的: 在網(wǎng)站快速發(fā)展, 功能不斷擴展時, 網(wǎng)站架構(gòu)能夠快速響應需求變化.

主要手段:

a. 事件驅(qū)動架構(gòu): 利用消息隊列實現(xiàn)
b. 分布式服務: 將業(yè)務和可復用服務分離開來, 通過分布式服務框架調(diào)用

3.5 安全性

小結(jié): 性能, 可用性, 伸縮性, 擴展性和安全性是網(wǎng)站架構(gòu)最核心的5個要素, 這幾個問題解決了, 大型網(wǎng)絡架構(gòu)設計的大部分挑戰(zhàn)也就是克服了.

第二篇: 架構(gòu)

第四章: 瞬時響應, 網(wǎng)站的高性能架構(gòu)

4.1 網(wǎng)站性能測試

1) 不同視角下的網(wǎng)站性能

  • 用戶視覺的網(wǎng)站性能

從用戶角度, 網(wǎng)站性能就是用戶在瀏覽器中直觀感受到的網(wǎng)站響應速度是快還是慢.

優(yōu)化手段:

  1. 優(yōu)化頁面HTML
  2. 利用瀏覽器端的并發(fā)和異步特性
  3. 調(diào)整瀏覽器緩存策略
  4. 使用CDN服務
  5. 反向代理
  • 開發(fā)人員視角的網(wǎng)站性能

開發(fā)人員關(guān)注: 應用程序本身及其子系統(tǒng)的性能, 包括響應延遲, 系統(tǒng)吞吐量, 并發(fā)處理能力, 系統(tǒng)穩(wěn)定性等技術(shù)指標.

優(yōu)化手段:

  1. 使用緩存加速數(shù)據(jù)讀取
  2. 使用集群提高吞吐能力
  3. 使用異步消息加快請求響應及實現(xiàn)削峰
  4. 使用代碼優(yōu)化手段改善程序性能
  • 運維人員視角的網(wǎng)站性能

運維人員更關(guān)注: 基礎設施性能和資源利用率, 如網(wǎng)絡運營商的帶寬能力, 服務器硬件的配置, 數(shù)據(jù)中心網(wǎng)絡架構(gòu), 服務器和網(wǎng)絡帶寬的資源利用率

**優(yōu)化手段: **

  1. 建設優(yōu)化骨干網(wǎng)
  2. 使用高性價比定制服務器
  3. 利用虛擬化技術(shù)優(yōu)化資源利用

2) 性能測試指標

從開發(fā)和運維視角看, 網(wǎng)站性能測試的主要指標有: 響應時間, 并發(fā)數(shù), 吞吐量, 性能計數(shù)器.

  • 響應時間

特指應用執(zhí)行一個操作需要的時間, 包括從發(fā)出請求開始到收到最后響應數(shù)據(jù)所需要的時間. 它是最重要的性能指標, 直觀反映系統(tǒng)的'快慢'.

常用系統(tǒng)操作響應時間表

| 操作 | 響應時間 |

  • 并發(fā)數(shù)
  • 吞吐量
  • 性能計數(shù)器

3) 性能測試方法

4) 性能優(yōu)化策略

4.2 Web前端性能優(yōu)化

  1. 瀏覽器訪問優(yōu)化
  2. CDN加速
  3. 反向代理

4.3 應用服務器性能優(yōu)化

  1. 分布式緩存
  2. 異步操作
  3. 使用集群
  4. 代碼優(yōu)化

4.5 存儲性能優(yōu)化

  1. 機械硬盤 vs. 固態(tài)硬盤
  2. B+樹 vs. LSM樹
  3. RAID vs. HDFS

小結(jié):

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末粟按,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子况木,更是在濱河造成了極大的恐慌壤巷,老刑警劉巖岳锁,帶你破解...
    沈念sama閱讀 206,723評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件哥牍,死亡現(xiàn)場離奇詭異谐檀,居然都是意外死亡惩歉,警方通過查閱死者的電腦和手機等脂,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,485評論 2 382
  • 文/潘曉璐 我一進店門俏蛮,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人上遥,你說我怎么就攤上這事搏屑。” “怎么了粉楚?”我有些...
    開封第一講書人閱讀 152,998評論 0 344
  • 文/不壞的土叔 我叫張陵辣恋,是天一觀的道長。 經(jīng)常有香客問我解幼,道長抑党,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 55,323評論 1 279
  • 正文 為了忘掉前任撵摆,我火速辦了婚禮底靠,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘特铝。我一直安慰自己暑中,他們只是感情好,可當我...
    茶點故事閱讀 64,355評論 5 374
  • 文/花漫 我一把揭開白布鲫剿。 她就那樣靜靜地躺著鳄逾,像睡著了一般。 火紅的嫁衣襯著肌膚如雪灵莲。 梳的紋絲不亂的頭發(fā)上雕凹,一...
    開封第一講書人閱讀 49,079評論 1 285
  • 那天,我揣著相機與錄音政冻,去河邊找鬼枚抵。 笑死,一個胖子當著我的面吹牛明场,可吹牛的內(nèi)容都是我干的汽摹。 我是一名探鬼主播,決...
    沈念sama閱讀 38,389評論 3 400
  • 文/蒼蘭香墨 我猛地睜開眼苦锨,長吁一口氣:“原來是場噩夢啊……” “哼逼泣!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起舟舒,我...
    開封第一講書人閱讀 37,019評論 0 259
  • 序言:老撾萬榮一對情侶失蹤拉庶,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后魏蔗,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體砍的,經(jīng)...
    沈念sama閱讀 43,519評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 35,971評論 2 325
  • 正文 我和宋清朗相戀三年莺治,在試婚紗的時候發(fā)現(xiàn)自己被綠了廓鞠。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片帚稠。...
    茶點故事閱讀 38,100評論 1 333
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖床佳,靈堂內(nèi)的尸體忽然破棺而出滋早,到底是詐尸還是另有隱情,我是刑警寧澤砌们,帶...
    沈念sama閱讀 33,738評論 4 324
  • 正文 年R本政府宣布杆麸,位于F島的核電站,受9級特大地震影響浪感,放射性物質(zhì)發(fā)生泄漏昔头。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 39,293評論 3 307
  • 文/蒙蒙 一影兽、第九天 我趴在偏房一處隱蔽的房頂上張望揭斧。 院中可真熱鬧,春花似錦峻堰、人聲如沸讹开。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,289評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽旦万。三九已至,卻和暖如春镶蹋,著一層夾襖步出監(jiān)牢的瞬間成艘,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 31,517評論 1 262
  • 我被黑心中介騙來泰國打工贺归, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留狰腌,地道東北人。 一個月前我還...
    沈念sama閱讀 45,547評論 2 354
  • 正文 我出身青樓牧氮,卻偏偏與公主長得像,于是被迫代替她去往敵國和親瑰枫。 傳聞我的和親對象是個殘疾皇子踱葛,可洞房花燭夜當晚...
    茶點故事閱讀 42,834評論 2 345

推薦閱讀更多精彩內(nèi)容