理解了雲原生，才能正確迎接雲時代的到來

在探討過無服務器技術《沉寂多年，無服務器爆發，其硬核是什麼？丨技術前沿》和裸金屬技術《將來將是容器和裸金屬的天下，這話有道理嗎？| 技術前沿》的發展後，本篇咱們討論雲原生（Cloud Native）技術。

若是說無服務器和裸金屬的爆發屬於間歇性的，那雲原生這幾年的熱度就稱得上持續火熱，且隨着雲計算普及進程的不斷加深，有愈演愈烈的趨勢。今天再談雲原生已經不是少數幾個大企業的專屬，愈來愈多的企業正在擁抱它，享受它帶來的紅利。

究竟什麼是雲原生？能帶來什麼價值？本文第一篇將進行全面的梳理，後續將逐步介紹相關的技術和趨勢。

雲原生四要素

雲原生，顧名思義，面向雲而設計的。設計的什麼？一套方法、一套理念、一套工具……

最先人們對雲計算的認識就是改變了基礎資源的使用方式，業務會逐步遷移上雲。但如今再看呢？遠不止這一點。雲計算在從新構建IT運行的規則，「上雲」和「雲上」是兩個概念。上雲是過去對雲計算的認知，也就是遷移；而云上是如今及將來對雲計算的認知，是雲上從新構建，這是雲原生的本質。

舉個例子對比，上雲和雲上就像後天培養和天生就有，區別是顯而易見的。

進一步說，雲原生的概念最先由來自Pivotal的Matt Stine於2013年提出，一直延用至今。它是Matt Stine根據其多年的架構和諮詢經驗總結出來的一個思想集合，並獲得了社區的不斷完善，包含內容很是多，囊括衆多板塊，如：

DevOps

持續交付（Continuous Delivery）

微服務（MicroServices）

敏捷基礎設施（Agile Infrastructure）

12要素（The Twelve-Factor App）

……

不只有企業文化、組織架構的重組與建設，也有方法論與原則，以及具體的操做工具。

12要素已經說了不少年了，這裏將思惟導圖整理出來，供參考。

因此，雲原生不是一個具體的產品，也絕非是把原先在傳統IT架構中的東西搬上雲，而是基於雲的一種全新IT理念，必須是與之相關的包括應用的架構、應用的開發方式、應用的部署和維護方式都要作出改變，這樣才能真正發揮出雲的價值，包括彈性、動態調度、自動伸縮等，享受新IT技術帶來的紅利。

爲了更好地推動雲原生技術的發展，2015年由谷歌牽頭成立CNCF，即雲原生計算基金會。目前，基金會成員已有一百多家企業與機構，包括百度、亞馬遜、微軟、思科等巨頭。

當前，CNCF所託管的應用已達14個，下圖爲其公佈的Cloud Native Landscape，給出了雲原生生態的參考體系。

CNCF認爲雲原生系統應該具有三大特徵：

容器化封裝：以容器爲基礎，提升總體開發水平，造成代碼和組件重用，簡化雲原生應用程序的維護。在容器中運行應用程序和進程，並做爲應用程序部署的獨立單元，實現高水平資源隔離。

自動化管理：統一調度和管理中心，從根本上提升系統和資源利用率，同時下降運維成本。

面向微服務：經過鬆耦合方式，提高應用程序的總體敏捷性和可維護性。

要充分理解雲原生，必須對其每個板塊進行了解。而當前，業界對雲原生的見解是很是一致的，那就是四要素：持續交付、DevOps、微服務、容器。

一個一個展開。

容器，雲原生的基石

容器不是新概念，1979年就出現了。

不少人會將Docker與容器劃等號，其實否則，Docker只是容器理念最普及的一種應用技術。容器的英文單詞是Container，有集裝箱的含義，而借用集裝箱技術會很好理解容器的優點。集裝箱的特色，在於標準化，這樣能夠大量堆疊，裝卸也很方便。容器也是這樣。

與容器作比較的是虛擬化技術。早期，你們認爲硬件抽象層基於Hypervisor的虛擬化方式可以最大程度實現系統管理的靈活性，由於各類不一樣操做系統的虛擬機都能經過Hypervisor生成、運行、銷燬。可是，隨着時間推移發現，Hypervisor沒有想象的那麼好，由於它的原理是每一個虛擬機都要安裝一個完整的操做系統和大量的應用，而實際生產環境你們更關心的是本身部署的應用。顯然，若是每次都部署一個完整的操做系統和大量關聯的開發環境，開發效率、管理效率都會很低下。

因而有了容器這種方式，簡單說，它只把應用代碼運行所需相關的環境打包、封裝進了一個系統，就像集裝箱同樣，直接運走就行，不用關心船是什麼樣，到哪均可以跑起來。

容器技術有四大特色：

極其輕量：只打包了必要的Bin/Lib；

秒級部署：根據鏡像的不一樣，容器的部署大概在毫秒與秒之間（比虛擬機強不少）；

易於移植：一次構建，隨處部署；

彈性伸縮：Kubernetes、Swam、Mesos這類開源、方便、好使的容器管理平臺有着很是強大的彈性管理能力。

換句話說，使用容器，用戶能夠將微服務及其所需的各類配置、依賴關係和環境變量很方便的移動到全新的服務器節點上，而無需從新配置環境。

在容器領域，Docker是最受歡迎的容器格式標準。同時，與Docker配合使用的Kubernetes則成爲了容器編排和管理工具中的事實標準。

微服務，改變產品開發方式

微服務是什麼？重點在「微」。它的核心是將單個應用程序做爲一組小型服務來開發。原來一個產品的開發多是拆成幾個大的模塊，而後由幾個團隊來作，而後再合，微服務的理念是把一個產品拆的更細，可能一我的、幾我的負責一個服務的開發，每一個服務之間都是獨立的。

每一個服務都在本身的進程中運行，並使用輕量級機制（一般是基於HTTP的API）進行通訊。 這些服務是圍繞業務功能構建，能夠經過全自動部署機制獨立部署，不須要集中管理，能夠用不一樣的編程語言編寫，並使用不一樣的數據存儲技術。

因此，微服務核心就是服務粒度要小，每一個服務是針對一個單一職責的業務能力的封裝，專一作好一件事情。可是又不能過小，不然易發生「服務爆炸」。一般在工程實踐中，若是一個功能被兩個或兩個以上的服務調用，就能夠被封裝爲服務。

因此，微服務的優勢很明顯，小而美、鬆耦合、靈活、易集成，可是挑戰也很明顯，最大的問題在於服務如何切分。其實，早在1968年康威就提出了——康威定律，系統的服務劃分應該是根據組織架構的功能來劃分。這一點用在微服務領域也很是合適。

這樣按照組織架構劃分的優點在於：

1.內聚更強，全部遵循同一種業務準則的人內聚在一塊兒，就容易解決問題。

2.服務解耦，變動容易，更加敏捷。

DevOps，內部協做更緊密

DevOps，若是從字面上來理解，是Dev（開發）+Ops（運維）。

實際上，能夠把DevOps看做開發（軟件工程）、技術運營和質量保障（QA）三者的交集。DevOps是一組過程、方法與系統的統稱，用於促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協做與整合。

爲何要整合？由於能幫助企業提高效率。

衆所周知，傳統的軟件組織將開發、IT運營和質量保障設爲各自分離的部門。開發與運營之間存在着信息「鴻溝」──例如運營人員要求更好的可靠性和安全性，開發人員則但願基礎設施響應更快，而業務用戶的需求則是更快地將更多的特性發布給最終用戶使用。

每一個部門需求都不一樣，怎麼調和？DevOps的價值就體如今這。DevOps的引入能對產品交付、測試、功能開發和維護起到意義深遠的影響。其最大的價值在於，透過自動化「軟件交付」和「架構變動」的流程，能使得構建、測試、發佈軟件更加地快捷、頻繁和可靠，這是每個企業都指望的。

所以，更深層次的理解，DevOps是一種重視「軟件開發人員（Dev）」和「IT運維技術人員（Ops）」之間溝通合做的文化、運動。

持續交付，雲原生終極目標

如何理解持續交付？聽着比容器、微服務、DevOps更抽象。簡單來講，它是一種狀態，一種能力，就像生產線能持續交付產品同樣。

具體而言，持續交付是一種軟件工程手法，它能讓軟件產品的產出過程在一個短週期內完成，保證軟件能夠穩定、持續的保持在隨時能夠發佈的情況。它的目標在於讓軟件的構建、測試與發佈變得更快以及更頻繁。這種方式能夠減小軟件開發的成本與時間，減小風險。

爲何要有持續交付？這是和曾經的軟件開發方式相比的，過去的軟件開發週期以月、季度、年來計算，今天呢？一個應用晚上線一個小時形成的損失均可能是巨大的，因此要小步快跑、快速迭代，這就是持續交付的價值所在，不斷的交付，不斷的修正。

很顯然，若是把雲原生的四要素串聯起來，持續交付纔是最終目標。但要實現持續交付，容器、微服務、DevOps缺一不可。

總結一下，雲時代必須以全新的理念來看待軟件架構和基礎設施，只有從這個角度理解雲原生才能獲得正確的答案。將來必然是屬於雲原生的，因此，企業變革的毫不僅僅是工具，而是從思想到方法，再到工具的一整套理念。只有這樣，才能更好迎接雲時代的到來。

本文由百度開發者中心發佈，一個面向開發者的知識分享平臺,專一於爲開發者打造一個有溫度的技術交流社區,開發者經過平臺來分享知識、相互交流。 developer 發佈！