《大型網站技術架構 核心原理與案例分析》讀書筆記

1、大型網站架構演化

一、大型網站特色

• 高併發，大流量
• 高可用
• 海量數據
• 用戶分佈普遍，網絡狀況複雜
• 安全環境惡劣
• 需求快速變動，發佈頻繁
• 漸進式發展

二、大型網站架構發展歷程

• 文件服務器，數據庫服務器，應用服務器分離
• 應用服務器增長本地緩存，本地緩存優先，增長分佈式緩存服務器
• 使用應用程序服務器集羣提升網站的併發，由負載均衡服務器統一調度分發
• 使用分佈式文件系統和分佈式數據庫系統
• 使用CDN網絡加速和反向代理服務器：基本原理都是緩存，CDN部署在網絡提供商的機房，是用戶在請求網絡服務時，能夠從距離本身最近的網絡提供商機房獲取數據。而反向代理是部署在中心機房，當用戶的請求到達中心機房後，首先訪問的是反向代理服務器，若是反向代理服務器中緩存這用戶請求的資源，就將其直接返回給用戶，目的都是儘早返回數據給用戶，加快用戶訪問速度，減輕後端服務器的壓力。
• 使用Nosql和搜索服務器
• 業務拆分，根據不一樣的產品，不一樣的業務，將一個網站拆分紅不一樣的應用，每一個應用獨立部署維護，各個應用之間經過消息中間件或者訪問同一個數據存儲系統來構成一個相互關聯的完整系統
• 分佈式服務，將公用的業務提取出來，獨立部署，爲其餘應用服務器提供可複用的共用業務服務（能夠經過dubbo和zookeeper集羣實現）

三、網站架構的價值觀和設計誤區

• 架構的選取隨網站所需靈活應對
• 主要驅動力量是網站的業務發展
• 不可一味追隨大公司的架構設計，照搬照抄
• 網站技術是爲了業務存在的，不可爲了技術而技術
• 不要企圖使用技術解決一切問題。技術是用來解決業務問題的，一樣業務問題也能夠採用業務手段，經過修改業務架構來解決

2、大型網站架構模式

一、分層

將系統在橫向緯度上分紅幾個部分，每一個部分負責單一職責，經過上層對下層的依賴和調用組成一個完整的系統。網絡的7層通信協議，計算機硬件、操做系統、應用軟件，都採用了分層的思想。將網站系統分爲應用層、服務層、數據層，三層結構分別部署在不一樣的服務器上

• 應用層：負責具體業務和視圖展現
• 服務層：爲應用層提供服務支持，如用戶管理服務、購物車服務
• 數據層：提供數據存儲訪問服務，如數據庫、緩存、文件、搜索引擎等

二、分割

在縱向方面對系統進行劃分，好比應用層，能夠將不一樣業務分割，將購物、論壇、搜索、廣告分割成不一樣的應用，由獨立的團隊負責。部署在不一樣的服務器上。

三、分佈式

分層和分割的目的就是爲了切分後的模塊便於分佈式部署，將不一樣的模塊部署在不一樣的服務器上。同時，分佈式也帶來了不少問題，

• 不一樣服務器之間的通訊對網絡依賴很大
• 保持數據一致性比較困難
• 網站依賴錯綜複雜，開發維護困難

    常見的分佈式方案有如下幾種

• 分佈式應用和服務。
• 分佈式靜態資源
• 分佈式數據和存儲
• 分佈式計算
• 分佈式文件系統
• 分佈式鎖
• 分佈式配置。支持網站線上服務配置實時更新

四、集羣

雖然分佈式已經將各個應用分開部署，可是對於用戶集中訪問的模塊，還須要獨立部署服務器集羣化，即多臺服務器部署相同應用構成一個集羣，經過負載均衡設備共同對外提供服務。而且支持線性擴展，發生故障時的失效轉移。即便是訪問量很小的分佈式應用和服務也至少要部署兩臺構成小的集羣，提升系統的可用性

五、緩存

緩存是改善軟件性能的第一手段。大型網站不少方面都使用了緩存設計：

• CDN，即內容分發網絡。在這裏緩存網站的一下靜態資源（較少變化的數據），能夠就近以最快速度返回給用戶。如視頻網站和門戶網站會將用戶訪問量大的熱點內容緩存在CDN
• 反向代理。當用戶的請求到達數據中心時，最早訪問到的是反向代理服務器，這裏緩存網站的靜態資源，無需繼續將請求轉發給應用服務器，直接返回給用戶
• 本地緩存。在應用服務器本地緩存這熱點數據，應用程序能夠在本地內存中直接訪問，無需訪問數據層
• 分佈式緩存。將數據存儲在專門的分佈式緩存集羣中，應用服務器經過網絡通信訪問緩存數據。

      緩存同時也存在着緩存擊穿、緩存雪崩、緩存熱點不集中的問題

六、異步

在單一服務器內部可經過多線程共享內存隊列的方式實現異步，在分佈式系統中，多個服務器集羣經過分佈式消息隊列實現異步。異步架構是典型的生產者-消費者模式。使用異步消息隊列可以帶來以下好處：

• 提升系統可用性
• 提升系統響應速度
• 消除併發訪問高峯。消息隊列可以把忽然增長的訪問請求數據放入到隊列中，等待消費者處理，不會對網站形成太大壓力

七、冗餘

爲了提升系統的可用性，防止某些服務器宕機的狀況下系統依然能夠繼續服務，須要必定的服務器冗餘運行、數據冗餘備份。數據庫除了按期備份實現冷備份以外，還須要主從分離，實時同步實現熱備份。爲了抵禦海嘯、地震等不可抗力，還須要在全球範圍內部署災備數據中心。

八、自動化

發佈過程自動化：自動化代碼管理，自動化測試，自動化安全測試，自動化部署。系統運行過程當中還有：自動化監控、自動化報警、自動化失效轉移、自動化失效恢復、自動化降級、自動化資源分配。

九、架構模式在新浪微博的應用

新浪微博系統分爲三層：

• 最下層是基礎服務層，提供數據庫、緩存、搜索、存儲等基礎服務
• 中間層是平臺服務和應用服務層，微博的核心是微博、用戶、關係，這些服務被分割成獨立的模塊，經過依賴調用和對共享基礎服務構成微博的業務基礎
• API層，是微博的業務層，包括網站、app、第三方應用，經過調用API集成到微博系統中，共同組成一個生態系統

微博的發佈，早起使用同步推模式，用戶發表微博後會當即將這條微博插入到數據庫全部粉絲的訂閱列表中，用戶量比較大時，會引發大量的數據庫寫操做，超出負載，致使系統性能降低。後來改用異步推拉方式，用戶發表微博以後馬上寫到消息隊列中而後馬上返回，消息隊列消費者將微博推送給當前在線粉絲的訂閱列表中，非在線用戶等登陸後在根據關注列表拉取微博訂閱列表

因爲微博頻繁刷新，微博使用多級緩存策略，熱門微博和明星微博緩存在全部的微博服務器上，在線用戶的微博和近期微博緩存在分佈式緩存集羣中

3、大型網站核心結構要素

一、性能。系統吞吐量幾個重要參數：QPS（TPS）、併發數、響應時間

        QPS（TPS）：每秒鐘request/事務 數量

        併發數： 系統同時處理的request/事務數

        響應時間：  通常取平均響應時間

        QPS（TPS）= 併發數/平均響應時間

二、高可用

指的是網站能夠保證大部分時間系統都是可用的，一些知名大型網站能夠獲得99.99%的時間都是可用的。高可用的設計目標是當有部分服務器宕機時，總體的服務或者應用依然可用。

• 保證網站高可用的主要手段就是冗餘，應用部署在多臺服務器上同時提供訪問，數據存儲在多個服務器上互相備份，任何一臺服務器宕機都不會影響應用的總體可用。
• 網站的高可用還須要軟件開發過程的質量保證，經過預發佈驗證、自動化測試、自動化發佈、灰度發佈等手段，減小將故障引入線上環境的可能。

三、伸縮性

衡量的主要指標就是是否能夠用多臺服務構架集羣，是否容易向集羣中添加新的服務器，加入的新的服務器是否能夠提供和原來服務器無差異的服務，集羣可容納的總服務器數量是否有限制。

• 應用服務器，經過使用合適的負載均衡設備，就能夠向集羣中不斷加入服務器
• 緩存服務器集羣，加入新的服務器可能會致使緩存路由失效，若是對緩存的依賴嚴重，可能會致使系統崩潰。
• 關係數據庫。雖然支持主從複製，主從熱備，可是很難作到大規模集羣的可伸縮性。所以關係型數據庫的可伸縮性方案必須在數據庫以外實現，經過路由分區等手段，將多個部署的數據庫服務器集成一個集羣。
• NoSql數據庫。因爲其先天就是爲了海量數據而生的，所以對可伸縮性的支持很是好。

四、擴展性

衡量的主要標準就是網站增長新的業務產品時，是否會對現有產品產生影響，不須要改動或不多改動既有業務就能夠上線新產品，不一樣產品之間不多的耦合，一個產品改動對其餘產品沒有影響。

網站的可擴展架構的主要手段是事件驅動架構和分佈式服務

• 事件驅動，一般利用消息隊列實現，把消息的生產者和消費者分開，這樣能夠透明的增長新的生產者和消費者
• 分佈式服務則是將業務和可複用服務拆分開，經過分佈式服務調用可複用服務。可複用服務升級變動的時候，也能夠經過提供多版本服務實現透明升級，不須要強制應用同步變動。

五、安全性

網站的安全架構須要保證網站不受惡意訪問和攻擊、保護網站的重要數據不被竊取。

 4、網站的高性能架構

一、網站性能測試

性能測試指標。主要指標有響應時間、併發數、吞吐量、性能計數器

        

二、Web前端性能優化

瀏覽器訪問優化

• 減小http請求。合併css、JavaScript、圖片，將瀏覽器一次訪問須要的資源合併成一個文件
• 使用瀏覽器緩存。經過設置http頭部中的Cache-Control和Expires屬性，設置瀏覽器緩存。將css、javascript、圖片等靜態資源經過瀏覽器緩存起來，若是須要靜態資源及時應用到客戶端瀏覽器，可經過改變文件名實現。
• 啓用壓縮。在服務端對文件進行壓縮，在瀏覽器端對文件進行解壓縮，有效減小通信傳輸的數據量，會對服務器和瀏覽器產生必定的壓力，通訊寬帶良好，服務器資源不足的狀況下，不適合採用
• 減小cookie傳輸，cookie包含在每次請求和響應中，太大的cookie會影響數據傳輸。深刻了解，cookie和session的區別

CDN加速

CDN，內容分發網絡，本質上也是緩存，並且將緩存在裏用戶最近的地方。部署在網絡運行商的機房，CDN緩存的是一些靜態資源

反向代理

• 反向代理服務器位於網站機房一側，代理網站web服務器接受http請求。具備保護網站安全的做用
• 代理服務器能夠經過配置緩存功能加速web請求，當用戶第一次請求靜態內容的時候，就被緩存在反向代理服務器上
• 也能夠實現負載均衡的功能

三、應用服務器性能優化

分佈式緩存

• 合理使用緩存，頻繁修改的數據不適合緩存，讀寫比在2:1之上，緩存纔有意義
• 沒有熱點訪問的數據，不適合作緩存
• 數據不一致，數據庫修改了數據並不會當即修改緩存，存在時間差
• 分佈式緩存服務器，提升緩存的可用性
• 緩存預熱，啓動時就把熱點數據放入緩存中。熱點數據是利用LRU（最近最久未用算法）對不斷訪問的數據篩選淘汰出來的
• 緩存穿透，大量請求不存在的數據，繞過緩存直達數據庫。一個簡單的策略：將不存在的數據也緩存起來
• 分佈式緩存架構：一種是須要同步更新的分佈式緩存，規模較大時，緩存更新數據須要同步到全部緩存服務器，代價驚人。另外一種是以memcache爲表明的互不通訊的分佈式緩存架構，應用程序經過一致性hash等路由算法選擇緩存服務器遠程訪問緩存數據，緩存服務器之間不通訊，集羣規模能夠很容易的擴容，具備良好的可伸縮性。

異步操做，能夠晚點作的事情都應該晚點作

使用集羣

代碼優化

• 多線程充分利用多CPU和解決IO阻塞問題，利用多線程IO阻塞與執行充分利用CPU資源。同時須要解決線程安全問題，將對象設計成無狀態對象，使用局部變量，在修改共同資源時加鎖
• 資源複用。儘可能複用開銷很大的資源，好比數據庫鏈接、線程、複雜對象
• 優化數據結構，好比hash表，要儘可能減小hash衝突，hashcode越散列，衝突越少，讀寫性能也就越好，目前比較好的字符串Hash散列算法有Time33算法和指紋加密算法md5結合使用。先對字符串指紋加密，對加密後的字符串進行Time33。
• 垃圾回收，JVM調優，儘可能減小Full GC ，甚至從不進行Full GC

四、存儲性能優化

SSD固態硬盤vs機械硬盤

• 機械硬盤，每次訪問數據，都須要移動磁頭臂，順序訪問和隨機訪問性能差異很大
• SSD固態硬盤，沒有機械裝置，數據存儲在可持久記憶的硅晶體上，能夠像內存同樣隨機訪問

B+樹vs LSM樹

爲了改善數據訪問特性，文件系統和數據庫系統會對數據排序後存儲，加快數據檢索速度，須要保證新的數據插入、更新、刪除後依然有序。

• 傳統關係型數據庫一般採用B+樹
• 目前許多NoSQL產品採用LSM樹最爲主要數據結構，能夠看作是一個n階合併樹

5、網站的高可用架構

一、高可用的應用層服務

• 負載均衡服務器經過心跳檢測機制發現故障服務器失去響應，就會把它從服務器列表中剔除，而將請求發送到其餘服務器上。
• 服務器集羣的session管理，分佈式緩存服務器，負載均衡服務器經過hash算法老是未來源於同一ip的請求分發到同一臺服務器上

二、高可用的基礎公共服務

使用相似負載均衡的失效轉移策略實現高可用的基礎服務，此外，還有幾點基於實踐的高可用基礎服務的策略：

• 分級管理。把基礎服務分爲核心服務和非核心服務，低級別的服務須要部署在不一樣的虛擬機上進行隔離，高優先級的服務須要部署在不一樣的物理機上進行隔離、而核心服務和數據甚至要部署在不一樣地域的數據中心進行隔離
• 超時設置。
• 異步調用。應用對服務的調用經過消息隊列等異步方式完成
• 服務降級。在網站訪問的高峯期，系統壓力增大，性能降低，嚴重會致使系統宕機。爲了核心應用正常運轉，須要對服務進行降級。有兩種方式：1 是拒絕低優先級應用的調用或者隨機拒絕部分請求調用。2 是關閉不重要的服務，好比雙十一最繁忙時段關閉「評價、確認收貨」等功能
• 冪等性設計。重複調用和調用一次產生的效果相同，即服務具備冪等性

三、高可用的數據服務

保證數據高可用的主要手段是數據備份和失效轉移機制。

• 經過強化CAP理論中的A（可用性）、P（分區容錯性，跨網絡分區的伸縮性），而在某種程度上放棄C（一致性）。根據BASE理論，保證最終一致性，和用戶一致性。
• 數據備份分爲冷備、異步熱備、同步熱備。異步熱備下，存儲服務器分爲主和從，寫入操做在主服務操做成功以後當即返回成功，而後經過異步線程同步到從服務。同步熱備，等待全部存儲服務寫入成功以後，再通知應用程序寫操做成功。
• 失效轉移由三部分組成。失效確認、訪問轉移、數據恢復。失效確認經過心跳檢測或應用程序失敗報告完成

四、高可用的軟件質量保障

• 網站發佈，發佈過程當中每次關閉的都是集羣中的一小部分，並保證發佈完成後當即能夠訪問。具體過程：先關閉負載均衡服務器上的一下部分服務器路由，關閉這些服務器，部署新的代碼，啓動這些服務，打開負載均衡的路由，重複操做直到集羣中全部的機器發佈完成。
• 自動化測試，自動化測試工具ThoughtWorks開發的Selenium，運行在瀏覽器中，模擬用戶操做進行測試。
• 預發佈驗證，預發佈機器是位於負載均衡路由以外的機器。一旦啓動時發現錯誤，馬上失敗拋出異常，中止啓動讓工程師介入排查錯誤，而不是啓動後執行錯誤的操做。須要快速失敗機制
• 代碼版本控制。
• 自動化發佈。火車發佈模型來實現自動化發佈
• 灰度發佈。天天只上線一小部分服務器，一旦發現有問題，回滾一小部分服務便可，不須要回滾全部服務

五、網站運行監控

監控數據採集

• 用戶行爲日誌採集，分爲服務端日誌採集和客戶端瀏覽器日誌採集
• 服務器性能監控，開源性能監控工具Ganglia，支持大規模服務器集羣，支持以圖形的方式在瀏覽器展現實時的性能曲線
• 運行數據報告

監控管理

• 系統報警
• 失效轉移
• 自動優雅降級

6、網站的伸縮性架構

 一、網站的伸縮性設計經過如下兩種方式實現

• 根據功能從橫向和縱向進行物理分離實現伸縮
• 分離以後的單一功能經過集羣實現伸縮，集羣內多臺服務器部署相同應用，提供相同的功能

二、應用服務器的伸縮性設計

• 負載均衡服務器實現http請求的分發
• http重定向負載均衡，這種方式比較簡單，可是一次用戶請求須要請求兩次服務器，重定向服務器自身的處理能力可能成爲瓶頸，實踐中這種方案不經常使用
• DNS域名解析負載均衡，控制權在域名服務商那裏，沒法提供更強大的管理。DNS是多級解析，修改以後較長時間才能生效。實踐中，利用域名解析做爲第一級負載均衡手段，即域名解析獲得的是一組負載均衡服務器的ip地址
• 反向代理負載均衡，反向代理服務器轉發請求在http協議層面，叫作應用層負載均衡，方向代理服務器的性能有可能會成爲瓶頸
• 數據鏈路層負載均衡，指在通信協議的數據鏈路層修改修改mac地址進行負載均衡。分發過程當中不修改ip地址，只修改目的mac地址，經過配置真實物理機集羣全部機器虛擬ip和負載均衡服務器ip相同，真實處理用戶請求的服務器可直接將數據返回給用戶瀏覽器，避免負載均衡服務器網卡帶寬成爲瓶頸。目前linux平臺最好的數據鏈路層負載均衡產品是LVS（Linux  Virtual Server）
• 負載均衡算法。輪詢（Round Robin）、加權輪詢、隨機（Random）、最少鏈接（Least Connections）、原地址散列（Source Hashing）

三、分佈式緩存的伸縮性設計

Memcached分佈式緩存集羣，一致性hash算法來保證新緩存服務器加入集羣后不會影響集羣的穩定性

四、數據存儲服務器的負載均衡

• 關係型數據庫的伸縮性設計。經過數據複製主從分離，根據不一樣的業務分割數據分庫，若是及時這樣單張表仍是很大，就須要進行單表分片。目前支持數據分片的關係型數據庫產品主要有Amoeba和Cobar
• Cobar服務器集羣的伸縮：是無狀態的服務器，能夠經過簡單的負載均衡的手段實現
• Mysql服務器集羣的伸縮：集羣中添加新服務器，須要利用一致性hash算法，進行儘可能少的數據移動來保證擴容後數據一致，Mysql數據同步以Schema爲單位，使用Mysql的同步機制。不支持join操做
• Nosql數據庫的伸縮性設計。應用最普遍的Apache的Hbase

7、網站的可擴展架構

一、用分佈式消息隊列下降系統耦合性

二、利用分佈式服務打造可複用的業務平臺。分佈式服務架構須要支持以下特色：

• 負載均衡。對於熱門服務，須要部署在一個集羣上，負載均衡
• 失效轉移
• 高效的遠程通訊
• 整合異構系統，整合不一樣的語言，不一樣的平臺
• 版本管理，須要支持服務多版本發佈，服務發佈者先升級接口發佈新版本的服務，同時提供舊版本服務供請求者調用
• 實時監控

三、分佈式服務架構框架設計。經常使用的Dubbo，他的遠程通訊模塊支持多種通信協議和數據序列化協議，使用NIO通信框架，具備較高的網絡通信性能。

四、可擴展的數據結構

傳統的關係型數據庫設計之初，須要指定表的字段、數據類型等，比較僵硬，不利於之後的擴展。雖然能夠經過預設冗餘字段來解決，可是也是一種較糟糕的設計。

許多Nosql數據庫使用的ColoumFamily（列族）設計就是一個解決方案，無需指定字段，能夠在數據寫入時再指定，經過這種方式，數據表能夠包括數百萬的字段

五、利用開放平臺建設網站生態圈

8、網站的安全架構

一、攻擊與防護

• xss攻擊，跨站點腳本攻擊，經過篡改網頁，注入惡意的html腳本，在用戶瀏覽網頁時，控制用戶瀏覽器進行惡意操做的一種攻擊行爲。XSS攻擊者通常都是經過在請求中嵌入惡意腳本達到攻擊的目的，須要對請求進行過濾和消毒處理。
• sql注入攻擊，經過在http請求中嵌入惡意sql命令，經過正則匹配對請求參數進行消毒處理

二、信息加密技術

• 單向散列加密，md五、sha等。經過對明文和salt利用單向散列加密算法得出密文，數據庫中存儲加密以後的密文。輸入的微小變化都會致使輸出的徹底不一樣
• 對稱加密。加密和解密使用同一個祕鑰，使用場合有通訊加密、cookie加密。經常使用算法有DES算法、RC算法
• 非對稱加密。加密和解密使用的不是用一個祕鑰，一個是公鑰，一個是私鑰。使用場合有信息安全傳輸、數字簽名等場合。經常使用算法有RSA算法，https傳輸中瀏覽器使用的數字證書實質上就是非對稱加密公鑰。

9、10、十一皆爲案例分析，此處略

12、秒殺系統架構設計

一、應對策略

• 秒殺系統獨立部署
• 秒殺商品頁面靜態化
• 租借秒殺活動網絡寬帶

二、秒殺系統架構設計

控制秒殺按鈕的點亮

十3、大型網站典型故障案例分析，內容略

十4、架構師領導藝術

一、關注人而不是產品

必定要堅信：一羣優秀的人作一件他們熱愛的事，必定能取得成功。

領導的真諦：尋找一個值得共同奮鬥的目標，營造一個讓你們都能最大限度發揮自我價值的工做氛圍。

沒有懶惰的員工，只有沒被激發出來的激情。全部強迫員工加班的管理者都應該爲本身的無能感到羞愧。

二、發掘人的優秀

是事情成就了人，而不是人成就了事。

發掘人的優秀比發掘優秀的人更有意義。

三、共享美好藍圖

架構師要和項目組全體成員共同描繪一個藍圖，這個藍圖是真個團隊可以認同的，是團隊共同奮鬥的目標。這個藍圖應該是表述清楚的、形象的、簡單的。

四、共同參與架構

不要只有架構師一人擁有架構，讓其餘人蔘與架構的設計和維護

五、學會妥協

不要企圖在項目中證實本身是正確的，必定要記住，你是來作軟件的，不是來作老大的。架構師越早被項目組遺忘，越表示架構很是成功；項目組越離不開架構師，越表示架構還有不少缺陷。

六、成就他人

想要成就本身，先要成就他人

十5、網站架構師職場攻略

一、發現問題，尋找突破

所謂問題，就是體驗不能知足指望，就會以爲出了問題。消除問題有兩個方法：下降指望、改善體驗

二、提出問題，尋求支持

• 把「個人問題」變成「咱們的問題」
• 給上司提封閉式問題，給下屬提開放式問題
• 指出問題，而不是批評人
• 用贊同的方式提出問題

三、解決問題，達成績效