Nacos服务发现基础整理

背景

微服务通信过程中，经常出现以下的情况导致目标服务器的地址变化，引发客服端服务调用也跟着修改目标地址。

• 目标服务动态添加机器。
• 目标服务动态下架子机器。
• 目标服务的地址发生改变。

为了能解决上述问题，所以引入了一个服务发现解决方案。服务发现就是在微服务架构的开发中， 一个服务获知和另外一个服务通信细节的过程。而服务发现的具有以下机制：

1. 服务发现中心也会维护一个注册表，记录各个微服务的地址，这个是服务发现的核心部分。
2. 每个微服务启动的时候，向服务发现中心注册自己的地址。
3. 微服务，作为服务发现中心客户端，会定期去服务发现中心同步服务注册表，缓存在本地，定期更新。
4. 微服务需要请求其他微服务的时候，会在本地或服务发现中心查询注册表，获得目标地址。
5. 如果目标地址有多个，会采用负载均衡算法，选择其中一个。
6. 服务发现中心，会检测微服务的在线状态，并把变动通知到各个微服务。

而Nacos服务发现中心正是满足上述机制的解决方案。

相关解决方案

当前服务发现的流行框架：

nacos的功能支持度比较高。

nacos微服务管理模型

整体的分级模型 命名空间->服务->集群->实例

在单个的命名空间里，

通常：

命名空间到服务：体现隔离

服务到集群：体现路由

集群到实例：体现同步

nacos集成在spring cloud中的应用

采用spring-cloud-alibaba可以方便把nacos集成到spring clound应用里。

搭建并注册微服务 

在spirng cloud里使用nacos搭建的服务发现中心，和各个微服务，都是使用相同的依赖，所以在父工程里加入一下依赖：

针对各个微服务采用：

之所以中间有个web的依赖，是因为spring cloud是用http请求的方式进行微服务之间的通信。

并且每个微服务的启动类上要加注解，这个注解才是重点：

然后在微服务配置 服务发现中心

这样就把一个微服务注册到服务发现中心。

对服务发现中心的配置也类似。

spring cloud 负载均衡

负载均衡就是用分流的方式，把用户请求按一定策略，分摊到同一服务的多个机器上执行，提升高并发的能力，缓解网络压力的手段。

服务端负载均衡

 可以采用nginx实现，说白了，就是为每个微服务维护一个列表，里面是该微服务的多个实例，当一个微服务被请求的时候，从其多个实例中，按照算法选择一个出来加以转发。

客户端负载均衡

可以采用Ribbon实现，就是把服务端负载均衡的事放在客户端来做。常见算法：

• RoundRobinRule： 默认轮询的方式
• RandomRule： 随机方式
• WeightedResponseTimeRule： 根据响应时间来分配权重的方式，响应的越快，分配的值越大。
• BestAvailableRule： 过滤掉那些因为一直连接失败的被标记为跳闸的后端server，然后选择并发量最小的方式
• RetryRule： 在一个配置时间段内当选择server不成功，在指定时间内重试
• ZoneAvoidanceRule： 根据server和所在区域的性能和可用性来选择。
• AvailabilityFilteringRule： 过滤掉那些因为一直连接失败的被标记为跳闸的后端server，然后应用RoundRobinRule

扩展

说下Spring cloud 集成nacos的解决方案和dubbo的关系，Spring cloud 集成nacos是为了实现全面的微服务框架，包括了服务注册和发现，复制均衡，熔断器，网关(也是一个微服务)等。而Dubbo只是实现微服务之间通信的RPC框架。

因为dubbo 主要是rpc框架实现，由于实现的比较好，业界希望能用在微服务的通信中。而spring-cloud-alibaba,作为spring-cloud这个规范的实现，实现了这个希望。

dubbo用于微服务架构里：

整体架构也分三层，

网关：接入层

application：应用层，面向用户，经常随着用户需求的变更而变更

Service：微服层，功能上相对稳定。

而通信的选型上，

• 网关到appllication，采用feign，兼容客户端过来的http请求，比如转发header啊这些。
• 但过了appllication后，微服务之间，微服务和application之间，要讲究通信性能，所以用dubbo。

实现的环节注意dubbo协议的通信：

从以下可以看出 nocas不仅可以支持http协议的通信，还有dubbo协议等。