微服务知识

Spring Cloud Netfix：Eureka，Ribbon，Feign，Hystrix，Zuul | Gateway，Config

Spring Colud Alibaba：Nacos，Sentinel，Seata

Nacos通过Ribbon实现负载均衡，Ribbon中定义了负载均衡算法，基于这些算法从服务实例中获取一个实例为消费方的提供服务

Nacos1.x架构流程 

1：服务启动时，通过调用nacos regist api发起服务注册通知nacos可以正常提供服务

2：服务消费者在启动时拉取要用到的服务列表

3：消费者每10s拉取一次数据(为了保证udp广播推送消息后的可靠性)

4：Nacos服务检测到异常(服务上下线)，会发送UDP协议给客户端进行更新

      UDP相对于TCP来说并不是可靠的协议，优点：快，耗时短，无需与目标服务建立长连接

5：客户端每5s定时发送心跳给服务端，维持健康状态检查

6：Nacos定时任务检测：每5s检查一次心跳信息来判断服务心跳状态是否正常(当前时间-上一次心跳时间)，如超过15s则将节点设置为非健康状态进行广播，如30s未有心跳消息则将节点移除

7：集群数据同步任务使用协议：Distro(AP)，Raft(CP)

Distro协议

1：naocs每个节点负责部分的写请求

2：每个节点把负责的新增数据同步给其他节点

3：每个节点定时发送自己负责数据的校验值到其他节点来保持数据一致性

4：每个节点独立处理读请求。及时从本地发出响应

5：新加入的Distro节点全量数据拉取(轮询所有Distro节点)

 Naocs配置中心长轮询机制

1.x

客户端轮询向服务端发出一个长连接请求，这个长连接30s超时，服务端收到客户端请求会先判断当前是否有配置更新，有则立即返回如果没有服务端会将这个请求hold29.5s加入队列，最后0.5s再次检测配置文件无论有无更新都进行正常返回。等待29.5s期间有配置更新提前结束并返回

2.x

服务端配置发生变更后，通过长连接通知客户端服务发生变化，客户端再拉取，并且额外增加定时任务每5s拉取一次

Nacos加载配置优先级

#作用：顺序
#${application.name}-${profile}.${file- extension}   nacos-config-prod.yaml
#${application.name}.${file-extension}   nacos-config.yaml
#${application.name}   nacos-config
#extensionConfigs  扩展配置文件
#sharedConfigs  多个微服务公共配置 redis

Nacos宕机服务或重启后读取配置信息

1：从内存读取，客户端获取配置中心的配置信息后，会在本地保存一份

2：先读取本地文件，如没有再远程拉取，拉取成功后写入本地快照，拉取失败则读取本地快照文件

Sentinel限流算法

1：计数器固定窗口算法

      通过维护一个单位时间内的计数值，每当一个请求通过将计数值加1，当计数值超过预先设定的阈值时，就拒绝单位时间内的其他请求。如单位时间已经结束，则将计数值清零，开始下一轮的计数

     缺点：临界值超过请求数问题无法解决

2：计数器滑动窗口算法

      将单位时间分成多格(格数越多，流量过度越平滑)，每经过一个格的时间，就将窗口向前移动一格，并将经过的格子丢弃进行一个窗口的计数

     缺点：格数越多，统计越精确，但实现很难预判具体单位时间拆分的格数

3：漏桶算法

      以一个常量限制出口流量速率，因此漏桶算法可以平滑突发的流量。流量容器可以看做一个FIFO队列，当入口流量速率大于出口流量速率时，超出的流量会被丢弃

     缺点：限制了流出速率，所以不支持突发流出流量

4：令牌桶算法

      令牌桶算法漏桶中存放的是令牌不是流量

       以恒定速率往令牌桶里加入令牌，令牌桶被装满时，多余的令牌会被丢弃。当请求到来时先尝试从令牌桶中获取令牌(从令牌桶移除一个令牌)，获取成功则请求放行，获取失败则拒绝请求

       令牌桶算法限制的是平均流量，因此其允许突发流量(只要令牌桶中有令牌，就不会被限流)

      

Sentinel服务熔断

熔断关闭状态：服务没有故障时，熔断器所处的状态，对调用方的调用不做任何限制

熔断开启状态：后续对服务接口的调用不再经过网络，直接执行本地的fallback方法

半熔断状态：尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率。如成功率达到预期，说明服务已恢复，进入熔断关闭状态。如成功率很低，则重新进入熔断开启状态

这篇好文章是转载于：学新通技术网