都在說雲原生，它的技術圖譜你真的瞭解嗎？

若是你研究過雲原生應用程序和相關技術，大機率你遇到過 CNCF 的雲原生全景圖。這張全景圖技術之多規模之大無疑會讓人感到震驚，該如何去理解這張圖呢？

若是把它拆開來一次只分析一小塊內容，你會發現整個全景圖沒有那麼複雜。事實上，該全景圖按照功能有序地組織在一塊兒，一旦你瞭解了每一個類別表明的內容，你就能夠輕鬆遊走於全景圖中。

雲原生全景圖的 4 層

首先，咱們剝離掉全部單個的技術，僅查看類別（以下圖）。圖中有不一樣的「行」，像建築的不一樣層，每層都有本身的子類別。最底層提供了構建雲原生基礎設施的工具。往上，你能夠開始添加運行和管理應用程序所需的工具，好比運行時和調度層。在最上層，有定義和開發應用程序的工具，好比數據庫、鏡像構建和 CI/CD 工具（咱們將在後文討論）。

好了，如今你應該記住了雲原生全景圖始於基礎設施，往上的每一層都更接近實際的應用程序。這就是每層表明的意思（後面咱們會討論上圖右邊的兩「列」）。下面咱們就從最底層開始，逐層進行解析。

供應層 （Provisioning）

供應指的是爲雲原生應用準備標準基礎環境所涉及的工具。它包含了基礎設施的建立、管理、配置流程的自動化，以及容器鏡像的掃描、簽名和存儲等。供應層經過提供設置和實施策略，在應用程序和平臺中構建身份驗證和受權，以及處理密鑰分發等等的工具，也拓展到了安全領域。

供應層包括：

• 自動化和部署工具：幫助工程師在無需人工干預狀況下便可構建計算環境；
• 容器註冊表：存儲應用程序的可執行文件；
• 不一樣安全領域的安全和合規框架；
• 密鑰管理解決方案：經過加密確保只有受權的用戶才能訪問特定的應用程序。
• 這些工具使工程師能夠編寫基礎設施參數，使系統能夠按需搭建新環境，確保了一致性和安全性。

運行時層（Runtime）

接下來是運行時層。這個詞可能會讓你感到迷惑。像不少 IT 術語同樣，運行時沒有嚴格的定義，且能夠根據語境有不一樣的用法。狹義上講，運行時是特定機器上準備運行應用程序的沙盒——也就是保障應用程序正常運行所需的最低配置。廣義上講，運行時是運行一個應用程序所需的全部工具。

在 CNCF 雲原生全景圖中，運行時保障了容器化應用程序組件的運行和通訊， 包括：

• 雲原生存儲：爲容器化應用提供虛擬磁盤或持久化存儲；
• 容器運行時：爲容器提供隔離、資源和安全；
• 雲網絡：分佈式系統的節點（機器或進程）經過其鏈接和通訊。

編排和管理層（Orchestration and Management）

一旦按照安全和合規性標準（供應層）自動化基礎設施供應，並安裝了應用程序運行所需的工具（運行時層），工程師就須要弄清楚如何編排和管理應用程序。編排和管理層將全部容器化服務（應用程序組件）做爲一個羣組管理。這些容器化服務須要相互識別和通訊，並須要進行協調。這一層可爲雲原生應用提供自動化和彈性能力，使雲原生應用自然具備可擴展性。

這一層包含：

• 編排和調度：部署和管理容器集羣，確保它們具備彈性伸縮能力，相互之間低耦合，而且可擴展。事實上，編排工具（絕大多數狀況下就是 Kubernetes）經過管理容器和操做環境構成了集羣；
• 協調和服務發現：使得服務（應用程序組件）之間能夠相互定位和通訊；
• 遠程進程調用（RPC）：使跨節點服務間通訊的技術；
• 服務代理：服務間通訊的中介。服務代理的惟一目的就是對服務之間的通訊進行更多控制，而不會對通訊自己添加任何內容。服務代理對下面將提到的服務網格（service mesh）相當重要。
• API 網關：一個抽象層，外部應用可經過 API 網關進行通訊；
• Service Mesh：某種程度上相似於 API 網關，它是應用程序進行通訊的專用基礎架構層，提供基於策略的內部服務間通訊。此外，它還可能包含流量加密、服務發現、應用程序監控等內容。

應用定義和開發層 （Application Definition and Developement)

如今，咱們來到了最頂層。應用定義和開發層，顧名思義，彙集了讓工程師構建和運行應用程序的工具。上述全部內容都是關於構建可靠、安全的環境，以及提供所有所需的應用程序依賴。

這一層包括：

• 數據庫：使應用程序能以有序的方式收集數據；
• 流和消息傳遞：使應用程序能發送和接收消息（事件和流）。它不是網絡層，而是讓消息成爲隊列並處理消息的工具；
• 應用程序定義和鏡像構建：用於配置、維護和運行容器鏡像（應用程序的可執行文件）的服務；
• 持續集成和持續交付（CI/CD）：使開發者可自動測試代碼是否與代碼庫（應用程序的其他部分）兼容。若是團隊足夠成熟，甚至能夠自動部署代碼到生產環境。

貫穿全部層的工具

接下來咱們將進入到雲原生全景圖右側貫穿全部層的兩列。可觀察性和分析（Observability&analysis）是監控各層的工具，平臺則將各層中不一樣的技術捆綁爲一個解決方案。

可觀察性和分析（Observability and Analysis）

爲了限制服務中斷並下降解決問題的平均時間（MRRT），你須要監控和分析應用層序的方方面面，以便在出現異常時可當即發現並糾正。複雜環境中容易出現故障，這些工具可快速識別並解決故障，從而下降故障帶來的影響。因爲這一類別貫穿並監控各層，所以它在側面，而不是嵌入到某一層中。

這這一類別你將發現：

• 日誌工具：收集事件日誌（有關進程的信息）；
• 監控方案：收集指標（以數字表示的系統參數，例如 RAM 可用性）；
• 追蹤工具：追蹤比監控更進了一步，它們監控用戶請求的傳播，與服務網格相關。
• 混沌工程（Chaos Engineering）：在生產環境中測試軟件的工具，可識別缺陷並進行修復，減小其對服務交付的影響。

平臺類（Platform）

能夠看到，圖中每個模塊解決一個特定的問題。但咱們知道，僅有存儲並不能提供應用程序所需的所有功能。你還須要編排工具，容器運行時，服務發現，網絡，API 網關等等。平臺覆蓋多層，將不一樣的工具組合在一塊兒，以解決更大的問題。

配置和微調不一樣的模塊使其安全可靠，並確保它利用的技術都能及時更新、全部漏洞都打了補丁，這並非一件容易的事情。使用平臺時，用戶不用額外擔憂這些細節問題。

你可能會注意到，全部的類別都圍繞着 Kubernetes 展開。這是由於 Kubernetes 雖然只是雲原生景觀圖這張拼圖中的一塊，但它倒是雲原生技術棧的核心。順便說一下，CNCF 剛建立時，Kubernetes 就是其中的第一個種子項目，後來纔有了其餘項目。

平臺可分爲四類：

• Kubernetes 發行版：採用未經修改的開放源代碼（儘管有人對其進行了修改），並根據市場須要增長了其餘功能；
• 託管的 Kubernetes：相似於 Kubernetes 發行版，可是由提供商託管；
• Kubernetes 安裝程序：自動執行 Kubernetes 的安裝和配置過程；
• PaaS/容器服務：相似於託管的 Kubernetes，可是包含了一套更普遍的應用部署工具（一般是來自雲原生景觀圖）。

總結

在每一個類別中，針對相同或類似的問題，都有不一樣的工具可選擇。有一些是適用於新現實的預雲原生技術，還有一些則是全新的。區別在於它們的實現和設計方法。沒有完美的技術符合你的全部需求。大多數狀況下，技術受設計和架構選擇的限制——始終須要權衡取捨。

在選擇技術棧時，工程師必須仔細考慮每種能力和須要權衡取捨的地方，以肯定最合適的選項。雖然這樣會讓狀況變得更復雜，但在選擇應用程序所需的最適合的數據存儲、基礎設施管理、消息系統等方案時，這樣作是最可行的辦法。如今，構建一個系統比雲原生以前的時代容易多了。若是構建恰當，雲原生技術將提供更強大的靈活性。在現現在快速變化的技術生態中，這多是最重要的能力之一。（文章來自CSDN，鳴謝）