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鑾峰緱鐩稿叧淇℃伅鍜屾湇鍔°傚綋浼佷笟闇瑕佸拰鍏朵粬鎵鏈夌殑鍏鍙稿拰骞垮ぇ娑堣垂鑰呰繘琛屼氦娴佺殑鏃跺欍傚畠浠灏卞繀椤诲厖鍒嗗埄鐢ㄤ簰鑱旂綉銆備簰鑱旂綉鏄鐩鍓嶄笘鐣屼笂鏈澶х殑璁＄畻鏈洪氫俊缃戠粶锛屽畠灏嗕笘鐣屽悇鍦扮殑璁＄畻鏈虹綉閾鑱旂粨鍦ㄤ竴璧枫備紒涓氬紑灞曞叏闈㈢殑鐢靛瓙鍟嗗姟蹇呴』鍊熷姪浜掕仈缃戙
鍙鏈夊湪浼佷笟鍐呰仈缃戙佸栬仈缃戜互鍙婂熷姪浜掕仈缃戠殑鍓嶆彁涓嬶紝浼佷笟鎵嶅彲鑳藉疄鐜扮湡姝ｆ剰涔変笂鐨勫畬鍏ㄧ殑鐢靛瓙鍟嗗姟銆