Spring WebFlux如何实现顺序API调用且避免嵌套并遵循单一职责？

核心思路 #

你当前的嵌套flatMap写法属于典型的响应式回调地狱，可读性和可维护性都很差，也不符合单一职责原则。这种顺序依赖调用的场景优先用zipWhen实现，不要用Context：Context是用来传递跨订阅链路的全局非业务参数（比如traceId、租户ID）的，用来存业务中间结果会导致逻辑隐晦、调试成本极高，完全不符合该场景的使用要求。

优化后的实现代码 #

import reactor.util.function.Tuples;

public Flux<PersonDto> getPersons() {
    return service.callA()
            // 第一步：调用B，同时保留A的结果
            .zipWhen(dtoA -> service.callB(dtoA.getAddressId()))
            // 第二步：调用C，同时保留A、B的结果
            .zipWhen(tupleAB -> service.callC(tupleAB.getT2().getPostalCodeId()))
            // 第三步：统一拼装DTO
            .map(tuple -> {
                var dtoA = tuple.getT1().getT1();
                var dtoB = tuple.getT1().getT2();
                var dtoC = tuple.getT2();
                return PersonDto.builder()
                        .name(dtoA.getName())
                        .address(dtoB.getAddress())
                        .postalCode(dtoC.getPostalCode())
                        .build();
            });
}

如果要严格遵循单一职责，还可以把每个步骤拆成独立的私有方法，方便单独单元测试：

public Flux<PersonDto> getPersons() {
    return service.callA()
            .zipWhen(this::callBWithAResult)
            .zipWhen(this::callCWithABResult)
            .map(this::buildPersonDto);
}

// 仅负责根据A的结果调用B，返回A+B的组合结果
private Mono<Tuple2<DtoA, DtoB>> callBWithAResult(DtoA dtoA) {
    return service.callB(dtoA.getAddressId())
            .map(dtoB -> Tuples.of(dtoA, dtoB));
}

// 仅负责根据A+B的结果调用C，返回C的结果
private Mono<DtoC> callCWithABResult(Tuple2<DtoA, DtoB> tupleAB) {
    return service.callC(tupleAB.getT2().getPostalCodeId());
}

// 仅负责根据三个接口的结果拼装响应DTO
private PersonDto buildPersonDto(Tuple2<Tuple2<DtoA, DtoB>, DtoC> tuple) {
    var dtoA = tuple.getT1().getT1();
    var dtoB = tuple.getT1().getT2();
    var dtoC = tuple.getT2();
    return PersonDto.builder()
            .name(dtoA.getName())
            .address(dtoB.getAddress())
            .postalCode(dtoC.getPostalCode())
            .build();
}

方案说明 #

• zipWhen 是专门设计用来处理「第二个Publisher依赖第一个Publisher的返回值」的场景，会自动保留前序的返回结果，不需要手动捕获外部变量，完全避免了嵌套回调。
• 拆分后每个方法只负责单一逻辑，改动任意一个调用的逻辑不会影响其他步骤，也可以单独对每个步骤写单元测试，完全符合单一职责原则。
• 如果你觉得Tuple的嵌套可读性差，也可以自定义一个临时的中间数据类来存A、B、C的结果，语义会更清晰。

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