持续交付之发布与监控

前言：本篇内容根据前携程系统研发部总监王潇俊老师的专栏《持续交付36讲》整理的学习笔记，有兴趣的同学也可购买专栏系统地学习。

一、发布是持续交付的最后一公里

发布是一个慢慢滚动向前、逐步生效的过程。
一个好的发布系统应该应是易用、快速、稳定、容错力强，必要时有能力回滚的系统。

什么是好的发布流程？

第一， 把大象放进冰箱分几步？

1. 在目标机器上执行命令停掉运行中的服务；
2. 把提前准备好的变更产物传上机器覆盖原来的目录；
3. 运行命令把服务再跑起来。

第二， 靠谱的单机部署

1. 下载新的版本，不执行覆盖；
2. 通知上游调用方，自己现在为暂停服务状态；
3. 运行命令load变更重启服务；
4. 验证服务的健康状况；
5. 通知上游调用方，自己服务恢复正常。

第三， 扩展到集群
当发布的目标是一组机器而不是一台机器时，主要问题就变成了如何协调整个过程。
比如，追踪、同步一组机器目前发布进行到了哪一步，编排集群的发布命令就成为了更核心的功能。集群提供了新的、更易行的方法提高系统地发布时稳定性，其中最有用的一项称为灰度发布。

灰度发布是指，渐进式地更新每台机器运行的脚步，一段时期内集群内运行着多个不同的版本，同一个API在不同机器上返回的结果很可能不同。

几种常见的灰度方式

1. 蓝绿发布，先增加一套新的集群，发布新版本到这批新机器，并进行验证，新版本服务器并不接入外部流量。此时旧版本集群保持原有状态，发布和验证过程中老版本所在的服务器仍照常服务。验证通过后，流控处理把流量引入新服务器，待全部流量切换完成，等待一段时间没有异常的话，老版本服务器下线。

• 这种发布方法需要额外的服务器集群支持，对于负载高的核心应用机器需求客观，实现难度巨大且成本较高。
• 蓝绿发布的好处是所有服务都使用这种方式时，实际上创造了蓝绿两套环境，隔离性最好，最可控，回滚切换几乎没有成本。

2. 滚动发布，不添加新机器，从同样的集群服务器中挑选一批，停止上面的服务，并更新为新版本，进行验证，验证完毕后接入流量。重复此步骤，一批一批地更新集群内所有的机器，直到遍历完所有机器。
这种滚动更新的方法比蓝绿发布节省资源，但发布过程中同时会有两个版本对外服务，无论是对自身或是调用者都有较高的兼容性要求，需要团队间的合作妥协。但这类问题容易解决，实际中往往会通过功能开关等方式来解决。
3. 金丝雀发布，从集群中挑选特定服务器或一小批符合要求的特征用户，对其进行版本更新及验证，随后逐步更新剩余服务器。

二、任何变更都需要发布
不可变模型
不可变模型转化到不可变基础设施，具体的要求：对任何的包、配置文件、软件应用和数据，都不做CRUD(创建、替换、更新、删除)操作。
不可变的前提是无状态。

不可变基础设施的神话

第一， 一致是最终的目标
三种模型
1. 发散，通常会碰到的基础设施的管理模型。基础设施随着我们的想法而变化。
2. 收敛，是Puppet和Chef遵循的设计原则。随着时间推移，目标和实际需求汇聚，达到一致。
3. 一致，指的是整个基础设施始终把每一天当成是与第一天相同的模型。

从发散到收敛的过程中会遇到顺序问题、频率问题、蝴蝶效应等问题。容器通过分层镜像与镜像发布技术，解决了这些问题。容器使得每一次变更都成为了一次发布，而每一次发布都成为了系统地重新构建，从而使得“一致”模型的目标能够达成。

首先，任何的变更，包括代码的、配置的、环境的、甚至是CPU、内存、磁盘的大小变化，都需要制作独立版本的镜像。

其次，变更的镜像可以提前制作，但必须通过发布才能生效。

再次，一组运行中的同一个镜像的实例，因为“不可变”的原因，其表现和实质都是完全一样的，所以不再需要关心顺序的问题。因为任何一个都等价，所以也就没有发布或替换的先后问题了。

最后，根据“一致”模型的要求，我们需要记录系统从第一天发展到今天的所有有序变更。

三、发布系统一定要注意用户体验

1 张页面展示发布信息

这个页面能够展示发布当时的绝大多数信息、数据和内容，这个页面既要全面，又要精准。

2个操作按钮简化使用

用户在页面上会看到的同时出现的按钮组合有以下四种情况：

1. 开始发布，1个按钮
2. 中断发布，1个按钮
3. 中断或重试发布，2个按钮，发生在有局部错误的情况下；
4. 中断或继续发布，2个按钮，发生在发布被刹车时。

3种发布结果

• 成功状态
• 失败状态
• 中断状态

4类操作选择

• 开始发布
• 停止发布
• 发布回退
• 发布重试

5个发布步骤

1. markdown: 为了减少应用发布时对用户的影响，所以在一个实例发布前，都会做拉出集群的操作，这样新的流量就不会再继续进入了。
2. download: 这就是根据版本号下载代码包的过程；
3. install: 在这个过程中，会完成停止服务、替换代码、重启服务这些操作；
4. verify: 除了必要的启动预检外，这一步还包括了预热过程；
5. markup: 把实例拉回集群，重新接受流量和请求。

6大页面主要内容

第一， 集群。
第二， 实例。
第三， 发布日志。
第四， 发布历史。
第五， 发布批次。
第六， 发布操作。

四、发布系统的核心架构和功能设计

首先，高效的发布系统架构应该是清晰的、健壮的、低耦合的。

其次，在设计核心模型时，考虑到部署架构的个性化设计，即要兼容单机应用，又要兼容单机多应用的问题。

再次，发布系统的发布流程，可以通过状态流转控制单机发布的5个步骤和发布批次。

最后，一款出色的发布系统除了要考虑以上问题外，还同时必须考虑一些附加问题，如：

• 为了降低Quick and Dirty 方式对业务功能的影响，你需要提供发布刹车机制；
• 利用分布式存储、尾单加速、symlink回滚等方式，可以提升发布速度；
• 必要的降级机制，可以保证发布系统的高可用。

五、业务及系统架构对发布的影响

单机单应用还是单机多应用？

单机单应用在故障排除、配置管理等方面有很多优势，另外应用与应用之间解耦，发布系统的设计会变得简单很多。

增量发布还是全量发布？

全量发布时互联网应用发布的最好方式，每个代码包只针对一个版本，清晰明了，回滚也非常简单。

六、如何利用监控保障发布质量？

监控的分类

1. 用户侧监控，关注的是用户真正感受到的访问速度和结果；
2. 网络监控，即CDN与核心网络的监控；
3. 业务监控，关注的是核心业务指标的波动；
4. 应用监控，即服务调用链的监控；
5. 系统监控，即基础设施、虚拟机及操作系统的监控。

发布监控的常见问题

快速发现发布带来的系统异常，优先观察业务监控是最直接、有效的方式。但有两种情况是业务监控无能为力的：

• 第一种情况是累积效应，即系统异常要累积到一定量后才会表现为业务异常；
• 另外一种情况就是业务的阴跌，这种小幅度的变化也无法在业务监控上得到体现。

因此，还需要配合应用监控。

监控的其他问题

第一个问题，测试环境也要监控吗？

如果监控系统只能做到系统监控或日志级别的系统监控，对于一些对系统性能压榨比较厉害、对稳定性没太多要求的测试环境来说，无需配备完整的监控系统。

如果监控系统已经做到了调用链甚至全链路的监控，那么监控系统无疑就是你的“鹰眼”，除了发现异常，还可以在定位异常等方面给你帮助。在这样的情况下，一定要为测试环境配备监控系统。

第二个问题，发布后需要监控多久？

30分钟。

第三个问题，如何确定异常是由我的发布引起的？

需要建立一套完整的运维事件记录体系，并将发布纳入其中，记录所有的运维事件。当有异常情况时，可以根据事件线进行相关性分析。