Categories
程式開發

技術破局:如何實現分佈式架構與雲原生?


螞蟻金服SOFAStack產品專家俞仁傑,在螞蟻金服數字課堂直播間分享了雲原生應用PaaS平台的建設實踐,以下為演講整理全文:

大家好,歡迎來到螞蟻金服數字課堂直播間。今年2月,我們SOFAStack金融分佈式架構產品已經在阿里雲上完成了商業化發布,為了讓更多朋友了解到我們的產品的能力、定位以及背後的設計思路,​​後續我們會有一系列的直播分享。我們今天想分享給大家的話題叫 《雲原生應用PaaS平台的建設實踐》,主要會圍繞PaaS產品能力在一些需要穩妥創新的金融場景下的落地思路,並且能夠更好地與雲原生架構做好鏈接。

金融場景雲原生落地面臨挑戰

雲原生是業務快速變化背景下的必然技術趨勢

回顧IT的發展史,雲計算分類為IaaS PaaS 和 SaaS已經有十幾年了。而事實上,整個雲計算行業的發展,我們能夠明顯看到企業在落地雲計算戰略的時候經歷的三個階段,Cloud-Based, Cloud-Ready, Cloud-Native。這三個階段其實是因為業務的變化越來越敏捷,要求企業關注重心上移,把更多的精力和人才投入到業務邏輯的建設上,而把下層自已並不擅長並且越來越複雜的基礎設施、中間件逐漸交給雲計算廠商去實現,專業的人做專業的事。

這本質是社會分工的進一步細化,也符合人類社會發展的規律。在雲原生時代,業界所提出的容器技術,Service mesh技術,Serverless技術都是希望讓業務研發與基礎技術更加的解耦,讓業務創新和基礎技術創新都更容易的發生。

技術破局:如何實現分佈式架構與雲原生? 1

容器技術帶來的是一種應用交付模式的變革

雲原生就是業務快速變化背景下的必然技術趨勢。而這個趨勢背後的實質載體,就是我們所說的雲原生、Kubernetes以及以Docker為代表的容器技術,這些所帶來的,本質是一種應用交付模式的變革。而為了真正能夠使業界、社區所倡導的新興應用交付模式落地到實際的企業環境,我們需要一個以應用為中心的平台來進行承載,貫穿應用運維的各項生命週期。

圍繞“雲原生”這個關鍵詞,其實在社區和業界已經有了非常多的交流和資料,圍繞Docker/K8S的最佳實踐、DevOps CICD、容器網絡存儲設計、日誌監控對接優化等等等等,而我們今天的分享,主要想表達的是我們圍繞在K8S之上塑造一個PaaS平台的產品價值主張。 Kubernetes是一個非常好的編排和調度框架,它核心的貢獻是讓應用的編排和資源的調度更加的標準化,同時提供了一個高度可擴展的架構,方便上層進行各種控制器和調度器的定制。但是,它並不是一個PaaS。 PaaS底層可以基於Kubernetes去實現,但是在上層要補足非常多的能力才能真正把Kubernetes用於生產環境,特別是金融行業的生產環境。

金融場景需要“穩妥創新”

生產環境落地雲原生需要著重考慮哪些挑戰?

技術破局:如何實現分佈式架構與雲原生? 2

我們之前做過一些調研和客戶訪談。就現在2020年來說,絕大多數金融機構都展現出了對Kubernetes、容器等技術的極大興趣,有不少機構也已經在一些非關鍵的業務、或開發測試環境搭建了開源或商業版的集群。驅動力很簡單,金融機構非常希望這一整套新的交付模式幫助到業務飛速迭代。然而對比落差非常明顯的是,真正敢於在核心生產環境落地雲原生架構的,又少之又少。因為金融業務創新的前提,是要保障穩妥。

我們團隊在服務螞蟻內部業務、外部金融機構的過程中,總結了以上這幾個方面,事實上這六大方面也是我們內部SRE不斷挑戰的幾點。我們在今天以及未來的分享中,會逐步總結深化應對這些挑戰的產品思路。

K8S體系下的應用變更與發布管控

我們今天分享的一個核心內容,就是我們如何在產品層面做應用變更的風險保障的。並圍繞此話題向大家介紹變更“三板斧”的背景、K8S原生部署能力、我們產品圍繞變更需求做的擴展並向大家介紹我們在開源方面的規劃。

技術破局:如何實現分佈式架構與雲原生? 3

需求背景:變更“三板斧”

所謂“三板斧”就是可灰度、可監控、可應急。這是螞蟻內部運維的一條紅線準則,所有的變更,都必須要遵從這個規則,即使再細小的變更,再嚴密的測試,也不能忽略這條規則。為了滿足這個需求,我們在PaaS產品層設計了各種各樣的精細化發布策略,比如分組發布、beta發布,灰度發布,藍綠髮布等。這些發布策略跟我們在做傳統運維時用的手段是非常相似的,但很多使用容器的用戶認為在k8s裡實現會非常的困難。

有些時候,由於對業務連續性的極高要求,也很難接受原生K8S 模型標準化模式,比如原生deployment 做灰度或者金絲雀發佈時,默認情況下在Pod變更和流量治理層面的管控還稍顯不足,無法完全做到無損發布或按需過程管控。因此,我們在PaaS產品層面做了定制,在Kubernetes層面做了自定義資源的擴展,目的是能夠在雲原生的場景下,依然對整個發布過程實現精細化管控,使得大規模集群發布、灰度、回滾時更加優雅,符合技術風險三板斧原則。

技術破局:如何實現分佈式架構與雲原生? 4

Kubernetes原生髮布能力

我們先來回顧一下K8S的原生Deployment對象,及其背後的ReplicaSet,其實已經是在最近好幾個大版本中已經逐漸的穩定了。簡單的來說,最常見的K8S發布場景,我們會通過Deployment的對象,聲明出我希望的發布模式以及Pod Spec定義。在運行時,會有ReplicaSet對象來管理Pod數量的預期,默認情況下會提供滾動發布或重建發布能力。

技術破局:如何實現分佈式架構與雲原生? 5

這幅圖的下半部分,是圍繞Deployment作滾動發佈時的示意圖,這裡不再做過多的展開,它的本質根據用戶根據我們的運維需求設定好一定的步長,創建新的Pod ,銷毀舊的Pod,因此能做到整個應用版本的變更和發布過程中,都能有對應的容器對外提供服務。對大部分場景來說,它是夠用的,而且整個過程也是非常好的理解,事實上在K8S體系,大家除了Pod/Node,看的最多的就是Deployment了。

CafeDeployment:感知底層拓撲和領域模型

技術破局:如何實現分佈式架構與雲原生? 6

回顧完Deployment,我們可以再給大家看一下我們根據實際需求作的CRD擴展,CAFEDeployment。 CAFE是我們SOFAStack PaaS產品線的名稱,本文的最後會作一些介紹。

CafeDeployment有一個很重要的能力,就是能夠感知到底層拓撲,這個拓撲是什麼意思呢?能夠知道我想把我的Pod發佈到哪裡,哪邊的Node,不只是基於親和性的規則作綁定,而是真正能把高可用、容災、以及部署策略等場景息息相關的信息,帶到整個圍繞發布的領域模型中。對此,我們提出了一個叫部署單元的領域模型,他是一個邏輯概念,在yaml中簡單的叫做Cell。在實際使用中,Cell的背後,可以是不同的AZ不同的物理機房,不同的機架,一切都是圍繞著不同級別的高可用拓撲。

技術破局:如何實現分佈式架構與雲原生? 7

CafeDeployment:精細化分組發布擴容

感知到了底層拓撲,我們再看一下CafeD的典型發布過程。這也是後面會通過產品控制台和命令行來演示的內容。這幅圖所展現的過程,是一個精細化的分組發布,目的是能夠讓容器實例層面的變更,做到足夠的可控和灰度。每一個階段都能暫停、驗證、繼續或回滾。

以圖上這個例子進行說明,我們的目標是發布或變更10個Pod,且需要讓這10個Pod能夠均勻分佈在兩個可用區,確保在應用層面是高可用的。同時,在發布的過程,我們是需要引入分組發布的概念,即每個機房都要先僅僅發布一個實例,暫停驗證之後,再進行下一組的發布。於是第0組,就變成兩邊各1個實例,第1組各兩個,第2組則是剩下的2個。在實際的生產環境中,圍繞容器大規模變更會配合業務監控及更多維度的觀察,確保每一步都是符合預期、驗證通過的。這樣在應用實例層面的精細化管控,為運維提供了能夠及時剎車回滾的機會,是線上應用發布的一個重要的保險繩。

CafeDeployment:優雅摘流無損發布

講完整個精細化的發布,我們再講一個精細化的摘流。無損發布需要確保南北和東西向的網絡流量都能被優雅摘除,確保在容器停機、重啟、縮容的時候能夠對線上業務無感。

技術破局:如何實現分佈式架構與雲原生? 8

這張圖展示了一個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調節,健康檢查,遷移修復等場景問題。

技術破局:如何實現分佈式架構與雲原生? 9

當前OpenKruise項目提供了一套Controller組件,其中的UnitedDeployment 可以理解為CafeDeployment的開源版本。除了基本的副本保持和發布能力,他還包含了CafeDeployment的主要功能之一,多部署單元的Pod發布能力。同時,由於UnitedDeployment是基於多種類型的workload(目前支持社區的StatefulSet和OpenKruise AdvancedStatefulSet)實現對pod的管理,因此它還能保留相應Workload的特性。

UnitedDeployment 的核心貢獻者吳珂(昊天) (Github:wu8685) 來自於SOFAStack CAFE 團隊,主導了整個CafeDeployment的設計與開發。當前我們正在努力把更多能力在經過大規模驗證之後,通過標準化的方式整合進開源版本中,逐步減少兩個版本的差異,使之趨於統一。

展望與規劃

技術破局:如何實現分佈式架構與雲原生? 10

講到這裡,因為時間關係,圍繞一些細節的技術實現就先分享到這裡了。回顧一下前面關於CafeDeployment關於整個發布策略的內容介紹,我們產品設計的一個關鍵價值主張就是,能夠為應用和業務在擁抱新興技術架構的時候,提供一個穩妥演進的能力。無論是虛擬機為代表的經典運維體系,還是規模化容器部署的雲原生架構,都需要精細化的技術風險管控。同時,在宏觀上,又能往最先進的架構上演進。

實踐參考:某互聯網銀行容器應用交付演進路線

技術破局:如何實現分佈式架構與雲原生? 11

以某個互聯網銀行的容器化演進路線為例。在成立之初,就確定了以雲計算基礎設施之上構建微服務分佈式體系。但從交付模式上看,一開始採用的還是基於經典虛擬機的PaaS管控模式,從2014年到2017年,業務都是通過Buildpack把應用包發佈到虛擬機上。這種運維模式雖然持續了三年,但是我們在這個過程中幫助完成了同城雙活、兩地三中心、到異地多活單元化的架構升級。

在2018年,隨著Kubernetes的逐漸成熟,我們在底層基於物理機和k8s構建了底盤,同時,用容器模擬VM,完成了整個基礎設施的容器化。但於此同時,業務並不感知,我們通過實際在底層K8S之上的Pod,以“富容器”的方式為上層應用提供服務。而從2019年到2020年,隨著業務的發展,對於運維效率、擴展性、可遷移性、精細化管控的要求更是驅使著基礎設施往更加雲原生的運維體系演進,並逐漸落地Service Mesh、Serverless、單元化聯邦集群管控等能力。

雲原生單元化異地多活彈性架構

技術破局:如何實現分佈式架構與雲原生? 12

我們正在通過產品化、商業化的方式,把這些年來積累的能力開放出來,希望能夠支持到更多金融機構也能夠在互聯網金融業務場景下快速復制雲原生的架構能力並為業務創造價值。

大家可能在很多渠道了解到螞蟻的單元化架構、異地多活的彈性和容災能力。這裡我給到大家一張圖,是我們當前在建設,且馬上在幾個月內在一家大型銀行作解決方案落地的架構抽象。在PaaS層面,我們在K8S上建設一層聯邦能力,我們希望每一個機房都有獨立的K8S群,因為一個K8S集群直接進行跨機房、跨地域部署是不可行的,無法滿足容災需求。進而通過多雲聯邦的管控能力,這同樣需要我們PaaS層產品針對Kubernetes做一些擴展,定義邏輯單元,定義聯邦層資源等等,最終達成多機房多地域多集群的單元化架構。結合之前分享中我們提到的,CafeDeployment、ReleasePipeline,還有一些Fedearation層的聯邦對象,我們做了大量擴展,最終目的是在這些複雜的場景中為業務提供統一的發布管控和容災應急能力。

SOFAStack CAFE 雲應用引擎

技術破局:如何實現分佈式架構與雲原生? 13

說到這裡,終於可以解釋下前面提了很多的CAFE是什麼意思了。 CAFE, Cloud Application Fabric Engine 雲應用引擎,是螞蟻金服SOFAStack 雲原生應用PaaS平台的名稱,不僅具備Kubernetes標準化的雲原生能力,更在上層把經過生產檢驗的應用管理、發布部署、運維編排、監控分析、容災應急等金融級運維管控能力開放了出來。同時,與SOFAStack 中間件、服務網格ServiceMesh、阿里雲容器服務ACK 做了深度集成。

技術破局:如何實現分佈式架構與雲原生? 14

CAFE提供的關鍵差異化能力,是為應用生命週期管理提供具有技術風險防控保障(包括變更管控,容災應急能力),並隨之提供可演進的單元化混合雲能力。是金融場景下落地分佈式架構,雲原生架構,混合雲架構的關鍵底盤。

SOFAStack 金融分佈式架構

技術破局:如何實現分佈式架構與雲原生? 15

最後一頁,其實才是今天真正的主題。今天所介紹的CAFE,是 SOFAStack金融分佈式架構產品中的一部分。當前SOFAStack已經在阿里雲上商業化發布了,大家可以來申請試用,並與我們作進一步的交流。大家可以通過搜索引擎、本文提供的產品鏈接、阿里雲官網了解更多。

作者介紹

螞蟻金服SOFAStack產品專家俞仁傑

本文轉載自公眾號螞蟻金服科技(ID:Ant-Techfin)。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzI0Nzc3MTQyMw==&mid=2247490643&idx=1&sn=6a7be7803c8f27671dc0d139dfcc8c14&chksm=e9aba423dedc2d352f9cf07415b3fd62d33d54111d23c9ec6a87542e405ffd42efab7a80ed76&scene=27#wechat_redirect