高性能网站架构和对应测试考虑

     今天早上把极客时间上的茹炳晟《软件测试52讲》正文完整地听完了。历时4个月，也是第一次正式购买这类学习课程。现在把最近的几讲内容，结合自己经验做个小结。

       高性能网站架构，主要是考虑基本功能性需求满足基础上，效率（performance）、高可用性（Availability）、高伸缩性（Scalability）、高扩展性（Extensibility）。

1、性能

 1.1前端高性能架构

         主要是优化用户实际感受到的前端页面展现时间。主要手段包括：a）优化脚本设计，减少文件请求次数；b）避免页面跳转；c）压缩文件；d）使用CDN分发，使用缓存；e）使用浏览器端缓存技术等。

      一般使用合适的测试工具（如：WebPageTest、Yslow），逐项检查加载和渲染时间，研读文本和源码，测试并不困难。

 1.2后端高性能架构

     1） 主要技术还是缓存。技术上对应有不同层级的缓存：例如前面说的前端技术上的浏览器级别的缓存；CDN本质上也是缓存；反向代理服务器本质上属于用户数据中心最前端的缓存；数据库中的热点数据，在应用服务器集群中有一级缓存，DNS服务器也采用缓存。动态页面静态化，本质上当然也是可以认为是缓存。只要一段时间内数据可以认为是无需更新的，则可以采用缓存技术提高性能。目前规范应用的主流缓存技术方案就是Memcached。缓存对应考虑测试场景：

• 缓存命中、不命中
• 基于缓存过期测试策略，考虑必须重新获取数据情况
• 针对可能存在缓存“脏数据”的情况
• 缓存穿透，永远不会出现取缓存数据情况
• 系统冷启动后，在缓存预热阶段数据库访问压力
• 分布式缓存集群，扩容场景测试

   2）集群

所有服务器地位对等的集群模式；配备单独重点的服务器的模式。主要关注测试点：

• 集群容量扩展，加入新节点的测试
• 无状态应用是否可以灵活转移
• 基于Session有状态应用，能否保证同一Session在同一节点处理
• 一个或多个节点宕机时可靠性
• 负载均衡算法实际效果是否符合预期
• 高并发场景下，集群能承载的最大容量

2、高可用性（Availability）

针对常见的几类故障，对应的解决办法如下：

1）服务器硬件故障。采取硬件冗余，各种热备，异地容灾，集群，包括云的灵活伸缩其实也可以视作一种硬件灵活调配。

2）发布新应用。可以采取灰度发布，逐步转移。

3）应用程序本身问题。预防当然时加强质量控制，加强前期测试，特别是发布前的友好用户的预发布测试（有点像灰度测试的意思）。

3、高伸缩性（Scalability）

主要指同样业务，适应用户规模变化调整服务规模的能力，堆叠性其实是个更形象的更切合英文的翻译。

一般有两类，一种是按层分切堆叠；一种是按业务纵向堆叠。关注点主要时应用服务器、缓存集群、数据库集群三个层面，和第一部分后台性能做的事情有很大重合度。

1）应用服务器层面：引入负载（任务）均衡器，采取合适的任务分配策略和算法，保证伸缩性。主要测试点：

• 单节点负载承受能力
• 负载均衡算法是否准确
• 可以引入节点数量是否有上限
• 新加入节点和最初节点是否有差异‘
• 系统承受能力是否随加入节点线性增长
• 有状态的应用，在节点增长时会否出现问题

2）缓存集群

同1.2.2.不再重复。

3）数据库

• 数据库正确读取到刚写入数据的延迟时间
• 数据库架构调整或参数调整时，数据库基准性能是否会明显变化
• 数据库在线扩容过程中，业务受影响程度
• 数据库集群某个节点故障时，业务受影响程度

4、高扩展性（Extensibility）

    高扩展的关键在架构设计上去耦，一般采用微服务架构或基于消息队列通信机制的事件驱动机制。

消息队列通信机制需要额外关注的测试点：

• 需要考虑如何在消息队列中构造测试数据；自输出中验证模块行为。因此，需要消息队列的读取和写入工具
• 需要针对消息队列满、消息队列扩容等特殊情况测试
• 需要针对消息丢失、消息处理异常缓慢等消息队列服务器出问题甚至宕机的情况进行异常设计

         归根结底，对互联网特别时电子商务网站的应用比较陌生，因此这里更多时结合讲座内容抄录。要真正做好测试，还是需要了解原理，才能发掘瓶颈、深入浅出。