11.6 高可用：架构运维方案

1.发布

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

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

不管发布的新功能是修改了一个按钮的布局还是核心交易功能，

都需要再服务器上关闭原有应用，然后重新部署启动新的应用，整个过程不影响用户的使用。

网站的发布过程和服务器宕机效果相当，可以用服务器宕机的高可用方案来应对网站的发布。

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

而是事实上的每周一两次。用户需要面对的是每周一两次的宕机故障。

2.自动化测试

代码在发布到线上服务器之前需要严格的测试。即使每次发布的新功能都是在原有的系统功能上的小幅增加，但是为了保证系统没有引入未预料的 BUG，网站测试还是需要对整个网站功能进行全面的回归测试。

此外还需要测试各种浏览器的兼容性，再发布频繁的网站应用中，如果使用人工来进行，成本和时间都难以承受。

目前大部分网站都采用 Web 自动化测试技术，使用自动测试工具或脚本完成测试。

比较流行的 Web 自动化测试工具是 ThoughtWorks 开发的 Selenium。

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

3.自动化部署

4.持续部署三步走

持续集成

• 允许工程师随时向公共分支提交代码，并立即自动化测试

持续交付

• 出了跑单元测试及软件打包，持续交付机制会将软件部署到各种测试环境中

持续部署

• 代码在没有人工干预的情况下被测试，构建，部署并推送到生产环境。

5.持续部署流程

6.预发布验证

即使经过严格的测试，软件部署到线上服务器还是会出现各种问题，甚至根本无法启动服务器。主要原因：测试环境和线上环境并不相同。特别是应用需要依赖的其他服务，如数据库，缓存，公共业务服务等，以及一些第三方服务。如：电信短信网关，银行网银接口等。也许是接口变化导致的通信失败；也许依赖的服务在线上环境还没有准备好；这些问题都可能导致应用故障。

因此在网站发布的时候，并不是吧测试通过的代码包直接发布到线上服务器，而是先发布到预发布机器上，

开发工程师和测试工程师在预发布机器上验证预发布，执行一两个典型的业务流程，确认系统没有问题后才正式发布。

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

7.代码版本控制

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

而这些团队对同一个应用的开发维护，其开发周期和发布特点各不相同。如何管理代码，既能保证代码发布版本的稳定正确，

同时又能保证不同团队的开发互不影响。

主干开发，分支发布：

• 代码修改都在主干上进行，需要发布的时候，从主干上拉一个分支发布，该分支及成为一个发布版本，如果该版本发现 bug，继续在该分支上修改发布，并将修改合并（merge）回主干，指导下次主干发布。

分支开发，主干发布：

• 任何修改都不得在主干上进行，需要开发一个新功能或者修复一个 BUG 的时候，从主干拉一个分支进行开发，开发完成测试通过后，合并回主干，然后从主干发布，主干上的代码永远是最新发布的代码。

互联网一般采用第二种。

8.自动化发布

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

9.灰度发布

应用发布完成后，仍然可能会发现因为软件问题而引入的故障，这时候就需要做发布回滚，

即卸载刚刚发布的软件，将上一个软件包重新发布，使系统恢复，消除故障。

大型网站的主要业务服务器集群规模非常庞大，比如：QQ 的服务器数量超过一万台。

一旦发现故障，即使想要发布回滚也需要很长的时间才能完成，只能看着故障时间增加。

为了应付这种局面，大型网站会使用灰度发布模式，将集群服务器分成若干部分，

每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，

持续几天的时间把整个集群全部发布完毕，期间如果发现问题，

就只需要回滚已发布的一部分服务器即可。

10.网站运行监控

“不允许没有监控的系统上线”，这是许多网站架构师在做项目上线评审的时候常说的一句话。

网站运行监控对于网站运维和架构设计优化只管重要，没有监控的网站，犹如盲人骑瞎马，夜半临深渊而不知。生死未卜，提高可用性，减少故障率就无从做起。

11.监控数据采集

12.用户行为日志收集

用户行为日志指用户在浏览器上所做所有操作机器所在的操作环境，

包括用户操作系统与浏览器版本信息，IP 地址，页面访问路径，

页面停留时间，这些数据对统计网站 PV/UV 指标，

分析用户行为，优化网站设计，个性化营销和推荐等非常重要。

具体用户行为日志手机手段有两种

服务器端日志收集，这个方案比较简单，Apache 等几乎所有 Web 服务器都具备日志记录功能，

可以记录大部分用户行为日志，开启 Web 服务器的日志记录功能即可。

其缺点可能会出现信息失真，如 IP 地址是代理服务器地址而不是用户真实 IP；

多个连接指向同一个页面的情况下无法分辨访问路径等。

客户端浏览器日志收集，浏览器可以收集用户真实的操作行为，

因此比服务器日志收集更加精准。其缺点是比较麻烦，需要再页面嵌入特定的 JS 脚本来完成。

13.服务器性能监控

收集服务器性能指标，如系统 Load，内存占用，磁盘 IO，网络 IO 等对尽早做出故障预警，

及时判断应用状况，防患于未然，将故障扼杀在萌芽时期非常重要。

此外根据性能监控数据，运维工程师可以合理安排服务器集群规模，

架构师技师改善系统性能及调整系统伸缩性策略。

目前网站使用比较广泛的开源性能监控工具是 Ganglia，

支持大规模服务器集群，并支持以图形的方式在浏览器展示实时性能曲线。

报警：

服务器运行正常的情况下，其各项监控指标基本稳定在一个特定水平，如果这些指标超过某个阈值，

就意味着系统可能将要出现故障，这时候就需要对相关人员报警，及时采取措施，

在故障还未真正发生就扼杀在萌芽状态。

监控管理系统可以配置报警阈值和值守人员的联系方式，报警方式除了邮件，及时通讯工具，

还可以配置手机短信，语音报警，保证发生报警时，工程师及时通知，迅速响应。

自动控制：

自动失效转移：除了应用程序访问失败时失效转移，监控系统也可以在发现故障的情况下主动通知应用，失效转移。

自动扩容：如果因访问压力大而导致服务性能指标下降，监控系统自动触发服务集群扩容。

自动限流：根据监控指标，自动控制访问流量。

14.监控系统架构

15.高可用价值观

保持简单，是问题易于发现，快速解决。

目标明确，解决特定环境下的具体问题。

价值回归，成本收益要合理。