過去的一整年裡，雲原生（Cloud Native）無疑是雲計算領域最熱的熱點。但一年過去了，到現在位置仍然很少有人能說清到底什麼是雲原生，網上的科普也都是寫的雲裡霧裡，看完仍然是似懂非懂...
這期的「SFKP • 計算機百科」，我們就來嘗試着理清雲原生的概念、特性以及應用場景，幫助你得出心中「雲原生」的定義。
雲原生的概念 
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），是一種軟體工程手法，讓軟體産品的産出過程在一個短周期内完成，以保證軟體可以穩定、持續的保持在随時可以釋出的狀況。它的目标在于讓軟體的建置、測試與釋出變得更快以及更頻繁。這種方式可以減少軟體開發的成本與時間，減少風險。
持續傳遞的常見展現就是在不影響使用者使用服務的前提下，頻繁把新功能釋出給使用者使用。
要做到這點非常非常難，一般的要求是做到不誤時開發、不停機更新，這就要求開發版本和穩定版本并存，需要很多流程和工具支撐。
有時候，持續傳遞也與持續部署混淆。持續部署意味着所有的變更都會被自動部署到生産環境中。持續傳遞意味着所有的變更都可以被部署到生産環境中，但是出于業務考慮，可以選擇不部署。
如果要實施持續部署，必須先實施持續傳遞。
雲原生和本地部署的差別 SFKP • 計算機百科丨雲原生才是「吞噬世界」的那條大魚...
了解了雲原生的概念，我們再來看看雲原生和本地部署的差別。
真正的雲化不僅僅是基礎設施和平台的變化，應用也需要做出改變，在架構設計、開發方式、部署維護等各個階段和方面都基于雲的特點，重新設計，進而建設全新的雲化的應用，即雲原生應用。
這裡，我們引用阿裡巴巴進階技術專家醬油（花名）發表的一篇文章中的分析：
- 本地部署的傳統應用往往采用 C/C++、企業級 Java 編寫，而雲原生應用則需要用以網絡為中心的 Go、Node.js 等新興語言編寫。
- 本地部署的傳統應用可能需要停機更新，而雲原生應用應該始終是最新的，需要支援頻繁變更，持續傳遞，藍綠部署。
- 本地部署的傳統應用無法動态擴充，往往需要備援資源以抵抗流量高峰，而雲原生應用利用雲的彈性自動伸縮，通過共享降本增效。
- 本地部署的傳統應用對網絡資源，比如 IP、端口等有依賴，甚至是寫死，而雲原生應用對網絡和存儲都沒有這種限制。
- 本地部署的傳統應用通常人肉部署手工運維，而雲原生應用這一切都是自動化的。
- 本地部署的傳統應用通常依賴系統環境，而雲原生應用不會硬連接配接到任何系統環境，而是依賴抽象的基礎架構，進而獲得良好移植性。
- 本地部署的傳統應用有些是單體（巨石）應用，或者強依賴，而基于微服務架構的雲原生應用，縱向劃分服務，子產品化更合理。
可見，要轉向雲原生應用需要以新的雲原生方法開展工作，也就是我們在概念中提到的：微服務、容器、DevOps 和持續傳遞等。
「吞噬世界」的雲原生 SFKP • 計算機百科丨雲原生才是「吞噬世界」的那條大魚...
這個圖大家一定熟悉又陌生。
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：《“雲原生”才是那條最大的魚》