147 lines
6.2 KiB
Markdown
147 lines
6.2 KiB
Markdown
---
|
||
tags: [test/review, architecture, arch/microservice, service-discovery]
|
||
create time: 2026-08-09 12:00
|
||
---
|
||
|
||
# 服务注册与发现 — 测试题
|
||
|
||
## 概述
|
||
本测试覆盖服务注册/注销/续约流程、Eureka/AP 取向、Nacos CP/AP 可切换、Consul 特性以及 CAP 理论在注册中心中的体现。共 10 道题目（6 选择 + 3 填空 + 1 简答）。
|
||
|
||
---
|
||
|
||
## 一、选择题（6道，由浅入深）
|
||
|
||
> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
|
||
|
||
### Q1（基础）— 考察定义层面
|
||
|
||
服务注册的标准三步走流程是：
|
||
|
||
A. 注册 → 查询 → 注销
|
||
B. 注册 → 续约（心跳）→ 注销
|
||
C. 发现 → 健康检查 → 更新
|
||
D. 心跳 → 续约 → 下线
|
||
|
||
### Q2（基础）→
|
||
|
||
Eureka 的自我保护机制在什么条件下会被触发？
|
||
|
||
A. 15 分钟内超过 50% 实例未发送心跳
|
||
B. 15 分钟内超过 85% 实例未发送心跳
|
||
C. 所有实例同时宕机
|
||
D. 注册中心 CPU 使用率超过 90%
|
||
|
||
### Q3（进阶）— 核心原理
|
||
|
||
Nacos 在同一套代码中为什么能既支持 AP 又支持 CP 模式？
|
||
|
||
A. 通过动态切换一致性协议实现，运行时修改配置即可
|
||
B. 两种模式使用不同的数据存储路径和服务类型
|
||
C. Nacos 有两个独立的二进制进程分别处理 AP 和 CP
|
||
D. 基于 K8s Namespace 做逻辑隔离
|
||
|
||
### Q4（进阶）— 比较/辨析
|
||
|
||
Consul 的三个独特优势不包括以下哪一项？
|
||
|
||
A. Serf Gossip 协议的成员管理
|
||
B. 丰富的健康检查方式（TCP/HTTP/script/Docker/TTL）
|
||
C. 内嵌 Raft 一致性的 KV 存储
|
||
D. 原生支持多级缓存（本地 + 远程）
|
||
|
||
### Q5（深入）— 场景推理
|
||
|
||
某金融系统对数据一致性要求极高，在选型服务注册中心时最应该考虑哪个因素？
|
||
|
||
A. 需要高可用容忍短暂不一致 → 选 Eureka
|
||
B. 需要强一致性 → 选 Nacos CP 模式或 Consul TCP 接口
|
||
C. DNS 接口最快 → 选 Consul DNS
|
||
D. 客户端缓存最可靠 → 选 Eureka 并关闭自我保护
|
||
|
||
### Q6（深入）— 源码级/边界场景
|
||
|
||
PACELC 理论对 CAP 做了哪些补充？
|
||
|
||
A. PACELC 指出无分区时也需权衡延迟与一致性
|
||
B. PACELC 指出分区恢复后需先进行数据同步再服务
|
||
C. PACELC 引入了第三维度——性能，CAP 只有两个维度
|
||
D. PACELC 证明 CAP 定理在分布式系统中是错误的
|
||
|
||
---
|
||
|
||
## 二、填空题（3道）
|
||
|
||
### F1 — 填空1
|
||
|
||
Eureka 的消费者会**缓存**服务列表，默认每 _____ 秒刷新一次。这样即使注册中心完全不可用，消费方依然能根据本地缓存继续通信。
|
||
|
||
> **提示**: 回顾原文 Eureka 小节中关于客户端缓存的描述。
|
||
|
||
### F2 — 填空2
|
||
|
||
Consul 的 DNS 接口因为是 _____ 模式的——直接指向随机节点读取本地内存缓存，不经过 Raft 日志——所以速度极快但可能读到旧数据。
|
||
|
||
> **提示**: 回想 CAP/PACELC 表格中 Consul DNS 的行。
|
||
|
||
### F3 — 填空3
|
||
|
||
Nacos 通过 _____ 实现环境隔离（dev/test/prod），每个命名空间有独立的服务和配置视图。底层基于 PostgreSQL 存储元数据。
|
||
|
||
> **提示**: Nacos 的环境隔离术语来自 Kubernetes。
|
||
|
||
---
|
||
|
||
## 三、简答题（1道）
|
||
|
||
### S1
|
||
|
||
面试官问你："Eureka 的自我保护机制在生产环境中什么时候该关？"请给出你的完整回答，包括：
|
||
- 自我保护机制的作用是什么
|
||
- 关了会有什么风险
|
||
- 什么场景下可以关
|
||
- 如果不关应该如何监控
|
||
|
||
> **答题框架提示**:
|
||
> 1. 解释机制的原理和风险
|
||
> 2. 分场景讨论
|
||
> 3. 给出具体的监控建议
|
||
|
||
---
|
||
|
||
## 参考答案与解析
|
||
|
||
### 选择题答案
|
||
|
||
| 题号 | 正确答案 | 解析 |
|
||
|------|---------|------|
|
||
| Q1 | B | 标准三步：① 注册服务（POST /register）；② 心跳续约（维持 lastDirtyTimestamp）；③ 主动注销（DELETE /deregister）。故障场景下感知延迟通常为续约超时周期（30~90 秒）。 |
|
||
| Q2 | B | 15 分钟内超过 85% 实例未发心跳触发保护窗口锁定，不再剔除任何实例。宁可多调几次失败也不主动剔。 |
|
||
| Q3 | B | 不同模式使用不同的存储路径和服务类型：CP 用 `nacos.v1.auth.user`（Raft），AP 用 `nacos.v1.instance`（Distro）。不是运行时切换而是物理隔离的路径。 |
|
||
| Q4 | D | Consul 的优势是 Serf Gossip、丰富健康检查、KV 存储。多级缓存不是 Consul 的功能，那是 Redis/Caffeine 层的职责。 |
|
||
| Q5 | B | 金融系统需要强一致性，应选 Nacos CP 模式（Raft）或 Consul TCP 接口（Raft Leader）。Eureka 最终一致不适合。DNS 可能 stale。关闭自我保护会增加雪崩风险。 |
|
||
| Q6 | A | PACELC = PA（Partition tolerant, choose Availability）+ EC（Else, choose Between Consistency and Latency）。CAP 只讨论分区场景，PACELC 补充了无分区时的 L/C 权衡。 |
|
||
|
||
### 填空题答案
|
||
|
||
| 题号 | 答案 | 解析 |
|
||
|------|------|------|
|
||
| F1 | `30` | 消费者每 30 秒刷新一次本地缓存。结合 Eureka 的续约超时周期（通常 30~90 秒），故障检测延迟约在一个续约周期左右。 |
|
||
| F2 | `AP` | Consul DNS API 直接读取随机节点的本地内存缓存，不走 Raft 日志，因此速度快但读到的可能是 stale data。如果需要强一致则走 TCP 端口。 |
|
||
| F3 | `namespace` | Nacos 的 namespace 相当于 K8s 的 Namespace，实现 dev/test/prod 的物理隔离。每个 namespace 独立存储服务列表和配置数据。 |
|
||
|
||
### 简答题参考答案
|
||
|
||
S1：**参考答案要点**：
|
||
1. **机制作用**：自我保护防止因网络抖动大量实例被误判为宕机而批量剔除，避免雪崩式下线。
|
||
2. **关了的风险**：一旦关闭，心跳稍微延迟就会被剔除，一批实例被认为故障全部移除，调用方拿不到任何健康实例。
|
||
3. **适用场景**：金融类对一致性要求高的场景可以考虑关闭；普通互联网业务不建议关，误判的危害大于不调用的危害。
|
||
4. **监控建议**：生产环境必须监控 `eureka.server.selfPreservationThreshold` 指标，当该阈值被触发时告警通知运维介入检查。
|
||
|
||
**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。
|
||
|
||
## 关联笔记
|
||
- [[负载均衡算法]]
|
||
- [[限流熔断降级]]
|
||
- [[配置中心设计]]
|