什么是cloud-native?cloud-native框架、cloud-native運行時和cloud-native基礎設施的自動化又有哪些內容?讀完這篇文章，就能有一個大概的了解。

你能做到每周、每天甚至每個鐘頭向客戶發布新特性嗎?新加入的開發者能夠在他們工作的第一天甚至面試階段就能部署代碼嗎?部署新員工的代碼后，你能因為確信應用程序運行正常而安然入睡嗎?建立快速發布機制，包括支持cloud-native應用的安全與可靠的運維的流程、工具和文化，已經成為軟件驅動組織的關鍵戰略因素。有了快速發布機制，這些組織就能在降低風險的同時更快地發布軟件。發布軟件越快，得到的反饋循環就越緊密，企業就能更有效地響應客戶的需要。

持續交付是軟件正在變成cloud-native應用的原因：更快地交付軟件，降低反饋循環的時間。完全實現cloud-native戰略，需要文化和技術兩方面的改變，DevOps是應對這些改變的方法。微服務是應用最成功的軟件體系架構模式，它擴展了開發和交付操作，避免緩慢、充滿風險的單體部署策略。例如，如果還沒有建立“快速失敗”和“自動優先”的 DevOps 文化，很難成功地實施微服務戰略。

持續交付、DevOps和微服務分別描述了cloud-native應用的為什么、怎么做和是什么。這些競爭優勢迅速成為玩轉軟件游戲的賭注。深究起來，上述三個概念糾纏在一起，不可區分。這就是cloud-native的含義所在。

cloud-native能做些什么?

貫穿軟件交付生命周期的cloud-native能讓用戶更有效地運維和擴展，成功擁有“敏捷性”：能夠快速為軟件添加新功能，同時保持生產環境的穩定性和安全性。cloud-native能做到這一點的原因是它把運行應用程序所需的基礎設施、中間件和后臺服務完全自動化。

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

新的體系架構方法，要求新的軟件開發方法。開發者必須運用新的一系列架構實踐——例如微服務和容器——來確保應用程序能被cloud- native平臺恰當地管理。cloud-native不僅帶來軟件開發速度的提升，還有運維方面的好處：方便移植的應用實例，一致的日志記錄和保證應用在線和數據流的監控功能。

想要了解cloud-native的好處，一種方法是引入運行時契約，即運行軟件的一系列指南。cloud-native框架幫助開發者編寫滿足云平臺運行時契約的應用程序。

cloud-native框架

cloud-native應用的本質是它們滿足如下特點的契約：通過可預測的行為，最大化復原。云平臺使用的高度自動化、容器驅動的基礎設施，引領軟件的編寫方式。開發者必須改變編碼方式，在開發者和運行應用的基礎設施之間建立一種新的契約。一個很好的契約例子是十二因素應用。

其中，大多數因素的內容有重疊，相互補充。這些因素的描述盡量保證直接和可操作：

從一個代碼庫部署到多個環境——一個代碼庫，包括生產環境軟件包，確保了單一的信任源，從而保證了更少的配置錯誤和更強的容錯和復原能力。

依賴管理是聲明式的——云平臺根據這些聲明管理依賴，確保云應用所需的庫和服務。

配置信息保存在環境中——環境變量是一種清楚、容易理解和標準化的配置方法，特別適合用不同編程語言編寫的無狀態應用的使用。

將后臺服務視為附加的資源——將每一種資源都視為一種遠程的資源，應用因此具有容錯和復原能力，因為它一方面要求編碼時就要考慮資源不可用的情況，另外一方面也增強微服務方法的好處。

區分構建、發布和運行階段——cloud-native應用的構建流程把大部分發布配置挪到開發階段，包括實際的代碼構建和運行應用所需的生產環境配置。

作為無狀態進程運行——盡量保持應用棧每一層的輕量級，保證cloud-native基礎設施的速度和效率。

通過端口綁定對外暴露服務——cloud-native應用的服務接口優先選擇 HTTP API 作為通用的集成框架。

通過添加無狀態進程實現橫向擴展——強調無狀態、無共享的設計，這意味著依賴底層平臺就能實現橫向擴展，不需要技術難度高的多線程編碼。

快速地啟動，優雅地關停——假設任何進程隨時都能啟動和關停。

開發、預發布和生產環境運行同樣的應用和依賴配置——由于強調自動化和在每個階段使用同一個云平臺，如果每個人用同樣的服務器配置，那么“應用在我這里是可以的”就意味著在其他人或者環境那里也是可以的。

日志輸出到標準輸出，方便日志聚合和事件響應——當日志是由云平臺而不是應用包含的庫處理時，日志處理機制必須保持簡單。

臨時任務作為短時進程運行——在cloud-native中，管理任務也是一個進程，而不是特別的工具;同樣重要的是，管理任務的進程不應使用秘密的 API 或者內部機制。

遵循上述原則的應用程序，具有一致的架構接口。為了使創建的分布式應用馬上就可以部署在云中，這些接口的構建采用一種無狀態、面向進程的設計模式。 Ruby on Rails 是一種革命性的 web 應用開發框架，它采用強制性的、約定高于配置的方法。從第一版 Rails 發布之日算起，已經九年半過去了，整個業界認識到了遵循約定的框架的威力。

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

當應用程序遵循運行時的契約時，彈性的cloud-native運行時就能編排、管理和擴展這些應用。

cloud-native運行時

容器已經成為云運行時的關鍵組件。容器的輕量本質和強力的資源管理特性，特別適合cloud-native，為之增加了速度和資源效率。容器將一個cloud-native應用打包成一個遵循云平臺約定的可執行物件。

與其它進程一樣，可在任何一臺主機(物理機或者虛擬機，無所謂)上運行很多容器。在開發階段，把應用構建為一個容器，使得開發者編碼和創建完整構建的周期大大縮短，這甚至運行開發者在他們的筆記本電腦上運行一個開發云，最大程度地減少了在生產環境的云運行時無法正常運行的可能性。在生產環境中，容器提供的關鍵好處包括更好的進程間安全、穩定性和準確地預測每個進程消耗的資源。更進一步，還能預報由于增長帶來的基礎設施耗費。

要有效地使用容器，就必須實現容器編排。編排是指無需人工交互和規劃，就能啟動、關停和分發容器到計算資源池中;一個彈性運行時。編排是對部署請求、自動擴展的流量分析、甚至是基礎設施失效的響應。完整的容器編排還要做到檢測和回滾變化，管理生產環境中應用的不同版本來完成 A/B 測試和每日部署。打包容器只是cloud-native架構需求的一部分：編排和管理容器在生產環境中的部署和運行，這比容器的打包重要得多。

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

管理容器的生命周期，包括創建、運行和摧毀——強有力地控制運行在生產環境中每一個容器的生命周期，有助于實現應用的按需自動擴展。

通過約束保證資源利用是可預測的——細粒度控制每個容器實例使用的資源。

進程隔離——使用內核級別的命名空間和本地文件系統，確保不同容器的進程之間是隔離的。

通過編排實現資源的最優利用——給定一個資源池(通常是虛擬機集群)，容器編排使得應用負載分布在整個資源池中。

檢測錯誤和從失效中恢復的方法——在生產環境中，出錯是難免的。編排平臺必須能檢測到關鍵組件的失效，自動移除工作不正常的容器實例和基礎設施，重新部署應用，以避免宕機。

通過使用 API ，cloud-native運行時能夠在各種不同的基礎設施上運行，不與特定的基礎設施綁定。管理良好的、自動化的基礎設施使得cloud-native架構更具有容錯和恢復能力。

cloud-native基礎設施的自動化

如果基礎設施自動化做得好，生產環境架構的管理幾乎不需要人工干預。

健壯自動化幾乎能處理傳統IT中需要手工處理的所有事情：當應用實例增減時更新路由器和負載均衡組件，部署應用所需的供應和聯網服務，分配新的基礎設施，設置監控和災后恢復服務，日志聚合，當基礎設施失效時重新部署應用。

像上面這些高級自動化實踐，能把你從應對零日危險的痛苦中拯救出來：自動化采用滾動更新的方式，為每一個節點打上安全補丁，同時又保證服務一直在線。

這種水平的自動化是由結構化平臺提供的。

從概念層次上，每一個結構化平臺都必須包括：

路由和負載均衡——應用的橫向擴展需要網絡路由，路由是可以動態更新的，它把外來請求分散到整個資源池。

后臺服務代理——大部分應用都需要各種后臺服務，包括數據庫、緩存和消息隊列。這些服務必須是高可用的服務，通過環境變量進行配置，以便滿足十二因素約定中對配置的要求。

基礎設施編排——平臺必須能自動管理基礎設施，提供彈性擴展的計算資源。

健康管理、監控和恢復——可視化顯示正在運行的應用和實例，以及當事件發生時的通知消息和審計日志。

可復用的運行時環境倉庫——應用以容器鏡像的形式發布，重復用于啟動應用實例，這保證了整個架構同一個應用的所有實例是完全一樣的。

日志聚合——高可用、橫向擴展的應用需要聚合所有實例的日志，用于分析和響應發生的事故。

cloud-native基礎設施編排提供了直到基礎設施的結構化平臺。這是與底層 API 集成的一層;也是cloud-native架構的基礎，cloud-native架構支撐了運行時編排的安裝、擴展、管理和更新。

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

cloud-native如此

那些想把持續交付的速度和好處最大化的人，需要支持cloud-native應用的體系架構，作為貫穿整個軟件交付周期的使能技術。應用是用滿足cloud-native運行時契約要求的cloud-native框架構建的，cloud-native基礎設施自動化大大改變了組織交付軟件的能力。這個平臺還包括用以實現持續交付、敏捷開發和 DevOps 運動的生產環境承諾的實踐和過程;云基礎設施的可用性和可靠性。

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