高并发平台架构规划方案设计说明Word文件下载.docx
《高并发平台架构规划方案设计说明Word文件下载.docx》由会员分享，可在线阅读，更多相关《高并发平台架构规划方案设计说明Word文件下载.docx（18页珍藏版）》请在冰点文库上搜索。
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:
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的吞吐率，当前的请求数等）都难于获取，只能等错误发生了才能知道采取排查，是运维人员很被动。
但随着规模的不断扩大，整个所基于的服务器集群也在不断扩大。
当服务器扩展到成百上千台的时候，手工去逐台采集已经很不现实。
因此必须通过专门的系统针对性的自动对各个服务器的信息采集，绘制成报表供运维实时掌握各个服务的现状。
监控系统的部署如图2-6-1所示。
图2-6-1服务器性能监控系统
4.7服务器管理系统
同“服务器性能监控系统”类似。
在规模不大，服务器只有若干台的情况下，运维人员可以逐台服务器手工配置，而且很难避免手误。
但随着访问流量的不断增加，网络服务都是以负载均衡集群的方式对外提供服务，随之集群规模的扩大，原来基于单机的服务器管理模式已经不能够满足需求，新的需求必须能够集中式的、分组的、批量的、自动化的对服务器进行管理，能够批量化的执行计划任务。
分布式服务器管理系统的部署如图2-7-1所示。
4.8代码分发系统
随着访问流量的不断增加，网络服务都是以负载均衡集群的方式对外提供服务，随之集群规模的扩大，为了满足集群环境下程序代码的批量分发和更新，我们还需要一个程序代码发布系统，其中文件同步现在用Filesync，也可以用Rsync。
代码发布系统部署如图2-8-1所示。
代码发布系统的作用：
1）生产环境的服务器以虚拟主机方式提供服务，不需要开发人员介入维护和直接操作，提供发布系统可以实现不需要登陆服务器就能把程序分发到目标服务器。
2）我们要实现部开发、部测试、生产环境测试、生产环境发布的4个开发阶段的管理，发布系统可以介入各个阶段的代码发布。
3）我们需要实现源代码管理和版本控制，SVN可以实现该需求。
图2-8-1代码发布系统部署图
5数据库分布式结构图
6数据库存储说明
编号
数据库
数据
备注
核心
业务
核心业务总DB
1、所有商品及商品相关的信息
2、所有订单信息
3、结算信息
4、店铺信息
5、机构信息
6、供应商信息
其中商品包括如下：
1、总供应商商品
2、省供应商商品
3、店铺自销商品
4、3S商品
商品DB
所有商品及商品相关的信息
商品读写都来自于该库，但每一个更新都会同步到核心业务总DB
订单DB
所有的订单以及与订单相关的信息
订单读写都来自于该库，但每一个更新都会同步到核心业务总DB
结算DB
所有结算需要的信息以及结算结果
结算读写都来自于该库，但每一个更新都会同步到核心业务总DB
会员DB
所有的会员身份及验证信息
独立但支持单点登录
评论DB
所有商品的评论信息
独立于核心系统
4
晒单DB
所有会员发布的晒单信息
5
流量统计DB
对各个页面访问跟踪记录以及统计信息
6
广告DB
上的所有广告位与广告信息
7
A市分站DB
A市下辖店铺上架正常显示的商品信息
数据从总的核心业务DB推送过来的商品信息
8
B市分站DB
B市下辖店铺上架正常显示的商品信息
9
......
10
N市分站DB
C市下辖店铺上架正常显示的商品信息
升级会员 