上一篇我们讲了关于大型网站开发如何保证高可用所采用的一些手段，在网站运维实践中，除了网络、服务器等硬件故障导致的系统可用性风险外，还有来自软件系统本身的风险。
特别是我们网站在系统发布上线时不可避免的，项目都需要打包重新发布，这段时间里，对于网站的可用性来说，相当于服务器是处于宕机状态的。设计一个高可用的网站，如果我们网站更新迭代很快，一周更新发布两次或者一次，那么其对系统的可用性来说就会比较频繁的不可用。
下面将分享一些关于跟我们传统软件开发过程中不同的保证可用的手段
1.网站发布
网站的发布过程事实上和服务器宕机效果相当，其对系统可用性的影响也和服务器宕机相似。所以设计一个网站的高可用架构时，需要考虑的服务器宥机概率不是物理上的每年一两次，而是事实上的每周一两次。也许你认为这个应用不重要，重启也非常快，用户可以忍受每年一 到两次的宕机故障，因而不需要复杂的高可用设计。事实上，由于应用的不断发布，用户需要面对的是每周一到两次的宕机故障。
但是网站发布毕竟是一次提前预知的服务器宥机，所以过程可以更柔和，对用户影响更小。通常使用发布脚本来完成发布，其流程如图
2.自动化测试
代码在发布到线上服务器之前需要进行严格的测试。即使每次发布的新功能都是在原有系统功能上的小幅增加，但为了保证系统没有引入未预料的 Bug,网站测试还是需要对整个网站功能进行全面的回归测试。此外还需要测试各种浏览器的兼容性。在发布频繁的网站应用中，如果使用人工测试，成本、时间及测试覆盖率都难以接受。
目前大部分网站都采用 W eb 自动化测试技术，使用自动测试工具或脚本完成测试。大型网站通常也会开发自己的自动化测试工具，可以一 键完成系统部署， 测试数据生成、测试执行、测试报告生成等全部测试过程。
3.预发布验证
即使是经过严格的测试，软件部署到线上服务器之后还是经常会出现各种问题，甚至根本无法启动服务器。主要原因是测试环境和线上环境并不相同，特别是应用需要依赖的其他服务，如数据库，缓存、公用业务服务等，以及一些第三方服务，如电信短信网关、银行网银接口等。
也许是数据库表结构不一 致；也许是接口变化导致的通信失败；也许是配置错误导致连接失败；也许是依赖的服务线上环境还没有准备好，这些问题都有可能导致应用故障。因此在网站发布时，并不是把测试通过的代码包直接发布到线上服务器，而是先发布到预发布机器上，开发工程师和测试工程师在预发布服务器上进行预发布验证，执行一些典型的业务流程，确认系统没有问题后才正式发布。
预发布服务器和线上正式服务器（应用服务器1,2,3)都部署在相同的物理环境（同一 个数据中心甚至同一 个机架上，如果使用虚拟机，甚至可能在同一 个物理服务器上 ）
中，使用相同的线上配置，依赖相同的外部服务。网站工程师通过在自己的开发用计算机上配置 hosts文件绑定域名IP 关系直接使用IP 地址访问预发布服务器。如果在预发布服务器上执行的测试验证是正确的 ， 基本可以确保在线上正式服务器部署时也没有问题。
4.代码控制
代码控制主要是在我们的开发分支上控制，如果是主干打包发布的话，那么出现问题，可以在分支开发，然后开发完成后，再把分支同步到主干。这样不影响在开发过程中影响到已发布系统的可用性。
5.自动化发布
网站的版本发布频繁，整个发布过程需要许多团队通力合作，发布前，多个代码分支合并回主干可能会发生冲突 ( conflict ),预发布验证也会带来风险，每次发布又相当于一次宕机事故。
6.灰度发布
应用发布成功后，仍然可能发现因为软件间题而引入的故障，这时候就需要做发布回滚，即卸载刚刚发布的软件，将上一 个版本的软件包重新发布， 使系统复原，消除故障。
大型网站的主要业务服务器集群规模非常庞大，比如某大型应用集群服务器数量超过一万台。一旦发现故障，即使想要发布回滚也需要很长时间才能完成，只能眼睁睁看着故障时间不断增加却干着急。为了应付这种局面，大型网站会使用灰度发布模式，将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天才把整个集群全部发布完毕， 期间如果发现间题，只需要回滚已发布的一 部分服务器即可。
待续。。。
网友评论