高可用——软件质量保证

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

下面会介绍一些为了保证线上系统的可用而采取的一些与传统软件按开发不同的质量保证。

1. 站发布

站需要保证7×24高可用运行，同时 站又需要不断地发布新功能吸引用户以保证在激烈的市场竞争中获得成功。

许多大型 站每周都需要发布一到两次，而中型 站则更加频繁，一些处于快速发展期的 站甚至每天发布十几次。

不管发布的新功能是修改了一个按钮的布局还是增加了一个核心业务，都需要在服务器上关闭原有的应用，

然后重新部署启动新的应用，整个过程还要求不影响用户的使用。

这相当于要求给飞行中的飞机换个引擎，既不能让飞机有剧烈晃动（影响用户体验），

也不能让飞机降落（系统停机维护），更不能让飞机坠毁（系统故障 站完全不可用）。

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

所以设计一个 站的高可用架构时，需要考虑的服务器宕机概率不是物理上的每年一两次，而是事实上的每周一两次。

也许你认为这个应用不重要，重启也非常块，用户可以忍受每年一到两次的宕机故障，因而不需要复杂的高可用设计。

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

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

预发布服务器和线上正式服务器都部署在相同的物理环境，

同一个数据中心甚至同一个机架上，如果使用虚拟机，甚至可能在同一台物理服务器上，使用相同的线上配置，依赖相同的线上环境。

站工程师通过在自己的开发机上配置hosts文件绑定域名IP关系直接使用IP地址访问预发布服务器。

如果在预发布服务器上执行的测试是成功的，基本可以保证在线上正是服务器部署时也没有问题。

不过，也有可能会因为预发布验证而引入问题。

因为预发布服务器连接的是真实的环境，所有预发布验证操作都是真实有效的数据，这些操作也许会引起不可预期的问题。

比如创建一个店铺，上架一个商品，就有可能有真的用户过来购买，如果不能操作，就会导致用户投诉。

此外，在 站应用中强调的一个处理错误的理念是快速失败（fast failed），即系统如果在启动时发现问题就立刻抛出异样，

停止启动让工程师介入排查错误，而不是启动后执行错误的操作。

4.代码控制

对于大型 站，核心应用系统和公共业务模块涉及许多团队和工程师，需要对相同的代码库进行共同开发和维护。

而这些团队对同一个应用的开发维护（开发周期和发布时间各不相同），如果代码控制环节出了问题，

可能将有问题的代码发布上线，将问题带入生产环节，导致系统故障。

站代码控制的核心问题是如何进行代码管理，既能保证代码发布版本的稳定正确，同时又能保证不同团队的开发互不影响。

目前大部分 站使用的源代码版本控制工具是SVN，SVN代码控制和版本发布方式一般有以下两种。

（1）主干开发、分支发布

代码修改都在主干（trunk）上进行，需要发布的时候，从主干上拉一个分支（branch）发布，

即分支成为一个发布版本，如果该版本发现Bug，继续在该分支上修改发布，将修改合并（merge）回主干，直到下次主干发布。

这两种方式各有优缺点。

主干开发、分支发布方式，主干代码反应目前整个应用的状态，一目了然，便于管理和控制，也利于持续集成。

分支开发、主干发布方式，各个分支独立进行，互不干扰，可以使不同发布周期的开发在同一应用中进行。

目前 站应用开发中主要使用的是分支开发、主干发布的方式。

可以想象，如果使用主干开发、分支发布，那么在同一个应用上，对于不同开发周期，不同发布时间的项目，

有可能A项目发布时，B项目只开发了一半，这时候的主干代码是半成品，根本不能发布。

而使用分支开发、主干发布的方式，只需要将A项目的分支合并到主干即可发布，不受B项目发布时间的影响。

目前在开源技术 区，Git作为版本控制工具，正逐步取代SVN的地位。

Git对分布式开发、分支开发等有更好的支持，也更容易在各个开发分支上及时反应主干最新跟新，

避免SVN在最后提交代码时发现主干代码差别太大难以merge成功。

如果想查看更多GIt和SVN的区别，请访问另一篇博客：http://www.cnblogs.com/yangmingxianshen/p/8361369.html

5.自动化发布

站版本发布频繁，整个发布过程需要许多团队通力合作，发布前，多个代码分支合并回主干可能发生冲突（conflict），

预发布验证也会带来风险，每次发布又相当于一次宕机事故。因此 站发布过程中荆棘丛生，一不小心就会踩雷区。

对于有固定发布日期的 站，很多 站选择周四作为发布日，这样一周前面有三天时间可以准备发布，

后面还有一天可以挽救错误，如果选择周五发布，发现问题就需要加班加点了。

火车发布模型：将每个应用的发布过程看作一次火车旅行，火车定点运行，期间有若干站点，

每一站都例行检查，不通过的项目下车，剩下的项目继续坐着火车，直到火车到达终点（应用发布成功）。

灰度发布也常用户用户测试，即在部分服务器上发布新版本，其余服务器保持老版本（或者发布另一个版本），

然后监控用户操作行为，收集用户体验 告，比较用户对两个版本的满意度，以确定最终的发布版本。这种手段叫做AB测试。

文章知识点与官方知识档案匹配，可进一步学习相关知识Git技能树首页概览2875 人正在系统学习中 相关资源：android实现手机摇晃摆动效果_android开发-Android代码类资源…