详解Spring Cloud Finchley版中Consul多实例注册的问题处理

consul 简介

consul 具有以下性质：

  1. 服务发现：consul通过http 方式注册服务，并且服务与服务之间相互感应。
  2. 服务健康监测
  3. key/value 存储
  4. 多数据中心

consul可运行在mac windows linux 等机器上。

由于Spring Cloud对Etcd的支持一直没能从孵化器中出来，所以目前来说大多用户还在使用Eureka和Consul，之前又因为Eureka 2.0不在开源的消息，外加一些博眼球的标题党媒体使得Eureka的用户有所减少，所以，相信在选择Spring Cloud的用户群体中，应该有不少用户会选择Consul来做服务注册与发现。

本文就来说一下，当我们使用Spring Cloud最新的Finchley版 + Consul 1.2.x时候最严重的一个坑：多实例注册的问题。

问题解读

问题：该问题可能在开发阶段不一定会发现，但是在线上部署多实例的时候，将会发现Consul中只有一个实例。

原因：造成该问题的主要原因是Spring Cloud Consul在注册的时候实例名（InstanceId）采用了：“服务名-端口号”（即： {spring.application.name}-{server.port} ）的值，可以看到这个实例名如果不改变端口号的情况下，实例名都是相同的。如果熟悉Spring Cloud Consul的读者，可能会问老版本也是这个规则，怎么没有这个问题呢？。主要是由于Consul对实例唯一性的判断标准也有改变，在老版本的Consul中，对于实例名相同，但是服务地址不同，依然会认为是不同的实例。在Consul 1.2.x中，服务实例名成为了集群中的唯一标识，所以，也就导致了上述问题。

解决方法

既然知道了原因，那么我们要解决它就可以有的放矢了。下面就来介绍两个具体的解决方式：

方法一：通过配置属性指定新的规则

下面举个例子，通过 spring.cloud.consul.discovery.instance-id 参数直接来配置实例命名规则。这里比较粗暴的通过随机数来一起组织实例名。当然这样的组织方式并不好，因为随机数依然有冲突的可能，所以您还可以用更负责的规则来进行组织实例名。

代码如下:

spring.cloud.consul.discovery.instance-id=${spring.application.name}-${random.int[10000,99999]}

方法二：通过扩展 ConsulServiceRegistry 来重设实例名

由于通过配置属性的方式对于定义实例名的能力有限，所以我们希望可以用更灵活的方式来定义。这时候我们就可以通过重写 ConsulServiceRegistry 的 register 方法来修改。比如下面的实现：

public class MyConsulServiceRegistry extends ConsulServiceRegistry {

  public MyConsulServiceRegistry(ConsulClient client, ConsulDiscoveryProperties properties, TtlScheduler ttlScheduler, HeartbeatProperties heartbeatProperties) {
    super(client, properties, ttlScheduler, heartbeatProperties);
  }

  @Override
  public void register(ConsulRegistration reg) {
    reg.getService().setId(reg.getService().getName() + “-” + reg.getService().getAddress() + “-” + reg.getService().getPort());
    super.register(reg);
  }
}

上面通过拼接“服务名”-“ip地址”-“端口号”的方式，构造了一个绝对唯一的实例名，这样就可以让每个服务实例都能正确的注册到Consul上了。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持我们。

赞 (0)

相关推荐

  • 详解使用Spring Cloud Consul实现服务的注册和发现

    首先安装consul环境,参照之前的文章:https://www.jb51.net/article/141789.htm 项目规划,2个服务端,1个客户端 首先来看服务端, 一:服务端1: 项目依赖 <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-clou

  • 详解Spring Cloud Consul 实现服务注册和发现

    Spring Cloud 是一个基于 Spring Boot 实现的云应用开发工具,它为基于 JVM 的云应用开发中涉及的配置管理.服务发现.断路器.智能路由.微代理.控制总线.全局锁.决策竞选.分布式会话和集群状态管理等操作提供了一种简单的开发方式.通过 Spring Boot 风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂.易部署和易维护的分布式系统开发工具包. Spring Cloud 包含了多个子项目(针对分布式系统中涉及的多个不同开源产品),比如:Sprin

  • 详解Spring Cloud Finchley版中Consul多实例注册的问题处理

    consul 简介 consul 具有以下性质: 服务发现:consul通过http 方式注册服务,并且服务与服务之间相互感应. 服务健康监测 key/value 存储 多数据中心 consul可运行在mac windows linux 等机器上. 由于Spring Cloud对Etcd的支持一直没能从孵化器中出来,所以目前来说大多用户还在使用Eureka和Consul,之前又因为Eureka 2.0不在开源的消息,外加一些博眼球的标题党媒体使得Eureka的用户有所减少,所以,相信在选择Spr

  • 详解Spring Cloud Netflix Zuul中的速率限制

    Spring Cloud Netflix Zuul是一个包含Netflix Zuul的 开源网关.它为Spring Boot应用程序添加了一些特定功能.不幸的是,开箱即用不提供速率限制. 除了Spring Cloud Netflix Zuul依赖项之外,我们还需要将Spring Cloud Zuul RateLimit 添加到我们的应用程序的pom.xml中: <dependency> <groupId>org.springframework.cloud</groupId&g

  • 详解spring cloud config实现datasource的热部署

    关于spring cloud config的基本使用,前面的博客中已经说过了,如果不了解的话,请先看以前的博客 spring cloud config整合gitlab搭建分布式的配置中心 spring cloud config分布式配置中心的高可用 今天,我们的重点是如何实现数据源的热部署. 1.在客户端配置数据源 @RefreshScope @Configuration// 配置数据源 public class DataSourceConfigure { @Bean @RefreshScope

  • 详解spring cloud config整合gitlab搭建分布式的配置中心

    在前面的博客中,我们都是将配置文件放在各自的服务中,但是这样做有一个缺点,一旦配置修改了,那么我们就必须停机,然后修改配置文件后再进行上线,服务少的话,这样做还无可厚非,但是如果是成百上千的服务了,这个时候,就需要用到分布式的配置管理了.而spring cloud config正是用来解决这个问题而生的.下面就结合gitlab来实现分布式配置中心的搭建.spring cloud config配置中心由server端和client端组成, 前提:在gitlab中的工程下新建一个配置文件config

  • 详解spring cloud构建微服务架构的网关(API GateWay)

    前言 在我们前面的博客中讲到,当服务A需要调用服务B的时候,只需要从Eureka中获取B服务的注册实例,然后使用Feign来调用B的服务,使用Ribbon来实现负载均衡,但是,当我们同时向客户端暴漏多个服务的时候,客户端怎么调用我们暴漏的服务了,如果我们还想加入安全认证,权限控制,过滤器以及动态路由等特性了,那么就需要使用Zuul来实现API GateWay了,下面,我们先来看下Zuul怎么使用. 一.加入Zuul的依赖 <dependency> <groupId>org.spri

  • 详解spring cloud使用Hystrix实现单个方法的fallback

    本文介绍了spring cloud-使用Hystrix实现单个方法的fallback,分享给大家,具体如下: 一.加入Hystrix依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix</artifactId> </dependency> 二.编写Controller package c

  • 详解Spring Cloud 跨服务数据聚合框架

    AG-Merge Spring Cloud 跨服务数据聚合框架 解决问题 解决Spring Cloud服务拆分后分页数据的属性或单个对象的属性拆分之痛, 支持对静态数据属性(数据字典).动态主键数据进行自动注入和转化, 其中聚合的静态数据会进行 一级混存 (guava). 举个栗子: 两个服务,A服务的某张表用到了B服务的某张表的值,我们在对A服务那张表查询的时候,把B服务某张表的值聚合在A服务的那次查询过程中 示例 具体示例代码可以看 ace-merge-demo 模块 |------- ac

  • 详解spring cloud整合Swagger2构建RESTful服务的APIs

    详解spring cloud整合Swagger2构建RESTful服务的APIs

    前言 在前面的博客中,我们将服务注册到了Eureka上,可以从Eureka的UI界面中,看到有哪些服务已经注册到了Eureka Server上,但是,如果我们想查看当前服务提供了哪些RESTful接口方法的话,就无从获取了,传统的方法是梳理一篇服务的接口文档来供开发人员之间来进行交流,这种情况下,很多时候,会造成文档和代码的不一致性,比如说代码改了,但是接口文档没有改等问题,而Swagger2则给我们提供了一套完美的解决方案,下面,我们来看看Swagger2是如何来解决问题的. 一.引入Swag

  • 详解Spring Cloud Feign 熔断配置的一些小坑

    1.在使用feign做服务调用时,使用继承的方式调用服务,加入Hystrix的熔断处理fallback配置时,会报错,已解决. 2.使用feign默认配置,熔断不生效,已解决. 最近在做微服务的学习,发现在使用feign做服务调用时,使用继承的方式调用服务,加入Hystrix的熔断处理fallback配置时,会报错,代码如下: @RequestMapping("/demo/api") public interface HelloApi { @GetMapping("user/

  • 详解Spring cloud使用Ribbon进行Restful请求

    写在前面 本文由markdown格式写成,为本人第一次这么写,排版可能会有点乱,还望各位海涵.  主要写的是使用Ribbon进行Restful请求,测试各个方法的使用,代码冗余较高,比较适合初学者,介意轻喷谢谢. 前提 一个可用的Eureka注册中心(文中以之前博客中双节点注册中心,不重要) 一个连接到这个注册中心的服务提供者 一个ribbon的消费者 注意:文中使用@GetMapping.@PostMapping.@PutMapping.@DeleteMapping等注解需要升级 spring

随机推荐