深入理解Nacos

大家好，欢迎来到IT知识分享网。

一、什么是Nacos，主要用来作什么?

二、哪些服务用到了Nacos?

三、Nacos是AP的还是CP的?

Nacos支持AP和CP两种模式，可以根据具体的使用场景进行选择。默认情况下是AP模式，可以通过修改nacos的配置文件来切换AP/CP。

在AP模式下，Nacos保证高可用性和可伸缩性，但不保证强一致性。在CP模式下，Nacos保证强一致性，但可能会降低可用性和可伸缩性，

在实际应用中，具体应该采用哪种模式，需要根据业务的特点和需求来判断。

如果在分布式系统中，某些数据的一致性对业务有非常高的要求，例如金融、支付等场景，那么可以选择使用CP模式。在CP模式下，当发生网络分区或故障时，为了保证数据一致性，Nacos会对服务进行自动隔密和恢复。但是，这会导致部分服务不可用，因此可用性会受到影响。

如果对于某些服务来说，可用性比一致性更加重要，例如网站、在线游戏等场景，那么可以选择使用AP模式。在AP模式下，Nacos会优先保证服务的可用性，如果发生了网络分区或故障，Nacos会在保证一定的可用性的前提下，尽可能保持数据一致性。这样虽然可能会导致数据不一致的情况，但是可以保证服务的可用性，从而减少业务的影响。

四、Nacos如何实现的配置变化客户端可以感知到?

客户端与配置中心的数据交互方式其实无非就两种，要么推，要么就是拉

推的模式就客户端和服务端建立TCP长链接，当服务端数据发生变化，立即通过这个已经建立好的长连接将数据推送到客户端。

长链接的优点是实时性，一旦数据变动，客户端立即就能感知到。但是缺点就是服务端需要维护大量的TCP连接这会占用大量的内存和CPU资源，同时也容易受到网络抖动等因素的影响。

拉的模式就是客户端轮询，通过不断轮询的方式检查数据是否发生变化，变化的话就把数据拉回来
轮询的优点是实现比较简单，但弊端也显而易见，轮询无法保证数据的实时性，并且轮询方式对服务端还会产生压为

那Nacos使用的是哪种模式呢?
在Nacos1.x版本中采用的是长轮询，看好哦，不是长连接，也不是轮询，是长轮询(Long Polling)。
在Nacos2.0中，采用qRPC长连接.

其实就是把长连接和轮询综合了一下，就是说客户端发起轮询，但是不立即返回，而是hold一段时间，这段时间保持着一个有效连接，超时或者变化再返回，然后再发起一次轮询。

1、长轮询

大概过程就是客户端向Nacos服务器发起一个长轮询请求，Nacos不会立即返回结果，而是会将请求挂起，直到有配置变化或者超时才会响应。当配置发生变化时，Nacos服务器会把变化后的配置信息响应客户端，并且客户端会再次发起一个新的长轮询请求。这样，客户端就能够实时感知到配置的变化。

这种方式避免客户端对服务端的不断轮询造成压力，也避免了长时间保持连接所带来的负担，同时也可以保证配置的实时性。但是，长轮询的缺点是需要频繁地发起HTTP请求，这会增加网络开销，同时也可能会受到网络延迟等因素的影响，导致配置的实时性不如长连接。

2、长轮询和长连接

五、Nacos能同时实现AP和CP的原理是什么?

六、Nacos 2.x为什么新增了RPC的通信方式?

Nacos 2.X 在 1.X的架构基础上，通信层通过 gRPC 和 Rsocket 实现了长连接 RPC 调用和推送能力。主要是为了改善Nacos在大规模集群环境下的性能和稳定性。

同时新增一个链接层，用来将不同类型的 Request 请求，将来自不同客户端的不同类型请求，转化为相同语意的功能数据结构，复用业务处理逻辑。同时，将来的流量控制和负载均衡等功能也会在链接层处理。

在Nacos的早期版本中，节点之间的通信采用了HTTP协议。在高并发、大规模集群环境下，由于HTTP的连接管理和请求响应的开销，会导致一些性能和稳定性方面的问题。

HTTP 短连接模型，每次客户端请求都会创建和销毁 TCP 链接，TCP 协议销毁的链接状态是 WAIT TIME，完全释放还需要一定时间，当 TPS 和 QPS 较高时，服务端和客户端可能有大量的 WAIT TIME 状态链接，从而会导致 connect time out 错误或者 Cannot assign requested address 的问题

配置模块使用 HTTP 短连接阻塞模型来模拟长连接通信，但是由于并非真实的长连接模型，因此每 30 秒需要进行-次请求和数据的上下文切换，每一次切换都有引起造成一次内存浪费，从而导致服务端频繁 GC

在大规模集群环境下，维护大量的HTTP连接会给负载均衡、路由等方面的管理带来一定的复杂性。并且HTTP协议对请求和响应的内容通常需要进行压缩和序列化处理，这也会带来一定的开销。

同时，1.0的版本中还存在以下几个问题:

为了解决这些问题，Nacos 2.x引入了qRPC的通信方式

Nacos2架构下的服务发现，客户端通过GRPC，发起注册服务或订阅服务的请求。服务端使用Client对象来记录该客户端使用qRPC连接发布了哪些服务，又订阅了哪些服务，并将该Client进行服务间同步。由于实际的使用习惯是服务到客户端的映射，即服务下有哪些客户端实例。

配置管理之前用Http1.1的Keep Alive模式30s发一个心跳模拟长链接，协议难以理解，内存消耗大，推送性能弱，因此2.0通过gRPC彻底解决这些问题，内存消耗大量降低。

• 客户端不再需要定时发送实例心跳，只需要有一个维持连接可用 keepalive 消息即可。重复 TPS 可以大幅降低。
• TCP 连接断开可以被快速感知到，提升反应速度。
• 长连接避免频繁连接开销，可以大幅缓解 TIME WAIT 问题。
• 真实的长连接，解决配置模块 GC 问题。
• 更细粒度的同步内容，减少服务节点间的通信压力。