從運維角度看中大型網站架構的演變之路

前言

一個成熟的網站架構並非一開始設計就具有高可用、高伸縮、高性能等特性的，它是隨着用戶量和業務線不斷增長，基礎架構才逐漸健壯的。在發展初期，通常都是從0到1，不會一上來就整一些大而全的架構，也不多人這麼任性。

 

說明

適用業務：電商/門戶/招聘網站
開發語言：PHP和JAVA
Web服務：Nginx/Tomcat8
數據庫：MySQL
操做系統：CentOS
物理服務器：Dell R730/R430

 

1、單臺服務器部署

項目開發完成上線，用戶訪問量寥寥無幾。

 

2、WEB與數據庫獨立部署

有必定用戶訪問量，單臺服務器性能有些吃力，想提升併發能力，增長一臺服務器，將HTTP請求與SQL操做負載分散不一樣服務器。

3、動靜分離-初期

什麼是動靜分離？靜態頁面與動態頁面分離部署。

4、數據庫主從與查詢緩存

RedisCache

使用Redis緩存數據庫查詢結果，將熱數據放到內存中，提升查詢速度，減小數據庫請求。

MySQL主從

基於binlog異步複製。

 
HA

MySQL：Keepalived

怎麼保證Redis緩存時效性？

a) 增長中間件，在主從同步延遲時間內，中間件將SQL讀操做還路由到主。
b) 主從同步延遲時間後，再異步發起一次淘汰Cache。
c) 增長消息隊列和清理Cache程序，入庫同時也寫入消息隊列，緩存清理程序訂閱消息隊列，一旦有數據更新，從新Cache。
d) Cache中的Item必定要設置過時時間。

5、七層負載均衡、共享存儲與Redis高可用

訪問量愈來愈大，單臺服務器性能已沒法支撐，因而增長負載均衡，水平擴展WEB節點，同時調整動靜分離。

七層負載均衡

根據域名或者後綴轉發不一樣的upstream。

NFS網絡文件系統

共享存儲存放網站程序或者靜態資源。

Redis主從

動靜分離-中期

HA

LB：Keepalived
NFS：DRBD+Heartbeat
Redis：Sentinel/Keepalived

Session如何會話保持？

a)源IP Hash
b)Session共享
c)Session Sticky（粘滯會話）
d)Session複製

6、數據庫架構擴展

訪問量上來了，SQL操做天然也就多了，單臺數據庫讀性能到達瓶頸，響應很慢；業務讀多寫少，須要提高讀性能，考慮擴展數據庫架構。

一主多從

基於binlog異步複製，多個從庫同步主庫。

讀寫分離

a)代碼邏輯層區分讀寫庫。
b)使用中間件代理，對SQL解析區分處理；開源主流的有：Atlas、MyCat等。

分庫、分表、分區

分庫：根據業務類型分離相關表到不一樣數據庫；例如WEB、BBS、Blog等。
分表：單個表上千萬條記錄，操做耗時長，採用垂直拆分和水平拆分，將數據分散存儲到不一樣小表上。
分區：根據表字段分紅多個區塊，這些區塊能夠分佈在不一樣磁盤上。

以上主要是分散磁盤I/O壓力，提升處理性能。

從庫四層負載均衡

當多個從庫時，採用LVS實現負載均衡，對程序提供VIP，訪問透明。

HA

主庫和從庫LB：Keepalived

7、SOA面向服務架構

SOA

面向服務架構設計理念，拆分臃腫程序架構，以核心業務爲單位分解，服務化、模塊化，分佈式部署。

服務化治理

使用Dubbo分佈式框架，治理SOA服務化，Dubbo提供高性能和透明化RPC遠程調用方案 。

配置中心

使用Zookeeper存儲服務鏈接信息。

消息隊列

使用RabbitMQ解耦服務，保障服務直接通訊。

8、DNS輪訓與數據庫全文檢索引擎

DNS輪詢

DNS負載均衡技術實現原理是在DNS服務器上一個主機名配置多個IP地址，用戶訪問時，輪訓返回解析記錄，從而達到負載均衡目的。

全文檢索引擎

像電商網站首頁都會有查詢表單，當商品多且品種多，關係型數據庫龐大，想要快速從數據庫中精確檢索出用戶想要的商品就顯的力不從心了。

引入全文檢索引擎，創建索引緩存，快速查詢海量數據，緩解數據庫壓力；開源主流的有：ElasticSearch、Sphinx。

9、靜態緩存服務器

每次請求靜態資源負載都會落在WEB節點和NFS存儲上，並且這些資源都是不多變更的，咱們把這些資源緩存到上層，請求到來時先判斷本地是否有緩存，若是有就直接返回，從而減小後端HTTP請求，響應會快不少。

10、分佈式文件系統與CDN

分佈式文件系統

當圖片、視頻不少時，NFS在處理效率和存儲容量上受侷限，這時用分佈式文件系統（DFS）就比較合適了，DFS是一種NAS存儲架構，C/S模式，多臺廉價服務器組成存儲集羣，提供高性能、高可用、高擴展等特性。客戶端掛載到本地，就像訪問本地文件系統同樣訪問遠程服務器文件。

CDN

每次請求靜態資源都會落在WEB節點和存儲上，並且這些資源都是不多變更的，若是把這些資源放到網站入口，豈不減小後端大量HTTP請求，有什麼方法呢？

使用CDN技術，它經過一種緩存技術將頻繁訪問的資源（主要靜態）分佈到全國各地邊緣服務器，用戶先訪問CDN服務器，CDN根據職能DNS返回客戶端就近網絡中的緩存服務器，若是這個緩存服務器有緩存請求的靜態資源就直接返回，不然回源站獲取返回，從而提升網站訪問速度，減小後端服務器壓力。

11、四層負載均衡與NoSQL數據庫

四層負載均衡

七層負載均衡要分析應用層協議，效率沒有四層高，有些應用場景並不須要分析應用層協議，只想實現轉發負載，那麼，四層負載均衡是首選。

固然，也能夠四層代理七層負載均衡，方面擴展七層負載均衡。

NoSQL數據庫

因爲個別SQL查詢量大，已經沒法在深度優化，能夠考慮使用NoSQL非關係型數據庫，它的產生就是解決大規模、高併發、大數據量等問題。但比較適合非結構化數據存儲，好比詳情頁內容、原始數據等。

12、如今

彈性伸縮

自動擴容，節點降級。

微服務

更細粒度拆分應用，實現服務化、輕量級、自動化部署等。

內存化

磁盤數據儘量在內存中處理。

異地容災

若是不可容忍網站不可用，應考慮到異地備份或異地雙活。

應急預案

十3、談古至今

儘可能將請求攔截在前面，從而減小數據庫和HTTP請求

數據庫層是架構瓶頸，須要精心設計，好比架構擴展、SQL優化（壓縮、索引等）

避免單點
分解壓力
擴展性
找瓶頸出方案

十4、應急預案

SRE：網站可靠性工程師

保證網站不宕機是他們的使命！

製做應急預案大體如下幾步：

一、系統分級

按照業務系統重要性劃分，好比訂單服務掛了，將影響用戶沒法下單，所以須要投入更多的資源保障；好比管理後臺掛了，不會影響到用戶；根據業務劃分不一樣級別，實施不一樣的質量保障和成本投入。

二、全鏈路分析

梳理從網站入口到數據存儲的各個環節，找出依賴服務，假設性去分析問題，若是某環節故障，影響範圍怎樣。

三、全方位監控

對相關鏈路實施全面監控，包括基礎資源監控、服務狀態監控、接口監控、日誌監控等，確保出現問題有依據可追溯。

四、制定應急預案

多思考方案可行性，不按期進行預案演習，驗證預案正確性和可控性及掌握恢復時間。

十5、應對策略

網絡接入層：

a)機房故障：從DNS輪訓摘除該機房或者切換到其餘機房
b)VIP網絡異常：切換備用VIP

代理層：

a)IP限流：某些IP訪問太大致使後端負載壓力太高；實施IP限流
b)後端應用異常：如軟硬件故障，摘除異常節點；若是某機房問題切換到其餘機房

應用層和服務層：

a)服務異常：某服務訪問超時，響應慢；摘除服務或切換到正常服務
b)程序線程池不夠用：線程池設置過小，致使請求堆積；提供參數開關，好比動態調整線程池大小
c)請求量太大：請求量太大，超過實際處理能力；請求限流或者設置請求閾值自動擴展節點

緩存層和數據層：

a)Redis掛掉：主從切換
b)MySQL掛掉：主從切換，切換後驗證
c)機房故障：切換緩存庫/數據庫到其餘機房