理解什麼是雲原生和雲原生應用的十二要素

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

雲原生

雲原生計算基金會 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. 網絡資料

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/fC-0r2j97ithE-z2AoPizQ

猜你喜歡