鋪天蓋地的「雲原生」究竟是什麼?

SOFAStack發表於2021-11-09


?

文|togettoyou

目前主要負責雲原生服務管理平臺的研發

日常致力於 Go 、雲原生領域

本文 3164 字 閱讀 5 分鐘

雲原生似乎已經是一個老生常談的概念了,相關的文章層出不窮。

本人現在工作中負責雲原生服務管理平臺的研發(主要管理各類雲原生基礎設施,平臺服務和第三方託管應用),但即便如此,常被問起雲原生是什麼時,我也很難簡潔的向人表述清楚,導致自我也經常問一遍,雲原生究竟是什麼,我又在做什麼。

PART. 1 雲原生究竟是什麼

雲原生是一個組合詞,即 Cloud Native

Pivotal(已被 VMware 收購)官網的 What is cloud native?[1] 一文中提到雲原生是一種構建和執行應用程式的方法,雲原生開發融合了 DevOps、持續交付、微服務和容器的概念在裡面

CNCF(雲原生計算基金會)在 cncf/toc[2] 給出了雲原生 V1.0 的定義:

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

這些技術能夠構建容錯性好、易於管理和便於觀察的鬆耦合系統。結合可靠的自動化手段,雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更。

雲原生計算基金會(CNCF)致力於培育和維護一個廠商中立的開源生態系統,來推廣雲原生技術。我們通過將最前沿的模式民主化,讓這些創新為大眾所用。

結合官方的定義,我個人對雲原生簡潔的理解就是:雲原生並不是某種具體技術,而是一類思想的集合,用來幫助快速構建和執行應用程式,其中既涵蓋著一整套技術體系(容器、服務網格、微服務、不可變基礎設施和宣告式 API),也包含著應用開發的管理要點(DevOps、持續交付、康威定律[3]),只要符合這類思想的應用就可以稱為雲原生應用。

圖片

PART. 2 雲原生技術體系

雲原生的一整套技術體系其實是緊密聯絡的,這得從軟體架構的逐步演進說起。

即 :單體 -> 微服務 -> 基於 K8s 上的微服務 -> 服務網格

單體架構,將所有的功能整合在一個工程裡,專案發展早期,應用的開發相對簡單,即使需要對應用進行大規模更改、測試、部署也很容易,甚至是橫向擴充套件。執行多個例項後,一個負載均衡器就可以搞定。

隨著時間推移,一個成功的應用必然變得越來越臃腫,程式碼庫隨之膨脹,團隊管理成本不斷提高,即俗話說的陷入單體地獄。面對單體地獄,開發者難以理解程式碼全部,開發速度變緩慢,部署週期變長,而且橫向擴充套件也會遇到挑戰,因為應用不同模組對資源的需求是互相沖突的,有些可能需要的是更大記憶體,有些可能需要的是高效能 CPU,作為單體應用,就必須都滿足這些需求。

當出現一個問題,自然會有針對該問題的解決方案,雲原生技術體系之一的微服務架構就是針對單體地獄的解決方案。既然單體應用是將全部功能都整合在一個工程裡去編譯部署,那現在只要把各個功能拆分出來(通常是根據業務能力或者根據子域分解,子域圍繞 DDD 來組織服務),將每個拆分的模組作為一個單獨的服務,獨立部署(服務之間通常通過 REST+JSONgRPC+ProtoBuf 進行通訊),使這一個個的服務共同提供整個應用的功能。

但微服務也不是銀彈,引入微服務架構後,分散式系統也帶來了各種複雜性。諸如配置中心、服務發現、閘道器、負載均衡等業務無關的基礎設施層面都需要開發者自行在業務層面實現。

比如一個常見的微服務架構解決方案(圖源鳳凰架構[4]),就需要開發者自行引入各種元件:

圖片

專案開發完成後終歸要到部署流程的,早期的傳統做法是把應用程式直接部署到伺服器上,但伺服器的系統、環境變數等是會不斷變化的,甚至安裝了新的應用,就會引起和其他應用的衝突,導致應用本身需要跟著使用者系統環境的改變而做出改變。為了解決這個問題,不可變基礎設施的口號就喊響了。

  • 第一階段是將服務部署為虛擬機器,將作為虛擬機器映象打包的服務部署到生產環境中,每一個服務例項都是一個虛擬機器。
  • 第二階段,為了減少開銷,將服務部署為容器,作為容器映象打包的服務部署到生產環境中,這樣每一個服務例項都是一個容器。

不可變基礎設施:

任何基礎設施的例項一旦建立之後變為只讀狀態,如需要修改或升級,需要使用新的例項替換舊的。容器映象就是一種不可變基礎設施的具體實現。

現在容器已然成為了微服務的好搭檔,服務例項隔離,資源也可以方便控制,但成千上百的容器,管理起來過於麻煩。於是,容器編排工具又出來了,Kubernetes 目前基本統一了容器編排的市場,實現了容器叢集的自動化部署、擴縮容和維護等功能。但 Kubernetes 可不只侷限於容器編排,上文的微服務架構中,需要開發者自行在應用層面解決業務無關的基礎設施層面的一系列問題,現在 Kubernetes 就可以解決大部分,如圖(圖源鳳凰架構[5]):

圖片

Kubernetes 的編碼方式其實就是一種宣告式 API(指通過向工具描述自己想要讓事物達到的目標狀態,然後由這個工具內部去計算如何令這個事物達到目標狀態)。

目前為止,我已經提到了雲原生技術體系中容器、服務網格、微服務、不可變基礎設施和宣告式 API 裡面的四種了,還有一個服務網格

一步步發展下來,都是為了把業務和基礎設施解耦 ,讓開發者可以快速開發自己的業務,無需關心底層基礎設施。服務網格也是想幹這事的,希望將更多業務無關的功能下沉到基礎設施,號稱微服務 2.0 。

服務網格核心在於將客戶端 SDK 剝離,以 Proxy 元件方式獨立程式執行,每個服務都額外部署這個 Proxy 元件,所有出站入站的流量都通過該元件進行處理和轉發,這個元件被稱為 Sidecar(邊車應用)。

Sidecar 只負責網路通訊,還需要有個元件來統一管理所有 Sidecar 的配置。在服務網格中,負責配置管理的部分叫控制平面(control plane),負責網路通訊的部分叫資料平面(data plane)。資料平面和控制平面一起構成了服務網格的基本架構。

圖片

聽說再更進一步就是無服務(Serverless)了。

「雲原生管理要點」

DevOps(Development 和 Operations 的組合詞)是一組過程、方法與系統的統稱,用於促進開發(應用程式/軟體工程)、技術運營和質量保障(QA)部門之間的溝通、協作與整合。

——百度百科

DevOps 的兩個核心理念是 CI(持續整合)和 CD(持續交付/部署)。

「結 尾」

感謝閱讀到這裡,本文較為粗糙的描述了雲原生作為一種思想,其技術體系之間的聯絡,如果有誤歡迎探討和指正!

「參考資料」

[1] What is cloud native?:

https://tanzu.vmware.com/cloud-native

[2 ] cncf/toc:

https://github.com/cncf/toc/blob/main/DEFINITION.md

[3] 康威定律:

https://zh.wikipedia.org/zhmy/%E5%BA%B7%E5%A8%81%E5%AE%9A%E5%BE%8B

[4] 鳳凰架構:

http://icyfenix.cn/exploration/projects/microservice_arch_springcloud.html

[5] 鳳凰架構:

http://icyfenix.cn/exploration/projects/microservice_arch_kubernetes.html

本週推薦閱讀

如何在生產環境排查 Rust 記憶體佔用過高問題

新一代日誌型系統在 SOFAJRaft 中的應用

終於!SOFATracer 完成了它的鏈路視覺化之旅

螞蟻集團技術風險程式碼化平臺實踐(MaaS)

圖片

相關文章