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

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

• 微服务介绍
• 构建微服务之使用API网关
• 构建微服务之微服务架构的进程通信
• 微服务架构中的服务发现（本文）
• 微服务之事件驱动的数据管理
• 微服务部署
• 重构单体应用为微服务

原文连接：Service Discovery in a Microservices Architecture

---

为何要使用服务发现

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

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

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

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

客户端发现模式

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

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

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

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

服务端发现模式

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

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

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 ，服务注册表是架构内置的一部分。

服务注册的方式

服务实例必须在注册表中注册和注销，有如下不一样的两种方法：一、服务实例本身注册，也叫作自注册模式；二、系统中其余组件管理服务实例的注册，也就是第三方注册模式。

自注册方式

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

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。