過去的一整年里，云原生(Cloud Native)無疑是云計算領域最熱的熱點。但一年過去了，到現(xiàn)在位置仍然很少有人能說清到底什么是云原生，網(wǎng)上的科普也都是寫的云里霧里，看完仍然是似懂非懂...

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

云原生的概念

[[314289]]

名詞解析：云原生 Cloud Native

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

「云原生」這個詞其實也不是沒爹沒娘的孩子，最早由 Pivotal(一家位于美國加州的計算機軟件公司)在 2013 年提出。2015 年，這家公司的 Matt Stine 在《遷移到云原生架構》一書中定義了符合云原生架構的幾個特征：12 因素、微服務、自敏捷架構、基于 API 協(xié)作、扛脆弱性;

到了 2017 年，Matt Stine 在接受媒體采訪的時候又將云原生架構歸納為模塊化、可觀察、可部署、可測試、可替換、可處理這六項特質;

而 Pivotal 最新官網(wǎng)對云原生概括為4個要點：DevOps+持續(xù)交付+微服務+容器。

2015 年，云原生計算基金會(CNCF)成立，他們最初把云原生定義為：容器化封裝 + 自動化管理 + 面向微服務;

到了2018年，CNCF又更新了云原生的定義，把服務網(wǎng)格(Service Mesh)和聲明式 API 給加了進來，變成了現(xiàn)在的版本：不可變基礎設施、容器、服務網(wǎng)格、微服務、聲明式 API。

可見，云原生的概念確實是在不斷變化的，并且哪怕都是權威機構，對于云原生的概念和定義也是有所區(qū)別的。

但這些其實并不重要，因素在不斷變化，根本原因是實現(xiàn)云原生的方式在不斷變化。上面提到的這些因素都是實現(xiàn)云原生的方式，但有了他們也未必就一定是云原生，沒有他們不一定就不能實現(xiàn)云原生。

又但是，既然我們在討論什么是云原生，那就只能基于現(xiàn)階段的發(fā)展情況來分析。綜合各權威機構和組織的說法，微服務、容器、DevOps 和持續(xù)交付這四個因素是必不可少的，我們今天就著重分析一下這四項：

1. 微服務

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

幾乎每個云原生的定義都包含微服務，微服務的核心方法是切割，從而解決我們軟件開發(fā)中一直追求的低耦合 + 高內聚的問題，也讓未來的系統(tǒng)變更具有彈性。

2. 容器

容器化為微服務提供實施保障，起到應用隔離作用。優(yōu)勢是每個服務都被無差別地封裝在容器里，可以被無差別地管理和維護。現(xiàn)在比較流行的工具是 Docker 和 Kubernetes。

Docker 是一個開源項目，讓應用程序部署在軟件貨柜下的工作可以自動化進行，借此在 Linux 操作系統(tǒng)上，提供一個額外的軟件抽象層，以及操作系統(tǒng)層虛擬化的自動管理機制。Docker 也是目前應用最為廣泛的容器引擎，在思科谷歌等公司的基礎設施中大量使用。

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

容器為云原生應用程序增加了更多優(yōu)勢。使用容器可以將微服務及其所需的所有配置、依賴關系和環(huán)境變量移動到全新的服務器節(jié)點上，而無需重新配置環(huán)境，這樣就實現(xiàn)了強大的可移植性。

3. DevOps

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

DevOps 的出現(xiàn)是由于軟件行業(yè)日益清晰地認識到，為了按時交付軟件產(chǎn)品和服務，開發(fā)部門和運維部門必須緊密合作。

當企業(yè)或者項目有良好的溝通效率，才可以有更大的生產(chǎn)力。DevOps 的引入能對產(chǎn)品交付、測試、功能開發(fā)和維護(包括──曾經(jīng)罕見但如今已屢見不鮮的──“熱補丁”)起到意義深遠的影響。

4. 持續(xù)交付

持續(xù)交付(英語：Continuous delivery，縮寫為 CD)，是一種軟件工程手法，讓軟件產(chǎn)品的產(chǎn)出過程在一個短周期內完成，以保證軟件可以穩(wěn)定、持續(xù)的保持在隨時可以釋出的狀況。它的目標在于讓軟件的建置、測試與釋出變得更快以及更頻繁。這種方式可以減少軟件開發(fā)的成本與時間，減少風險。

持續(xù)交付的常見體現(xiàn)就是在不影響用戶使用服務的前提下，頻繁把新功能發(fā)布給用戶使用。

要做到這點非常非常難，一般的要求是做到不誤時開發(fā)、不停機更新，這就要求開發(fā)版本和穩(wěn)定版本并存，需要很多流程和工具支撐。

有時候，持續(xù)交付也與持續(xù)部署混淆。持續(xù)部署意味著所有的變更都會被自動部署到生產(chǎn)環(huán)境中。持續(xù)交付意味著所有的變更都可以被部署到生產(chǎn)環(huán)境中，但是出于業(yè)務考慮，可以選擇不部署。

如果要實施持續(xù)部署，必須先實施持續(xù)交付。

云原生和本地部署的區(qū)別

了解了云原生的概念，我們再來看看云原生和本地部署的區(qū)別。

真正的云化不僅僅是基礎設施和平臺的變化，應用也需要做出改變，在架構設計、開發(fā)方式、部署維護等各個階段和方面都基于云的特點，重新設計，從而建設全新的云化的應用，即云原生應用。

這里，我們引用阿里巴巴高級技術專家醬油(花名)發(fā)表的一篇文章中的分析：

• 本地部署的傳統(tǒng)應用往往采用 C/C++、企業(yè)級 Java 編寫，而云原生應用則需要用以網(wǎng)絡為中心的 Go、Node.js 等新興語言編寫。
• 本地部署的傳統(tǒng)應用可能需要停機更新，而云原生應用應該始終是最新的，需要支持頻繁變更，持續(xù)交付，藍綠部署。
• 本地部署的傳統(tǒng)應用無法動態(tài)擴展，往往需要冗余資源以抵抗流量高峰，而云原生應用利用云的彈性自動伸縮，通過共享降本增效。
• 本地部署的傳統(tǒng)應用對網(wǎng)絡資源，比如 IP、端口等有依賴，甚至是硬編碼，而云原生應用對網(wǎng)絡和存儲都沒有這種限制。
• 本地部署的傳統(tǒng)應用通常人肉部署手工運維，而云原生應用這一切都是自動化的。
• 本地部署的傳統(tǒng)應用通常依賴系統(tǒng)環(huán)境，而云原生應用不會硬連接到任何系統(tǒng)環(huán)境，而是依賴抽象的基礎架構，從而獲得良好移植性。
• 本地部署的傳統(tǒng)應用有些是單體(巨石)應用，或者強依賴，而基于微服務架構的云原生應用，縱向劃分服務，模塊化更合理。

可見，要轉向云原生應用需要以新的云原生方法開展工作，也就是我們在概念中提到的：微服務、容器、DevOps 和持續(xù)交付等。

「吞噬世界」的云原生

這個圖大家一定熟悉又陌生。

2011 年，馬克·安德森說：“軟件正在吞噬世界”;三年后 Jonathan Bryce 又補充說：“世界的一切源于開源”;再之后，業(yè)內普遍認同“云計算已改變了天空的顏色”;但現(xiàn)在云計算概念又被清晰細分，“云原生”才是那條最大的魚。

既然云原生這么好，我們要不要馬上切換到云原生架構?

我覺得既然云原生的核心是應用，那么實際的應用就要更加的慎重。需要考慮企業(yè)的實際需求，目前的架構是否影響了業(yè)務發(fā)展?推倒重建的代價是否能夠承受的住?

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

去年靈雀云進行過一次生態(tài)調研。在國內排名 TOP100 的 IT 方案商(ISV)中，約有 60~70% 在企業(yè)在接觸云原生概念，但如果將調研范圍擴大到TOP300，這一認知比例反而大幅度下降。說明規(guī)模越大的企業(yè)越需要云原生的能力來服務更多的客戶、提供更優(yōu)質的服務。

小規(guī)模企業(yè)雖然更加靈活，但一方面是需求不那么強烈，另一方面云原生仍然在不斷的迭代變化，這個變動對他們來說夾雜著很多的風險。

但數(shù)字化運營已經(jīng)成為企業(yè)發(fā)展的必然選擇，而云原生技術與數(shù)據(jù)中臺正是實現(xiàn)數(shù)字化運營所必須的創(chuàng)新技術與方法論。但大部分企業(yè)在數(shù)字化轉型的過程中，平白付出了努力與時間，但因為對云原生與數(shù)據(jù)中臺技術方法論了解匱乏，加之沒有好的平臺與體系來深入了解而走了不少彎路。

云原生是企業(yè)發(fā)展的一劑良藥，但是藥三分毒，還是得慎重啊~