電商行業技術特點；
①技術新：(NoSql推廣首在社區網站和(hé)電商項目)，發展快，需求推動技術的(de)革新。

②技術範圍廣：除了java，像淘寶前端還使用了PHP，數據庫MySQL或者oracle，nosql，服務器端使用Linux，服務器安全、系統安全

③分布式：以前是在一(yī)台機器上做(zuò)運算，現在是分散到很多機器上，最後彙總起來。(集中式向分布式進行考慮)由需求來推動

④高(gāo)并發、集群、負載均衡、高(gāo)可(kě)用：由并發問題采用集群進行處理(lǐ)，其中，集群會涉及服務器的(de)主從以及分布問題，使用負載均衡。(權重高(gāo)低(dī))高(gāo)可(kě)用是對用戶而言，用戶的(de)服務不中斷(系統升級，服務不中斷，淘寶每周更新2次)。

⑤海量數據：雙11,570億的(de)背後，訂單有多少？浏覽次數有多少？商品會有多少？活動相關數據？

⑥業務複雜：不要簡單的(de)認為(wèi)是：商品展示出來後，加入購物車後購買就完成了。後台特别複雜，比如(rú)優惠(包郵、滿減)

⑦系統安全：系統上線必須通過系統安全部門審核通過。前年(nián)CSDN數據洩露。快捷酒店數據洩露(通過身份證就可(kě)以查看你的(de)開房記錄)。近幾年(nián)，安全意識逐步在提高(gāo)。

電商網站需求；

客戶需求：

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

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

需求功能矩陣

需求管理(lǐ)傳統的(de)做(zuò)法，會使用用例圖或模塊圖（需求列表）進行需求的(de)描述。這樣做(zuò)常常忽視(shì)掉一(yī)個很重要的(de)需求（非功能需求），因此推薦大家使用需求功能矩陣，進行需求描述。

圖片存儲的(de)要求（海量小圖片）用戶可(kě)以在線購買商品會員管理(lǐ)，購物車，結算功能良好購物體驗（可(kě)用性，性能）在線支付或貨到付款多種在線支付方式支付過程要安全，數據加密（安全性）多種支付接口靈活切換（靈活性，擴展性）可(kě)以在線與客服溝通在線客服功能可(kě)靠性：即時通訊商品打分評價商品評論 目前有成熟的(de)進銷存系統對接進銷存屬于約束條件對接時要考慮數據一(yī)緻性，魯棒性支持3~5年(nián)，業務的(de)發展 屬于約束條件伸縮性，可(kě)擴展性3~5年(nián)用戶數達到1000萬 約束條件舉辦雙11，雙12,三八男人節等活動活動管理(lǐ)，秒殺突增訪問流量（可(kě)伸縮）實時性要求（高(gāo)性能）參考京東或國(guó)美在線 參考條件

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

、網站初級架構

一(yī)般網站，剛開始的(de)做(zuò)法，是三台服務器，一(yī)台部署應用，一(yī)台部署數據庫，一(yī)台部署NFS文件系統。

這是前幾年(nián)比較傳統的(de)做(zuò)法，之前見到一(yī)個網站10萬多會員，垂直服裝設計門戶，N多圖片。使用了一(yī)台服務器部署了應用，數據庫以及圖片存儲。出現了很多性能問題。

如(rú)下圖：

但是，目前主流的(de)網站架構已經發生了翻天覆地(dì)的(de)變化。一(yī)般都會采用集群的(de)方式，進行高(gāo)可(kě)用設計。至少是下面這個樣子(zǐ)。

（1）       使用集群對應用服務器進行冗餘，實現高(gāo)可(kě)用；（負載均衡設備可(kě)與應用一(yī)塊部署）

使用數據庫主備模式，實現數據備份和(hé)高(gāo)可(kě)用；
、系統容量預估

預估步驟：

    注冊用戶數-日均UV量-每日的(de)PV量-每天的(de)并發量；
    峰值預估：平常量的(de)2~3倍；
    根據并發量（并發，事務數），存儲容量計算系統容量。

客戶需求：3~5年(nián)用戶數達到1000萬注冊用戶；

每秒并發數預估：

    每天的(de)UV為(wèi)200萬（二八原則）；
    每日每天點擊浏覽30次；
    PV量：200*30=6000萬；
    集中訪問量：24*0.2=4.8小時會有6000萬*0.8=4800萬（二八原則）；
    每分并發量：4.8*60=288分鍾，每分鍾訪問4800/288=16.7萬（約等于）；
    每秒并發量：16.7萬/60=2780（約等于）；
    假設：高(gāo)峰期為(wèi)平常值的(de)三倍，則每秒的(de)并發數可(kě)以達到8340次。
    1毫秒=1.3次訪問；

沒好好學(xué)數學(xué)後悔了吧(ba)？！（不知道(dào)以上算是否有錯誤，呵呵~~）

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

    按一(yī)台web服務器，支持每秒300個并發計算。平常需要10台服務器（約等于）；[tomcat默認配置是150]
    高(gāo)峰期：需要30台服務器；

容量預估：70/90原則

系統CPU一(yī)般維持在70%左右的(de)水平，高(gāo)峰期達到90%的(de)水平，是不浪費資源，并比較穩定的(de)。內(nèi)存，IO類似。

以上預估僅供參考，因為(wèi)服務器配置，業務邏輯複雜度等都有影響。在此CPU，硬盤，網絡等不再進行評估。

、網站架構分析

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

    需要部署大量的(de)服務器，高(gāo)峰期計算，可(kě)能要部署30台Web服務器。并且這三十台服務器，隻有秒殺，活動時才會用到，存在大量的(de)浪費。
    所有的(de)應用部署在同一(yī)台服務器，應用之間耦合嚴重。需要進行垂直切分和(hé)水平切分。
    大量應用存在冗餘代碼
    服務器SESSION同步耗費大量內(nèi)存和(hé)網絡帶寬
    數據需要頻繁訪問數據庫，數據庫訪問壓力巨大。

大型網站一(yī)般需要做(zuò)以下架構優化（優化是架構設計時，就要考慮的(de)，一(yī)般從架構/代碼級别解決，調優主要是簡單參數的(de)調整，比如(rú)JVM調優；如(rú)果調優涉及大量代碼改造，就不是調優了，屬于重構）：

    業務拆分
    應用集群部署（分布式部署，集群部署和(hé)負載均衡）
    多級緩存
    單點登錄（分布式Session）
    數據庫集群（讀寫分離(lí)，分庫分表）
    服務化
    消息隊列
    其他技術

、網站架構優化
1業務拆分

根據業務屬性進行垂直切分，劃分為(wèi)産品子(zǐ)系統，購物子(zǐ)系統，支付子(zǐ)系統，評論子(zǐ)系統，客服子(zǐ)系統，接口子(zǐ)系統（對接如(rú)進銷存，短(duǎn)信等外部系統）。

根據業務子(zǐ)系統進行等級定義，可(kě)分為(wèi)核心系統和(hé)非核心系統。核心系統：産品子(zǐ)系統，購物子(zǐ)系統，支付子(zǐ)系統；非核心：評論子(zǐ)系統，客服子(zǐ)系統，接口子(zǐ)系統。

業務拆分作用：提升為(wèi)子(zǐ)系統可(kě)由專門的(de)團隊和(hé)部門負責，專業的(de)人做(zuò)專業的(de)事，解決模塊之間耦合以及擴展性問題；每個子(zǐ)系統單獨部署，避免集中部署導緻一(yī)個應用挂了，全部應用不可(kě)用的(de)問題。

等級定義作用：用于流量突發時，對關鍵應用進行保護，實現優雅降級；保護關鍵應用不受到影響。
2應用集群部署（分布式，集群，負載均衡）

分布式部署：将業務拆分後的(de)應用單獨部署，應用直接通過RPC進行遠程通信；

集群部署：電商網站的(de)高(gāo)可(kě)用要求，每個應用至少部署兩台服務器進行集群部署；

負載均衡：是高(gāo)可(kě)用系統必須的(de)，一(yī)般應用通過負載均衡實現高(gāo)可(kě)用，分布式服務通過內(nèi)置的(de)負載均衡實現高(gāo)可(kě)用，關系型數據庫通過主備方式實現高(gāo)可(kě)用。

3 多級緩存

緩存按照存放的(de)位置一(yī)般可(kě)分為(wèi)兩類本地(dì)緩存和(hé)分布式緩存。本案例采用二級緩存的(de)方式，進行緩存的(de)設計。一(yī)級緩存為(wèi)本地(dì)緩存，二級緩存為(wèi)分布式緩存。（還有頁面緩存，片段緩存等，那是更細粒度的(de)劃分）

一(yī)級緩存，緩存數據字典，和(hé)常用熱點數據等基本不可(kě)變/有規則變化的(de)信息，二級緩存緩存需要的(de)所有緩存。當一(yī)級緩存過期或不可(kě)用時，訪問二級緩存的(de)數據。如(rú)果二級緩存也沒有，則訪問數據庫。

緩存的(de)比例，一(yī)般1:4，即可(kě)考慮使用緩存。（理(lǐ)論上是1:2即可(kě)）。

4，單點登錄（分布式Session）

系統分割為(wèi)多個子(zǐ)系統，獨立部署後，不可(kě)避免的(de)會遇到會話管理(lǐ)的(de)問題。一(yī)般可(kě)采用Session同步，Cookies，分布式Session方式。電商網站一(yī)般采用分布式Session實現。

再進一(yī)步可(kě)以根據分布式Session，建立完善的(de)單點登錄或賬戶管理(lǐ)系統。

流程說明

    用戶第一(yī)次登錄時，将會話信息（用戶Id和(hé)用戶信息），比如(rú)以用戶Id為(wèi)Key，寫入分布式Session；
    用戶再次登錄時，獲取分布式Session，是否有會話信息，如(rú)果沒有則調到登錄頁；
    一(yī)般采用Cache中間件實現，建議使用Redis，因此它有持久化功能，方便分布式Session宕機後，可(kě)以從持久化存儲中加載會話信息；
    存入會話時，可(kě)以設置會話保持的(de)時間，比如(rú)15分鍾，超過後自(zì)動超時；

結合Cache中間件，實現的(de)分布式Session，可(kě)以很好的(de)模拟Session會話。

數據庫集群（讀寫分離(lí)，分庫分表）

大型網站需要存儲海量的(de)數據，為(wèi)達到海量數據存儲，高(gāo)可(kě)用，高(gāo)性能一(yī)般采用冗餘的(de)方式進行系統設計。一(yī)般有兩種方式讀寫分離(lí)和(hé)分庫分表。

讀寫分離(lí)：一(yī)般解決讀比例遠大于寫比例的(de)場景，可(kě)采用一(yī)主一(yī)備，一(yī)主多備或多主多備方式。

本案例在業務拆分的(de)基礎上，結合分庫分表和(hé)讀寫分離(lí)

    業務拆分後：每個子(zǐ)系統需要單獨的(de)庫；
    如(rú)果單獨的(de)庫太大，可(kě)以根據業務特性，進行再次分庫，比如(rú)商品分類庫，産品庫；
    分庫後，如(rú)果表中有數據量很大的(de)，則進行分表，一(yī)般可(kě)以按照Id，時間等進行分表；（高(gāo)級的(de)用法是一(yī)緻性Hash）
    在分庫，分表的(de)基礎上，進行讀寫分離(lí)；

相關中間件可(kě)參考Cobar（阿裏，目前已不在維護），TDDL（阿裏），Atlas（奇虎360），MyCat（在Cobar基礎上，國(guó)內(nèi)很多牛人，号稱國(guó)內(nèi)第一(yī)開源項目）。

電商網站後台功能模塊分析；

後台：各類主要信息的(de)概要統計，包括客戶信息、 訂單信息、商品信息、庫存信息、評論和(hé)最近反饋等。

商品模塊：

 1.商品管理(lǐ)：商品和(hé)商品包的(de)添加、修改、 删除、複制、批處理(lǐ)、商品計劃上下架、SEO、商品多媒體上傳等，可(kě)以定義商品是實體還是虛拟，可(kě)以定義是否預訂、是否缺貨銷售等。

2.商品目錄管理(lǐ)：樹形的(de)商品目錄組織管理(lǐ)，并可(kě)以設置關聯/商品推薦。  

3.商品類型管理(lǐ)：定義商品的(de)類型，設置自(zì)定義屬性項、SKU項和(hé)商品評論項。 

4.品牌管理(lǐ)：添加、修改、删除、上傳品牌 LOGO。  

5.商品評論管理(lǐ)：回複、删除。
銷售模塊：

  1.促銷管理(lǐ)：分為(wèi)目錄促銷、購物車促銷和(hé) 優惠券促銷三類，可(kě)以随意定義不同的(de)促銷規則，滿足日常促銷活動：購物折扣、購物贈送積分、購物贈送優惠券、購物免運輸費、特價商品、特定會員購買特定商品、折上折、買二送一(yī)等。   2.禮券管理(lǐ)：添加、發送禮券

  3.關聯/推薦管理(lǐ)――基于規則引擎，可(kě)以支持多種推薦類型，可(kě)手工添加或者自(zì)動評估商品。

訂單模塊：

  1.訂單管理(lǐ)：可(kě)以編輯、解鎖、取消訂單、 拆分訂單、添加商品、移除商品、确認可(kě)備貨等，也可(kě)對因促銷規則發生變化引起的(de)價格變化進行調整。訂單處理(lǐ)完可(kě)發起退貨、換貨流程。

  2.支付：常用于訂單支付信息的(de)查看和(hé)手工 支付兩種功能。手工支付訂單，常用于“款到發貨”類型的(de)訂單，可(kě)理(lǐ)解為(wèi)對款到發貨這類訂單的(de)一(yī)種補登行為(wèi)。

  3.結算：提供商家與第三方物流公司的(de)結算 功能，通常是月結。同時，結算功能也是常用來對“貨到付款”這一(yī)類型訂單支付後的(de)數據進行對帳

庫存模塊：

  1.庫存管理(lǐ)：引入庫存的(de)概念，不包括銷售 規則為(wèi)永遠可(kě)售的(de)商品，一(yī)個SKU對應一(yī)個庫存量。庫存管理(lǐ)提供增加、減少等調整庫存量的(de)功能;另外，也可(kě)對具具體的(de)SKU設置商品的(de)保留數量、***小庫存量、再進貨數量。每條SKU商品的(de)具體庫存操作都會記錄在庫存明細記錄裏邊。

2.查看庫存明細記錄。

  3.備貨/發貨：創建備貨單、打印備貨單、打印發貨單、打印EMS快遞單、完成發貨等一(yī)系列物流配送的(de)操作。

  4.退/換貨：對退/換貨的(de)訂單進行收貨流程的(de)處理(lǐ)。

內(nèi)容模塊：

  1.內(nèi)容管理(lǐ)：包括內(nèi)容管理(lǐ)以及內(nèi)容目錄管理(lǐ)。內(nèi)容目錄由樹形結構組織管理(lǐ)。類似于商品目錄的(de)樹形結構，可(kě)設置目錄是否為(wèi)鏈接目錄。  

2.無限制創建獨立內(nèi)容網頁，比如(rú)關于我們，聯系我們。

   3.廣告管理(lǐ)：添加、修改、删除、上傳廣告、 定義廣告有效時限。

4.可(kě)自(zì)由設置商城導航欄目以及欄目內(nèi)容、欄目鏈接。

客戶模塊：

  1.客戶管理(lǐ)：添加、删除、修改、重設密碼、 發送郵件等。   2.反饋管理(lǐ)：删除、回複。

  3.消息訂閱管理(lǐ)：添加、删除、修改消息組 和(hé)消息、分配消息組、查看訂閱人。   4.會員資格：添加、删除、修改。

系統模塊：

  1.安全管理(lǐ)：管理(lǐ)員、角色權限分配和(hé)安全日志

  2.系統屬性管理(lǐ)：用于管理(lǐ)自(zì)定義屬性。可(kě)關聯模塊包括商品管理(lǐ)、商品目錄管理(lǐ)、內(nèi)容管理(lǐ)、客戶管理(lǐ)。

3.運輸與區域：運輸公司、運輸方式、運輸 地(dì)區。   4.支付管理(lǐ)：支付方式、支付曆史。   5.包裝管理(lǐ)：添加、修改、删除。

  6.數據導入管理(lǐ)：商品目錄導入、商品導入、 會員資料導入。   7.郵件隊列管理(lǐ)：監控郵件發送情況，删除 發送異常郵件。

報表模塊：
  缺省數個統計報表，支持時間段過濾、支持按不同狀态過濾、支持HTML、PDF和(hé)Excel格式的(de)導出和(hé)打印。   1.用戶注冊統計   2.低(dī)庫存彙總   3.缺貨訂單   4.訂單彙總   5.退換貨

責任編輯：中山網站建設
 【網訊網絡】國(guó)家高(gāo)新技術企業》十年(nián)專注軟件開發，網站建設，網頁設計，APP開發，小程序，微信公衆号開發，定制各類企業管理(lǐ)軟件（OA、CRM、ERP、訂單管理(lǐ)系統、進銷存管理(lǐ)軟件等)！服務熱線：0760-88610046、13924923903，http://www.wansion.net