戳藍字“CSDN云計算”關注我們哦！

盡管隨處可聞云原生，卻鮮少有人告訴你到底什么是云原生，若是找資料來看，讀完大多會感覺云繚霧繞，一知半解，總之虛得很，甚至會讓你一度懷疑自己的智商，不過我對于讀不懂的文章，一律歸因于文章寫得不夠直白，當然這不一定是事實，但這樣的思考方式能讓我避免陷入自我懷疑的負面情緒。

云原生之所以解釋不清楚，是因為云原生沒有確切的定義，云原生一直在發展變化之中，解釋權不歸某個人或組織所有。

技術的變革，一定是思想先行。

何謂云原生？

云原生是一種構建和運行應用程序的方法，是一套技術體系和方法論。云原生（CloudNative）是一個組合詞，Cloud+Native。Cloud 表示應用程序位于云中，而不是傳統的數據中心；Native 表示應用程序從設計之初即考慮到云的環境，原生為云而設計，在云上以最佳姿勢運行，充分利用和發揮云平臺的彈性+分布式優勢。

Pivotal 公司的 Matt Stine 于2013年首次提出云原生（CloudNative）的概念；2015年，云原生剛推廣時，Matt Stine 在《遷移到云原生架構》一書中定義了符合云原生架構的幾個特征：12因素、微服務、自敏捷架構、基于 API 協作、扛脆弱性；到了2017年，Matt Stine 改了口風，將云原生架構歸納為模塊化、可觀察、可部署、可測試、可替換、可處理6特質；而 Pivotal 最新官網對云原生概括為4個要點：DevOps+持續交付+微服務+容器。

2015年云原生計算基金會（CNCF）成立，CNCF 摻和進來后，最初把云原生定義為包括：容器化封裝+自動化管理+面向微服務；到了2018年，CNCF 又更新了云原生的定義，把服務網格(Service Mesh)和聲明式 API 給加了進來。

可見，不同的人和組織對云原生有不同的定義，相同的人和組織在不同時間點對云原生也有不同的定義，我的應對很簡單，選一個我最容易記住和理解的定義：DevOps+持續交付+微服務+容器。

總而言之，符合云原生架構的應用程序應該是：采用開源堆棧（K8S+Docker）進行容器化，基于微服務架構提高靈活性和可維護性，借助敏捷方法、DevOps支持持續迭代和運維自動化，利用云平臺設施實現彈性伸縮、動態調度、優化資源利用率。

云原生構建應用簡便快捷，部署應用輕松自如、運行應用按需伸縮。優點不一而足，缺點微乎其微，秒殺傳統 Web 框架，吊打祖傳 IT 模式，實在是保命或評優晉級的不可多得的終極絕密武器。

云原生的四要素

微服務

幾乎每個云原生的定義都包含微服務，跟微服務相對的是單體應用，微服務有理論基礎，那就是康威定律，指導服務怎么切分，很玄乎，凡是能稱為理論定律的都簡單明白不了，定律的大概意思是組織架構決定產品形態，不知道跟馬克思的生產關系影響生產力有無關系。

微服務架構的好處就是按 function 切了之后，服務解耦，內聚更強，變更更易；另一個劃分服務的技巧據說是依據 DDD 來搞，不過鄙人對 DDD 知之甚少。

容器化

Docker 是應用最為廣泛的容器引擎，在思科、谷歌等公司的基礎設施中大量使用，是基于 LXC 技術搞的，容器也是一個進程，容器化為微服務提供實施保障，起到應用隔離作用；K8S 是容器編排系統，用于容器管理，容器間的負載均衡，谷歌搞的，Docker 和 K8S 都采用 Go 編寫，都是好東西，你值得擁有。

DevOps

這是個組合詞，Dev+Ops，就是開發和運維合體，不像開發和產品，經常刀劍相見，實際上 DevOps 應該還包括測試，DevOps 是一個敏捷思維，是一個溝通文化，也是組織形式，為云原生提供持續交付能力。

持續交付

持續交付是不誤時開發，不停機更新，小步快跑，反傳統瀑布式開發模型，這要求開發版本和穩定版本并存，其實需要很多流程和工具支撐。

圖片來源網絡

如何云原生？

首先，云原生借了云計算的東風，沒有云計算，自然沒有云原生，云計算是云原生的基礎。

隨著虛擬化技術的成熟和分布式框架的普及，在容器技術、可持續交付、編排系統等開源社區的推動下，以及微服務等開發理念的帶動下，應用上云已經是不可逆轉的趨勢。

云計算的3層劃分，即基礎設施即服務(IaaS)、平臺即服務(PaaS)、軟件即服務(SaaS)為云原生提供了技術基礎和方向指引，真正的云化不僅僅是基礎設施和平臺的變化，應用也需要做出改變，擯棄傳統的土方法，在架構設計、開發方式、部署維護等各個階段和方面都基于云的特點，重新設計，從而建設全新的云化的應用，即云原生應用。

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

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

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

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

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

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

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

可見，要轉向云原生應用需要以新的云原生方法開展工作。云原生包括很多方面：基礎架構服務、虛擬化、容器化、容器編排、微服務。幸運的是，開源社區在云原生應用方面做出了大量卓有成效的工作，很多開源的框架和設施可以通過拿來主義直接用，2013年 Docker 推出并很快成為容器事實標準，隨后圍繞容器編排的混戰中，2017年誕生的 k8s 很快脫穎而出，而這些技術極大的降低了開發云原生應用的技術門檻。

圖片來源網絡
雖說云原生的推介文檔有引導之嫌，但面對它列舉的優點，作為杠精的我亦是無可辯駁。這么說的話，云原生也忒好了吧，應用是不是要立刻馬上分分鐘切換到云原生架構？我的觀點是：理想很豐滿，現實很骨感，需從應用的實際需要出發，目前的問題是否真的影響到業務發展？而推倒重來的代價能否承受得來？我曾經經歷過游戲團隊要把帶狀態的游戲服務器用微服務思路去做，折騰得死去活來最后以失敗告終。

技術的趨勢和影響

軟件設計有兩個關鍵目標：高內聚、低耦合，圍繞這2個核心目標，又提出了單一職責、開閉原則、里氏替換、依賴倒置、接口隔離、最少知識等設計原則。

軟件工程師一直都在為這兩個目標而努力奮斗，以求把軟件編寫得更加清晰、更加健壯、更加易于擴展和維護。

但后來，人們發現有更多的訴求，希望開發軟件變得更簡單、更快捷，程序員希望更少編寫代碼，非專業人員也希望能開發程序，于是，更多更傻瓜式的編程語言被發明出來，更多的編程技術(組件)和編程思想(復用)被發明出來，比如庫、組件、云基礎設施。

于是很多技術變成了屠龍之技，比如匯編，時代變了，然后很多軟件工程師搖身一變成了調參工程師、Call API 專家、用庫包能手、拼組件達人，這是效率分工的結果，也是技術發展的使然。

縱觀近二十年的科技互聯網發展歷程，大的趨勢是技術下沉，特別是近些年，隨著云計算的發展和普及，基礎設施越來越厚實，業務開發變得越來越容易，也越來越沒有技術含量，而之前困擾小團隊的性能、負載、安全性、擴展性問題都不復存在，這不禁讓互聯網行業的油膩大叔們噤若寒蟬，仿佛分分鐘就要被卷入歷史洪流而萬劫不復。

雖然不可否認技術的重要性在降低，但也還不至于那么悲觀。遙想 PC 時代，當VB、Delphi、MFC 出現的時候，也有類似論調，所見即所得，點點鼠標，就可以開發 PC 桌面程序，有沒有很高端？那時候工程師的擔心相比現在恐怕是只多不少吧，但后來隨著互聯網興起，出現了后端開發這個工種，工程師很快找到了新的戰場：網絡、分布式、數據庫、海量服務、容錯容災，于是又不亦樂乎地玩出一堆新花樣。


福利掃描添加小編微信，備注“姓名+公司職位”，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！

推薦閱讀：

• 漫畫：程序員戰力圖鑒
  
• 我們到底該如何看待6G？
  
• 漫畫：什么是插入排序？
  
• 從七個方面，面試大廠高級工程師
  
• 為什么說邊緣計算的發展比5G更重要？
  

• 記一道字節跳動的算法面試題? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

真香，朕在看了！

總結

以上是生活随笔為你收集整理的关于云原生需要了解什么的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。