❶ 什麼是電子商務體系結構
電子上午體系結構是由三部分組成的，電子商務框架、電子商務流程、專電子商務模式。而電子扇顧問框屬架又是由上流、信息流、資金流、物流構建而成。它的流程又是由一系列過程構建而成的，比如先是要尋找產品，發現產品信息。就像是實體店中我們選擇一件產品的過程一樣的。
希望這些能夠給你的疑惑帶來幫助。(*^__^*) 嘻嘻
❷ 電子商務網站常用的系統架構哪些
一. 商品展示
站內搜索(搜索提示，搜索規則，搜索成功頁，搜索不成功頁，相似推薦)
導航(頻道導航，其他導航如銷售排行，廣告位，推薦位，文字鏈，also buy等)
商品分類(品牌分類，品類分類，屬性分類如剪裁形式)
登陸頁(商品列表頁，商品詳細頁，商品活動頁)
這里的訪問邏輯是：a /b/c分流消費者去往相對個性化的頁面，由登陸頁體現商家的核心訴求和價值傳遞，完成call-to-action的第一步。
二. 內容展示：內容展示較為簡單，對純購物品牌而言包括：
公告區
幫助中心
論壇(如需商城與論壇發生交互，則需自行開發，否則可集成discuz做同步登陸即可)
三. 訂單確認
訂單確認，就是幫助消費者正確提交訂單信息的環節，看似簡單，實則非常復雜，需要對很多信息邏輯判斷和處理，一般由2個部分組成：
購物車
訂單提交(返回購物車，收貨地址&地址薄，支付方式判斷，配送方式，發票，訂單標記，實付金額計算等等)
四. 支付系統
與一般的想像不同，支付系統其實並不簡單等於第三方支付工具接入：
外部支付系統(支付寶將介面，財付通介面，網銀直聯埠，信用卡分期埠)
內部支付系統(賬戶余額，積分，禮品卡，優惠券)
支付系統的邏輯設計不但需要考慮到各種極端情況的發生(如一張訂單先用禮品卡，再用積分，最後網銀支付)，還要預留財務做賬所需的相關欄位，並充分考慮訂單取消之後如何回滾各類內部賬戶。
五. 用戶中心
注冊&登陸(快速注冊，完整注冊，注冊有禮，推薦注冊，密碼找回，主站id登陸，open-id登陸如qq，新浪微博等)
訂單中心(歷史訂單狀態，中間狀態訂單修改，物流追蹤)
服務中心(各類自助服務如退款申請，退換貨申請，建議與投訴等)
信息管理(用戶基本信息管理和賬戶信息管理)
一. 商品&促銷
商品管理(品類管理，品牌管理，單品管理)
促銷管理(活動管理和自定義活動模板管理)
在上述模塊中，最重要的是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。
❸ 電子商務網站有什麼樣的體系結構
電子商務網站是一種典型的基於Web的分布式､三層應用體系結構
❹ 電子商務網站一般架構有哪些
大型電子商務網站架構，摘抄 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緩存，應該效率上能接受。
❺ 電子商務系統有哪些部分組成
電子商務系統的部分組成如下：
商品管理模塊：功能有商品批量上下架、批量調價、庫存調度、商品名稱撰寫、商品簡介撰寫、批量商品排序、分類轉換、上傳圖片、標簽添加、商品添加、貨號篩選、商品分類、商品CSV導入導出、商品定時上下架、商品配件搭配銷售、商品頁SEO功能、無限分類管理、自定義分類模板、擴展屬性管理、規格管理等；
訂單管理模塊：功能有添加訂單、訂單狀態操作管理、訂單標簽、篩選、導出、列印、配貨單列印、訂單列印樣式管理（購物清單、配貨清單）、發貨單管理、退貨單管理、快遞單模板添加、快遞單模板編輯、快遞單模板下載、快遞單模板導出、發貨信息管理等；
會員管理模塊：功能有會員等級管理、群發郵件、消息、簡訊、批量編輯（會員等級、積分）、會員篩選、會員導出、會員注冊項管理、購買咨詢管理、商品評論管理、商店留言管理、站內消息管理等；
營銷管理模塊：功能有商品促銷、訂單促銷、優惠券管理、積分兌換優惠券、贈品兌換、贈品管理、捆綁銷售、積分設置管、站內推廣鏈接等；
全局設置模塊：功能有商店設置、郵件簡訊設置、會員注冊項、支付方式管理、貨幣管理、價格精度設置、支付自定義設置、配送方式添加編輯管理、配送方式、物流公司、地區設置、操作員管理、角色管理、商品圖片配置、圖片管理、數據備份與還原、隊列管理等；
統計報表模塊：功能有經營概況、賬款統計、銷售收入、預存款、銷售額總覽、銷售量排名、會員購物量排名、商品訪問購買次數、銷售指標分析、會員統計等；
采購管理模塊：功能有補貨提醒、采購訂單、入庫單、采購退貨單、供應商管理等；
倉儲管理模塊：功能有倉庫管理、庫存管理、庫位管理、庫存節點管理、預警、盤點、調撥等；
售後管理模塊：功能有售後申請審核、售後收貨、售後質檢等；
財務單據模塊：功能有銷售訂單收款單管理、銷售訂單退款單管理、采購訂單付款單管理、采購訂單退款單管理、采購預付款查詢等。
❻ 電子商務的體系結構可以分為哪四個層次
1．B2B 指的是Business to Business.
as in businesses doing business with other businesses,商家(泛指企業)對商家的電子商務，即企業與企業之間通過互聯網進行產品、服務及信息的交換。通俗的說法是指進行電子商務交易的供需雙方都是商家(或企業、公司)，她（他）們使用了Internet的技術或各種商務網路平台，完成商務交易的過程。這些過程包括：發布供求信息，訂貨及確認訂貨，支付過程及票據的簽發、傳送和接收，確定配送方案並監控配送過程等。有時寫作B to B，但為了簡便乾脆用其諧音B2B(2即two)。 B2B的典型是阿里巴巴、中國製造網、敦煌網、慧聰網等２．B2C即Business to Customer
B2C模式是我國最早產生的電子商務模式，以8848網上商城正式運營為標志。B2C即企業通過互聯網為消費者提供一個新型的購物環境——網上商店，消費者通過網路在網上購物、在網上支付。由於這種模式節省了客戶和企業的時間和空間，大大提高了交易效率，特別對於工作忙碌的上班族，這種模式可以為其節省寶貴的時間。３．C2C即Consumer To Consumer。
C2C同B2B、B2C一樣，都是電子商務的幾種模式之一。不同的是C2C是用戶對用戶的模式，C2C商務平台就是通過為買賣雙方提供一個在線交易平台，使賣方可以主動提供商品上網拍賣，而買方可以自行選擇商品進行競價。 C2C的典型是網路C2C、淘寶網等。４．B2G即Business To Government B2G模式即企業與政府之間通過網路所進行的交易活動的運作模式，比如電子通關，電子報稅等。B2G比較典型的例子是網上采購，即政府機構在網上進行產品，服務的招標和采購。這種運作模式的來源是投標費用的降低。這是因為供貨商可以直接從網上下載招標書，並以電子數據的形式發回投標書。同時，供貨商可以得到更多的甚至是世界范圍內的投標機會。由於通過網路進行投標，即使是規模較小的公司也能獲得投標的機會
❼ 電子商務體系結構
分數太少，題太多，而且還發錯地方了
❽ 電子商務網站結構
電子商務網站結構是指網站中頁面間的層次關系；按性質可分為邏輯結構及物理結構。網站結構對網站的搜索引擎友好性及用戶體驗有著非常重要的影響；
電子商務網站結構在決定頁面重要性（即頁面權重）方面起著非常關鍵的作用；
電子商務網站結構是衡量網站用戶體驗好壞的重要指標之一。清晰的網站結構可以幫助用戶快速獲取所需信息；相反，如果一個網站的結構極其糟糕的話，用戶在訪問時就猶如走進了一座迷宮，最後只會選擇放棄瀏覽；
電子商務網站結構還直接影響搜索引擎對頁面的收錄，一個合理的網站結構可以引導搜索引擎從中抓取更多有價值的頁面；
電子商務網站結構對網站及網站中頁面的影響。搜索引擎對重要頁面的抓取；由於互聯網中信息量極其龐大，為了向用戶展示更多有價值的信息，搜索引擎會優先抓取每個網站中相對重要的頁面（即權重較高的頁面）然而，搜索引擎是怎樣發現這些重要頁面的呢？根據重要頁面的鏈接指向的頁面可能是重要頁面的思路；
搜索引擎首先會從權重相對較高的頁面（即源頁面）出發跟蹤其中的鏈接，從而抓取其他相對重要的頁面（即目標頁面）；
通過電子商務網站結構分析，培基幫您設計高效、快捷的網站結構，提高網站的易操作性，讓客戶在最短的時間內找到想要的內容，改善客戶的操作體驗；
培基建議：
通過主頁可以到達任何一個一級欄目首頁、二級欄目首頁以及最終內容頁面；
通過任何一個網頁可以返回上一級欄目頁面並逐級返回主頁；
主欄目清晰並且全站統一；
通過任何一個網頁可以進入任何一個一級欄目首頁
不同主題的網站對網頁內容的安排會有所不同，但大多數網站首頁的頁面結構都會包括頁面標題、網站LOGO、導航欄、登錄區、搜索區、熱點推薦區、主內容區和頁腳區等構成；
參考資料：東莞培基官方網站
❾ 簡述電子商務網站的體系結構及各部分的作用
從宏觀角度看，電子商務發展框架要實現電子商務體系的各應用層面和眾多支持條件。該框架整體上可分為三個層次和兩個支柱，從最基礎的技術層到電子商務的應用層，一次分為網路層、多媒體消息/信息發布層、一般業務服務層；兩個支柱是各種技術標准和國家宏觀的政策、法律法規。三個層次一次代表電子商務順利實現的各級應用層次，而兩邊的支柱則是電子商務順利實現的保證條件。