通用化处理可分页Feign API调用的策略与实践_技术教程

本文探讨了如何通过函数式编程思想，优雅地抽象和通用化处理具有不同参数签名但都支持分页的feign api调用。通过引入统一的`pagingapi`接口和参数绑定机制，我们能够显著减少为每种api签名编写的样板代码，实现高度可复用和可维护的分页数据获取逻辑，并提供迭代式分页的最佳实践建议。

在微服务架构中，Feign客户端常用于声明式地调用远程API。当面对大量支持分页的API时，一个常见挑战是这些API可能具有不同的业务参数，但其分页参数（页码和每页大小）始终存在且位置固定。如果为每种参数组合都创建特定的接口和包装类，将导致大量的样板代码，降低代码的可维护性和可扩展性。

初始方法的挑战

考虑以下场景：我们有一个通用的分页数据获取逻辑drainFeignPageableCall，它依赖于一个PagedCall接口来执行实际的API调用。

public  List> drainFeignPageableCall(
        PagedCall feignCall
) {
    BaseFeignResult firstPage = feignCall.call(0, 10);
    List> baseFeignResults = drainFeignPageableCall(feignCall, firstPage, Lists.newArrayList(firstPage), 1);
    return baseFeignResults;
}

// 递归辅助方法
 List> drainFeignPageableCall(
        PagedCall feignCall,
        BaseFeignResult dataPage,
        List> acc,
        int page
) {
    if (dataPage.resp.getBody().getData().size() % 10 > 0) // 假设每页大小为10，此处判断是否最后一页
        return acc;

    BaseFeignResult res = feignCall.call(page, 10);
    acc.add(res);

    return drainFeignPageableCall(feignCall, res, acc, ++page);
}

// 核心数据结构与接口
public interface PagedCall {
    BaseFeignResult call(int p, int s);
}

@Builder
public static class BaseFeignResult {
    private final ResponseEntity> resp;
    private final RuntimeException excp;
}

为了使drainFeignPageableCall能够处理带有业务参数的API，例如ordersFeignClient::getOrdersBySampleIds，最初的解决方案可能涉及创建如下的特定接口和包装类：

public interface SingleParamPagingApi {
    ResponseEntity> callFeignApi(String arg, int page, int size) throws RuntimeException;
}

public static class SingleParamPageableCall implements PagedCall {
    SingleParamPagingApi fun;
    String param;

    public SingleParamPageableCall(SingleParamPagingApi fun, String param) {
        this.fun = fun;
        this.param = param;
    }

    @Override
    public BaseFeignResult call(int p, int s) {
        BaseFeignResult.BaseFeignResultBuilder builder = BaseFeignResult.builder();
        try {
            builder.resp(fun.callFeignApi(param, p, s));
        } catch (RuntimeException e) {
            builder.excp(e);
        }
        return builder.build();
    }
}

这种方法虽然可行，但每当API的业务参数数量或类型发生变化时（例如，从一个String参数变为两个String参数），就需要定义一个新的XParamPagingApi接口和对应的XParamPageableCall类，导致大量的重复代码和繁琐的维护工作。

采用函数式编程思想：统一分页API

为了解决上述问题，我们可以采用函数式编程中的“部分应用”（Partial Application）思想。核心思路是：将API的业务参数预先绑定，生成一个只接受分页参数的统一接口。

定义带业务参数的API接口： 首先，定义一些泛型接口，它们接受不同数量的业务参数，以及页码和每页大小。

// 针对一个业务参数的API接口
public interface PagingApi1 {
    ResponseEntity> callFeignApi(A0 arg0, int page, int size) throws RuntimeException;
}

// 针对两个业务参数的API接口
public interface PagingApi2 {
    ResponseEntity> callFeignApi(A0 arg0, A1 arg1, int page, int size) throws RuntimeException;
}

// 可以根据需要定义更多参数数量的接口，如PagingApi3, PagingApi4等

定义统一的分页API接口： 这个接口只负责接收页码和每页大小，不关心任何业务参数。
```
public interface PagingApi {
    ResponseEntity> callFeignApi(int page, int size) throws RuntimeException;
}
```
提供静态工厂方法进行参数绑定： 在PagingApi接口中，提供静态的of方法。这些方法接受具体的业务API接口实例和其对应的业务参数，然后返回一个PagingApi的实例。通过Lambda表达式，业务参
数被“捕获”并绑定到内部，使得返回的PagingApi实例在被调用时，能够使用这些预设的业务参数。
```
public interface PagingApi {
    // ... (上述接口定义)

    // 绑定一个业务参数
    static  PagingApi of(PagingApi1 api, A0 arg0) {
        return (p, s) -> api.callFeignApi(arg0, p, s);
    }

    // 绑定两个业务参数
    static  PagingApi of(PagingApi2 api, A0 arg0, A1 arg1) {
        return (p, s) -> api.callFeignApi(arg0, arg1, p, s);
    }

    ResponseEntity> callFeignApi(int page, int size) throws RuntimeException;
}
```
通过这种方式，无论原始API有多少个业务参数，我们都可以通过PagingApi.of(...)方法将其转换为一个统一的PagingApi实例，这个实例只关心分页参数。

重构分页调用包装器

有了统一的PagingApi，我们就不再需要SingleParamPageableCall这样的特定包装器了。取而代之的是一个通用的PageableCall，它直接接收PagingApi实例。

public static class PageableCall implements PagedCall {
    PagingApi fun;

    public PageableCall(PagingApi fun) {
        this.fun = fun;
    }

    @Override
    public BaseFeignResult call(int p, int s) {
        BaseFeignResult.BaseFeignResultBuilder builder = BaseFeignResult.builder();
        try {
            builder.resp(fun.callFeignApi(p, s));
        } catch (RuntimeException e) {
            builder.excp(e);
        }
        return builder.build();
    }
}

实际应用示例

现在，调用drainFeignPageableCall变得非常简洁和富有表现力：

// 假设 ordersFeignClient::getOrdersBySampleIds 是一个实现了 PagingApi1 接口的方法引用
drainFeignPageableCall(
        new PageableCall(
                PagingApi.of(ordersFeignClient::getOrdersBySampleIds, "34596")
        )
);

通过PagingApi.of方法，我们描述了如何将业务参数"34596"映射到getOrdersBySampleIds方法上，并生成了一个统一的PagingApi实例，再由PageableCall包装，最终传入drainFeignPageableCall进行分页数据获取。

进一步的优化和最佳实践

合并接口： PagingApi和PagedCall在功能上非常相似，都可以考虑合并成一个接口，例如直接让PagingApi实现PagedCall的功能，或者将PageableCall的逻辑内联到PagingApi的实现中。这可以进一步简化代码结构。

迭代式分页而非递归： 原始的drainFeignPageableCall方法使用了递归来获取所有页面数据。在Java中，深层递归可能会导致栈溢出错误（StackOverflowError），尤其是在处理大量页面时。更健壮和高效的做法是使用迭代（while或for循环）来替代递归。

public  List> drainFeignPageableCallIterative(
        PagedCall feignCall,
        int initialPageSize // 初始页大小，假设所有页面都用此大小
) {
    List> allResults = new ArrayList<>();
    int currentPage = 0;
    boolean hasMore = true;

    while (hasMore) {
        BaseFeignResult pageResult = feignCall.call(currentPage, initialPageSize);
        allResults.add(pageResult);

        // 检查是否有异常
        if (pageResult.excp != null) {
            // 处理异常，例如记录日志或抛出
            System.err.println("Error fetching page " + currentPage + ": " + pageResult.excp.getMessage());
            break; // 遇到错误停止
        }

        // 假设 IVDPagedResponseOf 包含总页数或当前页数据量来判断是否还有更多数据
        // 这里以原始逻辑为例，如果当前页数据量小于请求大小，则认为是最后一页
        if (pageResult.resp.getBody().getData().size() < initialPageSize) {
            hasMore = false;
        } else {
            currentPage++;
        }
    }
    return allResults;
}

请注意，上述迭代实现中的分页结束条件需要根据实际的IVDPagedResponseOf数据结构来精确判断，例如检查totalElements、totalPages或当前页返回的数据量是否小于请求的size。

总结

通过引入统一的PagingApi接口和静态工厂方法进行参数绑定，我们成功地将Feign API调用中的业务参数与分页逻辑解耦。这种方法极大地减少了处理不同API签名时的样板代码，提高了代码的复用性和可维护性，使得分页数据获取逻辑更加清晰和富有表达力。同时，采用迭代而非递归的方式处理分页，也提升了程序的健壮性和性能。

通用化处理可分页Feign API调用的策略与实践

Spring Boot REST API 异常处理最佳实践：

Java密码强度校验：正确检测字符串中的特殊字符、数字和字母

Spring Boot REST API 异常处理最佳实践：

Java密码强度校验：正确检测字符串中的特殊字符、数字和字母

相关文章