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 數量的預期，默認情況下會提供滾動發佈或重建發佈能力。
這幅圖的下半部分，是圍繞 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。