常见应用发布方式剖析

Posted 2023-03-03 alden_ygq

目录

1. 概述

2. 发布方式介绍

2.1 手动发布

2.1.1 简介

2.1.2 优点

2.1.3 缺点

2.1.4 应用场景

2.1.5 流量模式

2.1.6 注意事项

2.2 蓝绿发布

2.2.1 简介

2.2.2 优点

2.2.3 缺点

2.2.4  适用场合

2.2.5 流量模式

2.2.6 注意事项

2.3 金丝雀发布

2.3.1 简介

2.3.2 优点

2.3.3 缺点

2.3.4  适用场合

2.3.5 流量模型

2.4 滚动发布

2.4.1 简介

2.4.2 优点

2.4.3 缺点

2.4.4  适用场合

2.4.5  流量模型

3. 发布方式优化

---

1. 概述

互联网产品应用程序在升级过程中面临最大挑战是新旧业务切换时，除需将软件从测试的最后阶段变更升级到生产环境，同时要保证系统不间断提供服务。经过多年业界沉淀，业务升级渐渐形成了几个发布策略，目的是尽可能避免因发布导致的流量丢失或服务不可用问题，带来如丝般顺滑的新应用发布体验。本文主要介绍目前主流的集中发布策略：

• 手动发布
• 蓝绿发布
• 金丝雀(灰度)发布
• 滚动发布

2. 发布方式介绍

2.1 手动发布

2.1.1 简介

手动发布方式常用于新成立、缺少运维管控体系的公司或团队，其发布方式是直接使用新的版本覆盖掉老的版本，发布过程中业务会导致服务中断进而导致用户受到影响。

2.1.2 优点

• 发布简单
• 成本较低

2.1.3 缺点

• 发布过程中通常会导致服务中断进而导致用户受到影响

2.1.4 应用场景

• 适应于开发环境或者测试环境或者是公司内部系统这种对可用性要求不高的场景；
• 有些小的公司资源稀缺(服务器资源，基础设施等)

2.1.5 流量模式

2.1.6 注意事项

生产环境发布时间建议在业务流量最低的时间段进行发布，降低业务中断引起的业务影响范围。

2.2 蓝绿发布

2.2.1 简介

蓝绿发布过程中会同时存在两套系统：一套运行旧版本应用，被称为“绿色”；一套运行新版本应用，被称为“蓝色”。两套系统均功能完善，且系统均正常运行，只是系统版本和对外服务情况不同。正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。

两套系统互不干扰，发布过程中，可以单独对蓝色系统进行调试，而不影响绿色系统提供服务。在蓝色系统调试好后，可将流量导至蓝色系统，进行用户测试；若出现问题，则切回绿色系统。在用户测试没问题后，升级绿色系统。

2.2.2 优点

• 发布策略简单；
• 用户无感知，平滑过渡；
• 全量发布，升级/回滚速度快。

2.2.3 缺点

• 需要准备正常业务使用资源的两倍以上服务器，防止升级期间单组无法承载业务突发；
• 短时间内浪费一定资源成本；
• 基础设施无改动，增大升级稳定性。
• 全量发布，若新版本有问题，会影响全量用户的使用。

2.2.4  适用场合

• 对用户体验有一定容忍度的场景

• 机器资源有富余或者可以按需分配（AWS 云，或自建容器云）

• 暂不具备复杂滚动发布工具研发能力；

2.2.5 流量模式

2.2.6 注意事项

蓝绿发布是众多发布方式中的一种，需要根据特定情况进行选择。蓝绿部署能够简单快捷实施的前提假设是目标系统是非常内聚的，如果目标系统相当复杂，那么如何切换、两套系统的数据是否需要以及如何同步等，都需要仔细考虑。

当业务切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果业务后端数据库无法处理，会是一个比较麻烦的问题；

• 可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况，如果在蓝绿部署中协调不好这两者，还是有可能会导致服务停止。
• 需要提前考虑数据库与应用部署同步迁移 /回滚的问题。
• 蓝绿部署需要有基础设施支持。
• 在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险。

2.3 金丝雀发布

2.3.1 简介

金丝雀发布是灰度发布的一种。其来源于矿井工人发现,金丝雀对瓦斯气体很敏感,矿工会在下井之前,先放一只金丝雀到井中,如果金丝雀不叫了,就代表瓦斯浓度高，则终止下矿，金丝雀发布由此得名，其实现原理就是在发布过程中，将发布实例分为两批，第一批先发一台或者一小部分比例的机器作为金丝雀，用于流量验证如果金丝雀验证通过则把剩余机器全部发掉。如果金丝雀验证失败，则直接回退金丝雀。

2.3.2 优点

• 可以用少量用户来验证新版本功能，这样即使有问题所影响的也是很小的一部分客户；
• 成本低；
• 如无法做到平滑切换，则用户有感知。

2.3.3 缺点

• 金丝雀发布本质上仍然是一次性的全量发布，发布过程中用户体验并不平滑，有些隐藏深处的bug少量用户可能并不能验证出来问题，需要逐步扩大流量才可以。

2.3.4  适用场合

• 对新版本功能或性能缺乏足够信心

2.3.5 流量模型

2.4 滚动发布

2.4.1 简介

在金丝雀发布基础上的进一步优化改进，是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式。其发布方式是逐台进行平滑发布，整个发布过程如下所示:

发布前：

 发布中：

发布后：

滚动发布每次发布一台，后面的实例需要等待前面的实例发布完成(可提供服务) 。

2.4.2 优点

• 发布成本低；
• 用户体验影响小；
• 升级切换和回退（rollback）速度快。

2.4.3 缺点

• 不适用于实例多的业务，发布周期较长；
• 发布策略较复杂。

2.4.4  适用场合

• 实例数量较少的集群；

• 有一定的发布工具研发能力；

2.4.5  流量模型

3. 发布方式优化

以上的发布方式在实际运用过程中，或多或少都会存在一些无法避免的问题，不能做到完全无损发布，而在互联网行业中，流传着业务稳定性4个9的说法，即全年业务不可用的时长为52分钟。因此迭代频繁的产品如使用以上发布方式，则无法保证4个9的稳定性，因此很多互联网公司为了保证其业务可用性，纷纷在发布阶段针对业务稳定性做了很多的工作，以提高业务可用性，也出现了一些商用的产品，如阿里云的主备服务器组产品等。那么没有采用商用产品的企业是怎么做的呢？大部分企业是通过发布过程中屏蔽新流量的方式降低发布过程的业务的业务影响，实现方式有：

• 服务发现，动态探测服务可用性，如不可用，则从集群中摘除；
• 屏蔽策略，发布前屏蔽即将要发布的实例流量，待发布完成后解除；
• 流量调度策略，一般业务均为集群部署，发布时，将即将发布的实例流量转接到其他机器上，发布完成后解除，但此方法不适用于大并发迭代。