架構系列(一)---大型網站架構演化，要素及性能

大型網站架構演化

目錄

• 這是個人博客目錄，歡迎閱讀

大型網站特色

• 高併發，大流量
• 高可用，系統不間斷服務
• 海量數據，數據量大，須要存儲海量數據
• 用戶分佈普遍，用戶分佈在五湖四海
• 安全環境惡劣，容易受到受到攻擊
• 需求變動塊，發佈頻繁
• 漸進式發張，從小型網站慢慢發展爲大型系統

大型網站的技術挑戰

• 高併發訪問
• 海量的數據

演化發展

• 一臺服務器就足夠，程序，數據庫和文件都在一臺服務器上
• 使用三臺服務器，不一樣特性的服務器負責不一樣的功能。程序，數據庫和文件分離，應用程序處理大量業務，須要強大的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/
本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。若是以爲還有幫助的話，能夠點一下右下角的【推薦】，但願可以持續的爲你們帶來好的技術文章！想跟我一塊兒進步麼？那就【關注】我吧。