A. 鐢靛瓙鍟嗗姟緗戠珯涓鑸鏋舵瀯鏈夊摢浜
1錛庣數瀛愬晢鍔＄殑鍩烘湰姒傚康鐢靛瓙鍟嗗姟鏄鍒╃敤璁＄畻鏈哄強浜掕仈緗戝紑灞曠殑鍚勭嶅晢鍔℃椿鍔ㄣ傚叾涓鐢靛瓙鏄鎵嬫碉紝鍟嗗姟鏄鐩鐨勩傛槸閫氳繃緗戠珯鐨勫晢鍔¤繍浣滃拰浼氬憳鍒舵敹璐癸紝杈懼埌鐩堝埄鐨勭洰鐨勩傜數瀛愬晢鍔″寘鎷浠ヤ笅涓夐儴鍒嗗唴瀹癸細
鐢靛瓙錛氭寚淇℃伅鍩虹璁炬柦鍙婄浉鍏沖簲鐢ㄧ郴緇燂紝鍏朵腑淇℃伅鍩虹璁炬柦鍖呮嫭internet緗戠粶鍩虹鍜屼俊鎮鎶鏈錛屽簲鐢ㄧ郴緇熷簲鍖呮嫭鏀鎸佺數瀛愬晢鍔℃椿鍔ㄧ殑緗戠珯銆
鍟嗗姟錛氭寚涓氬姟鍐呭廣佹祦紼嬪強瑙勫垯錛岃繖鏄鐢靛瓙鍟嗗姟緗戠珯緋葷粺璁捐＄殑鍩虹鍜屼緷鎹銆
淇℃伅錛氭寚涓氬姟媧誨姩涓鐨勬暟鎹錛屽簲瀹屾暣銆佸叏闈銆佸疄鏃躲佸姩鎬併備笟鍔℃椿鍔ㄦ墍浣跨敤鐨勬暟鎹涔熸槸緗戠珯緋葷粺鏁版嵁搴撹捐＄殑渚濇嵁銆侷nternet鎶鏈銆佷俊鎮鎶鏈緋葷粺鍜屽晢鍔¤繃紼嬬殑鏈夋満闆嗘垚褰㈡垚浜嗕竴涓鏂扮殑鍟嗗姟妯″瀷錛屽嵆鐢靛瓙鍟嗗姟妯″瀷銆2錛庣數瀛愬晢鍔＄綉絝欑殑鍩烘湰鏋舵瀯璁捐＄數瀛愬晢鍔＄綉絝欐槸浠ュ晢鍔℃椿鍔ㄤ負涓蹇冭繘琛岀殑錛岃岀綉絝欑殑鐩堝埄涓鑸閫氳繃緗戠珯鐨勪細鍛樺埗鏀惰垂榪涜岋紝緗戠珯鐨勭泩鍒╃偣鏄緗戠珯鏍規嵁緗戠珯鐨勫晢鍔℃椿鍔ㄥ唴瀹圭『瀹氱殑錛屾墍浠ョ綉絝欑殑鍩烘湰鏋舵瀯璁捐℃棦瑕佷互鍟嗗姟媧誨姩鐨勪笟鍔″唴瀹廣佹祦紼嬨佺浉鍏寵勫垯涓哄熀紜錛屽張瑕佸吋欏劇數瀛愬晢鍔＄綉絝欑殑鏀惰垂浣撶郴銆傜綉絝欏熀鏈鏋舵瀯鐨勮捐′富瑕佹牴鎹浠ヤ笅姝ラよ繘琛岋細2.1紜瀹氱數瀛愬晢鍔＄綉絝欏姛鑳藉畾浣嶇『瀹氱綉絝欐墍娑夊強鐨勫晢鍔℃椿鍔ㄧ殑鍐呭廣佸晢鍔℃椿鍔ㄧ殑嫻佺▼銆傛瘮濡傛垜浠鍦ㄨ繘琛屾埧浜т俊鎮緗戠殑璁捐′腑錛岄栧厛鑰冭檻紜瀹氱綉絝欏彂甯冩埧浜т俊鎮鐨勭嶇被錛岀『瀹氫簡鎴挎簮淇℃伅鍖呮嫭涓浠嬫墍鐨勬埧婧愪俊鎮鍜屼釜浜虹殑鍑哄敭銆佸嚭縐熶俊鎮錛岀綉絝欒礋璐ｄ俊鎮鐨勫彂甯冨拰淇℃伅鐨勭＄悊銆傚悓鏃跺湪紜瀹氫簡淇℃伅鍙戝竷縐嶇被鍚庯紝紜瀹氫簡淇℃伅澶勭悊鐨勬祦紼嬩負鎴挎簮淇℃伅杈撳叆銆佷細鍛樿祫鏍煎℃牳銆佷俊鎮瀹℃牳錛屼俊鎮鍙戝竷銆2.2紜瀹氱綉絝欑殑鏀惰垂瀵硅薄鍜屾敹璐硅勫垯鍦ㄧ綉絝欐墍娑夊強鐨勫晢鍔″唴瀹圭『瀹氫簡鐨勬儏鍐典笅錛岀『瀹氭敹璐圭殑瀵硅薄鍜屽備綍榪涜屾敹璐癸紝浠ユや負渚濇嵁紜瀹氱綉絝欑殑鏍忕洰銆傜綉絝欐爮鐩鐨勫垝鍒嗗疄闄呬笂灝辨槸緋葷粺鐨勫姛鑳芥ā鍧楀垝鍒嗐傚湪鎴誇駭緗戠珯鐨勭郴緇熻捐′腑錛岀『瀹氫簡緗戠珯鍙瀵規埧浜т腑浠嬫墍榪涜屾敹璐癸紝涓浜虹敤鎴峰厤璐癸紝鎵浠ョ綉絝欑殑涓昏佹爮鐩鍒嗕負涓浜轟笓鍖哄拰涓浠嬫墍涓撳尯涓や釜涓昏佹爮鐩錛屽悓鏃舵牴鎹鍔熻兘鐨勯愭ユ墿澶э紝榪欐牱涔熷氨鍩烘湰紜瀹氫簡緗戠珯鐨勪俊鎮鏈嶅姟鍐呭瑰拰鏂瑰紡銆2.3紜瀹氱綉絝欑殑鏍忕洰鐨勫姛鑳藉湪紜瀹氫簡緗戠珯鐨勬敹璐歸」鐩鍚庯紝瑕佺『瀹氱綉絝欑殑涓昏佹爮鐩鍜屽姛鑳斤紝鍖呮嫭緗戠珯鐨勭＄悊鍔熻兘妯″潡銆佺綉絝欑殑淇℃伅鍙戝竷鏂瑰紡銆佺綉絝欏晢鍔℃椿鍔ㄧ殑鍙戝竷浠ュ強緗戠珯瀵艱埅鏍忕瓑銆傜綉絝欑殑鍔熻兘鏍忕洰鐨勮劇疆鍜岀郴緇熺殑涓昏佸姛鑳芥ā鍧楃殑鍒掑垎鏄鐩鎬竴鑷寸殑銆傜綉絝欎笟鍔′粙緇嶆ф爮鐩錛屽簲鍖呮嫭鍐呭瑰簲鍖呮嫭浼氬憳鐢寵鋒祦紼嬶紝鏀惰垂鏍囧噯錛岀綉絝欒繍琛岃勭▼絳夛紝浣跨敤鎴峰圭綉絝欑殑鏈嶅姟鏈変竴涓鏄庣『鐨勪簡瑙ｏ紝鏄鎵╁ぇ緗戠珯鐨勪細鍛樼敤鎴鋒暟閲忓拰鎻愰珮緗戠珯鐨勪嬌鐢ㄧ巼閮芥槸蹇呬笉鍙灝戠殑鏍忕洰銆傜綉絝欑殑瀵艱埅鏍忔槸緗戠珯鐨勬暣浣撳姛鑳界殑鍏ㄩ潰浠嬬粛錛屼嬌鐢ㄦ埛瀵圭綉絝欑殑鍔熻兘鏈変竴涓娓呮櫚鐨勪簡瑙ｏ紝涔熸槸緗戠珯涓嶅彲緙哄皯鐨勬爮鐩銆傚悓鏃朵篃搴旀湁緗戠珯榪愯岀殑鐩稿叧鎻愮ず淇℃伅錛屾瘮濡傚湪鎴誇駭緗戠珯鐨勮捐′腑錛屾垜浠鍦ㄧ『瀹氫簡鏀惰垂瀵硅薄鍜屼富瑕佸姛鑳藉悗錛岀『瀹氫簡緗戠珯棣栭〉鐨勪富瑕佹爮鐩涓轟腑浠嬫墍涓撳尯銆佷釜浜轟笓鍖恆佸啓瀛楅棿涓撳尯銆佹柊鎴挎ゼ甯傜瓑鏍忕洰錛屽悓鏃跺姞鍏ヤ簡涓婄綉瀵艱埅鏍忕洰瀵圭綉絝欑殑涓昏佸姛鑳借繘琛屼粙緇嶃2.4紜瀹氱綉絝欑殑淇℃伅嫻佸拰鎺у埗嫻佸湪紜瀹氫簡緗戠珯鐨勪富瑕佸姛鑳藉拰鍟嗗姟媧誨姩鐨勪富瑕佽勫垯鍚庯紝搴旇ョ『瀹氱綉絝欑殑淇℃伅嫻佸浘鍜屾帶鍒舵祦鍥撅紝浣滀負鏁版嵁搴撹捐＄殑鍩虹銆傚湪鎴誇駭緗戠殑璁捐′腑錛屾垜浠鏍規嵁鎴誇駭淇℃伅鍙戝竷鐨勫姛鑳藉拰鎵紜瀹氱殑淇℃伅瀹℃牳鍜屾帶鍒舵祦紼嬶紝紜瀹氭埧浜х綉鐨勫熀鏈鏁版嵁嫻佸浘涓猴細瀹炰緥錛氫竴涓緗戠珯鐨勬暟鎹嫻佸浘鍦ㄧ『瀹氫簡涓涓緗戠珯鐨勬暟鎹嫻佸浘鍜屾帶鍒舵祦鍚庯紝緋葷粺鐨勮繍琛屾帶鍒舵祦紼嬩篃灝辯『瀹氫笅鏉ヤ簡銆3錛庣綉絝欑殑鍚庡彴綆＄悊鍦ㄧ綉絝欑殑鍩烘湰鍔熻兘鍜屾暟鎹嫻佺『瀹氬悗錛屼負浜嗕繚璇佺綉絝欎俊鎮鐨勫噯紜鎬у拰鏈夋晥鎬э紝搴旀湁瀹屽杽鐨勫悗鍙扮＄悊鍜岀淮鎶ょ郴緇燂紝榪涜岀浉鍏蟲暟鎹鐨勫℃牳錛屽畾鏈熻繘琛屾暟鎹搴撶殑緇存姢鍜屽囦喚錛岃繘琛岀即璐逛細鍛樿祫鏍肩殑綆＄悊錛屾湁鏁堢殑淇濊瘉緗戠珯鐨勫晢鍔¤繍浣溿傛垜浠鍦ㄦ埧浜т俊鎮鍙戝竷緗戠珯鐨勫悗鍙扮＄悊緋葷粺鐨勭郴緇熻捐′腑錛岃捐′簡涓濂楀畬鏁寸殑緗戠珯鍚庡彴綆＄悊緋葷粺錛屼富瑕佸姛鑳藉寘鎷鎴挎簮淇℃伅綆＄悊濡傦細鎴誇駭淇℃伅瀹℃牳銆佹埧浜т俊鎮鍒犻櫎銆佹埧浜т俊鎮鍒犻櫎紜璁わ紱緗戠珯榪愯屾彁紺轟俊鎮鐨勭＄悊錛屼富瑕佹槸瀵圭綉絝欎笌鍟嗗姟榪愯惀鏈夊叧鐨勪俊鎮榪涜岀＄悊錛屼嬌緗戠珯鐨勭敤鎴峰圭綉絝欑殑榪愯屾儏鍐佃繘琛岀＄悊錛涚綉絝欎細鍛樿祫鏍肩殑瀹℃牳錛屽歸炬湡鏈緙磋垂鐨勭敤鎴峰彇娑堜細鍛樿祫鏍礆紱緗戠珯緋葷粺綆＄悊鍛樻潈闄愮＄悊錛屽逛笉鍚岀殑緗戠珯緋葷粺綆＄悊浜哄憳榪涜屾巿鏉冧嬌鐢ㄤ笉鍚岀殑鍚庡彴緇存姢鍔熻兘銆4錛庣綉絝欑殑鏁版嵁搴撹捐″湪紜瀹氫簡緗戠珯鐨勪富瑕佸晢鍔＄殑涓氬姟瀵硅薄鍜屼笟鍔℃祦紼嬪悗錛屽彲浠ョ『瀹氫簡緗戠珯鐨勬暟鎹嫻侊紝涔熷氨鍙浠ヨ繘琛屾暟鎹搴撹捐°傚湪榪涜屾暟鎹搴撹捐℃椂錛屽悓鏍峰拰涓鑸鐨勫簲鐢ㄧ郴緇熷紑鍙戜竴鏍鳳紝搴旇ユ敞鎰忎俊鎮鐨勫畬鏁存у拰鏁版嵁鐨勭嫭絝嬫с傛垜浠鍦ㄦ埧浜х綉絝欑殑寮鍙戣繃紼嬩腑錛屽湪鏁版嵁搴撶殑璁捐￠樁孌碉紝瀵圭郴緇熺殑鏁版嵁搴撴寜鎴挎簮鐨勫熀鏈淇℃伅銆佷腑浠嬫墍淇℃伅銆佷釜浜轟俊鎮鍒嗗埆榪涜屽簱琛ㄧ殑璁捐★紝鍚屾椂瀵圭郴緇熺殑緇存姢淇℃伅銆佹潈闄愮＄悊絳夋帶鍒朵俊鎮璁捐＄嫭絝嬬殑搴撹〃錛屼富瑕佺殑鏁版嵁搴撹〃涓烘埧婧愪俊鎮琛ㄣ佷腑浠嬫墍淇℃伅琛ㄣ佷細鍛樹俊鎮琛ㄧ瓑錛岃繖鏍峰彲浠ユ柟渚跨綉絝欑殑淇℃伅杈撳叆銆佹暟鎹搴撴煡璇㈠悓鏃朵篃鏂逛究緗戠珯鍚庡彴鐨勬暟鎹搴撶＄悊鍜屾暟鎹搴撶淮鎶ゃ傛暟鎹搴撹〃鏁版嵁鐨勭嫭絝嬫у拰鏁版嵁鍐椾綑鐩存帴褰卞搷鏁版嵁鐨勫瓨鍙栨晥鐜囷紝褰卞搷緗戠珯鐨勮繍琛岄熷害錛屾墍浠ュ湪鏁版嵁搴撹捐℃椂涓瀹氳侀伩鍏嶆暟鎹鐨勫啑浣欐э紝鍚屾椂瑕侀伩鍏嶉暱鏁版嵁搴撹〃鐨勮捐°傛葷粨錛氬湪鐢靛瓙鍟嗗姟緗戠珯寮鍙戣繃紼嬩腑錛岀綉絝欑殑鍟嗕笟榪愪綔妯″紡鍐沖畾浜嗙綉絝欑郴緇熻捐★紝涓涓鍔熻兘娓呮櫚鐨勭綉絝欑殑璁捐★紝涓瀹氳佷粠緗戠珯鐨勭郴緇熻捐″叆鎵嬨
B. 電子商務網站一般架構有哪些
大型電子商務網站架構，摘抄 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緩存，應該效率上能接受。
C. 電子商務網站常用的系統架構哪些
一. 商品展示
站內搜索(搜索提示，搜索規則，搜索成功頁，搜索不成功頁，相似推薦)
導航(頻道導航，其他導航如銷售排行，廣告位，推薦位，文字鏈，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。
D. 電子商務的三層結構模型是什麼
1、電子商務的三層結構模型，是指在客戶端與資料庫之間加入了一個「中間層」，也叫組件層。並不是指物理上的三層，不是簡單地放置三台機器就是三層體系結構，也不僅僅有B/S應用才是三層體系結構。三層是指邏輯上的三層，即使這三個層放置到一台機器上。三層體系的應用程序將業務規則、數據訪問、合法性校驗等工作放到了中間層進行處理。通常情況下，客戶端不直接與資料庫進行交互，而是通過COM/DCOM通訊與中間層建立連接，再經由中間層與資料庫進行交互。
2、1998年，SUN公司將電子商務體系結構被分解成表達層、應用（邏輯）層和數據層。
（1）表達層。表達層以Web伺服器為基礎，負責信息的發布，用於顯示數據和接收用戶輸入的數據，為用戶提供一種互動式操作的界面。
（2）應用層。應用層是系統架構中最體現核心架構的部分，處於數據層與表示層之間，起到了數據交換中承上啟下的作用。根據分層的思想，對於數據層而言，應用層是調用者，對於表達層而言，應用層是被調用者，應用層負責體系架構中所有核心業務邏輯的處理。
（3）數據層。數據層的基礎是DBMS，負責資料庫的訪問，可以訪問資料庫系統、二進制文件、文本文檔或是XML文檔。
E. 什麼是B2C電子商務數據架構模式
B2C(Business to Customer) 電子商務是以Internet 為主要手段, 由商家或企業通過網站向消費者提供商品和服務的一種商務模式。 目前,在Internet 上遍布了各種類型的B2C 網站,提供從鮮花、書藉到計算機、汽車等各種消費品和服務。 由於各種因素的制約,目前以及未來比較長的一段時間內, 這種模式的電子商務還只能佔比較小的比重。但是,從長遠來看, 企業對消費者的電子商務將取得快速發展, 並將最終在電子商務領域占據重要地位。 1、B2C電子商務模式分析 可以從不同角度對B2C 的商務模式進行分類和探析。 1.1 從企業和消費者買賣關系的角度分析 B2C 的商務模式主要分為賣方企業—買方個人的電子商務及買方企業— 賣方個人的電子商務兩種模式。 1.1.1 賣方企業—買方個人模式。 這是商家出售商品和服務給消費者個人的電子商務模式。 在這種模式中,商家首先在網站上開設網上商店,公布商品的品種、 規格、價格、性能等,或者提供服務種類、價格和方式, 由消費者個人選購,下定單,在線或離線付款,商家負責送貨上門。 這種網上購物方式可以使消費者獲得更多的商品信息, 雖足不出戶卻可貨比千家,買到價格較低的商品,節省購物的時間。 當然這種電子商務模式的發展需要高效率和低成本的物流體系的配合 。這種方式中比較典型的代表就是全球知名的亞馬遜網上書店( ht tp://www.amazon.com) 。 1.1.2 買方企業—賣方個人的電子商務。 這是企業在網上向個人求購商品或服務的一種電子商務模式。 這種模式應用最多的就是企業用於網上招聘人才。 如許多企業在深圳人才市場網( http://www.szhr. com.cn) 招聘各類人才。在這種模式中,企業首先在網上發布需求信息, 後由個人上網洽談。 這種方式在當今人才流動量大的社會中極為流行, 因為它建立起了企業與個人之間的聯系平台, 使得人力資源得以充分利用。 1.2 根據交易的客體分析 可把B2C 電子商務分為無形商品和服務的電子商務模式以及有形商品和服務的 電子商務模式。前者可以完整地通過網路進行, 而後者則不能完全在網上實現,要藉助傳統手段的配合才能完成。 1.2.1 無形商品和服務的電子商務模式。 計算機網路本身具有信息傳輸和信息處理功能,無形商品和服務( 如電子信息、計算機軟體、數字化視聽娛樂產品等) 一般可以通過網路直接提供給消費者。 無形商品和服務的電子商務模式主要有網上訂購模式、 廣告支持模式和網上贈予模式。 a. 網上訂閱模式。消費者通過網路訂閱企業提供的無形商品和服務, 並在網上直接瀏覽或消費。 這種模式主要被一些商業在線企業用來銷售報刊雜志、 有線電視節目等。網上訂閱模式主要有以下幾種:
F. 電子商務網站伺服器需要什麼配置
電子商務網站來的伺服器需要企業級高性能的機型。商城網站因為屬於在線交易類型的性質，所以在線人數較多，安全性、穩定性、速度都有要求的。
對於電子商務網站而言，安全性一直是客戶網路交易的最大問題之一，所以,選擇一個快速、安全的託管解決方案很有必要，關鍵是能從黑客和釣魚網站中保護你用戶數據安全。
1、快速而穩定的伺服器
無論是什麼行業或者類型的網站，快速穩定的伺服器是每個網站正常運行的前提，是支撐電商網站運營的支柱，一旦伺服器出現了問題，將會帶來嚴重的後果。所以伺服器的選擇非常重要，我們在租用伺服器時一定要對其進行全面的考察以及使用過該伺服器的用戶的一些評價。在選擇時，最 好選用知 名品牌主機，即使對伺服器不是很了解，也不會上當受坑。
2、合適的網站空間與流量
電商網站的圖片一般比較多，特別是為了更好地展示產品或服務，我們會找專人設計優質的頁面，這樣也就導致圖片比較大。再者就是電商網站一般訪客比較多，所以在空間和流量方面不要太小，不然會導致空間和流量不夠用，網站被迫停止訪問。當然也不要一味追求大的空間和流量，以免導致資源的浪費。當您對此不知道如何選擇時，在購買時可以咨詢下技術支持人員，他們會給您推薦最合適的主機。
3、伺服器安全加密
Linux操作系統和cPanel的安全加密增加了的伺服器安全性。通過增加伺服器強化舉措，它大大提高了用戶的伺服器和軟體的安全性、可靠性和兼容性。
4、安裝SSL數字證書
電商網站都是線上交易，必須保證用戶線上交易的安全，所以需要強大的加密系統。SSL數字證書通過加密最大程度的保護網站用戶的訪問數據，而且具有安全標示的網站更容易獲取用戶的信任。
電商網站對伺服器配置的要求還是非常高的，不但要速度、空間、流量，更需要安全穩定，所以再次提醒您，如果是電商網站盡量選擇知 名品牌銳訊網路的伺服器，它是您安全交易的保障。
G. 鐢靛瓙鍟嗗姟鐨勫熀紜妗嗘灦緇撴瀯鏄鎬庢牱鐨
浠庢妧鏈瑙掑害鐪嬶紝鐢靛瓙鍟嗗姟鐨勫熀紜妗嗘灦緇撴瀯鐢變互涓嬩笁閮ㄥ垎緇勬垚錛
(涓)浼佷笟鍐呴儴緗
浼佷笟鍐呴儴緗戠敱Web鏈嶅姟鍣ㄣ佺數瀛愰偖浠舵湇鍔″櫒銆佹暟鎹搴撴湇鍔″櫒浠ュ強瀹㈡埛絝鐨凱C鏈虹粍鎴愩傛墍鏈夎繖浜涙湇鍔″櫒鍜孭C鏈洪兘閫氳繃鍏堣繘鐨勭綉緇滆懼囬泦綰垮櫒HUB鎴栦氦鎹㈠櫒SWITCH榪炴帴鍦ㄤ竴璧楓
WEB鏈嶅姟鍣ㄥ彲浠ュ悜浼佷笟鍐呴儴鎻愪緵涓涓鍐呴儴WWW絝欑偣錛屽熸ゆ彁渚涗紒涓氬唴閮ㄦ棩甯哥殑淇℃伅璁塊棶錛涢偖浠舵湇鍔″櫒涓轟紒涓氬唴閮ㄦ彁渚涚數瀛愰偖浠剁殑鍙戦佸拰鎺ユ敹錛涙暟鎹搴撴湇鍔″櫒閫氳繃WEB鏈嶅姟鍣ㄥ拰鐢辮嚜宸卞逛紒涓氬唴閮ㄥ拰澶栭儴鎻愪緵鐢靛瓙鍟嗗姟澶勭悊鏈嶅姟錛涘㈡埛絝疨C鏈哄垯鐢ㄦ潵涓轟紒涓氬唴閮ㄥ憳宸ユ彁渚涜塊棶宸ュ叿錛屽憳宸ュ彲浠ラ氳繃絳夋祻瑙堝櫒鍦ㄦ潈闄愬厑璁哥殑鍓嶆彁涓嬫柟渚垮揩鎹峰湴璁塊棶鍚勭嶆湇鍔″櫒銆
(浜)浼佷笟澶栬仈緗
浼佷笟澶栬仈緗戞槸鏋舵瀯鍦ㄤ紒涓氬唴鑱旂綉鍜屼緵搴斿晢銆佸悎浣滀紮浼淬佺粡閿鍟嗙瓑鍏朵粬浼佷笟鍐呰仈緗戜箣闂寸殑閫氫俊緗戠粶銆備篃鍙浠ヨ達紝浼佷笟澶栬仈緗戞槸鐢變袱涓鎴栦袱涓浠ヤ笂鐨勪紒涓氬唴鑱旂綉榪炴帴鑰屾垚鐨勩傝繖鏍風粍緇囦箣闂村氨鍙浠ヨ塊棶褰兼ょ殑閲嶈佷俊鎮錛屽傚畾璐淇℃伅銆佷氦璐т俊鎮絳夈傚綋鐒訛紝緇勭粐闂撮氳繃澶栬仈緗戝悇鑷鐨勯渶瑕佸叡浜涓閮ㄥ垎鑰屼笉鏄鍏ㄩ儴鐨勪俊鎮銆
(涓)Internet
Internet鏄鐢靛瓙鍟嗗姟鏈騫挎硾鐨勫眰嬈°備換浣曠粍緇囬兘鍙浠ラ氳繃Internet鍚戜笘鐣屼笂鎵鏈夌殑浜哄彂甯冨拰浼犻掍俊鎮錛岃屼換浣曞叆閮藉彲浠ヨ塊棶Internet鑾峰緱鐩稿叧淇℃伅鍜屾湇鍔°傚綋浼佷笟闇瑕佸拰鍏朵粬鎵鏈夌殑鍏鍙稿拰騫垮ぇ娑堣垂鑰呰繘琛屼氦嫻佺殑鏃跺欍傚畠浠灝卞繀欏誨厖鍒嗗埄鐢ㄤ簰鑱旂綉銆備簰鑱旂綉鏄鐩鍓嶄笘鐣屼笂鏈澶х殑璁＄畻鏈洪氫俊緗戠粶錛屽畠灝嗕笘鐣屽悇鍦扮殑璁＄畻鏈虹綉閾鑱旂粨鍦ㄤ竴璧楓備紒涓氬紑灞曞叏闈㈢殑鐢靛瓙鍟嗗姟蹇呴』鍊熷姪浜掕仈緗戙
鍙鏈夊湪浼佷笟鍐呰仈緗戙佸栬仈緗戜互鍙婂熷姪浜掕仈緗戠殑鍓嶆彁涓嬶紝浼佷笟鎵嶅彲鑳藉疄鐜扮湡姝ｆ剰涔変笂鐨勫畬鍏ㄧ殑鐢靛瓙鍟嗗姟銆