硬核科普：到底啥是云原生？

本文主要根據課程 什么是云原生？_嗶哩嗶哩_bilibili 總結而來，其他參考文章如下：

• 《云原生人才計劃之Kubernetes 技術圖譜》發布！ - 知乎 (zhihu.com)
• kubernetes-阿里云與CNCF聯合推出的云原生技術公開課_嗶哩嗶哩_bilibili
• 什么是云原生？這回終于有人講明白了 - 知乎 (zhihu.com)

伴隨云計算的的大火大熱，云原生(CloudNative)的概念應運而生，但是搜集網路上的各種相關資料，對到底什么是云原生大都描述的云里霧里，究其原因，是因為云原生一直在發展變化當中，并沒有確切的定義，解釋權不歸某個人或組織所有，

接下來我將從網上搜集到的各種資料以及實習作業中我自己的理解，為大家解釋一下我眼中的云原生，

預備知識——云的一些基本概念

在介紹云原生之前，我們首先需要了解云相關的專業術語

1. IaaS、PaaS、SaaS

• 基礎設施即服務（laaS： Infrastructure as a Service）

  指把IT基礎設施(包括服務器、存盤和網路)作為一種服務通過網路對外提供，并根據用戶對資源的實際使用量或占用量進行計費的一種服務模式

• 平臺即服務（PaaS：Platform as a Service）

  把服務器平臺作為一種服務提供的商業模式，通過網路進行程式提供的服務

  所謂PaaS實際上是指將軟體研發的平臺作為一種服務，以SaaS的模式提交給用戶，因此，PaaS也是SaaS模式的一種應用，但是，PaaS的出現可以加快SaaS的發展，尤其是加快SaaS應用的開發速度，在2007年國內外SaaS廠商先后推出自己的PaaS平臺

• 軟體即服務（SaaS：Software as a Service）

  通過網路提供軟體服務，SaaS平臺供應商將應用軟體統一部署在自己的服務器上，客戶可以根據作業實際需求，通過互聯網向廠商定購所需的應用軟體服務，按定購的服務多少和時間長短向廠商支付費用，并通過互聯網獲得Saas平臺供應商提供的服務

2. 公有云、私有云、混合云

云計算平臺也稱為云平臺，是指基于硬體資源和軟體資源的服務，提供計算、網路和存盤能力，用于部署云計算資源，云平臺通常有三種公共云、私有云和混合云，

推薦閱讀：漫畫：什么是公有云、私有云和混合云？_程式人生的博客-CSDN博客

一. 什么是云原生

云原生CloudNative的概念最早在2013年由 Pivotal公司的 Matt Stine提出；2015年，云原生剛推廣時，Matt Stine 在《遷移到云原生架構》一書中定義了符合云原生架構的幾個特征：12因素、微服務、自敏捷架構、基于API協作、扛脆弱性；與此同時，云原生計算基金會（CNCF）成立，其最初把云原生定義為包括：容器化封裝+自動化管理+面向微服務；到了2017年，Matt Stine在接受InfoQ采訪時又改了口風，將云原生架構歸納為模塊化、可觀察、可部署、可測驗、可替換、可處理6特質；

而Pivotal最新官網對云原生概括為4個要點：DevOps+持續交付+微服務+容器，到了2018年，CNCF又更新了云原生的定義，把服務網格(Service Mesh)和宣告式API給加了進來，其在關于云原生定義v1.0版本中這樣描述云原生技術體系：

• 云原生技術有利于各組織在公有云、私有云、混合云等新型動態環境中，構建和運行可彈性拓展的應用
• 云原生代表技術包括容器、服務網格、微服務、不可變基礎設施和宣告式API
  • 這些技術能夠構建容錯性更好、易于管理和便于觀察的松耦合系統
  • 結合可靠的自動化手段、云原生技術使工程師能夠輕松地對系統做出頻繁和可預測的重大變更

當今，我們可以將云原生理解為構建和運行應用程式的方法，是一套技術體系和方法論，主要包含以下幾中代表技術/方法論：DevOps、容器及容器編排、宣告式API、微服務及微服務治理、服務網格、不可變基礎設施

為了更加細致的理解，我們將其拆分為兩部分：云Cloud和原生Native，原生指的是用任意編程語言開發的應用程式，稱為原生應用，云指的是開發好的應用后我們部署到云上，使應用在云上高效運行，充分利用和發揮云平臺的彈性+分布式優勢，總結起來，云原生就是原生應用上云到程序以及云上的一系列解決方案，再結合相關技術堆疊進行理解：

符合云原生架構的應用程式應該是：采用開源堆疊（K8S+Docker）進行容器化，基于微服務架構提高靈活性和可維護性，借助敏捷方法、DevOps支持持續迭代和運維自動化，利用云平臺設施實作彈性伸縮、動態調度、優化資源利用率，

二. 云原生誕生背景

上述我們對云原生的概念有了基本了解，接下來我們來談談云原生的誕生由來，任何新潮技術/方法論的提出都有實際需求的驅動，云原生的提出正是為了適應當今火熱的復雜應用體系下的分布式架構，

從上世紀80年代至今，軟體和資訊系統領域相關的技術都進行了各自不同形式的迭代，也附有各自的里程碑式的代表技術，其中主要體現在開發流程、應用架構、打包部署、基礎設施四個方面，如下圖所示，其中：

• 開發流程 從瀑布模型、敏捷模型再到如今的火熱的DevOps、GitOps等模型
• 軟體架構 從單體架構、分層架構、分布式架構再到如今的微服務架構
• 打包部署 技術從裸服務器、虛擬機再到今天主流的容器化技術
• 基礎設施 從資料中心、資料托管再到今天的云計算

可以看到：DevOps、微服務、容器化、云計算是當今的主流模型，

隨著業務規模的擴張，從單體架構走到分布式架構，以縱向或者橫向切分的方式將大的應用拆分為多個小應用幾乎是提升系統容量，加強系統可用性的必然選擇，分布式架構方便我們開發與實作、將出現故障的影響范圍縮小、將開發系統的拓展性大大增強，但是分布式帶來這些優點的同時也包含許多很多問題，例如發布頻率變高、部署變復雜、系統架構設計難度大大增強、并且由于網路通信的引入，回應時間也是重要因素，此外，對于運維的難度也是成倍放大，

為了解決以上問題，提出了一系列解決方案：

• 服務治理（依賴關系、呼叫鏈）
• 架構管理（版本管理、生命周期管理、[編排、聚合、調度]）
• DevOps
• 自動化運維
• 資源調度監控
• 整體架構監控
• 流量治理（負載均衡、路由、熔斷…）

簡單總結起來，運行分布式系統的典型需求主要有以下四個方面：

1. 生命周期管理
2. 網路管理
3. 狀態存盤管理
4. 分布式系統內外應用系結與集成管理

下圖大概展示了以上每個需求分別涉及到的一些技術問題：

能夠滿足以上需求方案曾經的主流系統是ESB(企業服務總線，Enterprise Service Bus)

ESB說白了就是一個中間件，比如面向訊息的中間件以及一些輕量級的集成框架，支持利用面向服務的架構支持異構環境中的服務、訊息，以及基于事件的互動，并且具有適當的服務級別和可管理性，它提供了良好的功能集，但是單體架構以及業務邏輯和平臺之間緊密的技術耦合會導致技術和組織中心化，這是與分布式系統背道而馳的，從上述四個需求方面分析，ESB系統對于分布式支持的局限性如下：

• 生命周期：ESB通常只支持一個語言運行，這限定了軟體打包、可用庫、打補丁頻率等諸多方面
• 網路：只支持一個語言及其相關技術，且網路問題和語意深深嵌套與業務中，這時候后續的架構升級等需要對代碼做出極大的變更
• 狀態：與狀態互動的庫和介面沒有完全抽象出來，也沒有與服務運行時完全解耦
• 系結：必須使用根據訊息交換模式構造代碼和設計流程，與分布式所需的多協議、多資料格式、多訊息交換模式來連接其他系統相違和，導致系統拓展及其受限

針對ESB系統的不足，當今云計算時代提出：基于容器化、容器編排、DevOps、微服務及典型的治理系統服務網格等技術的云原生解決方案

以上就是云原生的誕生背景，說白了就是隨著發展實際需求而驅動所得，

三. 云原生系列技術/方法論

云原生理解為構建和運行應用程式的方法，是一套技術體系和方法論，主要包含以下幾中代表技術/方法論：DevOps、容器及容器編排、微服務及微服務治理、服務網格、不可變基礎設施

1. DevOps

DevOps 是一系列做法和工具，可以使 IT 和軟體開發團隊之間的流程實作自動化，其中，隨著敏捷軟體開發日趨流行，持續集成 (CI) 和持續交付 (CD) 已經成為該領域一個理想的解決方案，在 CI/CD 作業流中，每次集成都通過自動化構建來驗證，包括編碼、發布和測驗，從而幫助開發者提前發現集成錯誤，團隊也可以快速、安全、可靠地將內部軟體交付到生產環境，

• 持續集成CI：代碼撰寫完成后，后續的構建、測驗、合并到代碼倉庫這一系列操作持續自動化完成
• 持續交付CD：自動化的將代碼打包成鏡像然后發布到鏡像倉庫中
• 持續部署：自動的倉庫中的鏡像部署到k8s平臺上，然后就能監控代碼的運行期間的各種指標程序以及日志資訊

總結一句話就是：DevOps就是只要代碼發生變更，通過一系列的自動化流程，就能在線上的云平臺看到代碼變更后的效果，減少了開發人員和運維人員之間大量作業，全部交給自動化鏈路來完成

也就是就是自動化的進行代碼撰寫、構建、分析、測驗、合并代碼庫、構建打包成鏡像、部署、線上運維分析這一倍訓

2. 容器&容器編排

容器技術由來以久，只不過2013年前后，dotCloud這家公司在Docker專案中發明了“容器鏡像”技術之后，創造性的解決了應用打包的難題，將容器技識訓發出新的生命力，并以應用容器的面目風靡于世，

所謂應用容器，與傳統容器比較起來，可以將此前的容器技術稱為系統容器，使用方式類似于一個輕量的虛擬機，其上運行了很多應用，而應用容器中通常只運行某一個特定應用的行程及其子行程，不會再運行其他行程，

基于Dokcer引進，應用容器的出現，如果某個容器中只運行單個應用的話，考慮到應用開發的分布式甚至是微服務的模型下，我們只有將一個系統相關的所有應用均以容器化方式運行并組織編排好其中的關系、運行邏輯以及通信機制，才能夠確保整個系統流暢平滑的運行，

因此單個容器的管理系統難以產生價值，容器編排才是根本，其中最為著名的容器編排系統就是kubernetes，也就是常說的k8s，現代的容器技術與k8s將打包、分發和應用部署演化成了與編程語言無關的格式

k8s有以下幾個關鍵特性：

• 遵循宣告式API編程范式，將宣告式API引入到了云計算管理平臺來，它結合控制器模式支撐起整個k8s系統運行的基本邏輯
• “以應用為中心”的現代應用基礎設施，該設施納管各類基礎支撐類服務，并經由宣告式api向上層應用暴露這些基礎設施能力，單機作業系統本身存在的主要目的也是創建運行調度編排應用程式，只不過k8s是把應用程式的創建啟動運行調度編排運行在一個更大的云計算環境中去
• platform for platform型別的系統，也就是為構建其他平臺而提供的平臺系統，所以大多數情況下，為了更加完善的運行應用，一般不直接使用k8s的原生api介面來構建運行應用，而是在k8s之上添加補充完善出其他平臺系統后再去運行應用程式，其中最為著名的兩個系統就是服務網格Service Mash和無服務計算Serverless

3. 微服務&微服務治理

微服務是一種流行的架構風格，用于構建彈性化、高度可拓展、可獨立部署且能夠快速迭代的應用程式，本質就是將大服務拆分成小服務，每個小服務都是自包含的，應該在有界背景關系中實作單個業務功能，

動態化是云原生應用的天然屬性，而微服務架構是支撐該目標的關鍵所在，服務治理工具又是支撐微服務運行的根本所在，為了便于用戶開發創建維護運行微服務應用，通常需要依賴對應的服務治理框架，著名的有Dubbo、Spring Cloud Alibaba、以及未來的服務治理框架ServiceMesh等

4. 服務網格

在分布式/微服務架構系統當中，服務間的通信是至關重要的，因此我們需要保證通信通道無故障、安全、高可用足夠健壯，這些需求恰恰是服務網格作為基礎結構組件出現的原因，它的實作方式就是通過在每一個應用實體的外層附加一個服務代理來確保受控的服務到服務的通信，這個代理稱之為sidecar，主要負責各個業務單元實體之間的通信相關的功能（例如服務發現、負載均衡、斷路、超時、重置等等），服務網格并不是一蹴而就的，而是從最早期的ESB到Dubbo、SpringCloud一路發展基礎之上所衍生出來的新一代的通信模型

如果說前一個時代，例如Dubbo+SpringCloud這種純粹的微服務框架當中，開發系統中的每一個業務邏輯幾乎都需要與同系統中其他模塊進行通信，因此為了實作各種各樣的高級網路功能，它必須內嵌與網路相關的例如服務發現、負載均衡、熔斷限流、服務路由等網路功能，這些功能早期是通過sdk的方式進行加載，如果考慮到分布式系統中的每個模塊可能是由不同編程語言所開發的話，那么這個sdk本身就需要支持多種不同語言來呼叫介面，這就使得存在幾個問題：

1. 可用sdk語言版本有限
2. sdk的更新會導致業務代碼的更新

于是發展到服務網格時期，我們的每一個微服務應用本身就被切分成兩部分，如上圖所示，每一個業務邏輯只需要對特定的一個輕量級sdk發一個請求呼叫即可，對應的網路功能則由專門開發獨立運行只需要通過標準協議進行通信的而無需與編程語言強系結強耦合的sidecar完成，這兩者聯合起來形成獨立應用，這里的sidecar專門處理服務間的通信，與業務邏輯無關，這樣業務邏輯專注于本身即可，無需感知sdk，這就解決了每一個業務邏輯的開發人員無需再關心有哪些sdk可以呼叫，只需要實作自己服務該有的業務邏輯并且能夠與對應的sidecar的標準介面進行關聯即刻，

因而，服務網格以sidecar的形式，將服務治理從業務邏輯中剝離，并拆解為獨立行程，實作異構系統的統一治理和網路安全，

服務網格最為典型的代表產品為Istio、Open Service Mesh 以及 阿里云的ASM

5. 不可變基礎設施

不可變基礎設施早在2013年由Chad Fowler在一篇博客中提出，提出該構想的原因在于：過去非容器化時代，我們通常將應用部署在裸服務器/虛擬機上，它們底層支持配置的多次變更，因而會導致一旦災難發生時，重新構建出一模一樣的配置環境非常困難，除非我們確保每一個運維/開發人員實作變更的時候能夠按照確切的流程提交工單并按照工單本身的要求一字不差的來執行變更；此外，還會存在導致狀態不一致的風險，

因此為了改變這種現狀，最好的方式就是確保底層環境不變，至少是運行應用程式的周邊依賴到的系統環境不變，很顯然，容器化時代能夠很好解決這個問題，因為現代應用容器當中，每一個容器運行單個應用，如果將這個應用的資料和狀態保存在容器外圍獨立于容器生命周期的存盤系統上，一旦這個容器啟動后自己本地不存盤除臨時資料外的其他任何資料，就確保了這個容器接近于只讀狀態，一旦容器本身出現故障或者其他原因需要重建時，只需要基于同一個鏡像啟動一個新的容器關聯到原存盤系統上就能恢復出一摸一樣的環境，

因而，不可變基礎設施核心思想在于任何基礎設施的實體一旦創建出來就變味只讀狀態，若需要修改和升級，都不能通過配置該實體實作，而只能通過替換為新實體來實作，

這樣，在公有云、私有云、混合云等云計算時代，如果要讓系統運行在IaaS環境之上的話，考慮到如果資料及不存在于容器中也不存在于容器運行所在主機上，而是存在于機器外圍一個統一的存盤系統之上，這個存盤系統的宣告周期與該主機生命周期無關，這樣就算主機故障導致容器故障，我們重建主機容器都可以完全復現未出故障前的狀態，也就避免了導致狀態不一致的風險，

此外，如果我們遵循不可變基礎設施的話，現在還有一種IaC技術，即基礎設施即代碼，通過借助于呼叫對應的IaaS云的api等等來確保底層系統環境當中的不僅是容器包括容器網路等一切環境都可重構可復現機制，那么整體的系統運維將變得更加簡單和易于實作，

四. 云原生系統功能特征

據上文所述，動態化是云原生應用和云原生基礎設施的天然屬性，而微服務架構是支撐該目標的關鍵所在，因此云原生系統往往需要具備以下功能特征：

1?? 構建云原生系統時，應該有一個統一的API網關

每一個服務本身都通過 api 向外提供其功能，我們當然不希望客戶端獲取所需功能的時候需要獨立的與對應每一個微服務進行通信，所以各個微服務提供的 api 應該聚合成為復合api，也就是對外提供一個統一的訪問介面，那因而我們再去構建云原生系統的時候，還應該有一個關鍵性的組件叫做api 網關，

2?? 微服務治理

服務治理工具又是支撐微服務運行的根本所在，例如Istio、Open Service Mesh、Linkerd 等等都是微服治理尤其是服務網格時代的微服治理的工具

3?? Serverless平臺

Serverless 是一種由開發人員和企業共同推動的運動，他們意識到軟體正在吞噬世界，但如果您自己構建和維護所有軟體，您也會被吞噬，這一運動要求將構建應用程式中最瑣碎的部分抽象化，以便開發人員能夠真正將時間花在交付業務價值上，

這一運動的目的是讓開發人員能夠單槍匹馬地構建處理生產級流量的應用程式，他們不必管理擴展他們的基礎設施，他們不必配置服務器，也不必為未使用的資源付費，他們可以專注于開發，

最著名的的Serverless平臺就是上文提到的Knative

4?? 云原生編排平臺

云原生的編排平臺去調度運行應用程式，并對其做健康監測、監控、彈性擴縮容等，最著名的就是k8s

5?? 靈活部署

微服務治理通常還能夠支持像對應服務靈活部署功能，例如灰度發布、藍綠發布，金絲雀部署、A/B測驗、影子Shadow部署等等相關功能

五. 云原生架構模型

為了能夠正常的運行云原生應用程式，云原生的架構模型至少需要組織以下五個層級：

1?? 基礎設施層

第一層為基礎設施層，即infrastructure，它主要由主機、存盤和網路來組成，事實上它也可以是基于對應的私有云、公有云或者混合云來進行構建，那我們這個時候可以使用云端的主機，也就是所謂的計算，還有網路用通信以及存盤技術，

2?? 供應層

第二層為供應層/預配層，即provisioning，這個層次主要是用來完成主機創建、作業系統，安裝、存盤空間分配、網路創建等底層基礎架構或基礎設施所提供的資源，用于配置給上層應用程式所使用的一個關鍵的中間供給層，所以這個層呢我們稱之為叫做主機管理層，那這他們通常要用到的是包括DevOps工具鏈或者是其他預配工具的相關層級，

3?? 運行時層

第三層為運行時層，主要包含了容器運行時環境相關聯的幾個關鍵介面，包括像容器運行時介面CRI、容器網路介面CNI、容器存盤介面CSI，那這樣就能夠用于確保在該運行時環境之上，以容器化的方式運行一個應用程式的時候它能夠呼叫底層所提供容器時運行環境，包括我們的計算資源、網路資源和存盤資源等非常重要的標準介面，所以這個時候我們需要一個運行時層來解決諸如此類的問題，

4?? 容器編排及管理層

第四層為容器編排與管理層，我們前面強調過單個容器沒有價值，只有將多個容器聯合起來統一進行編排，才能發揮其價值，于是在容器運行時層環境之上，我們需要提供一個容器編排和管理系統，其中最著名就是kubernetes，但kubernetes是一個platform for platform的平臺，它在設計上不是直接面向去組織維護運行我們的現代應用/云原生應用的，而是要在其基礎上再去添加組織出來其他的平臺來運行應用，比如我們要運行微服務應用的話，我們還應該在我們的kubernestes之上去附加一個istio這樣的服務網格系統，然后由該網格系統借助于底層的kubernetes去維護運行我們對應的微服務，主要是微服務之間安全可靠的通信等等，此外，如果我們期望運行的是一個serverless型別的應用的話，那么我們還需要在kubernetes基礎上去附加一個serverless的運行時環境，這其中比較著名的開源產品有knative等等，

5?? 云原生應用程式定義與開發層

第五層為云原生應用程式的定義與開發層，在前四層的技術之上，我們便可對云原生應用便捷的進行開發與定義，

因此架構圖如下所示：

首先底層基礎設施，很可能是私有云、公有云或者是混合云，在云環境的基礎之上，就是一個容器編排平臺，也就是k8s，然后如果需要用到無服務計算的話，那我們還需要額外提供一個Faas的平臺，就是serverless的運行時，接著在該平臺之上，我們就可以提供類似于叫做容器及服務的介面，叫Caas介面，再接著向上，我們應該去提部署和提供一個微服務的運行平臺，就是服務網格系統Istio去運行各種各樣的以微服務形式存在的業務業務單元，接著這些業務單元甚至包括我們底層平臺自身都應該納入到監控系統中來，沒有監控，那幾乎就沒辦法管理，所以我們的立體化監控系統由日志、指標監控以及對應的分布式鏈路跟蹤系統等所組成，這是現代云系統幾乎所必然要具備的幾個監控組件，還有就是api網關，用于實作api 統一的流量管理，尤其是接入外部系統式的流量管理，包括api治理、流量控制等相關功能，此外，對于這么多的微服務應用，必要時我們還應該提供一個統一的認證和訪問管理介面Iaam組件，再加上一層，那其實就是我們的開發人員所應該擁有和使用的開發環境，

進一步細化，架構圖如下所示：

在公有云、私有云之上，應該有kubernetes，然后在此基礎之上，我們應該提供一個微服務的技術中臺，通常它是一個Service Mesh，在這個Service Mesh的基礎上，我們應該提供開發框架、各種各樣的中間件系統、立體化監控系統以及微服務治理工具，以確保實作服務發現、服務監控、服務間通信以及各種各樣的網路功能，此外，為了確保高效的去交付每一個微服務應用，那我們還應該遵循DevOps，甚至是GItOps這樣的模型來實作應用的CI/CD等相關功能，當然接入外部的訪問流量時，我們應該有一個服務的統一接入層，就是API網關，

說到這兒相信您呢對現代的這種云原生架構體系有了基本的認識，如果要簡單總結一下的話，那么我們云原生的技術范疇大體可以分為以下六個方面：

1. 云應用與定義與開發流程
2. 云原生底層技術
3. 云應用編排與管理
4. 云原生工具集
5. 監控與可觀測性
6. Serverless

六. 如何構建云原生系統

有鑒于此，那我們究竟該如何構建云原生呢？只要遵循前面的范式，把對應系統組合起來，其實我們基本上就能夠構建出一個云原生的基礎平臺了

在這個云設計的平臺當中，它的每一層各有各的作用：

• 微服務架構就是解決單體架構導致的應用復雜性問題的，但事實上我們把它拆分成微服務以后，這個復雜性就留給了我們外部的治理系統，而并不是而并不是真正的減少了這個服務的服務的服務的服務的復雜性，
• 服務治理框架和立體化監控方案能夠解決服務間協同及呼叫例外的相關問題，
• 容器技術用于解決應用構建、分發和部署等相關的問題，
• k8s 用于解決服務編排、調度和彈性化等需求，
• Service Mesh 用于解決微服務框架的侵入式、流量治理等問題，將Service Mesh 運行于k8s 之上，可以提供更好的容器底層環境支持，
• 借助于 IaaS云和容器技術，可以解決不可變基礎設施相關的問題，