高并发平台架构规划设计方案设计.docx

高并发平台架构规划设计方案设计.docx

《高并发平台架构规划设计方案设计.docx》由会员分享，可在线阅读，更多相关《高并发平台架构规划设计方案设计.docx（16页珍藏版）》请在冰豆网上搜索。

高并发平台架构规划设计方案设计

编号∶______

版本∶______

高并发平台架构规划方案

V1.0

起草人：

田朝山

起草时间：

2013年01月08日

审核人：

审核时间：

修改情况记录：

序号

修改模块名称

修改容

修改人

修改人名称

1

2

3

1概述

1.1简述

本文档针对okgohome工程的特点，根据工程各个阶段的开展情况，在系统不调整或微调整的情况下逐步提升整体吞吐量以适应工程的快速开展。

其中包括各个阶段工程架构部署规划。

1.2设计目标

A.快速的响应能力

在各种情况下，能够快速响应用户请求；具备可靠地容灾能力，局部系统问题不影响整体系统的正常运行。

将停顿效劳时间降低到最低甚至是不连续效劳。

B.可伸缩性的系统体系

随着访问的增加，系统具备良好的伸缩能力。

其中包括硬件与软件两局部：

1）硬件：

Web效劳器集群，缓存效劳器集群，文件效劳器集群，数据库效劳器等集群。

各个群集之间负载均衡，任何一个集群由于资源缺乏出现瓶颈的时候，只要根据需要添加一个效劳器节点，做简单的配置就能到达扩展的目的。

2）软件：

整个软件应用系统纵向分割，按照模块划分，各个模块即相互独立，又可以无缝结合。

如果需要扩展一个模块，只要做独立开发，无需该原有系统的代码，只要做简单的配置就能结合在已经，并对该模块管理。

C.平安可靠的系统

为保证的正常运行，用户数据的高度平安，系统考虑了多种平安策略〔网络平安、系统平安、各子系统平安、子系统模块平安、回话期间平安等〕。

系统具有7×24小时的运行能力，并且具有系统灾难的快速恢复能力，及数据平安的保证。

D.易管理的体系架构

整个系统、效劳的状态处于一个实时的监控之下。

其中包括：

配置管理、故障性能检测、代码发布等：

1）配置管理：

可以通过统一的管理系统，对整个运行环境进展界面配置管理。

同类集群可以批量操作。

2）性能监测：

通过统一的监控系统对不同类型的效劳器或集群分别监测，根据监测报表实时决策优化方案。

3）代码发布:

如果扩展模块开发完，只要通过发布系统发布到指定的效劳器，或某一类效劳器。

1.3设计原那么

1）高可用性：

将停顿效劳时间降低到最低甚至是不连续效劳；

2）可扩展性：

随着访问的增加，系统具备良好的伸缩能力；

3）可视性：

系统、效劳的状态处于一个实时的监控之下；

4）高性能高可靠性：

经过优化的体系构造及合理的备份策略；

5）平安性：

构造上的平安及主机的平安策略；

6）易维护性：

通过简单的操作就能维护庞大的集群系统;

7）低本钱：

前期尽量在有限的硬件资源下，利用软件提高性能。

1.4读者对象

该文档的主要读者对象：

工程经理、架构师、效劳器维护人员等。

2工程分析

工程特点如下：

1）高并发，初期虽然PV比拟低，但随着快速开展pv增长很快；

2）数据实时性要求高；

3）数据正确性要求高；

4）大多数页面属于动态页面；

5）需要大量商品图片展示；

6）用户通过搜索引擎、广告、类目导航寻找商品；

7）读多写少，比例超过10:

1

8）卖家相关数据量比拟大，比方商品数、评价数。

3架构遵循规那么

1）能分拆的独立应用，尽量分割开来；

2）独立应用有程序与数据库组成；

3）程序有静态文件或动态文件组成；

4）数据库有主数据库〔专门用于写〕与从数据库〔专门用于读〕组成，其中主数据库中的数据会实时同步到从数据库；

5）频繁调用的动态数据能参加缓存；

6）数据库大到影响检索效率是，必须横向分割。

如:

用户表已经相当大，ID能整除2的放在userinfo2，ID能整除3的放在userinfo3，ID能整除4的放在userinfo4，ID能整除5的放在userinfo5等，把一大表分成4小表。

7）数据库、文件、缓存等效劳器能负载均衡；

8）要求不及时，能批处理的尽量独立批量处理。

4系统架构

工程初期由于压力较小，应用效劳、数据库、备份分别部署在独立的效劳器上，甚至都部署在同一台效劳器上。

但整个系统前期的开发需要按照以下负载方式考虑设计分布式部署，方便随着工程负荷增大，评估出负荷点，能很容易在不改变程序的根底上，添加硬件设备就能缓解整体负荷。

由于前期节点比拟少，“4.7效劳器性能检测系统〞、“4.8效劳器管理系统〞、“4.8代码分发系统〞等暂时不考虑，具体开发时间根据工程开展情况而定。

4.1子系统构造

注：

其中前台的每个分站旗下的App与分站一样，这里进用分站做个举例说明。

4.2App应用系统

包含web页面的各App应用，页面类型分为：

静态页面，动态页面。

静态页面对I/O要求比拟高；动态页面对存、CPU等要求比拟高。

因此静态页面与动态页面分开部署在具有针对性的效劳器上以提高性能。

Web效劳器分：

静态Web效劳器，动态Web效劳器。

其中当客户访问静态页面的时候，仅访问静态web效劳器，静态Web效劳器根据需要从文件效劳器上提取所必须的css，js，图片等文件；而当用户访问动态页面时，动态Web效劳器根据需要先去缓存效劳器上检查是否有需要的数据，如果有，那么直接从缓存效劳器中取，否那么从数据库中取相应的数据，同时添加到缓存效劳器上〔不是所有的数据都加到缓存效劳器中，主要加那些不频繁变化的数据〕，根据需要从文件效劳器上提取所必须的css，js，图片等文件。

如图2-1-1所示。

图2-1-1App应用系统〔分两局部：

动态，静态〕

静态网页的网址形式通常是以.htm、.html、.shtml、.xml等为后缀的。

同时在静态页面上也可以出现各种动态的效果，如.GIF格式的动画、FLASH、滚动字母等，这些“动态效果〞只是视觉上的。

静态页面的优点：

1）完全脱离了数据库访问的压力，直接访问速度快，用户体验良好，而且不容易屏蔽；

2）容非常稳定，容易被搜索引擎收录，并且容易获得较好排名；搜索引擎也会经常光临；

3）提高平安性，防止不良代码注入；

4）对效劳器要求不高。

因此对于不频繁变化的容尽量静态化，同时针对静态页面定制相应的效劳器，这样不但能提高的访问速度，同时能节省效劳器资源。

动态网页的网址形式通常是以.jsp、.php、.aspx、.asax、.shtml、.ascx等为后后缀的。

动态页面主要用于人机交互〔如：

论坛，评论等〕，实时效率比拟高。

动态页面不但效劳器要求比拟高，同时需要频繁与数据库交互，给数据库效劳器带来很大的压力。

因此只有中频繁变化的局部，以及管理系统需要做成动态页面

随着访问量的不断增加，即使静态页面与动态页面分开，分别部署在不同的效劳器上，也难于承受那么大的流量。

如果一台效劳器难于负荷静态效劳的时候，那么根据需要添加多台效劳器一起承载静态效劳负荷。

为了让多台效劳器更好的协同工作，且随着集群负荷的增加，可以根据需要添加效劳器以到达分担负荷的作用，那么利用网络负载平衡器把这些效劳器群集起来。

动态效劳业可以按照这样的均衡方式到达提高性能与扩展的效果。

如图2-1-2所示。

图2-1-2App应用系统负载均衡

其中Windows2003网络负载均衡原理：

是按照通讯量来分配的。

可以配置成各个主机均分；也可以给好点的机器多分点负荷量，给差点的机器分少点负荷量〔负荷量：

各主机处理的通信量/总的通讯量〕。

也可以指定各个主机的优先级，按照优先级确定那个主机处理接收到的通讯。

而整个群集对外表现为一个IP，一个域名只要绑定到该IP上，那么通过该域名的请求都会分发到群集中的各个效劳器上一起工作。

当规模越来越大的情况下，即使用群集能解决性能问题，但所有的效劳都部署在一个群集中，一个群集就有成百上千个站点很难管理。

因此在到一定规模的时候，就需要按照模块应用的不同进展纵向分割。

然后根据各个应用的访问量实际情况作负载均衡以提升整体的性能。

静态效劳，动态效劳都可以按照这样的方式部署。

其中动态效劳纵向分割不仅方便了站点管理，更深远的意义在于为数据库负载提供了方便。

因此动态效劳器更应该尽量按照应用的不同纵向分割。

如图2-1-3所示。

图2-1-3App应用负载均衡〔动态应用纵向分割〕

4.3数据库系统

大型的性能瓶颈主要来自于动态效劳，而影响动态效劳性能关键在于数据库能否及时响应。

各个动态应用规模越大，响应的数据库就越臃肿，响应的速度就越慢。

所以动态效劳局部响应的数据库的纵向分割不但便于管理，还能提升数据库的性能，能到达数据库负载均衡的效果。

由于局部数据库在没有借助第三方软件或硬件情况下，自身不能负载均衡。

就当前形势还没必要用到第三方负载均衡工具的情况下，采用如下方案:

1）读写别离。

由于读多写少，大局部时间消耗在查询上，因此让主库专门用于写，从库专门用于读〔读库可以有很多个，以减轻单个读库的负担〕，同时同步写库与读库的数据；如图2-2-1所示。

图2-2-1数据库主从别离

2）纵向分割就是，不同的应用可以分到不同的DB中，不同的实例中。

这种发放不但效率高，实施也很方便。

如图2-2-2所示。

图2-2-2数据库分布式部署

3）横向分割就是，某些应用不能分割，比方用户注册，但是用户表会非常大，可以把大表分成小表，可以采用表分区，数据存储在不同文件上，然后再部署到独立物理效劳器增加IO吞吐以改善读写性能，表分区的另外一个优势可以增加数据查询速度。

4）根据需要可以综合使用以上三种方法，可以实现无限极的扩展。

如图2-2-3所示。

图2-2-3数据库负载均衡〔综合用法〕

如果某个应用的访问量通过上面的方式综合使用都无法负载时候，再采用第三方的负载均衡。

4.4缓存系统

大型的吞吐率越大，尤其是动态效劳局部，使数据库的压力也越来越大。

如果数据库压力过大，严重影响的整体性能。

使用缓存能有效应对大负载，减少数据库的压力，并显著提高多层应用程序的性能。

采用业主流的Memcache。

Memcached是开源的分布式cache系统。

Memcached的缓存是一种分布式的，可以让不同主机上的多个用户同时访问，因此解决了共享存只能单机应用的局限，更不会出现使用数据库做类似事情的时候，磁盘开销和阻塞的发生。

主要应用App应用系统与数据库系统之间。

根据各个应用的实际情况配置多台缓存效劳器。

如图2-3-2所示。

图2-3-1Memcache缓存部署图

4.5文件存储系统

有些容，既没必要存放在数据库里，也不适合存放在缓存中，如图片，下载文件，js，css等数据。

当有海量容存放在文件系统中时，为了保证高并发请求下文件系统能够及时的相应请求，通过以下方式来提高文件系统的整体性能：

1）按照文件类型的不同，分别部署在不同的效劳器，甚至效劳器集群上。

如图片文件可以不是在图片效劳器上，当单台图片效劳器承受不了当前的负荷的时候，可以更具时间情况添加多台图片效劳器通过NBL群集起来协同工作。

2）当多台效劳器通过负载平衡都难于承受某类文件负荷的时候，可以按照该类文件所属的App应用纵向划分。

如“web应用1〞的图片文件单独部署在单台效劳器上，甚至是多台效劳器集群上。

3）为了将来易于扩展、移植，综合使用以上两种方法。

先把各种文件按照App应用划分，再把文件按照类型划分。

即使所有的文件部署到一台机器上，只要各个web应用中的各种类型的文件通过独立的域名调用，当以后某种App应用的的负荷很大时，或某种App应用中的某种类型文件负荷很大时，也可以轻松移植到新添加的效劳器上，只需要把相应域名解析到相应的效劳器IP上即可。

如图2-4-1所示。

图2-4-1文件分布式不是

4.6效劳器性能监控系统

在规模不大，效劳器只有假设干台的情况下，运维人员可以逐台效劳器通过Windows任务管理器查看效劳器资源使用情况，而这样只能看到CPU、存以及硬盘等的使用情况，其他的〔如：

IIS的吞吐率，当前的请求数等〕都难于获取，只能等