前言

網上有很多文章類似于我今天要分享的課程，有架構師寫的，有運維寫的，還有開發些的，偏重點都不同，今天我以咱們運維角度全面講解。

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

說明

適用業務：電商/門戶/招聘網站

開發語言：PHP和JAVA

Web服務：Nginx/Tomcat8

數據庫：MySQL

操作系統：CentOS

物理服務器：Dell R730/R430

一、單臺服務器部署

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


 

二、WEB與數據庫獨立部署

有一定用戶訪問量，單臺服務器性能有些吃力，想提高并發能力，增加一臺服務器，將HTTP請求與SQL操作負載分散不同服務器。

三、動靜分離-初期

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

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

uRedisCache

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

uMySQL主從

基于binlog異步復制。

uHA

MySQL：Keepalived

u怎么保證Redis緩存時效性？

a) 增加中間件，在主從同步延遲時間內，中間件將SQL讀操作還路由到主。

b) 主從同步延遲時間后，再異步發起一次淘汰Cache。

c) 增加消息隊列和清理Cache程序，入庫同時也寫入消息隊列，緩存清理程序訂閱消息隊列，一旦有數據更新，重新Cache。

d) Cache中的Item一定要設置過期時間。

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

訪問量越來越大，單臺服務器性能已無法支撐，于是增加負載均衡，水平擴展WEB節點，同時調整動靜分離。

u七層負載均衡

根據域名或者后綴轉發不同的upstream。

uNFS網絡文件系統

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

uRedis主從

u動靜分離-中期

uHA

LB：Keepalived

NFS：DRBD+Heartbeat

Redis：Sentinel/Keepalived

uSession如何會話保持？

a)源IP Hash

b)Session共享

c)Session Sticky（粘滯會話）

d)Session復制

六、數據庫架構擴展

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

u一主多從

基于binlog異步復制，多個從庫同步主庫。

u讀寫分離

a)代碼邏輯層區分讀寫庫。

b)使用中間件代理，對SQL解析區分處理；開源主流的有：Atlas、MyCat等。

u分庫、分表、分區

分庫：根據業務類型分離相關表到不同數據庫；例如WEB、BBS、Blog等。

分表：單個表上千萬條記錄，操作耗時長，采用垂直拆分和水平拆分，將數據分散存儲到不同小表上。

分區：根據表字段分成多個區塊，這些區塊可以分布在不同磁盤上。

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

u從庫四層負載均衡

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

uHA

主庫和從庫LB：Keepalived

七、SOA面向服務架構

uSOA

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

u服務化治理

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

u配置中心

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

u消息隊列

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

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

uDNS輪詢

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

u全文檢索引擎

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

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

九、靜態緩存服務器

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

十、分布式文件系統與CDN

u分布式文件系統

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

uCDN

每次請求靜態資源都會落在WEB節點和存儲上，而且這些資源都是很少變動的，如果把這些資源放到網站入口，豈不減少后端大量HTTP請求，有什么方法呢？

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

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

u四層負載均衡

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

當然，也可以四層代理七層負載均衡，方面擴展七層負載均衡。

uNoSQL數據庫

由于個別SQL查詢量大，已經無法在深度優化，可以考慮使用NoSQL非關系型數據庫，它的產生就是解決大規模、高并發、大數據量等問題。但比較適合非結構化數據存儲，比如詳情頁內容、原始數據等。

十二、現在

u彈性伸縮

自動擴容，節點降級。

u微服務

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

u內存化

磁盤數據盡可能在內存中處理。

u異地容災

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

u應急預案

十三、談古至今

盡量將請求攔截在前面，從而減少數據庫和HTTP請求

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

避免單點

分解壓力

擴展性

找瓶頸出方案

十三、應急預案

SRE：網站可靠性工程師

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

制作應急預案大致以下幾步：

1、系統分級

按照業務系統重要性劃分，比如訂單服務掛了，將影響用戶無法下單，因此需要投入更多的資源保障；比如管理后臺掛了，不會影響到用戶；根據業務劃分不同級別，實施不同的質量保障和成本投入。

2、全鏈路分析

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

3、全方位監控

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

4、制定應急預案

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

十四、應對策略

網絡接入層：

a)機房故障：從DNS輪訓摘除該機房或者切換到其他機房

b)VIP網絡異常：切換備用VIP

代理層：

a)IP限流：某些IP訪問太大導致后端負載壓力過高；實施IP限流

b)后端應用異常：如軟硬件故障，摘除異常節點；如果某機房問題切換到其他機房

應用層和服務層：

a)服務異常：某服務訪問超時，響應慢；摘除服務或切換到正常服務

b)程序線程池不夠用：線程池設置太小，導致請求堆積；提供參數開關，比如動態調整線程池大小

c)請求量太大：請求量太大，超過實際處理能力；請求限流或者設置請求閾值自動擴展節點

緩存層和數據層：

a)Redis掛掉：主從切換

b)MySQL掛掉：主從切換，切換后驗證

c)機房故障：切換緩存庫/數據庫到其他機房