你真正瞭解什麼是CloudNative嗎？

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

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

1. 從一個程式碼庫部署到多個環境——一個程式碼庫，包括生產環境軟體包，確保了單一的信任源，從而保證了更少的配置錯誤和更強的容錯和復原能力。
2. 依賴管理是宣告式的——雲平臺根據這些宣告管理依賴，確保雲應用所需的庫和服務。
3. 配置資訊儲存在環境中——環境變數是一種清楚、容易理解和標準化的配置方法，特別適合用不同程式語言編寫的無狀態應用的使用。
4. 將後臺服務視為附加的資源——將每一種資源都視為一種遠端的資源，應用因此具有容錯和復原能力，因為它一方面要求編碼時就要考慮資源不可用的情況，另外一方面也增強微服務方法的好處。
5. 區分構建、釋出和執行階段——cloud-native應用的構建流程把大部分發布配置挪到開發階段，包括實際的程式碼構建和執行應用所需的生產環境配置。
6. 作為無狀態程式執行——儘量保持應用棧每一層的輕量級，保證cloud-native基礎設施的速度和效率。
7. 通過埠繫結對外暴露服務——cloud-native應用的服務介面優先選擇 HTTP API 作為通用的整合框架。
8. 通過新增無狀態程式實現橫向擴充套件——強調無狀態、無共享的設計，這意味著依賴底層平臺就能實現橫向擴充套件，不需要技術難度高的多執行緒編碼。
9. 快速地啟動，優雅地關停——假設任何程式隨時都能啟動和關停。
10. 開發、預釋出和生產環境執行同樣的應用和依賴配置——由於強調自動化和在每個階段使用同一個雲平臺，如果每個人用同樣的伺服器配置，那麼“應用在我這裡是可以的”就意味著在其他人或者環境那裡也是可以的。
11. 日誌輸出到標準輸出，方便日誌聚合和事件響應——當日志是由雲平臺而不是應用包含的庫處理時，日誌處理機制必須保持簡單。
12. 臨時任務作為短時程式執行——在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框架的興起，容器編排的屬性最近獲得了很多關注。容器執行時需要做到：

1. 管理容器的生命週期，包括建立、執行和摧毀——強有力地控制執行在生產環境中每一個容器的生命週期，有助於實現應用的按需自動擴充套件。
2. 通過約束保證資源利用是可預測的——細粒度控制每個容器例項使用的資源。
3. 程式隔離——使用核心級別的名稱空間和本地檔案系統，確保不同容器的程式之間是隔離的。
4. 通過編排實現資源的最優利用——給定一個資源池(通常是虛擬機器叢集)，容器編排使得應用負載分佈在整個資源池中。
5. 檢測錯誤和從失效中恢復的方法——在生產環境中，出錯是難免的。編排平臺必須能檢測到關鍵元件的失效，自動移除工作不正常的容器例項和基礎設施，重新部署應用，以避免當機。

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

cloud-native基礎設施的自動化

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

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

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

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

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

1. 路由和負載均衡——應用的橫向擴充套件需要網路路由，路由是可以動態更新的，它把外來請求分散到整個資源池。
2. 後臺服務代理——大部分應用都需要各種後臺服務，包括資料庫、快取和訊息佇列。這些服務必須是高可用的服務，通過環境變數進行配置，以便滿足十二因素約定中對配置的要求。
3. 基礎設施編排——平臺必須能自動管理基礎設施，提供彈性擴充套件的計算資源。
4. 健康管理、監控和恢復——視覺化顯示正在執行的應用和例項，以及當事件發生時的通知訊息和審計日誌。
5. 可複用的執行時環境倉庫——應用以容器映象的形式釋出，重複用於啟動應用例項，這保證了整個架構同一個應用的所有例項是完全一樣的。
6. 日誌聚合——高可用、橫向擴充套件的應用需要聚合所有例項的日誌，用於分析和響應發生的事故。

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

本文作者：柳泉波

來源：51CTO