Nacos 作为目前主流的微服务中间件，包含了两个顶级的微服务功能：配置中心和注册中心。
1、配置中心扫盲
配置中心是一种集中化管理配置的服务，通俗易懂的说就是将本地配置文件“云端化”。 这样做的好处有以下几个:
当然，配置中心不可能有负载均衡的功能，所以略过，咱们直接来看注册中心。
2、注册中心扫盲
注册中心（Registry）是分布式系统中的一个组件，用于实现服务的注册与发现。注册中心用于管理服务实例的元数据信息，并提供服务发现和路由的功能。
在微服务架构中，服务之间经常需要互相调用和通信。注册中心的作用是为服务提供一个集中管理和协调的中心，默认情况下，服务将自己的信息注册到注册中心，其他服务可以通过查询注册中心的信息来发现和调用目标服务。
注册中心的核心功能包括以下几个：
- 服务注册：服务提供者在启动时将自己的信息（比如 IP 地址、端口号、服务名称等）注册到注册中心。注册中心维护着一张服务实例的清单。
- 服务发现：服务消费者通过向注册中心查询服务信息，获取可用的服务实例列表。通过注册中心，服务消费者能够找到并连接到目标服务。
- 健康检查：注册中心可以定时检查服务实例的健康状态，并根据服务的状态更新服务实例的可用性。
- 负载均衡：注册中心可以根据负载均衡策略，将请求分发给不同的服务实例，以实现负载均衡和服务高可用。
- 服务路由：在一些高级注册中心中，还可以定义服务路由规则，将请求路由到不同的服务实例，实现更灵活的流量控制和管理。
3、注册中心与负载均衡
负载均衡严格的来说，并不算是传统注册中心的功能。⼀般来说服务发现的完整流程应该是先从注 册中心获取到服务的实例列表，然后再根据自身的需求，来选择其中的部分实例或者按照⼀定的流 量分配机制来访问不同的服务提供者，因此注册中心本身⼀般不限定服务消费者的访问策略。
例如 Eureka、Zookeeper 包括 Consul，本身都没有去实现可配置及可扩展的负载均衡机制，Eureka 的 负载均衡是由 Ribbon 来完成的，而 Consul 则是由 Fabio 做负载均衡。
也就是说注册中心和负载均衡，其实完全属于两个不同的东西，注册中心主要提供服务的注册，以及将服务注册的列表交给消费者，至于消费者要使用哪种负载均衡策略？完全可以由自己决定。此时消费者可以通过客户端负载均衡器来实现服务的选择和调用，例如客户端负载均衡器 Ribbon 或 Spring Cloud LoadBalancer。
4、客户端与服务端负载均衡
客户端负载均衡器通常位于服务的消费者端，主要负责将请求合理地分发给不同的服务提供者。工作原理是客户端在发起请求前，通过负载均衡算法选择一个合适的服务实例进行请求。客户端根据服务实例的健康度、负载状况等指标来决定选择哪个服务实例。常见的客户端负载均衡器有 Ribbon、Feign 等。
服务端负载均衡器通常被称为反向代理服务器或负载均衡器，它位于服务的提供者端，接收客户端的请求，并根据一定的负载均衡策略将请求分发给后端的多个服务实例。工作原理是将客户端的请求集中到负载均衡器，由负载均衡器将请求分发给多台服务提供者。常见的服务器端负载均衡器有 Nginx、HAProxy 等。
客户端负载均衡 VS 服务端负载均衡
- 客户端负载均衡器的优点是可以实现本地的负载均衡算法，避免了对注册中心的频繁调用，降低了网络开销。它的缺点是每个客户端都需要集成负载均衡器，导致代码冗余和维护复杂性。
- 服务器负载均衡器的优点是可以集中管理请求流量，提供一致的负载均衡策略和配置，对客户端透明。它的缺点是服务器端负载均衡器通常需要独立部署和配置，增加了系统的复杂性和维护成本。并且它很可能成为整个系统的瓶颈（因为客户端需要频繁的调用），所以此时需要考虑其性能和可靠性等问题。
5、Nacos和负载均衡
然而 Nacos 的注册中心和传统的注册中心不太一样，例如 Eureka、Zookeeper、Consul 等。因为 Nacos 在 0.7.0 之后（包含此版本），它内置了以下两种负载均衡策略：
基于权重的负载均衡策略，这个在 Nacos 服务编辑的时候也可以看到其设置：
基于第三方 CMDB（地域就近访问）标签的负载均衡策略，这个可以参考官方说明文档：https://nacos.io/zh-cn/blog/cmdb.html
小结
注册中心和负载均衡器严格意义上来说是两个东西，但 Nacos 注册中心中，内置了两种负载均衡策略：基于权重和基于 CMDB（低于就近访问）的负载均衡策略。
思考
那么问题来了，既然 Nacos 中内置了基于权重的负载均衡策略，那为什么修改 Nacos 中的权重值，在服务端调用时，却没看到任何变化？
