大型網站架構系列：電商網站架構案例(1)

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

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

本次分享大綱

1. 電商案例的緣由
2. 電商網站需求
3. 網站初級架構
4. 系統容量估算
5. 網站架構分析
6. 網站架構優化
7. 架構總結
   
   

電商網站案例，一共有三篇本篇主要說明網站的需求，網站初始架構，系統容量估算方法。

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、系統容量預估

預估步驟：

（1）       註冊用戶數-日均UV量-每日的PV量-天天的併發量；

（2）       峯值預估：日常量的2~3倍；

（3）       根據併發量（併發，事務數），存儲容量計算系統容量。

 

客戶需求：3~5年用戶數達到1000萬註冊用戶；

 

每秒併發數預估：

（1）       天天的UV爲200萬（二八原則）；

（2）       每日天天點擊瀏覽30次；

（3）       PV量：200*30=6000萬；

（4）       集中訪問量：24*0.2=4.8小時會有6000萬*0.8=4800萬（二八原則）；

（5）       每分併發量：4.8*60=288分鐘，每分鐘訪問4800/288=16.7萬（約等於）；

（6）       每秒併發量：16.7萬/60=2780（約等於）；

（7）       假設：高峯期爲日常值的三倍，則每秒的併發數能夠達到8340次。

（8）       1毫秒=1.3次訪問；

 

沒好好學數學後悔了吧？！（不知道以上算是否有錯誤，呵呵~~）

 

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

（1）       按一臺web服務器，支持每秒300個併發計算。日常須要10臺服務器（約等於）；[tomcat默認配置是150]

（2）       高峯期：須要30臺服務器；

 

容量預估：70/90原則

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

 

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