大型網站技術架構—架構要素和高性能架構

爲了使網站的可以應對高併發訪問，海量數據處理，高可靠運行等一系列問題，咱們能夠選擇橫向或縱向兩個方向來入手

基本思路

首先能夠對整個架構進行分層，通常能夠分爲 應用層，服務層，數據層；實踐中，大的分層結構中還能夠繼續分層，好比 應用層還能夠繼續分爲 視圖層 和 業務邏輯層，服務層也能夠繼續細分爲 數據接口層 邏輯處理層 等

經過分層，咱們把一個龐大的系統切分爲不一樣的部分，便於分工開發和維護；各層之間相互有必定的獨立性，在網站的開發中能夠根據不一樣的需求進行相應的調整

邏輯上分層以後，在物理部署上也能夠根據需求制定不一樣的策略，剛開始能夠部署在同一臺物理機上，可是隨着業務的發展，必然要對不一樣的模塊進行分離部署

分層架構不只僅是爲了規劃軟件的邏輯結構以便於開發維護，隨着網站的發展，分層架構對網站的高併發分佈式架構來講尤其重要

進行了分層之後，接下來能夠從縱向進行業務分割

根據不一樣的業務模塊一個項目劃分紅不一樣的模塊交給單獨的團隊去開發部署，完成後分別部署在不一樣的服務器上，經過連接進行互聯

再根據不一樣狀況來對不一樣的節點進行冗餘來保證網站的高可用性

接下來進行緩存，CDN，反向代理等等的優化，這裏之後再細說

好了，如今咱們開始進入正題

架構要素

首先，對於一個高訪問量，大數據量的網站咱們須要考慮什麼呢？

性能

首先就是性能了，性能是一個網站的的重要指標，除非是沒得選擇，就這一個網站，否則用戶是絕對不會忍受一個超級慢的網站

正由於性能問題無處不在，解決性能問題的方式也各類各樣，從用戶請求一個 url 開始，進行的每個環節均可以進行優化；根據上面的分層，能夠大體從三個方面進行優化，應用層優化，服務層優化，數據層優化

涉及到的知識就是 web 前端的優化，應用服務器端的優化和數據的存儲，索引，緩存等，這些在後面的內容裏會分別展開細說

但性能只是一個網站的必要條件，除此以外，由於沒法預知網站可能會面臨的壓力或是攻擊，咱們還要保證網站在各類情境下（高併發，高負載，持續壓力不均勻等）保持穩定的性能

可用性

對於大型網站而言，出現宕機的狀況是可怕的，由於你可能有上千萬的用戶量，短短几分鐘的宕機都有可能致使網站聲譽掃地，若是是電商類的網站，更可能會致使用戶的財產損失，甚至會攤上官司，那時候損失的就不只是金錢和用戶了

所以咱們要保證可以提供天天 24 小時的可用，但實際中服務器並不能保證天天 24 小時都能平穩的運行，可能出現硬件問題，也可能出現軟件問題，總之問題老是會有的

因此咱們高可用設計的目標就是在某些服務器宕機的狀況下，也可以保證服務或應用正常運行

網站高可用的主要手段是 冗餘，應用部署在多臺服務器上同時提供訪問，數據存儲在多臺數據服務器之間互相進行熱備份，這樣任何一臺服務器宕機都不會影響服務或應用的總體，也不會產生數據丟失

對於應用服務器而言，多臺應用服務器經過一個負載均衡設備組成一個集羣同時對外提供服務，當一臺服務器宕機後，服務切換到其餘服務器上繼續執行，這樣就能夠保證了網站的高可用性，前提是應用服務器不容許存儲用戶會話信息，不然將會丟失，這樣即便用戶請求轉接到其餘服務器上面也沒法繼續執行

對於數據存儲服務器，要提供服務器之間的實時備份，這樣當一臺服務器宕機的時候，將數據訪問切換到其餘服務器上，並進行數據恢復和備份

衡量一個系統架構設計是否知足高可用的目標，就是假設其中一臺或多臺服務器宕機以及出現各類不可預期的問題時，系統總體是否依然可用

伸縮性

面對着大量用戶的高併發訪問和海量的數據存儲，不可能只用一臺服務器就可以知足所有需求，存儲所有數據

經過 集羣 的方式將多臺服務器組成一個總體共同提供服務，所謂 伸縮性 就是指經過不斷向集羣中加入服務器的手段來應對不斷上升的用戶併發訪問壓力和不斷增加的數據存儲需求

對於應用服務器集羣，只要服務器上不存儲數據，全部的服務器都是對等的，經過使用合適的負載均衡設備就能夠向集羣中不斷加入新的服務器

對於緩存服務器而言，加入新的服務器可能會致使緩存路由失效，從而致使大部分的緩存數據都沒法訪問，須要改進緩存路由算法來保證緩存數據可訪問

關係數據庫雖然支持數據複製，主從熱備份等機制，可是很難實現大規模集羣的可伸縮性

可擴展性

網站的擴展性直接關係到網站功能模塊的開發，網站快速發展，功能也不斷的增長

網站架構的可擴展性的主要目的是使其可以快速的應對需求變化

是爲了可以在增長新業務時，儘可能實現對現有產品無影響，不須要改動或是改動不多現有業務就可以上線新產品；不一樣的產品業務之間的耦合度很小，一個產品或業務的改動不會對其餘形成影響

大型網必定會吸引到第三方開發者，調用網站服務，開發周邊產品，擴展網站業務，這都須要網站提供開放平臺接口

安全性

最後的就是安全性了，互聯網是一個開放的平臺，任何人在任何地方均可以訪問網站，安全架構就是保護網站不受惡意的訪問和攻擊，保護數據不被竊取

性能，可用性，伸縮性，擴展性，安全性使網站架構的幾個核心要素，咱們網站架構的目的主要就是爲了解決這幾個問題，接下來都會分別進行介紹

高性能架構

說到高性能，在不一樣角色的眼中對於性能的定義也不一樣

• 用戶視角： 用戶感覺到的性能，就是從提交後到看到頁面的時間，不一樣計算機性能的差別，不一樣瀏覽器解析 HTML 的速度，不一樣網絡提供商提供的互聯網服務的速度，這些差別都會致使實際時間遠大於服務器處理請求的時間
  實踐中，咱們能夠用一些前端架構優化的手段，經過優化 HTML 樣式，利用瀏覽器異步和併發的特性，調整緩存策略，使用 CDN 服務，反向代理等，使用戶可以儘快的看到內容，即便不對應用服務優化，也可以很好地改善用戶體驗

• 開發者視角： 開發者更關注的是應用服務器的性能，包括響應延遲，系統吞吐量，併發處理，系統穩定性等> 主要優化手段能夠利用緩存加速數據讀取，使用集羣提升吞吐量，使用異步加快請求響應，優化代碼改善程序等

• 運維人員視角： 對於運維人員，會更關注一些基礎設施的性能和利用率，這裏再也不多說

性能測試指標

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

• 響應時間
  指的是從發出這個請求開始到接收到數據的時間，通常狀況下這個時間都很是很是的小甚至小於測試的偏差值，因此咱們能夠採用重複請求的方式來獲取具體的響應時間，好比請求十萬次，記錄總時間，而後計算出單次請求的時間

• 併發數
  指可以同時處理的請求數目，對於網站而言，即併發用戶數> 有幾個詞可能會產生混淆，這裏解釋一下

網站系統用戶數 > 網站在線用戶數 > 網站併發用戶數

• 吞吐量
  是單位時間能可以處理的請求數，體現的系統的總體處理能力> 衡量指標有不少，能夠是 請求數/秒 頁面數/秒 訪問人數/天 處理業務數/小時 等> 經常使用的量化指標有 TPS（每秒事務數） HPS（每秒 HTTP 請求數） QPS（每秒查詢數） 等

• 性能計數器
  描述服務器或操做系統的一些性能指標，包括系統負載（System Load），線程數，內存使用，磁盤和網絡 I/O 等，當這些值超過警告值（安全臨界值）時，就會想開發運維人員報警，及時處理異常

性能測試方法

性能測試是一個統稱，具體能夠分爲 性能測試，負載測試，壓力測試，穩定性測試

• 性能測試
  以初期設計的指標爲預期目標，不斷對系統施壓，看系統在預期的範圍內，可否達到預期的性能

• 負載測試
  對系統不斷增長併發請求以增長系統壓力，直到系統某項或多項指標達到安全臨界值，這時繼續對系統施加壓力，系統的處理能力會有所降低

• 壓力測試
  在超過安全負載的狀況下，繼續施壓，直到系統崩潰或再也不可以處理任何請求，以此來計算系統的最大壓力承受能力

• 穩定性測試
  在必定的壓力（不均勻施壓）下，系統可以穩定的運行較長時間

如上圖所示，a-b 區間內就是網站平常的運行區間，絕大多數時間都處於這一區間內；而 c 點至關於系統的最大負載點，b-c 段就是因某些緣由訪問量超過了平常訪問壓力；超過了 c 點後，繼續增長壓力，這時候系統的性能就開始降低，可是資源消耗會更多，直到 d 點，系統的崩潰點，超過這個點繼續加壓的話，系統將不能處理任何請求

性能測試反映的是系統的處理能力，與其對應的是用戶的等待時間（響應時間），以下如所示：

各點與上面的性能測試圖都相互對應，直到系統崩潰，用戶失去響應

性能優化策略

首先要定位問題產生緣由，排查不一樣環節的日誌，分析哪一個環節的響應時間與預期不相符，而後分析影響性能的緣由，是代碼問題仍是架構設計不合理，或者系統資源不足

而後就是性能優化，根據網站的分層架構，能夠大體的分爲 web 前端性能優化，應用服務器性能優化，存儲服務器性能優化三大類