你真正了解什么是 Cloud Native 嗎？
什么是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公司一樣，擁有相同的功能、靈活性、速度和安全性。最終你就有時間欣賞此前錯過的動畫片《我的小馬駒：友誼是神奇的》。
