求电商公司的架构图，服务器摆放，所用技术等等

电商公司，网络架构要保证的就是两点：1 速度 2 不间断

所以，外局，最起码要求两条INET线路（最好是两条光纤，理想状态是两条当地最快供应商的光纤，比如说电信，一条备用光纤比如说联通）

因为有两条或以上的INET，所以路由器也必须是支持多WAN的，建议并发处理万级以上的，不然CPU会吃不消。

路由器也要备多一个，备用的可以1千元以下的足够了。

负载均衡，用海蜘蛛、wayos，ros等设置就可以了，所以路由器本身就要选折这种系统的，还要限制流媒体和BT等吃流量厉害的软件。

主千兆交换机背板起码要80G以上的了。

下层的交换机，最好能是分组分部门，控制在每组16-24口之内。

注意预留备用交换机。

主流量服务器设置稳定后，建议还是摆放到专业机房去，毕竟那里的带宽是足够的，环境也舒适。

公司内如果光纤有固定ip，总下行可保证在200M，总上行可保证在50M，可在公司内做一个镜像服务器，由外部主服务器推送过来（下行），当然，最好有独立的镜像用光纤。

主从服务器的硬件反而要求不太高，现在几万的机子，硬件已经好得很了，不过一定要raid 5以上。

数据库，最起码是sql，然后就oracle，要看口袋里的银子。

最后，就是ups，智能管理的也是必须的，5kva以上吧，不然整个机房就没必要搞了。

噢，对了，空调和空净机也不能少，没空调你敢搞电商服务器？

摘要：服务器是指具有固定的地址，并为网络用户提供服务的节点，它能提高访问速度，也可以起到防火墙的作用。市面上的服务器可按照体系架构进行分类，也可按照应用层次进行分类。服务器的组成结构与普通电脑非常相似，主要包括中央处理器、内存、芯片组、I/O总线、I/O设备、电源、机箱等等部分，接下来就和小编一起来看看吧。服务器的种类有哪些

一、按照体系架构分类

1、非x86服务器

非x86服务器包括大型机、小型机和UNIX服务器，它们是使用RISC（精简指令集）或EPIC（并行指令代码）处理器，并且主要采用UNIX和其它专用操作系统的服务器。这种服务器价格昂贵，体系封闭，但是稳定性好，性能强，主要用在金融、电信等大型企业的核心系统中。

2、x86服务器

x86服务器又称CISC（复杂指令集）架构服务器，即通常所讲的PC服务器，它是基于PC机体系结构，使用Intel或其它兼容x86指令集的处理器芯片和Windows操作系统的服务器。价格便宜、兼容性好、稳定性较差、安全性不算太高，主要用在中小企业和非关键业务中。

二、按照应用层次分类

1、入门级服务器

这类服务器是最基础的一类服务器，也是最低档的服务器。入门级服务器主要采用Windows或者NetWare网络操作系统，可以充分满足办公室型的中小型网络用户的文件共享、数据处理、Internet接入及简单数据库应用的需求。随着PC技术的日益提高，许多入门级服务器与PC机的配置差不多，所以也有部分人认为入门级服务器与“PC服务器”等同。

2、工作组服务器

工作组服务器是一个比入门级高一个层次的服务器，但仍属于低档服务器之类。从这个名字也可以看出，它只能连接一个工作组（50台左右）那么多用户，网络规模较小，服务器的稳定性也不像下面我们要讲的企业级服务器那样高的应用环境，当然在其它性能方面的要求也相应要低一些。

工作组服务器较入门级服务器来说性能有所提高，功能有所增强，有一定的可扩展性，但容错和冗余性能仍不完善、也不能满足大型数据库系统的应用，但价格也比前者贵许多，一般相当于2~3台高性能的PC品牌机总价。

3、部门级服务器

这类服务器是属于中档服务器之列，一般都是支持双CPU以上的对称处理器结构，具备比较完全的硬件配置，如磁盘阵列、存储托架等。部门级服务器的最大特点就是，除了具有工作组服务器全部服务器特点外，还集成了大量的监测及管理电路，具有全面的服务器管理能力，可监测如温度、电压、风扇、机箱等状态参数，结合标准服务器管理软件，使管理人员及时了解服务器的工作状况。

大多数部门级服务器具有优良的系统扩展性，能够满足用户在业务量迅速增大时能够及时在线升级系统，充分保护了用户的投资。它是企业网络中分散的各基层数据采集单位与最高层的数据中心保持顺利连通的必要环节，一般为中型企业的首选，也可用于金融、邮电等行业。

4、企业级服务器

企业级服务器是属于高档服务器行列，正因如此，能生产这种服务器的企业也不是很多。企业级服务器最起码是采用4个以上CPU的对称处理器结构，有的高达几十个。另外一般还具有独立的双PCI通道和内存扩展板设计，具有高内存带宽、大容量热插拔硬盘和热插拔电源、超强的数据处理能力和群集性能等。企业级服务器适合运行在需要处理大量数据、高处理速度和对可靠性要求极高的金融、证券、交通、邮电、通信或大型企业。

服务器的组成结构是什么

服务器系统的硬件构成与我们平常所接触的电脑有众多的相似之处，主要的硬件构成仍然包含中央处理器、内存、芯片组、I/O总线、I/O设备、电源、机箱和相关软件这几个主要部分，这也成了我们选购一台服务器时所主要关注的指标。

在信息系统中，服务器主要应用于数据库和Web服务，而PC主要应用于桌面计算和网络终端，设计根本出发点的差异决定了服务器应该具备比PC更可靠的持续运行能力、更强大的存储能力和网络通信能力、更快捷的故障恢复功能和更广阔的扩展空间，同时，对数据相当敏感的应用还要求服务器提供数据备份功能。而PC机在设计上则更加重视人机接口的易用性、图像和3D处理能力及其他多媒体性能。

服务器有什么作用

1、提高访问速度。因为客户要求的数据存于代理服务器的硬盘中，因此下次这个客户或其它客户再要求相同目的站点的数据时，就会直接从代理服务器的硬盘中读取，代理服务器起到了缓存的作用，对热门站点有很多客户访问时，代理服务器的优势更为明显。

2、服务器可以起到防火墙的作用。因为所有使用服务器的用户都必须通过服务器访问远程站点，因此在服务器上就可以设置相应的限制，以过滤或屏蔽掉某些信息。这是局域网网管对局域网用户访问范围限制最常用的办法，也是局域网用户为什么不能浏览某些网站的原因。拨号用户如果使用服务器，同样必须服从服务器的访问限制，除非你不使用这个服务器。

3、通过服务器访问一些不能直接访问的网站。互联网上有许多开放的服务器，客户在访问权限受到限制时，而这些服务器的访问权限是不受限制的，刚好服务器在客户的访问范围之内，那么客户通过服务器访问目标网站就成为可能。国内的高校多使用教育网，不能出国，但通过服务器，就能实现访问因特网，这就是高校内服务器热的原因所在。

4、安全性得到提高。无论是上聊天室还是浏览网站，目的网站只能知道你来自于代理服务器，而你的真实IP就无法测知，这就使得使用者的安全性得以提高。

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

那就做成自定义控件啦。

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

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

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

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

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

直接生成缩略图的好处是节约性能。httpmodle相反，每次浏览的时候都会生成新的，服务器压力大，建议直接生成。

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

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

自定义控件。

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

正在学习这一块。

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

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

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

直接生成好，快一点。

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

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

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

这些都放在逻辑层好了。

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

MSMQ

10日志方面,log4net

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

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

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

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

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

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

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

传统电商架构是基于产品的基础属性，由产品、包装、平台运营、渠道推广组成；而O2O电商产品架构是基于线上和线下相结合的方式。将传统电商融入到O2O电商产品架构当中，不仅让消费者直观的感受到产品真实性，也能体验电商购物的便捷！

初始阶段的网站架构

大型网站都是从小型网站发展而来，网站架构也是一样，是从小型网站架构逐步演化而来，小型网站最开始没有太多人访问，只需要一台服务器就绰绰有余，这时的网站架构如图。

应用程序，数据库，文件等所有的资源都在一台服务器上。通常服务器操作系统使用Linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用MySql，汇集各种开源软件及一台廉价服务器就可以开始网站的发展之路了。

应用服务和数据服务分离

随着网站业务的发展，一台服务器逐渐不能满足需求：越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足，这时就需要将应用和数据分离，应用和数据分离后整个网站使用三台服务器：应用服务器，文件服务器和数据库服务器，如下图所示，这三台服务器对硬件资源的要求各不相同，应用服务器需要处理大量的业务逻辑，因此需要更快更强大的CPU,数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存，文件服务器需要储存大量用户上传的文件，因此需要更大的硬盘。

应用和数据分离后，不同特性的服务器承担不同的服务角色，网站的并发处理能力和数据存储空间得到了很大改善，支持网站业务进一步发展，但是随着用户逐渐增多，网站又一次面临挑战：数据库压力太大导致访问延迟，进而影响整个网站的性能，用户体验受到影响，这时需要对网站架构进一步优化。

使用缓存改善网站性能

网站访问特点和现实世界的财富分配一样遵循二八定律：80%的业务访问集中在20%的数据上。淘宝买家浏览的商品集中在少部分成交数多、评价良好的商品上；百度搜索关键词集中在少部分热门词汇上；经常登录的用户才会发微博、看微博，而这部分用户也只占总用户数目的一小部分。

既然大部分的业务访问集中在，那么如果把这一小部分数据缓存在内存中，就可以减少数据库的访问压力。网站使用的缓存分为两种：缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。本地缓存的访问速度更快一些，但是受应用服务器内存限制，其缓存数量有限，而且会出现和应用程序争用内存的情况。远程分布式可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论上做到不受内存容量限制的缓存服务。

使用缓存后，数据访问压力得到有效缓解，但是单一应用服务器能够处理的请求连接有限，在网站的访问高峰期，应用服务器会成为整个网站的瓶颈。

使用应用服务器集群改善网站的并发处理能力

使用集群是网站解决高并发，海量问题的常用手段，当一台服务器的处理能力、储存空间不足时，不要企图去换更强大的服务器，对大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求，这种情况下，更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。

对网站而言，只要能通过一台服务器的方式改善负载压力，就可以以同样的方式持续增加服务器不断改善系统性能，从而实现系统的可伸缩性，应用服务器实现集群是网站可伸缩集群架构设计中较为简单成熟的一种。如下图所示。

通过负载均衡调度服务器，可将来自用户浏览器的请求分发到应用服务器集群中的任何一台服务器上，如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不在成为网站的瓶颈。

数据库读写分离

网站使用缓存后，大部分数据操作访问都可以不通过数据库就能完成，但是仍有一部分读操作，(缓存访问不命中、缓存过期)和全部的写操作，需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。

目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能，实现数据库读写分离，从而改善数据库负载压力。

应用服务器在写数据的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库或得数据。为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离时对应用透明。

使用反向代理和CDN加速网站响应

CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，是用户在请求网站服务时，可以从距离自己最近的网路提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接给用户。

使用分布式文件系统和分布式数据库系统

分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用，不到万不得以时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上。

使用NOSQL和搜索引擎

对于海量数据的查询，我们使用nosql数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NOSQL有mongodb和redis，搜索引擎有lucene。

业务拆分

随着业务进一步扩展，应用程序变得非常臃肿，这时我们需要将应用程序进行业务拆分，如百度分为新闻、网页、等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者同享数据库来实现

分布式服务

这时我们发现各个业务应用都会使用到一些基本的业务服务，例如用户服务、订单服务、支付服务、安全服务，这些服务是支撑各业务应用的基本要素。我们将这些服务抽取出来利用分部式服务框架搭建分布式服务。淘宝的Dubbo是一个不错的选择

Janus 是由Meetecho设计和开发的开源、通用的基于SFU架构的WebRTC流媒体服务器，它支持在Linux的服务器或MacOS上的机器进行编译和安装。由于Janus 是使用C语言进行编写的，因此它的性能十分优秀。Janus 的整体架构图如下图所示。

Janus 主要由三个部分组成，分别是Core、Plugin和Transport，下面是相关模块的介绍：

从整体架构上看，Janus支持众多传输协议，并且采用业务插件架构设计模式。因此，Janus流媒体服务器十分适合多种业务模型或业务经常变化的公司或项目使用。