0. （热身·单选）ShopFlow 三大限界上下文不包括哪一个？

• A) Order
• B) Inventory
• C) Payment
• D) API Gateway（入口组件，非业务上下文）

回顾 ShopFlow 全景表

答案：D

1. （单选）「部分失败」最典型的特征是？

• A) 所有节点同时宕机
• B) 调用方无法确定远端是否已执行成功
• C) 数据库永远返回 null
• D) 网络永远零延迟

想想超时后 inventory 可能已扣减但 order 未收到响应

答案：B — 部分失败的核心是「结果不确定」，而非全体宕机

2. （填空）ShopFlow 中，负责「预留/扣减库存、防超卖」的限界上下文是 ______。

三大上下文：Order / Inventory / Payment

答案：Inventory（大小写不敏感）

3. （多选）下列哪些属于「从单机走向分布式」的常见驱动力？

• A) 水平扩展读写吞吐
• B) 故障隔离与提高可用性
• C) 消除所有网络不确定性
• D) 多团队并行交付不同业务能力

分布式换来扩展与隔离，但网络不确定性仍在

答案：A,B,D — 分布式不能消除网络不确定性（C 错误）

4. （单选）关于跨节点「时钟漂移」，下列做法错误的是？

• A) 用版本号或逻辑时钟排序事件
• B) 关键协调依赖租约 / fencing（后续章节展开）
• C) 业务上避免假设「各节点本机时间严格一致」
• D) 用各服务本机 System.currentTimeMillis() 直接排序跨节点事件

NTP 只能减小漂移，不能当作全局有序时钟

答案：D — 本机墙钟不能作为跨节点事件的可靠排序依据

5. （场景·单选）order-service 调用 inventory-service 超时，但库存侧可能已成功扣减。较稳妥的首选策略是？

• A) 立即无限次重试同一请求
• B) 幂等键 + 查询状态 / 对账，再决定是否补偿
• C) 当作成功并直接返回用户「下单成功」
• D) 忽略该调用，不做任何记录

对照正文「调用方视角 × 服务端真实状态」表

答案：B — 先消除「不确定」，再重试或走补偿（分布式数据：事务、幂等与 Saga 将展开 Saga）

1. （单选）发生网络分区时，CAP 定理要求系统如何取舍？

• A) 同时保证 C、A、P
• B) 在一致性 C 与可用性 A 之间二选一（P 通常不能放弃）
• C) 放弃分区容忍，只保证 C 和 A
• D) 与分区无关，只取决于数据库品牌

分区发生时不能既要「永远读到最新」又要「永远有响应」

答案：B — 有 P 时只能在 C 与 A 间取舍

2. （填空）BASE 中的 E 指 ______ consistent（最终一致）。

Eventually consistent 的首词

答案：Eventually（大小写不敏感）

3. （多选）下列哪些属于本章讨论的一致性模型？

• A) 最终一致
• B) 单机进程内栈变量可见性
• C) 因果一致
• D) HTTP Keep-Alive

分布式副本与客户端会话层面的一致性

答案：A,C — B、D 不是分布式一致性模型

4. （单选）Fencing token 的主要作用是？

• A) 加密网络传输
• B) 替代数据库主键自增
• C) 防止旧锁持有者（僵尸主）用更旧的 token 覆写新主的写
• D) 提高 Feign 超时上限

对照正文「旧主恢复」序列图

答案：C — 存储拒绝比已应用更小 token 的写

5. （单选）用户刚下单后刷新「我的订单」却看不到刚创建的订单，最可能缺少哪种客户端语义？

• A) 读己之写（Read-your-writes）
• B) 分区容忍（Partition tolerance）
• C) 舱壁隔离（Bulkhead）
• D) 蓝绿发布（Blue-green）

写主库后读从库可能读到旧数据

答案：A — 须保证用户能读到自己刚写入的数据

1. （单选）模块化单体与「分层大泥球单体」的主要区别是？

• A) 必须使用多个数据库实例
• B) 每个模块必须独立部署为容器
• C) 单进程单部署，但按业务能力划模块且跨模块只走公开 API
• D) 完全不能使用 Spring Boot

对照「模块化单体」一节

答案：C — 仍在单部署单元内，边界靠模块 API 而非随意跨表访问

2. （填空）SOA 时代常把路由、转换与编排集中在 ______（三字母缩写）上，易成变更瓶颈。

Enterprise Service Bus

答案：ESB（大小写不敏感）

3. （多选）下列哪些属于微服务带来的典型成本（而非收益）？

• A) 分布式事务与 Saga / 幂等设计复杂度上升
• B) 集成测试、契约测试与环境矩阵变多
• C) 团队可按服务独立发布（若边界清晰）
• D) 排障需链路追踪与跨服务日志关联

C 是收益；其余是分布式税

答案：A,B,D — C 属于收益

4. （单选）关于康威定律，下列说法最准确的是？

• A) 服务数量必须等于程序员人数
• B) 系统结构会反映组织内的沟通结构，拆服务应与团队拓扑对齐
• C) 只要使用 Spring Cloud 就自动满足康威定律
• D) 康威定律只适用于单体应用

架构镜像沟通结构

答案：B — 组织未拆却服务先拆，常得到分布式单体

5. （场景·单选）ShopFlow 仅 6 人，领域边界每周调整，尚无 CI/CD 与集中追踪。较稳妥的首选是？

• A) 立即拆 order / inventory / payment 三个独立部署服务
• B) 模块化单体 + 清晰模块 API，待团队与自动化成熟后再选择性拆分
• C) 引入 ESB 集中编排所有集成
• D) 为每个 Controller 各建一个微服务

对照「何时不应拆微服务」与章末 micro-check

答案：B — 先练边界、补自动化，再付分布式税

1. （单选）关于限界上下文，下列说法最准确的是？

• A) 所有微服务必须共用一个数据库 schema
• B) 上下文内有统一语言与完整模型，跨上下文只通过 API/事件集成
• C) 限界上下文等于 Maven 的 parent 模块
• D) 一个 Controller 类对应一个限界上下文

对照「限界上下文的关键属性」

答案：B — 禁止跨上下文共享实体与随意 JOIN

2. （填空）契约优先实践中，团队应先评审 ______ 规范再实现 Controller（常用 YAML 格式）。

OpenAPI Specification，常简称 OpenAPI

答案：OpenAPI（大小写不敏感）

3. （多选）下列哪些属于 REST API 设计的推荐做法？

• A) 资源 URI 用名词复数，如 /orders
• B) 写操作无需幂等键，超时后直接无限重试
• C) 错误响应含机器可读 code 与 traceId
• D) 对外 API 做版本化（如 /api/v1）

B 违反部分失败与幂等原则

答案：A,C,D — B 是反模式

4. （单选）消费者驱动契约（CDC） 的核心思想是？

• A) 提供者单方面定义 API，消费者必须适配
• B) 所有服务共用一个全局实体类库
• C) 消费者定义期望契约，提供者在 CI 中验证能否满足
• D) 只在生产环境联调时才检查 JSON 字段

集成失败左移到 PR/CI

答案：C — Pact 等工具实现该流程

5. （场景·单选）payment-service 收到渠道回调后，直接用 JDBC 更新 order 库的 status。较符合本章原则的做法是？

• A) 继续跨库 UPDATE，减少一次 HTTP 调用
• B) Payment 发布 PaymentCompleted 事件，由 order-service 自行更新状态
• C) 把 order 表迁移到 payment 服务统一管理
• D) 在 API Gateway 里写 SQL 更新订单

各上下文拥有自己的数据；跨库写是反模式

答案：B — Order 上下文拥有订单状态变更权

1. （单选）ShopFlow 中 order → inventory 的「预留库存」较适合哪种通信？

• A) 同步请求/响应（须当场知道成败）
• B) 仅异步事件，用户无需即时反馈
• C) 定时批处理即可
• D) 通过共享数据库直接 UPDATE

用户提交订单后需立即知道能否预留

答案：A — 同步 + 幂等 + 超时

2. （填空）「写业务表 + 发消息」原子性常用 Transactional ______ 模式（与业务同事务写待发事件表）。

Microservices.io 上的经典模式

答案：Outbox（大小写不敏感）

3. （多选）下列哪些属于异步事件驱动的典型收益？

• A) 解耦支付结果通知与 order 主流程
• B) 多订阅者（order、analytics）各消费 PaymentCompleted
• C) 消除所有重复消息
• D) 削峰、避免同步链路过长

MQ 常至少一次投递，须消费端幂等

答案：A,B,D — C 错误，重复仍可能发生

4. （单选）关于编舞（Choreography），下列说法最准确的是？

• A) 必须由 API Gateway 统一编排所有步骤
• B) 各服务订阅事件并自行决定本地动作，无中心协调者
• C) 与编排完全相同，只是换 Kafka 实现
• D) 只能用于单体应用

对比 order-service 作为编排者

答案：B — 流程分散在各服务

5. （场景·单选）order 同步调用 payment 并阻塞 30s 等待渠道回调。较符合本章推荐的做法是？

• A) 继续加长 readTimeout 到 120s
• B) order 返回待支付，payment 完成后发 PaymentCompleted 事件
• C) 在 Gateway 里轮询 payment 状态
• D) 取消异步，全部改共享表轮询

支付结果适合异步通知

答案：B — 短同步 + 事件通知

0. （热身·单选）ShopFlow 父 POM 中，Spring Cloud 组件版本应由谁统一管理？

• A) 每个 service 模块各自声明 openfeign 版本
• B) 仅 spring-boot-starter-parent，无需 Cloud BOM
• C) import spring-cloud-dependencies BOM
• D) Gradle version catalog 手写每组件版本

回顾父 POM dependencyManagement

答案：C — Cloud 发布列车由 BOM 对齐

1. （单选）shopflow-order-api 模块最适合放置哪类代码？

• A) JPA Entity 与 Repository 实现
• B) DTO、Feign 接口与 OpenAPI 生成物
• C) Spring Boot 主类与 Controller
• D) Eureka Server 配置

api 层无 Spring 运行时

答案：B — 契约与 DTO 供 service 与 Feign 消费

2. （填空）本地开发时，通过 spring.profiles.active=______ 激活 application-local.yml（填写 Profile 名，英文）。

与 application-local.yml 文件名对应

答案：local（大小写不敏感）

3. （多选）关于 Actuator /actuator/health，下列哪些说法正确？

• A) 可用于 K8s liveness/readiness 探针
• B) 应默认对外暴露 env、beans 等全部端点
• C) 后续可扩展 DB、注册中心等 readiness 检查
• D) 本章本地启动后期望看到 status 为 UP

敏感端点需限制暴露

答案：A,C,D — B 错误，勿暴露敏感端点

4. （场景·单选）团队想在 order-service 的 pom 里写死 spring-cloud-starter-openfeign 版本 4.0.0，而父 POM Cloud BOM 为 2025.0.1。较符合本章规范的做法是？

• A) 保留 4.0.0，便于「锁定已知好用版本」
• B) 删除子模块 version，由 BOM 统一管理
• C) 升级 Boot 到 2.7 以匹配 4.0.0
• D) 改用 Gradle 就不必 BOM

版本矩阵由父 POM 一处维护

答案：B — 避免与 Boot 3.5 / Cloud 2025 矩阵冲突

5. （判断·单选）本章本地启动 order-service 前，必须先启动 Eureka 注册中心，否则 health 无法 UP。

• A) 错误 — 本章无注册中心依赖，单服务可独立启动
• B) 正确 — 所有 Spring Cloud 服务必须同时启动 Eureka

注册发现见 practice-02

答案：A — 本章只验证脚手架与 Actuator

0. （热身·单选）ShopFlow 本课默认选用哪类注册中心？

• A) Consul 仅
• B) Netflix Eureka（Spring Cloud Netflix）
• C) 不使用注册中心，只用 K8s DNS
• D) ZooKeeper 独占

回顾 Eureka vs Nacos 对比表

答案：B — 本课教程默认 Eureka

1. （单选）Gateway 路由中 uri: lb://order-service 的 lb:// 表示？

• A) 负载均衡器硬件地址
• B) 本地回环 127.0.0.1
• C) 通过 LoadBalancer 从注册中心选 order-service 实例
• D) 仅 HTTP 不能 HTTPS

service-id 与 spring.application.name 一致

答案：C — lb 前缀触发客户端负载均衡

2. （填空）ShopFlow 本地 Eureka 控制台默认端口为 ______（数字）。

discovery-server application-local.yml

答案：8761

3. （多选）下列哪些适合放在 API Gateway 层？

• A) 统一路由与 StripPrefix
• B) JWT 校验后透传用户 ID 头
• C) 下单流程编排（reserve → pay → confirm）
• D) 全局限流（令牌桶）

编排属于 order-service

答案：A,B,D — C 是业务编排，不应在网关

4. （场景·单选）本地启动顺序错误：先起 Gateway，再起 Eureka，最后起 order-service。最可能出现？

• A) Gateway 启动时无可用实例或拉取注册表失败
• B) order-service 无法编译
• C) Eureka 自动删除 Gateway
• D) 无任何影响，顺序无关

推荐 discovery → services → gateway

答案：A — 注册表未就绪时 lb 路由不可用

5. （判断·单选）Eureka 心跳续约成功后，调用方就永远不会请求到已宕机实例。

• A) 正确 — 注册表与实例状态强一致
• B) 错误 — 剔除有延迟，仍可能出现部分失败

注册表是软状态

答案：B — 需客户端超时/重试（practice-03）