電子商務平台的網路架構

⑴ 網路購物在電子商務系統結構的什麼層

電子商務整體結構分為電子商務應用層結構（簡稱應用層）和支持應用實現的基礎結構（三層），基礎結構一般包括三個層次和兩個支柱。

三個層次自下而上分別為網路層、傳輸層和服務層，兩個支柱分別是安全協議與技術標准、公共政策與法律規范。前三個層次為基礎層次，其上就是各種特定的電子商務應用，可見三個基礎層次和兩個支柱是電子商務應用的條件。為不失一般性，在此僅對電子商務的基礎結構作概括說明。

主體四層

1、網路層（網路平台）

網路層是電子商務的硬體基礎設施，是信息傳輸系統，包括遠程通信網（telecom）、有線電視網（cable TV）、無線通信網（wireless）和互聯網（internet）。遠程通信包括電話、電報，無線通信網包括移動通信和衛星網，互聯網是計算機網路。

對這些網路基本上是獨立的，研究部門正在研究將這些網路連接在一起，到那時傳輸線路的擁擠將會徹底改變。

這些不同的網路都提供了電子商務信息傳輸線路，但是，當前大部分的電子商務應用還是基於Internet。

互聯網路上包括的主要硬體有：基於計算機的電話設備、集線器（hub）、數字交換機、路由器（routers）、數據機、有線電視的機頂盒（set-top box）、電纜數據機（cable modem）。

企業電子商務系統組

經營計算機網路服務的是Internet網路接入服務供應商（IAP）和內容服務供應商（ICP），他們統稱為網路服務供應商（ISP）。IAP只向用戶提供撥號入網服務，它的規模一般較小，向用戶提供的服務有限，一般沒有自己的骨幹網路和信息源，用戶僅將其作為一個上網的接入點看待。

ICP能為用戶提供全方位的服務，可以提供專線、撥號上網，提供各類信息服務和培訓等，擁有自己的特色信息源，它是ISP今後發展的主要方向，也是發展電子商務的重要力量。

2、傳輸層（信息發布平台）

網路層提供了信息傳輸的線路，線路上傳輸的最復雜的信息就是多媒體信息，它是文本、聲音、圖像的綜合。最常用的信息發布應用就是WWW，用HTML或 JAVA將多媒體內容發布在Web伺服器上，然後通過一些傳輸協議將發布的信息傳送到接收者。

3、服務層（電子商務平台）

這一層實現標準的網上商務活動服務，以方便交易，如標準的商品目錄/價目表建立、電子支付工具的開發、保證商業信息安全傳送的方法、認證買賣雙方的合法性方法。

4、應用層（電子商務各應用系統）

兩大支柱

1、公共政策與法律法規

公共政策包括圍繞電子商務的稅收制度、信息的定價（信息定價則圍繞誰花錢來進行信息高速公路建設）、信息訪問的收費、信息傳輸成本、隱私問題等，需要政府制定的政策。其中，稅收制度如何制定是一個至關重要的問題。

例如，對於咨詢信息、電子書籍、軟體等無形商品是否征稅，如何征稅；對於汽車、服裝等有形商品如何通過海關，如何征稅；稅收制度是否應與國際慣例接軌，如何接軌；關貿總協定是否應把電子商務部分納入其中。這些問題不妥善解決，則阻礙著電子商務的發展。

法規維系著商務活動的正常運作，違規活動必須受到法律制裁。網上商務活動有其獨特性，買賣雙方很可能存在地域的差別，他們之間的糾紛如何解決？如果沒有一個成熟的、統一的法律系統進行仲裁，糾紛就不可能解決。

那麼，這個法律系統究竟應該如何制定？應遵循什麼樣的原則？其效力如何保證？如何保證授權商品交易的順利進行，如何有效遏止侵權商品或仿冒產品的銷售。

如何有力打擊侵權行為，這些都是制定電子商務法規時應該考慮的問題。法規制定的成功與否直接關繫到電子商務活動能否順利開展。

2、安全協議與技術標准

安全問題可以說是電子商務的核心問題。如何保障電子商務活動的安全，一直是電子商務能否正常開展的核心問題。作為一個安全的電子商務系統，首先必須具有一個安全、可靠的通信網路，以保證交易信息安全、迅速地傳遞。

其次必須保證資料庫伺服器的絕對安全，防止網路黑客闖入盜取信息。電子簽名和認證是網上比較成熟的安全手段。同時，人們還制定了一些安全標准，如安全套接層（secure sockets layer）、安全HTTP協議（secure-HTTP）、安全電子交易（secure electronic transaction）等。

技術標準是信息發布、傳遞的基礎，是網路上信息一致性的保證。如果沒有統一的技術標准，這就像不同的國家使用不同的電壓傳輸電流，用不同的制式傳輸視頻信號，限制了許多產品在世界范圍的使用。EDI標準的建立就是電子商務技術標準的一個例子。

⑵ 電子商務網路有哪些基本結構類型

電子商務的分類及模式
1.按商業活動運作方式分類
（）完全電子商務：即可以完全通過電子商務方式實現和完成整個交易過程的交易。
（2）不完全電子商務：即指無法完全依靠電子商務方式實現和完成完整交易過程的交易，它需要依靠一些外部要素，如運輸系統等來完成交易。
2.按電子商務應用服務的領域范圍分類。
（1）企業對消費者（也稱商家對個人客戶或商業機構對消費者即b to c）的電子商務。商業機構對消費者的電子商務基本等同於電子零售商業。目前，internet上已遍布各種類型的商業中心，提供各種商品和服務，主要有鮮花、書籍、計算機、汽車等商品和服務。
（2）企業對企業（也稱為商家對商家或商業機構對商業機構即b to b）的電子商務。 商業機構對商業機構的電子商務是指商業機構（或企業、公司）使用internet或各種商務網路向供應商（企業或公司）訂貨和付款。商業機構對商業機構的電子商務發展最快，已經有了多年的歷史，特別是通過增值網路（value added network，van）上運行的電子數據交換（edi），使企業對企業的電子商務得到了迅速擴大和推廣。公司之間可能使用網路進行訂貨和接受訂貨、合同等單證和付款。
（3）企業對政府機構的電子商務
在企業-政府機構方面的電子商務可以覆蓋公司與政府組織間的許多事務。目前 國有些地方政府已經推行網上采購。
（4）消費者對政府機構的電子商務
政府將會把電子商務擴展到福利費發放和自 估稅及個人稅收的徵收方面。
（5）消費者對消費者的電子商務
3.按開展電子交易的信息網路范圍分類。
（1）本地電子商務通常是指利用本城市內或本地區內的信息網路實現的電子商務活動，電子交易的地域范圍較小。本地電子商務系統是利用internet、intranet或專用網將下列系統聯結在一起的網路系統：一，參加交易各方的電子商務信息系統，包括買方、賣方及其他各方的電子商務信息系統；二，銀行金融機構電子信息系統；三，保險公司信息系統；四，商品檢驗信息系統；五，稅務管理信息系統；六，貨物運輸信息系統；七，本地區edi中心系統（實際上，本地區edi中心系統聯結各個信息系統的中心）。本地電子商務系統是開展有遠程國內電子商務和全球電子商務的基礎系統。
（2）遠程國內電子商務是指在本國范圍內進行的網上電子交易活動，其交易的地域范圍較大，對軟硬體和技術要求較高，要求在全國范圍內實現商業電子化、自動化，實現金融電子化，交易各方具備一定的電子商務知識、經濟能力和技術能力，並具有一定的管理水平和能力等。
（3）全球電子商務是指在全世界范圍內進行的電子交易活動，參加電子交易各方通過網路進行貿易。涉及到有關交易各方的相關系統，如買方國家進出口公司系統、海關系統、銀行金融系統、稅務系統、運輸系統、保險系統等。

⑶ 電子商務系統的結構分為哪幾個層次

電子商務體系結構可以分為網路基礎平台、安全結構、支付體系和業務系統四個版層次。 1、網路權基礎平台 電子商務以網際網路為主要載體。網路帶寬、網路的可靠性、穩定性成為影響電子商務系統整體性能的重要因素。 2、安全結構 電子商務活動需要一個安全的環境,以保證在線交易等數據在網路中傳輸的安全性和完整性,實現交易雙方的身份認證,防止交易中抵賴的發生。電子安全結構建立在網路基礎平台之上。 3、電子商務業務系統和支付體系 電子商務業務系統分為支付型業務和非支付型業務。支付型業務需要支付體系層完成。支付體系在安全結構之上,為支付型電子商務業務提供各種支付手段;非支付型業務直接在安全結構之上,使用安全基礎層提供的各種認證手段和安全技術提供電子商務服務。 電子商務系統包括業務應用系統。例如,網上購物、證券交易、在線談判、電信交費、電子銀行等。 4、支付網關系統。它處於網際網路與銀行網路之間,主要完成通信、協議轉換和數據加密解密功能和保護銀行內部的網路。支付網關系統的使用可以過濾網際網路發過來的數據包,防止黑客的攻擊和不相關信息的流入。

⑷ 電子商務系統框架結構四大支柱和三大平台

電子商務的基本框架結構是指實現電子商務從技術到一般服務層所應具備的完整的運作基礎，它在一定程度上改變了市場構成的基本結構。傳統的市場交易鏈是在商品、服務和貨幣交換過程中形成的。而今，電子商務的應用強化了一個重要因素——信息，於是就有了信息服務、信息商品和電子貨幣等等。下面我們簡要地描述一下電子商務系統框架結構的四大支柱。

第一支柱，網路基礎設施，它是實現電子商務的最底層的硬體基礎設施，是信息傳播系統，包括遠程通信網、有線電視網、無線通信網和互聯網。這些網路都在不同程度上提供電子商務所需的傳輸線路，但是大部分的電子商務運作還是基於Internet。

第二支柱，在網路層提供的信息傳輸線路上，通過Internet傳輸信息的內容，如文本、聲音、圖像等。最常用的信息發布所應用的是WWW，及應用HTML將信息發布在WWW上。

第三支柱，貿易服務的基礎設施。第四層框架被稱為基礎設施，因為所有企業和個人在做交易時都需要它的服務。主要包括標準的商品目錄服務、建立價目表、電子支付工具的開發、保證商業信息安全傳送的方法、認證買賣雙方合法性的方法等。

第四支柱，電子商務的實際應用層。電子商務的具體應用范圍較廣，包括供應鏈管理、電子市場及電子廣告、網上購物、網上娛樂、有償信息服務及網上銀行。

電子商務的兩個支撐點是框架結構得以存在並能應用的基礎。相關的政策及法律法規是電子商務框架的第一個支撐點。電子商務的第二個支撐點是各種技術標准及相應的網路協議。

⑸ 電子商務系統的網路結構

電子商務復系統的各個元素（制CA中心、支付網關、業務應用系統、用戶終端）均連接在Internet網上，並通過該網路實現完整的電子商務；
CA安全認證系統建立在Internet網上，通過該網路向終端用戶、支付網關和業務應用系統提供證書發放和授權服務；
支付網關通過專線與該網路中心實現連接，一個支付網關可以實現對多個網路的連接；
業務應用系統直接建立在Internet網上，分布在全國各地，並通過該網路實現企業對用戶（B
TO
C）、企業對企業（B
TO
B）的電子商務應用；
用戶系統通過多種手段與電子商務綜合接入平台連接至Internet網，包括PSTN、DDN、FR、ISDN等。

⑹ 電子商務網站的基本架構

電子商務網站的基本架構設計
電子商務網站是以商務活動為中心進行的,而網站的盈利一般通過網站的會員制收費進行,網站的盈利點是網站根據網站的商務活動內容確定的,所以網站的基本架構設計既要以商務活動的業務內容、流程、相關規則為基礎,又要兼顧電子商務網站的收費體系.

網站基本架構的設計主要根據以下步驟進行：

2.1 確定電子商務網站功能定位
確定網站所涉及的商務活動的內容、商務活動的流程.比如我們在進行房產信息網的設計中,首先考慮確定網站發布房產信息的種類,確定了房源信息包括中介所的房源信息和個人的出售、出租信息,網站負責信息的發布和信息的管理.同時在確定了信息發布種類後,確定了信息處理的流程為房源信息輸入、會員資格審核、信息審核，信息發布.

2.2 確定網站的收費對象和收費規則
在網站所涉及的商務內容確定了的情況下,確定收費的對象和如何進行收費,以此為依據確定網站的欄目.網站欄目的劃分實際上就是系統的功能模塊劃分.在房產網站的系統設計中,確定了網站只對房產中介所進行收費,個人用戶免費,所以網站的主要欄目分為個人專區和中介所專區兩個主要欄目,同時根據功能的逐步擴大,這樣也就基本確定了網站的信息服務內容和方式.

2.3 確定網站的欄目的功能
在確定了網站的收費項目後,要確定網站的主要欄目和功能,包括網站的管理功能模塊、網站的信息發布方式、網站商務活動的發布以及網站導航欄等.
網站的功能欄目的設置和系統的主要功能模塊的劃分是相一致的.
網站業務介紹性欄目,應包括內容應包括會員申請流程,收費標准,網站運行規程等,使用戶對網站的服務有一個明確的了解,是擴大網站的會員用戶數量和提高網站的使用率都是必不可少的欄目.
網站的導航欄是網站的整體功能的全面介紹,使用戶對網站的功能有一個清晰的了解,也是網站不可缺少的欄目.
同時也應有網站運行的相關提示信息,比如在房產網站的設計中,我們在確定了收費對象和主要功能後,確定了網站首頁的主要欄目為中介所專區、個人專區、寫字間專區、新房樓市等欄目,同時加入了上網導航欄目對網站的主要功能進行介紹.

2.4 確定網站的信息流和控制流
在確定了網站的主要功能和商務活動的主要規則後,應該確定網站的信息流圖和控制流圖,作為資料庫設計的基礎.
在房產網的設計中,我們根據房產信息發布的功能和所確定的信息審核和控制流程,在確定了一個網站的數據流圖和控制流後,系統的運行控制流程也就確定下來了.

⑺ 電子商務網站一般架構有哪些

大型電子商務網站架構，摘抄 7.同一個網站的多語言該如何處理是好,使用配置文件然後cookie或url來判別?===客戶是自己公司，使用標准方法即可
8.電子商務網站最多的就是 商品的打折方式和積分的贈送了,這里要怎麼設計才好(工廠模式)?===采購成熟的規則引擎
9.如果同一時間並發大量訂單的話,如果確保一個訂單的有效提交呢?
==電子商務一般要使用MQ，推薦IBM MQ；使用MSMQ也可
第一點是資料庫要設計好，要達到什麼級別，你可能需要考慮哪些表需要拆分，哪些表的核心數據需要冗餘，如果是mysql，還要考慮其他的問題，比如存儲引擎。
新聞肯定是要生成純靜態頁，對資料庫壓力就小很多，不過靜態頁也有管理上的不方便，更新刪除添加都要對磁碟文件進行操作
做一個自定義緩存層，對緩存邏輯進行控制，可以採用第三方緩存模塊，如果使用.net來做，可以層層緩存，頁面緩存，數據緩存（memcache，不過在win下效率不高）
電子商務網站特點就是對事務的嚴格，需要資料庫設計的時候要求高性能，也需要合適的索引，支持高並發，經常對產品表用戶表等進行索引檢查，是否有很多索引掃描和表掃描（即使是局部的，也要將逗局部地控制到最小范圍）
mssql語句對不需要事務的查詢要附帶上with(nolock),以利於並發更新。
有些功能模塊不能按照想當然的方式開發，比如產品訪問次數，切不可將這些更新非常頻繁的欄位置於核心表內，明確的做法是將其剝離開來 還有就是切不可經常性將欄位設計成bool類型，這樣會給以後的擴展留出路，即使是男女這種欄位，也建議採用tiny類型
其他還有就是在產品設計的時候充分考慮seo，網站目錄結構清晰可讀，而不是帶著一串串的查詢參數。
對安全要有整體的把握，最好全都是用存儲過程，在項目上線前將資料庫存儲過程全部導出再查找貌似exec的語句，查找是否需要替換成sp_executesql。
另外，如果採用mssql，全文搜索直接用mssql fte就可以，速度和精確度都還是可以的，最重要的是維護和管理開發很簡單。
打折的處理可以按照電信的一次，二次批價功能，如果你做過電信方面的系統。
當然也可以設計得更簡單的一些。 靜態的頁面建議使用CDN加速，以解決網通和電信之間訪問速度的問題；
數據的緩存方面建議考慮用memcache，另外也可以分別在表現層和數據層利用.net中的現存緩存機製作業可；
簡單執行的sql可以不用存儲過程，存儲過程會佔用資料庫伺服器的處理時間，造成死鎖；
mvc建議還是做些CMS的項目上應用，電子商城不是很適合，個人觀點。url上可以做轉義，使url顯示更友好；
資料庫建議建立分布資料庫，這樣可以轉移查詢和大訪問量對資料庫帶來壓力；
圖片可以考慮單獨放在一台伺服器上；1.三層架構
2.使用手寫sql,手寫entity(生成也可),緩存反射綁定(不是緩存數據哦,緩存映射關系),要考慮網站的長期發展還是手寫吧 靈活 性能也好
3.沒有這種問題,商業驅動的,純購物就好了,千萬別搞什麼圈子,wiki
4.純.net的mvc不建議,webform不搞viewstate,不搞服務端控制項(除repeater)再加點mvc的思想已足夠用了
5.不需要緩存數據(除搜索產品部分),要考慮多台伺服器的程序快速部署,config文件會很多,config要序列化緩存
6.當然是先生成好了,參照jd吧,按業務每張圖片對應幾個不同大小的圖
7.據經驗,電子商務網站僅靠中英雙語來達到多語言是不靠譜的(文化 用戶習慣不是簡單的語言切換),如果想真正運營英語的就要重新開發一個版本
8.不搞模式
9.負載均衡(web,db)+ssb非同步處理數據
10.你是業務類型的日誌還是異常日誌? 前台訂單流程上異常日誌不需要了,找個工具錄個腳本不停的跑 保證隨時發現問題發郵件就可以了
11.找第三方搜索組件 類似endeca的
12.負載均衡挺簡單的,初期靠軟體就可以,一切圖片找第三方放cdn,前台網站用到ajax的地方很少,如果用的話jquery 1，一個電子商務網站用戶99.5%的行為時Find
2、對於商品檢索部分，能不用資料庫就不用資料庫（網上切詞等相關的開源平台很多）
3、分布式緩存（Memcached 、Volecity），個人測試volecity 3還是不錯的
4、系統設計時必須要考慮可運營。從這個角度去設計系統
5、對於電子商務網站改動很頻繁，必須考慮架構設計如何適應頻繁的版本更新
6、必須設計一個好的單點登錄系統。
7、建議能不用sqlserver就不用它。
8、對於大型電子商務網站來說，系統的I/O是起決定因素而不是CPU和內存。1.項目劃分是否會有問題,圖中分別是 實體層,數據訪問介面層,數據訪問層,業務邏輯介面層,業務邏輯,網站A,B,C
項目劃分其實不重要，重要的的是你在寫代碼的時候是否能把代碼合理的分到對應的項目里。
2.數據訪問層是要開發效率(NBear,Linq,Nh等),還是訪問效率(直接使用sql等)?是否可以先使用開發效率高的,等日後訪問量大了,再重寫並替換數據訪問層?
開發效率優先，訪問量大了以後，我相信是有錢投到硬體上的，在你程序寫的不是很爛的情況下，升級硬體遠比優化程序節省成本。
3.網站被切割成了多個子網站,有一些控制項(如header,footer)是要共享的,如何跨網站項目共享這些控制項呢?
那就做成自定義控制項啦。
4.ms的mvc 1.0也出來不少時間了,是否已經夠成熟運用到項目中?或者是網站後台使用webform的,前台使用mvc?
推薦使用使用webform的,前台使用mvc，對於前台來說使用mvc能更好的提升性能，更方便的更換頁面表現形式。後台界面相對穩定，用webform可以提高開發效率。
5.網站數據的緩存是自己開發一個hashtable什麼的來維護呢,還是使用Memcached ?
初期建議用hashtable，因為簡單，將來升級到Memcached 。
6.縮略圖的處理,我看有的網站是在上傳圖片的時候直接生成,有的是在httpmodle里處理,訪問的時候生成.
直接生成縮略圖的好處是節約性能。httpmodle相反，每次瀏覽圖片的時候都會生成新的圖片，伺服器壓力大，建議直接生成。
7.同一個網站的多語言該如何處理是好,使用配置文件然後cookie或url來判別?
多語言建議使用asp.net自帶的資源文件的方式實現，當前語言保存在cookie裡面。
8.電子商務網站最多的就是 商品的打折方式和積分的贈送了,這里要怎麼設計才好(工廠模式)?
規則引擎
9.如果同一時間並發大量訂單的話,如果確保一個訂單的有效提交呢?
使用MQ隊列
10.日誌方面,log4net?
log4net只能記錄程序運行日誌，主要目的是用來調試程序的，系統業務操作日誌還你是得自己建一個表來保存。
11.電子商務的全文檢索,這也是個頭疼的問題
lucene，微軟索引服務，sqlserver全文檢索，方案很多的。
12.負載均衡方面,有什麼好的文章推薦碼?
可以看windows 2003 集群方面的文章 1.項目劃分是否會有問題,圖中分別是 實體層,數據訪問介面層,數據訪問層,業務邏輯介面層,業務邏輯,網站A,B,C
目前我也是這樣分的,不過當數據表結構有修改時,會帶動其它層的聯級修改,非常不方便，所以開發之前最好將資料庫設計地完善一點。另外，當網站分成多個以後，其它項目生成的DLL文件要部署到每個網站的bin文件夾里，更新一次都要重新部署，這也是個挺煩人的事，當然可以將DLL部署到GAC里來解決這個問題，不過這樣的話本地調試起來就不太方便了，因為項目一有改動，就要將生成的DLL重新拷貝到GAC里才能看到效果。
2.數據訪問層是要開發效率(NBear,Linq,Nh等),還是訪問效率(直接使用sql等)?是否可以先使用開發效率高的,等日後訪問量大了,再重寫並替換數據訪問層?
這個我也在考慮。目前我還沒有採用ORM框架，都是在DAL里直接訪問DB的。
3.網站被切割成了多個子網站,有一些控制項(如header,footer)是要共享的,如何跨網站項目共享這些控制項呢?
自定義控制項。
4.ms的mvc 1.0也出來不少時間了,是否已經夠成熟運用到項目中?或者是網站後台使用webform的,前台使用mvc?
正在學習這一塊。
5.網站數據的緩存是自己開發一個hashtable什麼的來維護呢,還是使用Memcached ?
現在我用的比較多的是.net自帶的數據緩存。
6.縮略圖的處理,我看有的網站是在上傳圖片的時候直接生成,有的是在httpmodle里處理,訪問的時候生成.
直接生成好，快一點。
7.同一個網站的多語言該如何處理是好,使用配置文件然後cookie或url來判別?
我沒涉及到這一塊，不過我覺得資源文件應該就是用來處理這個問題的。
8.電子商務網站最多的就是 商品的打折方式和積分的贈送了,這里要怎麼設計才好(工廠模式)?
這些都放在邏輯層好了。
9.如果同一時間並發大量訂單的話,如果確保一個訂單的有效提交呢?
MSMQ
10.日誌方面,log4net?
目前我是自已寫代碼存在庫里的。
11.電子商務的全文檢索,這也是個頭疼的問題
用lucene.net分詞建索引，再直接從索引庫里搜索，又快又准。
12.負載均衡方面,有什麼好的文章推薦碼?
不清楚了。 這樣的設計要達到新蛋的效果肯定不可能的，新蛋少說幾百台伺服器，不同資料庫之間的發布訂閱鏈路都有幾千條。有復雜的緩存，負載均衡機制。新蛋所有的通訊都是基於WCF的。另外對於這么大型的網站來說，資料庫一刻都不停止，所以讀寫分離也很重要，因為你也不可能讓資料庫停下來進行備份。總歸要做到新蛋這樣的大型電子商務網站，靠你上面畫的這點好像遠遠不夠。
不過關於公共的header,footer,我不建議做成自定義控制項，這個維護起來不方便，稍有變動就要發布dll，麻煩的。
如果你的header和footer不是很大的話，建議採用js+css的方式。然後加上壓縮和cdn緩存，應該效率上能接受。

⑻ 電子商務網站常用的系統架構哪些

前台系統包括：商品展示，內容展示，訂單確認，支付系統，用戶中心四大模塊

一. 商品展示

• 站內搜索(搜索提示，搜索規則，搜索成功頁，搜索不成功頁，相似推薦)

• 導航(頻道導航，其他導航如銷售排行，廣告位，推薦位，文字鏈，also buy等)

• 商品分類(品牌分類，品類分類，屬性分類如剪裁形式)

• 登陸頁(商品列表頁，商品詳細頁，商品活動頁)

這里的訪問邏輯是：a /b/c分流消費者去往相對個性化的頁面，由登陸頁體現商家的核心訴求和價值傳遞，完成call-to-action的第一步。

二. 內容展示：內容展示較為簡單，對純購物品牌而言包括：

• 公告區

• 幫助中心

• 論壇(如需商城與論壇發生交互，則需自行開發，否則可集成discuz做同步登陸即可)

三. 訂單確認

訂單確認，就是幫助消費者正確提交訂單信息的環節，看似簡單，實則非常復雜，需要對很多信息邏輯判斷和處理，一般由2個部分組成：

• 購物車

• 訂單提交(返回購物車，收貨地址&地址薄，支付方式判斷，配送方式，發票，訂單標記，實付金額計算等等)

四. 支付系統

與一般的想像不同，支付系統其實並不簡單等於第三方支付工具接入：

• 外部支付系統(支付寶將介面，財付通介面，網銀直聯埠，信用卡分期埠)

• 內部支付系統(賬戶余額，積分，禮品卡，優惠券)

支付系統的邏輯設計不但需要考慮到各種極端情況的發生(如一張訂單先用禮品卡，再用積分，最後網銀支付)，還要預留財務做賬所需的相關欄位，並充分考慮訂單取消之後如何回滾各類內部賬戶。

五. 用戶中心

用戶中心的實質是用戶自助功能的dashboard，一般4個部分組成：

• 注冊&登陸(快速注冊，完整注冊，注冊有禮，推薦注冊，密碼找回，主站id登陸，open-id登陸如qq，新浪微博等)

• 訂單中心(歷史訂單狀態，中間狀態訂單修改，物流追蹤)

• 服務中心(各類自助服務如退款申請，退換貨申請，建議與投訴等)

• 信息管理(用戶基本信息管理和賬戶信息管理)

後台系統包括：商品&促銷，crm，訂單處理，wms，采購管理，財務管理，報表管理，系統設置，wa系統9大模塊

一. 商品&促銷

• 商品管理(品類管理，品牌管理，單品管理)

• 促銷管理(活動管理和自定義活動模板管理)

在上述模塊中，最重要的是2個部分：單品管理中的批量產品生成的自動程序和活動管理中「共享與互斥」管理。前者用於大幅提升上新速度，後者避免促銷活動失控。

二. crm ：crm是對b2c核心資源—會員的管理，服務與再營銷系統，包括如下部分：

• 會員管理(會員信息的增刪改查和到其他系統的鏈接)

• 用戶關懷(條件觸發和人工觸發相關edm &簡訊& ob)

• 定向營銷(會員分組和營銷活動管理)

• 客服管理(內容非常多，集成所有需前台與後台交互的功能，詳情還是看圖吧)

• 呼叫中心(ivr，坐席管理，統計報表，參數傳遞與窗口嵌入)

值得注意的，edm和簡訊通道市面上已經有成熟的外包服務商，一般都會外包；呼叫中心和在線客服自行開發成本太高，特別是呼叫中心系統，業務初期也都是外包的。

三. 訂單處理：訂單處理是在訂單未正式進入倉儲部門處理之前，對訂單的前置性處理環節。

• 訂單錄入(電話訂購，網上下單，外部團購訂單，無金額訂單錄入如禮品單)

• 訂單審核(自動審核和人工審核)

• rma處理(rma申請單和rma處理單)

四. wms(warehouse management system倉庫管理系統)

• wms的流程很長，功能模塊也很多，大致分為入庫管理，庫存管理，出庫管理和票據管理4個模塊四個模塊

五. 采購管理

• 供應商管理(供應商信息管理，合同發票管理)

• 采購單管理(po單管理，負po單管理)

• 庫存管理(庫存查詢，庫存佔用單，庫存變動log)

六 .財務管理：b2c的財務管理，主要是對供應商，渠道和內部費用支出的成本控制。

• 供應商結算

• 渠道結算

• 配送結算

• 內部結算

七. 報表管理：報表是b2c業務的宏觀表現，理論上說，每個部門的kpi都應該從中找到。

• 搜索報表(站內搜索量查詢)

• 銷售報表(多個維度銷量查詢，優惠券使用情況，報表導出)

• 財務報表

• 客服報表(客服日報和坐席報表)，前者反映與消費者發生的日常交互(包括正常與異常)，後者考核客服的工作績效

• 倉儲物流報表，這幾塊報表，是業務運作的核心，涉及到公司機密，就不能寫的太細了，見諒。

八. 系統設置：這塊大家都知道是幹嘛的，也就不多說了，分成三塊。

• 基礎設置(和業務有關的一些欄位值)

• 許可權設置(不同賬號的操作許可權和操作記錄)

• 其他設置

九. wa系統(web analytcis)

網站分析系統，幾乎全是外購，很少有能夠自建的，即使自建，最多做幾個簡單的模塊。用於實戰的，要麼是免費的ga(google analytics)，要麼是昂貴的omniture。