1. 程式人生 > >第一篇:概述 -- 1.大型網站架構演化筆記

第一篇:概述 -- 1.大型網站架構演化筆記

大型網站架構演化 筆記

在本書第一章節的內容中,主要從四個方面講解了大型網站架構的演化過程,分別是:大型網站軟體系統的特點、大型網站架構演化發展歷程、大型網站架構演化的價值觀與網站架構的設計誤區。以下詳細對這四點進行說明。

1.大型網站軟體系統的特點

通過通讀第一章節,個人認為相對於小型傳統網站,大型網站不但要在技術上實現具有更強健壯性的解決業務需求的能力,更要在面對突發問題上有靈活快速的解決辦法,對於網站的擴充套件性,模組型等有著高效的設計模式,簡而言之,就是“打造一個高可用、高效能、易擴充套件、可伸縮且安全的網站”。以下為具體的特點。

  1. 高併發,大流量
    大型網際網路應用系統具有大量高併發實時使用者和大流量訪問的特點。在一些特殊時期,B2C網站(Business-to-Customer,電子商務中直接面向消費者銷售產品和服務商業零售的模式

    )比如淘寶2017年的“雙十一”活動,活動交易峰值達到每秒32.5萬筆,支付峰值達到每秒25.6萬筆,第7分23秒支付數突破1億元。

  2. 高可用
    系統需要在7x24小時不間斷服務。若遇到宕機事件,必然會對使用者流量與網站信譽產生影響。

  3. 海量資料
    針對數量龐大的使用者,自然需要儲存於管理廣大的使用者資料,也對伺服器有了更為苛刻的要求。

  4. 使用者分佈廣泛,網路情況複雜
    在針對於全球使用者的大型網站中,不但要解決網路情況差異的問題,還要保證不同運營商網路之間的互通。

  5. 安全環境惡劣
    由於網際網路的開放性,保護使用者資料安全也是一大重要的因素。

  6. 需求快速變更,釋出頻繁
    針對具體的市場發展和使用者需求,網際網路產品需要具備更高的時效性,自然版本也需要更快的更新。

  7. 漸進式發展
    所有的大型網際網路企業都不是一蹴而就的,也都是一點點發展起來的,這也符合網站架構演化型別的發展。

2.大型網站架構演化發展史

如上述最後一點所說,在大型網站系統的發展過程中,與網站架構相一致的是漸進式的發展型別,最直白的特點就是使用者量,訪問量和資料處理都有了大量的增加,針對這些問題,大型網站在架構上,在不斷解決這些問題。

  1. 初始階段的網站架構
    因為初始階段沒有大量的使用者資料與訪問需求,大型網站在初期一般都是一臺伺服器就足夠解決問題,通常使用的開發技術也是LAMP技術(Linux + Apache + MYSQL + PHP)此時的應用程式,資料庫與檔案等都在一臺伺服器上,這樣的開源的軟體加上一臺比較便宜的伺服器就足夠初期的開發了。

    初始階段的網站架構
    初始階段的網站架構

  2. 應用服務和資料服務分離
    隨著使用者訪問和業務處理需求的增加,導致儲存空間的不足,從而需要將應用和資料分離。此時,整個網站包括三臺伺服器:應用伺服器,檔案伺服器和資料庫伺服器。其中應用伺服器需要處理大量的業務,需要更快的CPU;檔案伺服器用來儲存使用者資料,需要更大的硬碟和更高的安全性;資料庫伺服器需要快速的磁碟檢索和資料快取,需要更快更大的記憶體和硬碟。

    應用服務和資料服務相分離
    應用服務和資料服務相分離

  3. 使用快取改善網站效能
    隨著使用者增多,資料庫面臨的壓力也越來越大,導致資料訪問延遲增加,從而影響網站效能和使用者的體驗。
    因此,根據二八定律,80%的業務訪問集中在20%的資料上,我們將這些資料快取在記憶體上,就可以減少資料庫的IO,提高網站的訪問速度。
    此處的快取主要包括兩種:1.快取在應用伺服器的本地快取。2.快取在專門的分散式快取伺服器上的遠端快取。其中本地快取的訪問速度更快,但是受到快取大小的約束;遠端的分散式快取可以使用叢集的方式,使用大記憶體的伺服器作為快取伺服器,從而不受記憶體大小的限制。當需要訪問的資料不再快取上時,我們才會訪問資料庫,但是訪問流量明顯會遠遠減少。

    使用快取改善網站效能
    使用快取改善網站效能

  4. 使用應用伺服器叢集改善網站的併發處理能力
    再解決資料庫IO的問題以後,當用戶流量更多時,單一的應用伺服器就成為了限制網站訪問速度的主要因素。
    因此,對應用伺服器使用叢集設計,可以在面對更大的使用者需求時系統可以具有可伸縮性,因此可以有效地改善負載壓力。
    其次,通過負載均衡排程伺服器,可以使得來自使用者的訪問請求均衡的分佈在叢集中,從而保證網站的響應速度。

    使用應用伺服器叢集改善網站的併發處理能力
    使用應用伺服器叢集改善網站的併發處理能力

  5. 資料庫讀寫分離
    當用戶訪問量進一步增加時,對於快取中的資料已不足以支援使用者的需求,部分的讀操作和全部的寫操作都需要訪問資料庫,從而資料庫因為負載壓力過大成為網站的瓶頸。
    所以我們採用資料庫的主從分離作為解決方法。即配置兩臺資料庫作為主從關係,從資料庫可以實時更新同步主資料庫的內容。當寫資料時,直接寫到主資料庫中,然後實時更新到從資料庫,讀資料時,直接在從資料庫中訪問資料。除此之外,為了便於應用程式訪問讀寫分離的資料庫,在應用伺服器埠加上了資料訪問模組,使讀寫分離對應用透明。

    資料庫讀寫分離
    資料庫讀寫分離

  6. 使用反向代理和CDN加速網站響應
    在複雜的網路環境中,使用者訪問網站的速度也差別很大。研究表明,網站的延遲與使用者流失成正相關。因此為了加速網站的訪問速度,我們主要採用CDN和反向代理。
    CDN和反向代理都是使用快取,但是CDN會部署在網路提供商的機房,使得使用者在訪問網站服務時,從最近的網路節點上獲取資料;反向代理是部署在網站的中心機房,當用戶請求到達中心機房時,會先訪問中心機房中的快取資料,如果匹配則直接返回給使用者。個人認為CDN是反向代理的延伸,反向代理初期被用來解決伺服器壓力和響應速度的問題,大規模部署反向代理時,如果都部署在一起,那麼頻寬和距離仍然是瓶頸,而異地部署則要考慮負載均衡的問題,解決了這些問題也就基本部署成CDN了。

    使用反向代理和CDN加速網站響應
    使用反向代理和CDN加速網站響應

  7. 使用分散式檔案系統和分散式資料庫系統
    對於持續增長的業務需求,資料庫讀寫分離後還不足以滿足網站的業務需求,這時候就需要分散式檔案系統和分散式資料庫。目前常用的資料庫拆分是業務拆分,將不同的業務的資料部署在不同的伺服器上。注意,此處應用程式的對於檔案伺服器和資料庫伺服器的介面合併,統稱為統一資料訪問模組。

    使用分散式檔案系統和分散式資料庫系統
    使用分散式檔案系統和分散式資料庫系統

  8. 使用NoSQL和搜尋引擎
    因為對於網站業務的需求越來越複雜,資料儲存和檢索的需求也越來越複雜,因此採用非關係資料庫技術如NoSQL和非資料庫查詢技術如搜尋引擎等。此處應用伺服器可以通過一個統一的資料訪問模組訪問各種資料。
    以下為個人認為比較好的NoSQL的說明。
    NoSQL說明

    使用NoSQL和搜尋引擎
    使用NoSQL和搜尋引擎

  9. 業務拆分
    隨著大型網站業務場景的複雜,我們一般通過分而治之的手段將整個網站分為不同的產品線,再針對不同的產品線拆分為不同的應用,每個應用都用獨立部署維護。應用之間可以通過訊息佇列進行資料併發,或者超連結建立聯絡。不過最多的還是通過訪問同一資料儲存系統來形成完整的系統。

    業務拆分
    業務拆分

  10. 分散式服務
    隨著應用系統的整體複雜程度的增加,部署維護起來就更加的困難,同時因為所有的資料庫要和應用進行連線,在數萬臺伺服器的網站規模下,需要連線的資料是資料庫的平方,這樣會導致資料庫連線資源不足。
    針對不同的應用系統都有相同的功能,我們將這些可複用的業務連線資料庫,用分散式服務呼叫共用業務完成具體操作。

    分散式服務
    分散式服務

3.大型網站架構演化的價值觀

在此小節中,主要說明了在大型網站演化的過程中,我們應當抱著怎麼的心態來面對基於當前需求的網站開發,畢竟,沒有任何一個網站是剛誕生就是大型網站。因此,主要有以下兩點核心的價值觀:

  1. 大型網站架構技術的核心價值是隨著網站所需靈活應對
    大型網站的核心價值是能夠伴隨著小型網站逐步進化為大型網站的流程,不能一蹴而就,應當遵循網站的具體所需進行開發。符合當前網站的開發背景與能力才是最主要的。
  2. 驅動大型網站技術發展的主要力量是網站業務發展
    總而言之一句話:“是業務成就了技術,是事業成就了人”應當對成就自己技術的網站進行感激,並努力提高技術進行回饋,才能在快速發展的網際網路行業中持續進步。

4.網站架構設計誤區

大型網站架構發展過程常有以下誤區:

  1. 一味追隨大公司的解決方案
  2. 為了技術而技術
  3. 企圖用技術解決所有問題
    此處主要針對第三點進行說明:比如12306在2012年初的故障後,真正的問題並不知在於其技術架構,還在於其業務架構。其不應該在數億人一票難求的情況下用視窗售票的方式在網上售票,如果銷售方式使用排隊,分時段售票,也就控制住併發量,需要問題也不需要技術上來解決了。
    因此,技術是用來解決業務問題的,業務也可以用來解決業務問題。