电子商务网站的架构实现Word格式.docx

电子商务网站的架构实现Word格式.docx

《电子商务网站的架构实现Word格式.docx》由会员分享，可在线阅读，更多相关《电子商务网站的架构实现Word格式.docx（19页珍藏版）》请在冰豆网上搜索。

在双重作用下，负载均衡器的压力急剧上升。

对于任何一台负载均衡器来说：

支撑相同的请求量，七层交换所消耗的CPU要远远高于四层交换。

特别是在瞬间高并发连接的突发流量面前，负载均衡器面临着严峻的挑战。

挑战二：

微博等互联网新兴产品的出现，对负载均衡器的运维工作提出了更高的要求。

微博不仅改变着亿万网民的生活，而且也正悄然推动着运维体系的建设。

首先，与传统的新闻、博客相比，微博用户对服务质量的敏感度更高，而且这种敏感度会伴随着一次次的“@”和“转发”传播扩散。

在过去，当用户访问新浪服务感到慢时，反映的渠道多是打客户电话。

而现在只需要在微博上一个简单的“@” 

就可以与新浪的客服和技术人员直接沟通。

作为流量进出的一个关卡，当微博等线上关键业务出现访问异常或故障时，工程师们都迫切地想知道：

是负载均衡器的问题吗？

此时故障诊断的效率显得至关重要。

在实际工作中我们发现：

单纯依靠负载均衡器提供的CPU、内存、连接数等统计信息，还不足以发现一些隐蔽问题。

传统的抓包分析耗时耗力且效果不佳，再加上有些故障现象与客户端、后台服务器上的某些特殊设置有着千丝万缕的联系，所有这些交织在一起，给我们故障诊断带来了不小的挑战。

例如有次我们发现：

负载均衡器偶尔会给客户端返回HTTP 

5xx的响应，当时特想快速地知道究竟是什么样的HTTP请求会触发这样的现象。

但可惜的是，负载均衡器上仅有统计数字而没有请求的完整记录。

在花了很大力气抓包分析后，最终定位到是由于后台一个PHP程序不小心给页面设置了一个错误的HTTP 

Header，导致Web 

Server的HTTP响应不能被负载均衡器所接受，最终给客户端返回5xx。

因此在故障诊断方面，我们需要有更先进的理念和手段。

其次，微博在国内正处于快速成长期，会随时根据访问量来灵活调整服务器的数量和系统架构。

在这种快速灵活的变化面前，负载均衡器相关的配置调整工作也随之增加：

频繁的上下线服务器、变更七层规则等。

面对这种情况，我们需要思考：

如何能更加快速安全地完成好这些变更、如何能避免工程师每天被动地陷入这些重复烦琐的工作中等。

目前一些硬件设备提供了API接口，像增删Server、调整Server 

权重等这类风险性极低的操作可通过API接口操作，以达到提高效率的目的。

而Haproxy、LVS则缺乏这样的 

API接口，需要单独开发。

除此之外，关键应用对负载均衡器的监控也有越来越多的新需求。

比如：

有些应用希望当负载均衡器检测到服务器池中活跃的服务器数量少于一定比例后，便提前给系统管理员作出预警；

及时发现服务器池中权重等设置不合理的问题等。

挑战三：

多核处理器时代下，Haproxy等用户态的软件负载均衡正面临新的性能瓶颈。

近几年来CPU发展进入了多核时代，CPU由过去的单核发展到四核、六核、八核、十二核，甚至更多，而主频则变化不大。

在这种趋势下，充分利用多核特性显得尤为重要。

但在我们研究中发现，像Haproxy这类基于用户态的软件负载均衡，其对CPU主频的依赖度要远远高于CPU核数。

换言之，在高主频、核数少CPU下的性能很有可能要优于低主频、核数多的CPU。

这一点，在Haproxy服务器选型时尤为重要。

据我们分析，这主要是由于操作系统对多核（多CPU）下的并发支持度还不够好。

挑战四：

软件负载均衡发展路上的“鸡蛋-篮子”理论的艰难选择。

硬件负载均衡器往往以单台高性能著称，而Haproxy、LVS为代表的软件负载均衡的优势则在于成本低廉、可灵活定制，其性能与服务器CPU、网卡等硬件直接相关（当然特殊的优化也很重要）。

正如前面提到的，当七层交换流量越来越大时，我们究竟是该投入成本让单台LVS、Haproxy足以支撑如此大的流量，还是让更多中等性能的服务器共同分担这些流量呢？

这就是所谓的经典的“鸡蛋－篮子”理论：

究竟该不该将鸡蛋放到一个篮子里呢？

其实不同的选择各有利弊。

2~3年前，我比较赞同将流量分摊到多台软件负载均衡器上，当时主要考虑到风险的分散。

而现在，我更倾向于将流量集中于一台上。

之所以这样，是从以下四个角度考虑的。

第一，目前国内IDC内每个机架所放服务器数量跟电力配额直接相关。

而负载均衡由于其特殊性，往往是两台为一组，这样每增加一组都会增加额外的电力开销，特别是在电力资源紧张的IDC内，提高单台软件负载均衡器的承载能力可以为关键业务腾出更多的机架来。

第二，从服务稳定角度考虑，我们通常会将LVS、Haproxy直连核心交换机，如此一来，每增加一组，就意味着会占用更多的核心交换机端口资源。

第三，是基于管理成本的考虑。

LVS、Haproxy之所以能在新浪得到广泛应用，较低的管理成本是重要原因之一。

在新浪我们通过一套集中管理平台和快速初始化的办法实现了运维成本的非线性增加。

但不可否认的是，每新增一组，运维成本或多或少总会增加一些。

之前也曾设计过一套“同机房内负载均衡器的集群池方案”，即：

在一个机房内主备机的数量比不再固定为1:

1， 

虚拟IP（VIP）会根据集群池中每台Haproxy/LVS的负载状况，动态地“漂”在其中某台上。

但后来发现这个“听起来很美”的方案，在实际运行中遇到了种种问题，运维成本不降反升。

最终我们又回归了传统的1台Active+1台Standby的模式，正所谓简单即是美。

第四，目前硬件负载均衡器正朝着“更高的性价比”方向发展，换句话来讲，如果我们不提升软件负载均衡器的单机支撑能力，则终有一天，其与硬件设备相比的成本优势将会淡去。

挑战五：

在新时期下，如何找到负载均衡的最佳软硬结合之道？

朋友、同行聚会时，常有人问我：

“你们有了Haproxy、LVS后，会不会不买硬件设备了？

”、“你最近又在山寨什么？

”每次听到这些，我都会微微一笑。

如前文所述，Haproxy、LVS这类的软件负载均衡和硬件设备各有优势，在我看来，负载均衡的“软”、“硬”解决方案并非水火不容，只要找到最佳的软硬结合之道，鱼和熊掌还是可以兼得的。

下面是我们在长期摸索中，总结出来的一些经验。

软件负载均衡可优先承担四层交换流量，让硬件设备更专注于七层交换：

由于工作方式和原理的不同，专注于四层交换的LVS在稳定性、单机支撑能力、易维护性、管理成本等多方面均要大大优于Haproxy。

特别是在DR模式（即单臂）下， 

单台LVS足以应对绝大多数业务的访问量。

优先保障“明星”产品占用宝贵的硬件设备资源：

这里指的“明星产品”是指那些用户群正处于快速增长，并被广泛追捧的热点互联网产品，例如微博。

考虑到负载均衡器一旦发生异常或宕机后，将对产品的美誉度和用户体验产生一定程度的影响，这属于无形成本的损失。

正所谓“好钢要用在刀刃上”，我们可以优先将这类流量放到硬件负载均衡器上。

对于必须采用七层交换的重点服务来说，尽量避免同一重点服务的流量全部放在软件负载均衡器上。

例如某重点服务分布于四个IDC内，则可考虑两个IDC内使用Haproxy，另外两个IDC使用硬件设备。

这样一方面可以在一定程度上规避使用Haproxy可能带来的风险，另一方面也方便对软、硬件负载均衡器的稳定性、响应时间等进行长期对比观察。

要充分利用好同一IDC内的软、硬件负载均衡器，当一方负载高时，另一方可协助其分担流量，缓解燃眉之急。

总而言之，在负载均衡方面的支出正所谓该花则花、该省则省，合理使用可以让你在保障服务稳定的前提下，获得最佳的投入产出比。

挑战六：

软件负载均衡器的资源复用，在降低成本的同时，同时也面临着一定的运维风险。

目前我们的软件负载均衡器分布于全国各地，其中一些中小规模IDC内的软件负载均衡器的负载并不是特别高，而这些机房普遍又需要VPN、自动安装等服务，单独为这些服务再放1~2组服务器显得很不划算。

因此我们想到对软件负载均衡器进行资源的复用，即：

在软件负载均衡器上同时运行VPN等服务。

在实际中发现，这种资源复用面临两方面的风险：

一是VPN、自动安装、负载均衡可能分属于不同的管理员，这样大家对同台服务器进行操作会增大因配置冲突、操作不当等导致的服务间互相影响的概率；

二是非负载均衡的服务可能会突发占用过多的CPU或网络资源，对正常的负载均衡服务造成了一定的影响。

由于LVS、Haproxy服务的特殊性，像Xen这类通过虚拟化来实现资源隔离的办法又不太适用；

对服务器流量进行QOS设置，虽然可以起到一定的效果，但配置方面还是有些烦琐。

还有更好的办法吗？

这确实值得我们思考。

当然除了以上六方面挑战外，负载均衡领域还有很多值得研究之处。

不同网站有不同的实际情况，希望本文能对大家起到抛砖引玉的作用。

看大型网站如何做负载均衡

负载均衡是一个大型网站发展必须解决的问题，目前公司的网站就面临这样的问题。

在国内，已经有新浪博客、新浪播客、网易新闻、六间房、、Discuz!

、水木社区、豆瓣、YUPOO、海内、迅雷在线等多家网站使用Nginx作为Web服务器或反向代理服务器。

下面两张图介绍了实现的大概思路，分为硬实现和软实现。

方法一、NetScaler负载均衡交换机动静分离系统架构图（硬实现）

方法二、Nginx反向代理负载均衡器动静分离系统架构图（软实现）

了解更多请访问：

网站架构（页面静态化，图片服务器分离,负载均衡）方案全解析

王谦文的转帖┊王谦文的首页

1、HTML静态化

其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。

但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

2、图片服务器分离

大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。

这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。

3、数据库集群和库表散列

大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。

在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。

我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。

sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

4、缓存

缓存一词搞技术的都接触过，很多地方用到缓存。

网站架构和网站开发中的缓存也是非常重要。

这里先讲述最基本的两种缓存。

高级和分布式的缓存在后面讲述。

架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。

网站程序开发方面的缓存，Linux上提供的MemoryCache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。

另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，.net不是很熟悉，相信也肯定有。

5、镜像

镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。

在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。

也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

6、负载均衡

负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。

负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。

7、硬件四层交换

第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。

　第四层交换功能就象是虚IP，指向物理服务器。

它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。

这些业务在物理服务器基础上，需要复杂的载量平衡算法。

在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。

Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。

8、软件四层交换

大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。

但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。

软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是LinuxVirtualServer，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。

这样的架构我准备空了专门详细整理一下和大家探讨。

对于大型网站来说，前面提到的每个方法可能都会被同时使用到，我这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会，有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大，希望大家一起讨论，达到抛砖引玉之效。

用squid做webcacheserver，而apache在squid的后面提供真正的web服务。

当然使用这样的架构必须要保证主页上大部分都是静态页面。

这就需要程序员的配合将页面在反馈给客户端之前将页面全部转换成静态页面。

基本看出sina和sohu对于频道等栏目都用了相同的技术，即squid来监听这些IP的80端口，而真正的webserver来监听另外一个端口。

从用户的感觉上来说不会有任何的区别，而相对于将webserver直接和客户端连在一起的方式，这样的方式明显的节省的带宽和服务器。

用户访问的速度感觉也会更快。

转 

附链接

带宽：

4000M/S（参考）

服务器数量：

60台左右

Web服务器：

Lighttpd,Apache,nginx

应用服务器：

Tomcat

其他：

Python,Java,MogileFS、ImageMagick等

关于Squid与Tomcat

Squid与Tomcat似乎在Web2.0站点的架构中较少看到。

我首先是对Squid有点疑问，对此阿华的解释是”目前暂时还没找到效率比Squid高的缓存系统，原来命中率的确很差，后来在Squid前又装了层Lighttpd,基于url做hash,同一个图片始终会到同一台squid去，所以命中率彻底提高了”

对于应用服务器层的Tomcat，现在Yupoo!

技术人员也在逐渐用其他轻量级的东西替代，而YPWS/YPFS现在已经用Python进行开发了。

名词解释：

·

YPWS–YupooWebServerYPWS是用Python开发的一个小型Web服务器，提供基本的Web服务外，可以增加针对用户、图片、外链网站显示的逻辑判断，可以安装于任何有空闲资源的服务器中，遇到性能瓶颈时方便横向扩展。

YPFS–YupooFileSystem与YPWS类似，YPFS也是基于这个Web服务器上开发的图片上传服务器。

【Updated:

有网友留言质疑Python的效率，Yupoo老大刘平阳在del.icio.us上写到“YPWS用Python自己写的，每台机器每秒可以处理294个请求,现在压力几乎都在10％以下”】

图片处理层

接下来的ImageProcessServer负责处理用户上传的图片。

使用的软件包也是ImageMagick，在上次存储升级的同时，对于锐化的比率也调整过了（我个人感觉，效果的确好了很多）。

”Magickd“是图像处理的一个远程接口服务，可以安装在任何有空闲CPU资源的机器上，类似Memcached的服务方式。

我们知道Flickr的缩略图功能原来是用ImageMagick软件包的，后来被雅虎收购后出于版权原因而不用了（?

）；

EXIF与IPTCFlicke是用Perl抽取的，我是非常建议Yupoo!

针对EXIF做些文章，这也是潜在产生受益的一个重点。

图片存储层

原来Yupoo!

的存储采用了磁盘阵列柜，基于NFS方式的，随着数据量的增大，”Yupoo!

开发部从07年6月份就开始着手研究一套大容量的、能满足Yupoo!

今后发展需要的、安全可靠的存储系统“，看来Yupoo!

系统比较有信心，也是满怀期待的，毕竟这要支撑以TB计算的海量图片的存储和管理。

我们知道，一张图片除了原图外，还有不同尺寸的，这些图片统一存储在MogileFS中。

对于其他部分，常见的Web2.0网站必须软件都能看到，如MySQL、Memcached、Lighttpd等。

Yupoo!

一方面采用不少相对比较成熟的开源软件，一方面也在自行开发定制适合自己的架构组件。

这也是一个Web2.0公司所必需要走的一个途径。

非常感谢一下Yupoo!

阿华对于技术信息的分享，技术是共通的。

下一个能爆料是哪家?

–EOF–

lighttpd+squid这套缓存是放在另外一个机房作为cdn的一个节点使用的，图中没描绘清楚，给大家带来不便了。

squid前端用lighttpd没用nginx，主要是用了这么久，没出啥大问题，所以就没想其他的了。

URLHash的扩展性的确不好，能做的就是不轻易去增减服务器，我们目前是5台服务器做一组hash.

我们现在用Python写的WebServer，在效率方面，我可以给个测试数据，根据目前的访问日志模拟访问测试的结果是1台ypws,平均每秒处理294个请求（加载所有的逻辑判断）。

在可靠性上，还不没具体的数据，目前运行1个多月还没有任何异常。

lvs每个节点上都装nginx，主要是为了反向代理及处理静态内容，不过apache已显得不是那么必需，准备逐渐去掉。

我们处理图片都是即时的，我们目前半数以上的服务器都装了magickd服务，用来分担图片处理请求。

每天数以千万计的Blog内容中，实时的热点是什么?

Tailrank这个Web2.0Startup致力于回答这个问题。

专门爆料网站架构的ToddHoff对KevinBurton进行了采访。

于是我们能了解一下Tailrank架构的一些信息。

每小时索引2400万的Blog与Feed，内容处理能力为160-200Mbps，IO写入大约在10-15MBps。

每个月要处理52T之多的原始数据。

Tailrank所用的爬虫现在已经成为一个独立产品：

spinn3r。

服务器硬件

目前大约15台服务器，CPU是64位的Opteron。

每台主机上挂两个SATA盘，做RAID0。

据我所知，国内很多Web2.0公司也用的是类似的方式，SATA盘容量达，低廉价格，堪称不二之选。

操作系统用的是DebianLinux。

Web服务器用Apache2.0，Squid做反向代理服务器。

数据库

Tailrank用MySQL数据库，联邦数据库形式。

存储引擎用InnoDB，数据量500GB。

KevinBurton也指出了MySQL5在修了一些多核模式下互斥锁的问题（ThisBug?

）。

到数据库的J