架构师训练营 1 期第 11 周：安全稳定 - 总结

本文主要介绍在系统的发布运维环节，可能会导致系统故障或者降低系统可用性的一些问题，以及应对这些问题的方法策略。

发布

• 系统发布其实就是一次系统停机，新的代码要发不上线，老的系统进程需要被中断进程，会导致系统访问不可用，如何保证系统中断的时候，系统依然可用，我们需要结合负载均衡、失效转移等手段来保证，正这个过程中，部分服务器代码升级了，还有一部分未升级，会出现新老代码同时对外提供服务的情况，这个是可以接受的。

• 系统发布流程如下：

自动化测试

• 要想保证发到线上的应用是较少故障的，系统是高可用的，代码在发布到线上服务器之前需要进行严格的测试。即使每次发布的新功能都是在原有系统功能上的小幅增加，但是为了保证系统没有引入未预料的 BUG，网站测试还是需要对整个网站功能进行全面的回归测试。在发布频繁的网站应用中，每次发布之前都需要进行完整的测试，测试资源和测试周期都是不能满足要求的，同时在高负荷的测试工作量的压力下，人工测试也无法保证测试的结果和质量。

• 为了避免人工测试带来的高负荷的压力，以及测试不完全的影响，最后导致系统线上的故障和bug，我们最好是使用自动化测试的方法进行回归测试

• 自动化测试和手工测试的成本

• 做自动化测试，需要准备很多测试脚本和测试内容，在早期的时候，准备这些测试脚本本身可能需要较长的时间，投入成本比较大，而手工测试反而操作更简单更快，但是随着时间的推移，系统变稳定了，测试脚本也相对稳定，针对每次小的改动进行全量的测试，自动化测试的优势就体现出来了。

• 自动化测试是测试工程师的测试，是保证整个系统的功能完整性和正确率的测试，是代替人工测试的一种手段，是测试环节的工作。

• 单元测试是开发环节的一个测试，是由开发工程师自己进行的一个测试，它测试的是具体程序内部的方法，功能模块是否能够正常运行的测试。

• 开发工程师自己要保证负责开发的功能没有问题，测试工程师负责把整个系统集成起来，把每个工程师的工作打包成一个系统，然后对整个系统进行测试，保证系统整体的正确性

• 大多数的情况下，原来的测试脚本是能够正常执行的，在没有修改界面或请求响应的内容的时候，原来的测试脚本直接可以使用，小部分的功能逻辑被修改了，通过修改脚本或者增加新的测试用例也可以覆盖到，自动化测试用较低的成本实现了全部的每一次发布前的回归测试，全量的功能测试。

自动化部署

• 目前大多数互联网系统是使用手工部署的方式，开发工程师开发完成，测试工程师测试，测试完后，运维工程师打包发布；自动化部署是开发工程师开发完代码以后，直接提交代码到版本控制工具，自动会触发自动化的测试，自动化测试测试完成，没有发现bug，测试所有的功能正常，自动会触发发布功能，系统就自动发布了，即代码发布即系统发布这样的过程，通过这种方式去加快代码上线的过程，同时用自动化的手段去管理全部的发布过程，提高了效率，降低了人工参与引来的各种问题。

• 持续部署三步走

• 持续集成

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

• 持续交付

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

• 持续部署

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

• 持续部署流程

• 目前这种持续的自动化部署推广的并不多，一方面对于大公司而言，开发工程师很多，这种持续的自动化部署，可能会产生一些不可控的因素，所以还是要控制发布的时间节点，统一的进行发布，不会用这种持续的自动化部署，而小的公司很多时候又没有这样的技术力量去推行这样的自动化发布部署。目前一些云服务厂商会推动和提供一些自动化部署的一整套解决方案。

预发布验证

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

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

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

代码版本控制

• 对于大型互联网系统，核心应用系统和公用业务模块涉及许多团队和工程师，需要对相同的代码库进行共同开发和维护，而这些团队对同一个应用的开发维护，其开发周期和发布时间点各不相同。如何进行代码管理，既能保证代码发布版本的稳定正确，同时又能保证不同团队的开发互不影响。

• 主干开发，分支发布：

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

• 分支开发，主干发布：

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

• 一般互联网应用大部分使用第二种发布方式，即分支开发，主干发布的方式，因为互联网应用中不同的团队，开发速度可能完全不一致的，如果主干开发会导致要发布时，可能会发布不完整的内容，或者需要等待很长时间等开发完成后再发布，这两种情况都是不能接受的。采用分支开发时，为了避免由于开发周期较长在合并代码的时候产生大量的代码冲突，在开发的过程中，要不断的从主干上拉最新代码和分支代码进行合并，保证分支上的代码也是最新的。

自动化发布

• 自动化发布和自动化部署不一样，自动化部署是说，无需人工参与的情况下，自动的将代码部署上线；而自动化发布是说，发布还是人去控制，但是发布过程是自动的。

• 早期的时候，在发布的时候，大家去合并代码，合并完代码以后，有专门的发布工程师去发布上线，这个过程是没有控制的，会出现很多问题，一方面就是各种各样的代码冲突，需要运维工程师去协调各方的工程师去解决冲突，另一方面在发布过程中出了问题，也是人去解决这些问题的，而人解决问题的过程中，就会导致一些风险的产生，由于是人去处理问题，其中最大的麻烦在于发布的时间会拖延的很长，不断的会有一些代码冲突，预发布过程中发现的bug，不断的退回去重新修改代码重新提交，这种临时的紧急的修改代码，很容易引入新的bug，而测试工程师有时候测试不完整或注意不到，这些带着问题的代码就上线了，如果得不到及时处理，可能会导致故障扩大。

• 自动化发布就是把整个过程自动化的去管理起来，不再是人去处理这些问题，一则减少了人处理问题过程中可能引入的不确定因素，二则是整个过程变得更加有节奏，使最终的发布时间能够在一个合理的时间内完成。

• 在自动化发布过程中，不断的检查不符合规定的代码，把它们剔除出去，留下来那些风险较小的，能够继续发布的代码，最后去发布完成。这是一个严格的自动化发布的过程，会导致中间每个环节都会有一些分支被剔除发布，最后正式发布的时候，没有新代码能够发布，通常情况下，这种时候，会重新到起点，然后重新在走一次自动化发布过程，允许重新提交代码，重新进行确认，重新merge代码，重新预发布验证，都通过了以后再正式发布。因为把过程分成了几段，系统自动的去处理，除非有更高权限的人退回重来，否则系统就自动地往前去运行下去，可以减少一些，开发不完整或内部测试不完整的功能发布出去带来的风险。

灰度发布

• 应用发布完成功后，仍然可能会发现因为软件问题而引入的故障，这时候就需要做发布回滚，即卸载刚刚发布的软件，将上一个版本的软件包重新发布，使系统复原，消除故障。

• 大型网站的主要业务服务器集群规模非常庞大，比如 QQ 的服务器数量超过一万台。一 旦发现故障，即使想要发布回滚也需要很长时间才能完成，只能眼睁睁看着故障时间在 不断增加干着急。为了应付这种局面，大型网站会使用灰度发布模式，将集群服务器分 成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天的时间才把整个集群全部发布完毕，期间如果发现问题，就只需要回滚已发布的一部分服务器即可。

• 恢复发布不仅是保障系统的高可用，还要保障业务的持续发展，提升业务价值

网站运行监控

• 网站运行监控对于网站运维和架构设计优化至关重要，大多数系统都要进行系统的运行期监控，监控系统的各项指标是否正确，当系统出现异常波动的时候，系统指标出现问题的时候，第一时间会收到报警信息，第一时间去检查，首先确认功能是不是有问题，系统可用性是否用问题，根据监控数据指标信息，快速的分析问题，解决问题，这样一方面可以尽早的发现问题，另一方面在处理问题的过程中可以更多的得到一些监控数据的支持，去加快处理问题的速度。

• 监控数据采集

• 用户行为日志收集

• 服务器性能监控

• 业务运行数据报告

• 监控管理

• 监控数据采集后，除了用作系统性能评估、集群规模伸缩性预测等，还可以根据实时监控数据进行风险预警，并对服务器进行失效转移，自动负载调整，最大化利用集群所有机器的资源。

• 监控系统架构

• 通常在被监控服务器上，要部署一些Agent代理进程，用来收集监控这些服务器上面的各项指标，JVM指标，系统指标，甚至可以和应用进程进行通讯，收集它们的日志，收集它们报告上来的各种业务指标，这些指标收集到了以后就推送给监控服务。

• 监控服务通常使用一些大数据流计算的技术，一方面把数据存储起来，一方面推送给监控系统监控系统检查自己报警的阈值，如果查过了阈值就会通知相关的人员，同时可以通过一些自动化控制的策略或手段去控制服务器，实现一些限流降级的主动控制。