[翻译]微服务设计模式 - 6. 服务发现 - 服务注册中心

原文地址：https://microservices.io/patterns/service-registry.html

背景

访问一个服务的客户端使用客户端服务发现或者服务端服务发现确定一个服务实例的位置并发送请求给这个实例调用所需服务。

问题

在客户端服务发现中，客户端如何知道服务的可用实例在哪里？在服务端发现实例中，负载均衡器如何知道服务的可用实例在那里？

考虑因素

• 每个实例可能在特定的主机和端口暴露远程 API（例如 HTTP/REST，或者 Thrift）
• 服务实例的数量及其位置动态变化。虚拟机和容器通常被分配一个动态IP地址。例如，AWS EC2 自动扩容组根据 LOAD 调整实例数量。

解决方案

实现一个服务注册中心，即保存所有服务的实例信息和其位置的数据库。服务实例在启动时在服务注册中心注册，在关闭时时会取消注册。服务的客户端和或负载均衡器查询服务注册表以查找服务的可用实例，服务注册中心可能调用服务实例的健康检查 API 以验证它是否能够处理请求。

举例

我们用一个客户端服务发现的应用程序举例。用 Scala 编写，使用 SpringBoot 和 SpringCloud 作为微服务框架，以 Netflix Eureka服务注册中心。

Eureka 服务器是一个小型 SpringBoot 应用程序：

@SpringBootApplication
@EnableEurekaServer
public class EurekaServer {

  public static void main(String[] args) {
    new SpringApplicationBuilder(EurekaServer.class).web(true).run(args);
  }

}

使用 Docker 部署：

eureka:
  image: java:openjdk-8u91-jdk
  working_dir: /app
  volumes:
    - ./eureka-server/build/libs:/app
  command: java -jar /app/eureka-server.jar --server.port=8761
  ports:
    - "8761:8761"

其他服务注册中心(或通常用作服务注册中心的技术)的例子包括：

有些系统，如Kubernetes、Marathon 以及 AWS ELB 都有一个隐式的服务注册中心逻辑。

结果分析

注册中心这种设计模式的好处包括：

• 服务的客户端或者负载均衡器可以动态发现服务实例的位置。

同时，还有一些缺点：

• 除非服务注册中心内置到基础结构中，否则就需要维护另外一组基础结构组件。此外，服务注册中心是一个关键的系统组件。虽然客户端应该缓存服务注册中心提供的数据，但是如果服务注册中心挂掉了，该数据最终将过时。因此，注册中心必须高可用。

需要选择如何向注册中心注册服务实例。有两种选择：

• 自注册模式：服务实例自行注册。
• 第三方登记模式：第三方向服务注册中心注册服务实例。

服务注册中心的客户端需要知道注册中心实例的位置。注册中心实例必须部署在固定的公共网络地址上，并且在客户端配置了这些 IP 地址。

例如，Netflix Eureka 服务实例通常使用弹性 IP 地址部署。可用的弹性 IP 地址池是使用属性文件或通过 DNS 配置的。当Eureka实例启动时，它会参考配置来确定使用哪个可用的弹性 IP 地址，Eureka 客户端还会配置该弹性 IP 地址池。

相关模式

• 客户端发现服务，服务端发现服务
• 自注册和第三方注册这两种服务注册方式
• 健康检查 API：服务注册中心调用服务实例的健康检查 API 以验证它是否能够处理请求