技術破局：如何實現分佈式架構與雲原生？| 含 ppt 下載

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。