(轉載) 中大型網站架構演變之路
前言
網上有很多文章類似於我今天要分享的課程，有架構師寫的，有運維寫的，還有開發些的，偏重點都不同，今天我以咱們運維角度全面講解。
一個成熟的網站架構並不是一開始設計就具備高可用、高伸縮、高性能等特性的，它是隨著用戶量和業務線不斷增加，基礎架構才逐漸健壯的。在發展初期，一般都是從0到1，不會一上來就整一些大而全的架構，也很少人這麽任性。
說明
適用業務：電商/門戶/招聘網站
開發語言：PHP和JAVA
Web服務：Nginx/Tomcat8
數據庫：MySQL
操作系統：CentOS
物理服務器：Dell R730/R430
錄制視頻地址：http://edu.51cto.com/course/10288.html
此文章為博主原創，轉載請註明出處，抵制不道德行為！
一、單臺服務器部署
項目開發完成上線，用戶訪問量寥寥無幾。
二、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)機房故障：切換緩存庫/數據庫到其他機房
(轉載) 中大型網站架構演變之路