15 高可用 站的软件质量保证

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

2 自动化测试

代码在发布到线上服务器之前需要进行严格的测试。即使每次发布的新功能都是在原有系统功能上的小幅增加，但为了保证系统没有引入未预料的Bug, 站测试还是需要 对整个 站功能进行全面的回归测试。此外还需要测试各种浏览器的兼容性。在发布频 繁的 站应用中，如果使用人工测试，成本、时间及测试覆盖率都难以接受。

目前大部分 站都采用Web自动化测试技术，使用自动测试工具或脚本完成测试。 比较流行的Web自动化测试工具是Thoughtworks开发的Seleniumo Selenium运行在浏览 器中，模拟用户操作进行测试，因此Selenium可以同时完成Web功能测试和浏览器兼容测试。

3 预发布验证

即使是经过严格的测试，软件部署到线上服务器之后还是经常会出现各种问题，甚 至根本无法启动服务器。主要原因是测试环境和线上环境并不相同，特别是应用需要依 赖的其他服务，如数据库，缓存、公用业务服务等，以及一些第三方服务，如电信短信 关、银行 银接口等。

也许是数据库表结构不一致；也许是接口变化导致的通信失败；也许是配置错误导致 连接失败；也许是依赖的服务线上环境还没有准备好，这些问题都有可能导致应用故障。

因此在 站发布时，并不是把测试通过的代码包直接发布到线上服务器，而是先发 布到预发布机器上，开发工程师和测试工程师在预发布服务器上进行预发布验证，执行 一些典型的业务流程，确认系统没有问题后才正式发布。

预发布服务器是一种特殊用途的服务器，它和线上的正式服务器唯一的不同就是没 有配置在负载均衡服务器上，外部用户无法访问，如图5.15所示。

可以想象，如果使用主干开发、分支发布，那么在同一个应用上，对于不同开发周 期，不同发布时间的项目，有可能A项目发布的时候，B项目只开发了一半，这时候的 主干代码是半成品，根本不能发布。而使用分支开发、主干发布的方式，只需要将A项 目的分支合并回主干即可发布，不受B项目发布时间的影响。

目前在开源技术 区，Git作为版本控制工具，正逐步取代SVN的地位。Git对分布 式开发，分支开发等有更好的支持，也更容易在各个开发分支上及时反映主干的最新更 新，避免SVN在最后提交分支代码时发现和主干代码差别太大难以merge成功。但是Git 的学习成本较高，如何和 站开发流程相结合还缺乏最佳实践和使用规范。不过相信Git 成为 站的标准版本控制工具是迟早的事。

5 自动化发布

站的版本发布频繁，整个发布过程需要许多团队通力合作，发布前，多个代码分 支合并回主干可能会发生冲突（conflict）,预发布验证也会带来风险，每次发布又相当于 一次宕机事故。因此 站发布过程荆棘丛生，一不小心就会踩到雷。

对于有固定发布日期的 站（很多 站选择周四作为发布日，这样一周前面有三天时间可以准备发布，后面还有一天时间可以挽回错误。如果选择周五发布，发现文件就必须要周末加班了。），一到发布日，整个技术部门甚至运营部门就如临大敌，电话声此 起彼伏，工程师步履匆匆，连空气中的温度都仿佛升高了几度。即便如此，发布过程还 是常常岀错，发布日工程师加班到凌晨是常有的事。而且容易忙中岀错，因发布引发的 故障也居高不下。

据说国外某知名互联 公司的CTO就因为没有有效手段控制发布故障、减少发布日 的加班而引咎辞职。其继任者提出了一个火车发布模型：将每个应用的发布过程看作一 次火车旅程，火车定点运行，期间有若干站点，每一站都进行例行检查，不通过的项目 下车，剩下的项目继续坐着火车旅行，直到火车到达终点（应用发布成功）。但实际中， 有可能所有项目都下车了，开着空车前进是没有意义的，火车不得不回到起点，等待解 决了问题再重来一次。还有可能是车上有达官贵人（重点项目，CEO跟投资人拍胸脯的 项目），他不上车，谁也别想走，他出了错，大家都跟着回去重来。简化的火车发布模型 如图5.17所示。

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