云原生協(xié)調(diào)和服務發(fā)現(xiàn)的簡介和好處

      近年來,云原生計算基金會 (CNCF)在業(yè)界取得了不小的成績。CNCF 匯集了來自整個行業(yè)的供應商和開發(fā)人員,以培育云原生應用程序的增長。除了孵化項目和促進聚會之外,CNCF 還幫助教育世界了解云原生。他們最具影響力的貢獻之一是他們的交互式云原生景觀。

      云原生協(xié)調(diào)和服務發(fā)現(xiàn)的簡介和好處-南華中天

      由于云原生世界中的所有細微差別和差異,景觀可能難以駕馭。為了讓事情變得更簡單,我們在之前的帖子中提供了DevOps 云原生工具格局的完整概述。在這篇文章中,我們將仔細研究編排和管理子類別之一:協(xié)調(diào)和服務發(fā)現(xiàn)。

      云原生協(xié)調(diào)和服務發(fā)現(xiàn)簡介

      云原生協(xié)調(diào)和服務發(fā)現(xiàn)平臺的簡單定義是“支持自動、低延遲和分布式服務發(fā)現(xiàn)和健康檢查的平臺”。通常,這些服務使用 DNS、gRPC 和 HTTP 等協(xié)議來創(chuàng)建服務注冊表并啟用微服務之間的協(xié)調(diào)。

      對云原生協(xié)調(diào)和服務發(fā)現(xiàn)的需求

      云原生應用程序必須是分布式和松散耦合的,以保持可擴展性和彈性。微服務可幫助開發(fā)人員實現(xiàn)這些目標,但它們在服務發(fā)現(xiàn)方面帶來了獨特的挑戰(zhàn)。

      當您考慮微服務架構(gòu)的工作方式時,您就會開始看到這個問題。容器不斷地上下旋轉(zhuǎn)以滿足動態(tài)需求。IP 地址和主機名不斷變化。那么客戶端如何在需要時連接到服務或 API 網(wǎng)關呢?同樣,如何確保流量僅路由到健康節(jié)點?

      手動配置和檢查是舊客戶端/服務器范例的一個選項,但對于云原生來說是不切實際的。因此,開發(fā)人員需要一種自動、可擴展和分布式的替代方案。

      云原生協(xié)調(diào)和服務發(fā)現(xiàn)的簡介和好處-南華中天

      為什么云原生服務發(fā)現(xiàn)不同

      我們上面對云原生協(xié)調(diào)和服務發(fā)現(xiàn)服務的描述假設云原生應用程序需要不同的方法。那么,讓我們仔細看看發(fā)生了什么變化以及為什么會這樣。我們將從 OpenStack 基金會的“微服務架構(gòu)中的服務發(fā)現(xiàn)和注冊——什么、為什么以及如何?”中借鑒一下。本節(jié)中的介紹。如果您有 40 分鐘的空閑時間,我們建議您在此處查看完整的演示文稿。

      早期,Web 應用程序駐留在單個服務器上。因此,應用程序前端和應用程序后端之間存在一對一的關系。使用這種單體架構(gòu),您可以使用單個主機名發(fā)現(xiàn)服務。也就是說,將 IP 轉(zhuǎn)換為主機名的 DNS 是服務發(fā)現(xiàn)的唯一要求。

      隨著時間的推移,應用程序演變?yōu)榉植荚诙鄠€服務器上。由于這種額外的復雜性,您需要添加負載平衡器和潛在的虛擬 IP 地址以促進服務發(fā)現(xiàn)。

      Web 應用程序的下一個演變是 3 層應用程序。Web 層、應用程序?qū)雍蛿?shù)據(jù)庫層都結(jié)合在一起以實現(xiàn)應用程序交付。現(xiàn)在,每一層都可以獨立向上或向下擴展。除了 DNS 和負載平衡之外,您還需要運行健康檢查以確保您只將流量發(fā)送到正常運行的服務器。

      我們的下一個應用程序交付迭代是虛擬化。虛擬服務器的創(chuàng)建和銷毀在幾分鐘內(nèi)發(fā)生。因此,手動配置負載均衡器和健康檢查是不切實際的。當應用程序處于這種復雜程度時,您需要開始自動化。

      最后,使用云原生微服務架構(gòu),您會看到更多的復雜性和速度。容器專用于離散服務。容器的創(chuàng)建和銷毀可以在幾毫秒內(nèi)發(fā)生。有了這種范例,支持自動、超可擴展、低延遲服務發(fā)現(xiàn)和健康檢查的平臺是必不可少的。

      云原生協(xié)調(diào)和服務發(fā)現(xiàn)的簡介和好處-南華中天

      云原生協(xié)調(diào)和服務發(fā)現(xiàn)的好處

      鑒于微服務架構(gòu)的需求,您大概可以猜到云原生協(xié)調(diào)和服務發(fā)現(xiàn)平臺帶來的好處。這些服務可幫助您擺脫手動流程并充分利用云原生。他們的好處包括:

      • 性能——速度是云原生應用程序的一個重要屬性。當您使用專為分布式服務發(fā)現(xiàn)構(gòu)建的平臺時,您可以獲得顯著的性能提升。
      • 簡單的協(xié)調(diào)和健康檢查——使用舊的范例,您通常需要手動配置服務發(fā)現(xiàn)和負載平衡。使用云原生平臺,您可以自動化該過程。
      • 可擴展性——作為自動化服務發(fā)現(xiàn)過程的結(jié)果,您釋放了云原生應用程序超可擴展性的潛力。有關優(yōu)勢的示例,請查看 Jeremy Eder在 etcd3 遷移后的四個可擴展性和性能勝利。

      流行的云原生協(xié)調(diào)和服務發(fā)現(xiàn)服務

      現(xiàn)在您了解了云原生協(xié)調(diào)和服務發(fā)現(xiàn)的基礎知識,讓我們來看看這個類別中的服務。協(xié)調(diào)和服務發(fā)現(xiàn)類別中的項目使微服務之間的自動服務發(fā)現(xiàn)和通信成為可能。

      與云原生世界中的大多數(shù)事物一樣,在從此處列出的不同服務中進行選擇時,您需要考慮您的用例。在某些情況下,例如 etcd 和 CoreDNS,將這些服務結(jié)合使用是很常見的。在其他情況下,您可能需要一個根本不構(gòu)成 CNCF 景觀的解決方案,例如Consul。

      等等

      etcd是一種流行的分布式系統(tǒng)鍵值存儲。它主要用Go語言編寫,由 CNCF 孵化。您可以將 etcd 用于像將功能標志存儲為鍵值對這樣簡單的用例,或者像實現(xiàn)數(shù)據(jù)庫領導者選舉一樣高級的用例。

      如果您想了解 etcd 在實踐中的工作原理,Kunal Pariani 在這篇博客文章中介紹了如何使用 NGINX 和 etcd 進行服務發(fā)現(xiàn)。

      阿帕奇動物園管理員

      Apache 在云原生領域是一個大牌。ZooKeeper是他們提供大規(guī)模可靠服務協(xié)調(diào)和同步的服務。ZooKeeper 使用稱為znode的數(shù)據(jù)寄存器來協(xié)調(diào)進程之間的數(shù)據(jù)共享。Znodes 使用分層命名空間結(jié)構(gòu),ZooKeeper 以低延遲和可擴展的方式為客戶端提供對 znodes 的訪問。

      ZooKeeper 在可擴展性方面享有盛譽,并被許多企業(yè)和開源項目使用。例如,Box 使用 ZooKeeper 作為服務發(fā)現(xiàn)和服務協(xié)調(diào)解決方案。此外,雅虎!使用 ZooKeeper 進行領導人選舉、配置管理等。

      核心域名系統(tǒng)

      CoreDNS是一個用 Go 編寫的 DNS 服務器,強調(diào)簡單性。它也是一個CNCF畢業(yè)項目。速度和靈活性是 CoreDNS 的兩個核心租戶。由于強調(diào)靈活性,CoreDNS 提供了各種各樣的插件。事實上,將插件鏈接在一起的能力是 CoreDNS 的獨特價值主張之一。插件的使用有助于保持 CoreDNS 的輕量級和可擴展性,并使您能夠根據(jù)自己的需要對其進行優(yōu)化。CoreDNS?Kubernetes和etcd插件是兩個最流行的服務發(fā)現(xiàn)插件。

      有關如何使用 Kubernetes 實施 CoreDNS 的實際示例,請查看 GitHub 上 Chris O'Haver 的在 Kubernetes 集群文檔中擴展 CoreDNS。

      納科斯

      Nacos是阿里巴巴流行的服務發(fā)現(xiàn)、配置和管理平臺。該項目在中國擁有龐大的用戶群,在 GitHub 上擁有超過 9000 顆星。Nacos 為您提供基于 RPC 和基于 DNS 的服務發(fā)現(xiàn)。該平臺還支持健康檢查,讓您避免將流量發(fā)送到不健康的主機。此外,Nacos 支持動態(tài)配置服務,讓您更輕松地實現(xiàn)無狀態(tài)服務。

      如需深入了解 Nacos,請查看阿里巴巴技術(shù)團隊的Nacos 簡介:阿里巴巴針對云原生開發(fā)媒介的開源解決方案一文。在那里,您將看到 Nacos 如何使您能夠用更動態(tài)和可擴展的方法取代傳統(tǒng)的配置方法,例如硬編碼、配置文件和數(shù)據(jù)庫。

      Netflix尤爾卡

      Euerka是 Netflix 構(gòu)建的用于負載平衡和故障轉(zhuǎn)移的服務注冊中心。有趣的是,你會發(fā)現(xiàn)Eureka 2.0 已經(jīng)停產(chǎn)了,但是 1.x 項目仍然活躍。

      Euerka的用例很簡單。云原生應用程序需要自動臨時創(chuàng)建和銷毀容器和服務器。它使得依賴眾所周知的 IP 和 FQDN 來進行服務發(fā)現(xiàn)和負載平衡變得不切實際。由于其業(yè)務的超大規(guī)模性質(zhì),Netflix 需要一個可以動態(tài)注冊和注銷服務器的中間層負載均衡器。Eureka 填補了這個空白。

      說到這里,你可能會問:“到底什么是中間層?”。簡而言之,中間層是指給定的 AWS 區(qū)域。正如您所期望的那樣,根據(jù)該定義,Eureka 的主要用例是在 AWS 中。考慮到云原生對平臺獨立性的強調(diào),您可能會覺得這令人驚訝,但當您考慮 Netflix 的應用程序交付模型時,這是有道理的。

      最后的想法

      我們希望您喜歡我們對 CNCF 云原生景觀的協(xié)調(diào)和服務發(fā)現(xiàn)類別的解釋。您現(xiàn)在應該對與協(xié)調(diào)和服務發(fā)現(xiàn)相關的工具、協(xié)議和技術(shù)有一個很好的理解。通過這種理解,您可以決定哪些服務最適合您,并構(gòu)建更具彈性的可擴展云原生應用程序。