(轉載) 中大型網站架構演變之路

標籤：服務層   統一   讀寫   ida   HTST   情境   自動   適合   七層   

 標籤：網站架構 大型網站架構原創作品，允許轉載，轉載時請務必以超連結形式標明文章 原始出處 、作者資訊和本聲明。否則將追究法律責任。http://lizhenliang.blog.51cto.com/7876557/1951651

前言

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

一個成熟的網站架構並不是一開始設計就具備高可用、高伸縮、高效能等特性的，它是隨著使用者量和業務線不斷增加，基礎架構才逐漸健壯的。在發展初期，一般都是從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請求，響應會快很多。

十、Distributed File System與CDN

uDistributed File System

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

uCDN

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

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

十一、四層負載平衡與NoSQL資料庫

u四層負載平衡

七層負載平衡要分析應用程式層協議，效率沒有四層高，有些應用情境並不需要分析應用程式層協議，只想實現轉寄負載，那麼，四層負載平衡是首選。

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

uNoSQL資料庫

由於個別SQL查詢量大，已經無法在深度最佳化，可以考慮使用NoSQL非關係型資料庫，它的產生就是解決大規模、高並發、大資料量等問題。但比較適合非結構化資料存放區，比如詳情頁內容、未經處理資料等。

十二、現在

uAuto Scaling

自動擴容，節點降級。

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)機房故障：切換緩衝庫/資料庫到其他機房

 

(轉載) 中大型網站架構演變之路