摘要：所謂云原生，它不是一個產(chǎn)品，而是一套技術(shù)體系和一套方法論，而數(shù)字化轉(zhuǎn)型是思想先行，從內(nèi)到外的整體變革。更確切地說，它是一種文化，更是一種潮流，是云計算的一個必然導(dǎo)向。

隨著虛擬化技術(shù)的成熟和分布式架構(gòu)的普及，用來部署、管理和運行應(yīng)用的云平臺被越來越多的提及。IaaS、PaaS和SaaS是云計算的3種基本服務(wù)類型，它們是關(guān)注硬件基礎(chǔ)設(shè)施的基礎(chǔ)設(shè)施即服務(wù)、關(guān)注軟件和中間件平臺的平臺即服務(wù)以及關(guān)注業(yè)務(wù)應(yīng)用的軟件即服務(wù)。

在容器技術(shù)、可持續(xù)交付、編排系統(tǒng)等開源社區(qū)的推動下，以及微服務(wù)等開發(fā)理念的帶動下，應(yīng)用上云已經(jīng)是不可逆轉(zhuǎn)的趨勢。隨著云化技術(shù)的不斷進展，云原生的概念也應(yīng)運而生。

云原生概念的誕生

云原生（Cloud Native）的概念，由來自Pivotal的MattStine于2013年首次提出，被一直延續(xù)使用至今。這個概念是Matt Stine根據(jù)其多年的架構(gòu)和咨詢經(jīng)驗總結(jié)出來的一個思想集合，并得到了社區(qū)的不斷完善，內(nèi)容非常多，包括DevOps、持續(xù)交付（Continuous Delivery）、微服務(wù)（MicroServices）、敏捷基礎(chǔ)設(shè)施（Agile Infrastructure）和12要素（The Twelve-Factor App）等幾大主題，不但包括根據(jù)業(yè)務(wù)能力對公司進行文化、組織架構(gòu)的重組與建設(shè)，也包括方法論與原則，還有具體的操作工具。采用基于云原生的技術(shù)和管理方法，可以更好地把業(yè)務(wù)生于“云”或遷移到云平臺，從而享受“云”的高效和持續(xù)的服務(wù)能力。

The Twelve-Factor App

顧名思義，云原生是面向“云”而設(shè)計的應(yīng)用，因此技術(shù)部分依賴于傳統(tǒng)云計算的3層概念，基礎(chǔ)設(shè)施即服務(wù)（IaaS）、平臺即服務(wù)（PaaS）和軟件即服務(wù)（SaaS），例如，敏捷的不可變基礎(chǔ)設(shè)施交付類似于IaaS，用來提供計算網(wǎng)絡(luò)存儲等基礎(chǔ)資源，這些資源是可編程且不可變的，直接通過API可以對外提供服務(wù)；有些應(yīng)用通過PaaS服務(wù)本來就能組合成不同的業(yè)務(wù)能力，不一定需要從頭開始建設(shè)；還有一些軟件只需要“云”的資源就能直接運行起來為云用戶提供服務(wù)，即SaaS能力，用戶直接面對的就是原生的應(yīng)用。

云原生并不是一個產(chǎn)品

最近討論云原生應(yīng)用越來越多。關(guān)于云原生應(yīng)用，簡單地說，就是大多數(shù)傳統(tǒng)的應(yīng)用，不做任何改動，都是可以在云平臺運行起來，只要云平臺支持這個傳統(tǒng)應(yīng)用所運行的計算機架構(gòu)和操作系統(tǒng)。只不過這種運行模式，僅僅是把虛擬機當物理機一樣使用，不能夠真正利用起來云平臺的能力。

云并非把原先在物理服務(wù)器上跑的東西放到虛擬機里跑，真正的云化不僅是基礎(chǔ)設(shè)施和平臺的事情，應(yīng)用也要做出改變，改變傳統(tǒng)的做法，實現(xiàn)云化的應(yīng)用——應(yīng)用的架構(gòu)、應(yīng)用的開發(fā)方式、應(yīng)用部署和維護技術(shù)都要做出改變，真正的發(fā)揮云的彈性、動態(tài)調(diào)度、自動伸縮……一些傳統(tǒng)IT所不具備的能力。這里說的“云化的應(yīng)用”也就是“云原生應(yīng)用”。云原生架構(gòu)和云原生應(yīng)用所涉及的技術(shù)很多，如容器技術(shù)、微服務(wù)、可持續(xù)交付、DevOps等。

而云原生應(yīng)用最大的特點就是可以迅速部署新業(yè)務(wù)。在企業(yè)里，提供新的應(yīng)用程序環(huán)境及部署軟件新版本通常所需時間以日、周甚至以月計算。這種速度嚴重限制了軟件發(fā)布所能承受的風(fēng)險，因為犯錯及改錯也需要花費同樣的時間成本，競爭優(yōu)勢就會由此產(chǎn)生。

所以云原生不是一個產(chǎn)品，而是一套技術(shù)體系和一套方法論，而數(shù)字化轉(zhuǎn)型是思想先行，從內(nèi)到外的整體變革。更確切地說，它是一種文化，更是一種潮流，是云計算的一個必然導(dǎo)向。意義在于讓云成為云化戰(zhàn)略成功的基石，而不是障礙。它可以根據(jù)商業(yè)能力對公司進行重組的能力，既包含技術(shù)、也包含管理，可以說是一系列云技術(shù)和企業(yè)管理方法的集合，通過實踐及與其他工具相結(jié)合更好地幫助用戶實現(xiàn)數(shù)字化轉(zhuǎn)型。

云原生計算基金會（CNCF）

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

目前CNCF所托管的應(yīng)用已達14個，下圖為其公布的Cloud Native Landscape，給出了云原生生態(tài)的參考體系。

Cloud Native Landscape新版

CNCF(云原生計算基金會)認為云原生系統(tǒng)需包含的屬性：

容器化封裝：以容器為基礎(chǔ)，提高整體開發(fā)水平，形成代碼和組件重用，簡化云原生應(yīng)用程序的維護。在容器中運行應(yīng)用程序和進程，并作為應(yīng)用程序部署的獨立單元，實現(xiàn)高水平資源隔離。

自動化管理：統(tǒng)一調(diào)度和管理中心，從根本上提高系統(tǒng)和資源利用率，同時降低運維成本。

面向微服務(wù)：通過松耦合方式，提升應(yīng)用程序的整體敏捷性和可維護性。

正因為如此，你可以專注于創(chuàng)新，解決業(yè)務(wù)問題，而不是把時間花在“靜態(tài)、不靈活的傳統(tǒng)架構(gòu)”存在的許多技術(shù)問題。

云原生的四要素：持續(xù)交付、DevOps、微服務(wù)、容器

從云原生的概念中，我們總是能看到持續(xù)交付、DevOps、微服務(wù)、容器等技術(shù)的出現(xiàn)，那么它們到底是什么，這里引用Pivotal***云計算資深架構(gòu)師的部分觀點，為大家逐一揭開他們的神秘面紗！

01

持續(xù)交付——縮小開發(fā)者認知，靈活開發(fā)方向

首先是持續(xù)交付，什么樣的時候客戶要求持續(xù)交付？敏捷開發(fā)要求持續(xù)交付，因為敏捷開發(fā)要求隨時有一個版本可以上到大群環(huán)境，所以要持續(xù)交付。

而換句話說，持續(xù)交付就是不誤時開發(fā)。舉一個例子，有些公司非常喜歡談需求，談很久，可是開發(fā)只剩1/3時間就開發(fā)完成，然后交付，再上線運營。這就會碰到一個問題，就是你開始談需求到最后交付產(chǎn)品的時間，短則三月，長則半年，這中間市場已經(jīng)變化了，需求也隨之變化了。因此市場上出現(xiàn)了新的想法，即是不是能夠小步快跑，把交付的周期縮短一點，我可以實現(xiàn)快速交付，每次交付都可以重新確認方向，這樣盡量避免與未來期待的落差。

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

那么問題來了，持續(xù)交付對于開發(fā)的人談的需求、開發(fā)的方式有改變，那它對于開發(fā)有影響嗎？如果說公司的開發(fā)團隊一天可以交付五次，那研發(fā)團隊要幫忙部署一次嗎？現(xiàn)在公司大部分部署都是研發(fā)團隊幫忙部署應(yīng)用的，研發(fā)團隊部署五次，要改版五次就需要部署一次，這是無法實現(xiàn)的。而且每次部署的時候都要面對停機，而實際公司的應(yīng)用經(jīng)不起一天停機五次部署，在互聯(lián)網(wǎng)的思維之下，零宕機時間已經(jīng)是現(xiàn)在企業(yè)的基本要求。于是“藍綠部署”的概念營運而生。即在一個環(huán)境里面，第一版還在線上服務(wù)，第二版先做封測，封測完成后，讓外面的流量進來一些，看log是不是開發(fā)人員要的，確認后再把全部的流量導(dǎo)到新的版本上。

圖：藍綠(Blue-Green)部署

但“藍綠部署”在系統(tǒng)過多過復(fù)雜的情況下，在傳統(tǒng)架構(gòu)上實現(xiàn)非常困難，所以企業(yè)要做到zero down time的持續(xù)交付就需要有良好的平臺與工具協(xié)助。因此，持續(xù)交付的優(yōu)勢在于，它可以縮小開發(fā)者認知，重新確認開發(fā)方向。

02

微服務(wù)——內(nèi)聚更強，更加敏捷

第二部分是微服務(wù)。微服務(wù)是什么？有客戶表示，提供商出產(chǎn)品，客戶把應(yīng)用全部放上去，結(jié)果就是一個微服務(wù)。這種認知是錯誤的，因為微服務(wù)是一個架構(gòu)的改變。那么微服務(wù)是怎么做的呢？它所面臨的最大挑戰(zhàn)是什么？

是切割。那么如何切割呢？其實這件事情早在1968年康威就提出了——康威定律，系統(tǒng)的服務(wù)劃分應(yīng)該是根據(jù)組織架構(gòu)的功能來劃分。1968年康威就提出了這個想法，我認為拿來做微服務(wù)的切割非常適用。

Going Agile - Breaking the monolith

Conway's Law and Microservices

這樣按照組織架構(gòu)劃分的優(yōu)勢在于：

1.內(nèi)聚更強，所有遵循同一種業(yè)務(wù)準則的人內(nèi)聚在一起，就容易解決問題。

2.服務(wù)解耦，變更容易，更加敏捷。當做到解耦合的時候，要變更就容易。所以微服務(wù)應(yīng)該是切分成這個樣子，由上而下來切，根據(jù)Function來切。

另外一個劃分微服務(wù)的技巧，可以運用領(lǐng)域驅(qū)動設(shè)計(Domain Driven Design)的理論，而領(lǐng)域驅(qū)動設(shè)計亦可算是面向物件的一種設(shè)計思維；聚合可以讓微服務(wù)劃分更有依據(jù)，也讓未來的系統(tǒng)變更具有彈性。值得一提的是領(lǐng)域驅(qū)動設(shè)計，也提供微服務(wù)中的事物問題。因為過去巨石應(yīng)用進行兩個報數(shù)的階段，相當容易也常見，但在微服務(wù)架構(gòu)中，如何在分散的服務(wù)中進行事物就顯得相當困難。利用領(lǐng)域驅(qū)動設(shè)計的Event Souring進行設(shè)計，是目前最好的解決辦法。

那么在什么情況下需要微服務(wù)？我認為有三個標準：

1.有HA（High Available）的需求需要微服務(wù)。

2.有性能調(diào)校的需求（例如：圖片的呈現(xiàn)或者搜尋）需要微服務(wù)。

3.經(jīng)常變更的需要微服務(wù)。

實際上，微服務(wù)需要關(guān)注的源代碼范圍比較小，使得各個服務(wù)解耦、變更容易，內(nèi)聚更強，因為都會集中在服務(wù)里。另外，它更容易單獨改版，因為微服務(wù)之間是用RESTful間接起來的，用RESTful只要API的界面不改，原則上則不會錯，也更敏捷。

但微服務(wù)也會留下一些問題，例如App團隊如何分工？環(huán)境怎么配合？如何實現(xiàn)自動化部署?

03

容器技術(shù)——使資源調(diào)度、微服務(wù)更容易

再來看看容器。在機器上運行的容器只是主機操作系統(tǒng)上的一個進程，與任何其他進程無異。那么，為什么容器如此受歡迎呢？原因在于這個進程被隔離和限制的方式。這種方式很特殊，可簡化開發(fā)和運維。

其實1979年就有容器技術(shù)，很多人會以為說Docker是不是等于容器，其實Docker不等于容器。容器的歷史可追溯到Linux操作系統(tǒng)。容器利用了Linux的內(nèi)核功能。Linux中容器的核心概念（cgroup、namespaces和filesystems）在獨立的區(qū)域運行。容器的神奇之處在于將這些技術(shù)融為一體，以實現(xiàn)最大的便利性。

VMware之前的技術(shù)專家在2011年發(fā)展出一個技術(shù)，把這個技術(shù)貢獻出來成立了一個Cloud Foundry基金會。Docker在2013年才開始有，而且它第一版是用SLC的技術(shù)去做的。后來陸續(xù)一路成長，使得為服務(wù)的實現(xiàn)更容易了。

從 Infra 角度來看技術(shù)演進

從上面這個表中可以看出，從左邊開始，IaaS，虛擬化技術(shù)有了之后，剛剛提到的所謂第三代平臺，這四個區(qū)塊開發(fā)人員交付的內(nèi)容不一樣。所有的IaaS、CaaS、PaaS、FaaS一路的變化演進，對于客戶的負擔(dān)越到后面越小，而對于開發(fā)人員的想象力則愈發(fā)抽象。

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

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

Kubernetes是軟件容器領(lǐng)域的另一個值得關(guān)注的項目。Kubernetes是一個允許自動化部署、管理和伸縮容器的工具。為了便于管理其容器，谷歌建立了Kubernetes。它提供了一些強大的功能，例如容器之間的負載均衡，重啟失敗的容器以及編排容器使用的存儲。

容器生態(tài)圖 /作者：Jimmy Song

容器為云原生應(yīng)用程序增加了更多優(yōu)勢。使用容器，你可以將微服務(wù)及其所需的所有配置、依賴關(guān)系和環(huán)境變量移動到全新的服務(wù)器節(jié)點上，而無需重新配置環(huán)境，這樣就實現(xiàn)了強大的可移植性。

04

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

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

DevOps如果從字面上來理解只是Dev（開發(fā)人員）+Ops（運維人員），實際上，它是一組過程、方法與系統(tǒng)的統(tǒng)稱，其概念從2009年首次提出發(fā)展到現(xiàn)在，內(nèi)容也非常豐富，有理論也有實踐，包括組織文化、自動化、精益、反饋和分享等不同方面。

首先，組織架構(gòu)、企業(yè)文化與理念等，需要自上而下設(shè)計，用于促進開發(fā)部門、運維部門和質(zhì)量保障部門之間的溝通、協(xié)作與整合，簡單而言組織形式類似于系統(tǒng)分層設(shè)計。

其次，自動化是指所有的操作都不需要人工參與，全部依賴系統(tǒng)自動完成，比如上述的持續(xù)交付過程必須自動化才有可能完成快速迭代。再次，DevOps的出現(xiàn)是由于軟件行業(yè)日益清晰地認識到，為了按時交付軟件產(chǎn)品和服務(wù)，開發(fā)部門和運維部門必須緊密合作。

總之，DevOps強調(diào)的是高效組織團隊之間如何通過自動化的工具協(xié)作和溝通來完成軟件的生命周期管理，從而更快、更頻繁地交付更穩(wěn)定的軟件。在內(nèi)部溝通上，你可以想象DevOps是一個敏捷思維，是一個溝通的文化。當運營和研發(fā)有良好的溝通效率，才可以有更大的生產(chǎn)力。如果你的自動化程度夠高，可以自主可控，工作負擔(dān)降低，DevOps能夠帶來更好的工作文化、更高的工作效率。

總結(jié)

綜上所述，云原生的DevOps、平臺、持續(xù)交付、微服務(wù)都是云原生不可或缺的一部分，需要以全局地眼光看待問題，脫離任何一個元素，對于企業(yè)來說都是“管中窺豹”、“一葉障目”，只有加以整合才能見到云原生的全局風(fēng)貌。

面對業(yè)態(tài)各異的業(yè)務(wù)上云以及碎片化的物聯(lián)網(wǎng)解決方案部署，利用云原生思維和模式，構(gòu)建基于云原生的物聯(lián)網(wǎng)平臺以及解決方案，勢必將加速企業(yè)，甚至整個社會的數(shù)字化轉(zhuǎn)型。