微服务选择题1 - 在线考试测评模板

Q1:OpenFeign 相较于手写 HTTP 请求的主要优势是（　）。

必须手写请求细节

以声明式接口的方式简化远程调用

只能调用本地方法

不支持负载均衡

Q2:在 OpenFeign 接口中，用于标注该接口对应远程服务名的注解通常是（　）。

@Service

@FeignClient

@Repository

@Configuration

Q3:使用 OpenFeign 调用微服务时，接口方法上通常需要标注的 HTTP 方法注解是（　）。

@GetMapping/@PostMapping 等

@Autowired

@Component

@Bean

Q4:Spring Cloud Gateway 在微服务架构中承担的角色是（　）。

数据库中间件

统一入口/API 网关

消息队列

注册中心

Q5:下列关于 Gateway 过滤器的说法，正确的是（　）。

过滤器只能在请求转发前执行

过滤器可以在请求转发前后对请求或响应进行处理

网关不支持自定义过滤器

过滤器与路由无关

Q6:网关的 Cors 跨域配置主要用于解决（　）问题。

数据库连接超时

浏览器跨域请求被拦截

服务注册失败

消息丢失

Q7:下列不属于 Gateway 核心概念三要素的是（　）。

Route

Predicate

Filter

Entity

Q8:Gateway 实现路由转发中的负载均衡，通常需要在 uri 中使用的前缀是（　）。

http://

lb://

ftp://

file://

Q9:Gateway 中用于匹配请求是否符合路由条件的是（　）。

Filter（过滤器）

Predicate（断言）

Route（路由）

Listener（监听器）

Q10:灰度发布的核心思想是（　）。

一次性将新版本全量上线

逐步、小范围地将新版本发布给部分用户，降低风险

直接下线旧版本

只在测试环境发布

Q11:Gateway 中只对特定路由生效、需要在路由级别配置的过滤器称为（　）。

全局过滤器（GlobalFilter）

局部/路由过滤器（GatewayFilter）

拦截器（Interceptor）

监听器（Listener）

Q12:网关作为微服务架构入口，通常不承担的职责是（　）。

请求路由转发

统一鉴权

直接执行复杂业务 SQL 查询

流量控制

Q13:微服务链路中因某个服务故障引发连锁故障、导致系统整体不可用的现象称为（　）。

雪崩

降级

熔断

限流

Q14:下列不属于 Sentinel 流量控制阈值类型的是（　）。

QPS

并发线程数

数据库连接数

以上都不是流控阈值类型

Q15:Sentinel 中用于隔离不同资源、避免相互影响的机制是（　）。

线程隔离

服务注册

配置刷新

负载均衡

Q16:Sentinel 中处理限流、降级异常的统一回调方式通常通过（　）实现。

BlockHandler/FallbackHandler 等异常处理方法

try-catch 捕获所有异常并忽略

直接终止 JVM 进程

修改数据库事务隔离级别

Q17:流量控制中“直接拒绝”的处理效果是（　）。

超出阈值的请求直接被拒绝，返回异常

请求进入排队等待

请求被自动重试

请求被转发到其他服务

Q18:服务降级的目的是（　）。

在依赖不可用时提供兜底响应，保证核心链路可用

提高数据库查询效率

增加系统吞吐量上限

减少代码行数

Q19:下列关于熔断状态的说法，正确的是（　）。

熔断器只有开启和关闭两种状态

熔断器有开启、半开、关闭三种典型状态

熔断器状态不可自动切换

熔断与限流是同一概念

Q20:Sentinel 的授权规则主要用于（　）。

对请求来源进行黑白名单控制

配置数据库连接池大小

实现服务注册

实现日志采集

Q21:Sentinel 中用于定义被保护逻辑的最小单元称为（　）。

资源（Resource）

端点（Endpoint）

拓扑（Topology）

探针（Agent）

Q22:Sentinel 控制台的主要作用是（　）。

编写业务代码

实时监控与动态配置限流熔断规则

存储用户密码

编译 Java 代码

Q23:Sentinel 熔断策略中，基于慢调用比例触发熔断的依据是（　）。

响应时间超过设定阈值的请求占比

请求总数

服务启动时间

CPU 核心数

Q24:Dubbo 架构中负责发布服务的角色是（　）。

Consumer（消费者）

Provider（提供者）

Monitor（监控中心）

Registry（注册中心）

Q25:下列不属于 Dubbo 四大核心角色的是（　）。

Provider

Consumer

Registry

Gateway

Q26:Dubbo 是一款高性能的（　）框架。

RPC 远程调用

关系型数据库

前端 UI

操作系统

Q27:与基于 HTTP 的 OpenFeign 相比，Dubbo 的通信协议特点是（　）。

基于文本协议，性能较低

默认使用二进制协议，传输效率更高

不支持跨进程调用

只能在同一台机器内调用

Q28:Sentinel 对 Dubbo 服务进行限流与熔断降级的对象通常是（　）。

Dubbo 接口方法这一维度的调用资源

操作系统进程

数据库表

前端页面元素

Q29:Dubbo 服务提供者与消费者之间通常借助什么组件完成彼此发现？（　）

注册中心（如 Nacos）

前端浏览器

操作系统防火墙

数据库触发器

Q30:RocketMQ 是由下列哪家公司主导开源的消息中间件？（　）

阿里巴巴

微软

谷歌

IBM

Q31:希望消息在指定时间之后才被消费者看到，应使用（　）。

过滤消息

延时消息

批量消息

事务消息

Q32:能够保证本地事务与消息发送的最终一致性的消息类型是（　）。

普通消息

过滤消息

事务消息

顺序消息

Q33:消费者按照 Tag 等条件只消费部分感兴趣的消息，这种方式称为（　）。

过滤消息

批量消息

延时消息

事务消息

Q34:RocketMQ 中承担消息存储与转发职责的角色是（　）。

Broker

NameServer

Consumer Group

Topic 仅为逻辑概念，不参与存储

Q35:RocketMQ 中负责寻址、管理 Broker 路由信息的组件是（　）。

NameServer

Producer

Consumer

Topic

Q36:要求消息严格按照发送顺序被消费的消息类型是（　）。

普通消息

顺序消息

延时消息

批量消息

Q37:一次性发送多条消息以提升发送效率的方式称为（　）。

批量消息

顺序消息

事务消息

延时消息

Q38:事务消息中，生产者先发送的、暂不能被消费的消息称为（　）。

半消息（Half Message）

死信消息

延时消息

广播消息

Q39:相较于直接使用 RocketMQ 原生 API，使用 Spring Cloud Stream 的主要优势是（　）。

切换底层消息中间件时业务代码改动更小

消息投递必然更快

不需要部署消息中间件

无法与 RabbitMQ 整合

Q40:RabbitMQ 相较于 RocketMQ 的特点是（　）。

基于 AMQP 协议，是较早成熟的开源消息中间件

由阿里巴巴开源

不支持消息持久化

只能同步调用

Q41:Spring Cloud Stream 中用于对接具体消息中间件的组件称为（　）。

Binder（绑定器）

Router（路由器）

Filter（过滤器）

Balancer（均衡器）

Q42:下列关于 Spring Cloud Stream 的说法，错误的是（　）。

可以整合 RocketMQ

可以整合 RabbitMQ

必须为每种中间件重写全部业务逻辑

对上层业务代码屏蔽了中间件差异

Q43:Spring Cloud Stream 的核心设计目标是（　）。

为不同消息中间件提供统一的编程模型

替代关系型数据库

实现服务注册发现

实现网关路由

Q44:分布式事务问题通常产生于（　）。

单体应用内部方法调用

跨多个服务/数据库的业务操作需要保证一致性

前端页面渲染

静态资源加载

Q45:SAGA 模式的主要特点是（　）。

通过一系列本地事务加补偿动作实现最终一致性，长事务场景适用性较好

严格依赖数据库 XA 协议，不需要补偿

只能用于单机事务

不支持业务侵入

Q46:下列关于 AT 模式与 TCC 模式的比较，正确的是（　）。

AT 模式对业务代码侵入性更低，TCC 模式需要业务方实现三个接口

两者完全相同，没有区别

TCC 模式无需数据库支持

AT 模式不支持自动回滚

Q47:在电商下单扣库存的场景中，最适合体现“两阶段提交+自动回滚日志”特点的模式是（　）。

AT 模式

人工补偿脚本

纯前端校验

无事务处理

Q48:Seata Server 启动后，业务微服务通常需要配置的关键信息是（　）。

Seata Server 地址与事务分组

前端页面路由

操作系统防火墙规则

浏览器缓存策略

Q49:TCC 模式的三个阶段是（　）。

Try-Confirm-Cancel

Start-Run-Stop

Begin-Commit-Rollback

Open-Read-Close

Q50:下列关于 CAP 理论的说法，正确的是（　）。

一致性、可用性、分区容错性三者可以同时完全满足

在发生网络分区时，需要在一致性和可用性之间权衡

CAP 理论与分布式系统无关

CAP 只适用于单机系统

Q51:Seata 支持的事务模式不包括（　）。

AT

TCC

XA

FTP

Q52:AT 模式的实现基础是（　）。

两阶段提交与自动生成回滚日志

人工手动补偿

消息队列重试

不需要记录任何日志

Q53:XA 模式依赖的基础是（　）。

数据库原生支持的分布式事务协议

应用层手写补偿逻辑

消息队列的重试机制

前端页面的状态管理

Q54:Seata 中负责协调全局事务的角色通常称为（　）。

TC（TransactionCoordinator）事务协调者

TM 单独即可完成协调，无需其他角色

RM（ResourceManager）单独完成协调

NameServer

Q55:“无分布式事务”的原始项目在跨服务下单扣库存时最容易出现的问题是（　）。

数据始终保持一致

某一步失败后，已执行的操作无法自动回滚，导致数据不一致

性能远高于加了分布式事务的版本且无副作用

完全不会有并发问题

Q56:Skywalking 中用于采集应用调用数据、通常以无侵入方式接入应用的组件是（　）。

探针（Agent）

注册中心

网关

消息队列

Q57:Skywalking 整合 logback 的主要目的是（　）。

实现日志与调用链路 ID 的关联，便于按链路检索日志

替代数据库存储业务数据

实现服务熔断

实现负载均衡

Q58:Skywalking 主要用于实现（　）。

分布式链路追踪与性能监控

服务注册与发现

分布式事务

消息中间件

Q59:微服务架构下引入链路追踪的主要原因是（　）。

服务数量少、调用链路简单，不需要追踪

调用链路跨多个服务，故障定位困难，需要可视化追踪

链路追踪可以替代所有的日志系统

链路追踪只用于前端页面

Q60:Skywalking 探针接入应用的典型方式是（　）。

在启动命令中通过 javaagent 参数挂载，无需修改业务代码

必须重写全部业务代码

只能通过修改数据库表结构接入

必须使用特定的编程语言重写

Q61:下列不属于可观测性（Observability）常见维度的是（　）。

日志（Logging）

指标（Metrics）

链路追踪（Tracing）

编译（Compiling）