云原生應用是什么

這篇文章給大家介紹云原生應用是什么，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

云原生應用的概念

顧名思義，云原生應用的概念由云和原生兩個部分組成，云在這里指的是云平臺，也就是平臺即服務（Platform as a Service，PaaS）；原生應用指的是專門針對云平臺而設計和實現的，充分利用了云平臺的特性。應用的微服務可以專注于實現業務邏輯，而把微服務架構的復雜度交給云平臺來解決。

原生這個詞在軟件開發中有它獨特的含義。原生通常意味著高效和難以移植，也意味著針對特定的平臺而設計，可以充分利用平臺的特性，因此運行起來非常高效；同樣意味著與特定平臺的深度綁定，很難移植到其他平臺。云原生應用同樣具有這兩個特征，對于云原生應用來說，難移植并不是一個問題，畢竟遷移到云平臺之后，不會再想遷移回去。

云原生應用的特征

與其他應用相比，總結起來，云原生應用有如下 15 個特征。

1、單一代碼庫

云原生應用必須有單一的代碼庫，并在版本管理系統中進行追蹤。單一代碼庫可以是一個版本庫，也可以是共享同一根目錄的多個版本庫，其重要性在于每一個代碼提交（Commit）都會對應一個不可變的構建版本。在每次代碼提交之后，持續集成流程會被觸發，最終產生一系列的應用容器鏡像，這就在代碼提交和構建版本之間建立了一對一的對應關系，這種一對一的關系保證了每個構建版本都是可追蹤的，可以比較不同版本之間的代碼變化。

對于微服務架構的應用來說，每個應用由多個服務組成，這些服務應該由單一的代碼庫進行管理，這保證了構建版本的穩定性。如果一個改動涉及到多個服務，則這個改動應該在一次代碼提交中完成對所有相關服務的修改；如果服務的代碼分散在多個代碼庫中，則一個改動會被分成多個代碼提交，每個代碼提交都會觸發一次持續集成流程，產生對應服務的構建版本，這些服務的構建版本只包含了部分改動，是不完整的。在應用部署時，有的服務可能包含了部分改動，而有的服務則沒有，這使得部署的應用實際上是不能工作的。因此，微服務架構的應用應該使用單一代碼庫。

2、API 優先

云原生應用應該采用 API 優先的設計策略。微服務架構的應用使用公開 API 來作為服務的對外接口，API 屏蔽了服務的內部實現細節。API 優先的設計策略指的是在設計階段，應該首先設計 API 并確定 API 的細節。API 的設計過程需要多個團隊的參與，包括 API 的實現者和可能的使用者，這些團隊在充分討論中最終完成了 API 的定義。API 可以使用 OpenAPI 規范描述，從該規范中可以生成 API 文檔和模擬服務器。 

API 優先的策略保證了 API 的穩定性，同時可以減少不必要的后期修改。因為 API 是服務之間的接口，修改 API 就意味著相關的內部實現、測試用例和 API 的使用者都需要進行修改，如果在應用開發中出現了必須修改 API 的情況，那造成的影響是很大的。API 優先確保了盡可能減少在開發中對 API 進行修改。

API 優先的另外一個好處是可以提高開發效率。API 確定之后，可以利用工具生成文檔和模擬服務器，API 的使用者可以根據文檔來編寫使用 API 的代碼。測試人員可以編寫 API 相關的測試用例，并用模擬服務器運行測試。不同的團隊可以并行工作，從而提高效率。

3、依賴管理

云原生應用應該管理自己的依賴，Java 開發人員對依賴管理應該并不陌生，常用的 Java 構建工具 Maven 和 Gradle 都提供了依賴管理的支持。在開發過程中，只需要利用構建工具的支持即可；在管理依賴時，則需要區分應用自帶的依賴和運行環境提供的依賴。云原生應用通常會包含全部所需的依賴，尤其是以容器形式運行的應用，典型的例子是微服務的 REST API。云原生應用會自帶嵌入式的 Tomcat 這樣的服務器來提供 HTTP 服務。

4、設計、構建、發布和運行

云原生應用應該有完整的設計、構建、發布和運行流程，如下圖所示。

設計

設計在云原生應用的開發中必不可少。傳統應用通常采用瀑布式的開發流程，瀑布式的開發流程中會分配足夠的時間進行設計。云原生應用一般采用敏捷軟件開發流程，但是這并不意味著設計變得不再重要，只不過設計過程變成了一個迭代的過程，而且每次設計的范圍較小，通常只需要對某些新特性進行設計。

構建

構建階段從單一代碼庫中創建出帶版本號的二進制工件，構建過程通常由持續集成服務器來完成，每個構建都必須有唯一不變的版本號，構建出來的二進制工件也是不可變的。這就保證了同一個構建版本在經過測試之后，被部署的版本與測試過的版本保持一致。

發布

把構建出來的工件推送到云平臺之上，就得到了一個發布版本，發布版本中包含與部署環境相關的配置信息。云原生應用在部署時，通常有開發、測試和生產 3 個環境，在每個環境上的配置信息都不盡相同。發布版本也是不可變的，有唯一的發布號，每一個構建版本都可能對應多個發布版本。

運行

運行階段在云平臺之上運行應用，運行的方式取決于云平臺，可以是虛擬機或容器。云平臺負責管理應用的運行，包括監控應用運行狀態、處理失敗的情況和動態水平擴展等。

5、代碼、配置和憑據

代碼、配置和憑據是云原生應用開發中創建的三種不同類型的實體。代碼包括源代碼和相關資源文件；配置是與部署環境相關的配置信息，通常以 XML、YAML、JSON 或屬性文件的形式出現，配置中包含的信息包括第三方服務的連接方式、數據庫連接信息和應用自身的配置屬性等；憑據指的是密碼、私鑰和 API 密鑰等敏感信息。

 代碼和配置的區別在于，代碼不會隨著部署環境而變化，而配置則相反。在實踐中，應該盡可能把配置從應用中分離出來，進行外部化管理，構建出來的二進制工件中不包含任何配置信息，實際的配置值在部署時根據環境來確定。在運行時，一般使用環境變量來傳遞配置值，還可以使用類似 Spring Cloud Config 這樣的專門配置服務器來管理配置值，憑據都應該從源代碼倉庫中刪除。

6、日志

日志是應用開發中不可或缺的部分。與傳統應用不同的是，云原生應用并不需要對日志的輸出方式進行很多配置，只是簡單地把日志寫到標準輸出流（stdout）和標準錯誤流（stderr）。日志的收集和處理由云平臺上的其他服務來提供，這把應用開發人員從日志管理相關的任務中解放出來。云平臺上的日志管理服務非常多，開源的典型實現包括 Elastic 技術棧（ElasticSearch + LogStash + Kibana）和 Fluentd。

7、隨時可丟棄

云原生應用的生命周期可能是短暫的，隨時可能被終止。云平臺可能會隨時啟動和停止應用的實例，這就要求云原生應用的啟動和停止速度都要非常快。當應用的負載突然增大時，可以快速地啟動新的實例來處理請求；當應用的實例出現問題時，可以快速啟動一個新的實例作為替代。快速停止應用和快速啟動應用一樣重要，快速停止應用保證了資源可以被及時釋放。

8、支撐服務

云原生應用的運行離不開支撐服務。支撐服務是一個寬泛的概念，包括數據庫、消息中間件、緩存、用戶認證和授權、存儲等。連接這些支撐服務的配置信息應該被抽離出來，在運行時根據部署環境提供實際值。

9、環境等同

云原生應用的不同部署環境是等同的。開發、測試和生產環境之間不應該有差異，環境的等同性保證了云原生應用可以快速的進行部署，這一特征與構建工件的不變性是相輔相成的，兩者缺一不可。有了這兩個特征之后，每一個唯一版本的構建工件可以被依次部署到不同的環境，在測試環境上經過測試的版本，可以直接部署到生產環境。我們可以確定應用在生產環境上的行為與測試環境中一樣。

10、管理任務

云原生應用運行中可能會需要執行一些管理任務，比如生成報表或者執行一次性的數據查詢等，這些任務通常并不屬于業務流程的一部分，更多的是為了管理和運維的需要。這些任務在執行中會用到云原生應用所依賴的支撐服務，對于這些任務，應該創建獨立的應用，并在同樣的云平臺上運行。對于定期執行的任務，可以充分利用云平臺的支持，比如，Kubernetes 提供了對定時任務（CronJob）的支持。

以生成報表為例，可以創建一個獨立的應用來讀取數據庫并生成報表，該應用可以有自己獨立的容器鏡像。如果報表生成是手動觸發的，該應用應該獨立運行，并提供一個 API 接口來允許外部觸發。如果報表生成是定期的，應用部署時可以創建相應的定時任務來運行容器，在容器啟動時自動生成報表，生成完畢之后，容器運行結束。下圖說明了這兩種觸發方式的區別，圓角矩形的邊框表示應用的邊界。 

11、端口綁定

云原生應用在運行時并不負責管理實際的端口綁定，而是由云平臺統一管理。比如，一個基于 Spring Boot 的微服務應用通常在 8080 端口運行 HTTP 服務，當應用運行在云平臺上時，這個端口只是虛擬機或容器內的端口，并不是外部用戶或其他服務訪問時的實際端口。云平臺對網絡進行統一管理，負責分配實際的端口，云平臺同時提供了相應的機制來發現訪問服務的實際地址和端口。

12、無狀態進程

云原生應用應該是無狀態的。所有的狀態信息都應該從應用中抽離出來，并保存在支撐服務中，比如數據庫中。正因為應用是無狀態的，才可以由云平臺快速的啟動和停止，并進行垂直或水平擴展。

13、并發性

云原生應用使用水平擴展來并發運行多個實例，使用負載均衡來把請求分配到某個實例進行處理。

14、遙測數據

云原生應用需要收集一系列遙測數據，包括應用性能指標、運行狀態和日志等，這些遙測數據，對于云平臺和應用來說同等重要。云平臺可以用性能指標來進行自動水平擴展，比如，Kubernetes 支持 Pod 的自動水平擴展，當 CPU 的利用率超過預定的閾值時，會自動啟動新的 Pod 來處理請求。性能指標分成兩類：一類是業務無關的，比如請求的數量、請求的處理速度、以及平均的請求處理時間等；第二類是業務相關的，需要應用根據業務需求進行收集，比如處理的訂單數量和不同商品的銷售情況等。云原生應用通常會創建儀表盤來實時展示整體的運行狀態，方便運維人員進行監控。

15、認證和授權

云原生應用應該是安全的，安全應該在應用的設計階段就充分考慮。在實現中，可以使用基于角色的訪問控制（RBAC）來保護 API，已經有大量的開源框架來幫助實現認證和授權。

關于云原生應用是什么就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。