近年来，云原生计算基金会(CNCF)在业界取得了不小的成绩。CNCF汇集了来自整个行业的供应商和开发人员，以培育云原生应用程序的增长。除了孵化项目和促进聚会之外，CNCF还帮助教育世界了解云原生。他们最具影响力的贡献之一是他们的交互式云原生景观。

由于云原生世界中的所有细微差别和差异，景观可能难以驾驭。为了让事情变得更简单，我们在之前的帖子中提供了DevOps云原生工具格局的完整概述。在这篇文章中，我们将仔细研究编排和管理子类别之一：协调和服务发现。

云原生协调和服务发现平台的简单定义是“支持自动、低延迟和分布式服务发现和健康检查的平台”。通常，这些服务使用DNS、gRPC和HTTP等协议来创建服务注册表并启用微服务之间的协调。

对云原生协调和服务发现的需求

云原生应用程序必须是分布式和松散耦合的，以保持可扩展性和弹性。微服务可帮助开发人员实现这些目标，但它们在服务发现方面带来了独特的挑战。

当您考虑微服务架构的工作方式时，您就会开始看到这个问题。容器不断地上下旋转以满足动态需求。IP地址和主机名不断变化。那么客户端如何在需要时连接到服务或API网关呢？同样，如何确保流量仅路由到健康节点？

手动配置和检查是旧客户端/服务器范例的一个选项，但对于云原生来说是不切实际的。因此，开发人员需要一种自动、可扩展和分布式的替代方案。

我们上面对云原生协调和服务发现服务的描述假设云原生应用程序需要不同的方法。那么，让我们仔细看看发生了什么变化以及为什么会这样。我们将从OpenStack基金会的“微服务架构中的服务发现和注册——什么、为什么以及如何？”中借鉴一下。本节中的介绍。如果您有40分钟的空闲时间，我们建议您在此处查看完整的演示文稿。

早期，Web应用程序驻留在单个服务器上。因此，应用程序前端和应用程序后端之间存在一对一的关系。使用这种单体架构，您可以使用单个主机名发现服务。也就是说，将IP转换为主机名的DNS是服务发现的唯一要求。

随着时间的推移，应用程序演变为分布在多个服务器上。由于这种额外的复杂性，您需要添加负载平衡器和潜在的虚拟IP地址以促进服务发现。

Web应用程序的下一个演变是3层应用程序。Web层、应用程序层和数据库层都结合在一起以实现应用程序交付。现在，每一层都可以独立向上或向下扩展。除了DNS和负载平衡之外，您还需要运行健康检查以确保您只将流量发送到正常运行的服务器。

我们的下一个应用程序交付迭代是虚拟化。虚拟服务器的创建和销毁在几分钟内发生。因此，手动配置负载均衡器和健康检查是不切实际的。当应用程序处于这种复杂程度时，您需要开始自动化。

使用云原生微服务架构，您会看到更多的复杂性和速度。容器专用于离散服务。容器的创建和销毁可以在几毫秒内发生。有了这种范例，支持自动、超可扩展、低延迟服务发现和健康检查的平台是必不可少的。

云原生协调和服务发现的好处

鉴于微服务架构的需求，您大概可以猜到云原生协调和服务发现平台带来的好处。这些服务可帮助您摆脱手动流程并充分利用云原生。他们的好处包括：

流行的云原生协调和服务发现服务

现在您了解了云原生协调和服务发现的基础知识，让我们来看看这个类别中的服务。协调和服务发现类别中的项目使微服务之间的自动服务发现和通信成为可能。

与云原生世界中的大多数事物一样，在从此处列出的不同服务中进行选择时，您需要考虑您的用例。在某些情况下，例如etcd和CoreDNS，将这些服务结合使用是很常见的。在其他情况下，您可能需要一个根本不构成CNCF景观的解决方案，例如Consul。

etcd是一种流行的分布式系统键值存储。它主要用Go语言编写，由CNCF孵化。您可以将etcd用于像将功能标志存储为键值对这样简单的用例，或者像实现数据库领导者选举一样高级的用例。

如果您想了解etcd在实践中的工作原理，KunalPariani在这篇博客文章中介绍了如何使用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上ChrisO'Haver的在Kubernetes集群文档中扩展CoreDNS。

Nacos是阿里巴巴流行的服务发现、配置和管理平台。该项目在中国拥有庞大的用户群，在GitHub上拥有超过9000颗星。Nacos为您提供基于RPC和基于DNS的服务发现。该平台还支持健康检查，让您避免将流量发送到不健康的主机。此外，Nacos支持动态配置服务，让您更轻松地实现无状态服务。

如需深入了解Nacos，请查看阿里巴巴技术团队的Nacos简介：阿里巴巴针对云原生开发媒介的开源解决方案一文。在那里，您将看到Nacos如何使您能够用更动态和可扩展的方法取代传统的配置方法，例如硬编码、配置文件和数据库。

Euerka是Netflix构建的用于负载平衡和故障转移的服务注册中心。有趣的是，你会发现Eureka2.0已经停产了，但是1.x项目仍然活跃。

Euerka的用例很简单。云原生应用程序需要自动临时创建和销毁容器和服务器。它使得依赖众所周知的IP和FQDN来进行服务发现和负载平衡变得不切实际。由于其业务的超大规模性质，Netflix需要一个可以动态注册和注销服务器的中间层负载均衡器。Eureka填补了这个空白。

说到这里，你可能会问：“到底什么是中间层？”。简而言之，中间层是指给定的AWS区域。正如您所期望的那样，根据该定义，Eureka的主要用例是在AWS中。考虑到云原生对平台独立性的强调，您可能会觉得这令人惊讶，但当您考虑Netflix的应用程序交付模型时，这是有道理的。

我们希望您喜欢我们对CNCF云原生景观的协调和服务发现类别的解释。您现在应该对与协调和服务发现相关的工具、协议和技术有一个很好的理解。通过这种理解，您可以决定哪些服务最适合您，并构建更具弹性的可扩展云原生应用程序。