為什麼你必須瞭解雲原生？！

軟體架構持續交付 · 發表 2019-05-10 19:07:42

摘要：作者 | 我不想種地責編 | 胡巍巍伴隨雲端計算的滾滾浪潮，雲原生（Cloud Native）的概念應運而生，雲原生很火，火得一塌糊塗，都9102年了，如果你還不懂雲原生，那真的Out了。大家言必稱雲原生，卻鮮少有人告訴你到底什麼是雲原生，若是找資料來看，...

作者 | 我不想種地

責編 | 胡巍巍

伴隨雲端計算的滾滾浪潮，雲原生（Cloud Native）的概念應運而生，雲原生很火，火得一塌糊塗，都9102年了，如果你還不懂雲原生，那真的Out了。

大家言必稱雲原生，卻鮮少有人告訴你到底什麼是雲原生，若是找資料來看，讀完大多會感覺雲繞霧罩，一知半解，總之虛得很；

甚至會讓你一度懷疑自己的智商，不過我對於讀不懂的文章，一律歸因於寫文章的人太蠢，當然這不一定是事實，但這樣的思考方式能讓我避免陷入自我懷疑的負面情緒。

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

技術的變革，一定是思想先行，無產階級革命事業興旺發達也是因為有戰無不勝的馬指導。

何謂雲原生？

雲原生是一種構建和執行應用程式的方法，是一套技術體系和方法論。雲原生（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模式，實在是保命裝逼、評優晉級不可多得的終極絕密武器。

雲元素的四要素

微服務：

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

微服務架構的好處就是按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桌面程式，是不是很高階？

那時候碼農的擔心相比現在恐怕是隻多不少吧，但後來隨著網際網路興起，出現了後端開發這個工種，碼農很快找到了新的戰場，網路、分散式、資料庫、海量服務、容災防錯，於是又玩出一堆新花樣。

如果說PC時代的基礎設施是控制元件庫，網際網路時代的基礎實施是雲，那AI時代基礎設施是什麼？又有什麼高階玩法？

作者簡介：我不想種地，作者公眾號【碼磚雜役】，歡迎關注。

宣告：本文為作者原創投稿，版權歸其個人所有。作者獨立觀點，不代表CSDN立場。

【END】