高并发平台架构规划方案专项方案设计.doc

编号∶______
版本∶______
高并发平台架构规划方案

V1.0

起草人： 田朝山
起草时间：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.2 App应用系统
包括web页面各App应用，页面类型分为：静态页面，动态页面。静态页面对I/O规定比较高；动态页面对内存、CPU等规定比较高。因而静态页面与动态页面分开布置在具备针对性服务器上以提高性能。
Web服务器分：静态Web服务器，动态Web服务器。其中当客户访问静态页面时候，仅访问静态web服务器，静态Web服务器依照需要从文献服务器上提取所必要css，js，图片等文献；而当顾客访问动态页面时，动态Web服务器依照需要先去缓存服务器上检查与否有需要数据，如果有，则直接从缓存服务器中取，否则从数据库中取相应数据，同步添加到缓存服务器上（不是所有数据都加到缓存服务器中，重要加那些不频繁变化数据），依照需要从文献服务器上提取所必要css，js，图片等文献。如图2-1-1所示。
图2-1-1 App应用系统（分两某些：动态，静态）
静态网页网址形式普通是以.htm、.html、.shtml、.xml等为后缀。同步在静态页面上也可以浮现各种动态效果，如.GIF格式动画、FLASH、滚动字母等，这些“动态效果”只是视觉上。静态页面长处：
1) 完全脱离了数据库访问压力，直接访问速度快，顾客体验良好，并且不容易屏蔽；
2) 内容非常稳定，容易被搜索引擎收录，并且容易获得较好排名；搜索引擎也会经常光顾网站；
3) 提高网站安全性，防止不良代码注入；
4) 对服务器规定不高。
因而对于不频繁变化内容尽量静态化，同步针对静态页面定制相应服务器，这样不但能提高网站访问速度，同步能节约服务器资源。
动态网页网址形式普通是以.jsp、.php、.aspx、.asax、.shtml、.ascx等为后后缀。动态页面重要用于人机交互（如：论坛，评论等），实时效率比较高。动态页面不但服务器规定比较高，同步需要频繁与数据库交互，给数据库服务器带来很大压力。 因而只有网站中频繁变化某些，以及管理系统需要做成动态页面
随着访问量不断增长，虽然静态页面与动态页面分开，分别布置在不同服务器上，也难于承受那么大流量。
如果一台服务器难于负荷静态服务时候，则依照需要添加多台服务器一起承载静态服务负荷。为了让多台服务器更好协同工作，且随着集群负荷增长，可以依照需要添加服务器以达到分肩负荷作用，则运用网络负载平衡器把这些服务器群集起来。动态服务业可以按照这样均衡方式达到提高性能与扩展效果。如图2-1-2所示。
图2-1-2 App应用系统负载均衡
其中Windows 网络负载均衡原理：是按照通讯量来分派。可以配备成各个主机均分；也可以给好点机器多分点负荷量，给差点机器分少点负荷量（负荷量：各主机解决通信量/总通讯量）。也可以指定各个主机优先级，按照优先级拟定那个主机解决接受到通讯。而整个群集对外体现为一种IP，一种域名只要绑定到该IP上，则通过该域名祈求都会分发到群集中各个服务器上一起工作。
当网站规模越来越大状况下，虽然用群集能解决性能问题，但所有服务都布置在一种群集中，一种群集就有成百上千个站点很难管理。因而在网站到一定规模时候，就需要按照网站模块应用不同进行纵向分割。然后依照各个应用访问量实际状况作负载均衡以提高整体性能。静态服务，动态服务都可以按照这样方式布置。其中动态服务纵向分割不但以便了站点管理，更深远意义在于为数据库负载提供了以便。因而动态服务器更应当尽量按照应用不同纵向分割。如图2-1-3所示。
图2-1-3 App应用负载均衡（动态应用纵向分割）
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-1 Memcache缓存布置图
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 数据库存储阐明
编号
数据库
数据

备注
1
核心
业务
核心业务总DB
1、所有商品及商品有关信息
2、所有订单信息
3、结算信息
4、店铺信息
5、机构信息
6、供应商信息
其中商品涉及如下：
1、总供应商商品
2、省供应商商品
3、店铺自销商品
4、3S商品
商品DB
所有商品及商品有关信息
商品读写都来自于该库，但每一种更新都会同步到核心业务总DB
订单DB
所有订单以及与订单有关信息
订单读写都来自于该库，但每一种更新都会同步到核心业务总DB
结算DB
所有结算需要信息以及结算成果
结算读写都来自于该库，但每一种更新都会同步到核心业务总DB
2
会员DB
所有会员身份及验证信息
独立但支持单点登录
3
评论DB
所有商品评论信息
独立于核心系统
4
晒单DB
所有会员发布晒单信息
独立于核心系统
5
流量记录DB
对网站各个页面访问跟踪记录以及记录信息
独立于核心系统
6
广告DB
网站上所有广告位与广告信息
独立于核心系统
7
A市分站DB
A市下辖店铺上架正常显示商品信息
数据从总核心业务DB推送过来商品信息
8
B市分站DB
B市下辖店铺上架正常显示商品信息
数据从总核心业务DB推送过来商品信息
9
......
......
......
10
N市分站DB
C市下辖店铺上架正常显示商品信息
数据从总核心业务DB推送过来商品信息