大型网站技术架构，网站的高性能架构（二）
一、网站性能测试
网站的性能指标，既可以是开发人员客观的性能分析数据，测试指标。也可以是主观的终端用户体验感受。一般而言，我们用如下指一些标来衡定一个网站的性能水平：响应时间、并发数量、吞吐量、性能计数器。响应时间即从请求发出开始，到收到响应并解析成对应的可视化结果所花费的时间；并发数指系统能够同时处理的请求数量。吞吐量是指单位时间内系统能够处理的请求数量，常用的单位为TPS（每秒事务数）、HPS（每秒的 HTTP 请求数）、QPS（每秒数据库查询数）；性能计数器为直观的数据指标，比如当前系统负载、对象与线程数、CPU /内存使用率、磁盘与网络IO等。理想的系统负载应该对应为系统的 CPU 数量，因为系统负载指当前正在排队被 CPU 处理的进程数量。
常见的测试方法分为：性能测试、负载测试、压力测试和稳定性测试。性能测试用来验证在资源可接受范围内，系统在一定压力下能否达到预期的性能指标。负载测试用来测试当系统资源满载时，系统能够达到的最大吞吐量。压力测试则是在超过系统安全负载的时候继续施加压力，测试直到系统奔溃所用时间的长短。而稳定性测试则是让系统在一定压力下运行一段时间，检测系统在不同时间点是否有资源的使用异常，以此来推断系统的稳定性。
在性能测试和负载测试中，系统的 TPS 随着压力的增加，值会不断增高。而在压力测试下，由于此时系统资源早已耗尽，更多的压力只会拖垮 CPU 的性能，因此此时的系统 TPS 会随着压力的不断增加而逐渐降低。而系统的响应时间在所有测试中都是随着压力的增加而逐渐增加的，不过在压力测试中，每对系统施加单位的压力，系统的响应时间会成倍的疯狂增长。
对于系统性能的优化，需要从一个请求出发，记录下请求达到每个关键节点（比如代理服务器，负载均衡服务器，应用服务器）的时间，分析哪段时间不合理，再通过分析监控数据来检测问题所在。
二、WEB 前端优化
合并资源、分离静态资源到独立域名（防止 Cookie 污染）、浏览器本地缓存、服务器 GZip 压缩、CDN 加速（ISP端）、使用反向代理（相当于 Gateway 主机，可缓存资源，还可以保护内部网络）等等。
三、应用服务器优化
应用服务器主要用来处理系统业务，是整个网站架构中的核心，也是最复杂变化最多的部分。常用的优化手段有：使用分布式缓存（网站优化第一定律：优先考虑使用缓存。缓存不适用于频繁修改的数据，不适用与没有热点访问的数据，并且容易产生脏读。系统的正常运行不应该依赖于缓存系统，初始的缓存系统可以先进行“缓存预热”，比如 Redis 在初始化时会从硬盘中读取数据放到内存。如果在日志中发现大量的无法命中缓存的请求，这可能是发生了“缓存穿透”，恶意用户持续高并发的访问系统不存在的资源，这些资源无法被缓存下来导致了穿透问题，一个简单的对策是将不存在的数据也缓存起来。常见的分布式缓存系统如 JBoss 和 Memcache，JBoss 的所有集群机器在数据改变时会在所有机器更新，而 Memcache 采用 Leader 的方式，各个主机间不进行通信，因此其线性伸缩不会影响缓存系统的性能）、使用共享队列、使用集群、代码优化（采用多线程，线程数一般与 CPU 数量成正比，使用无状态对象或者加锁来防止一致性问题，数据连接、通信连接等资源复用）
四、存储系统优化
使用 SSD 硬盘、使用 NoSql 数据库（由于 LSM 树的数据更新速度较 B+ 树更快）、 根据需求使用 RAID 磁盘阵列和 HDFS（RAID 可以在一定程度上改善磁盘的访问延迟同时增强可用性。但对于大量数据的存储需求，基于 MapReduce 可以进行并发任务处理的 HDFS 可能更加合适）
明天继续说，大型网站技术架构，网站的高可用架构（三）
相关文章