阿里面試技術手冊(二):大型網站架構演化發展歷程
大型網站的技術挑戰主要來自於龐大的使用者,高併發的訪問和海量的資料,任何簡單的業務一旦需要處理數以 P 計的資料和麵對數以億計的使用者,問題就會變得很棘手。大型網站架構主要解決這類問題。
初始階段的網站架構
大型網站都是從小型網站發展而來,網站架構也是一樣,是從小型網站架構逐步演化而來。小型網站最開始沒有太
多人訪問,只需要一臺伺服器就綽綽有餘,這時的網站架構如下圖所示:
應用程式、資料庫、檔案等所有資源都在一臺伺服器上。
應用服務和資料服務分離
隨著網站業務的發展,一臺伺服器逐漸不能滿足需求:越來越多的使用者訪問導致效能越來越差,越來越多的資料導致儲存空間不足。這時就需要將應用和資料分離。應用和資料分離後整個網站使用3臺伺服器:應用伺服器、檔案伺服器和資料庫伺服器。
這 3 臺伺服器對硬體資源的要求各不相同:
應用伺服器需要處理大量的業務邏輯,因此需要更快更強大的CPU;
資料庫伺服器需要快速磁碟檢索和資料快取,因此需要更快的磁碟和更大的記憶體;
檔案伺服器需要儲存大量使用者上傳的檔案,因此需要更大的硬碟。
此時,網站系統的架構如下圖所示:
應用和資料分離後,不同特性的伺服器承擔不同的服務角色,網站的併發處理能力和資料儲存空間得到了很大改善,支援網站業務進一步發展。但是隨著使用者逐漸增多,網站又一次面臨挑戰:資料庫壓力太大導致訪問延遲,進而影響整個網站的效能,使用者體驗受到影響。這時需要對網站架構進一步最佳化。
使用快取改善網站效能
網站訪問的特點和現實世界的財富分配一樣遵循二八定律:80% 的業務訪問集中在20% 的資料上。既然大部分業務訪問集中在一小部分資料上,那麼如果把這一小部分資料快取在記憶體中,就可以減少資料庫的訪問壓力,提高整個網站的資料訪問速度,改善資料庫的寫入效能了。
網站使用的快取可以分為兩種:
快取在應用伺服器上的本地快取和快取在專門的分散式快取伺服器上的遠端快取。
本地快取的訪問速度更快一些,但是受應用伺服器記憶體限制,其快取資料量有限,而且會出現和應用程式爭用記憶體的情況。遠端分散式快取可以使用叢集的方式,部署大記憶體的伺服器作為專門的快取伺服器,可以在理論上做到不受記憶體容量限制的快取服務。
使用快取後,資料訪問壓力得到有效緩解,但是單一應用伺服器能夠處理的請求連線有限,在網站訪問高峰期,應用伺服器成為整個網站的瓶頸。
使用應用伺服器叢集改善網站的併發處理能力
使用叢集是網站解決高併發、海量資料問題的常用手段。當一臺伺服器的處理能力、儲存空間不足時,不要企圖去更換更強大的伺服器,對大型網站而言,不管多麼強大的伺服器,都滿足不了網站持續增長的業務需求。這種情況下,更恰當的做法是增加一臺伺服器分擔原有伺服器的訪問及儲存壓力。 對網站架構而言,只要能透過增加一臺伺服器的方式改善負載壓力,就可以以同樣的方式持續增加伺服器不斷改善系統效能,從而實現系統的可伸縮性。應用伺服器實現叢集是網站可伸縮架構設計中較為簡單成熟的一種,如下圖所示:
透過負載均衡排程伺服器,可以將來自使用者瀏覽器的訪問請求分發到應用伺服器叢集中的任何一臺伺服器上,如果有更多使用者,就在叢集中加入更多的應用伺服器,使應用伺服器的壓力不再成為整個網站的瓶頸。
資料庫讀寫分離
網站在使用快取後,使對大部分資料讀操作訪問都可以不透過資料庫就能完成,但是仍有一部分讀操作(快取訪問不命中、快取過期)和全部的寫操作都需要訪問資料庫,在網站的使用者達到一定規模後,資料庫因為負載壓力過高而成為網站的瓶頸。 目前大部分的主流資料庫都提供主從熱備功能,透過配置兩臺資料庫主從關係,可以將一臺資料庫伺服器的資料更新同步到另一臺伺服器上。網站利用資料庫的這一功能,實現資料庫讀寫分離,從而改善資料庫負載壓力。如下圖所示:
應用伺服器在寫資料的時候,訪問主資料庫,主資料庫透過主從複製機制將資料更新同步到從資料庫,這樣當應用伺服器讀資料的時候,就可以透過從資料庫獲得資料。為了便於應用程式訪問讀寫分離後的資料庫,通常在應用伺服器端使用專門的資料訪問模組,使資料庫讀寫分離對應用透明。
使用反向代理和 CDN 加速網站響應
隨著網站業務不斷髮展,使用者規模越來越大,由於中國複雜的網路環境,不同地區的使用者訪問網站時,速度差別也極大。有研究表明,網站訪問延遲和使用者流失率正相關,網站訪問越慢,使用者越容易失去耐心而離開。為了提供更好的使用者體驗,留住使用者,網站需要加速網站訪問速度。主要手段有使用 CDN 和方向代理。如下圖所示:
CDN 和反向代理的基本原理都是快取。
CDN 部署在網路提供商的機房,使使用者在請求網站服務時,可以從距離自己最近的網路提供商機房獲取資料反向代理則部署在網站的中心機房,當使用者請求到達中心機房後,首先訪問的伺服器是反向代理伺服器,如果反向代理伺服器中快取著使用者請求的資源,就將其直接返回給使用者使用 CDN 和反向代理的目的都是儘早返回資料給使用者,一方面加快使用者訪問速度,另一方面也減輕後端伺服器的負載壓力。
使用分散式檔案系統和分散式資料庫系統
任何強大的單一伺服器都滿足不了大型網站持續增長的業務需求。資料庫經過讀寫分離後,從一臺伺服器拆分成兩臺伺服器,但是隨著網站業務的發展依然不能滿足需求,這時需要使用分散式資料庫。檔案系統也一樣,需要使用分散式檔案系統。如下圖所示:
分散式資料庫是網站資料庫拆分的最後手段,只有在單表資料規模非常龐大的時候才使用。不到不得已時,網站更常用的資料庫拆分手段是業務分庫,將不同業務的資料部署在不同的物理伺服器上。
使用 NoSQL 和搜尋引擎
隨著網站業務越來越複雜,對資料儲存和檢索的需求也越來越複雜,網站需要採用一些非關聯式資料庫技術如NoSQL 和非資料庫查詢技術如搜尋引擎。如下圖所示:
NoSQL 和搜尋引擎都是源自網際網路的技術手段,對可伸縮的分散式特性具有更好的支援。應用伺服器則透過一個統一資料訪問模組訪問各種資料,減輕應用程式管理諸多資料來源的麻煩。
業務拆分
大型網站為了應對日益複雜的業務場景,透過使用分而治之的手段將整個網站業務分成不同的產品線。如大型購物交易網站都會將首頁、商鋪、訂單、買家、賣家等拆分成不同的產品線,分歸不同的業務團隊負責。
具體到技術上,也會根據產品線劃分,將一個網站拆分成許多不同的應用,每個應用獨立部署。應用之間可以透過一個超連結建立關係(在首頁上的導航連結每個都指向不同的應用地址),也可以透過訊息佇列進行資料分發,當然最多的還是透過訪問同一個資料儲存系統來構成一個關聯的完整系統,如下圖所示:
分散式微服務
隨著業務拆分越來越小,儲存系統越來越龐大,應用系統的整體複雜度呈指數級增加,部署維護越來越困難。由於所有應用要和所有資料庫系統連線,在數萬臺伺服器規模的網站中,這些連線的數目是伺服器規模的平方,導致資料庫連線資源不足,拒絕服務。
既然每一個應用系統都需要執行許多相同的業務操作,比如使用者管理、商品管理等,那麼可以將這些共用的業務提取出來,獨立部署。由這些可複用的業務連線資料庫,提供共用業務服務,而應用系統只需要管理使用者介面,透過分散式服務呼叫共用業務服務完成具體業務操作。如下圖所示:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/4798/viewspace-2831509/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 大型網站架構演化發展歷程網站架構
- 大型網站架構演化發展歷程 - 上網站架構
- 1.2 大型網站架構演化發展歷程網站架構
- 大型網站技術架構(二)--大型網站架構演化網站架構
- 大型網站架構演化歷程網站架構
- 大型網站技術架構(一)--大型網站架構演化網站架構
- 大型網站架構演化網站架構
- 大型網站技術架構(二)--架構模式網站架構模式
- 大型網站系統架構演化網站架構
- SAP 技術架構的發展歷程架構
- 大型網站的技術架構演進過程網站架構
- 大型網站技術架構(三)--架構模式網站架構模式
- 大型網站技術架構——2. 網站架構模式網站架構模式
- 大型網站技術架構(五)--網站高可用架構網站架構
- 大型網站系統架構演化之路【mark】網站架構
- 大型網站架構利器-CDN技術網站架構
- 大型網站架構技術一覽網站架構
- 大型網站技術架構(八)--網站的安全架構網站架構
- 大型網站技術架構(四)--核心架構要素網站架構
- 大型網站技術架構——核心原理與案例分析(二)網站架構
- 大型網站技術架構(四)--網站的高效能架構網站架構
- 大型網站技術架構(六)--網站的伸縮性架構網站架構
- 大型網站技術架構核心原理(1)網站架構
- 一張圖看懂大型網站技術架構網站架構
- 大型網站技術架構-入門梳理網站架構
- 大型網站技術架構的演進網站架構
- 大型網站技術架構(三)--架構核心要素網站架構
- 讀書筆記-大型網站技術架構筆記網站架構
- 《大型網站技術架構》讀書筆記網站架構筆記
- 大型分散式網站架構技術總結分散式網站架構
- 大型網站技術架構(七)--網站的可擴充套件性架構網站架構套件
- 《大型網站技術架構:核心原理與案例分析》讀書筆記 - 第4篇 架構師(附 大型網站架構技術一覽)網站架構筆記
- 大型網站架構改進歷程:儲存的瓶頸(三)網站架構
- 大型網站架構改進歷程:儲存的瓶頸(下)網站架構
- 大型網站架構改進歷程:儲存的瓶頸(上)網站架構
- 大型網站架構改進歷程:儲存的瓶頸(中)網站架構
- 大型網站架構改進歷程:儲存的瓶頸(4)網站架構
- 大型網站架構改進歷程:儲存的瓶頸(5)網站架構