145 lines
6.4 KiB
Markdown
145 lines
6.4 KiB
Markdown
---
|
||
tags: [test/review, architecture, arch/microservice, config-center]
|
||
create time: 2026-08-09 12:00
|
||
---
|
||
|
||
# 配置中心设计 — 测试题
|
||
|
||
## 概述
|
||
本测试覆盖 Apollo 三级 Namespace 模型、Nacos Config 长轮询推送机制、配置热更新实现原理、版本管理和回滚策略。共 10 道题目（6 选择 + 3 填空 + 1 简答）。
|
||
|
||
---
|
||
|
||
## 一、选择题（6道，由浅入深）
|
||
|
||
> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
|
||
|
||
### Q1（基础）— 考察定义层面
|
||
|
||
Apollo 的配置模型中，以下哪一层不是三级结构的一部分？
|
||
|
||
A. Environment（部署环境：dev/test/prod）
|
||
B. Application（业务应用）
|
||
C. Namespace（配置类型）
|
||
D. Tenant（租户）
|
||
|
||
### Q2（基础）→
|
||
|
||
Nacos Config 的秒级推送底层使用什么机制？
|
||
|
||
A. WebSocket 长连接
|
||
B. HTTP 长轮询（Long Polling）
|
||
C. MQTT 发布/订阅
|
||
D. Redis Pub/Sub
|
||
|
||
### Q3（进阶）— 核心原理
|
||
|
||
Nacos Config 长轮询的工作原理是什么？
|
||
|
||
A. 客户端每 5 秒定时发送请求，服务端每次都立即返回
|
||
B. 客户端发起请求后服务端将其挂起在 waitList 中，配置变化时写入 notificationId 后返回；如果 30 秒无变更则超时返回
|
||
C. 服务端主动通过 WebSocket 向客户端推送变更通知
|
||
D. 客户端通过 Redis Pub/Sub 订阅配置变更事件
|
||
|
||
### Q4（进阶）— 比较/辨析
|
||
|
||
以下关于 Apollo 和 Nacos Config 的区别描述中，哪个是正确的？
|
||
|
||
A. Apollo 用长轮询，Nacos 用短轮询
|
||
B. Apollo 的 namespace 支持更细粒度的权限控制和审批流，ConfigMap 只支持键值对映射
|
||
C. Nacos 不支持灰度发布，只有全量发布
|
||
D. Apollo 不支持多环境隔离，需要手动管理
|
||
|
||
### Q5（深入）— 场景推理
|
||
|
||
某团队在生产环境中修改了数据库连接串配置，服务重启后出现大量连接失败。从配置中心的角度看，最根本的原因是什么？
|
||
|
||
A. 使用了长轮询而非 WebSocket
|
||
B. 配置变更没有经过审核+灰度流程，直接全量推送到生产环境
|
||
C. Nacos 的 namespace 粒度不够细
|
||
D. Apollo 的三级结构过于复杂
|
||
|
||
### Q6（深入）— 源码级/边界场景
|
||
|
||
Apollo 的回滚操作本质上是怎样的？
|
||
|
||
A. 将版本号倒退回上一个版本，删除中间版本的所有记录
|
||
B. 用当前最新状态 + 差异计算生成一个新版本，保证发布记录单调递增
|
||
C. 复制上一个版本的快照作为新版本，不产生新的变更记录
|
||
D. 在数据库中将对应行的 version 字段减 1
|
||
|
||
---
|
||
|
||
## 二、填空题（3道）
|
||
|
||
### F1 — 填空1
|
||
|
||
Apollo 客户端发现配置新版本的默认拉取周期是 _____ 秒。当服务端生成了新的 releaseKey 后，客户端在下一次拉取时发现版本变化即触发热加载。
|
||
|
||
> **提示**: 回想原文中 Apollo 灰度发布流程的描述。
|
||
|
||
### F2 — 填空2
|
||
|
||
Spring Cloud 中使用 `@RefreshScope` 注解的 Bean 在配置变更后会自动生成_____，使得下次调用 getter 时获取的是最新的配置值。
|
||
|
||
> **提示**: 这个代理技术是 Spring 框架的核心特性之一，基于 AOP 实现。
|
||
|
||
### F3 — 填空3
|
||
|
||
配置热更新最大的风险是配置变更导致服务行为突变。Apollo 的解决方案是"_____+灰度"，先让少量实例生效观察指标，再逐步全量。
|
||
|
||
> **提示**: 两个字的动词，表示一个审核的动作。
|
||
|
||
---
|
||
|
||
## 三、简答题（1道）
|
||
|
||
### S1
|
||
|
||
面试官问："为什么 Nacos Config 用长轮询而不是 WebSocket？"请给出你的完整回答，并扩展到以下讨论：
|
||
- 长轮询 vs WebSocket 各自的优缺点
|
||
- 微服务架构中的中间件链路限制
|
||
- 在什么场景下可能考虑 WebSocket
|
||
|
||
> **答题框架提示**:
|
||
> 1. 长轮询的核心优势
|
||
> 2. Websocket 的主要劣势（在微服务语境下）
|
||
> 3. 混合方案的思考
|
||
|
||
---
|
||
|
||
## 参考答案与解析
|
||
|
||
### 选择题答案
|
||
|
||
| 题号 | 正确答案 | 解析 |
|
||
|------|---------|------|
|
||
| Q1 | D | Apollo 的三级结构是 Environment → Application → Cluster → Namespace。Tenant（租户）不是 Apollo 的标准层级——那是多租户 SaaS 平台的概念。 |
|
||
| Q2 | B | Nacos Config 使用 HTTP 长轮询实现秒级推送。不是 WebSocket（因为要兼容所有 HTTP 中间件），也不是 MQTT 或 Redis Pub/Sub。 |
|
||
| Q3 | B | 长轮询核心：客户端请求挂起到 waitList，配置变化时写 notificationId 后立即返回；30 秒超时防止连接无限期挂起。客户端收到通知后再拉取最新配置。 |
|
||
| Q4 | B | A 错：两者都用长轮询；C 错：Nacos 也支持灰度发布和回滚；D 错：Apollo 天然支持多环境隔离（namespace 就是为这个设计的）。 |
|
||
| Q5 | B | 直接全量推送错误配置是最危险的——所有实例同时失效。正确做法是先审核进入待发布状态，灰度到少数 IP 验证无误后再全量。 |
|
||
| Q6 | B | 回滚的本质不是"倒退版本"而是用当前状态 + 差异生成新版本。这样保证了发布记录永远单调递增（版本号一直增长），不会产生环形依赖。 |
|
||
|
||
### 填空题答案
|
||
|
||
| 题号 | 答案 | 解析 |
|
||
|------|------|------|
|
||
| F1 | `5` | Apollo Client 每 5 秒轮询一次服务端检查是否有新 releaseKey。这是配置热更新的延迟上限（理想情况下一个拉取周期即可感知变更）。 |
|
||
| F2 | `代理 Bean` | @RefreshScope 会动态创建代理对象，每次 getter 调用时检查缓存是否过期，若已过期则从配置中心拉取最新值。 |
|
||
| F3 | `审核` | "审核+灰度"流程：编辑配置进入审核状态→审核通过发布→灰度规则指定特定 IP 先接收→验证后全量发布。 |
|
||
|
||
### 简答题参考答案
|
||
|
||
S1：**参考答案要点**：
|
||
1. **长轮询的核心优势**：兼容所有 HTTP 中间件（网关、CDN、负载均衡器）。微服务架构中请求路径上通常有 Spring Cloud Gateway 等 HTTP-only 代理，这些代理不会做 WebSocket 升级，导致连接断开。
|
||
2. **WebSocket 的劣势**：全链路需要升级支持，跨 NAT/防火墙困难；运维复杂度显著增加。
|
||
3. **各自的缺点**：长轮询的连接保持期间占用服务端内存；WebSocket 需要维护连接池和心跳保活。
|
||
4. **WS 的适用场景**：需要毫秒级推送且能控制全链路的内部系统（如实时协作编辑器、游戏服务器）。对外暴露的微服务配置同步场景不适合。
|
||
|
||
**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。
|
||
|
||
## 关联笔记
|
||
- [[服务注册与发现]]
|
||
- [[限流熔断降级]]
|