您能否以每週爲單位向客戶發佈各類新功能?甚至進一步達到以每天乃至每小時爲單位?新晉開發人員能否在上班的第一天即進行代碼部署，或者是在工作審查過程中完成功能交付?瞭解到新員工完成代碼部署後，應用程序仍能完美運行，大家肯定可以睡個好覺。事實上，這種快捷的發佈週期需要配合一系列流程、工具甚至是管理文化，從而共同支撐起一套安全且可靠的雲原生應用程序運作機制。而這也成爲軟件驅動型企業的核心戰略因素之一，其目標在於以更快速度發佈軟件成果，且同時降低潛在風險。在擁有了這種快速發佈軟件的能力之後，我們將擁有更爲緊湊的反饋循環，從而高效響應客戶的每一項基本需求。
持續交付能力正是軟件邁向雲原生方向的主要動力：軟件發佈速度的加快能夠有效降低反饋週期的持續時間。DevOps代表着我們全面實現雲原生戰略過程中需要遵循的文化與技術轉變。微服務則是一套軟件架構模式，其已經被成功且廣泛地應用於開發及交付運營工作的規模擴展當中，且能夠有效規避緩慢、高風險及單一性部署策略。舉例來說，如果大家無法真正推廣“快速失敗”與“自動化優先”的DevOps文化，那麼微服務機制將很難獲得成功。
持續交付、DevOps以及微服務分別面向雲原生機制的三項根本性重點，即爲什麼、如何以及什麼。這些競爭優勢已經迅速成爲企業在軟件成果對抗當中勝出的有力武器。作爲最爲先進的概念性載體，它們往往相互交織在一起並呈現出不可分割的態勢——而這，正是雲原生機制的實際表現形式。
雲原生機制對我們意味着什麼?
在軟件交付生命週期當中引入雲原生機制之後，大家將能夠提高運營及規模化效率，進而實現所謂“敏捷性”：也就是快速爲軟件添加新功能，同時又不影響其在生產環境下的穩定性與安全性水平的能力。衆所周知，我們的應用程序在運行過程中需要基礎設施、開發者中間件以及支持服務的多方配合，而云原生方案則通過對這些因素的自動化改造實現上述目標。
這類方案絕不僅僅是在傳統面向虛擬化的編排體系基礎之上建立而成的臨時性自動化解決辦法。一套全面的雲原生架構當中包含自動化與編排兩類機制，能夠幫助用戶直接獲得相關效果，而無需再將自動化流程作爲可定製設計進行編寫。其內置自動化管理方案可作爲契約起效，從而執行政策並保障效果承諾。換句話來說，這類自動化方案使我們得以更爲輕鬆地構建出可以自動化方式管理的應用程序。
當然，新型基礎設施方案的出現同時也會對軟件的開發方式提出新的要求。開發人員必須利用一整套新的架構實踐組合——例如微服務與容器技術——從而確保應用程序能夠在雲平臺之上得到妥善管理，這也是我們在軟件開發提速之外需要認真考量的保障前提。新方案在運營層面亦帶來多項助益，具體包括應用程序實例可遷移、統一化登錄以及通過監控手段保障應用程序及數據流正常運作等等。
要發揮雲原生方案的固有優勢，較爲理想的途徑之一就是將其作爲運行時契約加以審視。所謂運行時契約，本質上是一套運行軟件所需遵循的指南組合。雲原生框架能夠幫助開發人員編寫出符合雲平臺之上運行時契約要求的應用程序。
雲原生框架
雲原生應用程序的一大關鍵性特質在於，其需要遵循一套設計契約以最大程度實現行爲的可預測性。雲平臺當中所使用的高自動化、容器驅動型基礎設施也對軟件的編寫方式提出了要求。開發人員必須改變自己的編程習慣，在開發人員與基礎設施之間創建出一套用於指導應用程序運行的新型“契約”。下面我們就通過“應用十二要素”中所提出的十二項基本原則來了解如何打造出一套理想的“契約”機制。
這十二項因素之間存在一定交集，同時亦相互支撐。大家在具體實施過程中，應當儘可能保持其直接關聯與可行性：
1.立足於單一代碼庫向多種環境部署 – 包括生產性組件在內的單一代碼庫能夠確保代碼的單一來源，從而降低配置錯誤數量並提高彈性水平。
2.以聲明方式管理依賴性 – 雲平臺需要引入必要的關聯性聲明並加以妥善管理，從而確保相關雲應用程序始終具備必要的庫及服務支持。
3.使用保存在環境當中的配置信息 – 環境變量能夠提供一套簡潔、易於理解且符合標準要求的使用方式，從而爲以多種編程語言編寫而成的無狀態應用程序提供良好的配置機制。
4.將後端服務作爲附加資源處理 – 將每種資源都作爲遠程資源處理的思路成就了彈性這一概念，這不僅從編程層面考慮到了資源不可用情況，同時也最大程度發揮了微服務方案當中的固有優勢。
5.將構建、發佈以及運行階段區分開來 – 雲原生應用程序的構建流程將大部分發布配置工作轉移到了“開發”階段，這意味着發佈包當中將包含有代碼本身以及運行應用程序所必需的生產配置方案。
6.以無狀態方式運行 – 雲原生基礎設施的速度表現與成本效益要得到切實體現，要求應用程序堆棧中的第一層擁有儘可能高的輕量化水平。
7.將服務與端口綁定 – 雲原生應用程序當中的服務接口一般傾向於利用基於HTTP的API作爲通用集成框架。
8.通過添加無狀態進程實現橫向擴展 – 對於無狀態非共享式設計思路的強調，意味着擴展工作能夠依賴於底層平臺——而非智能化多進程代碼——來完成。
9.啓動速度快，允許正常關閉 – 假定任意給定進程都能夠隨時進行啓動與關閉。
10.在開發、分段與生產環境下擁有統一運行效果 – 由於高度強調自動化機制並在各生命週期階段使用同樣的雲平臺，因此只要大家使用的是同一套“平臺”、那麼我這邊能用的在你那邊也同樣能用。
11.對彙總及事件響應的標準輸出結果進行記錄 – 當日志記錄由雲平臺而非應用程序內的庫負責處理時，將記錄機制作爲功能實體則變得非常關鍵。
12.允許臨時性任務以短期進程方式運行 – 在雲原生方案當中，管理任務可以單純轉化爲另一種進程、而非特定工具，而且必須保證其行爲方式要與使用“機密”API以及內部機制有所區別。
遵循以上指導性原則，我們完全可以在應用程序當中利用統一的架構接口構建起一套無狀態且面向過程的設計模式，從而打造出適合運行在雲環境之下的分佈式應用程序。Ruby on Rails憑藉着所堅持的、基於配置的公約方式在Web開發領域給應用程序框架帶來了一次革命。自Rails首次發佈至今的九年半時間裏，充分利用框架潛能的意識已經深入到了整個技術行業當中，而云原生機制的出現也將繼續延續這一發展趨勢。
以Spring Boot/Cloud以及Dropwizard for Java、Seneca for Node.js甚至是Ruby on Rails爲代表的各類框架已經爲雲契約構建起了很好的立足根基。它們的存在不僅能幫助我們節約大量時間，同時也讓開發者能夠將精力集中在編寫作爲應用核心的關鍵性業務邏輯身上，而非勞心勞力將代碼粘接在一起以實現正常運行。
當我們的應用程序符合運行時契約要求時，這意味着大家可以對其進行編排、管理並通過彈性雲原生運行時環境對其進行規模伸縮。
雲原生運行時
容器技術已經興起並發展成爲雲運行時環境當中的關鍵性組成部分。它們的輕量級特性以及緊湊的資源管理機制能夠極好地同雲應用程序方案加以配合，從而在提高速度的同時改進資源利用效率。容器技術相當於將一款能夠運行於雲平臺之上的應用程序打包成一套獨立的可執行組件，且確保其與雲平臺的契約要求相兼容。
與其它任意進程一樣，大家也可以在每一臺主機設備上運行多套容器系統(無論是裸機還是虛擬機)。在開發階段中，利用容器方案構建應用程序能幫助開發人員降低耗費在編程方面的時間週期，同時在筆記本設備上創建出一套完整的、甚至能夠面向開發者運行的雲環境，從而模擬出整個生產流程。在生產環境下，容器提供的密鑰機制能夠更好地保障不同進程之間的安全性，幫助各進程擁有更出色的穩定性與可預測的資源消耗水平。而着眼於下一個層級，我們還能夠藉此預測基礎設施在響應需求過程中的成長增長進度。
要有效運用容器技術，我們必須對其精心編排。編排是一種手段，目的是在無需人爲介入或者制定規劃的前提下以消耗性資源池爲基礎，實現容器的啓動、中止以及資源分發——這實際上是一套彈性運行時。編排方案當中需要包含部署請求、自動伸縮流量分析以及基礎設施發生故障時的響應措施等要素。完整的容器編排方案還能夠實現診斷及變更回滾，同時對處於生產環境下的不同實驗性應用程序版本進行管理及A/B測試乃至試探性部署。相比之下，簡單的打包容器則僅僅屬於雲原生架構需求當中的一部分，負責編排並管理相關容器的部署方式——在這種情況下，容器在生產環境下的具體效果甚至要比容器自身的打包方式更加重要。
隨着雲原生框架方案的持續興起，容器編排的出色屬性已經受到業界的廣泛關注。下面我們來總結享受容器運行時優勢時需要保證的幾項前提：
1.對生命週期的創建、運行以及中止加以管理 – 對運行在生產環境中的各容器的生命週期進行嚴格管理能夠幫助大家根據實際需求對應用程序規模加以自動伸縮。
2.通過約束性手段以可預測方式運用資源 – 容器機制允許我們對每項實例所使用的資源進行細化控制。
3.進程隔離 – 同樣的，容器機制能夠利用內核層級的命名空間與本地文件系統保證各個進程之間彼此隔離。
4.通過編排機制優化資源利用方式 – 考慮到資源池通常由一系列虛擬機系統共同構成，容器會以分佈式管理方式將工作負載分發至整個資源池當中。
5.故障診斷及生產恢復方式 – 生產環境下總會有組件發生故障，而這套編排平臺應當以自動化方式對關鍵性故障作出響應，包括移除異常實例及基礎設施並重新均衡負載以避免宕機等。
雲原生運行時能夠運行在類別廣泛的不同基礎設施之上，且通過API消除對具體基礎設施類型的依賴性。當然，擁有妥善管理的自動你可以基礎設施能夠讓我們的雲原生架構在彈性方面更上一層樓。
雲原生基礎設施自動化
以合理實施作爲出發點，基礎設施自動化將使整套生產架構以全面託管方式運作，且幾乎無需人爲因素的介入。
強大的自動化機制能夠處理幾乎任何原本需要由傳統IT人員完成的任務：新型路由器及負載均衡機制能夠完成應用實例的啓動與中止、配置以及網絡服務等應用程序部署過程中必需的環節，同時實現新基礎設施資源分配、設置監控方案與災難恢復場景、日誌彙總甚至是在基礎設施出現故障時對工作負載進行重新分配。
這類先進的自動化實踐能夠幫助我們免受零日安全漏洞的侵擾：自動化方案會在每個節點之上進行部署操作，從而在不產生任何停機時間的前提下應用安全補丁。
要實現這種級別的自動化效果，我們需要使用所謂結構化平臺。從宏觀角度看，這類結構化平臺必須擁有以下能力：
1.路由與負載均衡 – 通過容器編排對應用程序進行橫向擴展必然要求網絡路由加以配合，而後者則能夠以動態方式對面向整套資源池的輸入請求進行均衡。
2.支持服務代理 – 大部分應用程序在運行過程中都需要外部支持服務作爲配合，例如數據庫、緩存解決方案以及消息隊列機制等等，而這一切都應當由該平臺作爲貫穿整個環境的高可用性服務加以交付，且符合前面提到的十二項配置基本原則。
3.基礎設施編排 – 平臺應當自動管理整套基礎設施，從而對計算資源進行彈性規模伸縮。
4.運行狀況管理、監控與恢復 – 當事件發生時，將平臺之上所運行應用程序之虛擬化、實例以及通知與審計全部納入日誌記錄。
5.可重複使用的運行時環境庫 – 容器鏡像在創建過程中需要考慮到不同應用程序實例啓用時的發佈及可重複使用能力，從而確保整套架構中的全部實例皆擁有完全一致的運行前提。
6.日誌彙總 – 高可用性橫向擴展應用需要對來自全部實例的日誌信息加以彙總，從而進行分析並針對突發情況作出快速響應。
雲原生基礎設施編排機制提供一套貫徹基礎設施始終的結構化平臺，它既是整合了底層API的完整層級，同時也作爲雲原生架構中的基礎性組成部分存在，從而保證運行時編排體系得以安裝、擴展、管理以及更新。
這正是保障雲原生應用程序交付成功的宏觀層面考量方向，同時也是在運營過程中降低修復時間與壓力成本並加快軟件交付速度的有效途徑。如果部署與運營成本過於高昂，那麼持續交付與微服務架構將無從談起。我們當然需要着眼於此類工具的主要功能，但同時也必須重視高可信度文化及流程的建立。(在某些情況下，文化與流程甚至會成爲左右實際結果的關鍵性因素，但這就不在今天的討論範圍之內了。)
邁向雲原生之路
對於希望最大程度享受持續交付機制所帶來的速度與效益的用戶來說，擁有一套能夠支持雲原生應用程序的架構顯然極爲重要，只有這樣面向整體軟件交付生命週期的技術方案才能落實到位。以符合雲原生容器運行時特性的雲原生框架爲前提構建應用程序，同時實現雲原生基礎設施自動化，這樣企業業務能力才能在軟件交付過程中得到保證。此類平臺還包含大量用於實現持續交付、敏捷開發以及DevOps活動的具體實踐及流程，同時帶來雲基礎設施所固有的可用性及可靠性優勢。
總而言之，享受雲原生的穩定性與敏捷性優勢不應以犧牲固有效益爲代價。在雲原生架構當中，我們可以擁有同樣的資源儲備、靈活性水平、速度表現乃至安全成效——Netflix等雲原生企業已經給出了實證。保持信心，同時謹慎對待，這正是在雲原生之路上高歌猛進的重要原則。