云原生—编排及管理
前面的文章介紹過：云原生應用的定義和部署。今天主要介紹云原生編排及管理。云原生—應用定義及部署
目錄
一、Orchestration & Management?編排及管理?
二、Scheduling & Orchestration編排和調度
三、Coordination & Service Discovery?協調和服務發現
四、Remote Procedure Call??遠程過程調用RPC
五、Service Proxy?服務代理
六、API Gateway?API網關
七、Service Mesh?服務網格
一、Orchestration & Management?編排及管理?
前面已經講解了關于云原生應用定義和及部署，我們現在可以深入研究編排和管理流程。
本節內容里面，你可以找到用于處理運行和連接云原生應用程序的工具。
另外，本節內容也涵蓋了從 Kubernetes 本身到負責應用程序間和外部通信的基礎設施層的所有內容。
本質上來看，可擴展的云原生應用程序依賴于這些工具所支持的自動化和彈性化。
這一層主要負責容器平臺的編排和調度工作。包括服務的發現治理、遠程調用、服務代理、微服務治理等組件。
編排和管理的基本結構如下，
二、Scheduling & Orchestration編排和調度
編排和調度是指跨集群運行和管理容器。集群是一組通過網絡連接的物理或虛擬機器。
容器編排器（和調度器）有點類似于筆記本電腦上的操作系統。
操作系統管理您的所有應用程序，例如 Microsoft Office、微信和QQ等；操作系統會執行它們，并安排每個應用程序何時使用筆記本電腦的硬件資源，如 CPU、內存和存儲等。
雖然在一臺機器上運行一切在管理層面看是最好不過的，但今天的大多數應用程序實際上所處理的數據可能都比一臺計算機要大得多。
例如，目前像很京東、淘寶這種大型的電商平臺。他們擁有非常龐大的應用程序并分布在數萬臺不同的機器上，形成了一個分布式集群。
目前，大多數應用程序都是以這種方式構建的，因此，我們需要一個能夠管理在這些不同機器上運行的所有組件的一款軟件——“集群操作系統”。
這個工具就是容器編排器。
我們所熟知的K8S就行當下很火的容器編排器。K8S供了這些容器的強大管理能力。而且容器和K8S都是云原生架構的核心組件。
所解決的問題
在云原生架構中，應用程序被分解為許多小的組件或服務，每個組件或服務都放置在一個獨立容器中。這些被切分后的組件或者服務就被稱為微服務。
與傳統的單體應用相比，現在一般企業動輒則擁有數十個甚至數百個服務。如果出現問題，這些服務中的每一個都需要資源、監控和修復。
如果僅針對單個服務手動完成資源分配、監控和修復是有可能的，但如果是處理多個服務時，這種情形下仍以手動方式逐一維護就顯得捉襟見肘了。
這是就需要引入集群容器編排器來管理整個集群應用。
引入云原生的意義
我們知道，K8S是名副其實的容器編排器。
K8S架構和組件工作原則利用了 “期望狀態” 。也就是說，你定義了組件的期望狀態，而?K8S?要將它們始終調整到你所期望的這個狀態。
例如，服務的10個實例在3個節點上運行，可以訪問數據庫等，K8S不斷與實際狀態進行比較。如果期望和實際狀態不匹配，K8S通過創建或銷毀對象來協調它們。如果一個容器崩潰，那么K8S就會啟動一個新容器。
總之，K8S可以將整個集群視為“一臺計算機”。它只關注環境應該是什么樣子，并為您處理具體的實現細節。
另外，開發人員可以使用這種核心控制器模式來擴展?K8S。操作員模式允許人們為自定義資源編寫自定義控制器，并將任意邏輯和自動化構建到?K8S中。
三、Coordination & Service Discovery?協調和服務發現
業務應用程序中，一般是由多個單獨的服務組合而成，這些應用之間需要很好的協作才能為用戶提供有效的價值。
為了協作，服務之間通過網絡進行通信，為了實現通信這一機制，應用之間必須首先找到對方。那服務發現組件就是來解決這一問題的。
解決的問題
我們知道，云原生架構的特點就是動態性，這也意味著云原生架構內部的服務組織形式也在不斷發生變化。
當一個容器在一個節點上崩潰時，會在另一個節點上啟動一個新容器來替換它。然后應用程序會部署在新的容器中并需要及時為外界提供服務。那在整個集群環境中，如何快速跟蹤網絡中新的服務并發現它，以便在需要時能快速訪問到這臺機器。
這個問題就需要由我們的協調和發現組件來解決。
引入云原生意義
服務發現工具通過提供一個公共場所來查找和潛在地識別單個服務來解決這個問題。解決此類問題基本上有兩種類型的工具：
1）服務發現引擎
?服務發現引起，類似與數據庫的工具，用于存儲所有服務的信息以及如何定位它們。
2）名稱解析工具
名稱解析工具，主要接收服務位置請求并返回網絡地址信息的一種工具。
在K8S中，為了使 pod可訪問，引入了一個名為“服務”的新抽象層。服務為一組動態變化的 Pod 提供一個穩定的地址。這個“服務”通常是指放置在容器和 pod 中的服務。它是實際應用程序中具有特定功能的應用程序組件或微服務，比如手機上安裝的人臉識別應用等。
隨著分布式系統變得越來越普遍，傳統的 DNS 流程和傳統的負載均衡器往往無法跟上不斷變化的端點信息。為了彌補這些缺點，服務發現工具可以處理各個應用程序實例的快速注冊和注銷。
分布式計算中很重要的一點就是各個服務之間的協同以及服務發現，從Zookeeper到近年來在很多互聯網廠商和應用中流行的Consul，都可以用于分布式服務的發現和配置，Kubernetes默認使用的則是CoreOS旗下的Etcd。
四、Remote Procedure Call??遠程過程調用RPC
遠程過程調用 (RPC) 是一種使應用程序能夠相互通信的特殊技術。這是構建應用程序通信的一種方式。
解決的問題
現代應用程序由許多單獨的服務組成，這些服務必須進行通信才能進行協作。RPC 是處理應用程序之間通信的一種選擇。
引入云原生的意義
RPC 提供了一種緊密耦合的方式來處理服務之間的通信， 它可以支持多種編程語言支持，比如C++，C＃，Java，JavaScript，Python等。
RPC有很多潛在的好處：它使編碼連接更容易，它允許非常有效地使用網絡層和服務之間結構良好的通信。RPC 還因創建脆弱的連接點和迫使用戶對多個服務進行協調升級而受到批評。gRPC 是一種特別流行的 RPC 實現，已被 CNCF 采用。
微服務間進行通信，通常有兩種方式，其一為HTTP REST-JSON的方式，另一種為RPC方式，相比起來RPC方式效率更高。常用的包括 Google開源的 GRPC 、Apache旗下的Thrift 框架、Netflix 開源的自帶負載均衡的 Ribbon 和 Avra 數據序列化框架。
五、Service Proxy?服務代理
服務代理是一種工具，類似于中間人的身份。它的主要作用就行間攔截進出服務流量，收集有關網絡流量的信息，并對其應用請求做一些特殊邏輯處理，最后將該流量轉發到其他服務上。
這個工具既有點類似于我們日常所說的負載平衡器一樣簡單，也可以像與處理所有互連代理網格一樣復雜。
雖然服務代理本身很有用，特別是在將流量從更廣泛的網絡驅動到K8S集群時，服務代理也是其他系統的構建模塊，例如后面講提到的API網關和服務網格。
解決的問題
應用程序應以受控方式發送和接收網絡流量。為了跟蹤流量并可能對其進行轉換或重定向，我們需要收集數據。傳統上，支持數據收集和網絡流量管理的代碼嵌入在每個應用程序中。
而服務代理，則是將此功能“外部化”。它不再必須存在于應用程序中。相反，它嵌入在應用程序運行所運行的平臺層。
這樣便能允許開發人員，完全專注于編寫應用程序代碼，同時，允許處理流量的通用任務由平臺團隊統一管理。在應用領域層面分工更加明確。
引入云原生的意義
代理充當用戶和服務之間或不同服務之間的守護者。
憑借這種獨特的定位，代理服務可以快速洞察出正在發生的通信類型，然后確定將特定請求發送到那個服務上，或者完全拒絕某個請求等。
代理服務主要收集一些關鍵數據，比如管理路由（在服務之間平均分配流量或在某些服務出現故障時重新路由）、加密連接和緩存內容（減少資源消耗）等。
六、API Gateway?API網關
網關屬于一種軟件術語，如果兩個相互獨立的局域網之間通過路由器進行通信，那么中間的這個路由層就被稱之為“網關”。
任何一個應用系統如果需要被其他系統調用，就需要暴露 API，這些 API 代表著一個一個的功能點。
如果兩個系統中間通信，在系統之間加上一個中介者協助 API 的調用，這個中介者就是 API 網關。
API 網關允許組織將關鍵功能，比如授權或限制應用程序之間的請求數量等移動到集中管理的位置。它還用作外部API使用者的通用接口。
解決的問題
雖然大多數容器和核心應用程序都有一個 API，但 API 網關不僅僅是一個 API。API 網關簡化了組織管理和應用規則到所有交互的方式。
API 網關允許開發人員編寫和維護更少的自定義代碼。也能夠查看和控制應用程序用戶與應用程序本身之間的交互等。
引入云原生的意義
API 網關位于用戶和應用程序之間。它充當中間人的角色，從用戶那里獲取請求并將它們轉發到適當的服務。但在發出請求之前，它會評估是否允許用戶做他們想做的事情，并記錄有關誰提出請求以及他們提出了多少請求的詳細信息。
簡而言之，API 網關為應用程序用戶提供了一個帶有通用用戶界面的單一入口點。它還能夠將在應用程序中實現的任務移交給網關，從而節省開發人員的時間和金錢。
七、Service Mesh?服務網格
網格服務定義了一組接口，這些接口的定義明確并遵守特定的慣例，用于解決：服務器發現、動態服務創建、服務生命周期管理、通知等與服務生命周期有關的問題。
服務網格主要用于管理服務之間的流量通信。它們使平臺團隊能夠在集群內運行的所有服務中統一添加可靠性、可觀察性和安全性功能，而無需更改任何代碼。
本質上，服務網格是一個基礎設施層，它通過向服務代理網絡（網格）提供命令和控制信號來管理服務間通信。它的強大之處在于它能夠提供關鍵系統功能而無需修改應用程序。
與K8S一起，服務網格已成為云原生堆棧中一些最關鍵的基礎設施組件。
解決的問題
在云原生世界中，我們正在處理多個需要通信的服務。這意味著更多的流量在本質上不可靠且通常很慢的網絡上來回傳輸。為了應對這一系列新挑戰，工程師必須實施額外的功能。在服務網格之前，必須將該功能編碼到每個應用程序中。這種自定義代碼經常成為應用架構變形或代碼難以維護的根源，并為失敗或漏洞提供了新的可能途徑。
引入云原生的意義
服務網格在平臺層上的所有服務中統一添加可靠性、可觀察性和安全性功能，而無需觸及應用程序代碼。它們與任何編程語言兼容，允許開發團隊專注于編寫業務邏輯。
服務網格通過服務代理將集群上運行的所有服務綁定在一起，創建服務網格，因此服務網格。這些通過服務網格控制平面進行管理和控制。服務網格允許平臺所有者在應用程序上執行常見操作或收集數據，而無需開發人員編寫自定義邏輯。
服務網格提供了許多有用的功能，包括顯示詳細指標的能力、加密所有流量、限制哪些服務授權的操作、為其他工具提供額外的插件等等。有關更多詳細信息，請查看 服務網格接口規范。
總結：本節內容主要介紹了容器的編排和管理的概念。從中我們也了解到了K8S與容器在整個云原生架構中的重要性。初次之外，也了解了API網格、服務代理以及服務網格這些基礎層工具來如何解耦及高效管理我們的應用和請求流量。
下一節：云原生的運行環境。
關注公眾號?+ 輸入[面試題] + 免費領取面試資料(面試大綱+面試答案)!??
總結
- 上一篇： Mac版R语言（四）：pacman包——
- 下一篇： mac上使用多个版本的EasyConne