Chris Richardson微服务翻译：微服务架构中的服务发现

Chris Richardson 微服务系列翻译全7篇链接：

原文链接：Service Discovery in a Microservices Architecture

为什么要使用服务发现

假设我们需要通过 REST API 或 Thrift API 去调用某个服务，为了完成一次请求，我们需要知道服务实例的地址（IP和端口号）。传统运行在物理机上的应用，服务实例的网络地址一般是静态的，可以从配置文件中去读取地址。

对于基于云平台的微服务中，有更多如下的问题需要解决：

服务实例的网络地址是动态分配的。由于扩展、升级，服务地址会经常变动，因此，客户端需要使用更负责的服务发现机制。

主要有两种服务发现机制：客户端发现模式和服务端发现模式。

客户端发现模式

客户端决定服务实例的网络地址，并对请求实现负载均衡。客户端查询服务注册表（可用服务实例的数据库），然后使用负载均衡算法从中选择一个实例并请求。下图展示该模式的架构：

服务实例的网络地址在启动时记录到服务注册表上，等实例停止时从服务注册表中删除。服务实例的注册信息通常使用心跳机制来定期刷新。

Netflix OSS 是客户端发现模式的绝佳范例。Netflix Eureka 实现了服务注册表，为服务注册管理和可用实例查询提供了 REST API 接口，Netflix Ribbon 是 IPC 客户端，与 Eureka 一起实现对请求的负载均衡。

客户端发现机制有诸多优势和不足。优点：1、相对直接，除服务注册外，其他部分无需改动。2、客户端知晓可用的服务实例，能针对特定应用智能的实现负载均衡，例如一致性哈希算法。不足：客户端与服务注册表绑定，要针对服务端用到的每个编程语言和框架，实现客户端的服务发现逻辑。

服务端发现模式

下图展示了服务端发现模式的架构：

客户端通过负载均衡向某个服务发出请求，负载均衡查询服务注册表，并将请求路由至可用的服务实例。如同客户端发现模式，服务实例在服务注册表中注册或删除。

AWS Elastic Load Balancer （ELB）是服务端发现路由的范例。ELB 通常对外部的网络请求进行负载均衡，也可对虚拟私有云的内部请求进行负载均衡。客户端使用 DNS 通过 ELB 发出请求（HTTP或TCP），ELB 将请求负载均衡到一系列注册的 EC2 实例或 ECS 容器，这两者没有单独的服务注册表，而是注册在 ELB 中。

一些部署环境使用 Kubernetes 和 Marathon 在每个集群运行一个代理，作为服务端发现的负载均衡。代理可以根据 IP地址和端口来路由客户端请求，透明的将客户端的请求转发到集群中某个可用的服务实例上。

服务端发现机制的优点：客户端无需关注服务发现的细节，只需简单的向负载均衡发送请求，如上文所说，某些部署环境免费提供了这一功能；不足：除非部署环境提供了负载均衡，否则也成为了需要额外配置和管理的高可用组件。

服务注册表

服务注册表是服务发现的核心部分，是包含服务实例的网络地址的数据库。服务注册表需要高可用和实时更新。客户端能缓存从服务注册表中获取的网络地址，然而这些信息最终会过时，客户端也不能再根据该信息发现服务实例。因此，服务注册表对集群中的实例使用复制协议来保证一致性。

Netflix Eureka 是服务注册表的范例，为服务实例的注册和查询提供了 REST API：服务实例可以通过 POST 请求来注册网络地址，每 30秒通过 PUT 去更新注册信息，也可主动通过 DELETE 请求或实例注册超时来删除注册信息，客户端使用 GET 请求来检索已注册的服务实例。

Netflix 通过在每个 AWS EC2 域运行一个或多个 Eureka 服务实例来实现高可用。DNS TEXT 记录了 Eureka 集群的配置文件，配置文件映射了可用域和 Eureka 服务器网络地址的映射关系。Eureka 服务启动时查询 DNS 获取 Eureka 集群配置，确定同伴位置，为自己分配未被使用的弹性 IP 地址。

Eureka 客户端倾向使用同一域内的 Eureka 服务器，如果该域中没有可用的服务，则会使用其他域中的 Eureka 服务。

其他的服务注册表例如：

etcd ：高可用、分布式、一致性的 key-value 存储，用于共享配置和服务发现。Kubernetes 和 Cloud Foundry 使用了它
consul：发现和配置服务的工具，为客户端注册和服务发现提供了API，还可以通过健康检查来确定服务的可用性
Apache Zookeeper：广泛使用的、高性能的分布式应用的协调服务。 Apache Zookeeper 最初是 Hadoop 的子工程，现已成长为顶级项目

像 Kubernetes、Marathon 和 AWS ，服务注册表是架构内置的一部分。

服务注册的方式

服务实例必须在注册表中注册和注销，有以下不同的两种方法：1、服务实例自己注册，也叫做自注册模式；2、系统中其他组件管理服务实例的注册，也就是第三方注册模式。

自注册方式

使用自注册模式时，服务实例负责在注册表中注册和注销，另外也需要发送心跳来防止注册信息过期，如下图所示：

Netflix OSS Eureka 客户端就是这种模式的一个范例，他负责处理服务实例注册和注销的各个方面。Spring Cloud 实现了包括服务发现在内的各种模式，使得利用 Eureka 自注册服务实例更简单，只需要给 Java 配置类上添加 @EnableEurekaClient 即可。

自注册的优势：相对简单，不使用其他系统组件。不足：服务实例与服务注册表耦合，必须在每个客户端实现注册逻辑。

第三方注册方式

使用第三方注册模式，服务实例不需要向服务注册表注册，而是通过服务注册器的系统组件来处理。服务注册器通过轮询或订阅事件的方式来跟踪运行实例的更改，一旦监测到有新的可用服务实例，会向注册表注册此服务。服务注册器也负责注销已终止的服务实例。架构图如下图所示：

Registrator 是一个开源的服务注册器，他能够自动注册和注销 Docker 容器中的服务实例，支持包括 etcd 和 Consul 在内的多种服务注册表。

NetflixOSS Prana 是另一个服务注册器，主要面向非 JVM 语言的服务，与服务实例一起运行。Prana 使用 Netflix Eureka 来注册和注销服务实例。

第三方服务注册器的优点：服务与服务注册器解耦，无需为不同的编程语言实现服务注册的逻辑，而是通过一个专有服务以集中化的方式进行管理。不足：除非内置在部署环境中，不然又是一个需要被维护和管理的高可用组件。

总结

微服务应用中，服务实例的网络地址会动态的变化，因此，为了使客户端能够向服务端发起请求，必须有服务发现机制。

服务注册表是服务发现的关键。服务注册表是可用服务实例的数据库，提供了管理和查询的 API，服务实例使用管理 API 实现注册和注销，系统组件使用查询 API 发现可用的服务实例。

服务发现有两种模式：客户端发现和服务端发现。使用客户端发现的系统中，客户端直接查询注册表，选择一个可用实例发起请求；在服务端发现的系统中，客户端通过路由转发请求，路由会查询服务注册表并将请求转发到可用服务实例上。

服务实例的注册和注销也有两种方式。一是服务实例自己注册到服务注册表中，即自注册模式；另一种是其他系统组件处理注册和注销，也就是第三方注册模式。

在一些部署环境中，可以使用 Netflix Eureka、etcd、Apache Zookeeper 等实现服务发现。而另一些部署环境则内置了服务发现，例如，Kubernetes 和 Marathon 用来处理服务注册和注销，他们在集群的每个主机上运行一个代理完成服务端发现路由。

NHINX 能够用作服务端发现负载均衡使用，服务注册表可以向 NGINX 推送路由信息，例如使用 Cosul Template。