电子商务网站一般架构有哪些

大型电子商务网站架构，摘抄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，一个电子商务网站用户995%的行为时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)是要共享的,如何跨网站项目共享这些控件呢

那就做成自定义控件啦。

4ms的mvc10也出来不少时间了,是否已经够成熟运用到项目中或者是网站后台使用webform的,前台使用mvc

推荐使用使用webform的,前台使用mvc，对于前台来说使用mvc能更好的提升性能，更方便的更换页面表现形式。后台界面相对稳定，用webform可以提高开发效率。

5网站数据的缓存是自己开发一个hashtable什么的来维护呢,还是使用Memcached

初期建议用hashtable，因为简单，将来升级到Memcached。

6缩略图的处理,我看有的网站是在上传的时候直接生成,有的是在>

直接生成缩略图的好处是节约性能。>

7同一个网站的多语言该如何处理是好,使用配置文件然后cookie或url来判别

多语言建议使用aspnet自带的资源文件的方式实现，当前语言保存在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)是要共享的,如何跨网站项目共享这些控件呢

自定义控件。

4ms的mvc10也出来不少时间了,是否已经够成熟运用到项目中或者是网站后台使用webform的,前台使用mvc

正在学习这一块。

5网站数据的缓存是自己开发一个hashtable什么的来维护呢,还是使用Memcached

现在我用的比较多的是net自带的数据缓存。

6缩略图的处理,我看有的网站是在上传的时候直接生成,有的是在>

直接生成好，快一点。

7同一个网站的多语言该如何处理是好,使用配置文件然后cookie或url来判别

我没涉及到这一块，不过我觉得资源文件应该就是用来处理这个问题的。

8电子商务网站最多的就是商品的打折方式和积分的赠送了,这里要怎么设计才好(工厂模式)

这些都放在逻辑层好了。

9如果同一时间并发大量订单的话,如果确保一个订单的有效提交呢

MSMQ

10日志方面,log4net

目前我是自已写代码存在库里的。

11电子商务的全文检索,这也是个头疼的问题

用lucenenet分词建索引，再直接从索引库里搜索，又快又准。

12负载均衡方面,有什么好的文章推荐码

不清楚了。这样的设计要达到新蛋的效果肯定不可能的，新蛋少说几百台服务器，不同数据库之间的发布订阅链路都有几千条。有复杂的缓存，负载均衡机制。新蛋所有的通讯都是基于WCF的。另外对于这么大型的网站来说，数据库一刻都不停止，所以读写分离也很重要，因为你也不可能让数据库停下来进行备份。总归要做到新蛋这样的大型电子商务网站，靠你上面画的这点好像远远不够。

不过关于公共的header,footer,我不建议做成自定义控件，这个维护起来不方便，稍有变动就要发布dll，麻烦的。

如果你的header和footer不是很大的话，建议采用js+css的方式。然后加上压缩和cdn缓存，应该效率上能接受。

电商数据分析有几点很重要：

1、数据的及时更新

 对于电商数据来说，不同产品购买情况，不同渠道的销售情况，都需要每天关注查看，并及时根据数据变化调整策略

2、数据处理速度

电商数据通常是很大的，除了销售数据之外、流量类数据、用户类数据都需要分析关注，大量数据的查询处理，速度很重要

3、分析结果的清晰展现

在整理电商数据分析的指标体系和分析方法时，你会注意到，需要关注的指标非常多，所以建立清晰明确的分析报告，能有效监控和分析数据情况是必要的

目前在用的工具是海致BDP，可以比较好的对接数据库和推广渠道，分析速度快，建立了日常渠道和商品的监控看板，可以对比不同产品的销售情况、客单价、评价情况等。

其实早期得互联网公司曾经不仅是Oracle   客户，还都是大客户，最典型的代表有两个，一个是亚马逊，一个是阿里巴巴，后来两者都纷纷去掉了O，可见并不是什么ZZ因素，一定有一些原因，我们一起来逐步拨开看看：

 1Oracle数据库到底是为什么设计的？ 

Oracle数据库的理论源于1970年的一个论文，   "A Relational Model of Data for Large Shared Data Banks"   在这个论文中，提出了一个数据库的经典模型，也就是今天所谓的关系行数据库 Relational Database   这个论文，在当时验证了关系模型的一些优势。后来IBM基于这个论文开发了一个东西，叫SQL语言。   但是很奇怪的是，IBM没有更快的基于SQL语言去开发一个数据库，而Oracle在1979年第一个开发了商业级支持SQL语言的数据库产品。   当时，数据库主要处理的一个核心问题，就是几个特点ACID，鉴于篇幅，我们无法论述其中的意思，但是其中最有意思的就是一致性的C。什么意思呢，就是以银行交易为例，你如果在取钱的一瞬间查询余额有500，这个时候你取款，但是你恰好也告诉你家人在同一时间查询，如果查询到有500，他们也同时取款，会不会都成功呢？这个一致性的问题，对于银行要求是强一致性，也就是不能有半点差错。

2 互联网时代需要的数据库是什么？  

到了互联网时代，情况突然变了。比如我们都喜欢的知乎，微博这些信息流的App。   如果我发帖的瞬间，同时可能有很多人都在发帖，如果我们的App在全世界都在用，瞬间的用量峰值可能会因为某个热点事件突然变得很高，这个和上世纪80年代的企业级应用完全不同，即便是银行，我们还是可以保证当时的峰值大概有多少，因为营业点和ATM机的数量也是有限的，那时候你无法在手机上直接处理任何一笔交易。但是互联网的到来改变了一切，这个峰值不仅难以预估，而且可能和平时的平均值差别巨大。这样为了确保一个峰值，就去购买峰值所需的Oracle的License数量可能特别大。（Oracle是按照一个类似CPU数量或者用户数量来确定价格，你可以简单理解为用的峰值越高，你需要买的license越贵），这是一笔巨大的花费不说，而且还有另外一个问题。

3 互联网时代的应用需求不同。 

在我之前的一个回答里面写道了,   亚马逊工程师在优化自身的数据库的时候， 他们发现“：”   大约70%的 *** 作是键值类型的，其中只使用主键，只返回一行。大约20%的用户会返回一组行，但仍然只对单个表进行 *** 作。“这是一个伟大的发现——70%的 *** 作竟然都没有使用关系数据库的核心功能！为什么会这样呢？因为互联网时代的应用发生了变化。我举个例子，你如果设计一个类似亚马逊的电商网站的购物车，你允许客户把自己想买的东西放在里面。但是你设想一下，如果突然某个畅销的产品被卖家下架了，但是这个产品被很多的客户放在购物车里，你回想一下，银行交易需要确保的那种强一致性，在这里有必要么？如果你想强一致性，就需要这个商品下架的时候，清空每一个曾经加入购物车的这个商品。这样任何一个修改产品的 *** 作，都可能有无数个关联的交易在那里等着更新，可能商品的目录更新这个事情，就会变得巨慢无比，而且毫无意义。为什么说毫无意义呢，比如我在9点购物车放了一部手机，到10点商家卖光了，把这个产品下架了，这个时候如果商家只是在自己店面的页面更新，但是你的购物车并不实时更新，即使最差的情况是什么呢，就是10点的同时，你提交了一个购买的请求，这个购买的请求是需要保持一致性的，这个时候商家会返回一个失败，因为这个商品不存在。你再刷新一看，哦，卖光了。。。你的用户体验丝毫不受影响。再比如互联网的微博，如果我发一个微博就发上去，更新的时候，我不需要强一致性更新，那么可能和我距离近的朋友第一时间看到了，距离远的朋友可能稍晚一些看到了，有关系么？基本没什么影响，这些叫做分布式处理的方式在互联网应用非常普遍。

4 互联网时代有了更多选择

一方面开源数据库逐步成熟，MySQL，   Postgre这些后期之辈，陆续成熟且有越来越多的程序员能够熟练掌握，并且利用开源实现接近商业数据库的能力；另外一个方面，云厂商的出现让这个门槛更低，你不敢保证MySQL使用达到商业数据库的可靠性，你可以借助云厂商的产品，比如亚马逊云计算的托管数据库Aurora（兼容MySQL），这里非广告，只是告诉大家这种云厂商的产品让你用开源，性能和商业数据库接近，并且价格低廉，且无需运维或者很少运维成本，这样的情况下，中小互联网厂商就更多采用云厂商的托管开源数据库，自然不用Oracle这么昂贵的产品。

5   数据发生了变化

前面讲到微博这种信息流的数据格式很明显和银行交易类的关系格式有重大区别。其实互联网时代，日志，物联网等产生了更多奇怪的数据格式，比如时序数据，一个物联网的温度计，可能每一毫秒钟发一个温度信息，你如果拿关系数据库去存，可能很快就爆表了。。。但是物联网就是这样，而且这种数据几乎从不更改，就是按照时间序列一直存。比如股票交易所的大盘数据也是类似，这种特殊数据格式带来的需求在过去可能用关系数据库凑合一下就可以了，但是今天，越来越多的不同类型格式需求，就需要按需设计和采用不同的数据库。这些数据库因为有云的托管，你也不太需要运维，这样采用的成本也不高，比如亚马逊aws的Timestream数据库，官方号称两百万次写入1KB的数据，价格才一美金，于是，越来越多的企业开始按需去采用专门构建的数据库，而且大量采用云上托管，这些都不是Oracle数据库可以做的。

所以，各方面的综合因素，导致今天的Oracle跟不上时代，也就逐步被慢慢取代了。前几天，看到Gartner的全球数据库市场排名，亚马逊AWS取代了Oracle在全球数据库厂商的位置，一个时代就这样慢慢的被改变了，不知道我当时在Oracle   10g某个Package里面的代码是否还在？  

数据库是电子商务、金融以及ERP系统的基础，通常都保存着重要的商业伙伴和

客户信息。大多数企业、组织以及政府部门的电子数据都保存在各种数据库中，他们

用这些数据库保存一些个人资料，还掌握着敏感的金融数据。但是数据库通常没有象

*** 作系统和网络这样在安全性上受到重视。数据是企业，组织的命脉所在，因此选择

一款安全的数据库是至关重要的。大型网站一般使用oracle或DB2，而中小型网站大

多数使用更加灵活小巧的mssql数据库或者mysql数据库。

以上就是关于电子商务网站一般架构有哪些全部的内容，包括:电子商务网站一般架构有哪些、电商数据分析工具有哪些、为什么传统行业几乎都用Oracle，而互联网行业几乎都不用Oracle呢等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！