歡迎光臨
每天分享高質量文章

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

由螞蟻金服主辦的 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

已同步到看一看
赞(0)

分享創造快樂