Spring Boot中如何使用Mono.zip聚合不同类型Mono并返回响应

• 强行把异步调用扭成同步阻塞：CountDownLatch.await()会一直挂起当前Web工作线程，高并发场景下极易打满线程池，和直接用同步WebClient/RestTemplate没有本质性能差异，完全浪费了非阻塞调用的优势
• 异常处理完全缺失：任意一个远程调用抛出异常时，CountDownLatch的计数永远不会归零，当前线程会一直卡在等待状态直到系统超时，没有异常感知、重试、降级能力
• 线程安全无保障：在subscribe回调里给外部变量赋值，跨线程的变量可见性、竞态条件都没有任何防护
• 扩展性极差：每新增一个远程调用就要手动修改计数、加subscribe回调，冗余代码多且容易写错计数逻辑

核心原则 #

不要手动触发订阅、不要用锁/计数器挂起线程。所有Mono本质是冷流，只有最终被订阅时才会真正发起远程调用，只需要把所有异步流的定义、聚合逻辑写好，最后把聚合后的Mono返回给Web容器调度，全程无额外阻塞。

基础聚合逻辑 #

1. 把每个独立的WebClient远程调用封装成独立的Mono实例，此时不会真正发起请求
2. 用Mono.zip()打包所有需要等待的Mono，该API会自动等所有入参的Mono成功返回值后，才会触发后续的聚合逻辑
3. 在zip的组合回调里直接获取每个Mono的真实返回值，执行原本写在subscribe里的业务逻辑，组装成需要返回的Dto

两个Mono的聚合示例（对应你最初的两次调用场景） #

@RequestMapping(value = ["/{userId}"], method = [RequestMethod.GET])
fun getRoomList(@PathVariable("userId") userId: String): Mono<RoomDto.FullInfo> {
    // 定义两个独立的远程调用Mono，此时不会真正发起请求
    val priceSumMono: Mono<List<RoomPriceSumDto>> = Room.getRoomPriceSumMono(webClient, buildPriceQueryParam())
    val userListMono: Mono<List<List<UserDto.Info>>> = roomService.getUserListInRoomListMonoFromRemote(webClient, buildUserQueryParam(userId))

    // zip聚合，等两个Mono都返回后组装结果
    return Mono.zip(priceSumMono, userListMono)
        .map { tuple ->
            val priceSumResult = tuple.t1
            val userListResult = tuple.t2
            // 在这里执行原本写在subscribe里的业务逻辑
            val processedRoomInfo = processRoomPrice(priceSumResult)
            RoomDto.FullInfo(
                roomInfoList = processedRoomInfo,
                userListInRoomList = userListResult,
                userRoomCap = calcRoomCap(processedRoomInfo),
                maxRoomCount = getMaxRoomLimit()
            )
        }
}

你之前用Mono.zip没成功的核心原因是：依赖了subscribe回调里给外部变量赋的值来做聚合，但subscribe是异步执行的，zip初始化的时候这些变量还是空值。正确写法是完全通过tuple把每个Mono的返回值传递到组合逻辑里，不依赖外部临时变量。

扩展到3个及以上不同类型Mono的场景 #

• 聚合数不超过8个时，直接用带Tuple的zip重载方法，通过t1/t2/t3...依次获取每个流的返回值，天然支持不同类型的返回值

// 三个不同类型Mono的聚合示例
Mono.zip(
    priceSumMono,
    userListMono,
    roomCapConfigMono // 第三个远程调用返回房间容量配置
)
.map { tuple ->
    RoomDto.FullInfo(
        roomInfoList = processRoomPrice(tuple.t1),
        userListInRoomList = tuple.t2,
        userRoomCap = tuple.t3.defaultCap,
        maxRoomCount = tuple.t3.maxCount
    )
}

• 聚合数超过8个时，用Mono.zip(Iterable)的重载方法，把所有Mono放到集合里传入，聚合后按顺序取返回值即可。

如果当前应用没有全量切换到响应式Web栈，接口必须返回同步的RoomDto.FullInfo而非Mono<RoomDto.FullInfo>，不需要手写CountDownLatch，直接对聚合好的Mono调用.block()即可，比手写计数器安全得多：

// 前面的zip聚合逻辑和之前一致，最后直接block拿值
return Mono.zip(priceSumMono, userListMono)
    .map { tuple -> /* 组装Dto的业务逻辑 */ }
    .block()

这种写法的优势是：自动处理远程调用异常、支持配置超时时间、不存在计数遗漏的风险。

• 给每个远程调用的Mono单独加超时，比如priceSumMono.timeout(Duration.ofSeconds(3))，避免单个慢请求拖垮整个聚合流程
• 统一异常处理：任意远程调用失败时返回兜底数据，用onErrorReturn/onErrorResume实现降级逻辑
• 不要在subscribe回调里做变量赋值，所有业务处理逻辑都放在map/zip/flatmap的组合逻辑里，由Reactor调度器保证线程安全

内容的提问来源于stack exchange，提问作者mazend