1. 程式人生 > >大型網站架構系列:電商網站架構案例(1)

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

數學 pac 一致性 邏輯 tomcat服務器 部署 電商 小時 原型

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

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

根據實際需要,進行改造,擴展,支持千萬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,硬盤,網絡等不再進行評估。

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