火熱的云原生到底是什么？一文了解云原生四要素！

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

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

　　云原生概念的誕生

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

　　The Twelve-Factor App

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

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

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

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

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

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

　　云原生計(jì)算基金會(huì)(CNCF)

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

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

　　Cloud Native Landscape新版

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

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

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

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

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

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

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

　　01

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

　　首先是持續(xù)交付，什么樣的時(shí)候客戶要求持續(xù)交付?敏捷開(kāi)發(fā)要求持續(xù)交付，因?yàn)槊艚蓍_(kāi)發(fā)要求隨時(shí)有一個(gè)版本可以上到大群環(huán)境，所以要持續(xù)交付。

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

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

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

　　圖：藍(lán)綠(Blue-Green) 部署

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

　　02

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

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

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

　　Going Agile - Breaking the monolith

　　Conway's Law and Microservices

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

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

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

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

　　那么在什么情況下需要微服務(wù)?我認(rèn)為有三個(gè)標(biāo)準(zhǔn)：

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

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

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

　　實(shí)際上，微服務(wù)需要關(guān)注的源代碼范圍比較小，使得各個(gè)服務(wù)解耦、變更容易，內(nèi)聚更強(qiáng)，因?yàn)槎紩?huì)集中在服務(wù)里。另外，它更容易單獨(dú)改版，因?yàn)槲⒎?wù)之間是用RESTful間接起來(lái)的，用RESTful只要API的界面不改，原則上則不會(huì)錯(cuò)，也更敏捷。

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

　　03

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

　　再來(lái)看看容器。在機(jī)器上運(yùn)行的容器只是主機(jī)操作系統(tǒng)上的一個(gè)進(jìn)程，與任何其他進(jìn)程無(wú)異。那么，為什么容器如此受歡迎呢?原因在于這個(gè)進(jìn)程被隔離和限制的方式。這種方式很特殊，可簡(jiǎn)化開(kāi)發(fā)和運(yùn)維。

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

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

　　從 Infra 角度來(lái)看技術(shù)演進(jìn)

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

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

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

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

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

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

　　04

　　DevOps——以終為始，運(yùn)維合一

　　最后讓我們走向DevOps，它不是一種工具，DevOps其實(shí)要談的是運(yùn)維合一。

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

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

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

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

　　總結(jié)

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

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