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

大型网站架构演化

目录

这是我的博客目录，欢迎阅读

大型网站特点

高并发，大流量

高可用，系统不间断服务

海量数据，数据量大，需要存储海量数据

用户分布广泛，用户分布在五湖四海

安全环境恶劣，容易受到受到攻击

需求变更块，发布频繁

渐进式发张，从小型网站慢慢发展为大型系统

大型网站的技术挑战

高并发访问

海量的数据

演化发展

一台服务器就足够，程序，数据库和文件都在一台服务器上

使用三台服务器，不同特性的服务器负责不同的功能。程序，数据库和文件分离，应用程序处理大量业务，需要强大的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资源

对象池技术和单例模式，减少开销很大的系统资源的创建和销毁

不同场景使用合适的数据结构

垃圾回收对系统的性能产生巨大的影响，配置合适的参数进行调优

总结

不同人员的角度对性能的衡量标准不同的。

性能测试指标：响应时间，并发数，吞吐量，性能计数器

性能测试方法：性能测试，负载测试，压力测试，稳定性测试

性能优化的方法：前端优化，服务端优化，代码优化，硬件优化

我觉得分享是一种精神，分享是我的乐趣所在，不是说我觉得我讲得一定是对的，我讲得可能很多是不对的，但是我希望我讲的东西是我人生的体验和思考，是给很多人反思，也许给你一秒钟、半秒钟，哪怕说一句话有点道理，引发自己内心的感触，这就是我最大的价值。（这是我喜欢的一句话，也是我写博客的初衷）