SFKP • 計算機百科丨雲原生纔是「吞噬世界」的那條大魚...

過去的一全年裏，雲原生（Cloud Native）無疑是雲計算領域最熱的熱點。但一年過去了，到如今位置仍然不多有人能說清到底什麼是雲原生，網上的科普也都是寫的雲裏霧裏，看完仍然是似懂非懂...

這期的「SFKP • 計算機百科」，咱們就來嘗試着理清雲原生的概念、特性以及應用場景，幫助你得出心中「雲原生」的定義。

雲原生的概念

名詞解析：雲原生 Cloud Native

Cloud Native 翻譯爲雲原生，是 Matt Stine 提出的一個概念，它是一個思想的集合，包括 DevOps、持續交付、微服務、敏捷基礎設施、康威定律等，以及根據商業能力對公司進行重組。Cloud Native既包含技術也包含管理，能夠說是一系列Cloud技術、企業管理方法的集合。（Via.百度百科）

「雲原生」這個詞其實也不是沒爹沒孃的孩子，最先由 Pivotal（一家位於美國加州的計算機軟件公司）在 2013 年提出。2015 年，這家公司的 Matt Stine 在《遷移到雲原生架構》一書中定義了符合雲原生架構的幾個特徵：12 因素、微服務、自敏捷架構、基於 API 協做、扛脆弱性；

到了 2017 年，Matt Stine 在接受媒體採訪的時候又將雲原生架構概括爲模塊化、可觀察、可部署、可測試、可替換、可處理這六項特質；

而 Pivotal 最新官網對雲原生歸納爲4個要點：DevOps+持續交付+微服務+容器。

2015 年，雲原生計算基金會（CNCF）成立，他們最初把雲原生定義爲：容器化封裝 + 自動化管理 + 面向微服務；

到了2018年，CNCF又更新了雲原生的定義，把服務網格（Service Mesh）和聲明式 API 給加了進來，變成了如今的版本：不可變基礎設施、容器、服務網格、微服務、聲明式 API。

可見，雲原生的概念確實是在不斷變化的，而且哪怕都是權威機構，對於雲原生的概念和定義也是有所區別的。

但這些其實並不重要，因素在不斷變化，根本緣由是實現雲原生的方式在不斷變化。上面提到的這些因素都是實現雲原生的方式，但有了他們也未必就必定是雲原生，沒有他們不必定就不能實現雲原生。

又可是，既然咱們在討論什麼是雲原生，那就只能基於現階段的發展狀況來分析。綜合各權威機構和組織的說法，微服務、容器、DevOps 和持續交付這四個因素是必不可少的，咱們今天就着重分析一下這四項：

1. 微服務

微服務 (Microservices) 是一種軟件架構風格，它是以專一於單一責任與功能的小型功能區塊 爲基礎，利用模塊化的方式組合出複雜的大型應用程序，各功能區塊使用與語言無關的 API 集相互通訊。

幾乎每一個雲原生的定義都包含微服務，微服務的核心方法是切割，從而解決咱們軟件開發中一直追求的低耦合 + 高內聚的問題，也讓將來的系統變動具備彈性。

2. 容器

容器化爲微服務提供實施保障，起到應用隔離做用。優點是每一個服務都被無差異地封裝在容器裏，能夠被無差異地管理和維護。如今比較流行的工具是 Docker 和 Kubernetes。

Docker 是一個開源項目，讓應用程序部署在軟件貨櫃下的工做能夠自動化進行，藉此在 Linux 操做系統上，提供一個額外的軟件抽象層，以及操做系統層虛擬化的自動管理機制。Docker 也是目前應用最爲普遍的容器引擎，在思科谷歌等公司的基礎設施中大量使用。

而 Kubernetes 是由谷歌創建的，它是一個容許自動化部署、管理和伸縮容器的工具，而且提供了一些強大的功能，例如容器之間的負載均衡，重啓失敗的容器以及編排容器使用的存儲。

容器爲雲原生應用程序增長了更多優點。使用容器能夠將微服務及其所需的全部配置、依賴關係和環境變量移動到全新的服務器節點上，而無需從新配置環境，這樣就實現了強大的可移植性。

3. DevOps

DevOps (Development 和 Operations 的組合詞) 是一種重視軟件開發人員和 IT 運維技術人員之間溝通合做的文化、運動或慣例。透過自動化「軟件交付」和「架構變動」的流程，來使得構建、測試、發佈軟件可以更加地快捷、頻繁和可靠。

DevOps 的出現是因爲軟件行業日益清晰地認識到，爲了按時交付軟件產品和服務，開發部門和運維部門必須緊密合做。

當企業或者項目有良好的溝通效率，才能夠有更大的生產力。DevOps 的引入能對產品交付、測試、功能開發和維護（包括──曾經罕見但現在已家常便飯的──「熱補丁」）起到意義深遠的影響。

4. 持續交付

持續交付（英語：Continuous delivery，縮寫爲 CD），是一種軟件工程手法，讓軟件產品的產出過程在一個短週期內完成，以保證軟件能夠穩定、持續的保持在隨時能夠釋出的情況。它的目標在於讓軟件的建置、測試與釋出變得更快以及更頻繁。這種方式能夠減小軟件開發的成本與時間，減小風險。

持續交付的常見體現就是在不影響用戶使用服務的前提下，頻繁把新功能發佈給用戶使用。

要作到這點很是很是難，通常的要求是作到不誤時開發、不停機更新，這就要求開發版本和穩定版本並存，須要不少流程和工具支撐。

有時候，持續交付也與持續部署混淆。持續部署意味着全部的變動都會被自動部署到生產環境中。持續交付意味着全部的變動均可以被部署到生產環境中，可是出於業務考慮，能夠選擇不部署。

若是要實施持續部署，必須先實施持續交付。

雲原生和本地部署的區別

瞭解了雲原生的概念，咱們再來看看雲原生和本地部署的區別。

真正的雲化不只僅是基礎設施和平臺的變化，應用也須要作出改變，在架構設計、開發方式、部署維護等各個階段和方面都基於雲的特色，從新設計，從而建設全新的雲化的應用，即雲原生應用。

這裏，咱們引用阿里巴巴高級技術專家醬油（花名）發表的一篇文章中的分析：

1. 本地部署的傳統應用每每採用 C/C++、企業級 Java 編寫，而云原生應用則須要用以網絡爲中心的 Go、Node.js 等新興語言編寫。
2. 本地部署的傳統應用可能須要停機更新，而云原生應用應該始終是最新的，須要支持頻繁變動，持續交付，藍綠部署。
3. 本地部署的傳統應用沒法動態擴展，每每須要冗餘資源以抵抗流量高峯，而云原生應用利用雲的彈性自動伸縮，經過共享降本增效。
4. 本地部署的傳統應用對網絡資源，好比 IP、端口等有依賴，甚至是硬編碼，而云原生應用對網絡和存儲都沒有這種限制。
5. 本地部署的傳統應用一般人肉部署手工運維，而云原生應用這一切都是自動化的。
6. 本地部署的傳統應用一般依賴系統環境，而云原生應用不會硬鏈接到任何系統環境，而是依賴抽象的基礎架構，從而得到良好移植性。
7. 本地部署的傳統應用有些是單體（巨石）應用，或者強依賴，而基於微服務架構的雲原生應用，縱向劃分服務，模塊化更合理。

可見，要轉向雲原生應用須要以新的雲原生方法開展工做，也就是咱們在概念中提到的：微服務、容器、DevOps 和持續交付等。

「吞噬世界」的雲原生

這個圖你們必定熟悉又陌生。

2011 年，馬克·安德森說：「軟件正在吞噬世界」；三年後 Jonathan Bryce 又補充說：「世界的一切源於開源」；再以後，業內廣泛認同「雲計算已改變了天空的顏色」；但如今雲計算概念又被清晰細分，「雲原生」纔是那條最大的魚。

既然雲原生這麼好，咱們要不要立刻切換到雲原生架構？

我以爲既然雲原生的核心是應用，那麼實際的應用就要更加的慎重。須要考慮企業的實際需求，目前的架構是否影響了業務發展？推倒重建的代價是否可以承受的住？

這些都是須要考慮的問題。

去年靈雀雲進行過一次生態調研。在國內排名 TOP100 的 IT 方案商（ISV）中，約有 60~70% 在企業在接觸雲原生概念，但若是將調研範圍擴大到TOP300，這一認知比例反而大幅度降低。說明規模越大的企業越須要雲原生的能力來服務更多的客戶、提供更優質的服務。

小規模企業雖然更加靈活，但一方面是需求不那麼強烈，另外一方面雲原生仍然在不斷的迭代變化，這個變更對他們來講夾雜着不少的風險。

但數字化運營已經成爲企業發展的必然選擇，而云原生技術與數據中臺正是實現數字化運營所必須的創新技術與方法論。但大部分企業在數字化轉型的過程當中，平白付出了努力與時間，但由於對雲原生與數據中臺技術方法論瞭解匱乏，加之沒有好的平臺與體系來深刻了解而走了很多彎路。

雲原生是企業發展的一劑良藥，可是藥三分毒，仍是得慎重啊~

-END-

部分資料來源：

1.Picotal 官網：https://pivotal.io/cloud-native 阿里技術：《同志，雲原生了解一下？》《2020 雲原生 7 大趨勢預測》
2.twt社區：《「雲原生」究竟是什麼？「雲原生」的應用價值是什麼？》
3.Virtusa 執行副總裁 Senthil Ravindran：《爲什麼雲原生在吞噬世界 ？》
4.張戈bp：《「雲原生」纔是那條最大的魚》