編排和管理層是Cloud Native Computing Foundation的Cloud Native景觀的第三層。
在之前的文章《叮，你收到一份來自CNCF的雲原生景觀簡介》中，我們對CNCF雲原生生態系統做了概述。在《雲原生景觀：供應層(Provisioning)解決了什麼問題？如何解決的？》中，我們探討了供應層，該層主要致力於構建Cloud Native平臺和應用程序的基礎。
在《雲原生景觀：運行時層解決了什麼問題？如何解決的？》裏，我們着重介紹了運行時層，涵蓋了容器在雲原生環境中運行所需的所有內容，包括容器運行時，容器存儲工具，容器網絡。
一旦按照安全性標準自動搭建了基礎結構(供應層)，並設置了應用程序需要運行的工具（運行時層），工程師就需要知道如何編排和管理其應用程序。
因此現在，我們必須弄清楚如何將所有應用程序組件作爲一個整體來組織和管理。組件還要能夠彼此標識才能進行溝通和協調，以實現一個共同的目標。
查看雲原生景觀圖時，你會注意到一些區別：
-
大盒子中的項目是CNCF託管的開源項目。有些仍處於孵化階段（淺藍色/紫色框），而另一些則是已畢業的項目（深藍色框）。
-
白色小盒子中的項目是開源項目。
-
灰色的盒子是專有產品。
請注意，即使在撰寫本文時，我們也看到有新項目成爲CNCF的一部分，因此始終參考實際情況-事情發展很快！
編排和調度( Orchestration & scheduling )
是什麼
編排和調度是指在集羣中運行和管理容器，這是一種新穎的打包和推送應用程序的方式。
容器編排器在某種程度上類似於筆記本電腦上的操作系統（OS），它可以管理所有應用程序（例如Microsoft 360，Slack，Zoom等）。操作系統執行你要使用的應用程序，並計劃哪個應用程序何時使用電腦的CPU和其他硬件資源。
雖然在一臺機器上運行所有功能都很棒，但是當今大多數現代應用程序都是分佈式的，並且需要能夠管理在幾十個甚至幾百個計算機上運行的所有組件。簡而言之，你需要一個“集羣操作系統”。這就是編排工具的用武之地。
在大多數情況下，Kubernetes也是容器協調器。容器和Kubernetes都是雲原生架構的核心，這就是爲什麼我們如此瞭解它們的原因。
解決了什麼問題
在雲原生架構中，應用程序被分解爲多個小組件或服務，每個組件或服務都放置在一個容器中。你可能聽說過它們被稱爲微服務。現在，你不再擁有一個大型應用程序，而是擁有多個小型服務，每個服務都需要資源，監視和問題修復。雖然爲單個服務手動執行這些操作是可行的，但是當你擁有數百個容器時，你將需要自動化的流程。
它如何解決
容器協調器使容器管理自動化。Kubernetes是事實上的容器編排器。
Kubernetes做一些所謂的理想狀態和解。工程師在文件中指定所需狀態，並與實際狀態進行連續比較。如果期望狀態和實際狀態不匹配，Kubernetes會通過創建或銷燬對象來協調它們。
相應的解決工具
Kubernetes與其他容器協調器（例如Docker Swarm和Mesos）一起位於編排和調度部分。它的基本目的是允許你將多個不同的計算機作爲一個資源池進行管理。最重要的是，它允許你以聲明性的方式管理它們，即，不是告訴Kubernetes如何做某事，而是提供了你要完成的工作的定義。這使你可以在一個或多個YAML文件中維護所需的狀態，並將其應用於任何Kubernetes集羣。然後，協調器本身會創建缺失的內容或刪除不應該存在的任何內容。
| 術語 | 熱門項目/產品 |
|---|---|
| 集羣
調度器 編排 |
Kubernetes
Docker Swarm Mesos |
協調和服務發現 (Coordination &Service Discovery )
是什麼
如我們所見，現代應用程序由多個單獨的服務組成，這些服務需要進行協作才能爲最終用戶提供價值。爲了進行協作，他們需要通過網絡進行通信。爲了進行通信，他們必須首先相互定位。服務發現是弄清楚該如何做的過程。
解決了什麼問題
雲原生體系結構是動態的，可變的，這意味着它們在不斷變化。當一個容器在一個節點上崩潰時，一個新的容器會在另一個節點上替換它。或者，當應用擴展時，副本將散佈在整個網絡中。沒有一個地方可以提供特定服務。一切的位置在不斷變化。服務發現工具跟蹤網絡中的服務，以便服務可以在需要時找到彼此。
它如何解決
服務發現工具通過提供註冊和發現中心來查找和標識單個服務來解決此問題。該類別中基本上有兩種工具：
（1）服務發現引擎是類似於數據庫的工具，用於存儲存在哪些服務以及如何定位它們的信息。
（2）名稱解析工具（例如， Core DNS ）接收服務位置請求並返回網絡地址信息。
備註：
在Kubernetes中，爲了使Pod可達，引入了一個被稱爲“ service”的工作負載 。service爲動態更改的Pod組提供了一個穩定的地址。
相應的解決工具
隨着分佈式系統變得越來越普遍，傳統的DNS流程和負載均衡器通常無法跟上不斷變化的端點信息。爲了彌補這些缺點，創建了服務發現工具來處理各個應用程序實例信息，以快速地對其自身進行註冊和註銷。
CoreDNS和etcd是CNCF項目，內置在Kubernetes中。
| 術語 | 熱門項目/產品 |
|---|---|
| 域名解析(DNS)
服務發現(Service Discovery) |
CoreDNS etcd Zookeeper Eureka |
遠程過程調用(RPC)
是什麼
遠程過程調用（RPC）是一種使應用程序能夠相互通信的技術。
解決了什麼問題
現代應用程序由衆多單獨的服務組成，這些服務必須進行通信才能進行協作。RPC是處理應用程序之間通信的一種選擇。
RPC要解決的兩個問題：
解決分佈式系統中，服務之間的調用問題。
遠程調用時，要能夠像本地調用一樣方便，讓調用者感知不到遠程調用的邏輯。
它如何解決
RPC提供瞭解決服務之間通信的緊密耦合方式。它的通信高效，並且許多語言支持RPC接口實現。
相應的解決工具
gRPC是一種特別流行的RPC實施，已被CNCF採用。
| 術語 | 熱門項目/產品 |
|---|---|
| gRPC | gRPC |
服務代理 ( Service proxy)
是什麼
代理的唯一目的是對服務通信施加更多控制，它不會對通信本身添加任何內容。
服務代理是一種工具，用於攔截進出給定服務的流量，對其應用一些邏輯，然後將該流量轉發到另一個服務。它本質上充當“中間人”，收集有關網絡流量的信息/或對其應用規則。
解決了什麼問題
應用程序應以受控方式發送和接收網絡流量。爲了跟蹤流量並可能對其進行轉換或重定向，我們需要收集數據。傳統上，啓用數據收集和網絡流量管理的代碼嵌入在每個應用程序中。
服務代理使我們能夠“外部化”此功能。它不再需要存在於應用程序中。而是將其嵌入平臺層（你的應用程序在其中運行）。這是非常強大的功能，因爲它使開發人員可以完全專注於編寫應用程序邏輯，而處理流量的通用任務由平臺團隊管理。通過單個公共位置集中管理和分發全局所需的服務功能（例如，路由或TLS終止），服務之間的通信更加可靠，安全和高效。
它如何解決
代理充當用戶和服務之間的”看門人”。通過這種獨特的定位，代理可以洞悉正在發生的通信類型，他們可以確定將特定請求發送到哪裏，甚至完全拒絕該請求。
代理收集關鍵數據，管理路由（在服務之間平均分配流量或在某些服務發生故障時重新路由），加密連接信息和緩存數據（減少資源消耗）。
相應的解決工具
服務代理的工作原理是攔截服務之間的流量，對它們執行一些邏輯，然後潛在地允許流量繼續前進。通過將一組集中控制的功能放入此代理，他們可以收集有關服務間通信的詳細指標，防止服務過載，並將其他通用標準應用於服務。
服務代理是服務網格等其他工具的基礎，因爲它們提供了對所有網絡流量實施更高級別策略的方法。
請注意，CNCF將負載均衡器和 ingress 提供程序包括在此類別中。Envoy，Contour和BFE都是CNCF項目。
| 術語 | 熱門項目/產品 |
|---|---|
| 服務代理
入口 |
Envoy
Contour NGINX |
API網關
是什麼
人們通常通過諸如網頁或應用程序之類的GUI（圖形用戶界面）與計算機程序進行交互，而計算機則通過API（應用程序接口）進行交互。但是，不應將API與API網關混淆。
API網關允許組織將關鍵功能（例如授權或限制應用程序之間的請求數量）放置到集中管理的位置。它還用作API使用者的通用接口。
通過API網關，組織可以集中控制（限制或啓用）應用程序之間的交互並跟蹤它們，從而實現諸如退款，身份驗證之類的功能，並防止服務被過度使用（也稱爲速率限制）。
解決了什麼問題
儘管大多數容器和核心應用程序都具有API，但API網關不僅僅是API。API網關簡化了組織如何管理規則並將規則應用於所有交互。
API網關允許開發人員編寫和維護較少的自定義代碼。他們還使團隊能夠查看和控制用戶與應用程序本身之間的交互。
它如何解決
API網關位於用戶和應用程序之間。它充當中介，將來自用戶的消息（請求）轉發給適當的服務。但是在交出請求之前，它會評估是否允許用戶執行他們正在嘗試做的事情，並記錄有關發出請求的用戶信息以及發出的請求數量的詳細信息。
簡而言之，API網關爲用戶提供了應用程序的單入口點。它還使你可以將原本在應用程序中實現的任務移交給網關，從而節省了開發人員的時間和金錢。
相應的解決工具
API網關的工作原理是攔截對後端服務的調用，執行某種“增值活動“，例如驗證授權，收集指標或轉換請求，然後執行其認爲適當的任何操作。
API網關是一組下游應用程序的通用入口點，同時提供了一個團隊可以在其中注入業務邏輯以處理授權，速率限制和退款的地方。
| 術語 | 熱門項目/產品/產品 |
|---|---|
| API網關 | Kong
Mulesoft Ambassador |
服務網格
是什麼
“繼Kubernetes之後，服務網格技術已成爲雲原生堆棧中最關鍵的組件。”
服務網格管理服務之間的流量（即通信）。它們使平臺團隊能夠在集羣內運行的所有服務之間統一添加可靠性，可觀察性和安全性功能，而無需更改任何代碼。
解決了什麼問題
在雲原生世界中， 隨着服務數量的增加，我們必須處理它們之間的交互。除了服務之間的通信外，我們還必須處理整個系統運行狀況的監視，容錯，日誌記錄和遙測功能，處理多點故障等等。
在服務網格之前，必須將該功能編碼到每個單獨的應用程序中。
有了Service Mesh，我們不必使用任何第三方庫/組件，就可以在每個微服務中提供與網絡相關的通用功能，例如配置，路由，遙測，記錄，斷路等。
它如何解決
服務網格在平臺層上的所有服務之間均勻地增加了可靠性，可觀察性和安全性功能，而無需觸及應用程序代碼。它們與任何編程語言兼容，使開發團隊可以專注於編寫業務邏輯。
相應的解決工具
服務網格通過服務代理將集羣上運行的所有服務綁定在一起，從而形成服務網格。這些通過服務網格控制平面進行管理和控制。服務網格允許平臺所有者在不要求開發人員編寫自定義邏輯的情況下執行常見操作或在應用程序上收集數據。
服務網格可以定義爲處理微服務架構中服務間通信的專用基礎結構層 ，它的功能在於無需修改應用程序即可提供關鍵系統功能的能力。
服務網格提供了許多有用的功能，包括顯示詳細指標，加密所有流量，限制由什麼服務授權的操作，提供插件的功能等等。有關更多詳細信息，請查看服務網格接口規範。
| 術語 | 熱門項目/產品 |
|---|---|
| 服務網格
邊車(Sidecar) 數據平面 控制平面 |
Linkerd
Consul Istio |
結論
如我們所見，該層中的工具將一個個獨立的容器化服務作爲一個組進行管理。編排和調度工具類似某種集羣操作系統，用於管理整個集羣中的容器化應用程序。協調和服務發現，服務代理和服務網格可確保服務可以彼此找到並進行有效通信，以便作爲一個內聚的應用程序進行協作。API網關是一個附加層，可提供對服務通信的更多控制，尤其是在外部應用程序之間。
譯者：王延飛
譯文鏈接:
https://thenewstack.io/the-cloud-native-landscape-the-orchestration-and-management-layer/