【伺服器架構】網站架構要素和高性能架構

為了使網站的能夠應對高并發通路，海量資料處理，高可靠運作等一系列問題，我們可以選擇橫向或縱向兩個方向來入手

基本思路

首先可以對整個架構進行分層，一般可以分為 

應用層

，

服務層

，

資料層

；實踐中，大的分層結構中還可以繼續分層，比如 

應用層

還可以繼續分為 

視圖層

 和 

業務邏輯層

，服務層也可以繼續細分為 

資料接口層

邏輯處理層

 等

通過分層，我們把一個龐大的系統切分為不同的部分，便于分工開發和維護；各層之間互相有一定的獨立性，在網站的開發中可以根據不同的需求進行相應的調整

邏輯上分層之後，在實體部署上也可以根據需求制定不同的政策，剛開始可以部署在同一台實體機上，但是随着業務的發展，必然要對不同的子產品進行分離部署

分層架構不僅僅是為了規劃軟體的邏輯結構以便于開發維護，随着網站的發展，分層架構對網站的高并發分布式架構來說尤為重要

進行了分層以後，接下來可以從縱向進行業務分割

根據不同的業務子產品一個項目劃分成不同的子產品交給單獨的團隊去開發部署，完成後分别部署在不同的伺服器上，通過連結進行互聯

再根據不同情況來對不同的節點進行備援來保證網站的高可用性

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

好了，現在我們開始進入正題

架構要素

首先，對于一個高通路量，大資料量的網站我們需要考慮什麼呢？

性能

首先就是性能了，性能是一個網站的的重要名額，除非是沒得選擇，就這一個網站，不然使用者是絕對不會忍受一個超級慢的網站

正因為性能問題無處不在，解決性能問題的方式也各種各樣，從使用者請求一個 url 開始，進行的每一個環節都可以進行優化；根據上面的分層，可以大緻從三個方面進行優化，應用層優化，服務層優化，資料層優化

涉及到的知識就是 web 前端的優化，應用伺服器端的優化和資料的存儲，索引，緩存等，這些在後面的内容裡會分别展開細說

但性能隻是一個網站的必要條件，除此之外，因為無法預知網站可能會面臨的壓力或是攻擊，我們還要保證網站在各種情境下（高并發，高負載，持續壓力不均勻等）保持穩定的性能

可用性

對于大型網站而言，出現當機的情況是可怕的，因為你可能有上千萬的使用者量，短短幾分鐘的當機都有可能導緻網站聲譽掃地，如果是電商類的網站，更可能會導緻使用者的财産損失，甚至會攤上官司，那時候損失的就不僅是金錢和使用者了

是以我們要保證能夠提供每天 24 小時的可用，但實際中伺服器并不能保證每天 24 小時都能平穩的運作，可能出現硬體問題，也可能出現軟體問題，總之問題總是會有的

是以我們高可用設計的目标就是在某些伺服器當機的情況下，也能夠保證服務或應用正常運作

網站高可用的主要手段是 

備援

，應用部署在多台伺服器上同時提供通路，資料存儲在多台資料伺服器之間互相進行熱備份，這樣任何一台伺服器當機都不會影響服務或應用的整體，也不會産生資料丢失

對于應用伺服器而言，多台應用伺服器通過一個負載均衡裝置組成一個叢集同時對外提供服務，當一台伺服器當機後，服務切換到其他伺服器上繼續執行，這樣就可以保證了網站的高可用性，前提是應用伺服器不允許存儲使用者會話資訊，否則将會丢失，這樣即使使用者請求轉接到其他伺服器上面也無法繼續執行

對于資料存儲伺服器，要提供伺服器之間的實時備份，這樣當一台伺服器當機的時候，将資料通路切換到其他伺服器上，并進行資料恢複和備份

衡量一個系統架構設計是否滿足高可用的目标，就是假設其中一台或多台伺服器當機以及出現各種不可預期的問題時，系統整體是否依然可用

伸縮性

面對着大量使用者的高并發通路和海量的資料存儲，不可能隻用一台伺服器就能夠滿足全部需求，存儲全部資料

通過 

叢集

 的方式将多台伺服器組成一個整體共同提供服務，所謂 

伸縮性

 就是指通過不斷向叢集中加入伺服器的手段來應對不斷上升的使用者并發通路壓力和不斷增長的資料存儲需求

對于應用伺服器叢集，隻要伺服器上不存儲資料，所有的伺服器都是對等的，通過使用合适的負載均衡裝置就可以向叢集中不斷加入新的伺服器

對于緩存伺服器而言，加入新的伺服器可能會導緻緩存路由失效，進而導緻大部分的緩存資料都無法通路，需要改進緩存路由算法來保證緩存資料可通路

關系資料庫雖然支援資料複制，主從熱備份等機制，但是很難實作大規模叢集的可伸縮性

可擴充性

網站的擴充性直接關系到網站功能子產品的開發，網站快速發展，功能也不斷的增加

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

是為了能夠在增加新業務時，盡量實作對現有産品無影響，不需要改動或是改動很少現有業務就能夠上線新産品；不同的産品業務之間的耦合度很小，一個産品或業務的改動不會對其他造成影響

大型網一定會吸引到第三方開發者，調用網站服務，開發周邊産品，擴充網站業務，這都需要網站提供開放平台接口

安全性

最後的就是安全性了，網際網路是一個開放的平台，任何人在任何地方都可以通路網站，安全架構就是保護網站不受惡意的通路和攻擊，保護資料不被竊取

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

高性能架構

說到高性能，在不同角色的眼中對于性能的定義也不同

• 使用者視角： 使用者感受到的性能，就是從送出後到看到頁面的時間，不同計算機性能的差異，不同浏覽器解析 HTML 的速度，不同網絡提供商提供的網際網路服務的速度，這些差異都會導緻實際時間遠大于伺服器處理請求的時間

  實踐中，我們可以用一些前端架構優化的手段，通過優化 HTML 樣式，利用浏覽器異步和并發的特性，調整緩存政策，使用 CDN 服務，反向代理等，使使用者能夠盡快的看到内容，即使不對應用服務優化，也能夠很好地改善使用者體驗

• 開發者視角： 開發者更關注的是應用伺服器的性能，包括響應延遲，系統吞吐量，并發處理，系統穩定性等> 主要優化手段可以利用緩存加速資料讀取，使用叢集提高吞吐量，使用異步加快請求響應，優化代碼改善程式等
• 運維人員視角： 對于運維人員，會更關注一些基礎設施的性能和使用率，這裡不再多說

性能測試名額

主要的性能測試名額有 

響應時間

并發數

吞吐量

性能計數器

 等

• 響應時間

  指的是從發出這個請求開始到接收到資料的時間，一般情況下這個時間都非常非常的小甚至小于測試的誤內插補點，是以我們可以采用重複請求的方式來擷取具體的響應時間，比如請求十萬次，記錄總時間，然後計算出單次請求的時間

• 并發數

  指能夠同時處理的請求數目，對于網站而言，即并發使用者數> 有幾個詞可能會産生混淆，這裡解釋一下

網站系統使用者數 > 網站線上使用者數 > 網站并發使用者數

• 吞吐量

  是機關時間能能夠處理的請求數，展現的系統的整體處理能力> 衡量名額有很多，可以是 

  請求數/秒

  頁面數/秒

  通路人數/天

  處理業務數/小時

   等> 常用的量化名額有 

  TPS（每秒事務數）

  HPS（每秒 HTTP 請求數）

  QPS（每秒查詢數）

   等

• 性能計數器

  描述伺服器或作業系統的一些性能名額，包括系統負載（System Load），線程數，記憶體使用，磁盤和網絡 I/O 等，當這些值超過警告值（安全臨界值）時，就會想開發運維人員報警，及時處理異常

性能測試方法

性能測試是一個統稱，具體可以分為 

性能測試

，

負載測試

，

壓力測試

，

穩定性測試

• 性能測試

  以初期設計的名額為預期目标，不斷對系統施壓，看系統在預期的範圍内，能否達到預期的性能

• 負載測試

  對系統不斷增加并發請求以增加系統壓力，直到系統某項或多項名額達到安全臨界值，這時繼續對系統施加壓力，系統的處理能力會有所下降

• 壓力測試

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

• 穩定性測試

  在一定的壓力（不均勻施壓）下，系統能夠穩定的運作較長時間

如上圖所示，a-b 區間内就是網站日常的運作區間，絕大多數時間都處于這一區間内；而 c 點相當于系統的最大負載點，b-c 段就是因某些原因通路量超過了日常通路壓力；超過了 c 點後，繼續增加壓力，這時候系統的性能就開始下降，但是資源消耗會更多，直到 d 點，系統的崩潰點，超過這個點繼續加壓的話，系統将不能處理任何請求

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

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

性能優化政策

首先要定位問題産生原因，排查不同環節的日志，分析哪個環節的響應時間與預期不相符，然後分析影響性能的原因，是代碼問題還是架構設計不合理，或者系統資源不足

然後就是性能優化，根據網站的分層架構，可以大緻的分為 web 前端性能優化，應用伺服器性能優化，存儲伺服器性能優化三大類