金融級雲原生探索實踐系列 - 開篇

由螞蟻金服主辦的 SOFAStack Cloud Native Workshop 將在 6月24日於 KubeCon + CloudNativeCon + Open Source Summit China 大會的同場活動中進行，歡迎報名參與，更多信息可見此 連接 。
歡迎加入 SOFA 釘釘互動羣（釘釘搜索羣號）：23195297

楔子

爲支撐業務高速發展並積極擁抱主流技術，咱們從 2017 年開始探索並構建以Kubernetes爲核心的雲原生應用 PaaS 平臺。在 2018 年，咱們已在網商銀行順利落地了 K8S 容器引擎，並順利支撐了 2018 年雙十一。2019 年伊始，國泰產險做爲互金行業的典型表明，正基於 SOFAStack 容器應用服務和監控分析產品探索雲原生架構轉型。時至今日，已完成了關鍵業務 SOFABoot 應用的容器化改造，在開發、測試乃至灰度生產環境踐行雲原生的運維實踐。

這將是一系列技術分享文章的開端，基於在實際金融機構和場景中落地的雲原生產品項目經驗，咱們但願和你們一塊兒分享從中得到的洞察和總結，探討咱們的產品觀點、技術實現，並不是常期待你們的建議和指點，歡迎一塊兒交流共創。

雲原生容器產品的金融機構落地挑戰

從去年開始，雲原生、Kubernetes、容器這些關鍵字逐漸從社區走向金融科技圈，愈來愈多的金融機構客戶開始向咱們諮詢，雲原生技術是什麼，可以給企業帶來什麼價值，對現有業務有什麼影響？落地的路徑可能會是哪些？

咱們的觀點是，金融場景下的雲原生，絕對不止是 12Factors，亦不止是 CNCF TOC 所定義的 5 大件，咱們不只要提供標準、經過一致性認證的 Kubernetes 產品，還須要知足更多金融場景需求，創造實際業務價值。

通過很長一段時間的產品研發實踐、深挖內外容器平臺落地訴求，金融客戶的關注點可能包括但不限於如下幾點：

• 業務採用了雲原生可否節省資源，提高工程效率？
• 發現問題後如何作到快速止損，甚至線上零故障？
• 如何在雲原生下作到業務同城雙活甚至異地多活的高可用容災能力？
• 可否和現有業務能無縫集成，如何作平滑升級？
• 採用了雲原平生臺可否保證和現有云上一致的安全性？
• 雲原生可否支撐大規模分佈式系統的架構？
• ...

而基於以上實際場景下的落地挑戰，咱們對自身容器平臺產品的設計和實施，提出瞭如下六大關鍵價值主張：

雲原生容器產品的價值主張

一 使用 Immutable Infrastructure 的思想進行設計

在 PaaS 平臺中，核心是應用。在以前的經典運維體系中，要對應用打一個全量快照不是件容易的事情，但在雲原生世界中，會方便許多。從描述流量接入層的 Service 到描述應用配置和代碼包的 Pod template，這些已經是 kubernetes 的標準 Resources。

爲了解決應用管理需求，咱們定義了一個 CafeAppService 對象，用於總體描述上述內容，並經過 Revision 對象屬性做版本控制（和 Knative 中的 Revision 相似）。用戶每次的修改都是一個 Revision，發佈一個應用本質上是發佈該應用的一個 Revision，故可作到快速的彈性擴縮容，而且能夠方便回滾到以前發佈成功過的 Revision。相比以前基於包的經典發佈運維體系，效率有極大提高。

圖一 容器應用服務與版本

二 可審計和無損應用發佈的能力

發佈變動是 PaaS 平臺提供的重要能力。對於金融客戶來講，每次發佈必需要有據可查，並且要保證安全無損。這裏，咱們將螞蟻的安全生產理念融入其中，在產品層面上提供「可灰度，可回滾（應急），可監控」的能力。

爲了作到上述能力，咱們提供了發佈單的概念，並定義了一個原生的 CRD：CafeDeployment。接下來逐一介紹。

發佈單

主要兩個用途：作應用發佈的審查記錄，用於統計分析，故障覆盤回顧等；協調多個應用的發佈順序，這是因爲金融業務對系統的可靠性要求高，尤爲在涉及資金的主鏈路，另外，很多系統因爲業務緣由，存在依賴關係，必須作有序發佈。

CafeDeployment

在這裏只作簡單介紹，後續會有專題介紹。該 CRD 擁有三種能力：

• 原地升級（InplaceSet）：升級過程當中 Pod 的 IP 保持不變，可和經典的運維監控體系作無縫集成。
• 替換升級（ReplicaSet）：和社區版本的 ReplicaSet 能力保持一致。
• 有狀態應用（StatefulSet）：和社區版本的 StatefulSet 能力保持一致。

除此以外，相比社區的 deployment，還具有 beta 驗證，自定義分組策略，分組暫停，引流驗證（配合 ServiceMesh）的能力。

圖二 CafeDeployment 圖示

三 具備高可用容災能力的工做負載

金融業因爲監管的要求對系統可用性和容災能力具備很高的要求。從應用的生命週期來看，最主要有兩個狀態：發佈態 和 運行態。

對於發佈態，因爲存在 Pod 上下線的過程，線上有抖動不可避免，要作的是儘量的下降抖動幅度以及下降系統報錯率。kubernetes 的 deployment 在發佈一個 pod 時，pod 裏容器的 kill 和對應 endpoint 的銷燬是異步的，這就意味着可能出現 pod 裏應用容器已經 kill 了，但仍然會有流量打到該 Pod，致使出現報錯，甚至故障。爲了防止這種狀況，咱們採用 finalizer 的機制，保證在南北流量和東西流量（7 層協議）都切斷的狀況下才對 Pod 進行更新。

同時，還經過 CafeDeployment 裏的灰度發佈策略，保證發佈態時線上系統的水位不會太低，防止出現流量過載，形成系統異常。

對於運行態，要考慮如下幾個方面：Pod 異常退出後的從新上線，Node 故障後的 Pod 的遷移，機房級故障後系統仍然可用。對於第一點，Kubernetes 自己已經有了較好的機制；第二點，咱們作了加強，使用自定義的 NodeLifecycle Controller 結合更加詳細的監控信息來判斷Node是否出現故障，而後作 Pod 遷移；第三點，從 Scheduler 方面進行保障，CafeDeployment 能夠定義相應的高可用拓撲結構，以同城雙活爲例，在建立 Pod 時，調度器會根據定義好的拓撲信息儘可能將 Pod 均分到不一樣的可用區，達到同城雙活的狀態。

四 一致的驗證受權體驗

螞蟻金服 PaaS 平臺在近 4 年的時間裏，已經有了一套完整的 IAM 體系，而且許多客戶已經基於此定義了許多的角色，用作安全防禦。咱們從兩方面來提供一致性的體驗：

首先，在產品上的操做上提供和原先同樣的驗證受權機制。只要客戶將 K8S 內預先定義好的角色或者權限分配相應的用戶或用戶組，那該用戶或者屬於該用戶組的用戶就能在產品上作相應的操做。

其次，IAM 的權限和角色與 Kubernetes 的 RBAC 作映射。根據用戶在 IAM 所具有的角色，在 Kubernetes 集羣中建立相應的 ClusterRole，並生成訪問 Kubernetes 集羣的 token，建立 ClusterRoleBinding 與 token 綁定。這樣用戶使用 kubectl 操做集羣時也能夠具有相同的權限，保證權限的一致性。

五 經典到雲原生的過渡能力

目前互金行業的應用的運行時絕大部分仍然以虛擬機爲主，而且以傳統的應用包方式進行部署和平常升級運維。對於向雲原生的轉型必定不是一蹴而就的，會有過渡期，在這段時間內，就面臨着須要同時在經典與雲原生下兩種模式下同時作運維管理。

針對這種場景，APaaS 平臺提供如下能力幫助客戶解決痛點。

第一，支持經典與雲原生的互訪，拉齊兩種模式的基礎網絡、應用層流量和接入層流量。在基礎網絡層面，採用VPC Router 或者 ENI 方式，在幾乎沒有額外網絡開銷的前提下保證虛擬機和 Pod 能夠互通；在應用層，虛擬機和Pod可使用同一套中間件作服務註冊與發現，而且能夠相互調用；在接入層，虛擬機可經過 loadbalancer 類型的 Service 訪問後端的 Pod，甚至不在 VPC 內的 on permise 應用也可經過公網類型 loadbalancer Service 訪問到 Pod。

圖三 經典與雲原生的互訪

第二，提供兩種模式的混合發佈能力。能夠同時對經典虛擬機模式和雲原生模式的應用進行發佈運維，保持體驗一致性。

第三，採用原地升級方式（InplaceSet）進行發佈的雲原生應用可和經典監控系統無縫對接，接入原有的監控與報警體系。直到全部應用作完雲原生改造後，再遷移到雲原生生態中主流的 metrics 監控體系。

六 支撐跨集羣發佈運維的能力

這是一個高階話題，須要結合具體的業務場景來看。從實踐經驗來看，這會是一個架構演進路線：一開始採用一個集羣管理多個可用區，在碰到容量瓶頸或者須要異地多活場景時，再開始考慮進行集羣劃分，採用多集羣方式。以網商銀行的業務爲例，首先採起同城雙活，而後到兩地三中心，最後演進到如今的異地多活單元化架構。

在雲原生架構下，咱們須要解決兩個問題。

第一，在架構演進過程當中，如何保證上層接入產品少感知甚至不感知集羣數量的變化。這類上層產品（好比發佈運維、資源管理等），咱們稱爲一方產品，一般具備「上帝」視角，須要獲取到集羣中的全部資源信息，當集羣從一個演進到多個後，還須要可以分別出資源屬於不一樣的集羣，並做出相應的處理。咱們從如下方面解決該問題。

• 定義一個模型來標明資源所屬的集羣，而且該模型須要和現有模型創建聯繫，以便集羣擴展後作準確路由。
• 提供一個統一接入層來路由對不一樣集羣的訪問。
• 一方產品使用該模型和統一接入層來訪問集羣。

第二，在演進到多集羣以後，如何提供跨集羣資源的統一視圖。這點參考社區 Federation 對象的設計，須要將不一樣集羣裏的資源狀態進行同步，之說以沒有直接採起社區 Federation 方案，首先社區這塊目前仍是 Alpha 版本，還不成熟，另外，咱們定義的模型和涉及到的業務場景很複雜。這部份內容正在建設中，後續將繼續更新。

展望

金融級雲原生之路纔剛剛開始，將沉澱多年的技術積累與雲原生緊密結合並開放給整個行業，是一個持續探索的過程。本文僅作是一個概覽性介紹，其中的每一塊內容均可做爲一個專題來深度講述，後面會持續更新，和你們分享咱們最佳實踐，歡迎關注。

關於咱們

隨着螞蟻金融科技開放戰略和國際化的業務背景，時至今日螞蟻金服 SOFAStack 已經服務了許多家國內外金融機構做分佈式架構技術轉型升級，過程當中也逐漸打磨和豐富了大規模運維監控產品體系，即金融分佈式架構-雲應用引擎(SOFAStack-CAFE, Scalable Open Financial Architecture - Cloud Application Fabric Engine)，其中容器應用服務(AKS, Application Kubernetes Service) 則是基於 K8S 打造的核心容器服務產品，致力於知足機房級高可用、安全、彈性、可觀測性、發佈變動管控策略等方面的要求，併力求下降複雜新興技術帶來的門檻和應用風險。

最後打個廣告，歡迎加入 SOFAStack 產品研發團隊，共建金融級雲原生產品！目前產品經理、架構師 、先後端研發和質量等多個崗位開放招聘中，簡歷請投遞：ranger.yrj@antfin.com 。

公衆號：金融級分佈式架構（Antfin_SOFA）