| 问题 | 关键词/关键概念 |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| Nacos如何实现配置变化客户端感知？| **长轮询(1.x)**：30s超时、hold住请求、有变化立即返回<br>**长连接(2.x)**：gRPC双向流、配置变更主动推送、实时性更高<br>**本地缓存**：容灾降级、快照文件 |
| Nacos 2.x为什么新增RPC通信方式？| **性能提升**：长连接复用、减少连接开销<br>**实时性**：服务端主动推送、毫秒级感知<br>**资源优化**：减少HTTP短连接、降低CPU/内存消耗<br>**双向通信**：gRPC支持流式通信、连接状态监测 |
| Nacos是AP还是CP？| **双模式支持**：<br>**临时实例**：AP模式、Distro协议、最终一致性<br>**持久实例**：CP模式、Raft协议、强一致性<br>默认临时实例(AP) |
| Nacos同时实现AP和CP的原理？| **双协议架构**：<br>**Distro协议(AP)**：去中心化、数据分片、异步同步、最终一致<br>**Raft协议(CP)**：Leader选举、日志复制、强一致保证<br>**实例类型区分**：ephemeral=true临时AP、ephemeral=false持久CP |
| 什么是Nacos？主要作用？| **定义**：Dynamic Naming and Configuration Service<br>**功能**：服务注册发现、配置管理、服务管理平台<br>**特性**：多数据中心、健康检查、动态配置、路由策略、流量管理 |
| 注册中心如何选型？| **Nacos**：功能全面、支持AP/CP、配置中心一体<br>**Eureka**：AP模式、Netflix停更、简单易用<br>**Consul**：CP模式、KV存储、多数据中心<br>**Zookeeper**：CP模式、强一致、选举风暴问题 |
# Nacos核心架构详解
## **整体架构**
```Java
客户端层
├── 服务注册/发现 SDK
├── 配置管理 SDK
└── OpenAPI
网络层（2.x新增）
├── gRPC 长连接
└── HTTP 短连接（兼容）
核心功能层
├── Naming Service（服务注册）
│ ├── AP模式(Distro)
│ └── CP模式(Raft)
├── Config Service（配置管理）
└── Health Check（健康检查）
存储层
├── 内存存储（服务数据）
└── 持久化存储（MySQL/嵌入式DB）
```
## **Nacos 2.x升级要点**
### **通信模型演进**
```Java
1.x版本：HTTP短连接
├── 问题：连接开销大、轮询延迟、资源消耗高
└── 方案：长轮询机制(30s)
2.x版本：gRPC长连接 + HTTP兼容
├── 优势：连接复用、双向通信、实时推送
├── 性能：QPS提升3倍、RT降低90%
└── 兼容：保留HTTP接口
```
## **配置变更感知机制**
### **1.x长轮询模式**
```java
// 客户端
while(true) {
// 发起长轮询请求，超时30s
Response resp = httpClient.get("/config", 30s);
if (resp.hasChange()) {
updateConfig();
}
}
// 服务端
if (configChanged) {
response.immediately(); // 立即返回
} else {
hold(request, 29.5s); // 挂起请求
}
```
### **2.x长连接推送**
```java
// 建立gRPC双向流
StreamObserver<ConfigChangeRequest> requestStream =
stub.listenConfig(responseObserver);
// 服务端主动推送
configChangeEvent → gRPC推送 → 客户端实时接收
```
## **AP与CP模式实现**
### **AP模式(Distro协议)**
```Java
特点：
- 去中心化架构
- 每个节点平等
- 数据分片存储
- 异步同步机制
数据同步：
Node A → 异步同步 → Node B
→ 异步同步 → Node C
最终一致性保证
```
### **CP模式(Raft协议)**
```Java
特点：
- Leader/Follower架构
- 强一致性保证
- 日志复制机制
- 多数派确认
写入流程：
Client → Leader → 日志复制 → Followers
→ 多数确认 → 提交
```
## **实例类型对比**
|特性|临时实例(AP)|持久实例(CP)|
|---|---|---|
|**一致性**|最终一致|强一致|
|**可用性**|高可用|可能不可用|
|**健康检查**|客户端心跳|服务端主动检测|
|**使用场景**|微服务注册|基础服务、DNS|
|**性能**|高性能|性能较低|
|**存储**|内存|持久化|
## **注册中心选型对比**
|对比项|Nacos|Eureka|Consul|Zookeeper|
|---|---|---|---|---|
|**一致性**|AP+CP|AP|CP|CP|
|**健康检查**|TCP/HTTP/MySQL|心跳|TCP/HTTP/Script|Keep Alive|
|**多数据中心**|支持|不支持|支持|不支持|
|**配置中心**|内置|无|KV存储|需二次开发|
|**界面**|内置控制台|有|有|无|
|**性能**|高|中|中|中|
|**社区活跃度**|高(阿里)|低(停更)|中|高|
## **最佳实践**
### **服务注册**
```yaml
spring:
cloud:
nacos:
discovery:
ephemeral: true # 临时实例(AP)
heart-beat-interval: 5000 # 心跳间隔
heart-beat-timeout: 15000 # 心跳超时
```
### **配置管理**
```yaml
spring:
cloud:
nacos:
config:
refresh-enabled: true # 动态刷新
group: DEFAULT_GROUP
file-extension: yaml
```
## **性能优化建议**
1. **2.x版本**：优先使用2.x版本，性能提升明显
2. **连接池**：合理配置gRPC连接池大小
3. **集群部署**：至少3节点保证高可用
4. **存储优化**：使用外置MySQL集群
5. **监控告警**：接入Prometheus监控