强依赖和弱依赖服务应该如何分别保障？｜阿里巴巴后端开发面经解析

60 秒回答模板

我会先按业务影响把依赖分成强依赖和弱依赖。强依赖决定交易闭环或数据正确性，必须做多副本、容量保障、超时、重试、熔断隔离、数据一致性和故障预案；弱依赖不应阻塞主链路，优先异步化、缓存兜底、默认值降级、失败事件记录和后续补偿。真正落地时还要给每个依赖分配超时预算、失败策略和监控告警。

考点 核心机制与工程取舍

难度 中高频面试题

回答目标 按定义、机制、场景讲清楚

强依赖失败会让主流程无法正确完成，例如支付、库存扣减、账号鉴权；弱依赖失败只影响体验、推荐、通知、统计或旁路信息。判断标准不是服务重要不重要，而是当前链路是否必须等待它成功。

强依赖要提高成功率和确定性：多机房或多副本、容量冗余、健康检查、连接池保护、超时重试、幂等写入、事务或状态机一致性，以及故障时的排队、只读、拒绝或人工兜底。

弱依赖应该从同步主路径剥离，能异步就异步，能缓存就缓存，能默认值就默认值。失败时记录事件、保留上下文、异步重试或定时补偿，避免用户主操作被非核心能力拖住。

强弱依赖都要避免互相拖垮。线程池、连接池、限流桶、队列和熔断器按依赖隔离，防止一个慢依赖占满业务线程或把全局连接池耗尽。

主链路总超时要向下分配给每个依赖，强依赖关注成功率、延迟和一致性，弱依赖关注降级率、补偿积压和用户感知。没有监控的降级会变成静默失败。

可以降级，但不能破坏业务正确性。常见做法是只读、排队、暂停写入、拒绝请求或人工审核，而不是返回伪成功。

把失败上下文持久化到消息、任务表或 outbox，异步重试，超过阈值进入死信和告警，再通过对账补偿兜底。

会。同一个服务在不同链路里的等级不同，例如短信验证码在登录链路是强依赖，在营销通知链路是弱依赖。

熔断发生在异常之后，隔离能限制异常影响范围，防止慢调用提前耗尽线程、连接和队列。