[[412417]]

云原生是什么？

即使“云原生”的提出已經有一段時間，但不少人還是會有這樣一個問題：究竟什么是云原生？或者說云原生的確切定義是什么？

實際上，當我們接觸到很多云原生的開源技術和產品之后，會逐漸發現一個現象——云原生本質上其實并不是一個非常確切的物體。也就是說，云原生其實不存在什么具體定義，它指的是一個不斷演進的過程。與其談云原生的本質，不如我們將它理解為一套愿景。

那么這套愿景的內容又是什么呢？

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

不斷演進的云原生

下圖能夠直觀地闡明云原生整體的形態到底是怎么去演進和發展的。

云原生非常強調利用云的特性，所以它的核心方法論和核心概念都是圍繞如何讓我們的軟件和應用去利用云的特性。那么云的特性是什么呢？比如說云是能夠無限彈性的、云的資源是可以快速交付的、云的使用方法是可以按量付費的，這些都是云非常本質的特性。

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

再比如說，云原生強調要高度的自動化，實現自運維甚至自愈，其實也是希望軟件本身能夠去更好地利用云的特性。因為云的能力是非常強大的，云能夠提供各種各樣的運維能力，所以應用或者軟件可能從開發的時候，就要考慮到云其實能夠提供很多能力到應用層，而不是說先開發完應用，再去思考怎么借助云的能力去運維，這樣是構建不出來云原生應用的。

再比如說，云原生應用無所謂用什么語言寫，用什么框架寫，這也是很明顯的一個特點。因為云本身是一個基礎設施能力，那么就不應該也不會去用某種語言或者框架去鎖定。同樣也是希望這個世界上所有的軟件都能夠去利用云的能力，而不是說云只能服務于某種語言。

以上這些都是在云的背景下，云原生提出的一些非常重要的概念。而這些概念本身在我們的技術研究當中就會被映射成為一系列的系統，或者說架構思想。比如說前面提到不可變基礎設施，可以把一個應用舊的實例刪掉換成新的實例，像這樣的一套方法怎么去實現？就要靠容器技術。容器技術本質上提供容器鏡像，一個容器鏡像是自包含一個應用的運行環境，包括應用本身，可以隨時把這個鏡像版本替掉，上線一個新的版本就可以了。這其實代表著容器是不可變基礎設施的一個非常良好的實現。

那么這是不是意味著未來會有某一種技術，能夠更好地去實現不可變基礎設施呢？這是很有可能的，并且這項技術當然也是云原生的。當未來可能有一個新的技術去實現不可變基礎設施，或者更好地實現不可變基礎設施，那么這樣一個技術也一定是屬于云原生的核心范疇。與之類似的，像我們云原生今天強調的 Sidecar 架構，就是把中間件能力通過一個叫 Sidecar 容器的方式去對接到業務容器里去，而不是說在業務本身上去做定制，集成中間件去解決問題。這其實是希望能夠去實踐我們強調的與語言無關、與框架無關的這樣一套方法論所提出的一個架構。而這個架構的特點就是，中間件能力不再需要以語言或者框架的方式嵌到業務代碼本身里去，所以說 Sidecar 加上容器都能夠去實現這樣的一套方法。

這就是云原生方法論背后不斷推演出來的一系列技術和架構，而這些技術架構最終在云原生生態里面，往往是以開源的技術項目來給大家去使用的。比如說前面提到的容器就會有 Docker 上的項目，我們提到的 Sidecar 和自運維的這套思想，最終會通過 Kubernetes 去幫你去實現。

再比如說最近比較火熱的 Service Mesh，它本質上在幫你去做中間件的能力，只不過是通過 Sidecar 這種與語言無關的方式去做；再比如說我們未來或者說現在就已經比較火的 eBPF、WASM，他們其實都是在實踐云原生這套體系背后的某項思想和某種架構，以開源的方式去滿足讓用戶使用的場景。而正是因為有了這一系列的開源項目，我們才能做到說當我的用戶拿到這樣的開源項目，拿到這樣的技術，他能夠去真正實踐云原生理念，從而達到我們前面講到的這兩種云帶來的本質效果：

第一個是提升效率，比如說研發效率、交付效率、運營效率。例如我的應用本身通過容器實現了不可變基礎設施的這樣一套理念，那么它的交付就可以非常簡單，我只需要做鏡像，交付鏡像后它就可以運行在每一個地方；再比如說我們的運維，當你的軟件本身已經實現了自運維，那么它的運維的難度和成本一定是降低的，所以我們一定能夠借助云的能力去提效。

第二個是降低成本，這里包括了資源成本，也包括了人力成本。比如說通過 Kubernetes 或者說通過容器這樣的項目，我的應用可以更好地、更多地去集成云服務，通過云服務來減少運維成本和人力投入，這些都是很明顯的成本降低。再比如說我的應用通過云原生實現了上云，又通過云原生架構，可以很快速地進行資源交付和更新的模式，讓整個應用的資源成本也變得很低，這同樣也是通過云原生技術，讓應用能夠更好地使用到云的本質能力的一種非常好的體現和實踐。

總體而言，你會發現這一套云原生的方法其實是一個很完善的閉環，先不斷去地看、不斷地去探索如何利用云的特性幫助用戶去提效降本，然后把這一系列的方法或者這一系列的思想，總結沉淀成為云原生的概念和方法論，再通過一系列相應的架構和對應的開源項目將其實現，最后再讓用戶能夠去使用這些技術，從而達到釋放云計算紅利的本質目的。

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

今天的云原生

今天的云原生可能是圍繞著容器和 Kubernetes 來構建的，而這樣的項目實際上在幫助我們去實踐很多云原生背后的本質思想，包括不可變基礎設施、自動化等。今天 Kubernetes 被認為是一個云時代的通用控制平面，也有人把它叫做操作系統，就是說你的所有操作都可以借助 Kubernetes 在云上統一去完成。

1、Kubernetes 項目的“安卓化”

Kubernetes 項目的角色可能會越來越像一個安卓。舉一個例子，比如說今天的 Kubernetes 其實正在做到無處不在，每個地方每個云層都有 Kubernetes，甚至部署在端的用戶、或者部署在邊緣的環境下都是非常正常的，就跟安卓一樣，車上也有，我們電視里也有，甚至空調也會有可能有一個安卓。

Operator 是 Kubernetes 里面的一個核心思想，它代表著我的任何一個應用和它所需要的能力都可以定義成為一個 Kubernetes 的 API 對象，通過一個叫做 Controller 的機制讓你去使用云的能力，再讓你接入到各種各樣的基礎設施里面。這個 Operator 化帶來的一個直接結果就是，我的應用本身是高度自動化的，包括自愈、健壯性、可靠性、運行的確定性，這些在今天都可以交給 Kubernetes去解決。我的用戶或者說我應用的 owner，不需要再關心這些問題。

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

3、應用中間件能力進一步“下沉”

還有一個趨勢是，我們應用本身所需要的中間件能力下沉。即以前的中心化的中間件其實在過去幾年中，已經演進到了微服務架構。

微服務架構本質上是把以前的中心化中間件的這一套東西拆開，放在了業務代碼里面，而你需要去把它引入進來使用。一般來說，會提供一個比較重的客戶端或者一個庫讓你去使用，這是我們的微服務時代典型的中間件的一個使用方式。但是在今天，在我們云原生的越來越普及的這樣一個現狀下，有沒有像 Sidecar 這樣一個機制的存在？

今天的中間件實際上是大量的通過 Sidecar 方式去被使用到的，所以我的應用本身不需要再去引入一個庫，或者引入一個特定的框架來去做很多事情，我甚至都不需要感知。比如說我今天要去做流量的切分，我不需要說在應用里面去引入這么一個庫去做，而是完全交給我的基礎設施，交給云去做。

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

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

層出不窮的云原生服務

除此之外，伴隨著云原生整套體系的不斷發展，我們會看到，云服務在大量的、頻繁地向云原生生態去靠攏，甚至說帶來一些革命性的影響。

比如說，今天阿里云的云原生數據庫，它實際上就是基于云原生提到的核心的思想理念，比如說無限彈性、高度可擴展，提出了一個全新的數據庫架構，使得數據庫的本身非常容易去擴展，能夠去應付極高的、極為苛刻的流量和海量的數據處理需求，滿足今天現代互聯網應用的數據庫使用的訴求。

再比如說阿里云基礎設施，它能夠給我們帶來極致的資源使用效率，減少了很多層的虛擬化的性能損耗，讓容器本身具有彈性，非常容易地去運維部署和管理，并且通過安全容器，通過更強的安全邊界，保證容器之間的隔離，使隔離性是足夠的。它能夠為容器帶來極致的物理級別的網絡存儲和計算性能，這是非常重要的，也是我們的應用通過云原生的理念去使用云計算服務的一個非常典型的例子。

再比如說像亞馬遜云科技，它讓我們的芯片本身能夠去更容易或者說更直接的去適配容器化應用的使用方式。因為一個容器可能只有一個非常獨立或者說非常模塊化的一個進程在跑，那我就可以用芯片的核心去適配這樣的一個業務，把我的基礎設施的能力發揮得更強，把能力發揮到極致，同時保證像這樣的核心之間的干擾是非常少的，更適應容器化微服務的應用的使用方式。

比如亞馬遜云科技最近推出一個云原生應用部署引擎，它可以用我們這種完全一致的方式去部署任何的這種云服務或者是容器服務，這都是能夠去幫助我們利用云的能力去提升應用管理交付運維效率的一個非常典型的產品。

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

阿里巴巴云原生化

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

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

再比如說對大量的業務運維和 SRE 來說，云原生體系所提供的這種敏捷運維高效運營的這套理念，以及它的技術實現，包括前面講的輕量級的容器不可變、基礎設施、高度自動化的應用本身和運維方式，都能夠讓我們今天的軟件運維變得極其簡單、極其高效，尤其相比于之前的傳統方式，基于容器的基于自動化的一個方式，能夠極高地提高我們的運維自動化程度，大量減少人工介入，提升我們操作的并發度，真正意義上的實現所謂的把復雜留給系統，把簡單留給用戶，這就是我們今天云原生的體系。

那么更不用說今天容器化之后，比如淘寶這類的應用，去做水平擴容和升級都是非常快捷、非常高效的，而不是說升級一下淘寶，你的手機應用就掛了，在云原生時代這事不再會發生了。

另外一個例子是對基礎設施來說，通過阿里今天使用的神龍裸金屬的實力，加上我們的安全容器，能夠去幫助我們極大地提升今天數據中心的使用資源效率，我們叫提升資源效能。尤其是它能夠去支持我們極高密度地去部署安全容器，利用規模效應，降低資源碎片。可以去根據你的工作負載的不同形態，去放心地填資源的碎片，因為有神龍金屬所以我們能夠確保這樣做，依然有極高的業務的運行效率，同時不會互相之間有任何干擾。這些都是在今天云原生的環境下，這項基礎設施所能夠給我們帶來的一個非常重要的一套變革，甚至說對于阿里巴巴的這樣一個組織，隨著云原生技術的引入和發展，也帶來了一個非常好的變化，讓阿里巴巴的技術棧標準化開放，能夠跟生態無縫集成，也能夠降低研發成本，讓整個體系的可靠性和研發效率都有一個很好的提高。

而另一方面，隨著自身基礎設施的標準化，阿里巴巴的技術正在飛快地進入到開源社區當中。今天阿里巴巴是 CNCF 里面開源項目最多的一個公司，遠遠領先于任何一個廠商和其他一些組織。這里一個關鍵原因就在于，今天阿里巴巴的技術是跟生態無縫對接的，所以我們才能夠積極去參與這樣的一個更廣泛的開源生態，把阿里的開源技術輸出出去，甚至說這引領和影響了整個業界生態的發展過程，這個都是阿里巴巴的云原生化之后，我們看到的實實在在的一個變化。

總結

如果我們回顧一下今天講的云原生這套理念，可以發現它實際上是一套架構到技術到產品的不斷演進的過程。從架構上來講，云原生認為軟件天然生于云上、長于云上，能夠最大化的利用云的能力；另外一方面區別于傳統的模式，云原生能夠讓開發者享受到紅利，能夠去引領它的軟件和應用本身去不斷的現代化。

而圍繞這種架構和理念，我們有一系列的技術，這里面有開源的，有自研的，但是它背后的邏輯和思想是高度一致的。圍繞著基礎設施、應用架構、開發運維交付的場景，通過云原生技術讓系統更加可靠，具有彈性，有更好的容錯性，并且組件之間松耦合易管理，可觀測性做得更好，從而充分地去把云的能力透出來。云原生能夠釋放云的最大潛力，其實它的背后往往離不開云原生本質的這套理念和技術的支持，以這些理念和架構為代表的，像容器、不可變基礎設施等等，他們其實是我們去落地云原生里面的一個高效的手段。

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

所以我們會看到未來的云會更多地向 Service 化、SaaS 化、服務化的方式去演進，而較少地去專注在基礎設施這一層，因為我們真正的用戶關注點，其實在它的應用能否發揮最大的業務價值這個問題上面的。

未來的整個演進趨勢，它其實都伴隨著一個非常重要的點，就是說云的能力在不斷地越變越豐富，這是非常重要的。之所以在過去，我們的整個軟件架構本身它會需要大量的，比如說傳統中間件，甚至一些微服務框架或者是 PaaS，去幫助我們更好地的管理軟件，它的背后非常重要的原因在于云或者說基礎設施能力不夠強。比如說我今天就想要一個藍綠發布的能力，而很多云在很長一段時間內是不具備這個能力的，所以必須通過某種中間件或者某種框架來幫你去解決，但今天不是這樣。今天我們的云幾乎能做到你想象到的任何一種應用所需要的管理能力，甚至應該說云的能力其實已經幾乎要超出了我們今天軟件架構的大部分需求。所以在這種情況下，我必然不再需要一個額外的層，無論是傳統中間件，還是傳統的這種微服務框架或者 PaaS，去幫助彌補軟件的訴求跟基礎設施之間的鴻溝。

當這個鴻溝越來越窄，各種各樣的云原生技術開始出現。所以任何一種云原生技術，它不再是某種能力的彌補，而是更多地將云的能力以某種方式更簡單、更高效地透出給我的應用去使用。無論是容器、K8s 還是 Service Mesh，他們都是在不同的環節幫助應用本身能夠更好地去使用云服務。或者說使用到云背后的基礎設施能力，比如說 K8s 它可以讓應用非常無感地極簡地進入到我的云的存儲和網絡當中，使用云計算能力；Service Mesh 通過 Sidecar 這樣完全無侵入的方式，讓你能夠使用云的流量控制的能力來去作為微服務治理。

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