作者：張磊

雲原生是什麼？

提起雲原生，可能很多人都聽過這個概念，甚至有很多人是這個領域的從業者，但是大家依然會有一個問題，那就是什麼是雲原生，或者說雲原生的定義是什麼？

實際上我們在接觸到了很多的雲原生開源技術也好，雲原生產品也好，都會逐漸發現這麼一個現象，就是說雲原生它本質上其實並不是一個非常確切的事實或者物體。

所以在這裡強調一下，雲原生其實沒有什麼定義，它是一個不斷演進的過程。而雲原生更本質的內容，或者說雲原生的內涵，我們其實可以認為它是一套願景，那麼這個願景的內容是什麼呢？

雲原生認為，在未來雲的時代，咱們的軟件或者說應用是天然生於雲上，長於雲上。而正是因為這樣的現象或事實，雲計算就能夠最大程度地去幫助這些軟件降本提效，釋放軟件本身最大的業務價值，所以這個才是雲原生真正想要做的一件事情。它不是某項具體的技術，也不是某一個方法，更不是某一個具體的科研項目。

不斷演進的雲原生

我們可以通過下面這張圖來更好地闡明雲原生整體的玩法，或者說整體的形態到底是怎麼演進發展。

首先，前面講到雲原生非常強調利用雲的特性，所以它的核心方法論和核心概念都是圍繞著如何讓軟件和應用能夠利用雲的特性，那麼雲的特性是什麼呢？雲能夠無限彈性，雲的資源是可以快速交付，雲的使用方法是可以按量付費，這些都是雲常本質的特性。

所以說，圍繞這樣的雲特性，雲原生才有了一套最基礎的方法論和概念。比如，大家可能聽說過想不可變的基礎設施，就是說我們的應用部署在雲上，它可以假設應用載體是一個不可變的，這樣可以隨時把它刪掉、替換掉，所以更新應用會非常容易。升級應用可以直接採用刪掉舊的，上線新的方式來做，而不需要動態變更應用裡面的某項配置，甚至動態更改代碼實現。所以不可變基礎設施，就是一套非常典型的利用雲的快速資源交付能力的方法論。

再比如說，雲原生強調要高度的自動化，要能夠高度自運維，甚至自愈，這同時也是希望我們的軟件本身能夠更好地利用雲的特性。

因為雲的能力是非常強大的，能夠提供各種各樣的運維能力，所以我希望我的應用、軟件本身，它可能從開發的時候，考慮到雲能夠提供很多能力到應用層，而不是說先開發完應用，再去思考怎麼藉助雲去幫我們運維，因為這樣是構建不出一個自運維、自愈的軟件。

再比如說，雲經常強調這個應用用什麼語言、框架都是無所謂的，這也是一個很明顯的特點，因為雲本身是一個基礎設施能力，就應該不會去跟某種語言或者框架鎖定。同樣，也是希望世界上所有的軟件都能夠利用到雲的能力，而不是雲只能服務於某種語言。

這些都是基於雲，想要更好地利用雲的背景下，雲原生所提出的一些非常重要的概念。而這些概念本身在我們的技術演進當中，就會被映射成為一系列的系統，或者說架構思想。比如剛剛提到不可變基礎設施，一個應用可以隨時把舊的實例刪掉，換成新的實例。想要實現這樣的一套方法，就要靠容器技術。容器技術本質上給我們一個東西叫做容器鏡像，一個容器鏡像自包含一個應用的運行環境，包括應用本身，所以我們就隨時可以把鏡像舊的版本替掉，上線一個新的版本，這就是容器是不可變基礎設施的一套非常良好的實現。

這意味著未來是不是有某一種技術，能夠更好地實現不可變基礎設施，這是很有可能的，那麼這項技術是不是雲原生呢？當然。

所以未來可能有一個新的技術，能夠實現不可變基礎設施，或者更好地實現不可變基礎設施，這樣的技術也一定是雲原生的核心範疇。

與之類似的，雲原生裡面強調的Sidecar架構，就是把中間件能力通過Sidecar容器的方式對接到業務容器裡，而不是在業務本身上做定製，去集成中間件解決問題。這其實就是希望能夠實踐我們強調的無關語言、框架的方法論，提出了一個架構，而這個架構的特點就是中間件能力不再需要以語言或者框架的方式，嵌入到業務代碼中，所以說Sidecar加上容器能夠實現這樣一套方法，這個就是雲原生方法論背後所不斷推演出來的一系列技術和架構。

而這些技術架構最終在雲原生生態裡面，往往是以開源的技術項目提供給大家使用，比如剛剛提到容器，它就有Docker等方面的項目。提到了Sidecar，提到了自運維的這套思想，它會通過Kubernetes實現。再比如最近比較火的Service Mesh，它本質上是在幫我們做中間件的能力，只不過是通過Sidecar的方式去做。再比如說，我們未來或者說現在就已經比較活的eBPF、WASM等，其實都是在實踐雲原生這套體系背後的某項思想和某種架構，以開源的方式滿足我們使用的場景。

正是因為有了這一系列的開源項目，我們才做到一個用戶拿到這樣的科研項目，拿到這樣的技術，能夠真正實踐雲原生理念，從而達到前面講到的雲帶來的這兩種本質效果。

第一個是提升效率，比如研發效率，交付效率，運維效率。比如應用本身，它通過容器實現了不可變基礎設施的理念，那麼它的交付就可以非常簡單，我們只需要做交付鏡像，它就可以運行在每一個地方。

再比如說我們的運維，軟件本身通過Kubernetes已經實現了自運維、自動化，那麼它的運維難度和成本一定會降低。所以我們一定能夠藉助雲的能力提效。

第二個是降低成本，這裡包括了資源成本和人力成本，這個也很容易理解。比如說通過Kubernetes或者容器這樣的項目，我們的應用可以更好、更多地集成雲服務，通過雲服務來減少運維成本，減少人力投入，這都是很明顯的成本降低。

再比如說，通過應用的雲原生化，實現了應用上雲，之後通過雲的無限資源池Serverless架構，很快速地資源交付和和更新模式，讓整個應用的資源成本也變得很低。同樣，也是通過雲原生技術讓我們應用能夠更好地使用到雲本質能力非常好的體現和實踐。

所以總體而言，我們會發現這一套雲原生的方法，它其實是一個很完善的自閉環，不斷地去看，去探索如何利用雲的特性幫我們提效降本，然後把這一系列的方法或者思想總結和沉澱為雲原生的概念和方法論。

通過一系列相應的架構和對應的開源項目把它實現，然後再讓用戶能夠去使用這些技術，從而達到釋放雲計算紅利的本質目的。

所以說雲原生沒有一個確切的定義，它實際上是一套不斷自我演進的理論體系加上最佳實踐的組合。

今天的雲原生

而今天的雲原生大家可能都有些瞭解，就是圍繞著容器、Kubernetes去構建的，因為這樣的項目在直接幫助我們實踐很多雲原生背後的本質思想，包括不可變基礎設施、自動化等。

所以說在今天，Kubernetes項目可以被認為是一個雲時代通用的控制平面，也有人把它叫做操作系統，也就是說用戶所有的操作都可以藉助Kubernetes在雲上統一完成。

這裡面我們會發現Kubernetes這個項目的角色可能會越來越像一個安卓。舉一個例子，比如今天的Kubernetes無處不在，每個地方、每個雲上都有Kubernetes，部署在用戶端，部署在邊緣環境，都是非常正常的。

Kubernetes無處不在，就跟安卓一樣，車上有，電視裡有，甚至空調裡都可能存在，更重要的是用戶使用Kubernetes的本質目的是什麼？是交付和管理軟件。

比如說我們用Kubernetes，一定是在上面部署了某一個東西，比如部署了 AI的服務，或者部署一個淘寶，所以用戶的本質目的是使用這套東西來管理軟件，而這套東西Kubernetes本身它對上暴露的是一系列格式化的抽象，比如Deployment，Service，Ingress，讓我們能夠去管理和交付應用。而對下它啟動了一套標準化的接口，比如通過CNI就可以對接阿里雲的網絡，對接自研網絡插件，所以它本質上是中間層控制平面，接入了大量的基礎設施，暴露成為了應用所需要的一些能力，讓我們能夠用這些能力去管理應用。

而這樣的一個趨勢往後面不斷演進的話，我們就會發現這跟安卓系統特別像，比如安卓系統安裝在手機上，安卓本身其實是免費的，但是應用市場的應用是要付錢的，安卓的價值是在說把手機抽象包裝封裝成一系列應用可以使用的API，所以這就是安卓的定位，或者它的價值和今天的Kubernetes是完全一樣的。

所以，我們會看到未來Kubernetes不僅會出現在各種各樣的地方，更重要的是它會為應用軟件的研發、運維、交付的全生命週期提供一系列完整的能力，讓用戶能夠使用它。

與此同時，為了能夠更好地把軟件交付出去，未來我們會發現有很多這樣的項目在K8s上專門幫助我們解決軟件交付的問題。

與此同時，以前傳統的PaaS會不復存在，因為它的能力已經全部被Kubernetes接管，而未來會出現更多的開放、可擴展的PaaS，它們的作用是讓我們能夠更好、更簡單地交付和管理軟件，類似於安卓的豌豆莢，我們可以用豌豆莢便捷管理這些軟件。對於這樣趨勢，我們把它叫做Kubernetes的安卓化。

而另外一個趨勢就是說，在如今的雲原生生態裡面，我們的應用也好，能力也好，它都會往一個能夠自動化的方向演進，我們把它叫做Operator 化。

Operator是Kubernetes裡的一個核心思想，它指的是任何一個應用和所需要的能力都可以定義成為一個Kubernetes API對象，通過Controller機制讓我們去使用雲的能力，接入到各種各樣的基礎設施裡。

Operator 化帶來的一個直接結果就是我們的應用本身是高度自動化，包括自愈、健壯、可靠、運行的確定性，如今這些事情都是交給Kubernetes解決，用戶或應用的Owner不需要再關心這些問題。

這也是我們今天在K8s安卓化的背景下看到另外一個趨勢，就是應用本身和應用所需要的能力，它不斷地Operator化,不斷地往自動化方向演進。這也非常符合雲原生的理念，因為應用自動化和自愈能力越強，就越能夠跟雲對接，人工介入的成本會更低，時間也會更少，更多的是把自動化能力跟雲對接好，讓雲去幫助我們解決所有問題。

我們看到的另外一個趨勢是應用本身所需要的中間件能力正在下沉，意思是從以前的中心化的中間件，在過去幾年已經演進到了微服務架構。

微服務架構本質上是把中心化中間件這一套東西拆開，以SDK等方式放在業務代碼裡，我們需要把它引入進來使用，一般會提供一個比較重的客戶端或者一個庫讓我們去使用，這是微服務時代的中間件的一個典型使用方式。

但是在如今雲原生越來越普及的情況下，由於有像Sidecar這樣的機制存在，如今中間件大量通過Sidecar的方式去被使用，所以我們業務本身不需要再去引入一個庫或者特定的框架來做很多事情，我們甚至都不需要感知。

比如說，我們今天要去做流量的切分，不需要在應用裡面引入一個庫，而是完全交給基礎設施去做。

那麼應用怎麼去跟雲交互，就是通過Sidecar這麼一個容器，讓這個容器去代理應用本身所需要的進出流量，所以雲就可以非常容易地通過這樣一個代理調節流量去做流量切分，這就是一個非常簡單的Service Mesh原理。

我們能看到如今中間件能力通過這樣的方式在不斷下沉，它會帶來一個非常明顯的趨勢就是中間件不再與業務相關，不再與程序編寫語言相關了，也不需要對框架有什麼依賴，它的實現跟K8s、Kubernetes、容器化這套體系會非常緊密地結合。另外，對Sidecar的依賴也會更多，所以對Sidecar管理能力的要求也會逐步提高，可以把它總結為應用中間件能力的進一步下沉。

• 層出不窮的雲原生服務

除此之外，伴隨著雲原生整套體系的不斷髮展，可以看到雲服務也在大量、頻繁地向雲原生生態靠近，甚至帶來一些革命性的影響。

比如阿里雲的Polar DB，我們把它叫做雲原生的數據庫，它實際上就是基於雲原生的一些核心的思想理念，比如無限彈性，高度可擴展等，提出了一個全新的數據庫架構，使得數據庫本身能夠非常容易地擴展，應付極高、極為苛刻的流量和處理海量數據的需求，更滿足現代互聯網應用數據庫使用訴求。

再比如阿里雲的基礎設施，它是基於“裸金屬+容器”解決的，這也相當符合雲原生的思想。因為這樣的基礎設施能夠給我們帶來極致的資源使用效率，減少了很多性能損耗，讓容器便捷彈性地運維部署和管理。並且通過安全容器，通過更強的安全邊界來保證容器之間的隔離性。

神龍架構能夠為容器帶來物理級別極致的網絡存儲和計算性能，這是非常重要的，也是應用通過雲原生的理念使用雲計算服務的一個典型例子。

再比如說像AWS廠商已經發布了雲原生芯片，它讓芯片本身能夠更容易、更直接地適配容器化應用的使用方式，因為一個容器可能只有一個非常獨立或非常模塊化的一個進程在跑，就可以用芯片、核心去適配這樣的業務，把基礎設施的能力發揮得更強，把雲的能力發揮到極致，這也是一個非常典型的例子。同時，能夠保證這樣的核心之間干擾非常少，更適應容器化、微服務應用的使用方式。

再比如說，AWS推出了Proton，它是一個雲原生應用部署引擎，它可以用完全一致的方式去部署任何雲服務或容器服務，這都能夠幫助我們利用雲的能力去提升應用管理、交付、運維效率的一個典型產品。

所以我們看這些產品或者開源項目，我們思考這個雲產品是不是雲原生的技術，其實非常簡單，我們去判斷一下它能不能幫助我們的應用最大程度地利用雲計算降本提效，能否通過這樣的方式釋放最大的業務價值，這是判斷一項技術或者產品的定位是不是雲原生的一個核心標準，而不是看這個產品是不是容器。

回到阿里巴巴本身的例子，可以看到如今阿里巴巴的基礎設施已經基於像Kubernetes容器這樣的整套技術，完成了雲原生化，而真正回過頭來看這樣一件事情，我們會發現其實雲原生本身給阿里巴巴帶來了非常重要的一些變革。

• 阿里巴巴雲原生化

這裡稍微總結一下，第一個是我們對業務是研發，通過雲原生的思想很好地做到了關注點，分離研發更專注於業務。通過雲原生的標準交付方式，我們還提出了雲原生標準交付規範，標準化、模塊化地進行可持續交付，兼顧用戶體驗和靈活度，從而大幅提升業務的研發效能，完全專注於自己的業務，不需要再去接觸到複雜的基礎設施，這是雲原生給業務研發帶來的最大價值。

再比如說，對大量的業務運維SRE來說，雲原生體系所提供的敏捷運維、高效運營的理念，以及它的技術實現，包括前面講的輕量級容器，不可變基礎設施，再包括這種高度自動化的應用本身和運維方式，都能夠讓我們今天的軟件運維極其簡單、高效。

尤其相比於之前的傳統方式，基於容器的聲明式自動化方式，能夠極高地提高運維自動化程度，大量減少人工介入，提升操作的併發度，真正意義上實現所謂的把“把複雜留給系統，把簡單留給用戶”，這是雲原生的體系給阿里的基礎設施、運維、穩定性帶來的一個非常重要的變革。

如今容器化之後，現在的項目、淘寶應用等，做水平擴容、升級都是非常的快捷高效，而不是升級一下淘寶就會導致手機應用就掛了，這在雲原生時代是不會發生的。

另外一個例子是對基礎設施來說，阿里如今完全使用神龍裸金屬的實例，加上安全容器，它們能夠去幫助我們極大提升數據中心使用資源的效率，尤其是它能夠支持我們極高密度地部署安全容器，利用雲的規模效應降低資源碎片，我們可以做混部，可以根據工作負載的不同形態放心地填資源碎片，因為我們有神龍裸金屬，能夠確保這樣做依然有極高的業務運行效率，同時互相之間不會有任何干擾。這都是雲原生的環境下這套基礎設施所帶來的重要變革，隨著雲原生技術的引入和發展，也給阿里巴巴帶來了非常好的變化。

比如我們對內積極引入像Kubernetes、Service Mesh這樣的開源技術，另一方面讓阿里巴巴的技術棧非常地標準化開放，能夠跟生態無縫集成，也能夠降低研發成本，讓整個體系的可靠性和研發效率都有很好的提升。

而另一方面我們也知道，隨著自身基礎設施的標準化，阿里巴巴的技術正在大量、迅速地進入開源社區當中。目前阿里巴巴是CNCF裡面開源項目最多的公司，遠遠領先於任何廠商和其他組織。

這裡一個關鍵原因就在於，如今阿里巴巴的技術跟生態無縫對接，所以我們才能積極參與更廣泛的開源生態，把阿里的開源技術傳輸出去，甚至引領和影響整個業界生態的發展過程，這是阿里巴巴雲原生化之後的變化。

總結 – 我們視角的雲原生

回顧一下上文的雲原生理念，我們可以發現它實際上是一套架構到技術再到產品不斷引進的一個過程。從架構上來講，雲原生認為軟件天然生於雲上，能夠最大化地利用雲的能力。

另外一方面，區別於傳統的搬站模式，簡單地把應用搬上雲，雲原生能夠讓開發者享受到雲的紅利，去引領軟件和應用本身去不斷現代化。

而圍繞這種架構和理念，我們有一系列的技術，有開源的，有自研的，但是它背後的邏輯和思想是高度一致的。

我們圍繞著基礎設施、應用架構、開發、運維、交付等場景，通過雲原生技術讓我們的系統更加可靠、彈性，有更好的容錯性，並且組件之間鬆耦合、易管理可觀測，充分發揮雲計算的優勢。前面我們提到雲原生能夠釋放雲的最大潛力，其實它的背後往往離不開雲原生這套本質的理念和技術的支持。

所以以這些理念和架構為代表，如容器、不可變基礎設施、聲明式API、Service Mesh等，它們其實是我們落地雲原生的高效手段。

而圍繞這些手段本身，我們才有了各種各樣雲原生理念加持的產品，包括雲原生數據庫，雲原生服務，中間件，函數計算，容器等一系列的開放標準，能夠彈性，利用雲的價值，通過雲本身更好地服務應用、研發、運維和應用交付人員的一系列產品。它們能夠非常明顯地區別於傳統完全基於資源交付模式的雲計算服務提供的形態。

所以，我們會看到未來的雲會更多地向Serverless化、SARS化、服務化的方式演進，而較少地專注在基礎設施層，因為用戶真正的關注點在應用能否發揮最大的業務價值。

未來 - “雲原生”的下一步關注點？

前面我們講到的整個演進趨勢，它其實都伴隨著一個非常重要的點，就是雲的能力在不斷地豐富，這非常重要。

過去整個軟件架構本身，需要大量的傳統中間件，甚至一些微服務框架或者PaaS，幫助我們更好地管理軟件，它背後一個非常重要的原因在於雲或者基礎設施能力不夠強。比如我們今天就想要藍綠髮布這麼一個簡單的能力，雲在長期的一段時間內是不具備這個能力的，所以必須通過某種中間件或者某種框架來幫我們解決。

但如今不是這樣，如今我們的雲幾乎能滿足想象到的任何一種應用所需要的管理能力，甚至可以說雲的能力已經快要超出了如今軟件架構的大部分需求。

所以在這種情況下，必然不再需要一個額外的層，無論是傳統中間件還是傳統的微服務框架或者PaaS，來彌補軟件的訴求跟基礎設施之間的鴻溝，如今這個鴻溝越來越窄，這也是為什麼會出現各種各樣的雲原生技術。

所以說，任何一種雲原生技術不再是某種能力的彌補，更多的是如何把雲的能力以某種方式更簡單、更高效地透出給應用去使用。無論是容器、K8s還是Service Mesh，它們都是在不同的環節幫助應用更好地使用雲服務，或者說使用雲背後的基礎設施能力。

比如K8s，它可以讓我們的應用無感、極簡地接入到雲的存儲和網絡當中使用雲的計算能力，Service  Mesh通過Sidecar這樣完全無侵入的方式，讓我們能夠使用雲的流量控制能力來做微服務治理。

Dapr和OM通過與基礎設施完全無關的方式，讓我們能夠去編寫與基礎設施無關的代碼，以與基礎設施無關的方式交付應用。

所以未來整個雲計算的發展，包括雲原生背後的關注點一定也是這樣，不斷持續充分地釋放雲計算的基礎設施能力到軟件的研發交付乃至整個生命週期當中，這是非常重要的一點，因為未來雲的能力一定會越來越強。伴隨著這樣的趨勢，我們才會看到雲原生逐步引領整個雲計算生態往這個方向前進。