云原生應(yīng)用是什么

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

云原生應(yīng)用的概念

顧名思義，云原生應(yīng)用的概念由云和原生兩個部分組成，云在這里指的是云平臺，也就是平臺即服務(wù)（Platform as a Service，PaaS）；原生應(yīng)用指的是專門針對云平臺而設(shè)計(jì)和實(shí)現(xiàn)的，充分利用了云平臺的特性。應(yīng)用的微服務(wù)可以專注于實(shí)現(xiàn)業(yè)務(wù)邏輯，而把微服務(wù)架構(gòu)的復(fù)雜度交給云平臺來解決。

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

云原生應(yīng)用的特征

與其他應(yīng)用相比，總結(jié)起來，云原生應(yīng)用有如下 15 個特征。

1、單一代碼庫

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

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

2、API 優(yōu)先

云原生應(yīng)用應(yīng)該采用 API 優(yōu)先的設(shè)計(jì)策略。微服務(wù)架構(gòu)的應(yīng)用使用公開 API 來作為服務(wù)的對外接口，API 屏蔽了服務(wù)的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)。API 優(yōu)先的設(shè)計(jì)策略指的是在設(shè)計(jì)階段，應(yīng)該首先設(shè)計(jì) API 并確定 API 的細(xì)節(jié)。API 的設(shè)計(jì)過程需要多個團(tuán)隊(duì)的參與，包括 API 的實(shí)現(xiàn)者和可能的使用者，這些團(tuán)隊(duì)在充分討論中最終完成了 API 的定義。API 可以使用 OpenAPI 規(guī)范描述，從該規(guī)范中可以生成 API 文檔和模擬服務(wù)器。 

API 優(yōu)先的策略保證了 API 的穩(wěn)定性，同時(shí)可以減少不必要的后期修改。因?yàn)?API 是服務(wù)之間的接口，修改 API 就意味著相關(guān)的內(nèi)部實(shí)現(xiàn)、測試用例和 API 的使用者都需要進(jìn)行修改，如果在應(yīng)用開發(fā)中出現(xiàn)了必須修改 API 的情況，那造成的影響是很大的。API 優(yōu)先確保了盡可能減少在開發(fā)中對 API 進(jìn)行修改。

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

3、依賴管理

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

4、設(shè)計(jì)、構(gòu)建、發(fā)布和運(yùn)行

云原生應(yīng)用應(yīng)該有完整的設(shè)計(jì)、構(gòu)建、發(fā)布和運(yùn)行流程，如下圖所示。

設(shè)計(jì)

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

構(gòu)建

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

發(fā)布

把構(gòu)建出來的工件推送到云平臺之上，就得到了一個發(fā)布版本，發(fā)布版本中包含與部署環(huán)境相關(guān)的配置信息。云原生應(yīng)用在部署時(shí)，通常有開發(fā)、測試和生產(chǎn) 3 個環(huán)境，在每個環(huán)境上的配置信息都不盡相同。發(fā)布版本也是不可變的，有唯一的發(fā)布號，每一個構(gòu)建版本都可能對應(yīng)多個發(fā)布版本。

運(yùn)行

運(yùn)行階段在云平臺之上運(yùn)行應(yīng)用，運(yùn)行的方式取決于云平臺，可以是虛擬機(jī)或容器。云平臺負(fù)責(zé)管理應(yīng)用的運(yùn)行，包括監(jiān)控應(yīng)用運(yùn)行狀態(tài)、處理失敗的情況和動態(tài)水平擴(kuò)展等。

5、代碼、配置和憑據(jù)

代碼、配置和憑據(jù)是云原生應(yīng)用開發(fā)中創(chuàng)建的三種不同類型的實(shí)體。代碼包括源代碼和相關(guān)資源文件；配置是與部署環(huán)境相關(guān)的配置信息，通常以 XML、YAML、JSON 或?qū)傩晕募男问匠霈F(xiàn)，配置中包含的信息包括第三方服務(wù)的連接方式、數(shù)據(jù)庫連接信息和應(yīng)用自身的配置屬性等；憑據(jù)指的是密碼、私鑰和 API 密鑰等敏感信息。

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

6、日志

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

7、隨時(shí)可丟棄

云原生應(yīng)用的生命周期可能是短暫的，隨時(shí)可能被終止。云平臺可能會隨時(shí)啟動和停止應(yīng)用的實(shí)例，這就要求云原生應(yīng)用的啟動和停止速度都要非?？?。當(dāng)應(yīng)用的負(fù)載突然增大時(shí)，可以快速地啟動新的實(shí)例來處理請求；當(dāng)應(yīng)用的實(shí)例出現(xiàn)問題時(shí)，可以快速啟動一個新的實(shí)例作為替代?？焖偻Ｖ箲?yīng)用和快速啟動應(yīng)用一樣重要，快速停止應(yīng)用保證了資源可以被及時(shí)釋放。

8、支撐服務(wù)

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

9、環(huán)境等同

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

10、管理任務(wù)

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

以生成報(bào)表為例，可以創(chuàng)建一個獨(dú)立的應(yīng)用來讀取數(shù)據(jù)庫并生成報(bào)表，該應(yīng)用可以有自己獨(dú)立的容器鏡像。如果報(bào)表生成是手動觸發(fā)的，該應(yīng)用應(yīng)該獨(dú)立運(yùn)行，并提供一個 API 接口來允許外部觸發(fā)。如果報(bào)表生成是定期的，應(yīng)用部署時(shí)可以創(chuàng)建相應(yīng)的定時(shí)任務(wù)來運(yùn)行容器，在容器啟動時(shí)自動生成報(bào)表，生成完畢之后，容器運(yùn)行結(jié)束。下圖說明了這兩種觸發(fā)方式的區(qū)別，圓角矩形的邊框表示應(yīng)用的邊界。 

11、端口綁定

云原生應(yīng)用在運(yùn)行時(shí)并不負(fù)責(zé)管理實(shí)際的端口綁定，而是由云平臺統(tǒng)一管理。比如，一個基于 Spring Boot 的微服務(wù)應(yīng)用通常在 8080 端口運(yùn)行 HTTP 服務(wù)，當(dāng)應(yīng)用運(yùn)行在云平臺上時(shí)，這個端口只是虛擬機(jī)或容器內(nèi)的端口，并不是外部用戶或其他服務(wù)訪問時(shí)的實(shí)際端口。云平臺對網(wǎng)絡(luò)進(jìn)行統(tǒng)一管理，負(fù)責(zé)分配實(shí)際的端口，云平臺同時(shí)提供了相應(yīng)的機(jī)制來發(fā)現(xiàn)訪問服務(wù)的實(shí)際地址和端口。

12、無狀態(tài)進(jìn)程

云原生應(yīng)用應(yīng)該是無狀態(tài)的。所有的狀態(tài)信息都應(yīng)該從應(yīng)用中抽離出來，并保存在支撐服務(wù)中，比如數(shù)據(jù)庫中。正因?yàn)閼?yīng)用是無狀態(tài)的，才可以由云平臺快速的啟動和停止，并進(jìn)行垂直或水平擴(kuò)展。

13、并發(fā)性

云原生應(yīng)用使用水平擴(kuò)展來并發(fā)運(yùn)行多個實(shí)例，使用負(fù)載均衡來把請求分配到某個實(shí)例進(jìn)行處理。

14、遙測數(shù)據(jù)

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

15、認(rèn)證和授權(quán)

云原生應(yīng)用應(yīng)該是安全的，安全應(yīng)該在應(yīng)用的設(shè)計(jì)階段就充分考慮。在實(shí)現(xiàn)中，可以使用基于角色的訪問控制（RBAC）來保護(hù) API，已經(jīng)有大量的開源框架來幫助實(shí)現(xiàn)認(rèn)證和授權(quán)。

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