2月19日-2月26日，螞蟻金服開展了“共戰‘疫情’，技術破局”數字課堂線上直播，邀請資深專家從“雲原生”、“研發效能”、“資料庫”三方面分享螞蟻金服的實踐經驗并線上答疑，解析 PaaS 在金融場景的落地建設實踐，解析支付寶移動端彈性動态架構，分享 OceanBase 2.2版本的特性和實踐。
本文根據 螞蟻金服 SOFAStack 産品專家俞仁傑，在螞蟻金服數字課堂直播間分享的雲原生應用 PaaS 平台的建設實踐内容整理，以下為演講整理全文：
大家好，歡迎來到螞蟻金服數字課堂直播間。今年 2 月，SOFAStack 金融分布式架構産品已經在阿裡雲上完成了商業化釋出，為了讓更多朋友了解到我們的産品的能力、定位以及背後的設計思路，後續我們會有一系列的直播分享。我們今天想分享給大家的話題叫《雲原生應用 PaaS 平台的建設實踐》，主要會圍繞 PaaS 産品能力在一些需要穩妥創新的金融場景下的落地思路，并且能夠更好地與雲原生架構做好連結。
金融場景雲原生落地面臨挑戰
雲原生是業務快速變化背景下的必然技術趨勢
回顧 IT 的發展史，雲計算分類為 IaaS PaaS 和 SaaS 已經有十幾年了。而事實上，整個雲計算行業的發展，我們能夠明顯看到企業在落地雲計算戰略的時候經曆的三個階段，Cloud-Based, Cloud-Ready, Cloud-Native。這三個階段其實是因為業務的變化越來越靈活，要求企業關注重心上移，把更多的精力和人才投入到業務邏輯的建設上，而把下層自已并不擅長并且越來越複雜的基礎設施、中間件逐漸交給雲計算廠商去實作，專業的人做專業的事。
這本質是社會分工的進一步細化，也符合人類社會發展的規律。在雲原生時代，業界所提出的容器技術，Service Mesh 技術，Serverless 技術都是希望讓業務研發與基礎技術更加的解耦，讓業務創新和基礎技術創新都更容易的發生。
容器技術帶來的是一種應用傳遞模式的變革
雲原生就是業務快速變化背景下的必然技術趨勢。而這個趨勢背後的實質載體，就是我們所說的雲原生、Kubernetes 以及以 Docker 為代表的容器技術，這些所帶來的，本質是一種應用傳遞模式的變革。而為了真正能夠使業界、社群所倡導的新興應用傳遞模式落地到實際的企業環境，我們需要一個以應用為中心的平台來進行承載，貫穿應用運維的各項生命周期。
圍繞“雲原生”這個關鍵詞，其實在社群和業界已經有了非常多的交流和資料，圍繞Docker/K8S 的最佳實踐、DevOps CICD、容器網絡存儲設計、日志監控對接優化等等等等，而我們今天的分享，主要想表達的是我們圍繞在 K8S 之上塑造一個 PaaS 平台的産品價值主張。Kubernetes 是一個非常好的編排和排程架構，它核心的貢獻是讓應用的編排和資源的排程更加的标準化，同時提供了一個高度可擴充的架構，友善上層進行各種控制器和排程器的定制。但是，它并不是一個 PaaS。PaaS 底層可以基于 Kubernetes 去實作，但是在上層要補足非常多的能力才能真正把 Kubernetes 用于生産環境，特别是金融行業的生産環境。
金融場景需要“穩妥創新”
生産環境落地雲原生需要着重考慮哪些挑戰？
我們之前做過一些調研和客戶訪談。就現在 2020 年來說，絕大多數金融機構都展現出了對 Kubernetes、容器等技術的極大興趣，有不少機構也已經在一些非關鍵的業務、或開發測試環境搭建了開源或商業版的叢集。驅動力很簡單，金融機構非常希望這一整套新的傳遞模式幫助到業務飛速疊代。然而對比落差非常明顯的是，真正敢于在核心生産環境落地雲原生架構的，又少之又少。因為金融業務創新的前提，是要保障穩妥。
我們團隊在服務螞蟻内部業務、外部金融機構的過程中，總結了以上這幾個方面，事實上這六大方面也是我們内部 SRE 不斷挑戰的幾點。我們在今天以及未來的分享中，會逐漸總結深化應對這些挑戰的産品思路。
K8S 體系下的應用變更與釋出管控
我們今天分享的一個核心内容，就是我們如何在産品層面做應用變更的風險保障的。并圍繞此話題向大家介紹變更“三闆斧”的背景、K8S 原生部署能力、我們産品圍繞變更需求做的擴充并向大家介紹我們在開源方面的規劃。
需求背景：變更“三闆斧”
所謂“三闆斧”就是可灰階、可監控、可應急。這是螞蟻内部運維的一條紅線準則，所有的變更，都必須要遵從這個規則，即使再細小的變更，再嚴密的測試，也不能忽略這條規則。為了滿足這個需求，我們在 PaaS 産品層設計了各種各樣的精細化釋出政策，比如分組釋出、beta 釋出，灰階釋出，藍綠釋出等。這些釋出政策跟我們在做傳統運維時用的手段是非常相似的，但很多使用容器的使用者認為在 K8S 裡實作會非常的困難。
有些時候，由于對業務連續性的極高要求，也很難接受原生 K8S 模型标準化模式，比如原生 Deployment 做灰階或者金絲雀釋出時，預設情況下在 Pod 變更和流量治理層面的管控還稍顯不足，無法完全做到無損釋出或按需過程管控。是以，我們在 PaaS 産品層面做了定制，在 Kubernetes 層面做了自定義資源的擴充，目的是能夠在雲原生的場景下，依然對整個釋出過程實作精細化管控，使得大規模叢集釋出、灰階、復原時更加優雅，符合技術風險三闆斧原則。
Kubernetes 原生釋出能力
我們先來回顧一下 K8S 的原生 Deployment 對象，及其背後的 ReplicaSet，其實已經是在最近好幾個大版本中已經逐漸的穩定了。 簡單的來說，最常見的 K8S 釋出場景，我們會通過 Deployment 的對象，聲明出我希望的釋出模式以及 Pod Spec 定義。在運作時，會有 ReplicaSet 對象來管理 Pod 數量的預期，預設情況下會提供滾動釋出或重建釋出能力。
image.png這幅圖的下半部分，是圍繞 Deployment 作滾動釋出時的示意圖，這裡不再做過多的展開，它的本質根據使用者根據我們的運維需求設定好一定的步長，建立新的 Pod，銷毀舊的 Pod，是以能做到整個應用版本的變更和釋出過程中，都能有對應的容器對外提供服務。 對大部分場景來說，它是夠用的，而且整個過程也是非常好的了解，事實上在 K8S 體系，大家除了 Pod/Node，看的最多的就是 Deployment了。
CAFEDeployment：感覺底層拓撲和領域模型
回顧完 Deployment，我們可以再給大家看一下我們根據實際需求作的 CRD 擴充，CAFEDeployment。CAFE 是我們 SOFAStack PaaS 産品線的名稱，本文的最後會作一些介紹。
CAFEDeployment 有一個很重要的能力，就是能夠感覺到底層拓撲，這個拓撲是什麼意思呢？能夠知道我想把我的 Pod 釋出到哪裡，哪邊的 Node，不隻是基于親和性的規則作綁定，而是真正能把高可用、容災、以及部署政策等場景息息相關的資訊，帶到整個圍繞釋出的領域模型中。對此，我們提出了一個叫部署單元的領域模型，他是一個邏輯概念，在 yaml 中簡單的叫做 Cell。在實際使用中，Cell 的背後，可以是不同的 AZ 不同的實體機房，不同的機架，一切都是圍繞着不同級别的高可用拓撲。
CAFEDeployment：精細化分組釋出擴容
感覺到了底層拓撲，我們再看一下 CafeD 的典型釋出過程。這也是後面會通過産品控制台和指令行來示範的内容。這幅圖所展現的過程，是一個精細化的分組釋出，目的是能夠讓容器執行個體層面的變更，做到足夠的可控和灰階。每一個階段都能暫停、驗證、繼續或復原。
以圖上這個例子進行說明，我們的目标是釋出或變更 10 個 Pod，且需要讓這 10 個 Pod 能夠均勻分布在兩個可用區，確定在應用層面是高可用的。同時，在釋出的過程，我們是需要引入分組釋出的概念，即每個機房都要先僅僅釋出一個執行個體，暫停驗證之後，再進行下一組的釋出。于是第 0 組，就變成兩邊各 1 個執行個體，第 1 組各兩個，第 2 組則是剩下的 2 個。在實際的生産環境中，圍繞容器大規模變更會配合業務監控及更多元度的觀察，確定每一步都是符合預期、驗證通過的。這樣在應用執行個體層面的精細化管控，為運維提供了能夠及時刹車復原的機會，是線上應用釋出的一個重要的保險繩。
CAFEDeployment：優雅摘流無損釋出
講完整個精細化的釋出，我們再講一個精細化的摘流。無損釋出需要確定南北和東西向的網絡流量都能被優雅摘除，確定在容器停機、重新開機、縮容的時候能夠對線上業務無感。
這張圖展示了一個 Pod 作變更釋出時的控制流程規範。時序圖中包括了 Pod 以及其相關聯的各元件控制器，着重是和網絡相關的如 Service Controller、LoadBalancer Controller 作配合，進行切流、流量回複檢查等操作以實作無損釋出。
在傳統經典運維場景基于指令式的運維習慣下，我們可以通過依次執行指令每個元件進行原子操作，確定入口流量、應用間流量都能完全摘除後，再執行實際的變更操作。而在雲原生 K8S 場景下，這些複雜的操作都留給了平台，運維人員隻需作簡單的聲明即可。我們在部署時把應用所關聯的流量元件（不限于 Service loadbalancer/ RPC/ DNS...) 都透傳到 CAFEDeployment，添加對應的“finalizer”，并通過 ReadinessGate 來做 Pod 是否可以承載流量的辨別。
以原地更新控制器 InPlaceSet 控制下的 Pod 為例，在做指定 Pod 更新時，會設定 ReadinessGate=false，相關聯的元件感覺到變化後，逐個登出對應的 IP，觸發實際摘流動作。在等待相關 Finalizer 都被摘除之後，進行更新操作。待新版本部署成功後，設定 ReadinessGate=true，在依次觸發各關聯元件的實際流量挂在動作。待檢測到 finalizer 和實際 CAFEDeployment 中聲明的流量類型全部一緻後，目前 Pod 才算釋出完成。
開源版本介紹：OpenKruise - UnitedDeployment
我們再回到 PPT 的一個講解，其實剛剛說的 CAFEDeployment，它在我們整個 CAFED 的一個商業化的産品，事實上在整個商業闆的同時，我們也在做一些社群的開源，而在這個裡面我想介紹一下 OpenKruise 項目，OpenKruise 源于整個阿裡巴巴經濟體的大規模雲原生運維實踐，我們把許多基于 K8S 體系下的自動化運維運維操作通過 K8S 标準擴充的方式開源出來，對原生 Workload 無法滿足的能力作了強有力的補充，解決應用的自動化，包括部署、更新、彈性擴縮容、Qos 調節、健康檢查、遷移修複等場景問題。
目前 OpenKruise 項目提供了一套 Controller 元件，其中的 UnitedDeployment 可以了解為 CAFEDeployment 的開源版本。除了基本的副本保持和釋出能力，他還包含了 CAFEDeployment 的主要功能之一，多部署單元的 Pod 釋出能力。 同時，由于UnitedDeployment 是基于多種類型的 workload（目前支援社群的 StatefulSet 和 OpenKruise AdvancedStatefulSet）實作對 Pod 的管理，是以它還能保留相應 Workload 的特性。
UnitedDeployment 的核心貢獻者吳珂(昊天) (Github:wu8685) 來自于 SOFAStack CAFE 團隊，主導了整個 CAFEDeployment 的設計與開發。目前我們正在努力把更多能力在經過大規模驗證之後，通過标準化的方式整合進開源版本中，逐漸減少兩個版本的差異，使之趨于統一。
展望與規劃
講到這裡，因為時間關系，圍繞一些細節的技術實作就先分享到這裡了。回顧一下前面關于 CAFEDeployment 關于整個釋出政策的内容介紹，我們産品設計的一個關鍵價值主張就是，能夠為應用和業務在擁抱新興技術架構的時候，提供一個穩妥演進的能力。無論是虛拟機為代表的經典運維體系，還是規模化容器部署的雲原生架構，都需要精細化的技術風險管控。同時，在宏觀上，又能往最先進的架構上演進。
實踐參考：某網際網路銀行容器應用傳遞演進路線
以某個網際網路銀行的容器化演進路線為例。在成立之初，就确定了以雲計算基礎設施之上建構微服務分布式體系。但從傳遞模式上看，一開始采用的還是基于經典虛拟機的 PaaS 管控模式，從 2014 年到 2017 年，業務都是通過 Buildpack 把應用包釋出到虛拟機上。這種運維模式雖然持續了三年，但是我們在這個過程中幫助完成了同城雙活、兩地三中心、到異地多活單元化的架構更新。
在 2018 年，随着 Kubernetes 的逐漸成熟，我們在底層基于實體機和 K8S 建構了底盤，同時，用容器模拟 VM，完成了整個基礎設施的容器化。但于此同時，業務并不感覺，我們通過實際在底層 K8S 之上的 Pod，以“富容器”的方式為上層應用提供服務。而從 2019 年到 2020 年，随着業務的發展，對于運維效率、擴充性、可遷移性、精細化管控的要求更是驅使着基礎設施往更加雲原生的運維體系演進，并逐漸落地 Service Mesh、Serverless、單元化聯邦叢集管控等能力。
雲原生單元化異地多活彈性架構
我們正在通過産品化、商業化的方式，把這些年來積累的能力開放出來，希望能夠支援到更多金融機構也能夠在網際網路金融業務場景下快速複制雲原生的架構能力并為業務創造價值。
大家可能在很多管道了解到螞蟻的單元化架構、異地多活的彈性和容災能力。這裡我給到大家一張圖，是我們目前在建設，且馬上在幾個月内在一家大型銀行作解決方案落地的架構抽象。在 PaaS 層面，我們在 K8S 上建設一層聯邦能力，我們希望每一個機房都有獨立的 K8S 群，因為一個 K8S 叢集直接進行跨機房、跨地域部署是不可行的，無法滿足容災需求。進而通過多雲聯邦的管控能力，這同樣需要我們 PaaS 層産品針對 Kubernetes 做一些擴充，定義邏輯單元，定義聯邦層資源等等，最終達成多機房多地域多叢集的單元化架構。結合之前分享中我們提到的，CAFEDeployment、ReleasePipeline，還有一些 Fedearation 層的聯邦對象，我們做了大量擴充，最終目的是在這些複雜的場景中為業務提供統一的釋出管控和容災應急能力。
SOFAStack CAFE 雲應用引擎
說到這裡，終于可以解釋下前面提了很多的 CAFE 是什麼意思了。CAFE, Cloud Application Fabric Engine 雲應用引擎，是螞蟻金服 SOFAStack 雲原生應用 PaaS 平台的名稱，不僅具備 Kubernetes 标準化的雲原生能力，更在上層把經過生産檢驗的應用管理、釋出部署、運維編排、監控分析、容災應急等金融級運維管控能力開放了出來。同時，與 SOFAStack 中間件、服務網格 Service Mesh、阿裡雲容器服務 ACK 做了深度內建。
CAFE 提供的關鍵差異化能力，是為應用生命周期管理提供具有技術風險防控保障（包括變更管控，容災應急能力），并随之提供可演進的單元化混合雲能力。是金融場景下落地分布式架構，雲原生架構，混合雲架構的關鍵底盤。
SOFAStack 金融分布式架構
最後一頁，其實才是今天真正的主題。今天所介紹的 CAFE，是 SOFAStack金融分布式架構産品中的一部分。目前 SOFAStack 已經在阿裡雲上商業化釋出了，大家可以來申請試用，并與我們作進一步的交流。大家可以通過搜尋引擎、本文提供的産品連結、
阿裡雲官網了解更多。
在【金融級分布式架構】微信公衆号背景回複“CAFE”，即可下載下傳完整PPT。