架构系列(一)---大型网站架构演化,要素及性能

大型网站架构演化

目录

大型网站特点

  • 高并发,大流量
  • 高可用,系统不间断服务
  • 海量数据,数据量大,需要存储海量数据
  • 用户分布广泛,用户分布在五湖四海
  • 安全环境恶劣,容易受到受到攻击
  • 需求变更块,发布频繁
  • 渐进式发张,从小型网站慢慢发展为大型系统

大型网站的技术挑战

  • 高并发访问
  • 海量的数据

演化发展

  • 一台服务器就足够,程序,数据库和文件都在一台服务器上
  • 使用三台服务器,不同特性的服务器负责不同的功能。程序,数据库和文件分离,应用程序处理大量业务,需要强大的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/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。如果觉得还有帮助的话,可以点一下右下角的【推荐】,希望能够持续的为大家带来好的技术文章!想跟我一起进步么?那就【关注】我吧。

posted @ 2017-09-18 08:11 jiajun_geek 阅读(...) 评论(...) 编辑 收藏