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

云原生

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

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

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

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

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

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

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

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

十二要素應用

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

1、基準代碼

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

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

2、聲明式依賴

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

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

3、配置管理

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

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

4、后端服務

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

5、構建、發布、運行

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

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

6、進程

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

7、端口綁定

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

8、并發

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

9、易處理

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

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

10、開發環境與線上環境等價

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

11、日志

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

12、管理進程

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

總結

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

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

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

參考

1. 學透 Spring 從入門到項目實戰
2. 網絡資料