Nacos 作为目前主流的微服务中间件,包含了两个顶级的微服务功能:配置中心和注册中心。
配置中心是一种集中化管理配置的服务,通俗易懂的说就是将本地配置文件“云端化”。 这样做的好处有以下几个:
当然,配置中心不可能有负载均衡的功能,所以略过,咱们直接来看注册中心。
注册中心(Registry)是分布式系统中的一个组件,用于实现服务的注册与发现。注册中心用于管理服务实例的元数据信息,并提供服务发现和路由的功能。
在微服务架构中,服务之间经常需要互相调用和通信。注册中心的作用是为服务提供一个集中管理和协调的中心,默认情况下,服务将自己的信息注册到注册中心,其他服务可以通过查询注册中心的信息来发现和调用目标服务。
注册中心的核心功能包括以下几个:
负载均衡严格的来说,并不算是传统注册中心的功能。⼀般来说服务发现的完整流程应该是先从注 册中心获取到服务的实例列表,然后再根据自身的需求,来选择其中的部分实例或者按照⼀定的流 量分配机制来访问不同的服务提供者,因此注册中心本身⼀般不限定服务消费者的访问策略。
例如 Eureka、Zookeeper 包括 Consul,本身都没有去实现可配置及可扩展的负载均衡机制,Eureka 的 负载均衡是由 Ribbon 来完成的,而 Consul 则是由 Fabio 做负载均衡。
也就是说注册中心和负载均衡,其实完全属于两个不同的东西,注册中心主要提供服务的注册,以及将服务注册的列表交给消费者,至于消费者要使用哪种负载均衡策略?完全可以由自己决定。此时消费者可以通过客户端负载均衡器来实现服务的选择和调用,例如客户端负载均衡器 Ribbon 或 Spring Cloud LoadBalancer。
客户端负载均衡器通常位于服务的消费者端,主要负责将请求合理地分发给不同的服务提供者。工作原理是客户端在发起请求前,通过负载均衡算法选择一个合适的服务实例进行请求。客户端根据服务实例的健康度、负载状况等指标来决定选择哪个服务实例。常见的客户端负载均衡器有 Ribbon、Feign 等。
服务端负载均衡器通常被称为反向代理服务器或负载均衡器,它位于服务的提供者端,接收客户端的请求,并根据一定的负载均衡策略将请求分发给后端的多个服务实例。工作原理是将客户端的请求集中到负载均衡器,由负载均衡器将请求分发给多台服务提供者。常见的服务器端负载均衡器有 Nginx、HAProxy 等。
然而 Nacos 的注册中心和传统的注册中心不太一样,例如 Eureka、Zookeeper、Consul 等。因为 Nacos 在 0.7.0 之后(包含此版本),它内置了以下两种负载均衡策略:
基于权重的负载均衡策略,这个在 Nacos 服务编辑的时候也可以看到其设置:
基于第三方 CMDB(地域就近访问)标签的负载均衡策略,这个可以参考官方说明文档:https://nacos.io/zh-cn/blog/cmdb.html
注册中心和负载均衡器严格意义上来说是两个东西,但 Nacos 注册中心中,内置了两种负载均衡策略:基于权重和基于 CMDB(低于就近访问)的负载均衡策略。
那么问题来了,既然 Nacos 中内置了基于权重的负载均衡策略,那为什么修改 Nacos 中的权重值,在服务端调用时,却没看到任何变化?