6.4 KiB
tags, create time
| tags | 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
答题框架提示:
- 长轮询的核心优势
- Websocket 的主要劣势（在微服务语境下）
- 混合方案的思考
参考答案与解析
选择题答案
| 题号 | 正确答案 | 解析 |
|---|---|---|
| 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：参考答案要点：
- 长轮询的核心优势：兼容所有 HTTP 中间件（网关、CDN、负载均衡器）。微服务架构中请求路径上通常有 Spring Cloud Gateway 等 HTTP-only 代理，这些代理不会做 WebSocket 升级，导致连接断开。
- WebSocket 的劣势：全链路需要升级支持，跨 NAT/防火墙困难；运维复杂度显著增加。
- 各自的缺点：长轮询的连接保持期间占用服务端内存；WebSocket 需要维护连接池和心跳保活。
- WS 的适用场景：需要毫秒级推送且能控制全链路的内部系统（如实时协作编辑器、游戏服务器）。对外暴露的微服务配置同步场景不适合。
评分标准：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。