大型電子商務網站架構，摘抄

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緩衝，應該效率上能接受。