大型网站服务器架构浅析(大型网站系统架构)

扫码添加渲大师小管家，免费领取渲染插件、素材、模型、教程合集大礼包！

随着用户访问量的不断增加。网站的后台也会不断变化以应对需求。本文主要从一个小型网站到大型网站服务器架构的过度与变化来陈述。

1.1 网站后台架构

主要指由web server 。应用服务器。数据库。存储。监控等组成的网站后台系统。

1.2 架构演变

个人站点后台架构。如图2-1所示。

图2-1 单台一组

如图所示。如果是个人站点。访问量不大。一般都是将web server。应用服务器。数据库部署在一台物理服务器上。从图中也可以看到。一个网站最基本的后台需要web server。应用服务器。数据库三部分组成。

1.2.1 网站架构的进一步演变

考虑到网站访问量的不断增加。网站的后台架构也必须不断调整和优化。进一步实现功能分离。www.linuxidc.com特别是随着访问量不断增加以及考虑到数据库的负载和数据的重要性。数据库需要分离出来。从web server到数据库实现各个层次的负载均衡。

1.2.1.1 数据库功能分离。数据库单台部署

考虑到数据库的安全性和处理性能。数据库单台部署。如图2-2-1-1所示。

图2-2-1-1 数据库分离

如图所示。数据库与web server 。应用服务器分离出来。单台部署。这样做有两个好处：

(1)数据库服务器性能提高。不再和webserver 。应用服务器抢占资源。

(2)数据库服务器安全性能提高。不会因为一台服务器宕机而影响所有服务。特别是数据库服务。

1.2.1.2 前端负载均衡部署。用于缓解单台web server压力

随着访问量的不断增加。单台web server 负载会加大。甚至有宕机的危险。所以需要在前端增加负载均衡器。实现web server层的负载均衡。缓解压力。如图2-2-1-2所示。

图2-2-1-2 前端负载均衡

如图所示。通过增加web server并用负载均衡器(load balance)来缓解前端的web server和应用服务器压力。并且。为了保证数据库的绝对安全。做了Master-Slave主从备份。这样当master db宕机之后。slavedb可以立即启用。所以这样做有以下好处：

(1)前台web server 和 应用服务器压力减少。负载均衡器分流负载。

(2)后端数据库安全性加强。出现故障后。业务可以很快切换到slave db 上。

1.2.1.3 增加缓存及数据库读写分离

随着访问量的不断增加。发现整个系统的读写比例很大。对用户而言。读操作多于写操作。而且比例很大。这就需要进一步改善架构。实现读写分离。

通过增加db proxy。实现读写分离。如图所示。2-2-1-3。

图2-2-1-3

考虑到读写比例大的特点。如图2-2-1-3所示。通过增加db proxy。以及master-slaves 。实现读写分离。所有写操作在master db上进行。所有读操作在其他slave dbs 上进行。这样做有以下好处：

(1)缓解单台db的压力。减少单台db的负载

(2)增加多个slave。当master db宕机之后。可以很快切换到slave 上。减少所有db同时宕机的风险。

很多用户访问。读与写操作比例很大。如图2-2-1-3所示。通过在web server层上增加缓存。可以提高访问速度。比如可以缓存css。jpg等静态文件。

增加缓存有两个好处：

(1)加快用户的读请求访问速度。

(2)缓解web server的压力。

1.2.1.4 解决单点故障问题。增加在线备份设备(交换设备和服务器)

虽然上述几个架构图。从各个层面缓解了服务器压力。但是。还是存在当点故障的可能性。如果出现单点故障。没有在线物理设备提供使用。那该系统也不是一个高可用的系统。针对上述问题。增加在线物理备份设备。解决单点故障问题。如图2-2-1-4所示。

图 2-2-1-4

如图2-2-1-4所示。增加了负载均衡器的在线备用设备和db proxy在线备用服务器。这样做可以在负载均衡器出现故障的时候。启用在线备用设备;如果db proxy出现故障。也可以启用在线备用db proxy。实现故障转移。保证系统的高可用性。

1.1 高可用性

“高可用性”(High Availability) 通常用来描述一个系统。经过特殊设计。减少停止服务的时间。从而使其服务保持高度的可使用性。

计算机系统的可靠性用平均无故障时间(MTTF)来度量。即计算机系统平均能够正常运行多长时间。才会发生一次故障。系统的可靠性能越高。平均无故障时间越长。可维护性用平均维修时间(MTTR)来度量。即系统发生故障后维修和重新恢复正常运行平均花费时间。系统的可维护性越好。平均维修时间越短。计算机系统的可用性定义为：MTTF/(MTTF+MTTR)*100%。

举例来说。淘宝网在2010年成交额为300亿。则每分钟成交额为5—10万。那么对淘宝来说。其后台系统的高可用。对企业运营非常重要。淘宝数据负责人宁海元指出。淘宝系统。可用性至少需要99.999%。那么对于taobao.com系统。在一年365天。系统停止服务时间为5分15秒。

1.2 确保高可用性

高可用性的衡量指标

%availability=(TotalElapsed Time – Sum of Inoperative Times) / Total Elapsed Time

其中：

TotalElapsed Time 为系统总时间。包括可提供服务时间+停止服务时间。

Sumof Inoperative Times 为停止服务时间。包括宕机时间+维护时间。

1.2.1 如何确保高可用

可用性越高越好。提高可用性主要从一下几个方面入手：

(1)系统架构

(2)容灾性

(3)监控报警

(4)故障转移

1.2.1.1 系统架构

系统架构。指整个网站后台系统的架构。好的系统架构。主要从下面几个方面考虑：

(1)操作系统的选择。从稳定性。安全性和可维护性考虑。unix和linux性能远远好于windows。从成本考虑。Linux远远低于windows 和unix。

(2)负载均衡器的选择。硬件负载均衡器性能和稳定性高于软件负载均衡器。但成本上。软件比如haproxy。LVS优于硬件(比如F5。Netscaler)。

(3)web server的选择。Nginx优于传统的Apache。

(4)各级缓存的选择与应用。varnish。squid。memcached。

(5)网站开发语言的选择。与开发有关。www.linuxidc.com主要分为需要编译性的语言和不需要编译性的语言。

(6)数据库的选择。传统的关系数据库中。Oracle优于MySQL。但Oracle收费远远高于MySQL。实际上。Oracle有两种收费模式。一种是按用户数。一种是按主机处理器个数。而MySQL有免费的版本。

(7)底层存储设备的选择。比如机械磁盘和固态硬盘的选择。

(8)避免单点故障问题。在逻辑架构上。避免单点故障。避免出现割点。

1.2.1.2 容灾性

容灾性能对系统非常重要。比如服务器因为断电。导致数据文件的不一致。因为发生自然或者非自然灾害比如火灾导致的磁盘损坏。发生数据丢失等。所以容灾很重要。主要从以下几个方面提高容灾性能：

(1)服务器热备机的部署。当发生故障后。热备机能马上使用。提供服务。这里的服务器主要指web server 。应用服务器。数据库服务器等。

(2) 数据备份。比如做定期备份。热备份。增量备份。甚至需要做主从备份。来提高抗灾性能。并且从底层存储设备上进行备份。比如做RAID。

(3) 做双线网络交换。尽量优化设计网络。避免因为核心交换机故障。而影响服务。网络上避免单点故障。

1.2.1.3 监控报警

监控是指对在线服务和非服务的在线服务器和相应的进程进行状态检测。当出现宕机或者某项服务进程僵死之后。能够在尽量短的时间获得该信息。然后通过报警系统将信息发送到一线运维人员。所以。监控报警。直接影响宕机时间。监控报警。主要从以下几个方面展开：

(1)监控主机CPU使用情况。负载情况。

(2)监控主机内存使用情况。

(3)监控主机IO外设。主要以磁盘为主。如磁盘的读写。磁盘使用量等。

(4)监控主机网卡使用情况。网卡是否损坏。是否招到DDOS攻击。

(5)监控应用进程。包括web server 。应用服务器等。

(6)监控数据库使用情况。包括用户的请求数。缓存使用量等。

(7)监控交换设备的使用情况。网络入。出的流量。

(8)监控IDC机房温度。湿度等。

(9)防火墙。入侵检测等安全检测。监控等。

通过上面的各项监控。得到相应数值。应用监控绘图软件。把相应的数值绘画出来。现有监控绘图软件有mrtg。cacti。nagios等。然后设置一个报警阈值。如果超过该阈值。那么通过报警系统。www.linuxidc.com比如短信。msn。邮件。甚至是声音完成报警功能。典型的报警系统如图3-2-1-3所示。

图3-2-1-3

如图3-2-1-3所示。监控服务器从servers上收集系统信息。如果发现系统的某项状态指数超过预设的阈值。则发送邮件到运维人员。同时。把相应的报警信息发送到短信运营商的短信网关服务器。然后短信网关服务器发送短信到运维人员手机中。完成短信报警。上述报警过程。传送邮件报警信息。是基于TCP/IP协议。而传送短信报警信息。是基于gprs网络。

1.2.1.4 故障转移

故障转移是指。当对用户提供服务的服务器或者相应的应用进程发生故障后。比如服务器宕机。进程僵死之后。备用服务器能够在尽量短的时间内启用。提供服务。这样能够最大限度减少损失。保证用户的正常服务。所以。做好故障转移。要解决以下两个问题：

(1)实时监测故障问题。

(2)准确快速切换服务器问题。

针对不同层次的服务。监测机制也不同。详细情况。在3.2.1.3已经阐述。下面主要论述一下故障切换问题。

故障切换包括负载均衡器的故障切换。主机os的故障切换。web server的故障切换。应用进程的故障切换。数据库的故障切换。存储系统的故障切换。DNS的故障切换。交换设备的故障切换等。下面主要分析进程僵死的故障转移和服务器宕机的故障转移。

进程僵死故障转移案例。常见的web server僵死故障转移如图3-2-1-4所示。

图3-2-1-4-1

如图3-2-1-4-1所示。当主机172.29.141.112的web server 对外提供服务时。通过在主机172.29.141.113上部署监控程序Monitor_nginx.sh来监控主机172.29.141.112上面的web server进程运行情况。一旦发现172.29.141.112上web server停止服务。马上报警。先更改172.29.141.113的ip地址为172.29.141.112。再启用其自身的web server,完成故障转移。此外。也可以在两服务器上同时部署监控程序Monitor_nginx.sh。完成互相监控。

服务器宕机故障转移案例。常见的服务器宕机故障转移。如图3-2-1-4-2所示。

图3-2-1-4-2

如图3-2-1-4-2所示。服务器A和服务器B同时部署。但服务器A提供服务。而服务器B作为热备机。监控系统单独部署。当服务器A宕机之后。监控系统会检测到这一信息。然后通过浮动更改服务器B的ip地址。完成故障切换。

1.3 本文小结

本文主要阐述了网站后台系统的高可用性。分析了高可用性的定义和应用需求。重点阐述了如何做到高可用。通过从不同应用级别。如主机。存储。网络。外设。数据库。安全等各个级别进行分析。最后详细论述了web server的故障转移和主机系统的故障转移。

整理大型网站架构必知必会的几个服务器知识

最近看书及系统开发部署过程中的一些心得。再对照自己之前的从业经验。很多都是听闻而已。当然也有一些已经很熟悉。有的正在搞。有的未来希望可以着手付诸实施。留此存照。

1。负载均衡服务器

负载均衡服务器主要作用是实现某些类型服务器的规模扩展。比如对于系统前端的web服务器和后端的数据库服务器。想通过加服务器实现N+1横向扩展。通过多台服务器负载分担压力。负载均衡必不可少。

2。web服务器

最常见。内存要求不是很高但cpu要求较高。主要用于部署各种web应用。如带界面的web页面。不带界面的web服务。wcf等等。

3。缓存服务器

大中型网站。分布式缓存已是标配。缓存服务器专门用于部署分布式缓存。一般而言对内存和带宽要求较高。

4。消息队列服务器

队列是系统解耦利器。也是大中型分布式系统标配。没有队列。业务系统很容易高度耦合。系统吞吐量也会很快遭遇瓶颈。

5。文件服务器

分布式文件系统。专门用于存储业务系统需要的各种文件如图片。多媒体文件等。

6。索引服务器

用于网站全文索引。搜索必备。对内存和CPU要求较高。大型网站。通常还需要支持主从备份和容错。甚至多实例索引集群。

7。搜索服务器

通常需要部署多台。否则查询多了性能撑不住。对内存要求不高。有的中小型站点。索引和搜索服务器在物理和逻辑上都是同一台服务器。

8。作业服务器

主要用于后端应用程序大批量大数据量复杂业务逻辑的定时作业。大多数互联网公司标配。某些企业的定时调度框架是直接部署在web服务器上的。可以减少这里的所谓作业服务器。

9。数据库服务器

主要用于存储和查询数据。数据库已是各种系统实际上的标配。内存和CPU都要求极高。网络和硬件要求也不低。大中型网站还需要支持数据库的主从备份和容错。甚至多实例的数据库集群。

通常。大中型的互联网应用会经历一个从单一的数据库服务器,到Master/Slave主从服务器,再到垂直分区(分库)。然后再到水平分区(分表。sharding)的过程。而在这个过程中。Master/Slave以及分库相对比较容易。对应用的影响也不是很大。但是分表会引起一些棘手的问题。比如不能跨越多个分区join查询数据。如何实现DB负载等等。这个时候就需要一个通用的DAL框架来屏蔽底层数据存储对业务逻辑的影响。使得底层数据的访问对应用完全透明化。

10。nosql服务器

海量数据处理的兴起。各种nosql产品层出不穷。nosql服务器主要用于处理海量数据。支持存储。查询。分片等。

web应用中。有两个一直是不好实现横向扩展或者由于历史遗留问题实现代价非常大的东西。如你所知。就是：A。数据库 B。网络带宽。

而某些nosql的出现很可能解决这个历史遗留难题。现在已经有nosql产品弥补了关系型数据库天生不支持横向扩展的缺点。在特定场景下正在替代关系型数据库。

11。其他

需求不断变化和应用需要。某些互联网企业还可能衍生出基于安全的授权/证书服务器。全局唯一的流水号服务器。会话服务器等等。

参考：

<<大型网站技术架构>>

<<构建高性能web站点>>

http://www.cnblogs.com/terryli/archive/2008/04/06/1139121.html

http://www.cnblogs.com/ejiyuan/archive/2010/10/29/1796292.html

http://kb.cnblogs.com/page/99549/

http://highscalability.com/blog/2014/7/21/stackoverflow-update-560m-pageviews-a-month-25-servers-and-i.html

http://www.infoq.com/articles/perera-data-storage-haystack

http://lethain.com/introduction-to-architecting-systems-for-scale/

原文地址:https://blog.csdn.net/u010098331/article/details/52243121