微服务从设计到部署（四）服务发现

连接：https://github.com/oopsguy/microservices-from-design-to-deployment-chinese
译者：Oopsguy

本书主要介绍如何使用微服务来构建应用程序，如今是第四章。第一章已经介绍了微服务架构模式，并讨论了使用微服务的优势与缺点。第二章和第三章介绍了微服务间的通讯，并对不一样的通讯机制做出对比。在本章中，咱们将探讨服务发现（service discovery）相关的内容。

4.一、为什么使用服务发现

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

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

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

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

4.二、客户端发现模式

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

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

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

Netflix OSS 提供了一个很好的客户端发现模式示例。Netflix Eureka 是一个服务注册中心，它提供了一个用于管理服务实例注册和查询可用实例的 REST API。Netflix Ribbon 是一个 IPC 客户端，可与 Eureka 一块儿使用，用于在可用服务实例之间使请求负载均衡。本章稍后将讨论 Eureka。

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

如今咱们已经了解了客户端发现，接下来让咱们看看服务器端发现。

4.三、服务端发现模式

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

客户端经过负载均衡器向服务发出请求。负载均衡器查询服务注册中心并将每一个请求路由到可用的服务实例。与客户端发现同样，服务实例由服务注册中心注册与销毁。

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

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

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

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

4.四、服务注册中心

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

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

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

通过 Eureka 客户端 - 服务与服务客户端 - 查询 DNS 以发现 Eureka 服务器的网络位置。客户端优先使用相同可用性区域中的 Eureka 服务器，若是没有可用的，则使用另外一个可用性区域的 Eureka 服务器。

如下列举了其余服务注册中心：

• etcd - 一个用于共享配置和服务发现的高可用、分布式和一致的键值存储。使用 etcd 的两个著名项目分别为 Kubernetes 和 Cloud Foundry。
• Consul - 一个发现与配置服务工具。它提供了一个 API，可用于客户端注册与发现服务。Consul 可对服务进行健康检查，以肯定服务的可用性。
• Apache ZooKeeper - 一个被普遍应用于分布式应用程序的高性能协调服务。Apache ZooKeeper 最初是一个 Hadoop 子项目，但如今已经成为一个独立的顶级项目。

另外，如以前所述，部分系统，如 Kubernetes、Marathon 和 AWS，没有明确的服务注册中心。相反，服务注册中心只是基础设施的一个内置部分。
 
如今咱们已经了解服务注册中心的概念，接下来让咱们看看服务实例是如何被注册到服务注册中心。

4.五、服务注册方式

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

4.六、自注册模式

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

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

该方式的一个很好的范例就是 Netflix OSS Eureka 客户端。Eureka 客户端负责处理服务实例注册与注销的全部方面。实现了包括服务发如今内的多种模式的 Spring Cloud 项目能够轻松地使用 Eureka 自动注册服务实例。您只需在Java Configuration类应用 @EnableEurekaClient 注解便可。

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

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

4.七、第三方注册模式

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

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

服务注册器的一个例子是开源的 Registrator 项目。它能够自动注册和注销做为 Docker 容器部署的服务实例。注册器支持多个服务注册中心，包括 etcd 和 Consul。

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

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

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

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

4.八、总结

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

服务发现的一个关键部分是服务注册中心。服务注册中心是一个可用服务实例的数据库。服务注册中心提供了管理 API 和查询 API 的功能。服务实例经过使用管理 API 从服务注册中心注册或者注销。系统组件使用查询 API 来发现可用的服务实例。

有两种主要的服务发现模式：客户端发现与服务端发现。在使用了客户端服务发现的系统中，客户端查询服务注册中心，选择一个可用实例并发出请求。在使用了服务端发现的系统中，客户端经过路由器进行请求，路由器将查询服务注册中心，并将请求转发到可用实例。

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

在某些部署环境中，您须要使用如 Netflix Eureka 或 Apache ZooKeeper 等服务注册中心来设置您本身的服务发现基础设施。在其余部署环境中，服务发现是内置的，例如，Kubernetes 和 Marathon，能够处理服务实例的注册与注销。他们还在每个扮演服务端发现路由器角色的集群主机上运行一个代理。

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

微服务实战：NGINX 的灵活性

by Floyd Smith

在微服务环境中，因为自动扩展、故障和升级，您的后端基础设施可能会不断变化，这些包括了服务的建立，部署和扩展。如本章所述，在动态从新分配服务位置的环境中须要服务发现机制。

将 NGINX 应用于微服务的一部分好处是，您能够轻松地将其配置为自动响应后端基础设施做出的变动。NGINX 配置不只简单灵活，并且兼容 Amazon Web Services 使用的模板，能够更轻松地管理特定的服务变动与受负载均衡的变动服务组。

NGINX Plus 具备即时从新配置 API，无需从新启动 NGINX Plus 或手动从新加载配置就能感知受负载均衡服务组的变动。在 NGINX Plus Release 8 及更高版本中，您能够将对 API 所作的更改配置为在从新启动和配置从新加载时保持不变。（从新加载不须要从新启动，不要断开链接）NGINX Plus Release 9 及更高版本支持使用 DNS SRV 记录进行服务发现，可与现有服务器发现平台（如 Consul 和 etcd）进行更紧密地集成。

咱们在 NGINX 建立了一个用于管理服务发现的模型：

1. 为几个应用程序单独运行的Docker容器，包括如 etcd 的服务发现应用程序、服务注册工具、一个或多个后端服务器以及用于负载均衡其余容器的 NGINX Plus 自己。
2. 注册工具监控 Docker 的新容器，并使用服务发现工具注册新服务，此外，还能够删除消失的容器。
3. 容器及其运行的服务将自动添加到负载均衡上游服务器中或从其中删除。

此 Demo 应用程序可用于多个服务发现应用程序：Consul API、来自 Consul 的 DNS SRV 记录、etcd 以及 ZooKeeper 等。

本系列所有译文

• https://github.com/oopsguy/microservices-from-design-to-deployment-chinese

相关连接

• 微服务从设计到部署（一）微服务简介
• 微服务从设计到部署（二）使用 API 网关
• 微服务从设计到部署（三）进程间通讯