大型網站架構演化
目錄
大型網站特點
- 高並發，大流量
- 高可用，系統不間斷服務
- 海量數據，數據量大，需要存儲海量數據
- 用戶分布廣泛，用戶分布在五湖四海
- 安全環境惡劣，容易受到受到攻擊
- 需求變更塊，發布頻繁
- 漸進式發張，從小型網站慢慢發展為大型系統
大型網站的技術挑戰
- 高並發訪問
- 海量的數據
演化發展
- 一台服務器就足夠，程序，數據庫和文件都在一台服務器上
- 使用三台服務器，不同特性的服務器負責不同的功能。程序，數據庫和文件分離，應用程序處理大量業務，需要強大的cpu，數據庫需要快速檢索和緩存，需要更快的硬盤和更大的內存，文件則要更大的硬盤
- 用戶量大以后，數據庫訪問壓力大，所以采用需要采用緩存，由於應用服務器的內存有限，所以采用大內存的緩存服務器
- 用戶量增大，一台應用服務器壓力大，采用集群的方式來實現負載均衡
- 緩存不命中的時候，數據庫的壓力增大，配置主從服務器，主數據庫用於寫數據，然后同步到從數據庫，讀的時候讀取從數據庫，實現讀寫分離，從而改善數據庫負載壓力
- 采用CDN加速，將數據部署在網絡提供商的機房，使用戶在請求網站服務的時候，可以從距離自己最近的網絡提供商機房獲得數據。
- 通過反向代理加速，當請求到達網站中心機房時候，先到達代理服務器，如果緩存命中的話，直接返回給用戶，這樣的話提高了訪問速度，同時也降低了服務器的負載壓力
- 一台服務器滿足不了業務需求的增長，采用分布式文件系統和分布式數據庫系統
- 進行業務拆分，業務日益復雜，將整個業務分成不同的產品線，給不同的業務團隊負責
價值觀
- 網站的價值在於能給用戶提供什么價值，而不是他是怎么做的
- 大型網站都是從小型網站一步步發展起來的，小型網站的時候，不要盲目去追求架構，而是首要去為業務創造價值
- 是業務對架構提出要求，是業務促進技術的發展，是業務成就技術，所以，要對業務懷有感恩之心
網站架構設計誤區
- 不要盲從別人的經驗，堅持自我
- 不要為了技術而技術，技術是為業務服務的，關鍵是實現價值，不要以為最求時尚的技術
- 技術可以解決業務問題，但也可以通過業務的手段去解決
總結
- 隨着用戶的量的增加，業務的增多，數據量的增大，單機服務器滿足不了需求，所以，架構慢慢進行演化
- 不要盲目最求新技術，關鍵是實現價值。是業務的需求促進技術的發展，對業務要有感恩之心。
大型網站架構要素
性能
提高手段
- 瀏覽器緩存，頁面壓縮，減少cookie傳輸
- cdn加速
- 反向代理
- 服務器本地緩存或者分布式緩存
- 異步操作將用戶請求發送至消息隊列等待后續任務處理
- 數據庫添加索引，優化sql，緩存
可用性
衡量標准
- 扣除故障的時間，網站的總可用時間
提高手段
- 應用部署到多台服務器上同時提供訪問，多台應用服務器通過負載均衡設備組成一個集群對外提供服務，任何一台服務器宕機，將請求切換到其他服務器
- 對於存儲存儲數據庫，對數據進行實時備份
伸縮性
衡量標准
- 是否可以用多台服務器構建集群
- 是否容易向集群添加新的服務器
- 加入新的服務器后是否提供與原來無差別的服務
擴展性
衡量標准
- 為網站添加新的業務產品時，是否可以實現對現有產品透明無影響
- 不需要改動現有業務功能就能上線新的產品
- 一個產品改動對其他產品無影響
安全性
衡量標准
- 對現有的和潛在的各種攻擊手段和竊密手段是否有可靠的應對策略
總結
- 大型網站要素：性能，可用性，伸縮性，擴展性，安全性。
網站的高性能架構
不同人員眼中的性能
用戶角度的性能
- 對於用戶來說，直觀的就是用戶感受的網站響應的速度，也就訪問后到響應到瀏覽器的時間。而這段時間實際上包括計算機和服務器的時間服務器的處理時間，瀏覽器接受響應數據后渲染到頁面的時間
開發人員角度的性能
- 響應延遲
- 系統吞吐量
- 並發處理能力
- 系統穩定性
運維人員角度的性能
- 基礎設施性能和資源利用率，比如服務器硬件，網絡運營商的帶寬能力，服務器和網絡帶寬的資源的利用率
性能測試指標
響應時間
- 指一個操作從發出請求到響應數據需要的時間
- 打開一個網站
- 從數據庫查找記錄
- 從磁盤讀取數據
並發數
- 對於網站而言，並發數就是並發用戶數，也就是同時提交請求的用戶數目
- 系統用戶數(注冊用戶數)>在線用戶（登錄用戶數）>並發用戶數（同時提交請求的用戶數）
吞吐量
- 單位時間內系統處理的請求數量
性能計數器
- 系統負載，當前正在被cpu執行和等待被cpu執行的進程數目的總和
- 對象與線程數
- 內存使用
- cpu使用
- 磁盤和網絡IO
性能測試方法
性能測試
- 以預期規划的性能指標為預期目標，對系統不斷施加壓力，驗證系統在資源可接受范圍內，是否能達到性能預期
負載測試
- 對系統不斷地增加並發請求以增加系統壓力，直到系統的某項或多項性能指標達到安全臨界值
壓力測試
- 超過安全負載的情況下，對系統繼續施加壓力，直到系統崩潰，從而獲得最大承受壓力
穩定性測試
- 給系統加載一定業務壓力，使系統運行一段較長時間，來檢測系統是否穩定
性能分析
- 對請求經歷的各個環節進行分析，檢查請求處理的各個環節的日志，分析哪個環節響應時間不合理，然后檢查監控數據，分析影響性能的因素（內存，磁盤，網絡，cpu，代碼等），排查可能出現性能瓶頸的地方。
性能優化
- 前端優化
- 應用服務器優化
- 存儲服務器優化
前端優化
減少http請求
- http每次請求都需要建立通信鏈路，進行數據傳輸。對於每個請求，服務端需要創建線程去處理。
- 合並css，js，圖片。將瀏覽器一次訪問需要的css，js，資源合並成一個文件，這樣就可以只用一個請求，減少創造鏈路和服務端服務的開銷
使用瀏覽器緩存
- 靜態資源（css，js，圖標）更新頻率比較低，可以選擇將他緩存在服務器
啟用壓縮
- 服務端對文件進行壓縮，減少傳輸的數據的數據量，然后瀏覽器再進行解壓
css和js的順序
- 瀏覽器加載完所有css才會進行渲染
- 瀏覽器加載js后立即執行。
- 如果不將js放在底部，那么可能會在執行js的時候阻塞，造成頁面顯示緩慢。所以css可以放在最上面，js放在最下面
減少cookie傳輸
- 太大的Cookie會影響數據傳輸
- 寫入cookie的數據要慎重考慮，盡量減少Cookie的數據量
- 請求靜態資源發送Cookie是無意義的，服務器並不會對Cookie進行處理，這樣會消耗帶寬。所以靜態資源可以用獨立域名訪問。
CDN加速
- 所謂CDN實現的就是將資源放在離用戶最近的地方，是用戶快速獲取數據
- CDN可以緩存靜態資源
反向代理
- 反向代理服務器配置緩存功能加速請求，當用戶請求靜態資源的時候，直接從反向代理服務器返回
應用服務器性能優化
分布式緩存
異步操作
- 使用消息隊列將調用異步化
- 在不使用消息隊列的時候，用戶的請求數據直接寫入數據庫，高並發情況下，會給數據庫服務器造成巨大的壓力。使用消息隊列后，用戶請求的數據發送給消息隊列后直接返回。消費者進程從消息隊列讀取數據，異步寫入數據庫
使用集群
- 構建服務器集群，將並發請求分發到多台服務器
代碼優化
- 合理設置線程，IO密集型，線程數最多不超過cpu核心數，IO密集型，多啟動線程充分利用cpu資源
- 對象池技術和單例模式，減少開銷很大的系統資源的創建和銷毀
- 不同場景使用合適的數據結構
- 垃圾回收對系統的性能產生巨大的影響，配置合適的參數進行調優
總結
- 不同人員的角度對性能的衡量標准不同的。
- 性能測試指標：響應時間，並發數，吞吐量，性能計數器
- 性能測試方法：性能測試，負載測試，壓力測試，穩定性測試
- 性能優化的方法：前端優化，服務端優化，代碼優化，硬件優化
我覺得分享是一種精神，分享是我的樂趣所在，不是說我覺得我講得一定是對的，我講得可能很多是不對的，但是我希望我講的東西是我人生的體驗和思考，是給很多人反思，也許給你一秒鍾、半秒鍾，哪怕說一句話有點道理，引發自己內心的感觸，這就是我最大的價值。（這是我喜歡的一句話，也是我寫博客的初衷）
作者：jiajun 出處： http://www.cnblogs.com/-new/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。如果覺得還有幫助的話，可以點一下右下角的【推薦】，希望能夠持續的為大家帶來好的技術文章！想跟我一起進步么？那就【關注】我吧。