Java微服务的注册中心Nacos

Nacos的主要作用

• 配置中心:可以将微服务中的一些配置信息放到Nacos进行统一管理，也可以通过Nacos实现动态配置管理。也可以将不同环境的配置放在不同的Namespace下的group下，实现动态选择配置发布部署。
• 服务注册与发现:服务启动的时候指定注册中心为Nacos，可以将服务注册到Nacos，通过Nacos可以实现服务自动发现与负载均衡与服务的上下线。
• 服务治理：可以在Nacos实现服务的健康监控、服务限流、故障、降级。
• 动态配置: 服务在运行过程中，一些配置参数的变化可以通过Nacos的时间监听和配置来实现。

Nacos实现动态配置更新的技术

• 常见的配置更新所采用的技术推和拉

  • 推：服务端与客户端建立一个长链接，当服务端发现配置变化后通过这个已经存在的长链接推送给客户端。这样虽然实时性高，但是一只占用着大量的TCP链接，我们很少去改动配置造成内存与CPU的浪费，同时容易收到网络影响。
  • 拉：客户端启动一个定时器不停的轮询，当发现配置发生变动时就拉下来更新。实时性不能保障，而且轮询会造成服务端压力。

• Nacos1.0 为了解决这个问题采用的是长轮询

  • 长轮询就是每隔一段时间发起一个请求（这个请求有超时时间），服务端接收到请求后并不会立即返回，会将当前的请求挂起，当过程中有配置变化或者达到挂起时间了还没有拿到结果才会返回给客户端。 这样既避免了频繁的轮询，也避免了长时间的占用连接。但缺点就是不能实时感知也会有网络压力。折中办法。

• Nacos2.0 为了解决这个问题采用的是gRpc长连接

  • gRPC是一种高性能、‌开源的远程过程调用（‌RPC）‌框架，‌由Google在2015年开源。‌它基于HTTP/2协议，‌并使用Protocol Buffers作为接口定义语言（‌IDL）‌，‌提供了一种简单、‌快速、‌高效的方式来连接服务。‌gRPC的设计目标是为服务器和服务器之间的通信提供一个统一的、‌强大的解决方案，‌同时支持多种语言和平台。‌在gRPC中，‌客户端可以像调用本地对象一样直接调用另一台不同机器上服务端应用的方法，‌这使得创建分布式应用和服务变得更加容易

Nacos实现CAP

Nacos支持CP和AP的切换，默认是AP。
在AP模式下能保障高可用与可扩展性，但不能保障一致性。
在CP模式下能保障强一致性，但不能保障可用性和扩展性。(CP模式下当发生网络分区或故障时，Nacos会自动将服务进行隔离这样会导致服务不可用)

Nacos实现CAP原理

Nacos 1.0 实现CP的原理是采用Raft 2.0是JRaft，实现AP的原理是采用Distro协议
[https://blog.csdn.net/zcrzcrzcrzcrzcr/article/details/122260705]

Nacos 使用Distro 和 Raft 分别干什么用？

1. Nacos 使用 Distro 协议

• Distro 协议是 Nacos 社区自研的一种AP分布式协议，主要用于处理临时实例数据的一致性。该协议的特点包括：
  • 面向临时实例设计：Distro 协议是专为临时实例设计的分布式协议，确保在某些 Nacos 节点宕机后，整个临时实例处理系统依旧可以正常工作。
  • 节点平等：在 Distro 协议下，每个 Nacos 节点都是平等的，都可以处理写请求，并将新数据同步到其他节点。这种设计提高了系统的可用性和容错性。
  • 数据一致性：每个节点只负责部分数据，通过定时发送自己负责数据的校验值到其他节点来保持数据一致性。同时，每个节点独立处理读请求，及时从本地发出响应，保证了读操作的及时性和高效性。
  • 内存存储：Distro 协议管理的数据存储在缓存中，不需要将数据持久化到磁盘或数据库，这减少了磁盘I/O操作，提高了系统性能。

2. Nacos 使用 Raft 协议

• Raft 协议是一种强一致性、去中心化、高可用的分布式协议，Nacos 使用它来处理非临时数据的一致性。Raft 协议的特点包括：
  • 领导者选举：Raft 协议通过领导者选举机制确保系统中的所有节点都达成一致的领导者。领导者负责处理客户端的请求，并将请求以日志的形式追加到自己的日志中，然后复制到其他节点，确保数据的一致性。
  • 日志复制：领导者将客户端的请求以日志的形式追加到自己的日志中，并并行发送给其他节点。当大多数节点都复制了某个日志条目时，该条目就被认为是已提交的，从而保证了数据的一致性。
  • 容错性：Raft 协议能够容忍一定程度的节点故障和网络分区，确保在节点故障或网络分区的情况下，系统仍然能够正常工作并保持数据的一致性。
  • 动态成员关系：Raft 协议支持动态成员关系，允许系统在运行时动态添加或移除节点，提高了系统的灵活性和可扩展性。

ZAB与Raft的区别

• ZAB算法：全称是Zookeeper Atomic Broadcast，是专门为分布式协调服务Zookeeper设计的一种支持崩溃恢复的原子广播协议。它的主要目的是在Zookeeper集群中保证数据的一致性和服务的可用性。

• Raft算法：是一种用于管理日志复制和集群成员变更的共识算法。它旨在提供一种易于理解和实现的共识算法，用于构建可靠和可伸缩的分布式系统。

• 选举机制

  • ZAB算法：
    • 选举原则：结合节点ID（myid）和事务ID（zxid）进行选举。zxid越大表示数据越新，myid则用于在zxid相同的情况下决定领导者。
    • 节点状态：包括LOOKING（寻找Leader状态）、FOLLOWING（跟随者状态）、OBSERVING（观察者状态）和LEADING（领导者状态）。
    • 选举过程：当集群启动或领导者宕机时，处于LOOKING状态的节点会发起选举，通过比较zxid和myid的大小来确定领导者。
  • Raft算法：
    • 选举原则：基于“大多数派”原则，即获得过半投票的节点成为领导者。
    • 节点状态：包括Follower（跟随者状态）、Candidate（候选者状态）和Leader（领导者状态）。
    • 选举过程：节点通过随机超时时间触发选举，成为Candidate后向其他节点发送请求投票RPC消息，若获得过半投票则成为Leader。

• 数据一致性与容错性

  • ZAB算法：
    • 通过原子广播协议确保数据的一致性，即所有服务器上的数据都是一致的。
    • 支持崩溃恢复，能够在领导者宕机后快速选举出新的领导者，并从新的领导者同步数据。
  • Raft算法：
    • 同样保证数据的一致性，通过日志复制和提交机制确保所有节点上的日志内容是一致的。
    • 具有较高的容错性，能够容忍一定程度的节点故障和网络分区。

• 适用场景与特性

  • ZAB算法：
    • 特别适用于需要高可靠性和一致性的分布式协调服务场景，如Zookeeper。
    • 优化了数据新鲜度，尽可能保证数据的最新状态。
  • Raft算法：
    • 适用于各种需要共识机制的分布式系统场景，如分布式数据库、配置中心等。
    • 选举过程简单明了，易于实现和部署。
    • 通过任期机制和心跳信息确保系统的稳定性和一致性。