『壹』 電子商務網站一般架構有哪些
大型電子商務網站架構，摘抄 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緩存，應該效率上能接受。
『貳』 電子商務網站開發的基本原則
可能需要考慮的16項原則
1，你不可能滿足所有的用戶。
2，如果一個蠢方法有效，那它就不是一個蠢方法。
3，別忘了你的產品是由最年輕的程序員在最短的時間內開發出來的，所以，問題總是無法避免。
4，如果某個產品創意，只有你一家這么做，那一定是錯誤的方向。
5，沒有任何產品開發，運營計劃在實踐中能繼續順利執行。
6，所有預期5個月才會到來的瓶頸總是3個月內就會遇到。
7，重要的事總是簡單的。
8，簡單的事總是難以做到。
9，一般情況下，你除了時間外什麼都不缺。
10，關鍵用戶的意志應該獲得優先考慮。（不一定是大多數的）
11，當用戶為你免費生產內容的時候，別忘了，同時也在生產垃圾和風險。
12，需要兩個人彼此協助才能完成的任務，通常不會按時完成。
13，資金，設備，人才總是在你最需要的時候，找不到。
14，你為產品增加的任何功能都可能反而損害產品的競爭力－－－什麼都不做也一樣。
15，唯一比競爭對手還可怕的是內部開發，運營人員虛妄的想法。
16，正常用戶的行為是可以預測的，但是互聯網上卻充斥著各種各樣的玩家。
總結: 其實最重要的還是網站策劃,運營,開發方面 技術現在來看都比較成熟了
『叄』 網站URL動態改為靜態後為什麼百度一向不收錄
肯定要做301重定向,因為spider在你網站沒有做偽靜態之前,已經收錄了你的文章,現在要是沒有做301重定向,它是不知道把資料庫裡面的鏈接替換成現在的鏈接!也不會收錄已經收錄過的文章,就等於spider光顧你的網站時候已經找不到之前的鏈接而會慢慢的減少資料庫里的索引量,如果讓它長時間找不到的話,對你的網站來說就相當於之前收錄的所有文章在它的眼裡慢慢的消失掉,最終讓它不信任你的網站而面臨降權!
『肆』 電子商務網站建設
電子商務的模式
①純粹的電子商務網站。一種是阿里巴巴、中國化工網等門戶網站；一種是Amazon、8848這樣的零售網站模式。本報告將分析它們的發展前景以及電子商務網站盈利的支撐點。
②傳統產業的電子商務模式。一種是大公司，自建網站與供應商、客戶甚至最終消費者進行網上交易，其為企業帶來的好處最明顯。一種就是中小企業，以參加專業的網上信息與交易平台為較好選擇。
如果你要學習電子商務的內容,可以去"千源網"去找找,那裡有許多視頻資源供你參考,具體講解有關建設商務網站種種問題.
另外你還可以參照
順達CEO仿安利銷售模式電子商務管理系統
http://www.codefans.com/download.asp?CodeID=8320 祝你好運!
『伍』 網站哪些內容適合用CDN技術
網站哪些內容都可以使用CDN技術的。
CDN即內容分發網路，是構建在現有網路基礎之上的智能虛擬網路，CDN加速原理是用戶首次請求到CDN節點，CDN節點未命中向源站獲取文件，源站根據請求響應內容給CDN節點，同時CDN節點緩存內容，CDN節點將內容響應給終端用戶，當同一CDN節點內的用戶再次訪問時，CDN便會直接將緩存內容返回給用戶，讓用戶就近獲取所需內容，降低網路擁塞，提高用戶訪問響應速度和命中率。CDN加速功能雖然用域廣泛，但並不是任何互聯網產品都適用,考慮到加速的效果和運營成本，整理出推薦適用CDN加速的七類網站內容。
一. 靜態資源加速
著互聯網開發和迭代速度越來越快，我們訪問的網站也變得越來越龐大，一般的企業官網以及各類展示型網站的伺服器上都存儲了大量靜態資源，當較多用戶訪問我們的網站請求JS、CSS、圖片等靜態資源時，高並發量增加源站了壓力，造成訪問網路擁堵，導致我們的網站變慢卡頓。若把我們的靜態資源緩存到CDN節點上，訪問網站的用戶直接請求到就近CDN節點，CDN節點向用戶分發傳輸相關庫的靜態資源文件，這樣就可以降低網站自身伺服器的請求壓力，提高了網站的訪問速度和用戶體驗。
二. 動態資源加速
如今我們的互聯網產品需求功能化要求巨大，我們的動態產品越來越多，交互性的動態網頁如用戶注冊、信息發布、產品展示、訂單管理等網站，動態網站大大節省工作量，無須手動的自動更新，因時因人而變，不同時間、不同用戶訪問同一網址時會出現不同頁面等需求功能。動態資源實時性，交互性需求量更大，CDN加速系統中的核心伺服器與DNS技術相結合，實時監控網路環境變化，監控各地網路延遲，有效避開網路瓶頸及擁堵環節，提高數據在源站與互聯網終端用戶之間傳輸的穩定及高效性，保障各種動態數據能夠及時傳遞到終端，提高頁面載入速度及頁面展現質量。
三. 音頻/視頻加速
這個時代音樂，直播，小視頻，電影，電視，填滿了我們的碎片時光，大部分人生活離不開音頻/視頻，高質的用戶體驗要求音頻/視頻要扛得起夜晚高峰期的百萬高並發，呈現的依然是穩定高清音畫質，並且保證隱私信號傳輸的全程加密，CDN的HTTP/HTTPS音/視頻點播加速服務通過將音頻/視頻文件快速分層同步傳輸到加速節點上,當最終用戶訪問時將其對網站的請求定向到離用戶最近的節點上,為用戶提供穩定可靠高質的HTTP/HTTPS音頻/視頻聽覺視覺服務。
四. 圖片加速
普通人常用的圖片站一般為素材圖片網站，漫畫壁紙圖片站，圖片拼圖工具網站，圖片在線交易平台等，為個人及企業提供所需圖片素材搜索，圖片觀看,高清圖片下載等服務，例如漫畫和電商平台上每天都會有大量商品圖片的查詢更新請求，高峰情況下每天有千萬級甚至億級的圖片，CDN系統使網路和客戶源文件伺服器形成良好的互動,即將源站的圖片(jpg,jpeg,png,gif,bmp等各種格式)、flash動畫、css/js、及各種文件類型的圖片緩存到節點上，無需服務端改造，能夠使整體圖片流量帶寬下降30%~40%，實現各地用戶實時快速訪問刷新獲取網站圖片。
五. 下載加速
工具APP下載是我們現代人最基礎手機的使用習慣，網路軟體、殺毒軟體、聊天工具、系統工具、媒體播放、輸入法、手機主題和驅動等豐富的綠色軟體等軟體的全網下載需求促使軟體開發商們及軟體下載站需要提供安全、綠色、快速,是國內專業的下載環境，CDN下載加速就能為用戶創造高速加密的下載場景，CDN下載分發加速,針對安裝包獲取、手機ROM升級、應用程序包下載等業務場景，提供穩定、優質的下載加速，具備突發性超大流量承載能力。利用多級緩存收斂及資源預熱，緩解源站壓力，讓用戶獲得極速的下載體驗。
六. 海外加速
全球互聯產生的跨境電商，海外游戲，國外網站，讓文化物品跨越物理距離來到全人類面前。物理上的距離讓數據傳輸在高並發時期速度緩慢，致使海外用戶體驗感較差，針對部分海外運營商存在國際出口投入大、業務成本高;基礎設施不完善，網路穩定性低;缺乏技術人才，運營能力差;大量訪問用戶訴求難以解決等問題，CDN依託遍及全球加速節點資源豐富,500+中國大陸境外加速，利用底層服務商自研的智能全球調度體系和質量實時監控系統，精準調度境外用戶請求，提供靜態外文網站、跨境電商圖片網站，游戲APP下載、音視頻等多種加速業務及整體解決方案。CDN能有效降低跨境訪問延遲，提升服務可用性，支持全球業務無縫出海。
七. 安全加速
我們使用的大多數網站APP的設計開發，只考慮到展示和正常用戶穩定使用，對於看不見的網站安全並沒有太多重視。互聯網經濟的興起，出於惡性商業競爭、敲詐勒索等原因，1999年開始一些企業網站受到DDOS，CC攻擊,雅虎是當時最著名的受害者，近年來隨著攻擊成本越來越低、效果特別明顯等特點,DDOS，CC攻擊已經演變成全球性網路安全威脅。攻擊者藉助代理伺服器向受害主機發送大量的合法請求，導致受害網站資料庫壓力就越大，被訪問的頻率也越高，佔用大量的系統資源導致網站打開緩慢或者無法訪問。眾所周知DDOS攻擊主要針對的是IP，所以隱藏源站IP就顯得十分重要，CDN 服務將網站訪問流量分配到了各個節點中，這樣一方面隱藏網站的真實IP，另一方面即使遭遇 DDOS攻擊，也可以將流量分散到各個節點中，防止源站崩潰，從而起到防禦的作用，為網站APP做好防護。
『陸』 電商網站商品列表頁用的是搜索引擎還是資料庫+緩存的方式
大的電商網站頁面一般都是從緩存裡面讀取過來的，頁面更新快的緩存時間比較短。
搜索頁面建議是不加緩存，或者緩存時間極短。因為用戶關鍵詞很難確定，或許高頻詞會緩存一些，這些就得看網站的部署策略了，緩存策略只是解決了資料庫訪問的壓力
除了頁面緩存之外，資料庫還需要定時更新索引，索引的更新才是決定頁面最終命中效果的關鍵，大的電商網站索引創建會很耗時，所以需要相對較長的時間才會更新一下索引系統