我們為什麼需要雲原生？

在著名的《集裝箱改變世界》當中，我們能看到集裝箱的發明對於二十世紀全球化的巨大推動作用。集裝箱，這一看起來並無多少技術含量的發明，卻因為進行標準化和系統化運輸的創新徹底改變了全球的貨物貿易體系。

如今在IT領域，雲端計算的出現和發展相當於一次數字世界的“全球化”大的發現，而云原生就相當於一次“集裝箱式”的創新變革。

如果把網際網路看作是數字世界裡的貿易航線，那麼應用軟體和其中的資料就是穿行在航線上的船隻和貨物。在傳統的IT架構當中，最小的貨運單位就是船隻(單體應用)，不同的企業都有自家的船隻，因此每個船隻上都要配備全套的IT基礎設施(計算、儲存、網路等)，船隻要根據業務軟體的規模提前規劃，如果遇到業務增長，就只能在船上增補硬體裝置，但業務下降，這些裝置也只能閒置吃灰。

而云計算的出現，相當於是成立了幾家大型貨運公司，推出了一些超大型的標準化船隻，其他企業可以選擇把一部分貨物交給這些貨運公司去託運，甚至直接租用貨運公司的船隻去運貨，這就涉及到雲端計算幾種不同的服務提供方式。

伴隨著雲端計算這種“集中式貨運”的出現，一種適應雲端計算架構特點的應用開發技術和運維管理方式也出現了，那就是雲原生。雲原生的一個核心技術就是容器(Container)，而容器的創新之處就非常類似於集裝箱的創新。正如物理世界貨運的最小單元從船隻變成了集裝箱，在雲端計算中，軟體的最小單元不再是主機箱或者虛擬機器，而是一個個容器。

正是隨著雲端計算服務和容器化技術的發展下，越來越多的軟體開發者和IT運維管理人員開始改變過去獨立開發執行的傳統模式，從而提出一套基於雲端計算特點的新的軟體應用開發架構和模式，從而誕生了雲原生的概念。

雲有“原生”初長成

提及雲原生，就必然要提到雲端計算。眾所周知，按照雲端計算的服務提供方式，可以分為基礎設施即服務(IaaS)、平臺即服務(PaaS)、軟體即服務(SaaS)三層。從IaaS到PaaS，再到SaaS，意味著雲平臺提供的工具和服務越來越多，購買雲服務的企業所要做的開發相關的任務就越來越少，這一趨勢為雲原生的出現提供了技術基礎和方向指引。

(來源：CNCF基金會)

企業業務要想真正的雲化，不僅要在基礎設施和平臺層面實現，而且應用本身也應該基於雲的特點進行開發，從架構設計、開發方式、部署維護等各個階段和方面重新設計，構建真正應“雲”而生的“雲原生應用”。

根據行業內的說法，雲原生(Cloud-Native)概念的提出有幾個版本，公認的是由Pivotal公司CTO Matt Stine在2013年首次提出。當然，這一概念被提出來是沒有定義的，只是一系列技術的集合。

比如在2010年，WSO2公司CTO Paul Fremantle在部落格裡也提到“Cloud Native”的概念，不過他給出的相關解釋包含了分散式、多租戶、按需收費、彈性可伸縮這些特點，但這些主要是雲端計算服務的普遍特性，還不夠細化。

對於雲原生概念，Matt Stine在2015年發表的《遷移到雲原生應用架構》的一書中列舉出以下技術和特點：十二因素，微服務，子服務敏捷基礎設施，基於API的協作，反脆弱性。

後面，這家公司的另外一位技術大牛Kevin Hoffman 在《Beyond the 12 factor App》一書，基於原十二要素新增了三個新要素，即雲原生十五要素。

對於應用開發領域的從業者，這些要素想必都非常熟悉，相當於是一份SaaS應用的最佳實踐標準，可以適用於任何語言開發的後端應用服務，將開發流程自動化和標準化，降低開發者的學習成本。

到2017年，Matt Stine再次將雲原生架構歸納為模組化、可觀察、可部署、可測試、可替換、可處理6特質;而Pivotal官網則給出了雲原生的最新定義，概括為4個要點：容器、微服務、DevOps、持續交付。

另外一個比較正式的雲原生定義是由雲原生計算基金會(CNCF)提出的。在2015年，CNCF成立之初，這一組織將雲原生定義為包括：容器化封裝、自動化管理、面向微服務;到2018年，CNCF又把服務網格(Service Mesh)和宣告式API給加到雲原生的定義中來。

從雲原生的多個定義來看，這一概念在不斷完善和更新，不同組織和企業對於雲原生的側重點也有所不同。根據行業專家的總結，現在我們已經能夠看到雲原生的一個全貌特徵：

(圖源：王銀利《雲原生體系下的技海浮沉與理論探索》)

因此，整體來說，雲原生是一套在雲端構建和執行軟體應用的方法，可以歸結為一套技術方法論。“雲原生”的“Cloud”，代表了軟體應用是放在雲端而非傳統的IT裝置中，而“Native”則代表軟體應用從一開始設計，就是根據雲的環境，採用雲端的技術，充分利用雲平臺的彈性伸縮和分散式特點，最終在雲端高效、穩定、安全執行。

從本質上來說，雲原生是架構根植於雲，基於雲上開發、部署、維護的一套技術方法體系。

點開雲原生的“技能樹”

根據以上雲原生概念的共性，我們主要拆解下容器化、微服務、持續交付，DevOps這些涉及雲技術和運維管理方法的主要特徵。

首先來介紹代表性的容器技術。最初，一個軟體應用都是放在物理主機上的，管理起來非常不方便，後面出現了虛擬化技術，可以透過伺服器資源共享的方式，按需構建應用例項，但是虛擬化構建出的虛擬機器仍然是一個完整作業系統，雖然比物理機更靈活，但仍然資源浪費的情況。那麼，容器技術，就如同IT開發當中的集裝箱，採用更小單元徹底將一個應用的資源打包在不同的容器裡，從而可以適應各種應用的執行環境。

從2004年開始，谷歌就在內部大規模使用Cgroups等的OS虛擬化技術，2008年，谷歌推出的LXC(Linux Container)專案具備了Linux容器的雛型。2013年，Docker橫空出世，讓Linux容器技術快速席捲開發界。Docker的成功，也讓構建應用的最小單元變成了容器，而容器是微服務的最佳載體。

微服務就是一種跟單體應用相對應的新的應用架構，是應用服務單元的小型化和微型化。有個比喻非常貼切，單體應用就是一個大茶壺裡煮很多餃子，現在變成一個小茶壺裡煮一個餃子，但是擁有很多個茶壺。微服務就是要將應用的顆粒度做到最小，使之獨立承擔對外服務的職責。微服務的理念是隨著軟體系統的複雜度上升，需要投入的人力和時間資源越來越多，但卻需要及時交付而出現的。

DevOps，是Development+Operations的組合詞，也就是開發和運維的合體，當然也包含測試。DevOps是一種敏捷開發思維和IT組織的溝通方法，可以促進開發、技術運營和質量保障部門之間的溝通、協作和整合，從而提高軟體和服務的交付效率。反映在雲原生上面，就是提高持續交付的能力。

雲原生的持續交付，要做到不誤時開發，不停機更新，小步快跑，要求開發版本和穩定版本並存，其實需要很多流程和工具支撐。對於廣大使用者來說，現在一個最直觀的感受就是很多巨型應用可以做到幾乎在悄無聲息見就完成更新，根本不用再一次次進行應用的下載和安裝，而這就要歸功於雲原生的這些能力。

在軟體開發領域，曾經有一個“不可能三角”的說法，也就是功能複雜程度、交付週期和可靠性這三者無法同時實現，但基於以上雲原生的技術和管理方法，相當於解決了這一的一個開發難題，從而幫助企業提升應用開發效率，實現業務創新。

雲原生的能力將造成這樣一個結果，那就是讓一個應用的底座變得越來越複雜，資料處理也越來越自動化，而應用的業務層面則越來越輕，越來越簡單化。對於大眾使用者來說，就是應用的更新、功能的使用越來越便捷和“聰明”。

雲原生“江湖”

雲原生是順應雲端計算時代的應用開發特點而產生的一種技術理念，因此在雲原生概念一直沒有明確的定義，而只有不同組織的不同的解釋。相伴而生的就是雲原生技術的演化和廠商的紛爭。

現在一提到雲原生，基本就會提及Docker和Kubernetes(簡稱K8s)。那麼，這兩者到底是怎樣的關係呢?

簡單來說，Docker是目前最成功的容器工具，K8s是目前最流行的容器編排工具。所謂“編排”，源自音樂指揮家對不同樂器演奏的協調，那麼用在雲原生這裡，就是對包含應用程式的容器的協同關係管理。

最初，Google已經在容器技術上有了十多年的積累，只不過，Google的做法是秘而不宣，把基礎設施的複雜性都留在內部，只給開發者和使用者提供最簡單的操作工具就行。但是2013年開源容器工具Docker一經推出就大受歡迎，很快就成為事實上的容器標準，這嚴重刺激了Google。因此，Google採用了“敵人的敵人就是朋友”的戰略，開始支援與Docker分道揚鑣的CoreOS，推出了K8s專案，並支援CoreOS提出的另一個開源容器引擎Rocket。

2014年，當Google發現CoreOS在容器生態領域實在不是Docker的對手之後，決定換道超車，於當年宣佈推出K8s容器叢集編排工具，並在2014年6月7日將初始版本程式碼提交到Github上完全開源。而此時的Docker公司也雄心勃勃，於年底在DockerCon上釋出了自己研發的“Docker原生”容器叢集管理專案Docker Swarm，並想與K8s一較高下。一場“容器編排”的戰爭打響。

(Kubernetes來自於希臘語，含義是舵手或領航員)

但Kubernetes憑藉Google在容器叢集管理系統Borg+Omega上的多年技術積累，很快橫掃Docker Swarm和其他容器編排工具。到2017年6月，據CNCF統計：K8S佔據著77%的市場份額，到10月，Docker宣佈支援K8s，這標誌著容器編排的戰爭基本結束，最終以K8s的大獲全勝告終。

Docker被K8s成功收編，那最大的贏家就是2015年成立的雲原生計算基金會(CNCF)，當然還有全球的開發者。

CNCF是由Google 牽頭成立，隸屬於 Linux 基金會，初衷是圍繞雲原生服務雲端計算，致力於培育和維護一個廠商中立的開源生態系統，維護和整合開源技術，支援編排容器化微服務架構應用，透過將最前沿的模式民主化，讓這些創新為大眾所用。

截至2020年4月，CNCF基金會共託管49個雲原生專案，其中，Kubernetes是CNCF託管的第一個雲原生開源專案。現在全球主流的科技企業和雲端計算廠商絕大部分都是CNCF會員，雲廠商們把加入CNCF作為企業技術競爭力的宣傳點。

(CNCF全景圖)

可以說，雲原生在今天的發展壯大，確實離不開CNCF這樣的中立組織所發揮的作用。假如說Docker一家獨大，就很容易提高容器技術的使用成本，如果K8s不在CNCF開源共享，開發者又可能要面臨“二選一”的麻煩。

值得注意的是，在2020年12月，K8s宣佈棄用Docker，並非是簡單地對Docker的“卸磨殺驢”，而是對於容器編排的進一步最佳化。因此，我們可以看到雲原生的具體的技術工具還 演變進化當中。

到這裡，我們應該對雲原生的前世今生有一個基本的印象。

總的來說，雲原生沒有一個固定的概念定義，但卻有一個清晰的邏輯，那就是軟體應用正在按照雲原生的方式進行深度的雲化，充分貼合雲端計算的彈性可擴充套件、敏捷、分散式、自動化的特點，因雲而生，又應雲而行。

同時，雲原生體系的技術也處在不斷的演化發展當中，目前正形成以容器及容器編排、微服務、敏捷基礎設施、DevOps、宣告式API等為特點的雲原生應用的技術方法論。在這些雲原生技術的演進過程中，CNCF及其提供的開源專案和開發生態將發揮更加顯著的作用。

當然，儘管我們看到雲原生有這樣那樣的好處，但是雲原生從誕生到如今的破圈而紅並非是一蹴而就的，雲原生本身的演化也經歷一個從青澀到成熟的過程。但云原生的計算價值已經落地生根，某種程度上成為了企業IT的大勢所趨，甚至必然選擇。