萬字長文揭穿你，根本就不懂雲原生！

近年來，隨着雲計算概念和技術的普及，雲原生一詞也越來越熱門，無論是應用還是安全，凡是和雲相關的，都要在雲後面加上原生二字，好像不提雲原生，在技術上就落後了一大截。

一、雲原生產生背景

隨着雲計算技術的發展，企業上雲已成爲趨勢，越來越多的企業都已將應用部署到了雲上。但是應用上雲並不意味着就能充分利用雲平臺的優勢。目前，大部分雲化的應用，都是基於傳統的軟件架構來搭建的，然後再移植到雲上去運行，和雲平臺的整合度非常低，主要表現在以下幾個方面：

1. 操作系統依賴強

傳統應用程序和底層操作系統、硬件、存儲和後備服務之間存在緊密的依賴關係，這些依賴關係使得應用程序在跨越雲基礎設施進行遷移和擴展時非常複雜且有風險。

2. 系統緊耦合

傳統的企業應用多采用單體架構，將許多不同的功能模塊捆綁在一個部署包中，導致功能模塊之間產生不必要的依賴，並導致開發和部署過程中喪失敏捷性，無法獨立的部署、發佈更新、重啓。

3. 手動化擴展

通過手工管理基礎設施，包括手工編寫管理服務器、網絡和存儲的配置腳本。在大規模複雜的操作中，操作人員在診斷問題時會很慢，而且無法大規模地實施。手工製作的自動化腳本還有可能將人爲錯誤硬編碼到基礎設施中。

4. 恢復緩慢

基於虛擬機的基礎設施相對於基於微服務的應用程序來說，是緩慢而低效的。因爲單個虛擬機啓動 / 關閉的速度很慢，並且在部署應用程序代碼之前就會帶來巨大的開銷。

5. 瀑布開發

傳統應用的開發模式，IT 團隊定期發佈軟件，通常間隔幾周或幾個月。儘管發佈的許多組件已經提前準備好了，並且沒有依賴關係，也必須等待版本中的其他組件。客戶想要的功能被延遲，企業失去贏得客戶和增加收入的機會。

總體來說，提供方便的基礎設施，只是對雲計算最初級的利用（提升利用率，按需使用，不夠了隨時擴容），無法充分發揮雲計算的優勢，要想充分發揮雲計算的優勢（彈性、高可用性、易擴展性），就必須進行真正的雲化，不僅僅是基礎設施和平臺的變化，應用也需要做出改變，這就需要擯棄傳統的方法，在架構設計、開發方式、部署維護等各個階段和方面都基於雲的特點重新設計，從而建設全新的雲化的應用，也就是雲原生的應用。

二、雲原生的定義

關於什麼是雲原生，不同的人定義不同，目前比較權威的定義主要來自 Pivotal 公司和雲原生計算基金會（Cloud Native Computing Foundation，簡稱 CNCF）。

1. Pivotal 的定義

Pivotal 公司是雲原生應用的提出者，並推出了 Cloud Foundry 和 Spring 系列開發框架。早在 2015 年，Pivotal 公司的 Matt Stine 寫了一本名爲《遷移到雲原生應用架構》的小冊子，其中探討了雲原生應用架構的幾個主要特徵：符合 12 因素的應用、面向微服務架構、自服務敏捷架構、基於 API 的協作以及抗脆弱性。

在 2017 年 10 月，接受採訪時，Matt Stine 對雲原生的定義做了小幅調整，將雲原生架構定義爲具有以下六個特質：模塊化（Modularity）、可觀測性（Observability）、可部署性（Deployability）、可測試性（Testability）、可處理性（Disposability）以及可替換性（Replaceability）。而 Pivotal 官網對雲原生概括爲 4 個要點：DevOps、持續交付、微服務以及容器化。

圖 1：Pivotal 雲原生思想

Matt Stine 認爲雲原生是一個思想的集合，雲原生既包含技術（微服務，敏捷基礎設施），也包含管理（DevOps、持續交付、康威定律以及重組等），雲原生也可以說是一系列雲技術、企業管理方法的集合。

2. CNCF 的定義

CNCF 是在 2015 年由 Google 聯合 Linux 基金會成立的，它是一個非盈利組織，主要宗旨是統一雲計算接口和相關標準，通過技術優勢和用戶價值創造一套新的通用容器技術，推動雲計算和服務的發展。起初 CNCF 對雲原生（Cloud Native）的定義包含以下三個方面：

• 應用容器化

• 面向微服務架構

• 應用支持容器的編排調度

到了 2018 年，隨着雲原生生態的不斷壯大，所有主流雲計算供應商都加入了該基金會，且從雲原生的全景圖中可以看出雲原生正在蠶食原先非雲原生應用的部分。

CNCF 基金會中的會員以及容納的項目越來越多，該定義已經限制了雲原生生態的發展，CNCF 爲雲原生進行了重新定位，並於 2018 年 6 月 11 日明確了雲原生定義 1.0 版本：雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。

圖 2：雲原生代表技術

這些技術能夠構建容錯性好、易於管理和便於觀察的松耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更。

三、雲原生相關技術

依據 CNCF 發佈的雲原生 1.0 版本的定義，雲原生技術主要包括容器、微服務、服務網格、不可變基礎設施以及聲明式 API，下面就這幾類技術做個概述：

1. 容器技術

容器技術和雲原生好比一對螺旋體，容器技術催生了雲原生思潮，雲原生生態推動了容器技術發展。從 2013 年 Docker 技術誕生，到 2015 年 CNCF 這個雲原生領域重量級聯盟成立，這不是歷史的巧合而是歷史的必然。作爲雲原生關鍵技術之一的容器，從 2013 年誕生以來一直是行業關注的焦點之一。

2013 年之前，雲計算行業一直在爲雲原生的正確打開姿勢而操心。Platform as a Service（PaaS）看起來是個有前途的方向。2006 年 Fotango 公司發佈的 Zimi 服務，可以說是 PaaS 行業的鼻祖，具有按使用付費、免運維（Serverless）、API 化配置和服務等典型雲原生的特徵；2008 年 Google 推出 Google App Engine（GAE）；2011 年 Pivotal 發佈 Cloud Foundry。

這些早期的 PaaS 平臺在雲原生領域進行了非常有益的探索，推動了雲原生生態的健康發展，但是這些早期探索技術並沒有形成大的行業趨勢，而是侷限在一些的特定的領域。直到 Docker 開源，大家才如夢方醒，原來不是方向不對，而是應用分發和交付的手段不行。

Docker 真正核心的創新是容器鏡像（docker image），一種新型的應用打包、分發和運行機制。容器鏡像將應用運行環境，包括代碼、依賴庫、工具、資源文件和元信息等，打包成一種操作系統發行版無關的不可變更軟件包。

容器鏡像打包了整個容器運行依賴的環境，以避免依賴運行容器的服務器的操作系統，從而實現 “build once， run anywhere”。容器鏡像一旦構建完成，就變成 read only，成爲不可變基礎設施的一份子。

2. 微服務

微服務架構是相對於單體架構來說的，兩者分屬不同的架構風格。在微服務架構中，服務是一個單一的、可獨立部署的軟件組件，它實現了一些有用的功能，服務的 API 封裝了其內部實現，與單體架構不同，開發人員無法繞過服務的 API 直接訪問服務內部的方法和數據，因此，微服務架構強制實現了應用程序的模塊化。

微服務架構的最核心特性是服務之間的松耦合性。服務之間的交互採用 API 完成，這樣做就封裝了服務的實現細節，從而實現了在不影響客戶端的情況下，對實現方式做出修改。

微服務架構通過將大的系統按照業務服務的粒度進行拆分，每個服務可獨立開發、測試、驗證和部署，這樣分解後，帶來的好處有如下幾點：

• 使大型的複雜應用程序可以持續交付和持續部署

• 每個服務都相對較小並容易維護

• 服務可以獨立部署

• 服務可以獨立擴展

• 微服務架構可以實現團隊的自治

• 更容易實驗和採納新的技術

• 更好的容錯性

3. 服務網格

服務網格是用於處理服務間通信的專用基礎設施層，負責在微服務間進行可靠地請求傳遞。服務網格通常通過一組輕量級網絡代理來實現，這些代理與應用程序代碼一起部署，而不需要感知應用程序本身。

隨着規模和複雜性的增長，服務網格包含的實現的功能越來越多，它的需求包括服務發現、負載均衡、故障恢復、指標收集和監控以及通常更加複雜的運維需求，例如 A/B 測試、金絲雀發佈、限流、訪問控制和端到端認證等。其部署結構如下圖所示：

圖 3：服務網格部署圖

服務網格有如下幾個特點：

• 應用程序間通訊的中間層

• 輕量級網絡代理

• 應用程序無感知

• 解耦應用程序的重試 / 超時、監控、追蹤和服務發現

如果用一句話來解釋什麼是服務網格，可以將它比作是應用程序或者說微服務間的 TCP/IP，負責服務之間的網絡訪問、限流、熔斷和監控。對於編寫應用程序來說一般無須關心 TCP/IP 這一層（比如通過 HTTP 協議的 RESTful 應用），同樣使用服務網格也就無須關係服務之間的那些原來是通過應用程序或者其他框架實現的事情，比如 Spring Cloud、OSS，現在只要交給服務網格就可以了，從而極大地方便了微服務應用的開發。

4. 不可變基礎設施

一個工作負載（比如容器、虛擬機等）一旦部署以後就不會被修改。當需要更新，修復或修改某些內容的時候，只需要將新的、經過驗證的工作負載替換舊的即可。

不可變基礎設施的作用主要體現在系統的穩定性方面。傳統的應用程序一旦部署到用戶特定的服務器上以後，服務器系統是會不斷變化的，不是操作系統升級，就是安裝了新的應用，可能引起衝突，導致應用程序需要跟着用戶系統環境的改變而不斷升級，這中間就會不斷地出現新的問題。而不可變基礎設施就規避了所有的這些問題，因爲雲原生應用是部署在不可變的基礎設施上的，因此就不存在變化的問題。

5. 聲明式 API

聲明式 API 是一種比命令式 API 更高級的接口設計方式，簡單來說，命令式 API 提供給用戶怎麼做的能力，而聲明式 API 給用戶提供了做什麼的能力。

聲明式 API 是比命令式 API 更高級的一種接口，舉個例子，假如我們有一個炒菜機，如果炒菜機提供的接口是放油、放調料、放食材、大火、小火等操作，那就是命令式 API。

如果炒菜機提供的接口是來盤宮保雞丁、來盤魚香肉絲之類的，那就是聲明式 API 了。聲明式 API 比較典型的例子就是數據庫提供的 SQL 接口，只需要告訴數據庫你需要什麼數據即可，至於怎麼去獲取這些數據，數據庫自己會去按步驟操作。

四、雲原生的意義

傳統的軟件開發模式，在使用雲計算平臺時和使用物理機時沒有什麼大的區別，那麼就沒有將雲平臺的能力利用充分，在一定程度上導致了資源的浪費。雲原生就是用來解決這一類的問題，將雲計算平臺的優勢發揮到極致。

讓企業應用能夠利用雲平臺實現資源的按需分配和彈性伸縮，是雲原生應用重點關注的地方。它要求雲原生應用具備可用性和伸縮性，以及自動化部署和管理能力，可隨處運行，並且能夠通過持續集成、持續交付提升研發、測試與發佈的效率。雲原生應用並未完全顛覆傳統的應用，採用雲原生的設計模式可以優化和改進傳統應用模式，使應用更加適合在雲平臺上運行。

雲原生存在的意義是解放開發和運維，而不是讓開發和運維的工作變得更加複雜和繁重。雲原生還關注規模，分佈式系統應該具備將節點進行水平擴展的能力，能輕易地擴展到成千上萬的規模，並且這些節點具備多租戶和自愈能力。雲原生使得應用本身具備 “柔性”，即面對強大壓力的緩解能力以及壓力過後的恢復能力。

五、雲原生當前生態

作爲雲原生領域最具權威的組織，CNCF 在每年的年度報告中都會提及 CNCF Landscape 項目，該項目開始於 2016 年 11 月，旨在爲雲原生應用者提供一個資源地圖，幫助企業和開發人員快速瞭解雲原生體系的全貌。CNCF Landscape 項目在 Github 上已經獲得超過 7000 顆星，表明廣大開發者和使用者對該項目的關注和重視。該項目給出當前雲原生生態的全景圖（如下圖所示），通過該全景圖我們可以瞭解雲原生相關的各種類型的項目和產品：

圖 4：CNCF 生態全景圖

這張全景圖從雲原生的層次結構，以及不同的功能組成上，展現了雲原生體系的全貌，可以幫助用戶在不同組件層次去選擇恰當的軟件和工具進行支持。總體來看，雲原生生態分爲以下幾層：

1. Kubernetes 服務提供商

圖中最底層是 Kubernetes 認證的服務提供商，以及 Kubernetes 認證的培訓夥伴。

2. Provisioning

有了物理機或虛擬機後，在運行容器化服務之前，需要爲容器準備標準化的基礎環境，這就是 Provisioning 這一層的作用。在 Provisioning 這一層中，分爲以下幾個功能組成模塊：

• Automation & Configuration：用於自動化部署和配置容器運行平臺和環境，代表工具和廠商包括 Ansible、Chef、Puppet、VMware 以及 OpenStack。

• 容器鏡像庫：容器鏡像庫是整個 CNCF 雲原生中的核心部件之一，因爲基於容器的運行環境中，所有的應用都需要藉助容器鏡像庫來進行安裝和部署。容器鏡像庫又分爲公有和私有，公有的容器鏡像庫包括 docker 官方的 registry，AWS 的 Elastic Container Registry，Google 的 Container Registry 等。在私有鏡像庫中，VMware 中國團隊主導的 Harbor 得到了廣泛的應用，大量的容器平臺目前都基於 Harbor 構建其鏡像倉庫。

• Security & Compliance：Notary 和 TUF（The Upgrade Framework）是這個領域兩個主要的項目，其中 TUF 是一個開源的安全標準，Notary 是其中一個實現。Notary 軟件除了確保軟件的出處外，它還能保證在未經容器鏡像提供者批准的情況下，不會在鏡像供應鏈的任何地方修改鏡像內的內容，從而確保從開發到運營的過程中，安全都被無縫統一地嵌入到整個工作流中。

• Key Management：主要用於在整個容器平臺中進行祕鑰管理。

3. Runtime

Runtime 這一層可以理解爲容器的整個運行環境，是雲原生中最核心的部分，它包括了計算、存儲、網絡三大塊：

• Container Runtime：Docker 是最廣爲人知的容器運行環境，但生產環境下也有一些其他的容器環境在運行。Containerd 是滿足 OCI 規範的核心容器運行時，從設計上就是爲了嵌入大型系統的。它由 Docker Inc 公司啓動，並且在 2017 年 3 月份捐贈給了 CNCF。此外，CoreOS 的 RKT 是一個用於在 Linux 上運行應用程序容器的 CLI，也可以作爲安全、可組合和基於標準的容器虛擬化運行環境。

• Cloud-Native Storage：起初，容器爲無狀態的運行單元，容器最上一層文件系統無法保存其在運行時寫入的文件或數據，容器重建或重啓後，這些寫入的數據將丟失。但隨着數據庫、消息隊列等中間件逐步在容器環境中得到應用，如今用戶對容器持久化存儲的理解和需求也更加深入和迫切。

• Cloud-Native Network：網絡歷來是虛擬化技術中最靈活多變的部分，目前，大多數客戶使用的主要包括 Calico、Flannel、Open vSwitch 等方案。

4. Orchestration Management

這一層主要負責容器平臺的編排和調度，包括服務的發現和治理，遠程調用，服務代理，微服務治理等組件，包括：

• 計劃與編排：在這個領域，Kubernetes 是當仁不讓的頭號玩家，目前基於 Kubernetes 的容器生態得到了迅速發展。其它的編排工具還包括 Mesos 和 Docker Swarm 等。

• 協調與服務發現：分佈式計算中很重要的一點就是各個服務之間的協同以及服務發現（或節點發現的問題），從老牌的 ZooKeeper 到近年來在很多互聯網廠商和應用中流行的 Consul（Docker Swarm 默認使用），都可以用於分佈式服務的發現和配置，Kubernetes 默認使用的則是 CoreOS 旗下的 etcd。

• 遠程過程調用：微服務間進行通信，通常有兩種方式，一種是 HTTP REST-JSON 的方式，另一種爲 RPC 方式，兩者相比，RPC 方式效率更高。常用的包括 Google 開源的 GRPC、Apache 旗下的 Thrift 框架、Netflix 開源的自帶負載均衡的 Ribbon 和 Avra 數據序列化框架。

5. App Definition and Development

這一層就是容器平臺上運行的具體應用和工具了，可以理解爲容器平臺的應用商店。根據應用的不同作用的使用場景，可以大致分爲以下幾種類型：數據庫（例如 MySQL、MariaDB、MongoDB、PostgreSQL、Cassandra 等）、流處理和消息隊列（例如 Spark、Storm、RocketMQ、Kafka、RabbitMQ 等）、應用和鏡像製作（用於將應用封裝成標準鏡像，使應用能在標準的容器平臺上運行，例如 Helm、Docker Composer、Packer 等）、CI/CD（最常見的 Jenkins、Atlassian 公司開發的 Bamboo 等）。

6. Platform

從橫向上看，整個雲原生還包括衆多的經過認證的平臺供應商。

7. Observability and Analysis

這個部分包含了大量用於對平臺進行監控（Prometheus、Nagios、Grafana、Zabbix 等）、日誌（Fluentd、ElasticSearch、Logstash）、以及追蹤（Jaeger）的工具。

綜上所述，CNCF Landscape 全景圖中包含了 CNCF 社區成熟或使用範圍較廣、具有最佳實踐的產品和方案供用戶在實際應用中選擇，而且該生態還在快速發展中。

六、雲原生實施路徑

關於如何實現雲原生應用，CNCF 給出了比較詳細的利用開源軟件和雲原生技術的參考路線圖，如下圖所示：

圖 5：CNCF 雲原生技術路線圖

整個路線圖分成了十個步驟，每個步驟都是用戶或平臺開發者將雲原生技術在實際環境中落地時，需要循序漸進思考和處理的問題：

1. 容器化

目前最流行的容器化技術是 Docker，你可以將任意大小的應用程序和依賴項，甚至在模擬器上運行的一些程序，都進行容器化。隨着時間的推移，你還可以對應用程序進行分割，並將未來的功能編寫爲微服務。

2. CI/CD（持續集成和持續發佈）

創建 CI/CD 環境，從而使源代碼上的任意修改，都能夠自動通過容器進行編譯和測試，並被部署到預生產甚至生產環境中。

3. 應用編排

Kubernetes 是目前市場上應用編排領域被最廣泛應用的工具，Helm Charts 可以用來幫助應用開發和發佈者用於升級 Kubernetes 上運行的應用。

4. 監控和分析

在這一步中，用戶需要爲平臺選擇監控、日誌以及跟蹤的相關工具，例如將 Prometheus 用於監控、Fluentd 用於日誌、Jaeger 用於整個應用調用鏈的跟蹤。

5. 服務代理、發現和治理

CoreDNS、Envoy 和 LInkerd 可以分別用於服務發現和服務治理，提供服務的健康檢查、請求路由、和負載均衡等功能。

6. 網絡

Calico、Flannel 以及 Weave Net 等軟件用於提供更靈活的網絡功能。

7. 分佈式數據庫和存儲

分佈式數據庫可以提供更好的彈性和伸縮性能，但同時需要專業的容器存儲予以支持。

8. 流和消息處理

當應用需要比 JSON-REST 這個模式更高的性能時，可以考慮使用 gRPC 或者 NATS。gRPC 是一個通用的 RPC（遠程調用）框架（類似各種框架中的 RPC 調用），NATS 是一個發佈 / 訂閱和負載均衡的消息隊列系統。

9. 容器鏡像庫和運行環境

Harbor 是目前最受歡迎的容器鏡像庫，同時，你也可以選擇使用不同的容器運行環境用於運行容器程序。

10. 軟件發佈

最後可以藉助 Notary 等軟件用於軟件的安全發佈。

作者丨 yoshang 

來源丨網址：https://www.freebuf.com/articles/network/269379.html

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/UT3T7iSgriZ0d4c6n6Sa-Q