Describe the bug As we konw, when RefreshScopeRefreshedEvent published, service instances perform deregister and register actions. refer: EurekaDiscoveryClientConfiguration deregister and register will be call ApplicationInfoManager#setInstanceStatus to modify InstanceStatus.

protected static class EurekaClientConfigurationRefresher
			implements ApplicationListener<RefreshScopeRefreshedEvent> {

                 // ...

		public void onApplicationEvent(RefreshScopeRefreshedEvent event) {
			if (eurekaClient != null) {
				eurekaClient.getApplications();
			}
			if (autoRegistration != null) {
                                // deregister instance
				this.autoRegistration.stop();
				// register instance
				this.autoRegistration.start();
			}
		}
	}

But, the DiscoveryClient will also be modified InstanceStatus by schedule task.

void refreshInstanceInfo() {
            applicationInfoManager.refreshDataCenterInfoIfRequired();
            applicationInfoManager.refreshLeaseInfoIfRequired();

            InstanceStatus status;
            try {
                // get instance status
                status = getHealthCheckHandler().getStatus(instanceInfo.getStatus());
            } catch (Exception e) {
                logger.warn("Exception from healthcheckHandler.getStatus, setting status to DOWN", e);
                status = InstanceStatus.DOWN;
            }

            if (null != status) {
                // modify instance status
                applicationInfoManager.setInstanceStatus(status);
            }
       
    }

So, EurekaClientConfigurationRefresher & DiscoveryClient#refreshInstanceInfo concurrent execution causes concurrency issues

Step1 deregister instance then modify InstanceStatus to DOWN by EurekaClientConfigurationRefresher

// deregister instance
this.autoRegistration.stop();

Step2 get InstanceStatus from instanceInfo is DOWN by DiscoveryClient#refreshInstanceInfo()

// get instance status
status = getHealthCheckHandler().getStatus(instanceInfo.getStatus());

Step3 deregister instance then modify InstanceStatus to UP by EurekaClientConfigurationRefresher

// register instance
this.autoRegistration.start();

Step4 modify InstanceStatus to DOWN by DiscoveryClient#refreshInstanceInfo()

// modify instance status
applicationInfoManager.setInstanceStatus(status);

If the execution order is as above, the service InstanceStatus changes to DOWN.

您好，我在学习使用springboot2.6.4+springcloud2021.0.1整合nacos时dependencyManagement添加了

<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-alibaba-dependencies</artifactId> <version>2021.0.1.0</version> <type>pom</type> <scope>import</scope> </dependency>

gateway中配置如下： `server: port: 8600

spring:

codec:

max-in-memory-size: 1024

application: name: gateway cloud: nacos: discovery: server-addr: 192.168.199.5:8848 gateway: discovery: locator: enabled: true lower-case-service-id: true routes: - id: userServiceRouter uri: http://user-consumer predicates: - Path=/api/userService/user/** filters: - StripPrefix=2

并且gateway和应用服务都已经注册在了nacos，我很奇怪为什么我只有在uri=具体的ip:port我才能掉通服务，如果我通过服务名调用它会提示如下错误：java.net.UnknownHostException: Failed to resolve 'user-consumer' after 2 queries at io.netty.resolver.dns.DnsResolveContext.finishResolve(DnsResolveContext.java:1047) ~[netty-resolver-dns-4.1.74.Final.jar:4.1.74.Final] Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException: Error has been observed at the following site(s): *__checkpoint ⇢ org.springframework.cloud.gateway.filter.WeightCalculatorWebFilter [DefaultWebFilterChain] *__checkpoint ⇢ HTTP GET "/api/userService/user/addUser/gdfgdfg" [ExceptionHandlingWebHandler] Original Stack Trace: at io.netty.resolver.dns.DnsResolveContext.finishResolve(DnsResolveContext.java:1047) ~[netty-resolver-dns-4.1.74.Final.jar:4.1.74.Final] at io.netty.resolver.dns.DnsResolveContext.tryToFinishResolve(DnsResolveContext.java:1000) ~[netty-resolver-dns-4.1.74.Final.jar:4.1.74.Final] at io.netty.resolver.dns.DnsResolveContext.query(DnsResolveContext.java:418) ~[netty-resolver-dns-4.1.74.Final.jar:4.1.74.Final] at io.netty.resolver.dns.DnsResolveContext.onResponse(DnsResolveContext.java:629) ~[netty-resolver-dns-4.1.74.Final.jar:4.1.74.Final] at io.netty.resolver.dns.DnsResolveContext.access$400(DnsResolveContext.java:66) ~[netty-resolver-dns-4.1.74.Final.jar:4.1.74.Final] at io.netty.resolver.dns.DnsResolveContext$2.operationComplete(DnsResolveContext.java:462) ~[netty-resolver-dns-4.1.74.Final.jar:4.1.74.Final] at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:578) [netty-common-4.1.74.Final.jar:4.1.74.Final] at io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:571) [netty-common-4.1.74.Final.jar:4.1.74.Final] at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:550) [netty-common-4.1.74.Final.jar:4.1.74.Final] at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:491) [netty-common-4.1.74.Final.jar:4.1.74.Final] at io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:616) [netty-common-4.1.74.Final.jar:4.1.74.Final] at io.netty.util.concurrent.DefaultPromise.setSuccess0(DefaultPromise.java:605) [netty-common-4.1.74.Final.jar:4.1.74.Final] at io.netty.util.concurrent.DefaultPromise.trySuccess(DefaultPromise.java:104) [netty-common-4.1.74.Final.jar:4.1.74.Final] at io.netty.resolver.dns.DnsQueryContext.trySuccess(DnsQueryContext.java:216) ~[netty-resolver-dns-4.1.74.Final.jar:4.1.74.Final] at io.netty.resolver.dns.DnsQueryContext.finish(DnsQueryContext.java:208) ~[netty-resolver-dns-4.1.74.Final.jar:4.1.74.Final] at io.netty.resolver.dns.DnsNameResolver$DnsResponseHandler.channelRead(DnsNameResolver.java:1314) ~[netty-resolver-dns-4.1.74.Final.jar:4.1.74.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.74.Final.jar:4.1.74.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.74.Final.jar:4.1.74.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.74.Final.jar:4.1.74.Final] at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) ~[netty-codec-4.1.74.Final.jar:4.1.74.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.74.Final.jar:4.1.74.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.74.Final.jar:4.1.74.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.74.Final.jar:4.1.74.Final] at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[netty-transport-4.1.74.Final.jar:4.1.74.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.74.Final.jar:4.1.74.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.74.Final.jar:4.1.74.Final] at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[netty-transport-4.1.74.Final.jar:4.1.74.Final] at io.netty.channel.nio.AbstractNioMessageChannel$NioMessageUnsafe.read(AbstractNioMessageChannel.java:97) ~[netty-transport-4.1.74.Final.jar:4.1.74.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722) ~[netty-transport-4.1.74.Final.jar:4.1.74.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658) ~[netty-transport-4.1.74.Final.jar:4.1.74.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584) ~[netty-transport-4.1.74.Final.jar:4.1.74.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496) ~[netty-transport-4.1.74.Final.jar:4.1.74.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986) ~[netty-common-4.1.74.Final.jar:4.1.74.Final] at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.74.Final.jar:4.1.74.Final] at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[netty-common-4.1.74.Final.jar:4.1.74.Final] at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_171] `

我不明白为什么它无法根据服务名获取到具体信息，请帮助我下~

Which Component Nacos Discovery

Describe the bug When I run my application and register my service instance with the config spring.cloud.nacos.discovery.ephemeral=true, by which indicates that it's a permanent service. But when I shutdown the application gracefully, the console shows that it deregisters the instance: 2022-03-28 14:22:04.197 INFO 19248 --- [ionShutdownHook] c.a.c.n.registry.NacosServiceRegistry : De-registering from Nacos Server now... 2022-03-28 14:22:04.216 INFO 19248 --- [ionShutdownHook] c.a.c.n.registry.NacosServiceRegistry : De-registration finished.

Yet it turns out doesn't deregister the instance.

I've checked the deregister code:

com.alibaba.cloud.nacos.registry.NacosServiceRegistry#deregister(Registration registration)
	@Override
	public void deregister(Registration registration) {

		...

		NamingService namingService = namingService();
		String serviceId = registration.getServiceId();
		String group = nacosDiscoveryProperties.getGroup();

		try {
			namingService.deregisterInstance(serviceId, group, registration.getHost(),
					registration.getPort(), nacosDiscoveryProperties.getClusterName());
		}
		catch (Exception e) {
			...
		}

		...
	}

com.alibaba.nacos.client.naming.NacosNamingService#deregisterInstance(String serviceName, String groupName, String ip, int port, String clusterName)
    @Override
    public void deregisterInstance(String serviceName, String groupName, String ip, int port, String clusterName)
            throws NacosException {
        Instance instance = new Instance();
        instance.setIp(ip);
        instance.setPort(port);
        instance.setClusterName(clusterName);
        
        deregisterInstance(serviceName, groupName, instance);
    }

and the ephemeral field in com.alibaba.nacos.api.naming.pojo.Instance defaults as true, which causes the bug.

Which Component Nacos Discovery

Describe the bug When I run my application and register my service instance with the config spring.cloud.nacos.discovery.ephemeral=true, by which indicates that it's a permanent service. But when I shutdown the application gracefully, the console shows that it deregisters the instance: 2022-03-28 14:22:04.197 INFO 19248 --- [ionShutdownHook] c.a.c.n.registry.NacosServiceRegistry : De-registering from Nacos Server now... 2022-03-28 14:22:04.216 INFO 19248 --- [ionShutdownHook] c.a.c.n.registry.NacosServiceRegistry : De-registration finished.

Yet it turns out doesn't deregister the instance.

I've checked the deregister code:

com.alibaba.cloud.nacos.registry.NacosServiceRegistry#deregister(Registration registration)
	@Override
	public void deregister(Registration registration) {

		...

		NamingService namingService = namingService();
		String serviceId = registration.getServiceId();
		String group = nacosDiscoveryProperties.getGroup();

		try {
			namingService.deregisterInstance(serviceId, group, registration.getHost(),
					registration.getPort(), nacosDiscoveryProperties.getClusterName());
		}
		catch (Exception e) {
			...
		}

		...
	}

com.alibaba.nacos.client.naming.NacosNamingService#deregisterInstance(String serviceName, String groupName, String ip, int port, String clusterName)
    @Override
    public void deregisterInstance(String serviceName, String groupName, String ip, int port, String clusterName)
            throws NacosException {
        Instance instance = new Instance();
        instance.setIp(ip);
        instance.setPort(port);
        instance.setClusterName(clusterName);
        
        deregisterInstance(serviceName, groupName, instance);
    }

and the ephemeral field in com.alibaba.nacos.api.naming.pojo.Instance defaults as true, which causes the bug.

spring cloud alibaba 2.2.7版本，服务启动后，修改nacos中的配置信息，线程数高速增长，能达到3K，最终oom。

版本： nacos-server:1.4.2, nacos-client:1.4.1, spring-cloud-alibaba:2.2.5

问题描述： 启动后第一次修改nacos上的配置后，控制台打印出了更新信息，但是实际的配置没有更新。之后多次修改配置都能正常更新。 配置类代码：

@Slf4j
@Data
@Component
@ConfigurationProperties(prefix = "iptables")
@RefreshScope
public class IPtablesConfig {

    // 配置属性列表
    private List<Map<String, String>> mappings;

    // 实际使用
    public static Map<String, String> ipMap = new HashMap<>();

    /** 初始化 **/
    @Bean
    public void transfer() {
        this.toMap();
    }

    /** 监听配置刷新 **/
    @EventListener
    public void envListener(EnvironmentChangeEvent event) {
        log.info("iptables change: " + event);
        this.toMap();
    }

    // 将配置的属性列表转为实际使用的map
    public void toMap() {
        // 打印实际的ip映射信息
        log.info("ip-mappings: {}", mappings.toString());

        if (mappings == null && mappings.isEmpty()) {
            log.warn("当前不存在ip映射...");
            return;
        }
        log.info("正在构建ip映射...");
        ipMap.clear();
        mappings.forEach(map -> {
            ipMap.put(map.get("priv"), map.get("pub"));
        });
    }
}

过程： 启动时：

启动后能正常拉取配置。

第一次更新：

可以看到配置更新的系统日志打印出来了，但是配置类中打印出来的信息还是未更新的。

第二次更新：

之后就可以正常刷新了。

Does this pull request fix one issue?

Fixed #2455

How to use it

set spring.cloud.nacos.config.preference to remote, remote configuration will overwrite local configuration by default.

support to set for single config

spring:
  cloud:
    nacos:
      config:
        preference: remote
  config:
    import:
      - optional:nacos:test.yml?preference=local

Which Component

按照Spring Cloud Alibaba 2021.0.1.0 升级指南升级版本

遵循毕业版本依赖关系(推荐使用)

• spring boot 2.6.3
• spring cloud 2021.0.1
• spring cloud alibaba 2021.0.1.0

nacos server版本为2.0.4

Describe what problem you have encountered

本地application.yml application-dev.yml配置如下：

application.yml

spring:
  application:
    name: bike
  profiles:
    active: dev
  cloud:
    nacos:
      discovery:
        failure-tolerance-enabled: true
  config:
    import:
      - nacos:share.yaml?refreshEnabled=true
      - optional:nacos:${spring.application.name}.yaml?refreshEnabled=true

---
spring:
  config:
    activate:
      on-profile: dev
  cloud:
    nacos:
      discovery:
        server-addr: nacos.xxxxxx.com:8848
      config:
        server-addr: nacos.xxxxxx.com:8848

application-dev.yml:

test: local...

nacos上配置了bike.yaml:

test: nacos...

我期望的结果是

nacos上的bike.yaml优化级比本地的application-dev.yml高，test值为nacos...，之前使用bootstrap引入配置就是如此。

但实际测试的结果

test值为local...

这样导致我无法在nacos动态修改application-{profile}.yml的配置

我们鼓励使用英文，如果不能直接使用，可以使用翻译软件，您仍旧可以保留中文原文。 We recommend using English. If you are non-native English speaker, you can use the translation software.

Which Component eg. Nacos Discovery, Sentinel

Describe the bug A clear and concise description of what the bug is.

NacosRule Random string of microservice calls

ALL microservice LoadBalancer use NacosRule

/**
 * 指定所有服务负载均衡策略使用nacos策略
 *
 * @return
 */
@Bean
public IRule ribbonRule() {
    return new NacosRule();
}

gateway one call service-A then call service-B

when again call service-A ，the loadBalancer is use service-B

spring-cloud-starter-alibaba-nacos-discovery version 2.2.6.RELEASE

To Reproduce

Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Additional context Add any other context about the problem here. e.g. MacOS 、Java8 、 Version 0.2.1.RELEASE

nacos version 2021.1 nacos server 2.0.3 springboot 2.5.9 springcloud 2020.0.5

redis.password=k_=.p04jTp-=d.0opFddj.hjh1hh_=.mNo0

then, nacos config can not resolve the redis.password parameter, When I use yaml file, It can run usually.