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

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

云原生協調和服務發現簡介

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

對云原生協調和服務發現的需求

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

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

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

為什么云原生服務發現不同

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

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

隨著時間的推移，應用程序演變為分布在多個服務器上。由于這種額外的復雜性，您需要添加負載平衡器和潛在的虛擬 IP 地址以促進服務發現。

Web 應用程序的下一個演變是 3 層應用程序。Web 層、應用程序層和數據庫層都結合在一起以實現應用程序交付。現在，每一層都可以獨立向上或向下擴展。除了 DNS 和負載平衡之外，您還需要運行健康檢查以確保您只將流量發送到正常運行的服務器。

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

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

云原生協調和服務發現的好處

鑒于微服務架構的需求，您大概可以猜到云原生協調和服務發現平臺帶來的好處。這些服務可幫助您擺脫手動流程并充分利用云原生。他們的好處包括：

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

流行的云原生協調和服務發現服務

現在您了解了云原生協調和服務發現的基礎知識，讓我們來看看這個類別中的服務。協調和服務發現類別中的項目使微服務之間的自動服務發現和通信成為可能。

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

等等

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

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

阿帕奇動物園管理員

Apache 在云原生領域是一個大牌。ZooKeeper是他們提供大規模可靠服務協調和同步的服務。ZooKeeper 使用稱為znode的數據寄存器來協調進程之間的數據共享。Znodes 使用分層命名空間結構，ZooKeeper 以低延遲和可擴展的方式為客戶端提供對 znodes 的訪問。

ZooKeeper 在可擴展性方面享有盛譽，并被許多企業和開源項目使用。例如，Box 使用 ZooKeeper 作為服務發現和服務協調解決方案。此外，雅虎！使用 ZooKeeper 進行領導人選舉、配置管理等。

核心域名系統

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

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

納科斯

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

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

Netflix尤爾卡

Euerka是 Netflix 構建的用于負載平衡和故障轉移的服務注冊中心。有趣的是，你會發現Eureka 2.0 已經停產了，但是 1.x 項目仍然活躍。

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

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

最后的想法

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