火熱的雲原生究竟是什麼？一文了解雲原生四要素！

所謂雲原生，它不是一個產品，而是一套技術體系和一套方法論，而數字化轉型是思想先行，從內到外的總體變革。更確切地說，它是一種文化，更是一種潮流，是雲計算的一個必然導向。

隨着虛擬化技術的成熟和分佈式架構的普及，用來部署、管理和運行應用的雲平臺被愈來愈多的說起。IaaS、PaaS和SaaS是雲計算的3種基本服務類型，它們是關注硬件基礎設施的基礎設施即服務、關注軟件和中間件平臺的平臺即服務以及關注業務應用的軟件即服務。

在容器技術、可持續交付、編排系統等開源社區的推進下，以及微服務等開發理念的帶動下，應用上雲已是不可逆轉的趨勢。隨着雲化技術的不斷進展，雲原生的概念也應運而生。

雲原生概念的誕生

雲原生（Cloud Native）的概念，由來自Pivotal的MattStine於2013年首次提出，被一直延續使用至今。這個概念是Matt Stine根據其多年的架構和諮詢經驗總結出來的一個思想集合，並獲得了社區的不斷完善，內容很是多，包括DevOps、持續交付（Continuous Delivery）、微服務（MicroServices）、敏捷基礎設施（Agile Infrastructure）和12要素（The Twelve-Factor App）等幾大主題，不但包括根據業務能力對公司進行文化、組織架構的重組與建設，也包括方法論與原則，還有具體的操做工具。採用基於雲原生的技術和管理方法，能夠更好地把業務生於「雲」或遷移到雲平臺，從而享受「雲」的高效和持續的服務能力。

The Twelve-Factor App

顧名思義，雲原生是面向「雲」而設計的應用，所以技術部分依賴於傳統雲計算的3層概念，基礎設施即服務（IaaS）、平臺即服務（PaaS）和軟件即服務（SaaS），例如，敏捷的不可變基礎設施交付相似於IaaS，用來提供計算網絡存儲等基礎資源，這些資源是可編程且不可變的，直接經過API能夠對外提供服務；有些應用經過PaaS服務原本就能組合成不一樣的業務能力，不必定須要從頭開始建設；還有一些軟件只須要「雲」的資源就能直接運行起來爲雲用戶提供服務，即SaaS能力，用戶直接面對的就是原生的應用。

雲原生並非一個產品

最近討論雲原生應用愈來愈多。關於雲原生應用，簡單地說，就是大多數傳統的應用，不作任何改動，都是能夠在雲平臺運行起來，只要雲平臺支持這個傳統應用所運行的計算機架構和操做系統。只不過這種運行模式，僅僅是把虛擬機當物理機同樣使用，不可以真正利用起來雲平臺的能力。

雲並不是把原先在物理服務器上跑的東西放到虛擬機裏跑，真正的雲化不只是基礎設施和平臺的事情，應用也要作出改變，改變傳統的作法，實現雲化的應用——應用的架構、應用的開發方式、應用部署和維護技術都要作出改變，真正的發揮雲的彈性、動態調度、自動伸縮……一些傳統IT所不具有的能力。這裏說的「雲化的應用」也就是「雲原生應用」。雲原生架構和雲原生應用所涉及的技術不少，如容器技術、微服務、可持續交付、DevOps等。

而云原生應用最大的特色就是能夠迅速部署新業務。在企業裏，提供新的應用程序環境及部署軟件新版本一般所需時間以日、周甚至以月計算。這種速度嚴重限制了軟件發佈所能承受的風險，由於犯錯及改錯也須要花費一樣的時間成本，競爭優點就會由此產生。

因此雲原生不是一個產品，而是一套技術體系和一套方法論，而數字化轉型是思想先行，從內到外的總體變革。更確切地說，它是一種文化，更是一種潮流，是雲計算的一個必然導向。意義在於讓雲成爲雲化戰略成功的基石，而不是障礙。它能夠根據商業能力對公司進行重組的能力，既包含技術、也包含管理，能夠說是一系列雲技術和企業管理方法的集合，經過實踐及與其餘工具相結合更好地幫助用戶實現數字化轉型。

雲原生計算基金會（CNCF）

CNCF，即雲原生計算基金會，2015年由谷歌牽頭成立，基金會成員目前已有一百多企業與機構，包括亞馬遜、微軟、思科等巨頭。

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

Cloud Native Landscape新版

CNCF(雲原生計算基金會)認爲雲原生系統需包含的屬性：

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

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

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

正由於如此，你能夠專一於創新，解決業務問題，而不是把時間花在「靜態、不靈活的傳統架構」存在的許多技術問題。

雲原生的四要素：持續交付、DevOps、微服務、容器

從雲原生的概念中，咱們老是能看到持續交付、DevOps、微服務、容器等技術的出現，那麼它們究竟是什麼，這裏引用Pivotal臺灣雲計算資深架構師的部分觀點，爲你們逐一揭開他們的神祕面紗！

01

持續交付——縮小開發者認知，靈活開發方向

首先是持續交付，什麼樣的時候客戶要求持續交付？敏捷開發要求持續交付，由於敏捷開發要求隨時有一個版本能夠上到大羣環境，因此要持續交付。

而換句話說，持續交付就是不誤時開發。舉一個例子，有些公司很是喜歡談需求，談好久，但是開發只剩1/3時間就開發完成，而後交付，再上線運營。這就會碰到一個問題，就是你開始談需求到最後交付產品的時間，短則三月，長則半年，這中間市場已經變化了，需求也隨之變化了。所以市場上出現了新的想法，便是不是可以小步快跑，把交付的週期縮短一點，我能夠實現快速交付，每次交付均可以從新確認方向，這樣儘可能避免與將來期待的落差。

用小步快跑的方式，打破瀑布式開發流程

那麼問題來了，持續交付對於開發的人談的需求、開發的方式有改變，那它對於開發有影響嗎？若是說公司的開發團隊一天能夠交付五次，那研發團隊要幫忙部署一次嗎？如今公司大部分部署都是研發團隊幫忙部署應用的，研發團隊部署五次，要改版五次就須要部署一次，這是沒法實現的。並且每次部署的時候都要面對停機，而實際公司的應用經不起一天停機五次部署，在互聯網的思惟之下，零宕機時間已是如今企業的基本要求。因而「藍綠部署」的概念營運而生。即在一個環境裏面，初版還在線上服務，第二版先作封測，封測完成後，讓外面的流量進來一些，看log是否是開發人員要的，確認後再把所有的流量導到新的版本上。

圖：藍綠(Blue-Green) 部署

但「藍綠部署」在系統過多過複雜的狀況下，在傳統架構上實現很是困難，因此企業要作到zero down time的持續交付就須要有良好的平臺與工具協助。所以，持續交付的優點在於，它能夠縮小開發者認知，從新確認開發方向。

02

微服務——內聚更強，更加敏捷

第二部分是微服務。微服務是什麼？有客戶表示，提供商出產品，客戶把應用所有放上去，結果就是一個微服務。這種認知是錯誤的，由於微服務是一個架構的改變。那麼微服務是怎麼作的呢？它所面臨的最大挑戰是什麼？

是切割。那麼如何切割呢？其實這件事情早在1968年康威就提出了——康威定律，系統的服務劃分應該是根據組織架構的功能來劃分。1968年康威就提出了這個想法，我認爲拿來作微服務的切割很是適用。

Going Agile - Breaking the monolith

Conway's Law and Microservices

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

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

2.服務解耦，變動容易，更加敏捷。當作到解耦合的時候，要變動就容易。因此微服務應該是切分紅這個樣子，由上而下來切，根據Function來切。

另一個劃分微服務的技巧，能夠運用領域驅動設計(Domain Driven Design)的理論，而領域驅動設計亦可算是面向物件的一種設計思惟；聚合可讓微服務劃分更有依據，也讓未來的系統變動具備彈性。值得一提的是領域驅動設計，也提供微服務中的事物問題。由於過去巨石應用進行兩個報數的階段，至關容易也常見，但在微服務架構中，如何在分散的服務中進行事物就顯得至關困難。利用領域驅動設計的Event Souring進行設計，是目前最好的解決辦法。

那麼在什麼狀況下須要微服務？我認爲有三個標準：

1.有HA（High Available）的需求須要微服務。

2.有性能調校的需求（例如：圖片的呈現或者搜尋）須要微服務。

3.常常變動的須要微服務。

實際上，微服務須要關注的源代碼範圍比較小，使得各個服務解耦、變動容易，內聚更強，由於都會集中在服務裏。另外，它更容易單獨改版，由於微服務之間是用RESTful間接起來的，用RESTful只要API的界面不改，原則上則不會錯，也更敏捷。

但微服務也會留下一些問題，例如App團隊如何分工？環境怎麼配合？如何實現自動化部署?

03

容器技術——使資源調度、微服務更容易

再來看看容器。在機器上運行的容器只是主機操做系統上的一個進程，與任何其餘進程無異。那麼，爲何容器如此受歡迎呢？緣由在於這個進程被隔離和限制的方式。這種方式很特殊，可簡化開發和運維。

其實1979年就有容器技術，不少人會覺得說Docker是否是等於容器，其實Docker不等於容器。容器的歷史可追溯到Linux操做系統。容器利用了Linux的內核功能。Linux中容器的核心概念（cgroup、namespaces和filesystems）在獨立的區域運行。容器的神奇之處在於將這些技術融爲一體，以實現最大的便利性。

VMware以前的技術專家在2011年發展出一個技術，把這個技術貢獻出來成立了一個Cloud Foundry基金會。Docker在2013年纔開始有，並且它初版是用SLC的技術去作的。後來陸續一路成長，使得爲服務的實現更容易了。

從 Infra 角度來看技術演進

從上面這個表中能夠看出，從左邊開始，IaaS，虛擬化技術有了以後，剛剛提到的所謂第三代平臺，這四個區塊開發人員交付的內容不同。全部的IaaS、CaaS、PaaS、FaaS一路的變化演進，對於客戶的負擔越到後面越小，而對於開發人員的想象力則愈發抽象。

你們必定會遇到下列這些計算，一個是所謂的單體應用，或者翻譯成巨石應用。此外，大家必定會有一些批次的管理，另外就是所謂的數據庫的部分，開始可能會有容器技術，像K8S、Dock。

Docker是軟件行業最受歡迎的軟件容器項目之一。思科、谷歌和IBM等公司在其基礎設施和產品中使用Docker容器。

Kubernetes是軟件容器領域的另外一個值得關注的項目。Kubernetes是一個容許自動化部署、管理和伸縮容器的工具。爲了便於管理其容器，谷歌創建了Kubernetes。它提供了一些強大的功能，例如容器之間的負載均衡，重啓失敗的容器以及編排容器使用的存儲。

容器生態圖 /做者：Jimmy Song

容器爲雲原生應用程序增長了更多優點。使用容器，你能夠將微服務及其所需的全部配置、依賴關係和環境變量移動到全新的服務器節點上，而無需從新配置環境，這樣就實現了強大的可移植性。

04

DevOps——以終爲始，運維合一

最後讓咱們走向DevOps，它不是一種工具，DevOps其實要談的是運維合一。

DevOps若是從字面上來理解只是Dev（開發人員）+Ops（運維人員），實際上，它是一組過程、方法與系統的統稱，其概念從2009年首次提出發展到如今，內容也很是豐富，有理論也有實踐，包括組織文化、自動化、精益、反饋和分享等不一樣方面。

首先，組織架構、企業文化與理念等，須要自上而下設計，用於促進開發部門、運維部門和質量保障部門之間的溝通、協做與整合，簡單而言組織形式相似於系統分層設計。

其次，自動化是指全部的操做都不須要人工參與，所有依賴系統自動完成，好比上述的持續交付過程必須自動化纔有可能完成快速迭代。再次，DevOps的出現是因爲軟件行業日益清晰地認識到，爲了按時交付軟件產品和服務，開發部門和運維部門必須緊密合做。

總之，DevOps強調的是高效組織團隊之間如何經過自動化的工具協做和溝通來完成軟件的生命週期管理，從而更快、更頻繁地交付更穩定的軟件。在內部溝通上，你能夠想象DevOps是一個敏捷思維，是一個溝通的文化。當運營和研發有良好的溝通效率，才能夠有更大的生產力。若是你的自動化程度夠高，能夠自主可控，工做負擔下降，DevOps可以帶來更好的工做文化、更高的工做效率。

總結

綜上所述，雲原生的DevOps、平臺、持續交付、微服務都是雲原生不可或缺的一部分，須要以全局地眼光看待問題，脫離任何一個元素，對於企業來講都是「管中窺豹」、「一葉障目」，只有加以整合才能見到雲原生的全局風貌。

面對業態各異的業務上雲以及碎片化的物聯網解決方案部署，利用雲原生思惟和模式，構建基於雲原生的物聯網平臺以及解決方案，勢必將加速企業，甚至整個社會的數字化轉型。

---

 原文連接：http://www.sohu.com/a/255182751_219833

資料來源：51CTO、網易、Pivotal

物聯網智庫 整理髮布

轉載請註明來源和出處