大型網站架構

大型網站架構是一個系列文檔，歡迎你們關注。本次分享主題：電商網站架構案例。從電商網站的需求，到單機架構，逐步演變爲經常使用的，可供參考的分佈式架構的原型。除具有功能需求外，還具有必定的高性能，高可用，可伸縮，可擴展等非功能質量需求（架構目標）。

根據實際須要，進行改造，擴展，支持千萬PV，是沒問題的。

本次分享大綱 電商案例的緣由 電商網站需求 網站初級架構 系統容量估算 網站架構分析 網站架構優化 架構總結 電商網站案例，一共有三篇本篇主要說明網站的需求，網站初始架構，系統容量估算方法。

1、電商案例的緣由 分佈式大型網站，目前看主要有幾類1.大型門戶，好比網易，新浪等；2.SNS網站，好比校內，開心網等；3.電商網站：好比阿里巴巴，京東商城，國美在線，汽車之家等。大型門戶通常是新聞類信息，可使用CDN，靜態化等方式優化，開心網等交互性比較多，可能會引入更多的NOSQL，分佈式緩存，使用高性能的通訊框架等。電商網站具有以上兩類的特色，好比產品詳情能夠採用CDN，靜態化，交互性高的須要採用NOSQL等技術。所以，咱們採用電商網站做爲案例，進行分析。

2、電商網站需求 客戶需求：

創建一個全品類的電子商務網站（B2C），用戶能夠在線購買商品，能夠在線支付，也能夠貨到付款； 用戶購買時能夠在線與客服溝通； 用戶收到商品後，能夠給商品打分，評價； 目前有成熟的進銷存系統；須要與網站對接； 但願可以支持3~5年，業務的發展； 預計3~5年用戶數達到1000萬； 按期舉辦雙11，雙12,三八男人節等活動； 其餘的功能參考京東或國美在線等網站。 客戶就是客戶，不會告訴你具體要什麼，只會告訴你他想要什麼，咱們不少時候要引導，挖掘客戶的需求。好在提供了明確的參考網站。所以，下一步要進行大量的分析，結合行業，以及參考網站，給客戶提供方案。

其餘的略~~~~~

需求功能矩陣

需求管理傳統的作法，會使用用例圖或模塊圖（需求列表）進行需求的描述。這樣作經常忽視掉一個很重要的需求（非功能需求），所以推薦你們使用需求功能矩陣，進行需求描述。

本電商網站的需求矩陣以下：

網站需求 功能需求 非功能需求 全品類的電子商務網站 分類管理，商品管理 方便進行多品類管理（靈活性）網站訪問速度要快（高性能） 圖片存儲的要求（海量小圖片）用戶能夠在線購買商品會員管理，購物車，結算功能良好購物體驗（可用性，性能）在線支付或貨到付款多種在線支付方式支付過程要安全，數據加密（安全性）多種支付接口靈活切換（靈活性，擴展性）能夠在線與客服溝通在線客服功能可靠性：即時通信商品打分評價商品評論 目前有成熟的進銷存系統對接進銷存屬於約束條件對接時要考慮數據一致性，魯棒性支持3~5年，業務的發展 屬於約束條件伸縮性，可擴展性3~5年用戶數達到1000萬 約束條件舉辦雙11，雙12,三八男人節等活動活動管理，秒殺突增訪問流量（可伸縮）實時性要求（高性能）參考京東或國美在線 參考條件

以上是對電商網站需求的簡單舉例，目的是說明（1）需求分析的時候，要全面，大型分佈式系統重點考慮非功能需求；（2）描述一個簡單的電商需求場景，使你們對下一步的分析設計有個依據。

3、網站初級架構 通常網站，剛開始的作法，是三臺服務器，一臺部署應用，一臺部署數據庫，一臺部署NFS文件系統。

這是前幾年比較傳統的作法，以前見到一個網站10萬多會員，垂直服裝設計門戶，N多圖片。使用了一臺服務器部署了應用，數據庫以及圖片存儲。出現了不少性能問題。

以下圖：

可是，目前主流的網站架構已經發生了翻天覆地的變化。通常都會採用集羣的方式，進行高可用設計。至少是下面這個樣子。

（1） 使用集羣對應用服務器進行冗餘，實現高可用；（負載均衡設備可與應用一塊部署）

使用數據庫主備模式，實現數據備份和高可用；

4、系統容量預估 預估步驟：

註冊用戶數-日均UV量-每日的PV量-天天的併發量； 峯值預估：日常量的2~3倍； 根據併發量（併發，事務數），存儲容量計算系統容量。 客戶需求：3~5年用戶數達到1000萬註冊用戶；

每秒併發數預估：

天天的UV爲200萬（二八原則）； 每日天天點擊瀏覽30次； PV量：20030=6000萬； 集中訪問量：240.2=4.8小時會有6000萬0.8=4800萬（二八原則）； 每分併發量：4.860=288分鐘，每分鐘訪問4800/288=16.7萬（約等於）； 每秒併發量：16.7萬/60=2780（約等於）； 假設：高峯期爲日常值的三倍，則每秒的併發數能夠達到8340次。 1毫秒=1.3次訪問； 沒好好學數學後悔了吧？！（不知道以上算是否有錯誤，呵呵~~）

服務器預估：（以tomcat服務器舉例）

按一臺web服務器，支持每秒300個併發計算。日常須要10臺服務器（約等於）；[tomcat默認配置是150] 高峯期：須要30臺服務器； 容量預估：70/90原則

系統CPU通常維持在70%左右的水平，高峯期達到90%的水平，是不浪費資源，並比較穩定的。內存，IO相似。

以上預估僅供參考，由於服務器配置，業務邏輯複雜度等都有影響。在此CPU，硬盤，網絡等再也不進行評估。

5、網站架構分析

根據以上預估，有幾個問題：

須要部署大量的服務器，高峯期計算，可能要部署30臺Web服務器。而且這三十臺服務器，只有秒殺，活動時纔會用到，存在大量的浪費。 全部的應用部署在同一臺服務器，應用之間耦合嚴重。須要進行垂直切分和水平切分。 大量應用存在冗餘代碼 服務器SESSION同步耗費大量內存和網絡帶寬 數據須要頻繁訪問數據庫，數據庫訪問壓力巨大。 大型網站通常須要作如下架構優化（優化是架構設計時，就要考慮的，通常從架構/代碼級別解決，調優主要是簡單參數的調整，好比JVM調優；若是調優涉及大量代碼改造，就不是調優了，屬於重構）：

業務拆分 應用集羣部署（分佈式部署，集羣部署和負載均衡） 多級緩存 單點登陸（分佈式Session） 數據庫集羣（讀寫分離，分庫分表） 服務化 消息隊列 其餘技術 6、網站架構優化 6.1業務拆分

根據業務屬性進行垂直切分，劃分爲產品子系統，購物子系統，支付子系統，評論子系統，客服子系統，接口子系統（對接如進銷存，短信等外部系統）。

根據業務子系統進行等級定義，可分爲核心系統和非核心繫統。核心系統：產品子系統，購物子系統，支付子系統；非核心：評論子系統，客服子系統，接口子系統。

業務拆分做用：提高爲子系統可由專門的團隊和部門負責，專業的人作專業的事，解決模塊之間耦合以及擴展性問題；每一個子系統單獨部署，避免集中部署致使一個應用掛了，所有應用不可用的問題。

等級定義做用：用於流量突發時，對關鍵應用進行保護，實現優雅降級；保護關鍵應用不受到影響。

拆分後的架構圖：

參考部署方案2

如上圖每一個應用單獨部署 核心系統和非核心繫統組合部署 6.2應用集羣部署（分佈式，集羣，負載均衡）

分佈式部署：將業務拆分後的應用單獨部署，應用直接經過RPC進行遠程通訊；

集羣部署：電商網站的高可用要求，每一個應用至少部署兩臺服務器進行集羣部署；

負載均衡：是高可用系統必須的，通常應用經過負載均衡實現高可用，分佈式服務經過內置的負載均衡實現高可用，關係型數據庫經過主備方式實現高可用。

集羣部署後架構圖：

6.3 多級緩存

緩存按照存放的位置通常可分爲兩類本地緩存和分佈式緩存。本案例採用二級緩存的方式，進行緩存的設計。一級緩存爲本地緩存，二級緩存爲分佈式緩存。（還有頁面緩存，片斷緩存等，那是更細粒度的劃分）

一級緩存，緩存數據字典，和經常使用熱點數據等基本不可變/有規則變化的信息，二級緩存緩存須要的全部緩存。當一級緩存過時或不可用時，訪問二級緩存的數據。若是二級緩存也沒有，則訪問數據庫。

緩存的比例，通常1:4，便可考慮使用緩存。（理論上是1:2便可）。

根據業務特性可以使用如下緩存過時策略：

緩存自動過時； 緩存觸發過時； 6.4單點登陸（分佈式Session）

系統分割爲多個子系統，獨立部署後，不可避免的會遇到會話管理的問題。通常可採用Session同步，Cookies，分佈式Session方式。電商網站通常採用分佈式Session實現。

再進一步能夠根據分佈式Session，創建完善的單點登陸或帳戶管理系統。

流程說明

用戶第一次登陸時，將會話信息（用戶Id和用戶信息），好比以用戶Id爲Key，寫入分佈式Session； 用戶再次登陸時，獲取分佈式Session，是否有會話信息，若是沒有則調到登陸頁； 通常採用Cache中間件實現，建議使用Redis，所以它有持久化功能，方便分佈式Session宕機後，能夠從持久化存儲中加載會話信息； 存入會話時，能夠設置會話保持的時間，好比15分鐘，超事後自動超時； 結合Cache中間件，實現的分佈式Session，能夠很好的模擬Session會話。

6.5數據庫集羣（讀寫分離，分庫分表）

大型網站須要存儲海量的數據，爲達到海量數據存儲，高可用，高性能通常採用冗餘的方式進行系統設計。通常有兩種方式讀寫分離和分庫分表。

讀寫分離：通常解決讀比例遠大於寫比例的場景，可採用一主一備，一主多備或多主多備方式。

本案例在業務拆分的基礎上，結合分庫分表和讀寫分離。以下圖：

業務拆分後：每一個子系統須要單獨的庫； 若是單獨的庫太大，能夠根據業務特性，進行再次分庫，好比商品分類庫，產品庫； 分庫後，若是表中有數據量很大的，則進行分表，通常能夠按照Id，時間等進行分表；（高級的用法是一致性Hash） 在分庫，分表的基礎上，進行讀寫分離； 相關中間件可參考Cobar（阿里，目前已不在維護），TDDL（阿里），Atlas（奇虎360），MyCat（在Cobar基礎上，國內不少牛人，號稱國內第一開源項目）。

分庫分表後序列的問題，JOIN，事務的問題，會在分庫分表主題分享中，介紹。

6.6服務化

將多個子系統公用的功能/模塊，進行抽取，做爲公用服務使用。好比本案例的會員子系統就能夠抽取爲公用的服務。

6.7消息隊列

消息隊列能夠解決子系統/模塊之間的耦合，實現異步，高可用，高性能的系統。是分佈式系統的標準配置。本案例中，消息隊列主要應用在購物，配送環節。

用戶下單後，寫入消息隊列，後直接返回客戶端； 庫存子系統：讀取消息隊列信息，完成減庫存； 配送子系統：讀取消息隊列信息，進行配送；

目前使用較多的MQ有Active MQ,Rabbit MQ,Zero MQ，MS MQ等，須要根據具體的業務場景進行選擇。建議能夠研究下Rabbit MQ。

6.8其餘架構（技術）

除了以上介紹的業務拆分，應用集羣，多級緩存，單點登陸，數據庫集羣，服務化，消息隊列外。還有CDN，反向代理，分佈式文件系統，大數據處理等系統。

此處不詳細介紹，你們能夠問度娘/Google，有機會的話也能夠分享給你們。

7、架構總結

以上是本次分享的架構總結，其中細節可參考前面分享的內容。其中還有不少能夠優化和細化的地方，由於是案例分享，主要針對重要部分作了介紹，工做中須要你們根據具體的業務場景進行架構設計。

以上是電商網站架構案例的分享一共有三篇，從電商網站的需求，到單機架構，逐步演變爲經常使用的，可供參考的分佈式架構的原型。除具有功能需求外，還具有必定的高性能，高可用，可伸縮，可擴展等非功能質量需求（架構目標）。

2.網站技術架構示例 最近我在閱讀 2 本關於大型網站架構的書：《大型網站技術架構——核心原理與案例分析》李智慧、《大型網站系統與 Java 中間件實踐》曾憲傑。

我指望從這些書中學習到大型網站是如何作架構的，這個過程會遇到什麼問題。當看完這 2 本書後，我總結出兩個大問題：

1. 網站技術架構爲何會演進？換個說法就是爲何網站會變大？

2. 演進的過程會遇到什麼問題？或者說爲了演進，會遇到什麼問題？

網站技術架構爲何會演進

我我的總結出來咱們的技術架構演進的兩種驅動力，驅動着咱們爲何演進網站的技術架構：

1. 內在驅動力：咱們指望把當前的業務作得更好，開發更多新業務

2. 外在驅動力：用戶量的上升、用戶種類的多樣化

這兩種驅動力不是獨立的，更多時候是並行的。我想淘寶就是兩種驅動力並行驅動的結果。

演進的緣由很簡單。可是在什麼時機咱們就應該演進網站的技術架構了，以及如何演進？面對這些問題，說實話，我沒有任何經驗，再說現實中每家企業當時都面臨的問題都不同，因此，我很難從經驗中總結出什麼是演進的時機。

可是我能夠從另外一個角度切入這個問題：研究網站內外結構，找到這些結構可能出現的問題點，知道或者預見到問題點了，你固然就知道應該怎麼演進了。相似於你瞭解了 PC 機的結構，你也就知道何時要加內存了，何時要加硬盤了。

那麼咱們先看看網站的外部結構：

外部結構中，咱們能夠看由如下幾個部分構成：

U：表明用戶羣。當用戶羣變了，咱們的網站如何演進？用戶羣的分析，我目前能知道的維度有：數量，種類，地理位置（區域）。

N：表明網絡環境。網絡環境在每一個地區都不一樣。你能夠想像咱們爲何須要 CDN。當咱們指望每一個區域的用戶都能獲得好的體驗，咱們的網站如何演進？

S：表明安全。就是咱們要安全到什麼程度？這與網站當前所處階段及你網站的性質有關。

C：表明咱們的網站。屬於內部結構

網站的內部結構：

內部結構的組成：

A：應用服務。

D：數據服務

總結下來就是咱們在考慮網站是否應該演進了或者如何演進時，這些組成部分爲咱們提供了考慮問題的基準。

那麼咱們爲何不一開始就把網站設計成「大型」的。李智慧在後記裏寫到：「不要企圖去設計一個大型網站」，「緣由是互聯網發展運行有其本身的規律，短暫的互聯網歷史已經一再證實這種企圖行不通」。還說了：「大型網站不是設計出來的，而是逐步演化出來的」。對於最後這句話，我須要提醒下：「不是設計出來的」並不表明「隨意設計」。

對於「大型網站的設計」，我我的的見解是如今咱們的有「雲」了，計算是能夠買的，只要咱們的設計能適應「雲」，我是否是就能夠一開始就設計大型網站了？

演進的過程會遇到什麼問題

- 最初

從一個小網站提及。一臺服務器也就足夠了。

- 數據服務與應用服務分離

愈來愈多的用戶表明着愈來愈多的數據，一臺服務器已經知足不了。咱們將數據服務和應用服務分離，給應用服務器配置更好的 CPU，內存。而給數據服務器配置更好更大的硬盤。

- 使用緩存

由於 80% 的業務訪問都集中在 20% 的數據上，若是咱們能將這部分數據緩存下來，性能一會兒就上來了。而緩存又分爲兩種：本地緩存和遠程分佈式緩存。具體使用哪一種？仍是兩種都用，我目前不知道。

這裏有一個問題，書沒有提到：應該緩存哪些數據？應該有一些原則的吧。

- 使用服務器集羣

當這臺服務器的處理能力達到上限時，它就會成爲瓶頸。雖然你是能夠經過購買更強大的硬件，但總會有上限。這時，咱們就須要服務器的集羣。這時，就必須加個新東西：負載均衡調度服務器。

可是，使用服務器集羣時，須要考慮一個問題：Session 的管理問題。Session 的管理有如下幾種方式：

Session Sticky：打個比方就是若是咱們每次吃飯都要保證咱們用的是本身的碗筷，而只要咱們在一家飯店裏存着咱們的碗筷，只要咱們每次去這家飯店吃飯就行了。

這種方式的問題：

1. 一臺服務器重啓，上面的 session 都沒了

2. 負載均衡器成了有狀態的機器，要實現容災會有麻煩

Session 複製：就像咱們在全部的飯店裏都存一份本身的碗筷。不適合作大規模集羣，適合機器很少的狀況

這種方案的問題：

1. 應用服務器間帶寬問題

2. 大量用戶在線時，佔用內存過多

基於 Cookie：相似於每次吃飯都把本身的碗筷帶上

這種方案的問題：

1. Cookie 的長度限制

2. 安全性

3. 數據中心外部帶寬的消耗

4. 性能影響，服務器處理每次的請求的內容又多了

Session 服務器：一樣能夠是集羣的。這種方式適用於 session 數量及 web 服務器數量大的狀況

這種方案須要考慮的是：

1. 保證 session 服務器的可用性

2. 咱們在寫應用時須要作調整，我目前不知道應用服務器可否將這部分邏輯透明化

- 數據庫讀寫分離

數據庫的一部分讀（未緩存、緩存過時）及全部的寫操做都還須要通過數據庫。當用戶量達到必定量，數據庫將會成爲瓶頸。這邊咱們使用數據庫提供的熱備功能，將全部的讀操做引入 slave 服務器。注意：讀寫分離解決的是讀壓力大的問題。

由於數據庫的讀寫分離了，因此，咱們的應用程序也得作相應的變化。咱們實現一個數據訪問模塊使上層寫代碼的人不知道讀寫分離的存在。這裏，我很想知道若是我使用 ORM 模型時，如何實現讀寫的分離？

數據庫讀寫分離會遇到以下問題：

數據複製問題： 考慮時延、數據庫的支持、複製條件支持。不要忘了，分機房後，這個更是問題。 應用對於數據源的路由問題 　　- 使用反向代理和 CDN 加速網站響應

使用 CDN 能夠很好的解決不一樣的地區的訪問速度問題，反向代理則在服務器機房中緩存用戶資源：

- 使用分佈式文件系統

- 數據庫專庫專用：數據垂直拆分。

這樣能夠解決部分數據寫的問題

垂直拆分數據庫時，會遇到的問題：

跨業務的事務 應用的配置項多了 　　關於事務的問題，有兩種辦法：

使用分佈式事務 去掉事務或不追求強事務 　　- 某個業務的數據表的數據量或者更新量達到了單個數據庫的瓶頸：數據水平拆分

將同一個表的數據拆分到兩個數據庫中

數據水平拆分會遇到的問題：

SQL 的路由問題，須要知道某個 User 在哪一個數據庫上。 主鍵的策略會有不一樣。 查詢時的性能問題，如分頁問題

使用搜索引擎：解決數據查詢問題 部分場景可以使用 NoSQL 提升性能 開發數據統一訪問模塊：解決上層應用開發的數據源問題

- 業務拆分及應用拆分

網站的業務日益複雜，創建一個獨立的大型應用來完成這全部的業務變得不實際。從管理角度來，也不方便管理。然而，業務的拆分很難找到一種通用的模式，這是一個企業管理問題和技術問題的混合問題。同時和每一個企業的具體狀況有關。

可是從這兩本書來看，最終架構都走向服務化，也就是 SOA。而如何實現 SOA，是另外一個很大的話題，不是本篇文章的範疇。

我從程立 08 年的演講中截個圖來講明 SOA 後的架構大概是怎樣的：

- 非功能性問題

– 安全性問題、監控問題

– 發佈問題：新的架構意味着新的發佈方式

– 分機房

– 這兩本書都沒有說分機房的問題。我沒有經驗，但是也能夠猜到若是要分機房了，全部上面的問題均可能要從新考慮。

– 組織架構的變化

咱們的技術架構的變化，勢必會引發咱們的組織架構的變化，反之亦然。

這部分看似不該該由咱們來管，可是，我以爲，咱們技術人員也要參與一部分的組織架構的設計。舉個例子，組織架構的設計會涉及績效，而績效有時很像一個國家的法律。若是一個國家的法律不健全，會發生什麼？你懂的。

同時，咱們還必須考慮人員對新架構的學習成本。

這部分我目前在看相關的書籍，尚未一個系統的認識。

總結：

- 關於演進的順序

在現實中，技術架構的演進不必定就是按文章從頭至尾這樣列下來的，因此，要視具體狀況來下決定。

- 關於傳統演進與現代有「雲」環境下的演進

很惋惜，只有李智慧談到雲，並且只點了一下——「如今愈來愈多人的網站從創建之初就是搭建在大型網站提供的雲計算服務基礎之上，所需的一切資源：計算、存儲、網絡均可以按需購買線性伸縮，不須要本身一點一點地拼湊各類資源，綜合使用各類技術方案逐步去完善本身的網站架構」。

由於我用「雲」的時間也不長，還不能總結出有云架構與傳統的無雲架構在演進的時候有什麼不一樣。

說回傳統的架構演進，我本身總結和思考的結果是：

在對網站進行架構調整時，能夠從兩大的維度考慮：數據服務和應用服務。而這個調整的過程當中，須要分清當前哪一個點是瓶頸，須要知道哪一個點優化的優先級最高。同時，最重要的一點：咱們雖然做爲技術人員，也應該去學習業務知識，這樣咱們在考慮問題時分清哪些是業務問題，哪些是技術問題，分清後才能對症下藥。你要知道有些問題用技術手段並不比用業務手段更有效。12306 的分時賣票就是一個典型例子。