隨著企業數據量持續增長、業務系統日趨複雜、市場競爭日趨激烈，用戶需求需要得到越來越及時的響應，用戶服務需要不間斷地進行。但採用的傳統的雲計算服務模式，即按照傳統模式開發業務系統然後部署到雲上，會使得雲計算按需定製、彈性伸縮等優勢難以充分發揮。為解決以上問題，「雲原生」就此誕生。
雲原生是指專門為在雲平臺部署和運行而設計的應用及架構，包括十二項基本要素，分別是：
1.同一應用對應同一套基準代碼，並能多次部署；
2.顯式聲明第三方依賴；
3.將配置存儲至環境變量；
4.將後端服務作為鬆耦合的資源；
5.嚴格分離構建階段與運行階段；
6.將應用作為無狀態的進程運行；
7.通過埠綁定對外發布服務；
8.能夠通過水平伸縮應用程式進程來實現並發；
9.可以快速啟動和關閉應用；
10.要保持開發環境與生產環境等價；
11.使用事件流處理日誌；
12.將後臺管理任務當做一次性進程運行。
更具體來說，雲原生涉及一系列技術，典型技術包括以Docker和Kubernetes編排工具為主的容器技術、以Service Mesh為發展方向的微服務技術，以及以快速迭代、持續交付為目的的DevOps（開發運維一體化）技術。
關於容器技術。
容器是指將應用程式及其環境一起打包作為交付物，該交付物可以隨時構建、裝載、運行。由於其它類型容器（如RKT）市場佔比較低，容器一般指Docker。
容器編排工具是指讓集群中的多個容器能夠按計劃、有組織運行的工具。Kubernetes作為CNCF孵化項目，相比Mesos和Swarm已經呈現出十分明顯的優勢。
傳統虛擬機包含完整的作業系統，一旦開啟即對硬體資源的一部分獨佔。容器引擎只是一個隔離的進程，對資源並不獨佔，因此是一種更輕量的虛擬化。這使得容器在文件體積、啟動速度、佔用資源和開啟數量上都具有明顯優勢。
容器將依賴環境一起打包，因而屏蔽了開發、測試和運行環境的差異，再加上秒啟、可多開的特性，使得微服務和DevOps均得以實現。所以可以說，容器技術是雲原生的最佳載體，成為雲原生的基石
關於微服務。
採用化整為零的概念，將複雜的IT系統部署，通過功能化、原子化分解，形成一種鬆散耦合的組件，讓其更容易升級和擴展。
每個應用組件將其自身功能以服務的形式展現出來，並按照預先定義的協議進行交互，各個服務組件之間是鬆耦合的。
某個應用組件的程式語言與技術選型不會影響主體應用，如某個服務組件可以用Java 開發，而另一個可以用.NET開發。
每個服務組件都可以享有自己的資料庫，且該資料庫僅供該服務組件自己使用，其他服務組件都不能讀取或者修改。
每個服務組件都是可以自行部署和測試的，任何一個服務組件在測試、部署和運行的時候都不依賴其他服務組件。
任何一個服務組件的故障都應該是隔離的，單個服務組件的故障不應該拖垮整個應用，也不應該影響其他服務組件。
微服務是雲原生的實現方式，不僅涉及技術架構，還涉及業務怎麼劃分以及組織如何管理，如不同步規劃將無法發揮其價值。
關於DevOps。
隨著企業IT系統越來越複雜，功能迭代、局部升級、A/B Test甚至版本回滾成為常態，這都對開發、運維模式提出了新挑戰，DevOps應運而生。
DevOps即開發運維一體化，是敏捷開發的繼承和發展，目的是持續集成、持續交付，貫穿於開發到上線的始終。
DevOps因Docker的使用而更加簡單，所以完整的DevOps體系中會包含Docker、Kubernetes等工具。
DevOps和微服務很多技術都是重合的，但兩者的關注點並不同，微服務幫助我們以一種細顆粒度的方式開發、測試和發布服務，而DevOps提倡小規模和小批量的持續集成和持續部署，兩者相輔相成的，共同解決問題；
DevOps進一步增強了雲原生的敏捷特性，但其同樣對企業內部的業務職責劃分和組織架構調整提出了要求。
總結一下，容器+微服務+DevOps是實現雲原生的最佳組合，但只有容器是一種比較明確的技術，而微服務和DevOps更像是一種方法論，僅僅有技術層面的配合是遠遠不夠的，還需要有組織架構層面以及管理流程層面的共同配合才能發揮作用。
創作不易，歡迎朋友們關注、評論、轉發。如企業轉載或其它，請聯繫：keji5u（科技無憂訂閱號）