根據CNCF發布的雲原生1.0的定義，雲原生技術主要包括容器、微服務、服務網格、不可變基礎設施和聲明式API:
集裝箱技術
容器技術和雲原生質就像壹對螺旋體。容器技術催生了雲原生質，雲原生質生態推動了容器技術的發展。從2065 438+03 Docker科技的誕生，到2015雲原生領域重量級聯盟CNCF的成立，這不是歷史的巧合，而是歷史的必然。容器作為雲原生的關鍵技術之壹，自2013誕生以來，壹直是業界關註的焦點之壹。
2013之前，雲計算行業壹直在擔心雲的正確開放姿態。平臺即服務(PaaS)似乎是壹個很有前途的方向。Fotango公司2006年發布的米子服務可以說是PaaS行業的鼻祖，具有按使用付費和無服務器、API配置和服務等典型的雲原生特性。2008年，谷歌推出谷歌應用引擎(GAE)；2065 438+01 Pivotal發布的Cloud Foundry。
這些早期的PaaS平臺在雲原生生態領域做了非常有益的探索，促進了雲原生生態的健康發展。但是這些早期的探索技術並沒有形成大的行業趨勢，只是局限在壹些特定的領域。直到Docker開源，大家才如夢初醒。原來不是方向不對，而是應用分發交付的手段不好。
docker鏡像容器鏡像真正的核心創新，應用打包、分發、運行的新機制。容器映像將應用程序運行環境，包括代碼、依賴庫、工具、資源文件和元信息打包成壹個不可更改的軟件包，獨立於操作系統發行版。
容器映像將整個容器運行的環境打包，避免依賴運行容器的服務器的操作系統，從而實現“壹次構建，隨處運行”。壹旦構建了容器映像，它就變成只讀的，並成為不可變基礎結構的壹部分。
微服務
微服務架構是相對於單壹架構而言的，它們屬於不同的架構風格。在微服務架構中，服務是可以獨立部署的單個軟件組件，它實現壹些有用的功能。服務的API封裝了它的內部實現。與單壹架構不同，開發人員不能繞過服務的API直接訪問服務內部的方法和數據。因此，微服務架構迫使應用程序模塊化。
微服務架構的核心特征是服務之間的松耦合。服務之間的交互由API完成，API封裝了服務的實現細節，從而實現了實現方式的修改而不影響客戶端。
微服務架構將大型系統按照業務服務的粒度進行分解，每個服務都可以獨立開發、測試、驗證和部署。分解後，好處如下:
支持持續交付和部署大規模復雜應用。
每個服務都相對較小，易於維護。
服務可以獨立部署。
服務可以獨立擴展。
微服務架構可以實現團隊自治。
更容易試驗和采用新技術。
更好的容錯能力
服務網格
服務網格是壹個特殊的基礎設施層，用於處理服務之間的通信，並負責微服務之間的可靠請求傳遞。服務網格通常由壹組輕量級網絡代理來實現，這些代理與應用程序代碼壹起部署，而不需要知道應用程序本身。
隨著規模和復雜度的增長，服務網格包含越來越多的功能，其需求包括服務發現、負載均衡、故障恢復、指標收集和監控，通常還有更復雜的運維需求，如A/B測試、金絲雀發布、限流、訪問控制和端到端認證等。
服務網格具有以下特征:
應用程序之間通信的中間層
輕量級網絡代理
應用程序不敏感
分離應用重試/超時、監控、跟蹤和服務發現。
如果用壹句話來解釋什麽是服務網格，可以把它比作應用之間或者微服務之間的TCP/IP，負責服務之間的網絡接入、限流、融合和監控。壹般來說，寫應用不需要關心TCP/IP層(比如通過HTTP協議的RESTful應用)，也不需要把原本通過應用或者其他框架實現的服務之間的事情關聯起來，比如Spring Cloud和OSS，現在只需要交給服務網格就可以了，這極大的方便了微服務應用的開發。
不變的基礎設施
壹個工作負載(如容器、虛擬機等。)壹旦部署就不會被修改。當某些東西需要更新、修復或修改時，只需要用新的和經驗證的工作負載替換舊的工作負載。
不可變基礎設施的作用主要體現在系統的穩定性上。傳統應用壹旦部署到用戶專用的服務器上，服務器系統會不斷變化，要麽升級操作系統，要麽安裝新的應用，可能會產生沖突，導致應用需要隨著用戶系統環境的變化不斷升級，中間會不斷出現新的問題。不可變基礎設施避免了所有這些問題，因為雲原生應用部署在不可變基礎設施上，所以不存在變更的問題。
聲明式API
聲明式API是比命令式API更高級的界面設計方法。簡單來說，命令式API為用戶提供做什麽的能力，聲明式API為用戶提供做什麽的能力。
聲明式API是比命令式API更高級的接口。比如我們有壹臺料理機，如果料理機提供的接口是放油、調料、配料、大火、小火，那就是命令式API。
如果料理機提供的接口是服務宮保雞丁和魚香肉絲，那就是聲明式API。聲明式API的壹個典型例子是數據庫提供的SQL接口。妳只需要告訴數據庫妳需要什麽數據。至於如何獲取這些數據，數據庫會壹步步操作。