暢談雲原生(上):雲原生應用應該是什麼樣子?
今天和大家一起聊一聊雲原生這個話題,內容來自螞蟻金服中介軟體服務與容器團隊。
由於內容比較多,我們分為上下兩個半場。
前言
特別指出:這次分享主要是希望起到拋磚引玉的作用,讓大家更多的參與到雲原生這個話題的討論,希望後面有更多更好的分享。我們笨鳥先飛,起一個頭。
內容主要圍繞這幾個問題,上半場我們將圍繞前三個問題。
如何理解雲原生?
第一個話題:如何理解“雲原生”?之所以將這個話題放在前面,是因為,這是對雲原生概念的最基本的理解,而這會直接影響到後續的所有認知。
每個人對雲原生的理解都可能不同,就如莎士比亞所說:一千個人眼中有一千個哈姆雷特。
我們來快速回顧一下雲原生這個詞彙在近年來定義的變化。
先看Pivotal,雲原生的提出者,是如何定義雲原生的。
這是2015年,雲原生剛剛開始推廣時,Matt Stine給出的定義。
兩年之後,同樣是Matt Stine。
而這是Pivotal最新官方網站的描述。可見Pivotal對雲原生的定義一直在變。
再來看看目前雲原生背後最大的推手,CNCF,這是2015年CNCF剛成立時對雲原生的定義。
2018年CNCF更新了雲原生的定義。
這是新定義中描述的代表技術,其中容器和微服務兩項在不同時期的不同定義中都有出現,而服務網格這個在2017年才開始被社群接納的新熱點技術被非常醒目的列出來,和微服務並列,而不是我們通常認為的服務網格只是微服務在實施時的一種新的方式。
雲原生自身的定義一直在變,這讓我們該如何才能準確的理解雲原生呢?
這裡我們嘗試,將Cloud Native這個詞彙拆開來理解,先看看什麼是Cloud。
快速回顧一下雲端計算的歷史,來幫助我們對雲有個更感性的認識。
雲端計算的出現和虛擬化技術的發展和成熟密切相關,2000年前後x86的虛擬機器技術成熟後,雲端計算逐漸發展起來。
基於虛擬機器技術,陸續出現了IaaS/PaaS/FaaS等形態,以及他們的開源版本。
2013年docker出現,容器技術成熟,然後圍繞容器編排一場大戰,最後在2017年底,kubernetes勝出。2015年CNCF成立,並在近年形成了cloud native生態。
這是雲的形態變化,可以看到:供應商提供的功能越來越多,而客戶或者說應用需要自己管理的功能越來越少。
當雲發生如此之大的變化時,雲上的應用要如何適應?
在回顧完雲端計算的歷史之後,我們對Cloud有更深的認識,接著繼續看一下:什麼是Native?
這是從字典中摘抄下來的對Native詞條的解釋,注意其中標紅的關鍵字。
Native,總是和關鍵字 Born 聯絡在一起。
那Cloud和native和在一起,又該如何理解?
這裡我們丟擲一個我們自己的理解:雲原生代表著原生為雲設計。詳細的解釋是:應用原生被設計為在雲上以最佳方式執行,充分發揮雲的優勢。
這個理解有點空泛,但是考慮到雲原生的定義和特徵在這些年間不停的變化,以及完全可以預料到的在未來的必然變化,我覺得,對雲原生的理解似乎也只能回到雲原生的出發點,而不是如何具體實現。
雲原生應用應該是什麼樣子?
那在這麼一個雲原生理解的背景下,我再來介紹一下我對雲原生應用的設想,也就是我覺得雲原生應用應該是什麼樣子。
在雲原生之前,底層平臺負責向上提供基本執行資源。而應用需要滿足業務需求和非業務需求,為了更好的程式碼複用,通用型好的非業務需求的實現往往會以類庫和開發框架的方式提供,另外在SOA/微服務時代部分功能會以後端服務的方式存在,這樣在應用中就被簡化為對其客戶端的呼叫程式碼。
然後應用將這些功能,連同自身的業務實現程式碼,一起打包。
這是傳統非雲原生應用的一個形象表示:在業務需求的程式碼實現之後,包裹厚厚的一層非業務需求的實現(當然以類庫和框架的形式出現時程式碼量沒這麼誇張)。
而云的出現,可以在提供各種資源之外,還提供各種能力,從而幫助應用,使得應用可以專注於業務需求的實現。
在我們設想中,理想的雲原生應用應該是這個樣子:業務需求的實現佔主體,只有少量的非業務需求相關的功能。
非業務需求相關的功能都被移到雲,或者說基礎設施中去了,以及下沉到基礎設施的中介軟體。
以服務間通訊為例:需要實現上面列舉的各種功能。
SDK的思路:通過一個胖客戶端,在這個客戶端中實現各種功能。
Service Mesh的思路,體現在將SDK客戶端的功能剝離出來,放到Sidecar中。
通過這種方式,實現應用的輕量化。此時絕大部分的功能都在剝離,應用中只留下一個輕量級的客戶端。這個輕量級客戶端中還保留有少數功能和資訊,比如目標服務的標識(指出要呼叫的目標),序列化的實現。
這裡特別指出,有一個功能是我們努力嘗試但是始終沒有找到辦法的:業務動態配置的客戶端。也就是如何獲取和應用業務邏輯實現相關的動態配置資訊。如果有哪位同學對此有研究,希望可以指教。
我們的想法,雲原生應用應該超輕量化的方向努力,儘量將業務需求之外的功能剝離出來。當然要實現理想中的狀態還是比較難的,但是及時是比較務實的形態,也能比非雲原生下要輕量很多。
在這裡舉一個效果比較理想的實際案例,在service mesh中實現密文通訊。
由於客戶端和伺服器端兩個sidecar的存在,因此我們可以通過Sidecar之間的協商與合作分別實現加密和解密,從而實現遠端通訊的密文傳輸,而這個加密和解密的過程對於原有應用是透明的。
雲原生下的中介軟體該如何發展?
雲原生涉及到的面非常廣,對開發測試運維都會有影響,我們這裡將聚焦在中介軟體,給出我們的一些粗淺的想法,因為我們來自中介軟體部門。大家也可以將中介軟體自行替換為自己關心的領域,嘗試思考一下這個問題。
前面我們講到雲原生應用的理想形態和輕量化方向,這裡隱含了一個前提:不管雲原生應用的形態如何變化,雲原生應用最終對外提供的功能應該是保持一致的。
而要實現這一點,應用需要依賴於雲提供的能力,來替換因應用輕量化而剝離的原有能力,雲提供的能力是應用形態演變的基礎和前提。
理想狀態下,我們期望雲能夠提供應用需要的所有能力,這樣應用就可以以最原生化的形態出現。但是現實是這一點遠還沒有做到,我們依然需要在雲之外額外提供一些功能,比如原有中介軟體的功能。
在雲原生之前,中介軟體的做法通常是以類庫和框架的形式出現,近年來也有服務形式。而在雲原生時代,我們的想法是讓中介軟體下沉到基礎設施,成為雲的一部分。
在這裡解釋一下,在前面就提到了“下沉”,什麼是下沉?
我們的想法是:雲原生下的中介軟體,功能應該繼續提供,但是中介軟體給應用的賦能方式,應該雲原生化:
- 在雲原生之前,應用需要實現非常多的能力,即使是以通過類庫和框架的方式簡化,其思路是加強應用能力,方式如左圖所示,通過提供更大更厚的衣物來實現禦寒禦寒能力。
- 雲原生則是另外的思路,主張加強和改善應用執行環境(即雲)來幫助應用,如右圖所示,通過提供溫暖的陽光,來讓輕量化成為可能。
我們以Service Mesh模式為例來詳細講解,首先我們以白盒的視角來看Service Mesh的工作原理:
- 以原生模式開發應用:應用只需具備最基本的能力,如客戶端簡單發一個請求給伺服器端
- 部署時動態插入Sidecar:當我們將開發的雲原生應用部署到雲上,具體說是部署在k8s的pod中時,我們會自動在pod中再部署一個Sidecar,用於實現為應用賦能
- 在執行時,我們會改變雲原生應用的行為:如前面所說客戶端簡單發一個請求給伺服器端,在這裡會被改變為將請求劫持到Sidecar,注意這個改變對應用而言是透明無感知的
- 在Sidecar中實現各種功能:Sidecar裡面就可以實現原有SDK客戶端實現的各種功能,如服務發現,負載均衡,路由等等
- Sidecar在實現這些功能時,可以對接更多的基礎設施,也可以對接其他的中介軟體產品,這種情況下,Service Mesh產品會成為應用和基礎設施/中介軟體之間的橋樑
- 可以通過控制平面來控制Sidecar的行為,而這些控制可以獨立於應用之外
我們再以應用的視角,將雲和下沉到雲中的Service Mesh產品視為黑盒,來看Service Mesh模式:
- 以原生模式開發應用
- 以標準模式部署應用:底下發生了什麼不關心
- 客戶端簡單發一個請求給伺服器端:底下是如何實現的同樣不關心,應用只知道請求最終順利傳送完成
Service Mesh產品的存在和具體工作模式,對於執行於其上的雲原生應用來說是透明無感知的,但是在執行時這些能力都動態賦能給了應用,從而幫助應用在輕量化的同時依然可以繼續提供原有的功能。
Mesh模式不僅僅可以用於服務間通訊,也可以應用於更多的場景:
- Database mesh:用於資料庫訪問
- Message mesh:用於訊息系統
中介軟體下沉到基礎設施的方式,不只是有Mesh模式一種,而且也不是每個中介軟體都需要改造為Mesh模式,比如前面我們提到有些中介軟體是可以通過與Mesh整合的方式來間接為應用提供能力,典型如監控,日誌,追蹤等。
我們也在探索mesh模式之外的更多模式,比如DNS模式,目前還在探索中。
簡單歸納一下我們目前總結的雲原生賦能(Cloud Empower)的基本工作原理:
- 首先要將功能實現從應用中剝離出來:這是應用輕量化的前提和基礎
- 然後在執行時為應用 動態賦能:給應用的賦能方式也要雲原生化,要求在執行時動態提供能力,而應用無感知
本次暢談雲原生分享的上半場內容就到這裡結果了,歡迎繼續觀看下半場內容。
如開頭所說,這次分享是希望起到一個拋磚引玉的作用,期待後面會有更多同學出來就雲原生這個話題進行更多的分享和討論。也希望能有同學介紹更多雲原生的實現模式,更多雲原生的發展思路,拭目以待。
相關文章
- 雲原生是什麼?核心概念和應用方法解析
- 資料庫應用需要什麼樣的雲原生能力資料庫
- 中國的雲遊戲應該是什麼樣的?遊戲
- 什麼是雲原生?為什麼是Portworx來解決雲原生儲存問題?
- 智慧雲原生應用的崛起
- 雲原生儲存系列文章(一):雲原生應用的基石
- 【雲原生安全】從分散式追蹤看雲原生應用安全分散式
- 雲原生時代,微服務到底應該怎麼玩兒?微服務
- 聚焦雲原生安全|從分散式追蹤看雲原生應用安全分散式
- 到底什麼是雲原生資料庫?資料庫
- 「雲原生上雲」後的聚石塔是如何應對 雙11 下大規模應用挑戰的
- 雲原生時代,中介軟體應該如何 “進化”?
- 聽HashData CEO暢談雲原生資料倉儲
- 大咖說·禾連健康|“雲原生”的應用對企業有什麼樣的影響
- VMware的雲原生應用技術揭祕
- 用友雲平臺,真正的雲原生架構,加速雲應用落地架構
- 深度 | 阿里雲蔣江偉:什麼是真正的雲原生?阿里
- 雲原生時代來臨,開發者如何適應雲原生開發環境?開發環境
- 開放下載 | 《Knative 雲原生應用開發指南》開啟雲原生時代 Serverless 之門Server
- 真正的兒童智慧手錶應該是什麼樣子
- 雲原生應用的十個關鍵屬性
- 雲原生時代,應用架構將如何演進?應用架構
- 雲原生應用實現規範 - 初識 Operator
- 淺析雲原生應用安全組織架構架構
- 雲原生平臺,讓邊緣應用玩出花!
- Knative 助力 XTransfer 加速應用雲原生 Serverless 化Server
- 雲原生與邊緣計算的碰撞——邊緣原生應用實踐
- 應雲而生,幽靈的威脅 - 雲原生應用交付與運維的思考運維
- 在 Kyma 雲原生平臺上開發並部署 Node.js 應用Node.js
- 一個合理的生產環境的 Web 應用程式應該是什麼樣子的Web
- 申通快遞 雙11 雲原生應用實踐
- 如何開發一個標準的雲原生應用?
- 實現雲原生應用程式可移植的夢想
- 雲原生 DevOps,模型化應用交付能力很重要!dev模型
- 使用Java和Dapr構建雲原生應用簡介Java
- ALB Ingress 釋出!輕鬆應對雲原生應用流量管理
- 不懂 Kubernetes 實現雲原生是什麼體驗?
- TiDB Cloud GA,助力全球企業在雲上構建新一代雲原生應用TiDBCloud