当前位置：首页 > news >正文

彻底理解微服务配置中心的作用

news 来源：原创 2025/5/18 4:51:26

常见的配置中心有SpringCloudConfig、Apollo、Nacos等，理解它的作用，无非两点，一是配置中心能做什么，不使用配置中心会出现什么问题。

作用：配置中心是用来集中管理服务的配置，它是用来提高系统配置的维护性、时效性、安全性。

本文主要通过目前最流行的Nacos来进行分析，先看下图：

一.在微服务架构中，服务少则几十个，多则上百个，在这种状态下，如果还用以前传统的配置文件方式，会出现哪些问题？

1.维护性差：比如说我每个服务比如都连接了Redis，一旦Redis的服务器IP发生了更改，那么就需要把所有服务的配置文件中的Redis配置进行修改，这样的话，维护性非常的差；

2.时效性差：比如Redis配置，先修改了A服务，然后重启A服务，此时B、C、D......等服务都还没有重启，那么就不能保证它的数据一致性，所以我们需要最好的保证它的时效性，也就是说修改完以后，所以服务最好立马感知到并进行重启，这样才能最大程度保证它的时效性，保证了时效性才能保证它们的一致性；

3.安全性差：如果这些配置都维护在本地代码中，开发人员都可以看到，如果碰到恶心的公司不发公司，那么开发人员直接知道Redis、Mysql的远程地址等，直接可以删除跑路(但不建议，最好走仲裁~)，这样就有安全隐患。

如果我们把所有配置放在一个Nacos的配置中心里面统一进行管理，那么就可以非常方便的给它做一些配置，比如说双11大促开始，可以给Redis服务切换到性能高的Redis服务器上去，或者说切换到不同的Redis上去等等，还可以动态的去配置一些限流的策略，然后等大促完了后，可以把策略关掉，切回Redis服务，这种情况下不需要修改原本服务的配置，非常方便。

二.有哪些东西可以作为配置？

1.比方说，数据库连接Url，缓存连接ur字符串，数据库的用户名，密码都可以作为配置的字符串，除此之外，还有一些可以动态调整的参数等等(比如说A服务做了集群，一单数据库地址修改，集群的所有服务都需要进行修改，如果有配置中心，就只需要修改配置中心即可，它会让A服务实时的拉取配置)；

2.比方说，客户端的超时设置限流规则和降级开关，流量的动态调度；

3.比方说，某个功能只是针对某个地区用户，还有某个功能只在大促的时段开放。

如果这种需要通过静态的方式去配置或者发布的方式去配置，那么响应速度是非常慢，配置修改后，重启了第一台服务，其他服务还没有重启，就对业务存在风脸，如果有一套集中式的配置中心，只需要相关人员在配置中心动态去调整参数，就基本上可以实时或准实时去调整相关对应的业务，所以配置中心在微服务中算是一个举足轻重的组件。

三.微服务是怎么获取到配置中心的数据的，是推还是拉？

了解了 Nacos 的配置管理的功能后，还有一个问题需要弄明白，那就是 Nacos 客户端是怎么实时获取到 Nacos 服务端的最新数据的，其实客户端和服务端之间的数据交互，无外乎两种情况：服务端推数据给客户端和客户端从服务端拉数据，那到底是推还是拉呢，从 Nacos 客户端通Listener 来接收最新数据进行分析，如下图：

每当为一个Nacos客户端配置了配置中心，就会有一个监听器(Listener)，这个监听器就会结合一个定时任务实现一个长轮询的缓存池(LongPollingCachePool)，长轮询的缓存池会实时的去Nacos的配置中心拉取数据，会将本地缓存(CacheData)的MD5值和服务端的MD5值(compareMd5)做对比，如果对比不上，就说明发生了变法，一旦发送了变化，就会把新数据拉取(change)过来，然后再存如到CacheData中，然后重新的计算MD5的值，下一次还是继续比对MD5的值，如果比对不上，就说明又发生了变化，就会继续拉取对象的数据存入本地，当CacheData一旦发生了变化，就会触发Listener的回调方法，就是通知服务的配置数据进行相应的改变。

原理:
Nacos 服务端创建了相关的配置项后，客户端就可以进行监听了，客户端是通过一个定时任务来检査自己监听的配置项的数据的，一旦服务端的数据发生变化时，客户端将会获取到最新的数据，并将最新的数据保存在一个 CacheData 对象中，然后会重新计算 cacheData 的 md5 属性的值，此时就会对该 CacheData 所绑定的 Listener 触发 receiveconfginfo(接收配置信息) 回调。

拉的优势：

因为如果用推的方式，服务端需要维持与客户端的长连接(比如推的方式，如果有上百个客户端，一旦发生修改，就需要通知上百个服务，服务端压力就会变大)，这样的话需要耗费大量的资源，并且还需要考虑连接的有效性，例如需要通过心跳来维持两者之间的连接(如果服务端和客户端的连接失效，就不会给客户端推)，而用拉的方式，客户端只需要通过一个无状态的 http 请求即可定时获取到服务端的数据(这样压力就分发到了每一个Nacos的客户端，减轻服务端压力)。

相关文章：