雲原生架構總覽,發展定義架構及趨勢

語言: CN / TW / HK

本文已參與「新人創作禮」活動,一起開啟掘金創作之路。

隨著雲計算髮展的成熟和企業需求的推動,雲原生技術和理念得到了使用者的廣泛接受,雲原生應用場景不斷豐富,雲原生正在成為雲上的必然趨勢。


一、雲原生技術發展

• 2001年,VMware釋出了第一個針對x86伺服器的虛擬化產品ESXGSX,即ESX-i的前身。 • 2006年10月,以色列的創業公司Qumranet在完成了虛擬化Hypervisor基本功能、動態遷移以及主要的效能優化之後,正式對外宣佈了KVM的誕生。2009年4月, VMware推出業界首款雲作業系統VMware vSphere。 • 2006年,AWS推出首批雲產品Simple Storage Service (S3)Elastic Compute Cloud(EC2),使企業可以利用AWS的基礎設施構建自己的應用程式。 • 2010年7月,Rackspace HostingNASA聯合推出了一項名為OpenStack的開源雲軟體計劃。 • 2011年,Pivotal推出了開源版PaaS Cloud Foundry,作為Heroku PaaS的開源替代品,並於2014年底推出了Cloud Foundry Foundation。 • 2008年,LXC(Linux Container)容器釋出,這是一種核心虛擬化技術,可以提供輕量級的虛擬化,以便隔離程序和資源。LXCDocker最初使用的具體核心功能實現。 • 2013年,Docker釋出,組合LXCUnion File SystemcgroupsLinux技術建立容器化標準,docker風靡一時,container逐步替代VM,雲端計算進入容器時代。 • 2015年7月,Google聯合Linux基金會成立了CNCF組織,kubernetes成為CNCF 管理的首個開源專案。 • 2018年3月,KubernetesCNCF畢業,成為CNCF第一個畢業專案。

在這裡插入圖片描述

據《中國雲原生使用者調查報告2020》顯示,2019年中國雲原生市場規模約為350.2億元,雲原生技術加速向垂直行業滲透。

資料顯示,43.9%的使用者已在生產環境中採納容器技術,超過七成的使用者已經或計劃使用微服務架構進行業務開發部署。現階段已有9%的使用者雲原生相關投入已佔總IT投入的一半以上,技術研發、運維是企業主要支出部分。


二、雲原生的定義

1、Pivotal早期觀點 ①Pivotal公司的Matt Stine 於2013年首次提出雲原生的概念,並推出了Pivotal Cloud Foundry和Spring系列開發框架,是雲原生的探路者。 ②2015年,雲原生剛推廣時,Matt Stine在 《遷移到雲原生架構》——書中定義了符合雲原生架構的幾個特徵:

  • 符合12因素應用(12 Factors Application)
  • 面向微服務架構(Microservices)
  • 自服務敏捷整合設施(Self Service Agile Infrastructure)
  • 基於API的協作(API-Based Collaboration)
  • 抗脆弱性(Antifragility)

2、Pivotal當前論述

  • 雲原生是一種構建和執行應用程式的方法,它利用了雲端計算交付模型的優勢;
  • 雲原生關注如何建立和部署應用程式,而不是在何處;
  • 雖然現在公有云影響了幾乎每個行業的基礎設施投資思想,但類似雲的交付模式並不僅限於公有云環境,它適用於公有云和私有云;
  • 雲原生結合了DevOps、持續交付、微服務和容器的概念;
  • 當公司以雲原生方式構建和運營應用程式時,它們可以更快地將新想法推向市場並更快地響應客戶需求;

3、CNCF早期觀點 ①雲原生計算基金會(以下簡稱CNCF)是一個開源軟體基金會,成立於2015年7月, 致力於雲原生(Cloud Native)技術的普及和可持續發展。 ②起初,CNCF對雲原生的定義包含以下三個方面:

  • 應用容器化(Software stack to be Containerized)
  • 口面向微服務架構(Microservices Oriented)
  • 應用支援容器的編排排程(Dynamically Orchestrated)

③到2018年,隨著社群對雲原生理念的廣泛認可和雲原生生態的不斷擴大,還有CNCF專案和會員的大量增加,起初的定義已經不再適用。

4、CNCF當前定義 雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中,構建和執行可彈性擴充套件的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和宣告式API。

在這裡插入圖片描述 5、雲原生理念 ①利用容器和服務網格等技術,解耦軟體開發,提高了業務開發部署的靈活性和 易維護性。 ②以Kubernetes為核心的多層次、豐富的開源軟體棧,被各大廠商支援,使用者選 擇多,避免廠商繫結。 ③以Kubernetes為核心的松耦合平臺架構,易擴充套件,避免侵入式定製 Kubernetes 已被公認是platform for platform。 ③中心式編排,對應用和微服務進行統一的動態管理和排程,提高工作效率和資 源利用率。

6、雲原生技術版圖

在這裡插入圖片描述

7、容器技術——提高應用可移植性,提升業務敏捷 ①容器可以將應用本身及其依賴打包,使得應用可以實現“一次封裝,到處執行”。 ②容器也可以理解成-種沙盒技術,沙盒在電腦保安領域中是-種安全機制,為運 行中的程式提供的隔離環境。

主流的容器技術,如Docker,它是通過核心虛擬化技術(namespace以及cgroups 等)來提供容器的資源隔離與安全保障。由於Docker通過作業系統層的虛擬化實現隔離,所以Docker容器在執行時,不需要類似虛擬機器額外的作業系統開銷,提高資源利用率。同時,Docker能夠幫助你快速地測試、快速地編碼、快速地交付,並且縮短從編碼到執行應用的週期,從而使得企業實現業務敏捷。

8、微服務——加速企業應用架構升級 在CNCF的定義中,微服務也是作為一種代表性的技術,而實際上,微服務更側重於描述軟體架構,這種軟體架構相比單體架構,更加能夠發揮雲原生相關的技術優勢。

微服務是一種用於構建應用的架構方案,它是鬆散耦合的分散式架構框架,因此一個團隊的更改不會破壞整個應用。使用微服務的好處是,開發團隊能夠快速構建應用的新元件,以滿足不斷變化的業務需求。微服務架構有別於更為傳統的單體式方案,可將應用拆分成多個核心功能。每個功能都被稱為一項服務,可以單獨構建和部署,這意味著各項服務在工作(和出現故障)時不會相互影響。比如你線上購物時,使用搜索欄來找產品,這個搜尋功能就是一項服務,同時你也看到了相關產品推薦,這些推薦也是來自於另外一項服務,還有購物車等,都是一項一項的服務。

9、DevOps——促進開發運維一體化

在這裡插入圖片描述 DevOps=開發(Development)+運維(Operations),是打通開發與運維之間的壁 壘,促進開發、運營和質量保障(QA)等部門之間的溝通協作,以便對產品進行小 規模、快速迭代式地開發和部署,快速響應客戶的需求變化。它強調的是開發運維一體化,加強團隊間的溝通和快速反饋,達到快速交付產品和提高交付質量的目的。

10、雲原生能力已獲廣泛認可,加速企業向‘新雲原生企業”轉型 在這裡插入圖片描述 從技術維度來看, 容器在效能、彈性伸縮方面得到廣泛認可,容器和微服務對應用現代化、改進DevOps運作模式都取得廣泛認可,另外雲原生技術提高架構開放性,更符合市場技術趨勢,在業務價值方面,微服務的平臺化複用提升創新敏捷性得到86%調研人員認可,容器化可以提升資產利用率降本增效、更好的彈性伸縮, 容器標準映象封裝和CI/CD結合可以更快交付應用,雲原生技術對人工智慧、大資料等新興技術框架的支撐,加速業務創新都得到80%以上使用者認可。 總體上來說雲原生應用價值已獲得調研使用者廣泛認可, 以應用為中心的雲原生模式正在加速企業數字化程序,加速企業向“新雲原生企業”轉型。


三、雲原生應用

“雲原生應用程式是專為雲模型構建的。這些應用程式由小型專用功能團隊快速構建和部署到一個平臺,可提供輕鬆的橫向擴充套件和硬體解耦-為組織提供跨雲環境的更高靈活性,彈性和可移植性。”——Pivotal

“雲原生應用是獨立的小規模鬆散耦合服務的集合,旨在提供備受認可的業務價值,例如快速融合使用者反饋以實現持續改進。簡而言之,通過雲原生應用開發,可以加速構建新應用,優化現有應用並將這些應用全部組合在一起。其目標是以企業需要的速度滿足應用使用者的需求。”——RedHat

雲原生應用綜合理解: ①基於雲原生的相關技術,設計執行在雲上的,充分發揮雲優勢的應用。 ②一般採用容器的打包、分發、部署的形式,應用內(間)採用微服務的架構,充分利用雲提供的元件服務,採用DevOps的組織架構和方法,通過CI/CD工具鏈,實現產品和服務的持續交付。 在這裡插入圖片描述

傳統應用與雲原生應用的區別:

在這裡插入圖片描述

雲原生應用12要素:

  • 第一,基準程式碼。一份程式碼庫對應多份部署,所有部署的基準程式碼相同,但每份部署可以使用不同的版本。
  • 第二,依賴。顯式宣告依賴關係,通過依賴清單確切的宣告所有依賴項,這一做法會統一應用到生產和開發環境。
  • 第三,配置。 在環境中儲存配置,推薦將應用的配置儲存於環境變數中,環境變數可以非常方便地在不同的部署間做修改,卻不動一行程式碼。與配置檔案不同,不小心把它們遷入程式碼庫的概率微乎其微,與一些傳統的解決配置問題的機制,比如Java的屬性配置檔案相比,環境變數、語言和統計無關。
  • 第四,後端服務。把後端服務當作附加資源,每個不同的後端服務是一份資源,例如一個mysql資料庫是一個資源,兩個mysql資料庫被當做兩個不同的資源,雲原生應用將這些資料庫都視作附加資源,這些資源和他們附屬的部署保持松耦合。
  • 第五,構建釋出運行雲原生應用,需嚴格區分構建、釋出、執行這三個步驟。舉例來說,直接修改處於執行狀態的程式碼是非常不可取的做法,因為這些修改很難再同步回構建步驟。
  • 第六,程序。以一個或多個無狀態程序執行應用,在執行環境中,應用程式通常是以一個或多個程序執行的。
  • 第七,埠繫結。通過埠繫結來提供服務。
  • 第八,併發。通過程序模型進行擴充套件,在 12-factor 應用中,程序是一等公民。12-Factor應用的程序主要借鑑於unix守護程序模型 。開發人員可以運用這個模型去設計應用架構,將不同的工作分配給不同的程序型別。例如,HTTP請求可以交給 web 程序來處理,而常駐的後臺工作則交由 worker 程序負責。
  • 第九,易處理。快速啟動和優雅終止和最大化健壯性,這有利於快速彈性的伸縮應 用、迅速部署變化的程式碼或配置檔案的部署應用。
  • 第十,開發環境與線上環境等價,儘可能的保持開發預釋出線上環境相同。
  • 第十一 ,日誌。 把日誌當做事件流,日誌應該是事件流的彙總,將所有執行中的程序和後端服務的輸出流,按照時間順序收集起來。
  • 第十二,管理程序。後臺管理任務當做一次性程序執行,一次性管理程序應該和正常的常駐程序使用同樣的環境,這些管理程序和任何其他的程序一樣,使用相同的程式碼和配置,基於某個釋出版本執行,後臺管理程式碼應該隨其他應用程式程式碼一起釋出,從而避免同步問題。

四、雲原生架構原則及常用模式

在這裡插入圖片描述 彈性:微服務採用無狀態設計,支援按需使用、自動水平伸縮;例項快速啟動,並在不影響業務的前提下優雅中止。這一點可以充分利用雲的彈性的特徵,利用雲環境提供的映象、監控、資源動態編排和排程服務。設計應用程式時,不繫結特定基礎資源,使其能夠自由伸展,根據需要增刪例項。

分散式:更多強調解耦。應用側,則是業務邏輯和資料解耦、業務邏輯和會話解耦。資料分散式,每個服務擁有自己的資料庫,服務不能直接訪問其他服務的資料庫,只能通過服務介面訪問其他服務的資料。

高可用,高可用的概念範疇比較廣,雲原生應用的設計特徵,Design For Failure,即“為失敗而設計”,這裡主要強調基於不可靠的基礎設施資源來設計高可用系統,並且在應用例項失效的情況下,系統能快速發現並恢復。高可用的設計的主要原則有可觀測、可灰度、可回滾等。實現的方式有很多種,比如,通過k8s實現POD狀態的監測和維護,通過灰度釋出、藍綠部署等手段來保證升級、回滾時系統的高可用。

自動化:業務/服務的顆粒度更小,交付部署更頻繁,迫切需要系統能夠自動化部署,同時要增強對服務以及所部署的軟硬體環境的全方位監控、評估能力。

自服務:自服務強調服務可被其他應用或開發者自助發現,自助按需獲取,自助使用並計量,自助服務管理。自服務的前提是高度自治,同時,從易用性的角度,暴露友好的互動方式(Web介面、命令列、SDK…),使能應用開發者簡單、高效地使用其提供的功能。

1、雲原生架構模式:微服務架構

在這裡插入圖片描述 微服務架構就是其中一種實現方式。它實現了服務徹底拆分,各服務可以獨立打包、獨立部署和獨立升級,對開發者而言,擺脫開發語言的束縛。每個微服務負責的業務比較清晰,利於後期擴充套件和維護。微服務之間可以採用REST和RPC協議進行通訊。同時,微服務架構可以和其他雲原生技術完美結合,充分發揮雲的優勢。

2、雲原生架構模式:Serverless架構 Serverless (無伺服器架構)指的是由開發者實現的服務端邏輯執行在無狀態的計算容器中,它由事件觸發,完全被第三方管理,Serverless是 在傳統容器技術和服務網格上發展起來,更側重讓使用者只關注自己的業務邏輯即可。 在這裡插入圖片描述

3、Serverless與微服務的關係:微服務向Serverless演進,並長期共存

在這裡插入圖片描述 Serverless與微服務同屬服務化架構,二者在架構特徵上有很多相似之處,比如:都追求基礎設施的高可用、高容錯,應用的快速彈性,快速釋出,更好的運維可觀測性等。但作為新一代應用架構,Serverless化的變化在於:更快的彈性(毫秒級)、更快的釋出(分鐘級)、更簡化的運維(NoOps)、更細粒度的資源排程(函式級,可以是幾十行)。


五、雲原生未來發展趨勢

①Kubernetes編排統一化,編排物件不斷擴充套件延伸

  • Kubernetes 的編排物件持續豐富不斷擴充套件,以容器為基礎編排物件逐漸延展至虛擬機器、函式等,理論上所有可程式設計、有API、可抽象成資源的物件,都在成為 Kubernetes 的編排物件。
  • 應用側圍繞Kubernetes生態加速演進,以Kubernetes為核心的雲原生技術棧將推廣到更多的應用場景。在大資料領域,Spark和Kubernetes的整合已經非常普遍;機器學習方面,Kubernetes和Tensorflow等深度學習的框架深度整合,用Kubernetes去編排機器學習的工作流以取得業界的廣泛共識。

②服務治理Mesh化,加速傳統應用轉型

  • 傳統應用架構中業務和功能耦合度較高,無法充分發揮雲的效能。
  • 傳統應用中用於治理服務的中介軟體服務通常與應用強繫結部署,治理能力被植入每個應用,重複造輪子現象嚴重。Mesh化加速業務邏輯與非業務邏輯的解耦。將非業務功能從客戶端SDK中分離出來放入獨立程序,利用Pod中容器共享資源的特性,實現使用者無感知的治理接管。
  • 服務治理的 Mesh 化為傳統應用輕量化改造提供了前提,也為雲平臺沉澱通用服務治理能力,加速中介軟體下沉為基礎設施提供了可能

③應用服務Serverless化,更加聚焦業務的核心價值 Serverless將進一步釋放雲端計算的能力,將安全、可靠、可伸縮等需求交由基礎設施實現,使使用者僅需關注業務邏輯而無需關注具體部署和執行,極大地提高應用開發效率。同時這個方式促進了社會分工協作,雲廠商可以進一步通過規模化、集約化實現計算成本大幅優化。

④雲原生服務部署形態多元化,多雲將成為主流 儘管上雲已是大勢所趨, 但對於企業客戶而言, 有些業務出於對資料主權、安全隱私的考量,會採用混合雲架構。一些企業為了滿足安全合規、成本優化、提升地域覆蓋性等需求,會選擇多個雲廠商。