近年來，云原生計算基金會 (CNCF)在業(yè)界取得了不小的成績。CNCF 匯集了來自整個行業(yè)的供應(yīng)商和開發(fā)人員，以培育云原生應(yīng)用程序的增長。除了孵化項目和促進聚會之外，CNCF 還幫助教育世界了解云原生。他們最具影響力的貢獻之一是他們的交互式云原生景觀。
由于云原生世界中的所有細(xì)微差別和差異，景觀可能難以駕馭。為了讓事情變得更簡單，我們在之前的帖子中提供了DevOps 云原生工具格局的完整概述。在這篇文章中，我們將仔細(xì)研究編排和管理子類別之一：協(xié)調(diào)和服務(wù)發(fā)現(xiàn)。
云原生協(xié)調(diào)和服務(wù)發(fā)現(xiàn)簡介
云原生協(xié)調(diào)和服務(wù)發(fā)現(xiàn)平臺的簡單定義是“支持自動、低延遲和分布式服務(wù)發(fā)現(xiàn)和健康檢查的平臺”。通常，這些服務(wù)使用 DNS、gRPC 和 HTTP 等協(xié)議來創(chuàng)建服務(wù)注冊表并啟用微服務(wù)之間的協(xié)調(diào)。
對云原生協(xié)調(diào)和服務(wù)發(fā)現(xiàn)的需求
云原生應(yīng)用程序必須是分布式和松散耦合的，以保持可擴展性和彈性。微服務(wù)可幫助開發(fā)人員實現(xiàn)這些目標(biāo)，但它們在服務(wù)發(fā)現(xiàn)方面帶來了獨特的挑戰(zhàn)。
當(dāng)您考慮微服務(wù)架構(gòu)的工作方式時，您就會開始看到這個問題。容器不斷地上下旋轉(zhuǎn)以滿足動態(tài)需求。IP 地址和主機名不斷變化。那么客戶端如何在需要時連接到服務(wù)或 API 網(wǎng)關(guān)呢？同樣，如何確保流量僅路由到健康節(jié)點？
手動配置和檢查是舊客戶端/服務(wù)器范例的一個選項，但對于云原生來說是不切實際的。因此，開發(fā)人員需要一種自動、可擴展和分布式的替代方案。
為什么云原生服務(wù)發(fā)現(xiàn)不同
我們上面對云原生協(xié)調(diào)和服務(wù)發(fā)現(xiàn)服務(wù)的描述假設(shè)云原生應(yīng)用程序需要不同的方法。那么，讓我們仔細(xì)看看發(fā)生了什么變化以及為什么會這樣。我們將從 OpenStack 基金會的“微服務(wù)架構(gòu)中的服務(wù)發(fā)現(xiàn)和注冊——什么、為什么以及如何？”中借鑒一下。本節(jié)中的介紹。如果您有 40 分鐘的空閑時間，我們建議您在此處查看完整的演示文稿。
早期，Web 應(yīng)用程序駐留在單個服務(wù)器上。因此，應(yīng)用程序前端和應(yīng)用程序后端之間存在一對一的關(guān)系。使用這種單體架構(gòu)，您可以使用單個主機名發(fā)現(xiàn)服務(wù)。也就是說，將 IP 轉(zhuǎn)換為主機名的 DNS 是服務(wù)發(fā)現(xiàn)的唯一要求。
隨著時間的推移，應(yīng)用程序演變?yōu)榉植荚诙鄠€服務(wù)器上。由于這種額外的復(fù)雜性，您需要添加負(fù)載平衡器和潛在的虛擬 IP 地址以促進服務(wù)發(fā)現(xiàn)。
Web 應(yīng)用程序的下一個演變是 3 層應(yīng)用程序。Web 層、應(yīng)用程序?qū)雍蛿?shù)據(jù)庫層都結(jié)合在一起以實現(xiàn)應(yīng)用程序交付。現(xiàn)在，每一層都可以獨立向上或向下擴展。除了 DNS 和負(fù)載平衡之外，您還需要運行健康檢查以確保您只將流量發(fā)送到正常運行的服務(wù)器。
我們的下一個應(yīng)用程序交付迭代是虛擬化。虛擬服務(wù)器的創(chuàng)建和銷毀在幾分鐘內(nèi)發(fā)生。因此，手動配置負(fù)載均衡器和健康檢查是不切實際的。當(dāng)應(yīng)用程序處于這種復(fù)雜程度時，您需要開始自動化。
最后，使用云原生微服務(wù)架構(gòu)，您會看到更多的復(fù)雜性和速度。容器專用于離散服務(wù)。容器的創(chuàng)建和銷毀可以在幾毫秒內(nèi)發(fā)生。有了這種范例，支持自動、超可擴展、低延遲服務(wù)發(fā)現(xiàn)和健康檢查的平臺是必不可少的。
云原生協(xié)調(diào)和服務(wù)發(fā)現(xiàn)的好處
鑒于微服務(wù)架構(gòu)的需求，您大概可以猜到云原生協(xié)調(diào)和服務(wù)發(fā)現(xiàn)平臺帶來的好處。這些服務(wù)可幫助您擺脫手動流程并充分利用云原生。他們的好處包括：
- 性能——速度是云原生應(yīng)用程序的一個重要屬性。當(dāng)您使用專為分布式服務(wù)發(fā)現(xiàn)構(gòu)建的平臺時，您可以獲得顯著的性能提升。
- 簡單的協(xié)調(diào)和健康檢查——使用舊的范例，您通常需要手動配置服務(wù)發(fā)現(xiàn)和負(fù)載平衡。使用云原生平臺，您可以自動化該過程。
- 可擴展性——作為自動化服務(wù)發(fā)現(xiàn)過程的結(jié)果，您釋放了云原生應(yīng)用程序超可擴展性的潛力。有關(guān)優(yōu)勢的示例，請查看 Jeremy Eder在 etcd3 遷移后的四個可擴展性和性能勝利。
流行的云原生協(xié)調(diào)和服務(wù)發(fā)現(xiàn)服務(wù)
現(xiàn)在您了解了云原生協(xié)調(diào)和服務(wù)發(fā)現(xiàn)的基礎(chǔ)知識，讓我們來看看這個類別中的服務(wù)。協(xié)調(diào)和服務(wù)發(fā)現(xiàn)類別中的項目使微服務(wù)之間的自動服務(wù)發(fā)現(xiàn)和通信成為可能。
與云原生世界中的大多數(shù)事物一樣，在從此處列出的不同服務(wù)中進行選擇時，您需要考慮您的用例。在某些情況下，例如 etcd 和 CoreDNS，將這些服務(wù)結(jié)合使用是很常見的。在其他情況下，您可能需要一個根本不構(gòu)成 CNCF 景觀的解決方案，例如Consul。
等等
etcd是一種流行的分布式系統(tǒng)鍵值存儲。它主要用Go語言編寫，由 CNCF 孵化。您可以將 etcd 用于像將功能標(biāo)志存儲為鍵值對這樣簡單的用例，或者像實現(xiàn)數(shù)據(jù)庫領(lǐng)導(dǎo)者選舉一樣高級的用例。
如果您想了解 etcd 在實踐中的工作原理，Kunal Pariani 在這篇博客文章中介紹了如何使用 NGINX 和 etcd 進行服務(wù)發(fā)現(xiàn)。
阿帕奇動物園管理員
Apache 在云原生領(lǐng)域是一個大牌。ZooKeeper是他們提供大規(guī)模可靠服務(wù)協(xié)調(diào)和同步的服務(wù)。ZooKeeper 使用稱為znode的數(shù)據(jù)寄存器來協(xié)調(diào)進程之間的數(shù)據(jù)共享。Znodes 使用分層命名空間結(jié)構(gòu)，ZooKeeper 以低延遲和可擴展的方式為客戶端提供對 znodes 的訪問。
ZooKeeper 在可擴展性方面享有盛譽，并被許多企業(yè)和開源項目使用。例如，Box 使用 ZooKeeper 作為服務(wù)發(fā)現(xiàn)和服務(wù)協(xié)調(diào)解決方案。此外，雅虎！使用 ZooKeeper 進行領(lǐng)導(dǎo)人選舉、配置管理等。
核心域名系統(tǒng)
CoreDNS是一個用 Go 編寫的 DNS 服務(wù)器，強調(diào)簡單性。它也是一個CNCF畢業(yè)項目。速度和靈活性是 CoreDNS 的兩個核心租戶。由于強調(diào)靈活性，CoreDNS 提供了各種各樣的插件。事實上，將插件鏈接在一起的能力是 CoreDNS 的獨特價值主張之一。插件的使用有助于保持 CoreDNS 的輕量級和可擴展性，并使您能夠根據(jù)自己的需要對其進行優(yōu)化。CoreDNS Kubernetes和etcd插件是兩個最流行的服務(wù)發(fā)現(xiàn)插件。
有關(guān)如何使用 Kubernetes 實施 CoreDNS 的實際示例，請查看 GitHub 上 Chris O'Haver 的在 Kubernetes 集群文檔中擴展 CoreDNS。
納科斯
Nacos是阿里巴巴流行的服務(wù)發(fā)現(xiàn)、配置和管理平臺。該項目在中國擁有龐大的用戶群，在 GitHub 上擁有超過 9000 顆星。Nacos 為您提供基于 RPC 和基于 DNS 的服務(wù)發(fā)現(xiàn)。該平臺還支持健康檢查，讓您避免將流量發(fā)送到不健康的主機。此外，Nacos 支持動態(tài)配置服務(wù)，讓您更輕松地實現(xiàn)無狀態(tài)服務(wù)。
如需深入了解 Nacos，請查看阿里巴巴技術(shù)團隊的Nacos 簡介：阿里巴巴針對云原生開發(fā)媒介的開源解決方案一文。在那里，您將看到 Nacos 如何使您能夠用更動態(tài)和可擴展的方法取代傳統(tǒng)的配置方法，例如硬編碼、配置文件和數(shù)據(jù)庫。
Netflix尤爾卡
Euerka是 Netflix 構(gòu)建的用于負(fù)載平衡和故障轉(zhuǎn)移的服務(wù)注冊中心。有趣的是，你會發(fā)現(xiàn)Eureka 2.0 已經(jīng)停產(chǎn)了，但是 1.x 項目仍然活躍。
Euerka的用例很簡單。云原生應(yīng)用程序需要自動臨時創(chuàng)建和銷毀容器和服務(wù)器。它使得依賴眾所周知的 IP 和 FQDN 來進行服務(wù)發(fā)現(xiàn)和負(fù)載平衡變得不切實際。由于其業(yè)務(wù)的超大規(guī)模性質(zhì)，Netflix 需要一個可以動態(tài)注冊和注銷服務(wù)器的中間層負(fù)載均衡器。Eureka 填補了這個空白。
說到這里，你可能會問：“到底什么是中間層？”。簡而言之，中間層是指給定的 AWS 區(qū)域。正如您所期望的那樣，根據(jù)該定義，Eureka 的主要用例是在 AWS 中。考慮到云原生對平臺獨立性的強調(diào)，您可能會覺得這令人驚訝，但當(dāng)您考慮 Netflix 的應(yīng)用程序交付模型時，這是有道理的。
最后的想法
我們希望您喜歡我們對 CNCF 云原生景觀的協(xié)調(diào)和服務(wù)發(fā)現(xiàn)類別的解釋。您現(xiàn)在應(yīng)該對與協(xié)調(diào)和服務(wù)發(fā)現(xiàn)相關(guān)的工具、協(xié)議和技術(shù)有一個很好的理解。通過這種理解，您可以決定哪些服務(wù)最適合您，并構(gòu)建更具彈性的可擴展云原生應(yīng)用程序。
網(wǎng)站資訊
解決方案
關(guān)于我們
