這兩年，云原生的火熱程度一點都不亞于2014年的3D打印、2018年的區塊鏈，有種“忽如一夜春風來，千樹萬樹梨花開”的既視感。為此，筆者想借著這股“東風”，來談一談云原生。由于云原生概念并沒有明確，筆者理解可能有失偏頗，行文中若有偏差，敬請各位斧正。

其實，云原生的英文全稱為“CloudNative”，可以將這個單詞拆分為Cloud、Native兩個單詞：Cloud意即云，表示應用程序在云上，不是在傳統的數據中心、服務器;Native意即原生的、土著的、當地的、土生土長，表示應用程序專門為云環境設計。可以想象，“云原生”的漢語名稱并沒有采用云土著、云當地、云土生土長，而采用了一個非常優美的名字——云原生。

因此，云原生一種構建和運行應用程序的技術體系和方法論，這套技術體系從設計之初即考慮到云的環境，充分利用和發揮云平臺的彈性和分布式優勢。華為曾對符合云原生架構的應用程序如是描述：采用開源堆棧(K8S+Docker)進行容器化，基于微服務架構提高靈活性和可維護性，借助敏捷方法、DevOps支持持續迭代和運維自動化，利用云平臺設施實現彈性伸縮、動態調度、優化資源利用率。  

通過華為的這段描述，可以看出云原生的四個要素：容器化、微服務、DevOps、持續交付，這是現在公認的，也是Pivotal概括的4個主要要素，對此，不同的云計算廠商在原有的4要素之上有所延伸，有著自己的見解。

2013年，Pivotal公司的Matt Stine首次提出云原生(CloudNative)概念。

2015年，《遷移到云原生架構》定義了云原生架構的特征：12因素、微服務、自敏捷架構、基于API協作、扛脆弱性。

同年，云原生計算基金會(CNCF)成立，并將云計算定義為容器化封裝+自動化管理+面向微服務。

2017年，Matt Stine將云原生架構歸納為模塊化、可觀察、可部署、可測試、可替換、可處理6特質。

彼時，Pivotal將云原生概括為DevOps+持續交付+微服務+容器。

2018年，CNCF更新了云原生的定義，將服務網格(Service Mesh)和聲明式API加進來。

從云原生誕生到發展的脈絡來看，云原生的定義不斷完善，并存在概念混亂、不統一的現狀，不過目前，大多數云計算企業習慣使用DevOps+持續交付+微服務+容器來定義云原生。下面，我們來簡單理解一下云原生的4個主要要素。

1、微服務

微服務是一個獨立發布的應用服務，可以作為獨立組件升級、灰度或復用等，每個服務可以由專門的組織來單獨完成，依賴方只要定好輸入和輸出口即可完全開發，甚至整個團隊的組織架構更精簡，溝通成本低、效率高。

2、devOps

DevOps字面上是組合詞——Dev、Ops，即開發人員、運維人員。實際上，DevOps是一組過程、方法與系統的統稱，DevOps強調高效組織團隊之間如何通過自動化的工具協作和溝通來完成軟件的聲明周期管理，從而更快、更頻繁地交付更穩定的軟件。 

3、持續交付

敏捷開發要求持續交付，因為敏捷開發要求隨時有一個版本可以上到大群環境，所以要持續交付。持續交付目的的快速應對客戶的需求變化，要求發布非常頻繁，所以會存在多個版本同時提供服務的情況，因此需要支持灰度發布/金絲雀發布等。

4、容器化

Docker是軟件行業最受歡迎的軟件容器項目，Docker起到應用隔離作用，為微服務及其所需的所有配置、依賴關系和環境變量移動到全新、無差別的運行環境，移植性強。但是docker對于分布式應用的部署和編排沒有考慮，在網絡和存儲方式都沒有提出比較好的方式，包括docker-compose。

此外，與原生與本地部署有著什么樣的區別?

1、編程語言

據悉，本地部署的傳統應用采用C/C++、企業級java編寫;云原生應用需要用以網絡為中心的go、node.js等新興語言編寫。

2、持續交付

本地部署的傳統應用需要停機更新;云原生應用應該始終是最新的，需要支持頻繁變更，持續交付，藍綠部署。

3、動彈擴展

本地部署的傳統應用無法動態擴展，往往需要冗余資源以抵抗流量高峰，而云原生應用利用云的彈性自動伸縮，通過共享降本增效。

4、網絡限制

本地部署的傳統應用對網絡資源，比如ip、端口等有依賴，甚至是硬編碼，而云原生應用對網絡和存儲都沒有這種限制。

5、自動化

本地部署的傳統應用通常人肉部署手工運維，而云原生應用這一切都是自動化的。

6、移植性

本地部署的傳統應用通常依賴系統環境，而云原生應用不會硬連接到任何系統環境，而是依賴抽象的基礎架構，從而獲得良好移植性。

7、服務架構

本地部署的傳統應用有些是單體(巨石)應用，或者強依賴，而基于微服務架構的云原生應用，縱向劃分服務，模塊化更合理。