第三方注提不了现 阿里云开发者社区用户服务协议

服务发现

为何使用服务发现

我们假设您正在编写某些代码，这些代码调用了有 REST API 或 API 的服务。为了发送一个请求，您的代码需要知道服务实例的网络位置（ IP 地址与端口）。在运行于物理硬件上的传统应用中，服务实例的网络位置是相对静态的。例如，您的代码可以从偶尔更新的配置文件中读取网络位置。

然而，在现代基于云的微服务应用中，这是一个更难解决的问题，如图 4-1 所示。

服务实例具有动态分配的网络位置。此外，由于自动扩缩、故障与升级，整组服务实例会动态变更。因此，您的客户端代码需要使用更精确的服务发现机制。

有两种主要的服务发现模式：客户端发现（-side ）与服务端发现（-side ）。让我们先来看看客户端发现。

客户端发现模式

当使用客户端发现模式时，客户端负责确定可用服务实例的网络位置和请求负载均衡。客户端查询服务注册中心（ ），它是可用服务实例的数据库。之后，客户端利用负载均衡算法选择一个可用的服务实例并发出请求。

图 4-2 展示了该模式的结构

服务实例的网络位置在服务注册中心启动时被注册。当实例终止时，它将从服务注册中心中移除。通常使用心跳机制周期性地刷新服务实例的注册信息。

OSS 提供了一个很好的客户端发现模式示例。 是一个服务注册中心，它提供了一个用于管理服务实例注册和查询可用实例的 REST API。 是一个 IPC 客户端，可与 一起使用，用于在可用服务实例之间使请求负载均衡。

客户端发现模式存在各种优点与缺点。该模式相对比较简单，除了服务注册中心，没有其他移动部件。此外，由于客户端能发现可用的服务实例，因此可以实现智能的，特定于应用程序的负载均衡决策，比如使用一致性哈希。该模式的一个重要缺点是它将客户端与服务注册中心耦合在一起。您必须为服务客户端使用的每种编程语言和框架实现客户端服务发现逻辑。

现在我们已经了解了客户端发现，接下来让我们看看服务端发现。

服务端发现模式

服务发现的另一种方式是服务端发现模式。图 4-3 展示了该模式的结构：

AWS Load （ELB）是一个服务端发现路由示例。ELB 通常用于负载均衡来自互联网的外部流量。然而，您还可以使用 ELB 来负载均衡虚拟私有云（VPC）内部的流量。客户端通过 ELB 使用其 DNS 名称来发送请求（HTTP 或 TCP）。ELB 负载均衡一组已注册的 Cloud（EC2）实例或 EC2 （ECS）容器之间的流量。这里没有单独可见的服务注册中心。相反，EC2 实例与 ECS 容器由 ELB 本身注册。

HTTP 服务器和负载均衡器（如 NGINX）也可以作为服务端发现负载均衡器。例如，使用 动态重新配置 NGINX 反向代理。 是一个工具，可以从存储在 服务注册中心中的配置数据中定期重新生成任意配置文件。每当文件被更改时，它都会运行任意的 shell 命令。在列举的博文描述的示例中， 会生成一个 nginx.conf 文件，该文件配置了反向代理，然后通过运行一个命令告知 NGINX 重新加载配置的命令。更复杂的实现可以使用其 HTTP API 或 DNS 动态重新配置 NGINX。

某些部署环境（如 和 ）在群集中的每个主机上运行着一个代理。这些代理扮演着服务端发现负载均衡器角色。为了向服务发出请求，客户端通过代理使用主机的 IP 地址和服务的分配端口来路由请求。 之后，代理将请求透明地转发到在集群中某处运行的可用服务实例。

服务端发现模式有几个优点与缺点。该模式的一大的优点是把发现的细节从客户端抽象出来。客户端只需向负载均衡器发出请求。这消除了为服务客户端使用的每种编程语言和框架都实现发现逻辑的必要性。另外，如上所述，一些部署环境免费提供此功能。然而，这种模式存在一些缺点。除非负载均衡器由部署环境提供，否则您需要引入这个高可用系统组件，并进行设置和管理。

服务注册中心

服务注册中心（ ）是服务发现的一个关键部分。它是一个包含了服务实例网络位置的数据库。服务注册中心必须是高可用和最新的。虽然客户端可以缓存从服务注册中心获得的网络位置，但该信息最终会过期，客户端将无法发现服务实例。因此，服务注册中心由使用了复制协议（ ）来维护一致性的服务器集群组成。

如之前所述， 是一个很好的服务注册中心范例。它提供了一个用于注册和查询服务实例的 REST API。服务实例使用 POST 请求注册其网络位置。它必须每隔 30 秒使用 PUT 请求来刷新其注册信息。通过使用 HTTP 请求或实例注册超时来移除注册信息。正如您所料，客户端可以使用 HTTP GET 请求来检索已注册的服务实例。

通过在每个 EC2 可用性区域（ Zone）中运行一个或多个 服务器来实现高可用。每个 服务器都运行在具有一个 IP地址的 EC2 实例上。 DNS TEXT 记录用于存储 集群配置，这是一个从可用性区域到 服务器的网络位置列表的映射。当 服务器启动时，它将会查询 DNS 以检索 群集配置，查找其对等体，并为其分配一个未使用的 IP 地址。

经过 客户端 — 服务与服务客户端 — 查询 DNS 以发现 服务器的网络位置。客户端优先使用相同可用性区域中的 服务器，如果没有可用的，则使用另一个可用性区域的 服务器。

以下列举了其他服务册中心注：

另外，如之前所述，部分系统，如 、 和 AWS，没有明确的服务注册中心。相反，服务注册中心只是基础设施的一个内置部分。

现在我们已经了解服务注册中心的概念，接下来让我们看看服务实例是如何被注册到服务注册中心。

服务注册方式

如之前所述，服务实例必须在服务注册中心中注册与注销。有几种不同的方式来处理注册和注销。一是服务实例自我注册，即自注册模式。另一个是使用其他系统组件来管理服务实例的注册，即第三方注册模式。我们先来了解自注册模式。

自注册模式

当使用自注册模式时，服务实例负责在服务注册中心注册和注销自己。此外，如果有必要，服务实例将通过发送心跳请求来防止其注册信息过期。

图 4-4 展示了该模式的结构。

该方式的一个很好的范例就是 OSS 客户端。 客户端负责处理服务实例注册与注销的所有方面。实现了包括服务发现在内的多种模式的 Cloud 项目可以轻松地使用 自动注册服务实例。您只需在 Java 类上应用 @ 注解即可

自注册模式有好有坏。一个好处是它相对简单，不需要任何其他系统组件。然而，主要缺点是它将服务实例与服务注册中心耦合。您必须为服务使用的每种编程语言和框架都实现注册代码。

将服务与服务注册中心分离的替代方法是第三方注册模式。

第三方注册模式

当使用第三方注册模式时，服务实例不再负责向服务注册中心注册自己。相反，该工作将由被称为服务注册器（ ）的另一系统组件负责。服务注册器通过轮询部署环境或订阅事件来跟踪运行实例集的变更情况。当它检测到一个新的可用服务实例时，它会将该实例注册到服务注册中心。此外，服务注册器可以注销终止的服务实例。

图 4-5 展示了该模式的结构：

开源的 项目是一个很好的服务注册器示例。它可以自动注册和注销作为 容器部署的服务实例。注册器支持多个服务注册中心，包括 etcd 和 。

另一个服务注册器例子是 Prana。其主要用于非 JVM 语言编写的服务，它是一个与服务实例并行运行的侧中应用。 Prana 使用了 来注册和注销服务实例。

服务注册器在部分部署环境中是一个内置组件。 Group 创建的 EC2 实例可以自动注册到 ELB。 服务将自动注册并提供发现。

第三方注册模式同样有好有坏。一个主要的好处是服务与服务注册中心之间解耦。您不需要为开发人员使用的每种编程语言和框架都实现服务注册逻辑。相反，仅需要在专用服务中以集中的方式处理服务实例注册。

该模式的一个缺点是，除非部署环境内置，否则您同样需要引入这样一个高可用的系统组件，并进行设置和管理。

总结

在微服务应用程序中，运行的服务实例集会动态变更。实例具有动态分配的网络位置。因此，为了让客户端向服务发出请求，它必须使用服务发现机制。

服务发现的一个关键部分是服务注册中心。服务注册中心是一个可用服务实例的数据库。服务注册中心提供了管理 API 和查询 API 的功能。服务实例通过使用管理 API 从服务注册中心注册或者注销。系统组件使用查询 API 来发现可用的服务实例。有两种主要的服务发现模式：客户端发现与服务端发现。在使用了客户端服务发现的系统中，客户端查询服务注册中心，选择一个可用实例并发出请求。在使用了服务端发现的系统中，客户端通过路由进行请求，路由将查询服务注册中心，并将请求转发到可用实例。

服务实例在服务注册中心中注册与注销有两种主要方式。一个是服务实例向服务注中心自我注册，即自注册模式。另一个是使用其他系统组件代表服务完成注册与注销，即第三方注册模式。

在某些部署环境中，您需要使用如 或 等服务注册中心来设置您自己的服务发现基础设施。在其他部署环境中，服务发现是内置的，例如， 和 ， 可以处理服务实例的注册与注销。他们还在每一个扮演服务端发现路由角色的集群主机上运行一个代理。

一个 HTTP 反向代理和负载均衡器（如 NGINX）也可以用作服务端发现负载均衡器。服务注册中心可以将路由信息推送给 NGINX，并调用一个正常的配置更新；例如，您可以使用 。 NGINX Plus 支持额外的动态重新配置机制 — 它可以使用 DNS 从注册中心中提取有关服务实例的信息，并为远程重新配置提供一个 API。