nocas
2021-01-12 22:17:18 3 举报AI智能生成
登录查看完整内容
nacos
作者其他创作
大纲/内容
nocas
基础
高可用
nacos-client 重试保证高可用
nacos-client 端发起请求时，成功立即返回，失败则逐个重试，直到成功
nacos-server 端 一致性协议 distro 保证高可用
临时服务
临时服务健康检查失败后会从列表中删除，常用于服务注册发现场景。
服务注册发现场景，私有协议 distro，一致性模型为AP
持久化服务
持久化服务健康检查失败后会被标记成不健康，常用于 DNS ，配置中心场景。
与zk一致，转发给leader写然后同步给follwer和observer
raft算法实现
1.每个节点启动时RaftCore会创建两个定时任务，一个是选举，一个心跳
2.同时每个服务的leaderDueMs等待的时间是随机的0-15s
3.leaderDueMs小于0时，发起选举，term轮次自增，向其他节点发送投票请求
4.其他节点term<选举发起节点的term，投发起选举的节点
5.谁先发起谁当选leader
6.选举term每次加1，而发布内容term每次加100。100其实就是允许重新发起投票的次数，这个数字越大越安全
7.只有leader可以向其他节点发起心跳，其他节点收到心跳会重置leaderDueMs，如果长时间没有心跳，leaderDueMs<0后发起选举
角色
LEADER
FOLLOWER 同步或上报信息给leader
CANDIDATE 领导候选者
distro协议流程
Nacos 启动时首先从其他远程节点同步全部数据。
Nacos 每个节点是平等的都可以处理写入请求，同时把新数据同步到其他节点。（临时节点）
与zk不同，zk leader写然后同步给follwer和observer
每个节点只负责部分数据，定时发送自己负责数据的校验值到其他节点来保持数据一致性。
写请求
当该节点接收到属于该节点负责的服务时，直接写入
当该节点接收到不属于该节点负责的服务时，将在集群内部路由，转发给对应的节点，从而完成写入。
读请求
集群中的各个节点会同步服务状态，每个节点都会有一份最新的服务数据。都能响应读请求
当该节点宕机后，原本该节点负责的一部分服务的写入任务会转移到其他节点，从而保证 Nacos 集群整体的可用性。
网络分区，客户端会表现为有时候服务存在有时候服务不存在
nacos-client 本地缓存文件 Failover 机制 保证高可用
整个 Server 端宕机
Dubbo 内存里面是存了一份地址，依然不影响RPC调用
为了性能，因为不可能每次 RPC 调用时都读取一次注册中心，缓存机制
注册中心宕机后内存会有一份数据，这也起到了可用性的保障
Nacos 注册中心宕机，Dubbo 应用发生重启
Failover 机制，依然不影响RPC调用
nacos-client 在接收到 nacos-server 的服务推送之后，会在内存中保存一份，随后会落盘存储一份快照。snapshot 默认的存储路径为：{USER_HOME}/nacos/naming/ 中
用来排查服务端是否正常推送了服务
当客户端加载服务时，如果无法从服务端拉取到数据，会默认从本地文件中加载。
开启该参数的方式：dubbo.registry.address=nacos://127.0.0.1:8848?namingLoadCacheAtStart=true
心跳同步服务 提升了可用性
一个心跳报文包含了全部的服务信息
nacos-server 节点全部宕机，服务数据全部丢失。nacos-server 即使恢复运作，也无法恢复出服务，而心跳包含全部内容可以在心跳期间就恢复出服务，保证可用性。
nacos-server 出现网络分区。由于心跳可以创建服务，从而在极端网络故障下，依旧保证基础的可用性。
推+拉 客户 配置信息实时更新
注册中心的区别
eurka和nacos
1.eureka是需要通过maven加载依赖后，搭建server服务部署；nacos是通过下载alibaba打好的jar进行部署
2.eureka控制台粗糙，不能区分namespace；nacos有更人性化的控制
3.eureka本身没有配置中心，才有git或svn的地址配置文件；nacos有动态配置中心，类似apollo
4.高可用，eureka比较简单，在调用方配置注册中心地址；nacos需要配置虚拟ip实现高可用
5.eureka注册基于服务；nacos注册基于接口
6.eureka 客户端注册服务上报所有信息，节点多的情况下，网络，服务端压力过大，且浪费内存，同时集群伸缩性不强，服务端集群通过广播式的复制，增加服务器压力；nacos 服务注册发现 ，distro协议每个服务负责部分节点，容易扩容且单个服务压力不大
7.eureka客户端更新服务信息通过简单的轮询机制，当服务数量巨大时，服务器压力过大；nacos 客户端长轮询30s超时（有更细立即返回）+ 服务端延时队列29.5s左右（变更事件通知立即返回响应）
8.Eureka2.0 闭源；nacos 阿里开源
0 条评论
回复 删除
下一页
