雲原生是什麼

雲原生概念

雲原生從字面意思上來看可以分成雲和原生兩個部分。

雲是和本地相對的，傳統的應用必須跑在本地伺服器上，現在流行的應用都跑在雲端，雲包含了IaaS,、PaaS和SaaS。

原生就是土生土長的意思，我們在開始設計應用的時候就考慮到應用将來是運作雲環境裡面的，要充分利用雲資源的優點，比如️雲服務的彈性和分布式優勢。

雲原生不是一個具體的産品，也絕非是把原先在傳統IT架構中的東西搬上雲，而是基于雲的一種全新IT理念，必須是與之相關的包括應用的架構、應用的開發方式、應用的部署和維護方式都要做出改變，這樣才能真正發揮出雲的價值，包括彈性、動态排程、自動伸縮等，享受新IT技術帶來的紅利。

雲原生的四要素

CNCF認為雲原生系統應該具備三大特征：

容器化封裝：以容器為基礎，提高整體開發水準，形成代碼群組件重用，簡化雲原生應用程式的維護。在容器中運作應用程式和程序，并作為應用程式部署的獨立單元，實作高水準資源隔離。

自動化管理：統一排程和管理中心，從根本上提高系統和資源使用率，同時降低運維成本。

面向微服務：通過松耦合方式，提升應用程式的整體靈活性和可維護性。

要充分了解雲原生，必須對其每一個闆塊進行了解。而目前，業界對雲原生的看法是非常一緻的，那就是四要素：容器、微服務、DevOps、持續傳遞。

一個一個展開。

容器，雲原生的基石

容器不是新概念，1979年就出現了。

很多人會将Docker與容器劃等号，其實不然，Docker隻是容器理念最普及的一種應用技術。容器的英文單詞是Container，有集裝箱的含義，而借用集裝箱技術會很好了解容器的優勢。集裝箱的特點，在于标準化，這樣可以大量堆疊，裝卸也很友善。容器也是這樣。

與容器做比較的是虛拟化技術。早期，大家認為硬體抽象層基于Hypervisor的虛拟化方式能夠最大程度實作系統管理的靈活性，因為各種不同作業系統的虛拟機都能通過Hypervisor生成、運作、銷毀。但是，随着時間推移發現，Hypervisor沒有想象的那麼好，因為它的原理是每個虛拟機都要安裝一個完整的作業系統和大量的應用，而實際生産環境大家更關心的是自己部署的應用。顯然，如果每次都部署一個完整的作業系統和大量關聯的開發環境，開發效率、管理效率都會很低下。

于是有了容器這種方式，簡單說，它隻把應用代碼運作所需相關的環境打包、封裝進了一個系統，就像集裝箱一樣，直接運走就行，不用關心船是什麼樣，到哪都可以跑起來。

容器技術有四大特點：

極其輕量：隻打包了必要的Bin/Lib；

秒級部署：根據鏡像的不同，容器的部署大概在毫秒與秒之間（比虛拟機強很多）；

易于移植：一次建構，随處部署；

彈性伸縮：Kubernetes、Swam、Mesos這類開源、友善、好使的容器管理平台有着非常強大的彈性管理能力。

換句話說，使用容器，使用者可以将微服務及其所需的各種配置、依賴關系和環境變量很友善的移動到全新的伺服器節點上，而無需重新配置環境。

在容器領域，Docker是最受歡迎的容器格式标準。同時，與Docker配合使用的Kubernetes則成為了容器編排和管理工具中的事實标準。

微服務，改變産品開發方式

微服務是什麼？重點在“微”。它的核心是将單個應用程式作為一組小型服務來開發。原來一個産品的開發可能是拆成幾個大的子產品，然後由幾個團隊來做，然後再合，微服務的理念是把一個産品拆的更細，可能一個人、幾個人負責一個服務的開發，每個服務之間都是獨立的。

每個服務都在自己的程序中運作，并使用輕量級機制（通常是基于HTTP的API）進行通信。這些服務是圍繞業務功能建構，可以通過全自動部署機制獨立部署，不需要集中管理，可以用不同的程式設計語言編寫，并使用不同的資料存儲技術。

是以，微服務核心就是服務粒度要小，每個服務是針對一個單一職責的業務能力的封裝，專注做好一件事情。但是又不能太小，否則易發生“服務爆炸”。通常在工程實踐中，如果一個功能被兩個或兩個以上的服務調用，就可以被封裝為服務。

是以，微服務的優點很明顯，小而美、松耦合、靈活、易內建，但是挑戰也很明顯，最大的問題在于服務如何切分。其實，早在1968年康威就提出了——康威定律，系統的服務劃分應該是根據組織架構的功能來劃分。這一點用在微服務領域也非常合适。

這樣按照組織架構劃分的優勢在于：

1.内聚更強，所有遵循同一種業務準則的人内聚在一起，就容易解決問題。

2.服務解耦，變更容易，更加靈活。

DevOps，内部協作更緊密

DevOps，如果從字面上來了解，是Dev（開發）+Ops（運維）。

實際上，可以把DevOps看作開發（軟體工程）、技術營運和品質保障（QA）三者的交集。DevOps是一組過程、方法與系統的統稱，用于促進開發（應用程式/軟體工程）、技術營運和品質保障（QA）部門之間的溝通、協作與整合。

為什麼要整合？因為能幫助企業提升效率。

衆所周知，傳統的軟體組織将開發、IT營運和品質保障設為各自分離的部門。開發與營運之間存在着資訊“鴻溝”──例如營運人員要求更好的可靠性和安全性，開發人員則希望基礎設施響應更快，而業務使用者的需求則是更快地将更多的特性釋出給最終使用者使用。

每個部門需求都不同，怎麼調和？DevOps的價值就展現在這。DevOps的引入能對産品傳遞、測試、功能開發和維護起到意義深遠的影響。其最大的價值在于，透過自動化“軟體傳遞”和“架構變更”的流程，能使得建構、測試、釋出軟體更加地快捷、頻繁和可靠，這是每一個企業都期望的。

是以，更深層次的了解，DevOps是一種重視“軟體開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動。

持續傳遞，雲原生終極目标

如何了解持續傳遞？聽着比容器、微服務、DevOps更抽象。簡單來說，它是一種狀态，一種能力，就像生産線能持續傳遞産品一樣。

具體而言，持續傳遞是一種軟體工程手法，它能讓軟體産品的産出過程在一個短周期内完成，保證軟體可以穩定、持續的保持在随時可以釋出的狀況。它的目标在于讓軟體的建構、測試與釋出變得更快以及更頻繁。這種方式可以減少軟體開發的成本與時間，減少風險。

為什麼要有持續傳遞？這是和曾經的軟體開發方式相比的，過去的軟體開發周期以月、季度、年來計算，今天呢？一個應用晚上線一個小時造成的損失都可能是巨大的，是以要小步快跑、快速疊代，這就是持續傳遞的價值所在，不斷的傳遞，不斷的修正。

很顯然，如果把雲原生的四要素串聯起來，持續傳遞才是最終目标。但要實作持續傳遞，容器、微服務、DevOps缺一不可。

總結一下，雲時代必須以全新的理念來看待軟體架構和基礎設施，隻有從這個角度了解雲原生才能得到正确的答案。未來必然是屬于雲原生的，是以，企業變革的絕不僅僅是工具，而是從思想到方法，再到工具的一整套理念。隻有這樣，才能更好迎接雲時代的到來。