第 14 章
分章自测题（四）
第5章（5.1–5.4）。微服务板块（第4、5章合计）占 ACA 考试 40% 权重，这一章偏"工具链"——消息队列、稳定性、压测、监控，产品名字多，但每个产品解决的问题很明确，抓住"谁解决什么问题"就不容易混。
建议用法：先自己想答案，再看解析。做错的不用死记答案，回头把对应章节那一段再看一遍，搞清楚"为什么"比记住"是什么"更重要。
第5章自测：消息队列和应用工具产品体系
单选题
1. 引入消息队列最直接的两个价值是？
| 选项 | 内容 |
|---|---|
| A | 加密传输和身份认证 |
| B | 异步解耦和削峰填谷 |
| C | 数据库备份和容灾 |
| D | 前端页面渲染加速 |
正确答案：B
解析：消息队列的核心价值就两个——异步解耦（生产者发完消息就走，不用等消费者处理完，一方的抖动不会传导给另一方）和削峰填谷（流量洪峰先堆在队列里，消费者按自己的节奏慢慢消费）。这两个词考试里经常成对出现。
2. 高并发场景下同步调用容易引发雪崩，问题的根源是什么？
| 选项 | 内容 |
|---|---|
| A | 数据库表结构设计不合理 |
| B | 同步调用把"生产请求的速度"和"处理请求的速度"绑在了一起 |
| C | 服务器的操作系统版本太旧 |
| D | 没有使用 HTTPS 协议 |
正确答案：B
解析：同步调用意味着上游发了请求就必须等下游处理完才能释放资源。一旦下游顶不住，上游的连接和线程资源也会被占满，压力沿调用链逐级往上传导，最终演变成级联故障（雪崩）。消息队列就是为了打断这种绑定。
3. RocketMQ 最典型的定位是什么？
| 选项 | 内容 |
|---|---|
| A | 海量日志采集管道 |
| B | 业务消息——订单、支付、库存这类对可靠性和事务性要求高的场景 |
| C | 前端静态资源分发 |
| D | 大数据离线批处理 |
正确答案：B
解析：业务事务选 RocketMQ，海量数据管道选 Kafka——这是最简单的选型口诀。RocketMQ 原生支持事务消息、顺序消息、延时消息、死信队列，天然适合和交易强相关的业务场景。A 是 Kafka 的定位。
4. 关于 RocketMQ 的历史，下列说法正确的是？
| 选项 | 内容 |
|---|---|
| A | 是 LinkedIn 开源的项目 |
| B | 2012年阿里自研，是中国第一个非 Hadoop 生态的 Apache 顶级项目 |
| C | 从未开源，只有阿里云商业版 |
| D | 基于 Kafka 二次开发而来 |
正确答案：B
解析：RocketMQ 2012年阿里自研并开源，2016年捐给 Apache，2017年毕业成为顶级项目——是中国第一个非 Hadoop 生态的 Apache 顶级项目。A 说的是 Kafka，Kafka 才是 LinkedIn 开源的。
5. 下列哪种场景最适合用 Kafka 而不是 RocketMQ？
| 选项 | 内容 |
|---|---|
| A | 订单支付状态变更通知 |
| B | 需要事务消息保证最终一致性的场景 |
| C | 日志采集聚合和大数据实时流处理 |
| D | 需要延时消息和死信队列的业务场景 |
正确答案：C
解析：Kafka 的核心优势是超高吞吐量，基于顺序追加日志的存储模型，天然适合海量数据管道。A、B、D 这些对事务语义、消息功能有高要求的场景，RocketMQ 更合适。
6. 限流、降级、熔断三者的共同点是什么？
| 选项 | 内容 |
|---|---|
| A | 都在"牺牲一部分"来保住"更重要的部分" |
| B | 都是在系统空闲时执行的预防措施 |
| C | 都需要双倍的服务器资源 |
| D | 都是前端层面的优化手段 |
正确答案：A
解析：限流牺牲超阈值的请求、降级牺牲非核心功能、熔断牺牲对已出问题下游的调用——方式不同，但本质都是局部牺牲，保全大局。
7. 某个依赖服务已经持续返回错误，调用方应该采取什么措施？
| 选项 | 内容 |
|---|---|
| A | 限流——限制请求速率 |
| B | 降级——关掉非核心功能 |
| C | 熔断——停止调用该服务，一段时间后小流量尝试恢复 |
| D | 重试——不断重试直到成功 |
正确答案：C
解析：关键词"依赖服务已经持续出错"→ 熔断。继续打请求过去只会越打越糟，不如先断开，等一段时间后小流量探测它是否恢复。限流是保护自己不被外部流量压垮，降级是主动放弃非核心功能，都不是针对"下游已经挂了"这个场景。D 无限重试是雪崩的帮凶。
8. AHAS 的流控降级模块底层基于哪个开源项目？
| 选项 | 内容 |
|---|---|
| A | Chaos Monkey |
| B | Sentinel |
| C | Prometheus |
| D | Envoy |
正确答案：B
解析：AHAS 流控降级 = Sentinel 的商业化托管版本。Sentinel 是阿里巴巴双十一技术体系里的核心流量控制组件（开源）。Chaos Monkey 是 Netflix 的混沌工程工具，Prometheus 是监控，Envoy 是服务网格代理。
9. 混沌工程的核心理念是什么？
| 选项 | 内容 |
|---|---|
| A | 等故障发生后再排查原因 |
| B | 在生产或接近生产的环境中主动注入故障，提前验证系统的容错能力 |
| C | 给所有服务加上最高级别的安全防护 |
| D | 用代码审查代替测试 |
正确答案：B
解析：混沌工程 = 与其祈祷不出故障，不如主动制造可控的故障，验证系统是不是真的扛得住。Netflix 的 Chaos Monkey 是这个理念的代表——随机杀掉生产实例，逼团队把系统设计得能容忍单点故障。A 是"救火模式"，混沌工程反对的恰恰是这种被动方式。
10. AHAS 的三个模块形成一条什么样的闭环？
| 选项 | 内容 |
|---|---|
| A | 架构感知（知道系统长什么样）→ 流控降级（出问题时兜底）→ 故障演练（提前验证兜底有效） |
| B | 日志采集 → 指标监控 → 链路追踪 |
| C | 代码编译 → 自动测试 → 自动部署 |
| D | 需求管理 → 代码审查 → 制品发布 |
正确答案：A
解析：AHAS 三模块——架构感知让你看清依赖关系，流控降级在出问题时兜底，故障演练提前验证兜底机制管不管用。B 说的是 ARMS 的能力，C 和 D 说的是 DevOps/云效。
11. PTS 压测报告里，P99 指标的含义是什么？
| 选项 | 内容 |
|---|---|
| A | 系统有 99% 的概率不会崩溃 |
| B | 99% 的请求响应时间都低于这个值 |
| C | 系统可以承受 99 个并发用户 |
| D | 99% 的数据已经持久化 |
正确答案：B
解析：P99 是分位数指标——99%的请求响应时间都低于这个值。为什么看 P99 而不只看平均值？因为平均值容易被大量正常请求"拉低"，掩盖少数用户的糟糕体验。P99 能反映真实的用户体验下限。
12. 可观测性的三大支柱是什么？
| 选项 | 内容 |
|---|---|
| A | CPU、内存、磁盘 |
| B | Metrics（指标）、Logs（日志）、Traces（链路追踪） |
| C | 前端、后端、数据库 |
| D | 开发、测试、运维 |
正确答案：B
解析：业界公认的可观测性三大支柱——Metrics（QPS/错误率这些数字指标）、Logs（系统运行的文本记录）、Traces（一次请求跨服务的完整路径）。ARMS 正是覆盖这三块的一站式产品。
13. ARMS 的前端监控模块（RUM）站在什么角度看问题？
| 选项 | 内容 |
|---|---|
| A | 服务器端的 CPU 和内存占用 |
| B | 真实用户浏览器的角度——页面加载速度、首屏时间、JS报错 |
| C | 数据库的查询性能 |
| D | 消息队列的消费延迟 |
正确答案：B
解析：RUM = Real User Monitoring，关键词是"Real User"——不是从服务端看自己跑得好不好，而是从真实用户浏览器的角度看页面加载快不快、有没有白屏、JS 有没有报错。这个视角是其他监控手段替代不了的。
14.（场景题）完美日记大促改造方案中，用 PTS 做常态化压测、用 AHAS 做限流降级，改造后大促吞吐量提升了多少倍？
| 选项 | 内容 |
|---|---|
| A | 5 倍 |
| B | 10 倍 |
| C | 50 倍 |
| D | 100 倍 |
正确答案：C
解析：完美日记 2020年4月三周年大促，系统吞吐量相比半年前提升了 50 倍。这个案例基本是第5章全套产品（ACK + Spring Cloud Alibaba + PTS + AHAS + 链路追踪）在真实大促场景的完整闭环。
多选题
M1.（3个）消息队列的核心角色包括？
| 选项 | 内容 |
|---|---|
| A | 生产者（Producer） |
| B | 消费者（Consumer） |
| C | 主题（Topic） |
| D | 负载均衡器（SLB） |
| E | 域名解析服务（DNS） |
正确答案：A、B、C
解析：消息队列围绕三个核心角色——生产者发消息、消费者收消息、Topic 给消息分类。中间还有 Broker（消息服务器）负责暂存。D 和 E 是网络层的组件，和消息队列的核心模型无关。
M2.（3个）关于限流、降级、熔断，匹配正确的是？
| 选项 | 内容 |
|---|---|
| A | 限流——限制单位时间请求量，超过阈值直接拒绝 |
| B | 降级——主动放弃非核心功能，保住核心链路 |
| C | 熔断——依赖服务持续失败时，暂停对它的调用 |
| D | 限流——依赖服务出错时，停止调用它 |
| E | 降级——提高所有功能的响应速度 |
正确答案：A、B、C
解析：D 把限流和熔断搞混了——限流是控制请求速率保护自己，熔断是停止调用已出问题的下游。E 也不对——降级是放弃非核心功能，不是提速。记法：限流保护自己，降级放弃非核心，熔断隔离下游。
M3.（3个）AHAS 的三大模块包括？
| 选项 | 内容 |
|---|---|
| A | 流控降级 |
| B | 架构感知 |
| C | 故障演练 |
| D | 链路追踪 |
| E | 代码托管 |
正确答案：A、B、C
解析：AHAS 三件套——流控降级（Sentinel 商业版）、架构感知（自动画依赖拓扑）、故障演练（混沌工程实践）。D 是 ARMS 的能力，E 是云效 Codeup 的能力。
M4.（3个）关于性能测试的类型，匹配正确的是？
| 选项 | 内容 |
|---|---|
| A | 负载测试——逐步加压到预期负载，验证正常流量下系统是否达标 |
| B | 压力测试——持续加压超过预期直到系统崩溃，找出真实上限 |
| C | 稳定性测试——长时间维持负载，检查是否有内存泄漏等累积问题 |
| D | 负载测试——直接把系统压到崩溃 |
| E | 压力测试——只测5分钟就出结论 |
正确答案：A、B、C
解析：三种测试回答不同的问题——负载测试问"正常流量下行不行"，压力测试问"上限在哪"，稳定性测试问"长时间跑会不会出问题"。D 把负载测试和压力测试搞混了，E 是不严谨的做法。
M5.（3个）ARMS 的核心功能模块包括？
| 选项 | 内容 |
|---|---|
| A | 应用监控——无侵入探针采集应用性能数据 |
| B | 链路追踪——TraceID/Span 机制可视化请求路径 |
| C | 前端监控（RUM）——从真实用户浏览器角度看体验 |
| D | 消息队列管理——管理 RocketMQ 集群 |
| E | 容器编排——管理 Kubernetes 集群调度 |
正确答案：A、B、C
解析：ARMS 四大模块是应用监控、链路追踪、前端监控（RUM）、Prometheus 监控——都围绕"看得见"这个主题。D 是消息队列产品自己的事，E 是 ACK 的事。记法：ARMS 只管"看"，不管"跑"。
第5章补充题
单选题（续）
15. 系统可用性常说的"四个9"（99.99%），一年大概能容忍多长时间的故障？
| 选项 | 内容 |
|---|---|
| A | 约 8.7 小时 |
| B | 约 52 分钟 |
| C | 约 5 分钟 |
| D | 零故障 |
正确答案：B
解析：三个 9（99.9%）≈ 一年 8.7 小时故障；四个 9（99.99%）≈ 一年约 52 分钟。每多一个 9，容忍的故障时间缩短约 10 倍。A 是三个 9 的数据，别搞混。
16. RocketMQ 原生支持的事务消息，解决的是什么问题？
| 选项 | 内容 |
|---|---|
| A | 保证消息的传输加密 |
| B | 保证"发消息"和"改本地数据库"这两个操作的最终一致性 |
| C | 保证消息按顺序消费 |
| D | 保证消息在多个 Topic 之间自动路由 |
正确答案：B
解析：事务消息是分布式事务的一种轻量方案——比如下单时既要扣库存（改数据库），又要通知物流（发消息），事务消息保证这两步要么都成功、要么都不生效。C 说的是顺序消息，另一个功能。
17. Kafka 的超高吞吐量源于什么存储模型？
| 选项 | 内容 |
|---|---|
| A | 随机读写的关系型数据库 |
| B | 基于顺序追加的日志（log），Partition 独立顺序写 |
| C | 内存缓存，不做持久化 |
| D | 分布式文件系统 HDFS |
正确答案：B
解析：Kafka 的 Partition 各自独立做顺序追加写，顺序写磁盘的吞吐量远高于随机写，这是它海量吞吐的根基。而且 Partition 数量可以按需扩展，吞吐量几乎线性增长。
18.（场景题）大促期间系统压力大，团队决定暂时关闭"猜你喜欢"推荐功能，把资源留给下单支付。这属于什么措施？
| 选项 | 内容 |
|---|---|
| A | 限流 |
| B | 降级 |
| C | 熔断 |
| D | 扩容 |
正确答案：B
解析：主动放弃非核心功能，保住核心链路 = 降级。"猜你喜欢"是非核心的，下单支付是核心的。限流是控制请求速率，熔断是隔离已出问题的下游，这里的场景是主动选择"关掉什么"。
19. 全链路压测相比单场景压测的核心优势是什么？
| 选项 | 内容 |
|---|---|
| A | 只需要更少的测试时间 |
| B | 能发现跨环节的短板——整体承载能力取决于链路上最弱的那一环 |
| C | 不需要任何压测工具 |
| D | 只测一个接口就够了 |
正确答案：B
解析：全链路压测模拟用户从进入网站到完成下单支付的完整路径，能暴露木桶效应——单独测某个接口可能很快，但串起来走一遍才发现瓶颈卡在另一个环节。PTS 正是脱胎于阿里双11全链路压测的方法论。
20. 分布式链路追踪的核心实现机制是什么？
| 选项 | 内容 |
|---|---|
| A | 每个服务独立记日志，手动拼接 |
| B | 请求进来时生成全局唯一的 TraceID，随请求跨服务传递，每一跳记录一段 Span |
| C | 所有服务共享同一份日志文件 |
| D | 只在网关层记录，不深入到各个服务 |
正确答案：B
解析：TraceID 是"线索"，Span 是"片段"——一次请求跨十几个服务，TraceID 把它们串起来，每个 Span 记录某一跳的耗时和状态，最后拼成完整的调用链路图。这就是 ARMS 链路追踪模块落地的机制。
21. ARMS 和 SLS（日志服务）的关系是什么？
| 选项 | 内容 |
|---|---|
| A | 功能完全重复，只需要用其中一个 |
| B | ARMS 侧重应用性能指标和链路追踪，SLS 侧重日志的统一存储和检索，两者配合覆盖更完整的可观测性 |
| C | SLS 是 ARMS 的子模块 |
| D | ARMS 只管日志，SLS 只管指标 |
正确答案：B
解析：可观测性三大支柱里，ARMS 更偏 Metrics 和 Traces，SLS 更偏 Logs。两者各有侧重、配合使用，不是谁替代谁。D 说反了。
22.（场景题）申通快递云原生改造前的架构痛点是什么？
| 选项 | 内容 |
|---|---|
| A | 业务量太小，不需要微服务 |
| B | 基于 VMware 虚拟化和 Oracle 数据库，业务逻辑耦合在存储过程里，环境不一致 |
| C | 已经是完整的云原生架构，不需要改造 |
| D | 使用了过多的微服务导致管理混乱 |
正确答案：B
解析：申通原来是典型的传统架构——VMware + Oracle，很多业务逻辑写在 Oracle 存储过程和触发器里，系统之间靠数据库同步工具传递数据。上云后用 ACK + 云数据库替代，先容器化解决环境一致性，再微服务化拆分业务。
多选题（续）
M6.（3个）RocketMQ 支持的消息类型/能力包括？
| 选项 | 内容 |
|---|---|
| A | 事务消息 |
| B | 顺序消息 |
| C | 定时/延时消息 |
| D | 视频转码 |
| E | DNS 解析 |
正确答案：A、B、C
解析：RocketMQ 的消息能力很丰富——事务消息（保证本地数据库和消息的最终一致性）、顺序消息（保证消费顺序）、定时/延时消息（到指定时间才投递）、还有死信队列（消费失败的兜底）。D 和 E 跟消息队列无关。
M7.（2个）关于 Kafka 的适用和不适用场景，正确的是？
| 选项 | 内容 |
|---|---|
| A | 适合日志采集聚合和大数据实时流处理 |
| B | 适合需要复杂事务消息语义的订单支付场景 |
| C | 不适合数据分析（那是 MaxCompute/Spark 的活） |
| D | 适合把数据直接分发给终端用户 |
| E | 不适合任何高吞吐场景 |
正确答案：A、C
解析：Kafka 管的是数据的搬运和缓冲——日志采集、流处理是它的主场。但数据分析是计算引擎的活，分发到终端是 CDN 的活，Kafka 不管"算"也不管"最后一公里"。B 的复杂事务语义是 RocketMQ 的强项。
M8.（3个）关于压测报告的核心指标，正确的是？
| 选项 | 内容 |
|---|---|
| A | RT（响应时间）衡量一次请求耗时多久 |
| B | TPS/QPS 衡量系统每秒处理的事务或请求数 |
| C | P99 比平均值更能反映真实的用户体验下限 |
| D | 只要平均 RT 低就说明系统没问题 |
| E | 错误率高说明压测工具出了 bug |
正确答案：A、B、C
解析：D 是常见误区——平均值容易被大量正常请求拉低，1% 的用户等了 10 秒你看不到，P99/P95 才能暴露这种"长尾"问题。E 也不对——错误率高通常说明被测系统已经顶不住了，不是压测工具的问题。
留言区待配置
部署 Twikoo 后端后，设置环境变量 NEXT_PUBLIC_TWIKOO_ENV_ID