在大型網站架構演化歷程(上)(請戳我)中已經介紹了利用服務器分離、使用緩存、應用服務器集羣來提升網站的性能。本文繼續介紹優化服務器架構的其它幾種方案。算法
網站在使用緩存後,使對大部分數據讀操做訪問均可以不經過數據庫就能完成,可是仍有一部分讀操做(緩存訪問不命中、緩存過時)和所有的寫操做都須要訪問數據庫,在網站的用戶達到必定規模後,數據庫由於負載壓力太高而成爲網站的瓶頸。 目前大部分的主流數據庫都提供主從熱備功能,經過配置兩臺數據庫主從關係,能夠將一臺數據庫服務器的數據更新同步到另外一臺服務器上。網站利用數據庫的這一功能,實現數據庫讀寫分離,從而改善數據庫負載壓力。以下圖所示:
應用服務器在寫數據的時候,訪問主數據庫,主數據庫經過主從複製機制將數據更新同步到從數據庫,這樣當應用服務器讀數據的時候,就能夠經過從數據庫得到數據。爲了便於應用程序訪問讀寫分離後的數據庫,一般在應用服務器端使用專門的數據訪問模塊,使數據庫讀寫分離對應用透明。sql
隨着網站業務不斷髮展,用戶規模愈來愈大,因爲中國複雜的網絡環境,不一樣地區的用戶訪問網站時,速度差異也極大。有研究代表,網站訪問延遲和用戶流失率正相關,網站訪問越慢,用戶越容易失去耐心而離開。爲了提供更好的用戶體驗,留住用戶,網站須要加速網站訪問速度。主要手段有使用 CDN 和反向代理。以下圖所示:
CDN 和反向代理的基本原理都是緩存。使用 CDN 和反向代理的目的都是儘早返回數據給用戶,一方面加快用戶訪問速度,另外一方面也減輕後端服務器的負載壓力。
(1) CDN 部署在網絡提供商的機房,使用戶在請求網站服務時,能夠從距離本身最近的網絡提供商機房獲取數據
(2) 反向代理則部署在網站的中心機房,當用戶請求到達中心機房後,首先訪問的服務器是反向代理服務器,若是反向代理服務器中緩存着用戶請求的資源,就將其直接返回給用戶數據庫
任何強大的單一服務器都知足不了大型網站持續增加的業務需求。數據庫通過讀寫分離後,從一臺服務器拆分紅兩臺服務器,可是隨着網站業務的發展依然不能知足需求,這時須要使用分佈式數據庫。文件系統也同樣,須要使用分佈式文件系統。以下圖所示:
分佈式數據庫是網站數據庫拆分的最後手段,只有在單表數據規模很是龐大的時候才使用。不到不得已時,網站更經常使用的數據庫拆分手段是業務分庫,將不一樣業務的數據部署在不一樣的物理服務器上。後端
隨着網站業務愈來愈複雜,對數據存儲和檢索的需求也愈來愈複雜,網站須要採用一些非關係數據庫技術如 NoSQL 和非數據庫查詢技術如搜索引擎。以下圖所示:
緩存
大型網站爲了應對日益複雜的業務場景,經過使用分而治之的手段將整個網站業務分紅不一樣的產品線。如大型購物交易網站都會將首頁、商鋪、訂單、買家、賣家等拆分紅不一樣的產品線,分歸不一樣的業務團隊負責。服務器
具體到技術上,也會根據產品線劃分,將一個網站拆分紅許多不一樣的應用,每一個應用獨立部署。應用之間能夠經過一個超連接創建關係(在首頁上的導航連接每一個都指向不一樣的應用地址),也能夠經過消息隊列進行數據分發,固然最多的仍是經過訪問同一個數據存儲系統來構成一個關聯的完整系統,以下圖所示:
網絡
隨着業務拆分愈來愈小,存儲系統愈來愈龐大,應用系統的總體複雜度呈指數級增長,部署維護愈來愈困難。因爲全部應用要和全部數據庫系統鏈接,在數萬臺服務器規模的網站中,這些鏈接的數目是服務器規模的平方,致使數據庫鏈接資源不足,拒絕服務。數據結構
既然每個應用系統都須要執行許多相同的業務操做,好比用戶管理、商品管理等,那麼能夠將這些共用的業務提取出來,獨立部署。由這些可複用的業務鏈接數據庫,提供共用業務服務,而應用系統只須要管理用戶界面,經過分佈式服務調用共用業務服務完成具體業務操做。以下圖所示:
架構
參考資料:<<大型網站技術架構>>分佈式
精心整理 | 歷史乾貨文章目錄
【福利】本身蒐集的網上精品課程視頻分享(上)
【數據結構與算法】 通俗易懂講解 二叉樹遍歷
【數據結構與算法】 通俗易懂講解 二叉搜索樹
碼農有道,爲您提供通俗易懂的技術文章,讓技術變的更簡單!