云原生這個詞相信大家都不陌生，那如果要問你，到底什么是云原生，該怎么回答呢？

云原生

云原生計算基金會 CNCF 在他們的官網(wǎng)上給出的解釋是這樣的。

云原生技術有利于各組織在公有云、私有云和混合云等新型動態(tài)環(huán)境中構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網(wǎng)格、微服務、不可變基礎設施和聲明式 API。

這些技術能夠構建容錯性好、易于管理和便于觀察的松耦合系統(tǒng)。結合可靠的自動化手段，云原生技術使工程師能夠輕松地對系統(tǒng)作出頻繁和可觀測的重大變更。

其實上面的定義講了這么多，對應什么是云原生還是很模糊的，不過從上面的定義中我們可以得到幾個關鍵的信息

1. 云原生應用是需要部署在云環(huán)境中的，但是反過來部署在云環(huán)境中的應用并不一定是云原生應用。
2. 云原生應用具備一定的可擴展性、容錯性和可觀察性；
3. 云原生不是一種技術或者框架，而是一種思想；

這個也比較好理解，早期的時候如果一個公司想要上線應用或者服務，需要自己購買機器部署機房，然后才能在機房的服務器中部署自己的應用，這種肯定不是云原生，畢竟連云都還沒有上。

后面漸漸的很多云廠商起來了，提供了云環(huán)境，這個時候大家如果要部署應用就不再需要自建機房了，只需要在云廠商那里購買對應數(shù)據(jù)中心的服務器就行，就可以部署應用了，但是到這里只能說我們的應用上云了，我們的應用還并不是云原生應用。

這也是我們上面提到的應用部署到了云環(huán)境上面，并不是代表就是云原生應用的，因為這個時候我們的應用并沒有充分利用云廠商的能力，同時也不具備擴展性、容錯性和可觀察性。

十二要素應用

前面介紹了什么是云原生，現(xiàn)在說下什么是十二要素應用。十二要素應用的提出是知名的 PasS 平臺 Heroku 的 CTO Adam Wiggins 提出的，原本說的是云上運行的應用需要遵守的 12 條最佳實踐，不過它也同樣適用于云原生應用。

1、基準代碼

基準代碼說的是在我們日常開發(fā)和部署的時候，可能會有很多個環(huán)境，比如開發(fā)，測試，線上等，我們需要是同一份基準代碼。不過這里主要強調的還是線上，因為我們云原生應用的部署是隨時隨地都可以動態(tài)擴展的，這就要保證我們線上的環(huán)境都是基于一份基準代碼來進行部署，實現(xiàn)一套代碼多份部署。

這點也很好理解，跟我們的分布式架構一樣，也是同一份代碼部署多個實例。

2、聲明式依賴

聲明式依賴說的是我們要顯示聲明依賴關系，現(xiàn)在有很多依賴管理工具，比如說我們的 Java 項目就會有 maven 和 gradle，其他語言的項目也會有其他的包管理工具。

除了我們開發(fā)中需要的類庫的依賴需要顯示之外，如果還需要依賴系統(tǒng)級別的工具或者庫，我們也需要進行聲明式的依賴，不能隱式依賴，這是因為在云原生的環(huán)境下，我們都是基于容器來部署應用的，如果不顯示的將這些依賴聲明出來，我們是不能創(chuàng)建出一模一樣的容器鏡像，這可能會導致服務不可用。

3、配置管理

一個應用如果想要正常的啟動，除了代碼沒問題之外還要有正確的配置才行，對于云原生應用來說也是一樣的。我們要做到不同的環(huán)境對于不同的配置，如果環(huán)境是一樣的，配置也需要是一樣的。并且要求我們的配置必須是和代碼分開的，這也是很好理解的，畢竟我們一份應用代碼要多環(huán)境部署，如果配置一樣那是沒有辦法部署的。

對于配置的管理可以用一些中間件，比如 Diamond 或者其他的一些配置中心來管理，配置中心可以實現(xiàn)配置的實時變更和推送，很方便我們進行管理和變更。

4、后端服務

這里的后端服務更多說的是我們應用依賴的一些下游服務、組件服務、中間件服務，比如消息隊列、數(shù)據(jù)庫、緩存、調度平臺等。云原生應用要求我們把這些后端服務都要當成資源來調用，并且這些資源也要符合云原生應用的規(guī)范，也就是能隨時動態(tài)擴展。

5、構建、發(fā)布、運行

云原生應用要求我們嚴格將應用的構建、發(fā)布和運行進行隔離。應用的這幾個過程是每次需求迭代過后上線的必經(jīng)過程，并且這幾個步驟是按照這個順序進行的，也就是說不存在還沒構建就進行發(fā)布，這個很好理解。對于我們 Java 應用來說，構建就是將源代碼進行編譯和打包，在構建階段如果不通過是不會進行下一步的。

應用構建的時候如果缺少依賴或者有編譯錯誤都會終止構建；發(fā)布則是將我們編譯好的 Jar 包或者其他形式和配置文件一起進行部署到指定環(huán)境的容器中；運行則是將需要發(fā)布的內容進行啟動，這個時候如果我們的配置有問題有可能會導致應用啟動不了。

6、進程

云原生應用要求我們的應用是無狀態(tài)的，這個也很好理解，畢竟云原生是隨時可擴展的，那就必須要求我們的應用是無狀態(tài)的，這就要求我們在開發(fā)的時候就要注意不要在代碼中使用一些需要狀態(tài)的邏輯。比如定時任務 scheduled 這種，會導致每個實例都會定時運行，可能會產(chǎn)生問題，可以采用類似于 XXL-JOB 這種分布式調度平臺。

7、端口綁定

應用通過綁定端口來提供服務，這一點可能有些小伙伴不理解，因為現(xiàn)在大部分情況下我們已經(jīng)是這樣做的了，之所以提出這一點是為了避免在應用中使用進程通信。

8、并發(fā)

要求在高并發(fā)的時候支持通過進程擴展，也就是要求我們的應用是無狀態(tài)，能通過更多的進程部署來實現(xiàn)擴展。這一點也很好理解，跟我們前面提到的無狀態(tài)也是有關聯(lián)的。

9、易處理

所謂易處理說的是我們的云原生應用應該具備快速啟動和優(yōu)雅終止的能力，因為的云原生環(huán)境要求具有彈性擴容的能力，那就需要我們的應用能夠快速的啟動和結束。

快速啟動可以讓我們的應用更快的提供服務，更快的滿足彈性伸縮的要求，而優(yōu)雅的終止也是為了避免在應用關閉的時候還存在任務或者流量訪問。

10、開發(fā)環(huán)境與線上環(huán)境等價

此外我們需要盡量的保持開發(fā)環(huán)境、預發(fā)環(huán)境以及線上云原生環(huán)境相同，當然這里的相同只是是盡可能的保持相同，同樣的環(huán)境能保證我們實現(xiàn)的功能不會因為環(huán)境問題而出現(xiàn)不可用的情況。但是要知道因為一些資源的問題，開發(fā)環(huán)境、預發(fā)環(huán)境跟線上環(huán)境是不會完全一樣的。

11、日志

云原生要求我們把日志當成事件流，同樣是因為云原生環(huán)境應用的實例個數(shù)隨時都在發(fā)生著變化，每個實例時時刻刻都會產(chǎn)生日志，我們不能說在每臺實例上面查看日志，所以我們要把日志統(tǒng)一收集和采集到特定的日志系統(tǒng)中。這一點其實在分布式系統(tǒng)里面也是一樣的，一般會通過 ELK 技術，將日志進行存儲和分析。

12、管理進程

最后一條這個管理進程指的是將后臺管理系統(tǒng)的任務當成是一次性的進程進行執(zhí)行，其實這一點不算是普適的要素，跟具體的后臺系統(tǒng)功能有關，這里就不討論了。

總結

上面提到了什么是云原生以及 12 條云原生應用的要素，很多跟我們分布式系統(tǒng)的要求都是一致的，只不過云原生應用的要求會更高一點，更嚴格一點，更自動化一點。

從了不起的角度來看云原生應用是目前看來最好的一種方式，對于企業(yè)或者個人來說都是最快和成本最低的。

對于很多小公司來說完全沒必要自建一套基礎設施，直接采用云廠商提供的能力就好，從而快速實現(xiàn)自身業(yè)務的發(fā)展，畢竟小公司活下去才是最重要的，沒必要在這種事情上面浪費時間和精力。

參考

1. 學透 Spring 從入門到項目實戰(zhàn)
2. 網(wǎng)絡資料