擺脫臨時性自動化方案之定位，發揮優勢以實現可預測功能。
您能否以每周為單位向客戶發布各類新功能?甚至進一步達到以每天乃至每小時為單位?新晉開發人員能否在上班的第一天即進行代碼部署，或者是在工作審查過程中完成功能交付?了解到新員工完成代碼部署后，應用程序仍能完美運行，大家肯定可以睡個好覺。事實上，這種快捷的發布周期需要配合一系列流程、工具甚至是管理文化，從而共同支撐起一套安全且可靠的云原生應用程序運作機制。而這也成為軟件驅動型企業的核心戰略因素之一，其目標在于以更快速度發布軟件成果，且同時降低潛在風險。在擁有了這種快速發布軟件的能力之后，我們將擁有更為緊湊的反饋循環，從而高效響應客戶的每一項基本需求。
持續交付能力正是軟件邁向云原生方向的主要動力：軟件發布速度的加快能夠有效降低反饋周期的持續時間。DevOps代表著我們全面實現云原生戰略過程中需要遵循的文化與技術轉變。微服務則是一套軟件架構模式，其已經被成功且廣泛地應用于開發及交付運營工作的規模擴展當中，且能夠有效規避緩慢、高風險及單一性部署策略。舉例來說，如果大家無法真正推廣“快速失敗”與“自動化優先”的DevOps文化，那么微服務機制將很難獲得成功。
持續交付、DevOps以及微服務分別面向云原生機制的三項根本性重點，即為什么、如何以及什么。這些競爭優勢已經迅速成為企業在軟件成果對抗當中勝出的有力武器。作為最為先進的概念性載體，它們往往相互交織在一起并呈現出不可分割的態勢——而這，正是云原生機制的實際表現形式。
云原生機制對我們意味著什么?
在軟件交付生命周期當中引入云原生機制之后，大家將能夠提高運營及規?；剩M而實現所謂“敏捷性”：也就是快速為軟件添加新功能，同時又不影響其在生產環境下的穩定性與安全性水平的能力。眾所周知，我們的應用程序在運行過程中需要基礎設施、開發者中間件以及支持服務的多方配合，而云原生方案則通過對這些因素的自動化改造實現上述目標。
這類方案絕不僅僅是在傳統面向虛擬化的編排體系基礎之上建立而成的臨時性自動化解決辦法。一套全面的云原生架構當中包含自動化與編排兩類機制，能夠幫助用戶直接獲得相關效果，而無需再將自動化流程作為可定制設計進行編寫。其內置自動化管理方案可作為契約起效，從而執行政策并保障效果承諾。換句話來說，這類自動化方案使我們得以更為輕松地構建出可以自動化方式管理的應用程序。
當然，新型基礎設施方案的出現同時也會對軟件的開發方式提出新的要求。開發人員必須利用一整套新的架構實踐組合——例如微服務與容器技術——從而確保應用程序能夠在云平臺之上得到妥善管理，這也是我們在軟件開發提速之外需要認真考量的保障前提。新方案在運營層面亦帶來多項助益，具體包括應用程序實例可遷移、統一化登錄以及通過監控手段保障應用程序及數據流正常運作等等。
要發揮云原生方案的固有優勢，較為理想的途徑之一就是將其作為運行時契約加以審視。所謂運行時契約，本質上是一套運行軟件所需遵循的指南組合。云原生框架能夠幫助開發人員編寫出符合云平臺之上運行時契約要求的應用程序。
云原生框架
云原生應用程序的一大關鍵性特質在于，其需要遵循一套設計契約以最大程度實現行為的可預測性。云平臺當中所使用的高自動化、容器驅動型基礎設施也對軟件的編寫方式提出了要求。開發人員必須改變自己的編程習慣，在開發人員與基礎設施之間創建出一套用于指導應用程序運行的新型“契約”。下面我們就通過“應用十二要素”中所提出的十二項基本原則來了解如何打造出一套理想的“契約”機制。
這十二項因素之間存在一定交集，同時亦相互支撐。大家在具體實施過程中，應當盡可能保持其直接關聯與可行性：
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等云原生企業已經給出了實證。保持信心，同時謹慎對待，這正是在云原生之路上高歌猛進的重要原則。
原文標題：The cloud-native future
京公網安備 11010502049343號