原文地址：https://microservices.io/patterns/client-side-discovery.html

服务之间需要互相调用，在单体架构中，服务之间的互相调用直接通过编程语言层面的方法调用就搞定了。在传统的分布式应用的部署中，服务地址和端口是固定并且提前预知的，所以只需要简单的 HTTP/REST 调用或者其他的 RPC 机制直接调用即可。但是在当下的云原生微服务体系中，微服务大多在某个虚拟机或者某个容器下运行，服务实例数量以及提供服务的地址以及端口都是不固定的，可以理解为，这些服务实例都是临时的。所以，需要实现使服务客户端能够对一组动态变化的临时服务实例发请求的机制。

提出问题

某个服务的客户端，API网关或者一些其他需要发现服务实例的服务，如何知道服务实例的位置？

考虑因素

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

解决方案

当想请求一个服务时，客户端查询一个公共的服务登记处（Service Registry，我们一般称为注册中心），来查询要调用的服务有哪些实例，并在地址是哪里。如下图所示：

举例

这里用 Scala 语言，Spring Boot 和 Spring Cloud 框架举个例子，Spring Cloud 的服务发现主要就是基于客户端服务发现的。

RegistrationServiceProxy 是该应用程序的一个组件，用于注册用户:

@Componentclass RegistrationServiceProxy @Autowired()(restTemplate: RestTemplate) extends RegistrationService {  @Value("${user_registration_url}")  var userRegistrationUrl: String = _  override def registerUser(emailAddress: String, password: String): Either[RegistrationError, String] = {      val response = restTemplate.postForEntity(userRegistrationUrl,        RegistrationBackendRequest(emailAddress, password),        classOf[RegistrationBackendResponse])       ...}

这个类注入了 RestTemplate 以及 user_registration_url，当这个应用被部署的时候，user_registration_url实际为http://REGISTRATION-SERVICE/user，REGISTRATION-SERVICE是客户端用来做服务发现的服务名称。服务发现通过 Netflix OSS 组件实现，包括作为注册中心的 Eureka，以及查询 Eureka 获取实例来做 Http 请求调用的 Ribbon。

客户端服务发现使用各种 Spring Cloud 注解进行配置：

@Configuration@EnableEurekaClient@Profile(Array("enableEureka"))class EurekaClientConfiguration {  @Bean  @LoadBalanced  def restTemplate(scalaObjectMapper : ScalaObjectMapper) : RestTemplate = {    val restTemplate = new RestTemplate()    restTemplate.getMessageConverters foreach {      case mc: MappingJackson2HttpMessageConverter =>        mc.setObjectMapper(scalaObjectMapper)      case _ =>    }    restTemplate  }

@EnableEurekaClient注解启用了 Eureka 客户端。@LoadBalanced 注解配置 RestTemplate 使用已配置为使用 Eureka 客户端进行服务发现的 Ribbon 进行远程调用。因此，RestTemplate 将通过对 http://REGISTRATION-SERVICE/user 解析拿到服务名称，之后通过查询 Eureka 查找可用服务实例的网络位置来进行请求。

分析

客户端服务发现的优点：

与服务端服务发现相比，网络中间组件和网络跳转更少一些

客户端服务发现的缺点：

与注册中心耦合，不同的注册中心注册逻辑不一样。
需要实现不同语言的客户端服务发现逻辑。

[翻译]微服务设计模式 - 4. 服务发现 - 客户端服务发现

提出问题

考虑因素

解决方案

举例

分析

相关设计模式

更多相关文章

随机推荐