架構要素和高性能架構

作者：Arno

上一篇我們把整個架構演變過程大致說了一下，這次我們來說說從哪方面進行考慮設計。

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

基本思路

首先可以對整個架構進行分層，一般可以分為應用層，服務層，數據層；實踐中，大的分層結構中還可以繼續分層，比如 應用層 還可以繼續分為視圖層和 業務邏輯層，服務層也可以繼續細分為數據介面層邏輯處理層等。

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

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

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

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

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

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

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

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

架構要素

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

性能

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

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

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

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

可用性

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

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

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

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

對於應用伺服器而言，多台應用伺服器通過一個負載均衡設備組成一個集群同時對外提供服務，當一台伺服器宕機後，服務切換到其他伺服器上繼續執行，這樣就可以保證了網站的高可用性，前提是應用伺服器不允許存儲用戶會話信息，否則將會丟失，這樣即使用戶請求轉接到其他伺服器上面也無法繼續執行。

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

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

伸縮性

面對著大量用戶的高並發訪問和海量的數據存儲，不可能只用一台伺服器就能夠滿足全部需求，存儲全部數據.

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

對於應用伺服器集群，只要伺服器上不存儲數據，所有的伺服器都是對等的，通過使用合適的負載均衡設備就可以向集群中不斷加入新的伺服器。

對於緩存伺服器而言，加入新的伺服器可能會導致緩存路由失效，從而導致大部分的緩存數據都無法訪問，需要改進緩存路由演算法來保證緩存數據可訪問。

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

可擴展性

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

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

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

大型網一定會吸引到第三方開發者，調用網站服務，開發周邊產品，擴展網站業務，這都需要網站提供開放平台介面。

安全性

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

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

高性能架構

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

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

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

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

性能測試指標

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

響應時間

指的是從發出這個請求開始到接收到數據的時間，一般情況下這個時間都非常非常的小甚至小於測試的誤差值，所以我們可以採用重複請求的方式來獲取具體的響應時間，比如請求十萬次，記錄總時間，然後計算出單次請求的時間

並發數

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

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

吞吐量

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

性能計數器

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

性能測試方法

性能測試是一個統稱，具體可以分為性能測試，負載測試，壓力測試，穩定性測試。

性能測試

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

負載測試

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

壓力測試

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

穩定性測試

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

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

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

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

性能優化策略

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

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

具體的優化方法我們下篇再繼續。

在微信公眾號內回複數字「1」

小編拉你進粉絲微信群

不是在文章評論里回復

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！