前言

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

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

說明

適用業(yè)務：電商/門戶/招聘網(wǎng)站

開發(fā)語言：PHP和JAVA

Web服務：Nginx/Tomcat8

數(shù)據(jù)庫：MySQL

操作系統(tǒng)：CentOS

物理服務器：Dell R730/R430

一、單臺服務器部署

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


 

二、WEB與數(shù)據(jù)庫獨立部署

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

三、動靜分離-初期

什么是動靜分離？靜態(tài)頁面與動態(tài)頁面分離部署。

四、數(shù)據(jù)庫主從與查詢緩存

uRedisCache

使用Redis緩存數(shù)據(jù)庫查詢結果，將熱數(shù)據(jù)放到內(nèi)存中，提高查詢速度，減少數(shù)據(jù)庫請求。

uMySQL主從

基于binlog異步復制。

uHA

MySQL：Keepalived

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

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

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

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

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

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

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

u七層負載均衡

根據(jù)域名或者后綴轉發(fā)不同的upstream。

uNFS網(wǎng)絡文件系統(tǒng)

共享存儲存放網(wǎng)站程序或者靜態(tài)資源。

uRedis主從

u動靜分離-中期

uHA

LB：Keepalived

NFS：DRBD+Heartbeat

Redis：Sentinel/Keepalived

uSession如何會話保持？

a)源IP Hash

b)Session共享

c)Session Sticky（粘滯會話）

d)Session復制

六、數(shù)據(jù)庫架構擴展

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

u一主多從

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

u讀寫分離

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

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

u分庫、分表、分區(qū)

分庫：根據(jù)業(yè)務類型分離相關表到不同數(shù)據(jù)庫；例如WEB、BBS、Blog等。

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

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

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

u從庫四層負載均衡

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

uHA

主庫和從庫LB：Keepalived

七、SOA面向服務架構

uSOA

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

u服務化治理

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

u配置中心

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

u消息隊列

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

八、DNS輪訓與數(shù)據(jù)庫全文檢索引擎

uDNS輪詢

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

u全文檢索引擎

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

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

九、靜態(tài)緩存服務器

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

十、分布式文件系統(tǒng)與CDN

u分布式文件系統(tǒng)

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

uCDN

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

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

十一、四層負載均衡與NoSQL數(shù)據(jù)庫

u四層負載均衡

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

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

uNoSQL數(shù)據(jù)庫

由于個別SQL查詢量大，已經(jīng)無法在深度優(yōu)化，可以考慮使用NoSQL非關系型數(shù)據(jù)庫，它的產(chǎn)生就是解決大規(guī)模、高并發(fā)、大數(shù)據(jù)量等問題。但比較適合非結構化數(shù)據(jù)存儲，比如詳情頁內(nèi)容、原始數(shù)據(jù)等。

十二、現(xiàn)在

u彈性伸縮

自動擴容，節(jié)點降級。

u微服務

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

u內(nèi)存化

磁盤數(shù)據(jù)盡可能在內(nèi)存中處理。

u異地容災

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

u應急預案

十三、談古至今

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

數(shù)據(jù)庫層是架構瓶頸，需要精心設計，比如架構擴展、SQL優(yōu)化（壓縮、索引等）

避免單點

分解壓力

擴展性

找瓶頸出方案

十三、應急預案

SRE：網(wǎng)站可靠性工程師

保證網(wǎng)站不宕機是他們的使命！

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

1、系統(tǒng)分級

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

2、全鏈路分析

梳理從網(wǎng)站入口到數(shù)據(jù)存儲的各個環(huán)節(jié)，找出依賴服務，假設性去分析問題，如果某環(huán)節(jié)故障，影響范圍怎樣。

3、全方位監(jiān)控

對相關鏈路實施全面監(jiān)控，包括基礎資源監(jiān)控、服務狀態(tài)監(jiān)控、接口監(jiān)控、日志監(jiān)控等，確保出現(xiàn)問題有依據(jù)可追溯。

4、制定應急預案

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

十四、應對策略

網(wǎng)絡接入層：

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

b)VIP網(wǎng)絡異常：切換備用VIP

代理層：

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

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

應用層和服務層：

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

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

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

緩存層和數(shù)據(jù)層：

a)Redis掛掉：主從切換

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

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