springboot 2.4.13 无法从nacos获取配置，但是可以注册到nacos

springboot 2413，集成了nacos，启动后，nacos注册中心有服务，但是，发现，配置没有生效。于是，开启了一段源码查找的过程。

首先，是pom引入的nacos配置

然后，applicationyml添加nacos配置

启动后，发现注册中心有服务，但是，服务的配置不是从nacos配置中心获取的，而是本地的。

查找一下nacos源码，找到nacos配置自动注入那块儿：

然后发现，是这个NacosPropertySourceLocator实现的配置导入的

查询源码，可以发现，相关的配置，是通过这个方法，加载的，这个方法是总入口。

于是，尝试加断点，查看配置信息，看看为什么没有导入配置。然而，程序根本就没有进入这个方法里面！！！

根据接口实现，可以发现NacosPropertySourceLocator 是PropertySourceLocator的实现类，这个方法的调用执行，不是nacos自己去做的，而是通过spring去做的。

spring cloud 通过BootstrapApplicationListener，以监听器的方式，通过监听springboot启动过程中的事件，通过onApplicationEvent方法处理事件，导入spring cloud相关配置。

通过加断点，可以发现，这里的方法bootstrapEnabled()返回值是false，直接就不执行后续的加载了。

因此，需要保证bootstrapEnabled返回值是true。

查看PropertyUtils源码，可以发现，需要配置项 springcloudbootstrapenabled=true 并且存在 orgspringframeworkcloudbootstrapmarkerMarker 类的时候，spring cloud 才会去加载spring cloud的配置。

因此，pom中需要添加marker所在的组件依赖：

此时，需要在 bootstrapyml 中添加spring cloud配置：

（至于为什么是bootstrapyml而不是applicationyml，这又是另一个问题了）

有了上面的配置，程序启动后，就能正常的从nacos配置中心获取配置了。

一、服务注册中心的由来

假如没有服务注册中心，我们会干些什么事情呢？

在传统行业的项目架构中以下的方案最为常见了：

这种架构开发、部署都是最简单的，一般适用于中小企业访问量并不是太多的情况下，各个系统服务一台机器就搞定了。系统之间的调用也是拿到对方的IP+PORT直接连接。

接下来可能因为应用B开始访问量大了，单台机器已经不能满足我们的需求，于是一些反向代理工具应运而出，其中比较常见的有Apache、Nigix，架构演变为：

相比之前的应用B的单台机器访问，这种nginx代理的方式减轻了服务器的压力，但是可能会出现Nginx挂了，那么整个服务也不可用，于是又来了这么一套架构：

这样看方案算是完美了吧。然后事情并不是想象的那么一帆风顺，这还只是应用A调用一个应用B，如果应用A调用的可能是应用B、C、D、E，这种完全就不知道他后面到底还想干嘛，这种架构看似可以，但是绝对会累死运维的（nginx的配置将会非常混乱，直接导致运维不干了）。

服务注册中心干些什么事情呢？

上面提到的那种靠人力（主要是运维干的事情）比较繁琐，还不好维护，有这么几点不方便：应用服务的地址变了、双十一搞活动服务器新增等等。那么我们可以有这么的一种架构：

    服务注册中心主要是维护各个应用服务的ip+port列表，并保持与各应用服务的通讯，在一定时间间隔内进行心跳检测，如果心跳不能到达则对服务IP列表进行剔除，并同时通知给其它应用服务进行更新。同样要是有新增的服务进来，应用服务会向注册中心进行注册，服务注册中心将通知给其它应用进行更新。每个应用都有需要调用对应应用服务的地址列表，这样在进行调用时只要处理客户负载杂均衡即可。

二、微服务注册中心

1Zookeeper

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

上面的话直接摘抄的内容，国内很多公司做分布式开发最初的选型大部分都是采用dubbo框架。dubbo框架注册中心主要使用zookeeper。zookeeper服务端与客户端的底层通讯为netty。zookeeper采用CAP理论中的CP，一般集群部署最少需要3台机器。

2Euraka

先来看一下euraka的架构图：

Register：服务注册

当Eureka客户端向Eureka Server注册时，它提供自身的元数据，比如IP地址、端口，运行状况指示符URL，主页等。

Renew：服务续约

Eureka客户会每隔30秒发送一次心跳来续约。 通过续约来告知Eureka Server该Eureka客户仍然存在，没有出现问题。 正常情况下，如果Eureka Server在90秒没有收到Eureka客户的续约，它会将实例从其注册表中删除。 建议不要更改续约间隔。

Fetch Registries：获取注册列表信息

Eureka客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与Eureka客户端的缓存信息不同， Eureka客户端自动处理。如果由于某种原因导致注册列表信息不能及时匹配，Eureka客户端则会重新获取整个注册表信息。 Eureka服务器缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka客户端和Eureka 服务器可以使用JSON / XML格式进行通讯。在默认的情况下Eureka客户端使用压缩JSON格式来获取注册列表的信息。

Cancel：服务下线

Eureka客户端在程序关闭时向Eureka服务器发送取消请求。 发送请求后，该客户端实例信息将从服务器的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容：

DiscoveryManagergetInstance()shutdownComponent()；

Eviction 服务剔除

在默认的情况下，当Eureka客户端连续90秒没有向Eureka服务器发送服务续约，即心跳，Eureka服务器会将该服务实例从服务注册列表删除，即服务剔除。

自我保护机制：

既然Eureka Server会定时剔除超时没有续约的服务，那就有可能出现一种场景，网络一段时间内发生了 异常，所有的服务都没能够进行续约，Eureka Server就把所有的服务都剔除了，这样显然不太合理。所以，就有了 自我保护机制，当短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下， Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关(eurekaserverenableself-preservation: false)

3Consul

consul推荐的架构图：

Consul不像Euraka的部署那么简单，他是go语言开发的，需要运维单独部署，有提供java的客户端连接，采用的是CAP的CP。

4Nacos

    Euraka是Spring Cloud Netflix早期版本中推荐使用的，后来euraka10版本不再维护，euraka20已经闭源，导致很多新项目基于Spring Cloud Netflix 开发的选型变迁为Consul

Nacos是阿里开源的服务注册中心，它可以与spring cloud aliaba集成使用。

Nacos的官方介绍：

    Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您实现动态服务发现、服务配置管理、服务及流量管理。

    Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构(例如微服务范式、云原生范式)的服务基础设施。

Nacos 地图

Nacos 生态图

如 Nacos 全景图所示，Nacos 无缝支持一些主流的开源生态，例如

Spring Cloud

Apache Dubbo and Dubbo Mesh TODO

Kubernetes and CNCF TODO

三、服务注册与发现技术选型

以下是来自网上的一个分享：

除了上述的几种以外，笔者更推荐使用Nacos作为服务注册中心。

推荐理由：

Nacos服务注册表结构Map<namespace, Map<group::serviceName, Service>>采用多层次Map结构，控制的颗粒度更细，支持金丝雀模式发布，心跳同步机制也更快速，服务更新更及时。

在nacos+config中，可以使用@NacosValue注解动态刷新private static类型的属性。但是private static类型的属性是属于类的，而不是属于对象的，因此不能使用普通的setter方法来动态刷新其值。

以下是一个示例代码，演示了如何使用@NacosValue注解来动态刷新private static类型的属性：

import comalibabanacosapiconfigannotationNacosValue;import orgspringframeworkstereotypeComponent;@Componentpublic class Config {    @NacosValue(value = "${a}", autoRefreshed = true)

private static int a;    public static int getA() {        return a;

}

}

在上面的示例代码中，使用了@NacosValue注解来标记a属性。其中，value属性表示nacos配置中心中的配置项名称，${a}表示从配置中心获取名称为a的配置项的值，并将其赋值给a属性。autoRefreshed属性表示是否开启自动刷新功能，如果开启，则当配置中心中的配置项发生变化时，a属性的值也会相应地发生变化。

在使用private static类型的属性时，需要注意以下几点：

需要提供一个公共的getter方法，用于获取属性的值；

不能提供setter方法，因为private static类型的属性属于类，而不是对象，不能通过setter方法动态修改其值；

在使用@NacosValue注解时，需要将其标记在属性上，而不是标记在getter方法上；

在上述示例中，因为a属性是private static类型，因此不能提供setter方法，只能提供一个公共的getter方法getA()。当配置中心中的a配置项发生变化时，@NacosValue注解会自动更新a属性的值，因此可以通过ConfiggetA()方法获取最新的值。

需要注意的是，对于private static类型的属性，因为其属于类，因此在多线程环境下可能会存在线程安全问题。因此，应该尽量避免使用private static类型的属性，或者采取合适的线程安全措施。