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

五柳-先生發表於2016-02-27

大型網站架構是一個系列文件,歡迎大家關注。本次分享主題:電商網站架構案例。從電商網站的需求,到單機架構,逐步演變為常用的,可供參考的分散式架構的原型。除具備功能需求外,還具備一定的高效能,高可用,可伸縮,可擴充套件等非功能質量需求(架構目標)。

根據實際需要,進行改造,擴充套件,支援千萬PV,是沒問題的。

本次分享大綱

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

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

一、電商案例的原因

分散式大型網站,目前看主要有幾類1.大型門戶,比如網易,新浪等;2.SNS網站,比如校內,開心網等;3.電商網站:比如阿里巴巴,京東商城,國美線上,汽車之家等。大型門戶一般是新聞類資訊,可以使用CDN,靜態化等方式優化,開心網等互動性比較多,可能會引入更多的NOSQL,分散式快取,使用高效能的通訊框架等。電商網站具備以上兩類的特點,比如產品詳情可以採用CDN,靜態化,互動性高的需要採用NOSQL等技術。因此,我們採用電商網站作為案例,進行分析。

二、電商網站需求

客戶需求:

  • 建立一個全品類的電子商務網站(B2C),使用者可以線上購買商品,可以線上支付,也可以貨到付款;
  • 使用者購買時可以線上與客服溝通;
  • 使用者收到商品後,可以給商品打分,評價;
  • 目前有成熟的進銷存系統;需要與網站對接;
  • 希望能夠支援3~5年,業務的發展;
  • 預計3~5年使用者數達到1000萬;
  • 定期舉辦雙11,雙12,三八男人節等活動;
  • 其他的功能參考京東或國美線上等網站。

客戶就是客戶,不會告訴你具體要什麼,只會告訴你他想要什麼,我們很多時候要引導,挖掘客戶的需求。好在提供了明確的參考網站。因此,下一步要進行大量的分析,結合行業,以及參考網站,給客戶提供方案。

其他的略~~~~~

需求功能矩陣

需求管理傳統的做法,會使用用例圖或模組圖(需求列表)進行需求的描述。這樣做常常忽視掉一個很重要的需求(非功能需求),因此推薦大家使用需求功能矩陣,進行需求描述。

本電商網站的需求矩陣如下:

 

網站需求

功能需求

非功能需求

全品類的電子商務網站

分類管理,商品管理

方便進行多品類管理(靈活性)

網站訪問速度要快(高效能)

圖片儲存的要求(海量小圖片)

使用者可以線上購買商品

會員管理,購物車,結算功能

良好購物體驗(可用性,效能)

線上支付或貨到付款

多種線上支付方式

支付過程要安全,資料加密(安全性)

多種支付介面靈活切換(靈活性,擴充套件性)

可以線上與客服溝通

線上客服功能

可靠性:即時通訊

商品打分評價

商品評論

 

目前有成熟的進銷存系統

對接進銷存

屬於約束條件

對接時要考慮資料一致性,魯棒性

支援3~5年,業務的發展

 

屬於約束條件

伸縮性,可擴充套件性

3~5年使用者數達到1000萬

 

約束條件

舉辦雙11,雙12,三八男人節等活動

活動管理,秒殺

突增訪問流量(可伸縮)

實時性要求(高效能)

參考京東或國美線上

 

參考條件

 

 

 

 

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

 

三、網站初級架構

一般網站,剛開始的做法,是三臺伺服器,一臺部署應用,一臺部署資料庫,一臺部署NFS檔案系統。

這是前幾年比較傳統的做法,之前見到一個網站10萬多會員,垂直服裝設計門戶,N多圖片。使用了一臺伺服器部署了應用,資料庫以及圖片儲存。出現了很多效能問題。

如下圖:

 

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

 

(1)       使用叢集對應用伺服器進行冗餘,實現高可用;(負載均衡裝置可與應用一塊部署)

使用資料庫主備模式,實現資料備份和高可用;

四、系統容量預估

預估步驟:

(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,硬碟,網路等不再進行評估。

 

分享是快樂的,也是個人成長的過程。文章一般是自己的學習總結,工作經驗,不足之處在所難免,請大家指正,共同進步。建立了一個以架構為中心的KK群466097527 ,歡迎大家加入。專注大型分散式網站架構,大資料,架構模式,設計模式。

相關文章