大型網站技術架構，3大型網站核心架構要素

前言：

 

什麼是架構？"最高層次的規劃，難以改變的決定"，這些規劃和決定奠定了事物將來發展的方向和最終的藍圖。

 

從這個意義上說，人生規劃也是架構，選什麼學校，學什麼專業、進什麼公司、找什麼對象、過什麼樣的生活，都是本身人生的架構。

 

軟件架構：有關軟件總體結構與組件的抽象描述，用於指導大型軟件系統各個方面的設計。

 

軟件架構須要關注的點：

功能性需求

性能、可用性、伸縮性、擴展性和安全性

 

架構設計過程當中須要平衡這5個要素之間的關係以實現需求和架構目標，也能夠經過考察這些架構要素來衡量一個軟件架構設計的優劣，判斷其是否知足指望。

3.1 性能

任何軟件架構的設計都必須考慮可能會帶來的性能問題

瀏覽器端，能夠經過瀏覽器緩存、頁面壓縮、合理佈局頁面、減小Cookie傳輸等手段改善性能。

使用CDN、反向代理服務器，緩存靜態內容、熱點數據，加快請求響應速度，減輕應用服務器負載壓力。

應用服務器端，可使用服務器本地緩存和分佈式緩存，經過緩存在內存中的熱點數據處理用戶請求，加快請求處理過程，減輕數據庫負載壓力。

能夠經過異步操做將用戶請求發送至消息隊列等待後續任務處理，而當前請求直接返回響應給用戶。

 

在網站有不少用戶高併發請求的狀況下，能夠將多臺應用服務器組成一個集羣共同對外服務，提升總體處理能力，改善性能。（無狀態、冪等設計）

 

代碼層面，能夠經過多線程、改善內存管理等手段優化性能。

 

數據庫服務器端，索引、緩存、SQL優化

NoSQL經過優化數據模型、存儲結構、伸縮特性等手段

 

衡量網站性能有一系列指標，

響應時間

TPS

系統性能計數器

經過測試這些指標以肯定系統設計是否達到目標。經過監控這些指標能夠分析系統瓶頸，預測網站容量，並對異常指標進行報警，保障系統可用性。

 

對於網站而言，性能符合預期僅僅是必要條件，由於沒法預知網站可能會面臨的訪問壓力，因此必須要考察系統在高併發訪問狀況下，超出負載設計能力的狀況下可能會出現的性能問題。網站須要長時間持續運行，還必須保證系統在持續運行且訪問壓力不均勻的狀況下保持穩定的性能特性。

 

3.2 可用性

網站高可用架構設計的前提是必然會出現服務器宕機，而高可用設計的目標就是當服務器宕機時，服務或者應用依然可用。

網站高可用的主要手段時冗餘，應用部署在多臺服務器上同時提供服務，數據存儲在多臺服務器上互相備份，任何一臺服務器宕機都不會影響應用的總體可用，也不會致使數據丟失。

對於應用服務器而言，多臺應用服務器經過負載均衡設備組成一個集羣共同對外提供服務，任何一臺服務器宕機，只需把請求切換到其餘服務器就可實現應用的高可用，可是一個前提條件是應用服務器上不能保存請求的會話信息。不然服務器宕機，會話丟失，即便將用戶請求轉發到其餘服務器上也沒法完成業務處理。

 

對於存儲服務器，因爲其上存儲着數據，須要對數據進行實時備份，當服務器宕機時須要將數據轉移到可用的服務器上，並進行數據恢復以保證繼續有服務器宕機的時候數據依然可用。

 

除了運行環境，網站的高可用還須要軟件開發過程的質量保證。經過預發佈驗證、自動化測試、自動化發佈、灰度發佈等手段，減小將故障引入線上環境的可能，避免故障範文擴大。

 

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

 

3.3 伸縮性

什麼是伸縮性？

所謂伸縮性是指經過不斷向集羣中加入服務器的手段來緩解不斷上升的用戶併發訪問壓力和不斷增加的數據存儲需求。

 

衡量架構伸縮性的主要標準：

是否能夠用多臺服務器構建集羣，

是否容易向集羣中添加新的服務器，

加入新的服務器後是否能夠提供和原來的服務器無差異的服務。

集羣中可容納的總的服務器數量是否有限制。

 

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

 

對於緩存服務器集羣，加入新的服務器可能會致使緩存路由失效，進而致使集羣中大部分緩存數據都沒法訪問。

雖然緩存的數據能夠經過數據庫從新加載，可是若是應用已經嚴重依賴緩存，可能會致使整個網站崩潰。須要改進緩存路由算法保證緩存的可訪問性。

(帶虛擬節點的一致性哈希算法）

 

關係型數據庫的集羣伸縮性方案必須在數據庫以外實現，經過路由分區等手段將部署有多個數據庫的服務器組成一個集羣。

 

大部分NoSQL產品，天生爲海量數據而生，伸縮性通常支持的比較好，能夠作到較少的運維參與的狀況下實現集羣規模的線性伸縮。

 

3.4 擴展性

網站的擴展性架構關注的是網站的功能性需求。

 

衡量網站架構擴展性好壞的主要標準：

在網站增長新的業務產品時，是否能夠實現對現有產品透明無影響，不須要任何改動或者不多改動既有業務功能就能夠上線新產品。

不一樣產品之間是否不多耦合，一個產品改動對其餘產品無影響，其餘產品和功能不須要受牽連進行改動。

 

網站可伸縮架構的主要手段時事件驅動架構和分佈式服務。

 

事件驅動架構在網站一般利用消息隊列實現，將用戶請求和其餘業務事件構形成消息發佈到消息隊列，消息的處理者做爲消費者從消息隊列中獲取消息進行處理。

經過這種方式將消息產生和消息處理分離開來，能夠透明地增長新的消息生產者任務或者新的消息消費者任務。

 

分佈式服務則是將業務和可複用服務分離開來，經過分佈式服務框架調用。

新增產品能夠經過調用可複用的服務實現自身的業務邏輯，而對現有產品沒有任何影響。

可複用服務升級變動的時候，也可經過提供多版本服務對應用實現透明升級，不須要強制應用同步變動。

 

大型網站爲了保持市場地位，還會吸引第三方開發者，調用網站服務，使用網站數據開發周邊產品，擴展網站業務。

三方開發者使用網站服務的主要途徑時大型網站提供的開放平臺接口。

 

3.5 安全性

網站的安全架構就是保護網站不受惡意訪問和攻擊，保護網站的重要數據不被竊取。

 

衡量網站安全架構的標準就是針對現存和潛在的各類攻擊與竊密手段，是否有可靠的應對策略。

 

3.6 小結

性能、可用性、伸縮性、擴展性和安全性時網站架構最核心的幾個要素，這幾個問題解決了，大型網站架構設計的大部分挑戰也就克服了。