三层架构下跨微服务调用应放在Service层还是Repository层？

常规业务场景下，跨微服务调用优先放在Service层是更优选择，仅在特定纯数据聚合场景下可以考虑扩展Repository层的能力做适配，具体判断逻辑如下：

为什么不推荐放到常规Repository层 #

Repository的核心职责是抽象领域对象的持久化集合，默认仅负责对接本地持久化存储（数据库、缓存等），处理数据读写、存储结构到业务模型的映射逻辑。将跨微服务调用放到常规Repository层会存在两个明显问题：

• 破坏单一职责原则：原本仅处理持久化逻辑的层会混入RPC/HTTP调用的重试、熔断、降级逻辑，后续维护人员默认Repository仅操作本地存储，排查问题时容易遗漏远程调用逻辑
• 模糊业务边界：大多数跨微服务调用并非纯数据读写，往往会触发被调用方的业务逻辑（比如调用用户服务做权限校验、调用支付服务生成支付流水），这类逻辑完全不属于「存储介质读写」的范畴，放到Repository层会导致职责混乱

为什么放到Service层更合理 #

Service层的设计目标就是封装、编排业务逻辑，聚合多数据源的处理结果，跨微服务调用本身就是业务流程的一部分，放到该层的优势十分明确：

• 职责匹配：如果你的业务逻辑需要同时操作本地数据库+调用其他微服务，放在Service层可以统一编排流程，不需要把完整业务逻辑拆分到两层维护
• 异常处理更高效：跨微服务调用的降级、fallback策略往往和业务强相关（比如调用商品服务失败时返回兜底的默认商品信息），和业务逻辑放在一起维护可读性更高

特殊场景的适配方案 #

如果你调用的其他微服务完全是纯数据查询服务，不存在任何业务触发逻辑，只需要做返回结果到本地业务模型的映射，可以单独封装独立的远程调用类，命名上明确和本地Repository做区分（比如命名为UserRemoteRepository、GoodsRemoteClient），不要和本地数据库的Repository混放在同一个目录或者同一个类中，避免造成歧义。

内容的提问来源于stack exchange，提问作者J.F.