云原生协调和服务发现速成班

近年来，云原生计算基金会 (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 云原生景观的协调和服务发现类别的解释。您现在应该对与协调和服务发现相关的工具、协议和技术有一个很好的理解。通过这种理解，您可以决定哪些服务最适合您，并构建更具弹性的可扩展云原生应用程序。