我們已經(jīng)進入云計算下半場敦腔，不再像上半場在糾結要不要上云均澳，而是討論怎么上云？才能把云計算的價值發(fā)揮到淋漓盡致符衔。如何把云計算與不同的業(yè)務場景深度結合找前？如何讓技術真正作用于企業(yè)？如何節(jié)省企業(yè)IT部署成本判族？

誰也不知道答案躺盛，直到“云原生”來了。

◆◆云原生是什么◆◆

云原生是什么形帮？這個眾說紛紜颗品，沒有統(tǒng)一的定義，姑且以老大哥CNCF的定義來了解云原生沃缘。

老大哥躯枢？CNCF？

CNCF槐臀，全稱為Cloud Native Computing Foundation锄蹂，中文譯為“云原生計算基金會”。成立于2015年12月11日水慨，CNCF是Linux基金會旗下的基金會得糜。CNCF致力于培育和維護一個廠商中立的開源生態(tài)系統(tǒng)，來推廣云原生技術晰洒。CNCF是云原生領域影響力最大最有話語權的組織朝抖。

說起CNCF的故事，還要從Cgroups（control groups谍珊，控制組群）開始說起治宣，時間軸回到16年前。

2004年，谷歌開始使用容器技術侮邀，于2006年發(fā)布了Cgroups,最初叫Process Container（進程容器）坏怪。

Process Container的目的非常直白，它希望能夠像虛擬化技術那樣給進程提供操作系統(tǒng)級別的資源限制绊茧、優(yōu)先級控制铝宵、資源審計能力和進程控制能力。帶著這樣的設計思路华畏，Process Container在2006年由Google的工程師正式推出后鹏秋，第二年就進入了Linux內核主干。

因為在Linux內核中亡笑，容器（container）這個名詞有許多不同的意義侣夷，為避免混亂，就更名為Control Groups况芒，也就是Cgroups惜纸。

2013 年叶撒，Docker 項目正式發(fā)布绝骚，2014 年，K8s項目也正式發(fā)布祠够。

原因非常容易理解压汪，因為有了容器和 Docker 之后，就需要有一種方式去幫助大家方便古瓤、快速止剖、優(yōu)雅地管理這些容器，這就是K8s項目的初衷落君。

K8s是云原生的基石穿香，后面會細講。在 Google 和 Redhat 發(fā)布了K8s 之后绎速，這個項目的發(fā)展速度非常之快皮获。

2015 年，由Google纹冤、Redhat 以及微軟等大型云計算廠商以及一些開源公司共同牽頭成立了 CNCF 云原生基金會洒宝。CNCF成立之初，就有22個創(chuàng)始會員萌京，而且K8s也成為了 CNCF 托管的第一個開源項目雁歌。

在這之后，CNCF 迅猛發(fā)展知残。截止2020年2月靠瞎，從官網(wǎng)看到數(shù)據(jù)顯示有433個會員。

那么CNCF是如何定義云原生的呢？

翻譯為中文：

云原生技術有利于各組織在公有云较坛、私有云和混合云等新型動態(tài)環(huán)境中印蔗，構建和運行可彈性擴展的應用。云原生的代表技術包括容器丑勤、服務網(wǎng)格华嘹、微服務、不可變基礎設施和聲明式API法竞。?這些技術能夠構建容錯性好耙厚、易于管理和便于觀察的松耦合系統(tǒng)。結合可靠的自動化手段岔霸，云原生技術使工程師能夠輕松地對系統(tǒng)作出頻繁和可預測的重大變更薛躬。 云原生計算基金會（CNCF）致力于培育和維護一個廠商中立的開源生態(tài)系統(tǒng)，來推廣云原生技術呆细。我們通過將最前沿的模式民主化型宝，讓這些創(chuàng)新為大眾所用。

除了CNCF關于云原生的定義絮爷，網(wǎng)絡上流傳的另一個版本是Pivotal 公司的 Matt Stine于2013年首次提出云原生概念趴酣；2015年，云原生剛推廣時坑夯，Matt Stine在《遷移到云原生架構》一書中定義了符合云原生架構的幾個特征：12因素岖寞、微服務、自敏捷架構柜蜈、基于API 協(xié)作仗谆、扛脆弱性。

到了2017年淑履，Matt Stine 改了口風隶垮，將云原生架構歸納為模塊化、可觀察秘噪、可部署狸吞、可測試、可替換缆娃、可處理6特質捷绒；而Pivotal 官網(wǎng)對云原生概括為4個要點：DevOps+持續(xù)交付+微服務+容器。

云原生所需能力與特征 by:CNCF大使 宋凈超

MattStine認為云原生它是一個思想的集合贯要，包括DevOps暖侨、持續(xù)交付（Continuous Delivery）、微服務（MicroServices）崇渗、敏捷基礎設施（Agile Infrastructure）字逗、康威定律（Conways Law）等京郑。

云原生即包含技術（微服務，敏捷基礎設施）葫掉，也包含管理（DevOps些举，持續(xù)交付，康威定律俭厚，重組等）户魏。云原生也可以說是一系列云技術、企業(yè)管理方法的集合挪挤。

我們以CNCF官方的定義來接著了解叼丑。云原生的代表技術包括容器、服務網(wǎng)格扛门、微服務鸠信、不可變基礎設施和聲明式API。那么這些技術都是什么论寨？這些技術有什么聯(lián)系星立？

◆◆云原生代表技術◆◆

容器

一般我們說的“容器”（LinuxContainer，LXC）葬凳，都是“Linux容器”（當然微軟也在搞容器绰垂，但還沒linux那么成熟）。開源解決方案供應商紅帽官網(wǎng)給出的容器定義：

Linux? 容器是與系統(tǒng)其他部分隔離開的一系列進程沮明。運行這些進程所需的所有文件都由另一個鏡像提供辕坝，這意味著從開發(fā)到測試再到生產(chǎn)的整個過程中窍奋，Linux 容器都具有可移植性和一致性荐健。因而，相對于依賴重復傳統(tǒng)測試環(huán)境的開發(fā)渠道琳袄，容器的運行速度要快得多江场。容器比較普遍也易于使用，因此也成了 IT 安全方面的重要組成部分窖逗。

容器提供進程級的隔離址否，可以將操作系統(tǒng)管理的資源劃分到相互隔離的組中，在相互隔離的組之間解決資源使用存在沖突的問題碎紊。比如應用程序（Application佑附，APP ）APP 1 只能在centos 操作系統(tǒng)上運行，APP2只能在ubuntu操作系統(tǒng)上運行仗考，而同一個操作系統(tǒng)同時運行APP1和APP2就產(chǎn)生沖突音同，容器技術則恰恰可以解決這類問題。目前主流的容器技術有Docker秃嗜、LXD以及RKT等权均。

Docker

說到容器顿膨，就不得不說Docker拂共。

2010年棘脐，幾個大胡子的年輕人在美國舊金山成立了一家名叫“dotCloud”的公司。這家公司主要提供基于PaaS的云計算技術服務枫攀。具體來說必指，是和LXC有關的容器技術囊咏。LXC，就是Linux容器虛擬技術（Linux container）

后來塔橡，dotCloud公司將自己的容器技術進行了簡化和標準化匆笤，并命名為——Docker。

Docker項目發(fā)布時谱邪，無非也是LXC的一個使用者炮捧，它創(chuàng)建和使用應用容器的邏輯跟Warden等競爭對手沒有本質不同。不過惦银，我們現(xiàn)在也知道咆课，真正讓PaaS項目無所適從的，是Docker項目最厲害的殺手锏：容器鏡像扯俱。

Docker項目通過容器鏡像书蚪，直接將一個應用運行所需的完整環(huán)境，即：整個操作系統(tǒng)的文件系統(tǒng)也打包了進去迅栅。這種思路殊校，可算是解決了困擾PaaS用戶已久的一致性問題，制作一個“一次發(fā)布读存、隨處運行”的Docker鏡像的意義为流，一下子就比制作一個連開發(fā)和測試環(huán)境都無法統(tǒng)一的Buildpack高明了太多。

Docker項目大大降低了容器技術的使用門檻让簿，輕量級敬察，可移植，虛擬化尔当，語言無關莲祸，寫了程序扔上去做成鏡像可以隨處部署和運行，開發(fā)椭迎、測試和生產(chǎn)環(huán)境徹底統(tǒng)一了锐帜，還能進行資源管控和虛擬化。

Docker作為一種開源應用容器引擎畜号，是為開發(fā)人員和系統(tǒng)管理員設計的用于構建缴阎、發(fā)布和運行分布式應用的平臺，典型的Docker平臺Kubernetes弄兜、Openshift V3药蜻、Flynn瓷式、Deis等。

Docker允許開發(fā)人員將各種應用以及依賴包打包到一個可移植的Docker容器中语泽，以Docker容器為資源分割和調度的基本單位贸典，封裝整個軟件運行時的環(huán)境，然后發(fā)布到Linux機器上踱卵。

Docker設計原理如上圖所示廊驼。按照Docker的設計方案，應用軟件的交付過程如同海上運輸惋砂，操作系統(tǒng)OS如同一個貨輪妒挎，每一個在OS基礎上的軟件都如同一個集裝箱，用戶可以通過標準化手段自由組裝運行環(huán)境西饵，同時集裝箱的內容可以由用戶自定義酝掩，也可以由專業(yè)人員（開發(fā)人員或系統(tǒng)管理員）定制，如此一來眷柔，交付一個應用軟件產(chǎn)品期虾，就相當于交付一系列標準化組件的集合。

一句話解釋Docker?

沒有集裝箱就沒有全球化驯嘱，Docker就是IT世界里的集裝箱镶苞。

有了容器，就需要編排管理容器的生命周期鞠评，kubernetes要了解一下茂蚓。

Kubernetes

說一下kubernetes，kubernetes一度被大家稱為云原生的基石剃幌。

K8s,全稱是Kubernetes聋涨。這個單詞來自于希臘語，含義是舵手或領航員锥忿。K8s是它的縮寫牛郑，用“8”字替代了“ubernete”這8個字符怠肋。

K8s并不是一件全新的發(fā)明敬鬓。它是谷歌根據(jù)其內部使用的 Borg 改造成的一個通用容器編排調度器，于2014年6月開源笙各，同年7月钉答，微軟、Red Hat杈抢、IBM数尿、Docker等公司，相繼加入K8s惶楼。2015年右蹦，谷歌將其捐贈給 Linux 基金會下屬的云原生計算基金會（CNCF）诊杆，K8s也成為CNCF第一個項目。

K8s的架構何陆，略微有一點復雜晨汹，我們簡單來看一下。

一個K8s系統(tǒng)贷盲，通常稱為一個K8s集群（Cluster）淘这。這個集群主要包括兩個部分：一個Master節(jié)點（主節(jié)點）和一群Node節(jié)點（計算節(jié)點）。

列舉下一些專用術語的解釋巩剖。

Master（主節(jié)點）：控制 K8s 節(jié)點的機器铝穷，也是創(chuàng)建作業(yè)任務的地方。

Node（節(jié)點）：這些機器在 K8s 主節(jié)點的控制下執(zhí)行被分配的任務佳魔。

Pod：由一個或多個容器構成的集合曙聂，作為一個整體被部署到一個單一節(jié)點。同一個 pod 中的容器共享 IP 地址鞠鲜、進程間通訊（IPC）筹陵、主機名以及其它資源。Pod 將底層容器的網(wǎng)絡和存儲抽象出來镊尺，使得集群內的容器遷移更為便捷朦佩。

Replicationcontroller（復制控制器）：控制一個 pod 在集群上運行的實例數(shù)量。

Service（服務）：將服務內容與具體的 pod 分離庐氮。Kubernetes服務代理負責自動將服務請求分發(fā)到正確的 pod 處语稠，不管 pod 移動到集群中的什么位置，甚至可以被替換掉弄砍。

Kubelet：這個守護進程運行在各個工作節(jié)點上仙畦，負責獲取容器列表，保證被聲明的容器已經(jīng)啟動并且正常運行音婶。

kubectl：?這是 Kubernetes 的命令行配置工具慨畸。

理解完K8s 部分專業(yè)術語，就大致對K8s有個了解了衣式。

云可以為我們提供穩(wěn)定而唾手可得的基礎設施寸士，但是業(yè)務上云成了一個難題，K8s 的出現(xiàn)與其說是從最初的容器編排解決方案開始碴卧，倒不如說是為了解決應用上云（即云原生應用）這個難題弱卡。

CNCF 中托管的一系列項目即致力于云原生應用整個生命周期的管理，從部署平臺住册、日志收集婶博、Service Mesh（服務網(wǎng)格）、服務發(fā)現(xiàn)荧飞、分布式追蹤凡人、監(jiān)控以及安全等各個領域通過開源軟件為我們提供一整套解決方案名党。

Google 通過將云應用進行抽象簡化出的 Kubernetes 中的各種概念對象，如Pod挠轴、Deployment兑巾、Job、StatefulSet 等忠荞，形成了Cloud Native 應用的通用可移植的模型蒋歌，Kubernetes 作為云應用的部署標準，直接面向業(yè)務應用委煤，大大提高了云應用的可移植性堂油，解決云廠商鎖定的問題，讓云應用可以在夸云之間無縫遷移碧绞，甚至用來管理混合云府框，成為企業(yè) IT 云平臺的新標準。

微服務

在介紹微服務時讥邻，首先得先理解什么是微服務迫靖，顧名思義，微服務得從兩個方面去理解兴使，什么是"微"系宜、什么是"服務"，微 狹義來講就是體積小发魄、著名的 "2 pizza 團隊" 很好的詮釋了這一解釋（2 pizza 團隊最早是亞馬遜 CEO Bezos提出來的盹牧，意思是說單個服務的設計，所有參與人從設計励幼、開發(fā)汰寓、測試、運維所有人加起來只需要2個披薩就夠了）苹粟。

而所謂服務有滑，一定要區(qū)別于系統(tǒng)，服務一個或者一組相對較小且獨立的功能單元嵌削，是用戶可以感知最小功能集毛好。

傳統(tǒng)的單體架構是以整個系統(tǒng)為單位進行部署，而微服務則是以每一個獨立組件（例如用戶服務掷贾，商品服務）為單位進行部署睛榄。對于單體應用，如果發(fā)現(xiàn)某一業(yè)務的請求量非常大想帅，那么是無法單獨擴展該業(yè)務的，只能拷貝整個單體應用啡莉，再部署一套環(huán)境港准，來實現(xiàn)集群旨剥。正因為單體應用的缺陷，才有了微服務浅缸。

微服務和單體應用的區(qū)別轨帜，可以用Martin Fowler的這張圖來解釋：

圖中左邊是單體架構的集群，右邊是微服務集群衩椒。

什么意思呢蚌父？比如根據(jù)每個服務的吞吐量不同，支付服務需要部署20臺機器毛萌，用戶服務需要部署30臺機器苟弛，而商品服務只需要部署10臺機器。這種靈活部署只有微服務架構才能實現(xiàn)阁将。

而近幾年流行的Docker膏秫，為微服務架構提供了有效的容器。

服務網(wǎng)格

服務網(wǎng)格( Service Mesh )是指用以處理服務與服務之間通信的基礎設施層做盅。其最早由Buoyant公司（開發(fā)Service Mesh項目Linkerd的公司）提出缤削，并在內部使用。該公司2016年9月29日第一次公開使用這個術語吹榴。

Service Mesh一般用于微服務應用的可配置基礎架構層( configurable infrastructure layer )亭敢。Istio( 由Google、IBM图筹、Lyft公司在背后進行支持 ) 是目前最廣為人知的一款服務網(wǎng)格架構吨拗。

Kubernetes(由Google最早進行設計并開源)是目前Istio唯一支持的容器組織框架。

為什么Service Mesh這么受歡迎婿斥？對許多公司來說劝篷，Docker 和 Kubernetes 這樣的工具已經(jīng) "解決了部署問題"，或者說幾乎解決了民宿。但他們還沒有解決運行時的問題娇妓，這就是服務網(wǎng)格的由來。

什么是解決了部署問題活鹰？使用 Docker 和 Kubernetes 等功能可顯著減輕部署的增量操作負擔哈恰。使用這些工具，部署100個應用或服務不再是部署單個應用的100倍志群。這是向前邁出的一大步着绷，對許多公司來說，這導致采用微服務的成本大幅降低锌云。這不僅是因為 Docker 和 Kubernetes 所提供了強大的抽象荠医，而且還因為它們使整個組織的打包和部署模式過程標準化了。

Service Mesh的出現(xiàn)，彌補了Kubernetes在微服務的連接彬向、管理和監(jiān)控方面的短板兼贡，為Kubernetes提供更好的應用和服務管理。因此娃胆，Service Mesh的代表Istio一經(jīng)推出遍希，就被認為是可以和Kubernetes形成雙劍合璧效果的微服務管理的利器，受到了業(yè)界的推崇里烦。

不可變基礎設施

在傳統(tǒng)的可變服務器基礎架構中凿蒜，服務器會不斷更新和修改。使用此類基礎架構的工程師和管理員可以通過SSH連接到他們的服務器胁黑，手動升級或降級軟件包废封，逐個服務器地調整配置文件，以及將新代碼直接部署到現(xiàn)有服務器上别厘。換句話說虱饿，這些服務器是可變的;它們可以在創(chuàng)建后進行更改。

可變基礎設施通常會導致以下問題：

在災難發(fā)生的時候触趴，難以重新構建服務氮发。持續(xù)過多的手工操作，缺乏記錄冗懦，會導致很難由標準初始化后的服務器來重新構建起等效的服務爽冕。

在服務運行過程中，持續(xù)的修改服務器披蕉，就猶如程序中的可變變量的值發(fā)生變化而引入的狀態(tài)不一致的并發(fā)風險颈畸。這些對于服務器的修改，同樣會引入中間狀態(tài)没讲，從而導致不可預知的問題眯娱。

不可變基礎架構是另一種基礎架構范例，其中服務器在部署后永遠不會被修改爬凑。程序設計中不可變變量（ImmutableVariable）就是在完成賦值后就不能發(fā)生更改徙缴，只能創(chuàng)建新的來整體替換舊的。由于具有這樣的特性這種變量可以在并發(fā)環(huán)境下安全的使用嘁信。對于基礎設施的不可變性于样，最基本的就是指運行服務的服務器在完成部署后，就不在進行更改潘靖。

不可變基礎架構的好處包括基礎架構中更高的一致性和可靠性穿剖，以及更簡單，更可預測的部署過程卦溢。

它可以緩解或完全防止可變基礎架構中常見的問題糊余，例如配置漂移和雪花服務器秀又。但是，有效地使用它通常包括全面的部署自動化啄刹，云計算環(huán)境中的快速服務器配置涮坐，以及處理狀態(tài)或短暫數(shù)據(jù)（如日志）的解決方案凄贩。

聲明式API

聲明式（Declarative）的編程方式一直都會被工程師們拿來與命令式（Imperative）進行對比誓军，這兩者是完全不同的編程方法。

我們最常接觸的其實是命令式編程疲扎，它要求我們描述為了達到某一個效果或者目標所需要完成的指令昵时，常見的編程語言 Go、Ruby椒丧、C++ 其實都為開發(fā)者了命令式的編程方法壹甥，

聲明式和命令式是兩種截然不同的編程方式:

在命令式 API 中，我們可以直接發(fā)出服務器要執(zhí)行的命令壶熏，例如： “運行容器”句柠、“停止容器”等；

在聲明式 API 中棒假，我們聲明系統(tǒng)要執(zhí)行的操作溯职，系統(tǒng)將不斷向該狀態(tài)驅動。

通俗的說帽哑，命令式編程是第一人稱谜酒，我要做什么，我要怎么做妻枕。 操作系統(tǒng)最喜歡這種編程范式了僻族， 操作系統(tǒng)幾乎不用"思考", 只要一對一的將代碼翻譯成指令就可以了。 而聲明式編程則類似于"第二人稱"屡谐， 也就是你要做什么述么。 有點"產(chǎn)品經(jīng)理"和"開發(fā)“之間的關系，"產(chǎn)品經(jīng)理"只負責提需求愕掏，而"開發(fā)"怎么實現(xiàn)他不并關心度秘。

讓我們來總結一下上面提到的技術和工具。

k8s是整個云原生的基石亭珍，云原生的整個生態(tài)體系都是依靠k8s建立起來的敷钾。 容器（Container）是k8s的底層引擎； Docker是應用最廣的容器工具肄梨； 微服務是docker的好搭檔阻荒； 服務網(wǎng)格是微服務的輔助，建立在k8s上的針對請求的擴展功能众羡； 不可變基礎設施是現(xiàn)代運維的基石侨赡； 聲明式API是k8s的編碼方式；

◆◆云原生應用價值◆◆

由于篇幅關系，簡單列舉三項云原生應用價值羊壹。

1）快速迭代

利用云原生應用程序開發(fā)蓖宦，意味著使用敏捷與可擴展的組件，如以Kubernetes為代表的容器來提供離散和可重用的功能油猫，這些功能以良好描述的方式集成稠茂，甚至跨越多云等技術邊界，這使得交付團隊可以使用重復的自動化和編排來快速迭代情妖。

2）自動部署

云原生方法遠優(yōu)于傳統(tǒng)的面向虛擬化的業(yè)務流程睬关，傳統(tǒng)方法需要投入大量的精力來構建開發(fā)環(huán)境，以及軟件交付過程中的其他不同環(huán)境毡证。而云原生架構具備自動化和組合功能电爹，并且依賴于可靠、經(jīng)過驗證和審核的已知良好流程的基礎料睛，交付十分敏捷丐箩，而不再需要人工干預重復執(zhí)行。

3）獨立高效

云原生帶來了微服務化架構恤煞，一個微服務基本是一個能獨立發(fā)布的應用服務屎勘，因此可以作為獨立組件升級、灰度或復用等阱州，對整個大應用的影響也較小挑秉，每個服務可以由專門的組織來單獨完成，依賴方只要定好輸入和輸出口即可完全開發(fā)苔货、甚至整個團隊的組織架構也會更精簡犀概，因此溝通成本低、效率高夜惭。

談云原生就要談云計算姻灶，不和云計算對比都是耍流氓。云計算的第一個浪潮是關于成本節(jié)約和業(yè)務敏捷性诈茧，尤其是云計算的基礎設施更加廉價产喉。

很多企業(yè)傾向于使用微服務架構來開發(fā)應用。微服務開發(fā)快速敢会，職責單一曾沈，能夠更快速的被客戶所采納。同時鸥昏，這些應用能夠通過快速迭代的方式塞俱，得到進化，贏得客戶的認可吏垮。云原生可以打通微服務開發(fā)障涯、測試罐旗、部署、發(fā)布的整個流程環(huán)節(jié)唯蝶。

云供應商為迎合市場九秀，提供了滿足各種場景方案的 API，例如用于定位的 Google Maps粘我，用于社交協(xié)作的認證平臺等鼓蜒。將所有這些 API 與企業(yè)業(yè)務的特性和功能混合在一起，可以讓他們?yōu)榭蛻魳嫿í毺氐姆桨竿康巍Ｋ羞@些整合都在 API 層面進行友酱。這意味著晴音，不管是移動應用還是傳統(tǒng)的桌面應用都能無縫集成柔纵。所以，采用云原生所開發(fā)的應用都且具備極強的可擴展性锤躁。

軟件不可能不出故障搁料。傳統(tǒng)的企業(yè)級開發(fā)方式，需要有專職人員來對企業(yè)應用進行監(jiān)控與維護系羞。而在云原生架構下郭计，底層的服務或者是API都由將部署到云中，等價于將繁重的運維工作轉移給了云平臺供應商椒振。這意味著客戶應用將得到更加專業(yè)的看護昭伸，同時，也節(jié)省了運維成本澎迎。

◆◆結 語◆◆

9年前庐杨，Netscape公司的創(chuàng)始人馬克·安德森說：“軟件正在吞噬世界”；6年前夹供，OpenStack基金會創(chuàng)始人Jonathan Bryce 補充說：“世界的一切源于開源”灵份；再之后，業(yè)內普遍認同“云計算已改變了天空的顏色”哮洽；但近兩年云計算概念又被清晰細分填渠，“云原生”才是那條最大的魚。

“大魚”來了鸟辅，我們能做的不是墨守成規(guī)氛什，而是擁抱“大魚”，時代在召喚云原生匪凉，但是云原生不是一蹴而就枪眉，而是有個循序漸進的過程。排斥云原生洒缀，了解云原生瑰谜，擁抱云原生欺冀，追隨云原生。

參考資料：

1.Kubernetes 是什么萨脑？隐轩，Linux中國

2.Kubernetes與云原生應用概覽，宋凈超

3.云原生的不同解釋及正確含義渤早，倚天碼農(nóng)

4.10分鐘看懂Docker和K8S职车，鮮棗課堂

5.CNCF官方大使張磊：什么是云原生？

如果閱讀有收獲鹊杖，求幫忙擴散文章悴灵！感謝！