作者 | 长门

**导读：**本篇是《SpringCloud 应用在 Kubernetes 上的最佳实践》系列文章的第七篇，主要介绍了新功能上线时，如何尽快减少对线上用户的影响？发布系统需要提供回滚到前一个或前几个版本的能力，达到快速恢复线上业务的目的。

前言

通常一次应用的线上发布就表示了一次新功能的上线。在上线过程中，可能发生一些非预期的情况，如新版本软件有 bug，或者功能不达预期，就会影响了线上客户的使用。为了尽快减少对线上用户的影响，发布系统需要提供回滚到前一个或前几个版本的能力。达到快速恢复线上业务的目的。

从应用的部署变更层次来看，可以分为以下三层：

所以对应了以下的回滚场景：

回滚应用内的配置，适用于由于应用配置变更导致的问题，此时如果应用能够实现动态的配置加载，通过回滚配置就能实现业务恢复的目的，否则需要重启应用；
回滚应用代码的版本，适用于代码修改导致的问题。此时需要回滚代码的版本（镜像），重启应用；
回滚应用的工作负载与运维配置（基础设施层）。

应用内配置回滚

应用内的配置通常与应用系统需要或业务逻辑配置有关，如配置数据库的连接信息，业务规则配置等，配置的变更也很容易造成线上系统的问题，一般的做法是通过 configmap 或 properties 配置文件来实现，这种情况下很难做到动态推送和回滚的能力，因为回滚需要保存不同版本的配置。

通过分布配置管理（ACM）（EDAS 默认支持）很容易实现配置的集中管理，回滚和灰度，分布式推送，审计等功能。可以在 ACM 或 EDAS 的控制台上实现一键回滚，如下图所示：

应用代码回滚

Deployment 是一种常见部署的应用的 workload，回滚代码其实对应了回滚对应代码版本的镜像，其实就是对应就是 Deployment 的回滚，Kubernetes 可以通过以下方式支持 Deployment 的回滚。

Deployment 回滚

在一个标准的 Kubernetes 体系下，如果出现新版本的 pod 不能正常工作，需要将 deployment 回滚到历史版本，Kubernetes 提供了原生的支持；其原理是在默认情况下，Kubernetes 会将历史记录保留在系统中，直接使用使用 rollout 命令回滚即可，如下：

回滚到上一个版本

kubectl rollout undo deployment.v1.apps/{deployment.name}

回滚到指定的版本：可以通过kubectl rollout history查看历史的版本

kubectl rollout history  deployment.v1.apps/{deployment.name}

可以通过以下命令回滚到指定的版本

kubectl rollout undo deployment.v1.apps/{deployment.name} --to-revision={version}

EDAS 中应用回滚

而在 EDAS 中，结合了原生的能力做了更丰富的白屏的体验，我们就发布过程中和发布完成后两个场景分别描述。

发布过程中回滚

发布过程中回滚是指在应用发布过程中，就发现了问题，需要将应用回滚到前一个版本。此时的操作就是中断发布流程，将已经升级完成后或正在升级的服务器回滚到前一个版本。

EDAS 在每次变更时候，可以直接中断发布流程，一键回滚。如下图所示:

另外，EDAS 发布系统提供单批，分批，金丝雀灰度等多种发布形式，在分批和金丝雀灰度的发布的时候，EDAS 还提供不同批次的监控信息，如系统指标，应用指标，应用异常检测等能力，提供快速发现问题能力，如果存在问题，可以立即进行回滚。如下图所示：

我们推荐的方式也是在发布过程中尽量使用分批和金丝雀的能力，以将发布引起的不可用降至最小。

发布完成后回滚

发布后回滚是指一次部署过程已经完成，包含部署成功或失败。这个时候，可以通过部署历史的版本来实现回滚的功能。EDAS 默认会存储最多十个部署过的版本，如下图所示：

通过以上的功能，基本上可以覆盖应用在上线过程中需要回滚的场景。减少由于系统发布出问题，造成系统功能使用上的影响。

应用自动回滚

从上面的介绍，可以看到回滚的操作都是人工进行的，其实在一些场景里，可以根据一些监控指标，如CPU，load，内存等维度，快速发现问题，就能做到自动回滚，可以能够更快地恢复系统。在 Kubernetes 的体系中，Flagger(https://github.com/weaveworks/flagger) 就是能够实现自动回滚的一个很好的工具。

应用工作负载和运维配置回滚

上面介绍了应用内配置和应用代码回滚的方式，在常见的变更中，还存在工作负载及运维配置的变更，如更改工作负载的类型，变更 JVM 参数，日志配置，弹性伸缩等。其中 JVM 参数等通常可以随 Deployment 进行回滚，但是类似 Kubernetes service，日志，弹性伸缩规则等这些基础设施和运维相关的能力回滚就很难做到了。需要将应用的代码，工作负载，运维配置等实现配置化来实现回滚的能力。

这里推荐阿里巴巴与微软联合提出的 OAM（Open Application Model）的规范，它定义了应用的统一交付模型。

在 OAM 中，一个应用程序包含以下几个核心的理念：

Component：是指应用中的组件，可以是应用运行所依赖的服务如 MySQL 数据库等，也可以是应用的本身，如 Spring cloud 的服务提供者。可以通过 Component 的定义规范来编写一个组件；
Trait：是指应用的运维特征，描述了应用部署在具体环境中的运维特征，比如弹性伸缩规则和 Ingress 配置等，这些运维特征会应用到具体的组件上；
Applicationconfiguration：是将 Components 和 traits 组装成一个真正能运行起来应用的定义。这个配置文件就是 OAM 规范中的一个声明式 API，通过它就能实例化出对应的，真实运行的应用。

一个 OAM 的应用例子如下：

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:name: springcloud-provider-deploymentannotations:version: v1.0.0description: "Description of this deployment"
spec:components:- componentName: springcloud-provider-componentparameterValues:- name: PARAMETER_NAMEvalue: SUPPLIED_VALUE- name: ANOTHER_PARAMETERvalue: "AnotherValue"traits:- name: manualscaler.core.oam.devversion: v1spec:replicaCount: 3scopes:- scopeRef:apiVersion: core.oam.dev/v1alpha2kind: NetworkScopename: example-vpc-network

通过 OAM 的 ApplicationConfiguration 这份配置，就能描述线上真正运行的应用，结合能将配置版本化的系统，如 Git，ACM 等，采用对应的 ApplicationConfiguration 的版本，就能实现应用的一键回滚。EDAS 里就是通过 OAM 规范来管理 Kubernetes 的应用，结合 OAM 声明式 API 的方式，EDAS 里将会实现多种应用回滚的场景，为线上业务保驾护航。

如果你有任何疑问，可以钉钉搜索群号：23310022，进入 OAM 项目中文讨论群。

后续及结语

本章我们介绍了 EDAS 的发布系统在 EDAS Kubernetes 集群上进行应用发布的时候，针对一些异常场景，如何进行快速回滚。但是如果出现问题，如何快速找到问题所在，接下来的文章我们将介绍，在 EDAS 里通过线上里联调来进行问题诊断。

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的公众号。”

SpringCloud 应用在 Kubernetes 上的最佳实践 — 线上发布（可回滚）相关推荐

SpringCloud 应用在 Kubernetes 上的最佳实践 — 线上发布（优雅上下线）
作者 | 骄龙导读:本篇是<SpringCloud 应用在 Kubernetes 上的最佳实践>系列文章的第八篇,主要介绍了如何做到流量的无损上/下线.更多相关文章阅读可查看文末. 前言 ...
SpringCloud 应用在 Kubernetes 上的最佳实践 — 线上发布（可监控）
作者 | 骐羽阿里巴巴技术专家导读:本篇是"SpringCloud 应用在 Kubernetes 上的最佳实践"系列文章的第六篇,主要介绍了如何保障生产环境服务稳定,做到随时发 ...
SpringCloud 应用在 Kubernetes 上的最佳实践 — 线上发布（可灰度）
作者 | 白寂阿里云开发工程师导读:前三篇文章我们介绍了应用的开发和部署,那么在应用成功上云后,我就要面对应用的管理话题了,这一篇我们来看看如何做线上发布,并且是可灰度的. 相关文章推荐: &l ...
SpringCloud 应用在 Kubernetes 上的最佳实践 —— 高可用（容量评估）
作者 | 牛兔导读:本文是<SpringCloud 应用在 Kubernetes 上的最佳实践>系列文章的第 11 篇,从前面两期开始我们进入到了高可用专题,分别介绍了流量防护和故障演练 ...
SpringCloud 应用在 Kubernetes 上的最佳实践 — 高可用（熔断）
作者 | 宿何导读:前几篇我们主要站在应用发布的场景,描述在发布过程中会遇到的灰度.监控.回滚.优雅上下线等保障发布能顺利进行的注意事项.作为一个程序员 GG,可灰度的发布顺利上线往往意味着准点下班 ...
SpringCloud 应用在 Kubernetes 上的最佳实践 — 诊断（线上联调）
作者 | 纳海阿里巴巴高级开发工程师 **导读:**上篇我们介绍了应用成功上云后,面对应用的管理,如何做可灰度的线上发布,那么当云上的应用行为不符合预期的时候,您会怎么处理呢?修改代码,打包,部署 ...
SpringCloud 应用在 Kubernetes 上的最佳实践 —— 高可用（弹性伸缩）
作者 | 三未前言弹性伸缩是一种为了满足业务需求.保证服务质量.平衡服务成本的重要应用管理策略.弹性伸缩让应用的部署规模能够根据实时的业务量产生动态调整,在业务高峰期扩大部署规模,保证服务不被业务 ...
Spring Cloud 应用在 Kubernetes 上的最佳实践 — 高可用（混沌工程）
作者 | 穹谷导读:从上篇开始,我们进入到了高可用的章节,上篇提到的熔断能力,是历年保障大促当天晚上整个系统不被洪峰流量打垮的法宝.本文将重点介绍为什么我们要做混沌工程以及如何使用 ChaoBlad ...
bk3432开发的应用实例_SpringCloud应用在Kubernetes上的最佳实践—诊断（线上联调）...
作者 | 纳海阿里巴巴高级开发工程师导读:上篇我们介绍了应用成功上云后,面对应用的管理,如何做可灰度的线上发布,那么当云上的应用行为不符合预期的时候,您会怎么处理呢?修改代码,打包,部署,然后查看 ...

SpringCloud 应用在 Kubernetes 上的最佳实践 — 线上发布（可回滚）

前言