大型网站技术架构，5网站的高可用架构之高可用网站的软件质量保证

5.6 高可用网站的软件质量保证

在网站运维实践中，除了网络、服务器等硬件故障导致的系统可用性风险外，还有来自软件系统本身的风险。

本节不再赘述传统的软件测试和软件质量保证管理，而是讲一些不同的质量保证手段。

 

5.6.1 网站发布

网站的发布过程事实上和服务器宕机效果相当，其对系统可用性的影响也和服务器宕机相似。

由于应用的不断发布，用户需要面对的是每周一到两次的宕机故障。

但是，网站发布毕竟是一次提前预知的服务器宕机，所以过程可以更柔和，对用户影响更小。通常使用发布脚本来完成发布，其流程如下图

 

 发布过程中，每次关闭的服务器都是集群中的一小部分，并在发布完成后立即可以访问，因此整个发布过程不影响用户使用。

 

5.6.2 自动化测试

虽然是系统功能的小幅增加，但是全面的回归测试需要的。此外还需要测试各种浏览器的兼容性。

在发布频繁的网站应用中，如果使用人工测试，成本、时间及测试覆盖率都难以接受。

 

Web自动化测试技术，使用自动测试工具或脚本完成测试。

 

Selenium运行再浏览器中，模拟用户操作进行测试，因此Selenium可以同时完成Web功能测试和浏览器兼容测试。

大型网站通常也会开发自己的自动化测试工具，可以一键完成系统部署，测试数据生成、测试执行、测试报告生成等全部测试过程。

 

5.6.3 预发布验证

测试通过的代码包发布到预发布环境机器上，开发工程师和测试工程师再预发布环境进行预发布验证，执行一些典型的业务流程，确认系统没有问题后才正式发布。

 

预发布服务器和线上正式服务器唯一不同的是没有配置在负载均衡服务器上，外部用户无法访问。

 

预发布服务器和线上服务器都部署在相同的物理环境中，使用相同的线上配置，依赖相同的外部服务。

网站工程师通过在自己的开发机器上配置hosts文件绑定域名IP关系直接使用IP地址访问预发布服务器。如果在预发布服务器上执行的测试验证是正确的，基本可以确保线上正式服务器部署时也没有问题。

 

但是，预发布也可能引入问题。因为预发布服务器连接的是真实的生产环境，所有的预发布验证操作都是真实有效的数据，这些操作也许会引起不可预期的问题。比如创建一个店铺，上架一个商品，就可能有真的用户过来购买，如果不能发货，会导致用户投诉。

 

快速失败，如果系统在启动时发现问题就立刻抛出异常，停止启动让工程师介入排查错误，而不是启动后执行错误的操作。

 

5.6.4 代码控制

VCS版本控制系统Git，SVN管理代码 。

git flow

阿里巴巴代码规约、findbugs、checkstyle代码静态扫描。

 

5.6.5 自动化发布

很多网站选择周四作为发布日，这样一周前面有三天时间可以准备发布，后面一天时间可以挽回错误。如果选择周五发布，发现问题就必须要周末加班了。

 

火车发布模型

 

 

火车发布模型是基于规则驱动的流程，根据响应驱动流程，自动构造代码分治，进行代码合并，执行发布脚本。

正常流程下，可以做到发布过程无人值守，无需SCM(网站配置管理员)参与，每个项目相关人员基于流程执行相应的操作，即可完成应用自动发布。

 

5.6.6 灰度发布

发布成功后，依然可能引入故障，就需要做发布回滚。

 

发布的量很大，回滚也会很耗时，大型网站会使用灰度发布，将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天才把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可。

 

 

灰度发布也常用于用户测试，即在部分服务器上发布新版本，其余服务器保持老版本，然后监控用户操作行为，收集用户体验报告，比较用户对两个版本的满意度，以确定最终的发布版本。这种手段也被称作AB测试。