架构系列(一)---大型网站架构演化，要素及性能
大型网站架构演化
目录
大型网站特点
- 高并发，大流量
- 高可用，系统不间断服务
- 海量数据，数据量大，需要存储海量数据
- 用户分布广泛，用户分布在五湖四海
- 安全环境恶劣，容易受到受到攻击
- 需求变更块，发布频繁
- 渐进式发张，从小型网站慢慢发展为大型系统
大型网站的技术挑战
- 高并发访问
- 海量的数据
演化发展
- 一台服务器就足够，程序，数据库和文件都在一台服务器上
- 使用三台服务器，不同特性的服务器负责不同的功能。程序，数据库和文件分离，应用程序处理大量业务，需要强大的cpu，数据库需要快速检索和缓存，需要更快的硬盘和更大的内存，文件则要更大的硬盘
- 用户量大以后，数据库访问压力大，所以采用需要采用缓存，由于应用服务器的内存有限，所以采用大内存的缓存服务器
- 用户量增大，一台应用服务器压力大，采用集群的方式来实现负载均衡
- 缓存不命中的时候，数据库的压力增大，配置主从服务器，主数据库用于写数据，然后同步到从数据库，读的时候读取从数据库，实现读写分离，从而改善数据库负载压力
- 采用CDN加速，将数据部署在网络提供商的机房，使用户在请求网站服务的时候，可以从距离自己最近的网络提供商机房获得数据。
- 通过反向代理加速，当请求到达网站中心机房时候，先到达代理服务器，如果缓存命中的话，直接返回给用户，这样的话提高了访问速度，同时也降低了服务器的负载压力
- 一台服务器满足不了业务需求的增长，采用分布式文件系统和分布式数据库系统
- 进行业务拆分，业务日益复杂，将整个业务分成不同的产品线，给不同的业务团队负责
价值观
- 网站的价值在于能给用户提供什么价值，而不是他是怎么做的
- 大型网站都是从小型网站一步步发展起来的，小型网站的时候，不要盲目去追求架构，而是首要去为业务创造价值
- 是业务对架构提出要求，是业务促进技术的发展，是业务成就技术，所以，要对业务怀有感恩之心
网站架构设计误区
- 不要盲从别人的经验，坚持自我
- 不要为了技术而技术，技术是为业务服务的，关键是实现价值，不要以为最求时尚的技术
- 技术可以解决业务问题，但也可以通过业务的手段去解决
总结
- 随着用户的量的增加，业务的增多，数据量的增大，单机服务器满足不了需求，所以，架构慢慢进行演化
- 不要盲目最求新技术，关键是实现价值。是业务的需求促进技术的发展，对业务要有感恩之心。
大型网站架构要素
性能
提高手段
- 浏览器缓存，页面压缩，减少cookie传输
- cdn加速
- 反向代理
- 服务器本地缓存或者分布式缓存
- 异步操作将用户请求发送至消息队列等待后续任务处理
- 数据库添加索引，优化sql，缓存
可用性
衡量标准
- 扣除故障的时间，网站的总可用时间
提高手段
- 应用部署到多台服务器上同时提供访问，多台应用服务器通过负载均衡设备组成一个集群对外提供服务，任何一台服务器宕机，将请求切换到其他服务器
- 对于存储存储数据库，对数据进行实时备份
伸缩性
衡量标准
- 是否可以用多台服务器构建集群
- 是否容易向集群添加新的服务器
- 加入新的服务器后是否提供与原来无差别的服务
扩展性
衡量标准
- 为网站添加新的业务产品时，是否可以实现对现有产品透明无影响
- 不需要改动现有业务功能就能上线新的产品
- 一个产品改动对其他产品无影响
安全性
衡量标准
- 对现有的和潜在的各种攻击手段和窃密手段是否有可靠的应对策略
总结
- 大型网站要素：性能，可用性，伸缩性，扩展性，安全性。
网站的高性能架构
不同人员眼中的性能
用户角度的性能
- 对于用户来说，直观的就是用户感受的网站响应的速度，也就访问后到响应到浏览器的时间。而这段时间实际上包括计算机和服务器的时间服务器的处理时间，浏览器接受响应数据后渲染到页面的时间
开发人员角度的性能
- 响应延迟
- 系统吞吐量
- 并发处理能力
- 系统稳定性
运维人员角度的性能
- 基础设施性能和资源利用率，比如服务器硬件，网络运营商的带宽能力，服务器和网络带宽的资源的利用率
性能测试指标
响应时间
- 指一个操作从发出请求到响应数据需要的时间
- 打开一个网站
- 从数据库查找记录
- 从磁盘读取数据
并发数
- 对于网站而言，并发数就是并发用户数，也就是同时提交请求的用户数目
- 系统用户数(注册用户数)>在线用户（登录用户数）>并发用户数（同时提交请求的用户数）
吞吐量
- 单位时间内系统处理的请求数量
性能计数器
- 系统负载，当前正在被cpu执行和等待被cpu执行的进程数目的总和
- 对象与线程数
- 内存使用
- cpu使用
- 磁盘和网络IO
性能测试方法
性能测试
- 以预期规划的性能指标为预期目标，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期
负载测试
- 对系统不断地增加并发请求以增加系统压力，直到系统的某项或多项性能指标达到安全临界值
压力测试
- 超过安全负载的情况下，对系统继续施加压力，直到系统崩溃，从而获得最大承受压力
稳定性测试
- 给系统加载一定业务压力，使系统运行一段较长时间，来检测系统是否稳定
性能分析
- 对请求经历的各个环节进行分析，检查请求处理的各个环节的日志，分析哪个环节响应时间不合理，然后检查监控数据，分析影响性能的因素（内存，磁盘，网络，cpu，代码等），排查可能出现性能瓶颈的地方。
性能优化
- 前端优化
- 应用服务器优化
- 存储服务器优化
前端优化
减少http请求
- http每次请求都需要建立通信链路，进行数据传输。对于每个请求，服务端需要创建线程去处理。
- 合并css，js，图片。将浏览器一次访问需要的css，js，资源合并成一个文件，这样就可以只用一个请求，减少创造链路和服务端服务的开销
使用浏览器缓存
- 静态资源（css，js，图标）更新频率比较低，可以选择将他缓存在服务器
启用压缩
- 服务端对文件进行压缩，减少传输的数据的数据量，然后浏览器再进行解压
css和js的顺序
- 浏览器加载完所有css才会进行渲染
- 浏览器加载js后立即执行。
- 如果不将js放在底部，那么可能会在执行js的时候阻塞，造成页面显示缓慢。所以css可以放在最上面，js放在最下面
减少cookie传输
- 太大的Cookie会影响数据传输
- 写入cookie的数据要慎重考虑，尽量减少Cookie的数据量
- 请求静态资源发送Cookie是无意义的，服务器并不会对Cookie进行处理，这样会消耗带宽。所以静态资源可以用独立域名访问。
CDN加速
- 所谓CDN实现的就是将资源放在离用户最近的地方，是用户快速获取数据
- CDN可以缓存静态资源
反向代理
- 反向代理服务器配置缓存功能加速请求，当用户请求静态资源的时候，直接从反向代理服务器返回
应用服务器性能优化
分布式缓存
异步操作
- 使用消息队列将调用异步化
- 在不使用消息队列的时候，用户的请求数据直接写入数据库，高并发情况下，会给数据库服务器造成巨大的压力。使用消息队列后，用户请求的数据发送给消息队列后直接返回。消费者进程从消息队列读取数据，异步写入数据库
使用集群
- 构建服务器集群，将并发请求分发到多台服务器
代码优化
- 合理设置线程，IO密集型，线程数最多不超过cpu核心数，IO密集型，多启动线程充分利用cpu资源
- 对象池技术和单例模式，减少开销很大的系统资源的创建和销毁
- 不同场景使用合适的数据结构
- 垃圾回收对系统的性能产生巨大的影响，配置合适的参数进行调优
总结
- 不同人员的角度对性能的衡量标准不同的。
- 性能测试指标：响应时间，并发数，吞吐量，性能计数器
- 性能测试方法：性能测试，负载测试，压力测试，稳定性测试
- 性能优化的方法：前端优化，服务端优化，代码优化，硬件优化
我觉得分享是一种精神，分享是我的乐趣所在，不是说我觉得我讲得一定是对的，我讲得可能很多是不对的，但是我希望我讲的东西是我人生的体验和思考，是给很多人反思，也许给你一秒钟、半秒钟，哪怕说一句话有点道理，引发自己内心的感触，这就是我最大的价值。（这是我喜欢的一句话，也是我写博客的初衷）
作者：jiajun 出处： http://www.cnblogs.com/-new/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。如果觉得还有帮助的话，可以点一下右下角的【推荐】，希望能够持续的为大家带来好的技术文章！想跟我一起进步么？那就【关注】我吧。
