如何基于非分页API构建分页聚合API，该实现是否属于不良实践？

直接在API C上层基于两个非分页接口实现分页，绝大多数场景下属于不良实践，不建议作为长期方案使用，核心问题如下：

• 资源浪费极其严重：API A返回的是大规模数据集，每次处理分页请求都需要全量拉取API A、API B的全部数据，聚合完成后再截取对应分页范围的内容返回。不管用户请求的是第几页，都要承受全量拉取大数据的带宽、CPU、内存开销，请求耗时高不说，流量上来后很容易打垮API A或API C的服务。
• 数据一致性无法保障：基于内存中临时聚合的数据集做偏移分页，两次分页请求的间隙如果API A或API B有数据增删，会直接出现分页结果重复、漏项的问题，完全不符合分页接口的一致性要求。
• 可扩展性基本为零：如果后续ItemA的数据集持续增长，全量拉取的超时、服务OOM风险会指数级上升，这套方案完全扛不住数据量的增长。

如果是临时过渡场景，同时满足API C访问量极低、API A当前数据量远没到触发拉取超时/内存溢出的阈值、业务对分页一致性要求不高、已经在排期改造下层分页能力这几个前提，可以临时使用上层分页方案过渡，但绝对不能长期线上运行。

最优改造方案 #

优先改造API A为分页接口即可，API B因为返回的是小规模数据集，不需要做分页改造：

1. API C接收上游传入的分页参数（页码、每页条数、排序规则等）
2. API C将分页参数透传给改造后的分页版API A，拉取对应页的ItemA数据
3. API C全量拉取API B的小规模ItemB数据集，和当前页的ItemA做聚合后直接返回即可

如果业务要求分页的排序规则是基于聚合后的联合字段，而非ItemA本身的字段，可以额外引入预聚合存储层，定时同步API A、API B的数据到统一存储（如Elasticsearch）中做索引，直接基于预聚合好的数据做分页查询，性能和一致性都能得到保障。

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