購物網站架構

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

大型電子商務網站架構，摘抄7.同一個網站的多語言該如何處理是好,使用配置文件然後cookie或url來判別?===客戶是自己公司，使用標准方法即可

8.電子商務網站最多的就是商品的打折方式和積分的贈送了,這里要怎麼設計才好(工廠模式)?===采晌頃購成熟的規則引擎

9.如果同一時間並發大量訂單的話,如果確保一個訂單的有效提交呢?

==電子商務一般要使用MQ，推薦IBMMQ；使用MSMQ也可

第一點是資料庫要設計好，要達到什麼級別，你可能需要考慮哪些表需要拆分，哪些表的核心數據需要冗餘，如果是mysql，還要考慮其他的問題，比如存儲引擎。

新聞肯定是要生成純靜態頁，對資料庫壓力就小很多，不過靜態頁也有管理上的不方便，更新刪除添加都要對磁碟文件進行操作

做一個自定義緩存層，對緩存邏輯進行控制，可以採用第三方緩存模塊，如果使用.net來做，可以層層緩存，頁面緩存，數據緩存（memcache，不過在win下效率不高）

電子商務網站特點就是對事務的嚴格，需要資料庫設計的時候要求高性能，也需要合適的索引，支持高並發，經常對產品表用戶表等進行索引檢查，是否有很多索引掃描和表掃描（即使是局部的，也要將「局部」控制到最小范圍）

mssql語句對不需要事務的查詢要附帶上with(nolock),以利於並發更新。

有些功能模塊不能按照想當然的方式開發，比如產品訪問次數，切不可將這些更新非常頻繁的欄位置於核心表內，明確的做法是將其剝離開來還有就是切不可經常性將欄位設計成bool類型，這樣會給以後的擴展留出路，即使是男女這種欄位，也建議採用tiny類型

其他還有就是在產品設計的時候充分考慮seo，網站目錄結構清晰可讀，而不是帶著一串串的查詢參數。

對安全要有整體的把握，最好全都是用存儲過程，在項目上線前將資料庫存儲過程全部導出再查找貌似exec的語句，查找是否需要替換成sp_executesql。

另外，如果採用mssql，全文搜索直接用mssqlfte就可以，速度和精確度都還是可以的，最重要的是維護和管理開發很簡單。

打折的處理可以按照電信的一次，二次批價功能，如果你做過電信方面的系統。

當然也可以設計得更簡單的一些。靜態的頁面建議使用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的地方很少,如果用的話jquery1，一個電子商務網站用戶99.5%的行為時Find

2、對於商品檢索部分，能不用資料庫就不用資料庫（網上切詞等相關的開源平台很多）

3、分布式緩存（Memcached、Volecity），個人測試volecity3還是不錯的

4、系統設計時必須要考慮可運營。從這個角度去設計系統

5、對於電子商務網站改動很頻繁，必須考慮架構設計如何適應頻繁的版本更新

6、必須設計一個好的單點登錄系統。

7、建議能不用sqlserver就不用它。

8、對於大型電子商務網站來說，系統的I/O是起決定因素而不是CPU和內存。1.項目劃分是否會有問題,圖中分別是實體層,數據訪問介面層,數據訪問層,業務邏輯介面層,業務邏輯,網站A,B,C

項目劃分其實不重要，重要的的是你在寫代碼的時候是否能把代碼合理的分到對應的項目里。

2.數據訪問層是要開發效率(NBear,Linq,Nh等),還是訪問效率(直接使用sql等)?是否可以先使用開發效率高的,等日後訪問量大了,再重寫並替換數據訪問層?

開發效率優先，訪問量大了以後，我相信是有錢投到硬體上的，在你程序寫的不是很爛的情況下，升級硬體遠比優化程序節省成本。

3.網站被切割成了多個子網站,有一些控制項(如header,footer)是要共享的,如何跨網站項目共享這些控制項呢?

那就做成自定義控制項啦。

4.ms的mvc1.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.負載均衡方面,有什麼好的文章推薦碼?

可以看windows2003集群方面的文章1.項目劃分是否會有問題,圖中分別是實體層,數據訪問介面層,數據訪問層,業務邏輯介面層,業務邏輯,網站A,B,C

目前我也是這樣分的,不過當數據表結構有修改時,會帶動其它層的聯級修改,非常不方便，所以開發之前最好將資料庫設計地完善一點。另外，當網站分成多個以後，其它項目生成的DLL文件要部署到每個網站的bin文件夾里，更新一次都要重新部署，這也是個挺煩人的事，當然可以將DLL部署到GAC里來解決這個問題，不過這樣的話本地調試起來就不太方便了，因為項目一有改動，就要將生成的DLL重新拷貝到GAC里才能看到效果。

2.數據訪問層是要開發效率(NBear,Linq,Nh等),還是訪問效率(直接使用sql等)?是否可以先使用開發效率高的,等日後訪問量大了,再重寫並替換數據訪問層?

這個我也在考慮。目前我還沒有採用ORM框架，都是在DAL里直接訪問DB的。

3.網站被切割成了多個子網站,有一些控制項(如header,footer)是要共享的,如何跨網站項目共享這些控制項呢?

自定義控制項。

4.ms的mvc1.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緩存，應該效率上能接受。

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

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

一.商品展示

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

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

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

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

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

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

公告區

幫助中心拍蠢

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

三.訂單確認

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

購物車

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

四.支付系統

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

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

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

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

五.用戶中心?

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

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

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

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

一.商品&促銷

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四.wms(warehousemanagementsystem倉庫管理系統)

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

五.采購管理

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

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

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

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

供應商結算

渠道結算

配送結算

內部結算

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

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

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

財務報表

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

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

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

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

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

其他設置

九.wa系統(webanalytcis)

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

⑶ 建立一個獨立的購物網站需要怎樣的伺服器幾個伺服器同時可以在線購物多少人

1台伺服器就足夠了。出於安全性，性能，穩賀衡槐定性方面的考慮，自己買全新伺服器更好一些。

你說的這些內容，互動性比較多，最好是用最新nehalem架構的至強四核的伺服器配置，才可以保證流暢不卡。如果是1000人在線，用一台單路四核至強的就可以了。

你可以看看國產品牌正睿的這款單路四核伺服器，它采攔歷用英特爾最新的nahalem平台架構，標配一顆至強?X3430四核處理器(2.4GHz/8M緩存)，英特爾3420伺服器晶元組主板，2GDDR31333MHz高性能內存，SATA2320G硬碟，雙千兆網卡，性能可以說是非常的不錯。

產品型號：I1456132S-E

產品類型：單路四核機架式伺服器

處理器：XeonX3430

內存：2GDDR3

硬碟：SATA2320G

機構：1U機架式

價格：￥3999

銀牌服務

重慶五年免費上禪友門服務，全國三年免費上門服務，關鍵部件三年以上免費質保。

給你推薦的是國產品牌正睿的伺服器產品，他們的產品性價比很高，做工很專業，兼容性，質量之類的都有保障，售後也很完善，3年免費質保，3年免費上門服務，在業界口碑很不錯。

⑷ 如何構建一個成功的B2C電子商務購物網站

因為我們發現大量的B2C購物網站是無法為網站投資者創造效益的，原因很簡單，一個沒有去真正的了解用戶、無法獲得用戶信任的電子商務網站是無法獲得成功的。 淘寶成功的秘訣就在於運用網路營銷的法則去構架一個電子商務網站，我們確保其面向用戶和搜索引擎時都是友好的，通過對每個客戶的用戶群進行分析，我們為每個客戶開發的網站都是獨特的。由於在營銷型網站建設中我們已經做了詳細介紹，我們只將對以下2個重點進行重復： 1、面向搜索引擎友好，因為通過合理的網站架構和內容組織可以達到SEO搜索引擎優化的目的，從而讓更多的用戶通過搜索引擎關鍵字搜索找到我們，達到網站推廣和宣傳的目的。(當然今日的淘寶也不再需要)。 B2C電子商務購物網站建設的誤區： 1、可能很多人認為B2C電子商務網站建設是一個簡單的事情，因為到處都有這方面的免費程序下載，當然，如果您沒有資金投入或純粹個人興趣嘗試是可以的，但是如果准備把其作為企業的一個發展項目或者個人的一個創業計劃來實施，那肯定無法滿足您的要求。畢竟每個網站面向的用戶群是不一樣的，這樣千篇一律的模版程序是無法滿足您和您用戶的個性需求的，如果生硬的套上去也無法獲得更多客戶的信任，何況這樣的程序通常都會有一些安全隱患。 2、很多企業通常設置了復雜的會員許可權和繁瑣的購物流程來體現網站功能的強大性，其實簡單化流程比復雜化流程更難。通過人性化的設計，我們的開發工作可能更復雜，但是通過我們復雜的設計、開發工作來簡化用戶的操作，這樣才能讓消費者真正地感覺到網上購物的方便快捷。其實很多用戶在網上購買商品時都是沖動型消費，所以購物流程簡化和在線支付的方便性在此時的作用也就非常大了。 3、產品展示要達到營銷的效果。產品的展示是電子商務網站信息流中一個重要的環節。產品的展示和描述是一門藝術，合理的產品展示模式和准確的描述，更容易讓消費者相信產品的品質、獲得消費者的信賴。 4、B2C購物網站更需要特色和規模化，很多B2C網站因為缺乏長期的戰略規劃從而導致無法實現規模化，所以一直半死不活的存在著，其實這跟傳統經營的道理是一樣的，規模化經營在抗風險能力和防止被仿冒的能力上都要強很多，我們通過互聯網路面向的是全國甚至全球的市場，規模化經營的實現會更加容易，但這需要戰略規劃的手段來按步驟實現的。當然，特色是B2C的靈魂，我們也可以用定位這個詞來描述它，千萬不要指望把什麼客戶都網路進來，我們需要找准市場切入點，並貫徹實施在網站建設和運營的每一個細節中去。 5、千萬不能忽略老客戶的感受，在B2C網站中，老客戶的口碑傳播速度是最快的，而且在我們網站的訪問群及成交訂單中，有相當程度是老客戶所貢獻的。我們應該從產品、服務、網站人性化設置及功能體現上對老客戶進行強化綁定，從而提高老客戶的忠誠度。 6、一個B2C電子商務購物網站沒有流量是不行的，因為沒有流量意味著沒有更多的用戶了解我們和我們的商品。但是極度的去追求流量的做法也是不可取的，畢竟B2C的效益轉換是很重要的，流量並不等於訂單。訂單數量=有效流量*成交率，所謂有效流量是指我們目標消費群的流量，而不是有多少人來訪問，B2C網站應該著重分析我們的客戶群特徵，並有針對性的進行SEO搜索引擎優化和網站推廣、網路營銷等活動，這樣我們才能吸引真正有效的目標客戶。當然如果您的成交率非常低，說明您的網站或產品、服務存在一定問題，這時候我們應該花大量的精力去改善和完善網站及產品服務，在完善之前即使花大量的成本去提高流量也是無效的、而且也是不符合成本運算規則的。

⑸ 如何分析購物網站的頁面布局

一、定位分析

網站剖析：對網站的自身進行解剖分析，目的是尋找到網站的基礎問題所在;

電子商務定位：對企業網站進行電子商務定位，明確網站的位置;

電子商務模式分析：分析網站的電子商務模式，研究與網站相匹配的電子商務模式;

行業競爭分析：行業競爭的情亮鏈碧況，行業網站的綜合分析;

網站發展計劃分析：電子商務網站短期規劃與長期發展戰略的實施反饋分析等。

二、網站診斷

網站結構診斷：網站的結構是否合理，是否高效，是否方便，是否符合用戶訪問的習慣;

網站頁面診斷：頁面代碼是否精簡，頁面是否清晰，頁面容量是否合適，頁面色彩是否恰當;

文件與文件名診斷：喚鄭文件格式，文件名等敬舉;

訪問系統分析：統計系統安裝，來路分析，地區分析，訪問者分析、關鍵詞分析等;

推廣策略診斷：網站推廣策略是否有效，是否落後，是否採用復合式推廣策略等。

三、營銷分析

關鍵詞分析：關鍵詞是否恰當，關鍵詞密度是否合理等;

搜索引擎登錄分析：採用何種登錄方式，登錄的信息是否有效;

鏈接相關性分析：鏈接的人氣是否高，是否屬於相關性較大的鏈接;

目標市場分析：對目標市場進行分析，研究目標市場與營銷的關系;

產品分析：分析產品的特性，產品的賣點等;

營銷頁面分析：營銷頁面設置的位置，營銷頁面的內容，營銷頁面的第一感覺等;

營銷渠道分析：所採用的營銷之渠道如何，新的營銷渠道如何開拓;

後續產品和服務分析：後續產品的開發，服務的情況反饋分析;

價格分析：價格如何，合理性等。

四、綜合優化

網站的架構優化：結構優化，電子商務運行環境優化等;

網站頁面優化：頁面布局，頁面設計優化;

導航設計：導航的方便性，導航的文字優化等;

鏈接整理：對網站的內外鏈接進行處理;

標簽優化設計：對相關標簽進行優化設計。

五、整合推廣

網站流量推廣策略：關鍵還是流量問題，這個過程中會用到許多網路營銷方法;

外部鏈接推廣：友情鏈接策略的使用;

病毒式營銷策略：具體的策略需要靈活運用;

其它推廣：關注網路變化，開發新的推廣手段。

上述網站推廣的五個關鍵步驟統合了網路營銷、電子商務網站建設、網站宣傳推廣和網站策劃等知識，稱之為不可不知的關鍵步驟是不為過的。

能夠充分理解這五個關鍵步驟，輔以強有力的執行，再加上持之以恆，那就等著看好吧，你的網站一定會名揚網路啊。

（信息來源：商城義烏p>