使用Consul实现服务发现:instance-id自定义

标签: Spring Cloud Spring Cloud Spring Cloud Consul Consul | 发表时间:2019-12-19 14:18 | 作者:
出处:http://www.itmuch.com/

TIPS

本文基于Spring Cloud Hoxton,理论支持Spring Cloud所有版本。

本文探讨如何自定义微服务注册到Consul的InstanceId。

Consul把InstanceId作为唯一标识,而Spring Cloud Consul默认的InstanceId是 ${spring.application.name}-${server.port}

这样导致的问题是:某个微服务即使有多个实例,只要端口相同,那么Consul上依然只会保留1条数据!要想解决这个问题,只需要让不同实例,拥有不同的InstanceId即可。

方式1:拼接随机值

添加配置:

1     
2
3
4
5
spring:     
cloud:
consul:
discovery:
instance-id: ${spring.application.name}-${server.port}-${random.long}

目前市面上的一些文章也是这么玩的。但这样做,在一些场景下还是有一点小问题的。

举个例子:假设某个微服务实例崩溃了,然后在很短的时间内(Consul还没来得及把这个实例删除);应用重启了,就会导致Consul上出现两条数据,但其实代表的是一个实例(虽然过段时间后,Consul会把没用的实例删除,但在一段时间内出现2条数据还是很诡异的)。

TIPS

${random.long} 是Spring Boot自带的“扩展配置”,还有很多的使用姿势。文档可详见 https://docs.spring.io/spring-boot/docs/2.2.0.M5/reference/html/spring-boot-features.html#boot-features-external-config-random-values

方式2:拼接机器唯一标识


讲到这里,聪明的同学一定会想到,一个合理的instanceid应该满足以下两点需求:

  • 不同实例的instanceid不同;
  • 相同实例启动多次,instanceid应该相同。

要想实现这两点诉求,只要在instanceid上加上机器的唯一标示就OK了,比如IP或者是主机名等等。

1     
2
3
4
5
spring:     
cloud:
consul:
discovery:
instance-id: ${spring.application.name}-${server.port}-${spring.cloud.client.hostname}

或者:

1     
2
3
4
5
spring:     
cloud:
consul:
discovery:
instance-id: ${spring.application.name}-${server.port}-${spring.cloud.client.ip-address}

TIPS

这里, ${spring.cloud.client.hostname} 以及 ${spring.cloud.client.ip-address} ,是利用了Spring Boot配置文件可以读取环境变量的特点。

你的应用只要集成 Spring Boot Actuator ,就可以通过 /actuator/env 查看所有环境变量啦!环境变量的Key值,都可以写到配置文件中。

方式3:代码扩展

如果上面两种方式依然满足不了你的需求,那么你还可以通过写代码的方式去扩展。

代码:

1     
2
3
4
5
6
7
8
9
10
11
12
13
public class WiiConsulAutoRegistration extends ConsulAutoRegistration {     
public WiiConsulAutoRegistration(NewService service, AutoServiceRegistrationProperties autoServiceRegistrationProperties, ConsulDiscoveryProperties properties, ApplicationContext context, HeartbeatProperties heartbeatProperties, List<ConsulManagementRegistrationCustomizer> managementRegistrationCustomizers) {
super(service, autoServiceRegistrationProperties, properties, context, heartbeatProperties, managementRegistrationCustomizers);
}

public static String getInstanceId(WiiProperties wiiProperties,
Environment environment) {
return String.format("%s-%s-%s",
environment.getProperty("spring.application.name"),
wiiProperties.getIp(),
wiiProperties.getPort());
}
}

配置:

1     
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@Configuration     
public class XXXConfiguration {
@Bean
public ConsulAutoRegistration consulRegistration(
AutoServiceRegistrationProperties autoServiceRegistrationProperties,
ConsulDiscoveryProperties properties,
ApplicationContext applicationContext,
ObjectProvider<List<ConsulRegistrationCustomizer>> registrationCustomizers,
ObjectProvider<List<ConsulManagementRegistrationCustomizer>> managementRegistrationCustomizers,
HeartbeatProperties heartbeatProperties) {
return WiiConsulAutoRegistration.registration(autoServiceRegistrationProperties,
properties, applicationContext, registrationCustomizers.getIfAvailable(),
managementRegistrationCustomizers.getIfAvailable(), heartbeatProperties);
}
}

TIPS

  • 这种方式更加灵活,你想怎么玩就怎么玩。你可以在InstanceId上拼接mac地址或者其他什么玩意儿……不过,只是为了定制个唯一标示而已,这么玩 成本有点高了,我建议: 如果没有不得已的苦衷,就甭折腾了
  • 我的个人项目 Spring Cloud Wii (也就是现在的Spring Cloud Alibaba Sidecar)就是使用的这种方式自定义InstanceId的。但Wii之所以采用这种方式,是因为Wii本身就要扩展 WiiConsulAutoRegistration ,定制一下InstanceId只是顺手而为。相关代码在这里,有兴趣可以看下: https://github.com/eacdy/spring-cloud-wii/blob/master/spring-cloud-wii/src/main/java/com/itmuch/wii/consul/WiiConsulAutoRegistration.java

未来…

未来如果这个Pull Request被合并,就不用折腾了……详见: https://github.com/spring-cloud/spring-cloud-consul/pull/570

相关 [consul 服务 发现] 推荐:

服务发现:Zookeeper vs etcd vs Consul

- - 企业架构 - ITeye博客
服务发现:Zookeeper vs etcd vs Consul. 【编者的话】本文对比了Zookeeper、etcd和Consul三种服务发现工具,探讨了最佳的服务发现解决方案,仅供参考. 如果使用预定义的端口,服务越多,发生冲突的可能性越大,毕竟,不可能有两个服务监听同一个端口. 管理一个拥挤的比方说被几百个服务所使用的所有端口的列表,本身就是一个挑战,添加到该列表后,这些服务需要的数据库和数量会日益增多.

基于 Consul 的 Docker Swarm 服务发现

- - IT瘾-dev
基于 Consul 的 Docker Swarm 服务发现. 2017 年 1 月 10 日发布. Docker 是一种新型的虚拟化技术,它的目标在于实现轻量级操作系统的虚拟化. 相比传统的虚拟化方案,Docker. 虚拟化技术有一些很明显的优势:启动容器的速度明显快于传统虚拟化技术,同时创建一台虚拟机占用的资源也要远远小于传统的虚拟技术.

使用Consul做服务发现的若干姿势

- - 程序猿DD
从2016年起就开始接触Consul,使用的主要目的就是做服务发现,后来逐步应用于生产环境,并总结了少许使用经验. 最开始使用Consul的人不多,为了方便交流创建了一个QQ群(群号在最后),这两年微服务越来越火,使用Consul的人也越来越多,目前群里已有400多人,经常有人问一些问题,比如:. 服务注册到节点后,其他节点为什么没有同步.

使用Consul实现服务发现:instance-id自定义

- - 周立的博客 - 关注Spring Cloud、Docker
本文基于Spring Cloud Hoxton,理论支持Spring Cloud所有版本. 本文探讨如何自定义微服务注册到Consul的InstanceId. Consul把InstanceId作为唯一标识,而Spring Cloud Consul默认的InstanceId是 ${spring.application.name}-${server.port}.

基于Nginx和Consul构建高可用及自动发现的Docker服务架构 - DockOne.io

- -
如果你在大量接触或使用微服务的话,你可能会碰到一个问题:当你创建的服务数量越来越多时,这些服务之间的通信便越难管理,而且维护代价会越来越高. 针对这个问题,Consul给出了一份完美的答卷. Consul是一套开源的分布式服务发现和配置管理系统,支持多数据中心分布式高可用. Consul是HashiCorp(Vagrant的创建者)开发的一个服务发现与配置项目,用Go语言开发,基于 Mozilla Public License 2.0 的协议开源.

安装Consul集群

- - 周立的博客 - 关注Spring Cloud、Docker
本文基于Consul 1.5.3,理论适用于Consul 1.6及更低版本. 运行一个consul agent. 将agent加入到consul集群. 列出consul cluster集群中的members. 这里只列出几个常用的命令,consul有将近20个命令,本文不作展开,详见: https://www.consul.io/docs/commands/index.html.

[转]consul VS zookeeper、etcd、doozerd

- - Xiao_Qiang_的专栏
  zookeeper、doozerd、etcd都有着相似的架构,这三者的服务节点都需要一个仲裁节点来操作,它们是强一致的,并提供各种操作原语. 应用程序可以通过客户端lib库来构建分布式的系统. 在一个单datacenter中,consul的server节点工作在一种简单的方式下,consul server需要一个仲裁操作,并提供强一致性.

Consul注销实例时候的问题

- - 程序猿DD
当我们在Spring Cloud应用中使用Consul来实现服务治理时,由于Consul不会自动将不可用的服务实例注销掉(deregister),这使得在实际使用过程中,可能因为一些操作失误、环境变更等原因让Consul中存在一些无效实例信息,而这些实例在Consul中会长期存在,并处于断开状态. 它们虽然不会影响到正常的服务消费过程,但是它们会干扰我们的监控,所以我们可以实现一个清理接口,在确认故障实例可以清理的时候进行调用来将这些无效信息清理掉.

基于consul的Redis高可用方案

- -
这几天在研究如何做Redis的高可用容灾方案,查询了资料和咨询DBA同行,了解到Redis可以基于consul和sentinel实现读写分离以及HA高可用方案. 本文讲述基于consul的Redis高可用方案实践. 感谢邓亚运的提示和资料协助. Consul是HashiCorp公司基于go语言研发用于服务发现和配置共享开的分布式高可用的系统.

[原]Curator服务发现

- - 升华思想 技术高深
一个服务发现系统提供下面几个机制:.  注册它们有用的服务.  定位一个单一特殊服务的实例.  当一个服务改变时发出通知. 3.3.1.1 服务实例. 一个服务实例使用类ServiceInstance作为服务实例类. ServiceInstance有一个名称、id、地址、端口或者ssl端口以及可选负载(用户定义).