WEB架构思想——瓶颈分析

最近对架构设计系统的学习下，站在一定高度对系统的整体运营是有很好帮助的

A. 硬件法
1. 多个机器并发服务
2. 数据复制多份, 空间换时间
3. 带宽复用和叠加网路设备

B. 软件法
1. 采用高缓存. 将访问量高的信息放在内存中, 直接使用内存输出
2. 精确定位. 减少定位搜索时间, 包括索引等
3. 分历史和新闻信息存储. 历史访问量低, 放在历史库. 新闻访问量高, 放缓存

web网站架构思想

大型的web站点很容易出现瓶颈的问题，都些问题都需要在需求分析阶段（架构设计阶段）或之前就要弄明白的，
至少要知道将来可能存在哪些缺 陷，可能你会说，我现在没那么大的访问量，在线用户很少，还不需要考虑那么
多，有这样的想法是很可怕的，如果访问量上来（突增），就无法应对了， 可能会推翻系统重建，类似中国的
”破窗效应“，对把系统做大做强是不利的，对用户更是不利的。不过这也为扩大内需做贡献了，呵呵；虽然现
在 业务很少，但我们要考虑业务的突增来设计系统，起初考虑成本，可以只满足当前业务配置系统。使架构具有
可扩展性出现瓶颈大概有四个方面：数据库、网络架构、网络带宽、读写。但这四个方面都是应用程序服务，所以前期的应用架构设计很重要，就拿北京的交通来说，一旦北京公路竣工完毕，投入到运营中，交通是否方便，是否拥塞交管部门只能在现有的环境下通过相关的法规或者是一些其他的方法来改善交通的拥塞情况，它只是其辅助作用。

1.数据库

数据库服务器操作系统的选择：一般为linux，unix（aix，hpunix,solaires等）
数据库的选择 ：目前一般为oracle，mysql，db2，sqlserver
硬件的选择：根据自己的业务需求

例如：

数据库服务器操作系统为linux，数据库选择oracle10g ，CPU采用至强3G x 2或x4，内存8G或16G或以上，目前的cpu发展很快，很少成为瓶颈，我们就拿内存来衡量系统的最大并发连接，拿16G的内存来说按照Oracle推荐的，分配给Oracle实例的内存为物理内存的80%。那么对于OLTP应来，pga_aggregate_target(20%的空间用来进行PGA的存储)的值大约就是 2621MB[(16*1024MB×80%)×20%]。这些内存将被分配与PGA区域，并且这个是和并发连接有直接关系的，每个并发的连接都需要一定量的PGA内存以执行SQL语句，假设每个用户session平均需要1M（按照通常的经验值）的空间来计算，那么从并发连接数上来讲，共可以支持近2600左右个并发连接数。

如果一台数据库承载不了当前的业务，就要扩展；我们现在很幸运，因为已经很有多案例我们可以参考，因为这些案例都是经过实践长时间验证的，像拥有亿级用户的myspace社区，可以参考它的按用户横向扩展，用数据库缓存最终才解决myspace的数据库瓶颈问题

2、网络架构
常用网络架构大都在硬件防火墙存在TCP并发连接瓶颈。通常平台使用Web界面访问，访问方式采用TCP短连接方式传输数据，我们使用clearsight对与该平台业务类似的淘宝以及阿里巴巴页面的TCP连接数进行了测试，结果没个页面平均短连接数保持在30个左右。目前主流的高端企业防火墙（电信级防火墙除外）在理想情况下（防火墙不受到外界任何攻击，防火墙不开启任何附加的保护策略，只使用默认的防火墙策略）每秒TCP连接数可达30000并发，如果TCP连接在1秒内建立完成，则一个分布式处理中心大约可以承受30000/30=1000个TCP并发。这一点不是非常满意，这样一来在分布式处理中心还要做些文章。

3、网络带宽

对于网络带宽，假设系统有1000个并发用户数，网络是100Mbps，则有效带宽为12.5MBytes，每页面的平均大小按照 100KB计算，那么不管服务器本身速度多快，最好的响应时间为：2000User*200KB/(12.5MBytes*1024) = 31.25秒，即：如果网络是100Mbps的话，最好的页面访问执行时间也就是31.25秒。这样无论服务器的响应有多快，总是要在网络上传输这么大的数据量。因此，网络将是一个很大的瓶颈。如果网络是125MBytes即约1Gbps，则响应时间是3.125秒，所以并发飙升，带宽费用将是一笔巨大的开支。

4、读写

假设最大的读写在图片服务器，且配置如下：1、CPU：至强3G x 2，或同级别的其他CPU；2、内存：2G或以上；3、硬盘：300G x 2做RAID 0或146G x 4做RAID 1+0。就普通的服务器而言，其使用的SCSI硬盘的理论最大传输速度是320M/S，实际可能只有一半。按照系统需求中一般的页面的响应时间应在5秒内（局域网内为3秒内，互联网上一般应该在5秒内）的要求计算图片总流量为800M（按照实际值计算）。如果按照每个页面上的图片的平均大小为100K来计算，普通配置图片服务器可以承受8000用户的流量。

有了这些数据我们在做系统架构的时候就知道如果规避种种问题，当然在架构阶段尽可能的为升级留有余地。我喜欢在建楼之前画尽可能多的图纸，做尽可能多的实验。不管怎样我们都热爱这份Web大楼的建造，有的三两层，有的几十层甚至上百层。高度说明不了问题，关键在于你的心是否容的下这所建筑！

还有一点，当我们的图片服务器里的图片很多的话，这也会成为瓶颈，有能力的话可以从新改写管理图片的文件系统，因为一般的文件系统是通过目录结构来查找到图片资源的，这是很耗时的，如果通过类似索引的结构查找到图片，那速度将会提高很大

参考文档：

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

http://www.dbanotes.net/arch/imobile_web_arch_ppt.html

http://blog.csdn.net/wangjiafeng2008/archive/2008/12/02/3431718.aspx

http://www.dbanotes.net/arch/heroku_architecture.html