作者 | 長門
導讀：本篇是《SpringCloud 應用在 Kubernetes 上的最佳實踐》系列文章的第七篇，主要介紹了新功能上線時，如何盡快減少對線上使用者的影響？釋出系統需要提供復原到前一個或前幾個版本的能力，達到快速恢複線上業務的目的。
相關文章推薦：
- 《SpringCloud 應用在 Kubernetes 上的最佳實踐 —— 開發篇》
- 《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 部署篇(開發部署）》
- 《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 部署篇(工具部署)》
- 《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出（可灰階）》
- 《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 診斷（線上聯調）》
- 《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-deployment
annotations:
version: v1.0.0
description: "Description of this deployment"
spec:
components:
- componentName: springcloud-provider-component
parameterValues:
- name: PARAMETER_NAME
value: SUPPLIED_VALUE
- name: ANOTHER_PARAMETER
value: "AnotherValue"
traits:
- name: manualscaler.core.oam.dev
version: v1
spec:
replicaCount: 3
scopes:
- scopeRef:
apiVersion: core.oam.dev/v1alpha2
kind: NetworkScope
name: example-vpc-network 通過 OAM 的 ApplicationConfiguration 這份配置，就能描述線上真正運作的應用，結合能将配置版本化的系統，如 Git，ACM 等，采用對應的 ApplicationConfiguration 的版本，就能實作應用的一鍵復原。EDAS 裡就是通過 OAM 規範來管理 Kubernetes 的應用，結合 OAM 聲明式 API 的方式，EDAS 裡将會實作多種應用復原的場景，為線上業務保駕護航。
如果你有任何疑問，可以釘釘搜尋群号：23310022，進入 OAM 項目中文讨論群。
後續及結語
本章我們介紹了 EDAS 的釋出系統在 EDAS Kubernetes 叢集上進行應用釋出的時候，針對一些異常場景，如何進行快速復原。但是如果出現問題，如何快速找到問題所在，接下來的文章我們将介紹，在 EDAS 裡通過線上裡聯調來進行問題診斷。
“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公衆号。”