什么是cloud-native?cloud-native框架、cloud-native運(yùn)行時(shí)和cloud-native基礎(chǔ)設(shè)施的自動(dòng)化又有哪些內(nèi)容?讀完這篇文章，就能有一個(gè)大概的了解。

你能做到每周、每天甚至每個(gè)鐘頭向客戶發(fā)布新特性嗎?新加入的開發(fā)者能夠在他們工作的***天甚至面試階段就能部署代碼嗎?部署新員工的代碼后，你能因?yàn)榇_信應(yīng)用程序運(yùn)行正常而安然入睡嗎?建立快速發(fā)布機(jī)制，包括支持cloud-native應(yīng)用的安全與可靠的運(yùn)維的流程、工具和文化，已經(jīng)成為軟件驅(qū)動(dòng)組織的關(guān)鍵戰(zhàn)略因素。有了快速發(fā)布機(jī)制，這些組織就能在降低風(fēng)險(xiǎn)的同時(shí)更快地發(fā)布軟件。發(fā)布軟件越快，得到的反饋循環(huán)就越緊密，企業(yè)就能更有效地響應(yīng)客戶的需要。

持續(xù)交付是軟件正在變成cloud-native應(yīng)用的原因：更快地交付軟件，降低反饋循環(huán)的時(shí)間。完全實(shí)現(xiàn)cloud-native戰(zhàn)略，需要文化和技術(shù)兩方面的改變，DevOps是應(yīng)對(duì)這些改變的方法。微服務(wù)是應(yīng)用最成功的軟件體系架構(gòu)模式，它擴(kuò)展了開發(fā)和交付操作，避免緩慢、充滿風(fēng)險(xiǎn)的單體部署策略。例如，如果還沒有建立“快速失敗”和“自動(dòng)優(yōu)先”的 DevOps 文化，很難成功地實(shí)施微服務(wù)戰(zhàn)略。

持續(xù)交付、DevOps和微服務(wù)分別描述了cloud-native應(yīng)用的為什么、怎么做和是什么。這些競(jìng)爭(zhēng)優(yōu)勢(shì)迅速成為玩轉(zhuǎn)軟件游戲的賭注。深究起來，上述三個(gè)概念糾纏在一起，不可區(qū)分。這就是cloud-native的含義所在。

cloud-native能做些什么?

貫穿軟件交付生命周期的cloud-native能讓用戶更有效地運(yùn)維和擴(kuò)展，成功擁有“敏捷性”：能夠快速為軟件添加新功能，同時(shí)保持生產(chǎn)環(huán)境的穩(wěn)定性和安全性。cloud-native能做到這一點(diǎn)的原因是它把運(yùn)行應(yīng)用程序所需的基礎(chǔ)設(shè)施、中間件和后臺(tái)服務(wù)完全自動(dòng)化。

傳統(tǒng)的自動(dòng)化方法建立在面向虛擬化的編排的基礎(chǔ)上，需要用戶編寫定制的自動(dòng)化腳本。cloud-native完全超越這種自動(dòng)化方法。真正的 cloud-native架構(gòu)包含完全自主的自動(dòng)化和編排，用戶只需提出自己的需求，不用描述如何做。在一個(gè)cloud-native環(huán)境中，很難維護(hù)臨時(shí)、專門的自動(dòng)化。cloud-native架構(gòu)內(nèi)置的自動(dòng)化管理服務(wù)起到了契約的作用，執(zhí)行策略和保證承諾。換句話說，這種自動(dòng)化使得構(gòu)建能被自動(dòng)管理的應(yīng)用程序變得容易。

新的體系架構(gòu)方法，要求新的軟件開發(fā)方法。開發(fā)者必須運(yùn)用新的一系列架構(gòu)實(shí)踐——例如微服務(wù)和容器——來確保應(yīng)用程序能被cloud- native平臺(tái)恰當(dāng)?shù)毓芾?。cloud-native不僅帶來軟件開發(fā)速度的提升，還有運(yùn)維方面的好處：方便移植的應(yīng)用實(shí)例，一致的日志記錄和保證應(yīng)用在線和數(shù)據(jù)流的監(jiān)控功能。

想要了解cloud-native的好處，一種方法是引入運(yùn)行時(shí)契約，即運(yùn)行軟件的一系列指南。cloud-native框架幫助開發(fā)者編寫滿足云平臺(tái)運(yùn)行時(shí)契約的應(yīng)用程序。

cloud-native框架

cloud-native應(yīng)用的本質(zhì)是它們滿足如下特點(diǎn)的契約：通過可預(yù)測(cè)的行為，***化復(fù)原。云平臺(tái)使用的高度自動(dòng)化、容器驅(qū)動(dòng)的基礎(chǔ)設(shè)施，***軟件的編寫方式。開發(fā)者必須改變編碼方式，在開發(fā)者和運(yùn)行應(yīng)用的基礎(chǔ)設(shè)施之間建立一種新的契約。一個(gè)很好的契約例子是十二因素應(yīng)用。

其中，大多數(shù)因素的內(nèi)容有重疊，相互補(bǔ)充。這些因素的描述盡量保證直接和可操作：

1. 從一個(gè)代碼庫(kù)部署到多個(gè)環(huán)境——一個(gè)代碼庫(kù)，包括生產(chǎn)環(huán)境軟件包，確保了單一的信任源，從而保證了更少的配置錯(cuò)誤和更強(qiáng)的容錯(cuò)和復(fù)原能力。
2. 依賴管理是聲明式的——云平臺(tái)根據(jù)這些聲明管理依賴，確保云應(yīng)用所需的庫(kù)和服務(wù)。
3. 配置信息保存在環(huán)境中——環(huán)境變量是一種清楚、容易理解和標(biāo)準(zhǔn)化的配置方法，特別適合用不同編程語言編寫的無狀態(tài)應(yīng)用的使用。
4. 將后臺(tái)服務(wù)視為附加的資源——將每一種資源都視為一種遠(yuǎn)程的資源，應(yīng)用因此具有容錯(cuò)和復(fù)原能力，因?yàn)樗环矫嬉缶幋a時(shí)就要考慮資源不可用的情況，另外一方面也增強(qiáng)微服務(wù)方法的好處。
5. 區(qū)分構(gòu)建、發(fā)布和運(yùn)行階段——cloud-native應(yīng)用的構(gòu)建流程把大部分發(fā)布配置挪到開發(fā)階段，包括實(shí)際的代碼構(gòu)建和運(yùn)行應(yīng)用所需的生產(chǎn)環(huán)境配置。
6. 作為無狀態(tài)進(jìn)程運(yùn)行——盡量保持應(yīng)用棧每一層的輕量級(jí)，保證cloud-native基礎(chǔ)設(shè)施的速度和效率。
7. 通過端口綁定對(duì)外暴露服務(wù)——cloud-native應(yīng)用的服務(wù)接口優(yōu)先選擇 HTTP API 作為通用的集成框架。
8. 通過添加無狀態(tài)進(jìn)程實(shí)現(xiàn)橫向擴(kuò)展——強(qiáng)調(diào)無狀態(tài)、無共享的設(shè)計(jì)，這意味著依賴底層平臺(tái)就能實(shí)現(xiàn)橫向擴(kuò)展，不需要技術(shù)難度高的多線程編碼。
9. 快速地啟動(dòng)，優(yōu)雅地關(guān)停——假設(shè)任何進(jìn)程隨時(shí)都能啟動(dòng)和關(guān)停。
10. 開發(fā)、預(yù)發(fā)布和生產(chǎn)環(huán)境運(yùn)行同樣的應(yīng)用和依賴配置——由于強(qiáng)調(diào)自動(dòng)化和在每個(gè)階段使用同一個(gè)云平臺(tái)，如果每個(gè)人用同樣的服務(wù)器配置，那么“應(yīng)用在我這里是可以的”就意味著在其他人或者環(huán)境那里也是可以的。
11. 日志輸出到標(biāo)準(zhǔn)輸出，方便日志聚合和事件響應(yīng)——當(dāng)日志是由云平臺(tái)而不是應(yīng)用包含的庫(kù)處理時(shí)，日志處理機(jī)制必須保持簡(jiǎn)單。
12. 臨時(shí)任務(wù)作為短時(shí)進(jìn)程運(yùn)行——在cloud-native中，管理任務(wù)也是一個(gè)進(jìn)程，而不是特別的工具;同樣重要的是，管理任務(wù)的進(jìn)程不應(yīng)使用秘密的 API 或者內(nèi)部機(jī)制。

遵循上述原則的應(yīng)用程序，具有一致的架構(gòu)接口。為了使創(chuàng)建的分布式應(yīng)用馬上就可以部署在云中，這些接口的構(gòu)建采用一種無狀態(tài)、面向進(jìn)程的設(shè)計(jì)模式。 Ruby on Rails 是一種革命性的 web 應(yīng)用開發(fā)框架，它采用強(qiáng)制性的、約定高于配置的方法。從***版 Rails 發(fā)布之日算起，已經(jīng)九年半過去了，整個(gè)業(yè)界認(rèn)識(shí)到了遵循約定的框架的威力。

像 Java 的 Spring Boot/Cloud 和 Dropwizard 、Node.js 的 Seneca 框架，甚至包括 Ruby on Rails (外加幾個(gè) gem 包)在內(nèi)，它們都能很好地滿足cloud-native契約的要求，這勢(shì)必節(jié)省開發(fā)者的時(shí)間，讓開發(fā)者專心編寫應(yīng)用的核心代碼——關(guān)鍵業(yè)務(wù)邏輯，不必費(fèi)心于支持應(yīng)用工作的膠水代碼。

當(dāng)應(yīng)用程序遵循運(yùn)行時(shí)的契約時(shí)，彈性的cloud-native運(yùn)行時(shí)就能編排、管理和擴(kuò)展這些應(yīng)用。

cloud-native運(yùn)行時(shí)

容器已經(jīng)成為云運(yùn)行時(shí)的關(guān)鍵組件。容器的輕量本質(zhì)和強(qiáng)力的資源管理特性，特別適合cloud-native，為之增加了速度和資源效率。容器將一個(gè)cloud-native應(yīng)用打包成一個(gè)遵循云平臺(tái)約定的可執(zhí)行物件。

與其它進(jìn)程一樣，可在任何一臺(tái)主機(jī)(物理機(jī)或者虛擬機(jī)，無所謂)上運(yùn)行很多容器。在開發(fā)階段，把應(yīng)用構(gòu)建為一個(gè)容器，使得開發(fā)者編碼和創(chuàng)建完整構(gòu)建的周期大大縮短，這甚至運(yùn)行開發(fā)者在他們的筆記本電腦上運(yùn)行一個(gè)開發(fā)云，***程度地減少了在生產(chǎn)環(huán)境的云運(yùn)行時(shí)無法正常運(yùn)行的可能性。在生產(chǎn)環(huán)境中，容器提供的關(guān)鍵好處包括更好的進(jìn)程間安全、穩(wěn)定性和準(zhǔn)確地預(yù)測(cè)每個(gè)進(jìn)程消耗的資源。更進(jìn)一步，還能預(yù)報(bào)由于增長(zhǎng)帶來的基礎(chǔ)設(shè)施耗費(fèi)。

要有效地使用容器，就必須實(shí)現(xiàn)容器編排。編排是指無需人工交互和規(guī)劃，就能啟動(dòng)、關(guān)停和分發(fā)容器到計(jì)算資源池中;一個(gè)彈性運(yùn)行時(shí)。編排是對(duì)部署請(qǐng)求、自動(dòng)擴(kuò)展的流量分析、甚至是基礎(chǔ)設(shè)施失效的響應(yīng)。完整的容器編排還要做到檢測(cè)和回滾變化，管理生產(chǎn)環(huán)境中應(yīng)用的不同版本來完成 A/B 測(cè)試和每日部署。打包容器只是cloud-native架構(gòu)需求的一部分：編排和管理容器在生產(chǎn)環(huán)境中的部署和運(yùn)行，這比容器的打包重要得多。

隨著前述cloud-native框架的興起，容器編排的屬性最近獲得了很多關(guān)注。容器運(yùn)行時(shí)需要做到：

1. 管理容器的生命周期，包括創(chuàng)建、運(yùn)行和摧毀——強(qiáng)有力地控制運(yùn)行在生產(chǎn)環(huán)境中每一個(gè)容器的生命周期，有助于實(shí)現(xiàn)應(yīng)用的按需自動(dòng)擴(kuò)展。
2. 通過約束保證資源利用是可預(yù)測(cè)的——細(xì)粒度控制每個(gè)容器實(shí)例使用的資源。
3. 進(jìn)程隔離——使用內(nèi)核級(jí)別的命名空間和本地文件系統(tǒng)，確保不同容器的進(jìn)程之間是隔離的。
4. 通過編排實(shí)現(xiàn)資源的***利用——給定一個(gè)資源池(通常是虛擬機(jī)集群)，容器編排使得應(yīng)用負(fù)載分布在整個(gè)資源池中。
5. 檢測(cè)錯(cuò)誤和從失效中恢復(fù)的方法——在生產(chǎn)環(huán)境中，出錯(cuò)是難免的。編排平臺(tái)必須能檢測(cè)到關(guān)鍵組件的失效，自動(dòng)移除工作不正常的容器實(shí)例和基礎(chǔ)設(shè)施，重新部署應(yīng)用，以避免宕機(jī)。

通過使用 API ，cloud-native運(yùn)行時(shí)能夠在各種不同的基礎(chǔ)設(shè)施上運(yùn)行，不與特定的基礎(chǔ)設(shè)施綁定。管理良好的、自動(dòng)化的基礎(chǔ)設(shè)施使得cloud-native架構(gòu)更具有容錯(cuò)和恢復(fù)能力。

cloud-native基礎(chǔ)設(shè)施的自動(dòng)化

如果基礎(chǔ)設(shè)施自動(dòng)化做得好，生產(chǎn)環(huán)境架構(gòu)的管理幾乎不需要人工干預(yù)。

健壯自動(dòng)化幾乎能處理傳統(tǒng)IT中需要手工處理的所有事情：當(dāng)應(yīng)用實(shí)例增減時(shí)更新路由器和負(fù)載均衡組件，部署應(yīng)用所需的供應(yīng)和聯(lián)網(wǎng)服務(wù)，分配新的基礎(chǔ)設(shè)施，設(shè)置監(jiān)控和災(zāi)后恢復(fù)服務(wù)，日志聚合，當(dāng)基礎(chǔ)設(shè)施失效時(shí)重新部署應(yīng)用。

像上面這些高級(jí)自動(dòng)化實(shí)踐，能把你從應(yīng)對(duì)零日危險(xiǎn)的痛苦中拯救出來：自動(dòng)化采用滾動(dòng)更新的方式，為每一個(gè)節(jié)點(diǎn)打上安全補(bǔ)丁，同時(shí)又保證服務(wù)一直在線。

這種水平的自動(dòng)化是由結(jié)構(gòu)化平臺(tái)提供的。

從概念層次上，每一個(gè)結(jié)構(gòu)化平臺(tái)都必須包括：

1. 路由和負(fù)載均衡——應(yīng)用的橫向擴(kuò)展需要網(wǎng)絡(luò)路由，路由是可以動(dòng)態(tài)更新的，它把外來請(qǐng)求分散到整個(gè)資源池。
2. 后臺(tái)服務(wù)代理——大部分應(yīng)用都需要各種后臺(tái)服務(wù)，包括數(shù)據(jù)庫(kù)、緩存和消息隊(duì)列。這些服務(wù)必須是高可用的服務(wù)，通過環(huán)境變量進(jìn)行配置，以便滿足十二因素約定中對(duì)配置的要求。
3. 基礎(chǔ)設(shè)施編排——平臺(tái)必須能自動(dòng)管理基礎(chǔ)設(shè)施，提供彈性擴(kuò)展的計(jì)算資源。
4. 健康管理、監(jiān)控和恢復(fù)——可視化顯示正在運(yùn)行的應(yīng)用和實(shí)例，以及當(dāng)事件發(fā)生時(shí)的通知消息和審計(jì)日志。
5. 可復(fù)用的運(yùn)行時(shí)環(huán)境倉(cāng)庫(kù)——應(yīng)用以容器鏡像的形式發(fā)布，重復(fù)用于啟動(dòng)應(yīng)用實(shí)例，這保證了整個(gè)架構(gòu)同一個(gè)應(yīng)用的所有實(shí)例是完全一樣的。
6. 日志聚合——高可用、橫向擴(kuò)展的應(yīng)用需要聚合所有實(shí)例的日志，用于分析和響應(yīng)發(fā)生的事故。

cloud-native基礎(chǔ)設(shè)施編排提供了直到基礎(chǔ)設(shè)施的結(jié)構(gòu)化平臺(tái)。這是與底層 API 集成的一層;也是cloud-native架構(gòu)的基礎(chǔ)，cloud-native架構(gòu)支撐了運(yùn)行時(shí)編排的安裝、擴(kuò)展、管理和更新。

以上是對(duì)成功交付cloud-native應(yīng)用的理論思考的概述。cloud-native在加速軟件交付的同時(shí)，降低了運(yùn)維中的修正代價(jià)，無論是時(shí)間還是壓力方面。如果部署和運(yùn)維的代價(jià)高，持續(xù)交付和微服務(wù)是站不住腳的。這里主要關(guān)注工具的功能，但是不能低估所需要的高度信任文化和過程。(有人甚至認(rèn)為文化和過程是更為關(guān)鍵的成功因素，那需要討論的內(nèi)容就更多了)。

cloud-native如此

那些想把持續(xù)交付的速度和好處***化的人，需要支持cloud-native應(yīng)用的體系架構(gòu)，作為貫穿整個(gè)軟件交付周期的使能技術(shù)。應(yīng)用是用滿足cloud-native運(yùn)行時(shí)契約要求的cloud-native框架構(gòu)建的，cloud-native基礎(chǔ)設(shè)施自動(dòng)化大大改變了組織交付軟件的能力。這個(gè)平臺(tái)還包括用以實(shí)現(xiàn)持續(xù)交付、敏捷開發(fā)和 DevOps 運(yùn)動(dòng)的生產(chǎn)環(huán)境承諾的實(shí)踐和過程;云基礎(chǔ)設(shè)施的可用性和可靠性。

cloud-native做到了穩(wěn)定性和敏捷性兼顧。有了cloud-native架構(gòu)，就可以像Netflix這樣的cloud-native公司一樣，擁有相同的功能、靈活性、速度和安全性。最終你就有時(shí)間欣賞此前錯(cuò)過的動(dòng)畫片《我的小馬駒：友誼是神奇的》。

原文鏈接：http://www.dockone.io/article/688