前言

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

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

說明

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

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

Web服務(wù)：Nginx/Tomcat8

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

操作系統(tǒng)：CentOS

物理服務(wù)器：Dell R730/R430

一、單臺(tái)服務(wù)器部署

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


 

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

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

三、動(dòng)靜分離-初期

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

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

uRedisCache

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

uMySQL主從

基于binlog異步復(fù)制。

uHA

MySQL：Keepalived

u怎么保證Redis緩存時(shí)效性？

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

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

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

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

五、七層負(fù)載均衡、共享存儲(chǔ)與Redis高可用

訪問量越來越大，單臺(tái)服務(wù)器性能已無法支撐，于是增加負(fù)載均衡，水平擴(kuò)展WEB節(jié)點(diǎn)，同時(shí)調(diào)整動(dòng)靜分離。

u七層負(fù)載均衡

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

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

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

uRedis主從

u動(dòng)靜分離-中期

uHA

LB：Keepalived

NFS：DRBD+Heartbeat

Redis：Sentinel/Keepalived

uSession如何會(huì)話保持？

a)源IP Hash

b)Session共享

c)Session Sticky（粘滯會(huì)話）

d)Session復(fù)制

六、數(shù)據(jù)庫架構(gòu)擴(kuò)展

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

u一主多從

基于binlog異步復(fù)制，多個(gè)從庫同步主庫。

u讀寫分離

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

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

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

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

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

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

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

u從庫四層負(fù)載均衡

當(dāng)多個(gè)從庫時(shí)，采用LVS實(shí)現(xiàn)負(fù)載均衡，對程序提供VIP，訪問透明。

uHA

主庫和從庫LB：Keepalived

七、SOA面向服務(wù)架構(gòu)

uSOA

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

u服務(wù)化治理

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

u配置中心

使用Zookeeper存儲(chǔ)服務(wù)連接信息。

u消息隊(duì)列

使用RabbitMQ解耦服務(wù)，保障服務(wù)直接通信。

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

uDNS輪詢

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

u全文檢索引擎

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

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

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

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

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

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

當(dāng) 圖片、視頻很多時(shí)，NFS在處理效率和存儲(chǔ)容量上受局限，這時(shí)用分布式文件系統(tǒng)（DFS）就比較合適了，DFS是一種NAS存儲(chǔ)架構(gòu)，C/S模式，多臺(tái)廉 價(jià)服務(wù)器組成存儲(chǔ)集群，提供高性能、高可用、高擴(kuò)展等特性。客戶端掛載到本地，就像訪問本地文件系統(tǒng)一樣訪問遠(yuǎn)程服務(wù)器文件。

uCDN

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

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

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

u四層負(fù)載均衡

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

當(dāng)然，也可以四層代理七層負(fù)載均衡，方面擴(kuò)展七層負(fù)載均衡。

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

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

十二、現(xiàn)在

u彈性伸縮

自動(dòng)擴(kuò)容，節(jié)點(diǎn)降級(jí)。

u微服務(wù)

更細(xì)粒度拆分應(yīng)用，實(shí)現(xiàn)服務(wù)化、輕量級(jí)、自動(dòng)化部署等。

u內(nèi)存化

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

u異地容災(zāi)

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

u應(yīng)急預(yù)案

十三、談古至今

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

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

避免單點(diǎn)

分解壓力

擴(kuò)展性

找瓶頸出方案

十三、應(yīng)急預(yù)案

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

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

制作應(yīng)急預(yù)案大致以下幾步：

1、系統(tǒng)分級(jí)

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

2、全鏈路分析

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

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

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

4、制定應(yīng)急預(yù)案

多思考方案可行性，不定期進(jìn)行預(yù)案演習(xí)，驗(yàn)證預(yù)案正確性和可控性及掌握恢復(fù)時(shí)間。

十四、應(yīng)對策略

網(wǎng)絡(luò)接入層：

a)機(jī)房故障：從DNS輪訓(xùn)摘除該機(jī)房或者切換到其他機(jī)房

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

代理層：

a)IP限流：某些IP訪問太大導(dǎo)致后端負(fù)載壓力過高；實(shí)施IP限流

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

應(yīng)用層和服務(wù)層：

a)服務(wù)異常：某服務(wù)訪問超時(shí)，響應(yīng)慢；摘除服務(wù)或切換到正常服務(wù)

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

c)請求量太大：請求量太大，超過實(shí)際處理能力；請求限流或者設(shè)置請求閾值自動(dòng)擴(kuò)展節(jié)點(diǎn)

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

a)Redis掛掉：主從切換

b)MySQL掛掉：主從切換，切換后驗(yàn)證

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