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

隨著虛擬化技術的成熟和分散式架構的普及，用來部署、管理和執行應用的雲平臺被越來越多的提及。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

物聯網智庫 整理髮布

轉載請註明來源和出處

&n