如果你一直在跟蹤和研究云原生應用程序和技術，一定會知道云原生計算基金會(CNCF)的云原生技術圖譜(Landscape)。乍一眼看去，你一定會被龐大的云原生規模所震撼，為什么會有如此眾多的類別和技術，想要了解完整的技術圖譜不是容易的事情。

清晰技術圖譜可在CNCF網站查看

但如果對其剝絲抽繭，分解類別，以及搞清楚每一類代表了哪些技術，以及每個類別所要解決的問題，那么理解上就會輕松很多。大體上云原生技術圖譜可以分為四層配置層(Provisioning Layer)、運行時層(Runtime Layer)、編排和管理層(Orchestration and Management Layer)、應用定義和開發層(Application Definition and Development Layer)。架構的每一層都有自己的子類別。

配置層(Provisioning Layer)

配置層是構建云原生應用程序基礎所涉及的工具。它包含了從自動化基礎結構的創建，管理和配置到掃描，簽名和存儲容器鏡像等所有內容。提供設置和實施策略，在應用程序和平臺中構建身份驗證和授權，以及處理機密分發的工具，資源調配，甚至擴展到了安全領域。它包含了一些重要的子類別：

• 自動化和配置工具——幫助工程師在無需人工干預下構建計算環境。
• 容器注冊表——存儲應用程序的可執行文件。
• 安全和合規框架——涉及不同的安全領域。
• 密鑰管理解決方案——加密來確保只有授權的用戶才能訪問應用程序。

這些工具使工程師可以整理所有基礎架構的細節，便于系統可以根據需要來調整環境，確保它們的一致性和安全性。

運行時層(Runtime Layer)

運行時是可能引起混淆的術語之一。與IT中的許多術語一樣，沒有嚴格的定義，可以根據上下文使用不同的定義。從狹義上講，運行時是準備運行應用程序的特定計算機上的沙箱，即應用程序所需的最低限度。從廣義上講，運行時是應用程序需要運行的任何工具。

在CNCF的云原生環境中，運行時在兩者之間的某個位置定義，重點放在對容器化應用特別重要的組件上：它們需要運行，記憶和互動的內容。它們包括：

• 云原生存儲為容器化的應用程序提供了虛擬化磁盤或持久性。
• 容器運行時為容器提供了約束，資源和安全性方面的考慮，并使用編程后的應用程序執行了文件。
• 云原生網絡，分布式系統的節點(機器或過程)通過其進行連接和通信的網絡。

編排和管理層(Orchestration and Management Layer)

一旦按照安全性和合規性標準自動執行基礎結構設置，并設置了應用程序需要運行的工具，工程師就必須弄清楚如何編排和管理其應用程序。編排和管理層處理所有容器化服務(應用程序組件)如何作為一個組進行管理。他們需要確定其他服務，相互通信并進行協調。云原生應用程序具有固有的可擴展性，它依賴于此層啟用的自動化和彈性。

在這一層中包括：

• 編排和調度——部署和管理容器集群，以確保它們具有彈性，松散耦合和可伸縮性。實際上，在大多數情況下，編排工具Kubernetes就是通過管理容器和操作環境構成集群的
• 協調和服務發現——因此服務(應用程序組件)可以相互定位和通信。
• 遠程過程調用(RPC)——一種使一個節點上的服務與通過網絡連接的不同節點上的服務進行通信的技術。
• 服務代理——是放置在服務之間的中介，通過它們進行通信。代理的唯一目的是對服務通信施加更多控制，它不會對通信本身添加任何內容。這些代理對于下面提到的服務網格至關重要。
• API網關——一個抽象層，外部應用程序可以通過它進行通信。
• 服務網格——在某種程度上類似于API網關，它是應用程序通過其進行通信的專用基礎結構層，但是它提供了策略驅動的內部服務到服務的通信。此外，它可能包括從流量加密到服務發現到應用程序可觀察性的所有內容。

應用定義和開發層(Application Definition and Development Layer)

顧名思義，應用程序定義和開發層側重于讓工程師能夠構建應用程序并使其運行的工具。上面討論的所有內容都與構建可靠，安全的環境以及提供所有必需的應用程序依賴關系有關。

在這層包括：

• 數據庫——使應用程序能夠以有組織的方式收集數據的數據庫。
• 流和消息——傳遞使應用程序能夠發送和接收消息(事件和流)。它不是網絡層，而是用于對消息進行排隊和處理的工具。
• 應用程序定義和鏡像構建——是幫助配置，維護和運行容器鏡像(應用程序的可執行文件)的服務。
• 持續集成和交付(CI/CD)——使開發人員能夠自動測試其代碼是否與代碼庫(應用程序的其余部分)兼容，如果他們的團隊足夠成熟，甚至可以自動部署到生產中。

跨所有層運行的工具

回到類別上，下面討論在所有層上運行的列分類。可觀察性和分析是監控所有層的工具。另一方面，平臺將這些層中的多種技術捆綁到一個解決方案中，包括可觀察性和分析。

可觀察性與分析(Observability and Analysis)

為了限制服務中斷并降低MRRT(解決問題的時間)，需要監控和分析應用程序的各個方面，以便立即發現并糾正任何異常情況。故障將在復雜的環境中發生，這些工具將通過幫助盡快識別和解決故障來幫助減輕影響。由于此類別遍歷并監控所有層，因位于垂直面，而不是嵌入在特定層中。

在這層包括：

• 收集事件日志——有關進程的信息的日志記錄工具。
• 監控解決方案——收集指標(數字系統參數，例如RAM可用性)。
• 跟蹤——比監控和監控用戶請求的傳播更進一步。與服務網格相關。
• 混沌工程——是對生產中的軟件進行測試的工具，可以在缺陷影響服務交付之前對其進行識別并加以修復。

平臺(Platforms)

如上，每個模塊都解決了一個特定的問題。僅存儲并不能提供管理應用程序所需的全部功能。我們需要一個編排工具、容器運行時、服務發現、網絡、API網關等。覆蓋多層，平臺將不同的工具捆綁在一起，以解決更大的問題。

配置和微調不同的模塊以使其可靠和安全，并確保更新其利用的所有技術，并修補漏洞。使用平臺，用戶不必擔心這些細節，可實現生產中的增值。

你可能會注意到，所有類別都圍繞Kubernetes展開。這是因為Kubernetes是云原生堆棧的核心。別忘記，Kubernetes是CNCF的第一個孵化項目，之后才有了其他所有后續項目。

平臺可分為四種：

• Kubernetes發行版(Kubernetes distributions)采用了未經修改的開源代碼，盡管有供應商對其進行了修改，并圍繞其市場添加了其市場需求的其他功能。
• 托管Kubernetes(Hosted Kubernetes)類似于發行版，但由提供商在其或用戶自己的基礎架構上進行管理。
• Kubernetes安裝程序(Kubernetes installers)，它們可以自動執行Kubernetes的安裝和配置過程。
• PaaS/容器服務(PaaS/container services)，與托管的Kubernetes相似，但是包含了廣泛的應用程序部署工具集(通常是云原生環境的一部分)。

總結

在每種類別中，都有解決相同或相似問題的不同工具。有些是滿足當下云原生技術的，有些則是全新的。區別在于它們的實現和設計方法。沒有好的技術，因為在大多數情況下技術受到設計和架構選擇的限制，始終存在一個權衡。

在選擇堆棧時，云原生工程師必須仔細考慮每種功能并進行權衡，以確定適合其用例的好選擇。盡管這帶來了額外的復雜性，但選擇最適合應用程序需求的數據存儲，基礎架構管理，消息系統等是必須的。現在，架構系統比在云之前的原生世界中容易得多。而且，如果進行適當的架構設計，云原生技術將提供強大且急需的靈活性。

本文標題：一文讀懂云原生技術圖譜
文章源于：http://m.newbst.com/news46/99596.html

成都網站建設公司_創新互聯，為您提供企業建站、動態網站、網站設計、靜態網站、定制網站、響應式網站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯