作者丨Bryant Son
譯者丨良言
策劃丨趙鈺瑩
隨著使用容器開發應用程式變得越來越流行，雲原生應用程式也開始普及起來。本文作者對雲原生技術展開了深入分析，並對雲原生專案的生命週期進行了簡要說明，最後介紹了 9 個值得考慮的開源雲原生專案。
隨著使用容器開發應用程式變得越來越流行，雲原生應用程式也開始普及起來。根據其定義：
雲原生技術用於開發一類特別的應用程式，這類應用程式透過容器中的服務構建，然後按照微服務的形式部署，並透過 DevOps 敏捷流程以及可持續交付工作流在彈性基礎設施上進行管理。
上述描述包括了雲原生應用程式中四個不可或缺的要素：
容器化
微服務
DevOps
持續整合和交付（CI/CD）
儘管這些技術有著截然不同的歷史，但它們相輔相成，並且在很短的時間內催生了雲原生應用程式及其工具集的指數性增長。這張雲原生計算基金會（cloud native Computing Foundation，CNCF）的資訊圖展示了當今雲原生應用程式生態的規模和範圍。
雲原生計算基金會專案
這張圖片只是一個開始。正如 node。js 的發明引發了無數 JavaScript 工具的爆炸式增長一樣，容器技術的流行也開啟了雲原生應用程式的指數增長。
好訊息是已經有幾個組織開始監督這些專案並將它們連線起來。一個是開放容器計劃（Open Containers Initiative，OCI），這是一個輕量級、開放的治理結構（或專案），在 Linux 基金會的支援下產生，其明確的目的就是圍繞容器格式和執行時建立開放的行業標準。另一個是 CNCF，一個致力於雲計算普及化和可持續化的開源軟體組織。
除了圍繞雲原生應用程式構建社群以外，CNCF 還幫助專案建立了治理結構。CNCF 提出了成熟度級別的概念：沙箱、孵化和畢業。這些級別分別對應下圖中的創新者、早期採用者和早期大眾。
CNCF 專案成熟等級
CNCF 對每個成熟等級都有詳細的標準（為方便讀者，我們將在下面詳細講解）。一個正在孵化或畢業的專案需要技術監督委員會（TOC）三分之二的投票。
沙箱階段
要想進入沙箱階段，一個專案必須至少有兩個 TOC 贊助人。詳細過程請參閱 CNCF 沙箱指南 1。0 版本。
孵化階段
注意：我們期望從孵化階段開始對專案進行全面的盡職調查。
要進入孵化階段，專案首先必須滿足沙箱階段的要求，此外：
記錄至少有三個獨立的終端使用者在生產中成功使用了該專案，並且技術委員會認定其具有足夠的質量和範圍。
有一定數量的提交者。提交者的定義是具有提交許可權的人，即可以對專案部分或整體接收貢獻的人。
展示專案的提交和合並貢獻持續穩定增長。
由於這些度量標準可能因為專案的型別、範圍和大小而有很大的差異，因此對於專案是否滿足這些標準，TOC 具有最終決定權。
畢業階段
要從沙箱或孵化階段畢業，或者要加入一個新專案作為畢業專案，該專案必須滿足孵化階段的所有標準，另外還要加上：
至少有來自兩個組織的提交者。
實現並維護了核心基礎設施倡議的最佳實踐徽章。
已經完成了一個獨立的第三方安全審計，公佈結果的範圍和質量類似於下面的例子（包括關鍵漏洞的修復）：
https：//github。com/envoyproxy/envoy#security-audit
所有的關鍵漏洞都需要在畢業前得到修復。
採用 CNCF 行為守則。
明確定義專案治理和提交者流程。這最好放在一個 goverance。md 檔案中，並引用一個 OWNERS。md 檔案來顯示當前提交者和歷史提交者。
至少在主要倉庫提供一個專案採用者的公開列表（例如，專案網站上的 ADOPTERS。md 或公司徽標）。
獲得技術選擇委員會的絕對多數選票進入畢業階段。如果專案能夠證明足夠成熟，它們可以嘗試直接從沙箱移動到畢業。專案可以無限期地保持孵化狀態，但通常預計會在兩年內畢業。
值得考慮的九個專案
雖然不可能涵蓋上圖中所有的 CNCF 專案，但我將介紹九個最有趣的開源專案，這些專案有的已經畢業，有的仍在孵化階段。
讀者可透過該影片教程來詳細瀏覽這些專案。
畢業專案
畢業專案被認為是成熟的（已經被許多組織採用）並且必須遵守 CNCF 的指導方針。以下是三個最受歡迎的開源 CNCF 畢業專案。請注意，其中一些描述直接摘自專案網站或稍作編輯。
Kubernetes
在談論雲原生應用程式的時候怎麼能忘記 Kubernetes？由 Google 發明的 Kubernetes 無疑是最著名的容器編排平臺，它也是一個開源工具。
什麼是容器編排平臺？基本上，一個容器引擎本身可以用來管理幾個容器。然而，當面對數以千計的容器和數以百計的服務時，管理這些容器就變得超級複雜。這時候容器引擎就有了用武之地。容器編排引擎透過自動化容器的部署、管理、網路和可用性來幫助擴充套件容器。
Docker Swarm 和 Mesosphere Marathon 是其它兩個容器編排引擎，但可以肯定地說，Kubernetes 成為了贏家（至少目前是這樣）。Kubernetes 也催生了像 OKD 這樣的容器即服務平臺（Container-as-a-Service，CaaS）。OKD 是 Kubernetes 的 Origin 社群發行版，並提供對 RedHat OpenShift 的支援。
想要入門，請訪問 Kubernetes 的 GitHub 程式碼庫，並從 Kubernetes 文件頁面訪問其文件和學習資源。
Prometheus
Prometheus 是 SoundCloud 在 2012 年開發的一個開源系統監控和警報工具包。從那時起，許多公司和組織就採用了 Prometheus。該專案有一個非常活躍的開發者和使用者社群，它現在是一個獨立的開源專案，獨立於公司之外由社群進行維護。
Prometheus 的架構
理解 Prometheus 最簡單的方法就是把它想象成一個每年 365 天，每天 24 小時都在運轉的生產系統。沒有哪個系統是完美的，有技術可以減少故障（稱為容錯系統）。然而，如果發生問題，最重要的事情是儘快定位問題。這時候，類似 Prometheus 這樣的監控工具就可以派上用場了。
Prometheus 不僅僅是一個容器監控工具，它在雲原生應用程式公司中也非常受歡迎。此外，包括 Grafana 在內的其他開源監控工具也都使用 Prometheus。
入門 Prometheus 最好的方法就是檢視它的 GitHub 庫。在本地執行 Prometheus 很容易，但是你需要安裝一個容器引擎。Prometheus 的網站上有關於這方面的詳細文件。
Envoy
Envoy（或 Envoy Proxy）是一個為雲原生應用程式設計的開源邊緣和服務代理。它由 Lyft 建立，是一個專門為單一服務和應用程式設計的高效能 C++ 分散式代理，還是一個專為大型微服務網狀架構設計的通訊匯流排和通用資料平面。Envovy 基於對 Nginx、HAProxy、硬體負載平衡器和雲負載平衡器等解決方案的學習，與每個應用程式一起執行，透過以一種與平臺無關的方式提供通用功能來實現網路抽象。
當基礎設施中所有的服務流量流經 Envoy 網格時，可以很容易地在一個地方透過一致的可觀察性來圖形化問題區域、調整總體效能以及新增底層功能。基本上，Envoy Proxy 是一種服務網格工具，可以幫助組織為生產環境構建容錯系統。
服務網格應用程式有很多替代品，比如 Uber 的 Linkerd （下面討論）和 Istio 。Istio 透過部署為 Sidecar 並利用 Mixer 配置模型來擴充套件 Envoy Proxy。值得注意的特點有：
包括所有的基本功能（例如同 Istio 控制平面配對時）
工作負載低，在規模化擴充套件時將近百分之九十九的延遲處於負載不足
核心層作為 L3/L4 過濾器，提供了許多 L7 過濾器
支援 gRPC 和 HTTP/2（上游 / 下游）
由 API 驅動，支援動態配置和熱過載
側重於度量的收集、跟蹤和整體可觀察性
想要理解 Envoy、證明它的能力並實現其全部優點，需要在執行生產級環境方面具有豐富的經驗。更多詳細內容可以參閱文件，也可以訪問它的 GitHub 程式碼庫。
孵化專案
以下是六個最受歡迎的開源 CNCF 孵化專案。
Rkt
Rkt 的發音是”rocket（火箭）”，它是一個 pod 原生容器引擎。它有一個在 Linux 上執行容器的命令列介面（CLI）。在某種意義上，它同其它容器類似，如 Podman 、Docker 和 CRI-O。
Rkt 最初由 CoreOS 開發（後來被 RedHat 收購），你可以在官網上找到詳細的文件，也可以在 GitHub 上訪問原始碼。
Jaeger
Jaeger 是一個面向雲原生應用程式的開源端到端分散式跟蹤系統。在某種程度上，它是一個像 Prometheus 一樣的監控解決方案。但是它又是不同的，因為它的使用場景可以擴充套件到：
分散式事務監控
效能和延遲最佳化
根本原因分析
服務依賴項分析
分散式上下文傳播
Jaeger 是一項由 Uber 開發的開源技術。你可以在官網上找到詳細的文件，也可以在 GitHub 上找到原始碼。
Linkerd
就像 Lyft 的 Envoy Proxy 一樣，Uber 開發了開源解決方案 Linkerd 來維持它的產品級服務。在某些方面，Linkerd 就像是 Envoy，因為它們都是服務網格工具，旨在提供平臺範圍內的可觀察性、可靠性和安全性，而不需要配置或程式碼更改。
然而，兩者之間存在一些細微的差別。雖然 Envoy 和 Linkerd 同時充當代理，可以報告已連線的服務，但 Envoy 並不像 Linkerd 那樣被設計成 Kubernetes Ingress 控制器。Linkerd 的顯著特點包括：
支援多平臺（Docker、Kubernetes、DC/OS、Amazon ECS 或任何獨立機器）
內建的服務發現抽象，以統一多個系統
支援 gRPC、HTTP/2 和 HTTP/1。x 請求以及所有 TCP 通訊