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

由螞蟻金服主辦的 SOFAStack Cloud Native Workshop 將在 6月24日於 KubeCon + CloudNativeCon + Open Source Summit China 大會的同場活動中進行，歡迎報名參與，更多資訊可點選“閱讀原文”進行檢視。 

歡迎加入 SOFA 釘釘互動群（釘釘搜尋群號）：23195297

本文作者：螞蟻金服 卿祤、 首仁

| 楔子

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

這是一系列技術分享文章的開端，基於在實際金融機構和場景中落地的雲原生產品專案經驗，我們希望和大家一起分享從中獲得的洞察和總結，探討產品觀點、技術實現，並非常期待大家的建議和指點，歡迎一起交流共創。

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

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

我們的觀點是，金融場景下的雲原生，絕對不止是 12Factors [3]，亦不止是 CNCF TOC 所定義的 5 大件 [4]，我們不僅要提供標準、透過一致性認證的 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版本，還不成熟，另外，我們定義的模型和涉及到的業務場景很複雜。這部分內容正在建設中，後續將繼續更新。

| 展望

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

文章涉及相關連結

[1] SOFAStack：

https://www.sofastack.tech/

[2] SOFABoot：

https://www.sofastack.tech/sofa-boot/docs/Home

[3] 12Factors：

https://12factor.net/zh_cn/

[4] 5 大件（CNCF 雲原生定義）：

https://github.com/cncf/toc/blob/master/DEFINITION.md
分享