前言
具有一定复杂度的业务都有可能存在跨服务分页搜索的问题，这是一个常见的技术难点，接下来将介绍几种常见的方式，以在一定程度上解决这个问题。
组合筛选
适用场景：对于量级不大，比如一些业务Key过滤后，数据量小于1k这种情况，我们可以考虑这种方案。
优点：处理简单，不需要额外的中间操作（数据同步、中间表...）。A服务过滤后的数据，再传给B服务过滤，C服务 ...，直到完成
缺点：过滤参数在服务间传递过多、依赖较多服务、不能传递过多的参数等
微批查询
并不是所有场景都限制严格意义上的实时，准实时的情况下，针对跨服务、跨库的查询方案，我们还可以定时微批查询的方式，将结果先同步到结果表，业务层直接从中间表查询数据。
比如 30s、60s、120s ... 等时间跨度。
适用场景
特点：
- 准实时
- 大吞吐：查询消耗大，消耗一定算力。（单次查询调动的数据量级大）
- 高并发：使用场景量级较大
如果你的业务场景有这些特点，可以考虑使用微批查询。
定期同步数据到业务表
考虑这么一个场景，直播过程中，管理端需要观察C端的各种行为数据、营销数据，比如：
- 在线时长
- 抢券行为
- 支付行为
- 调起支付次数
- IM互动次数
- 标签备注
- 数据权限控制
即，展现一个比较全面的数据面板，基本是准实时展示，涉及到多个服务、多个数据表的交互，经过一系列的计算、数据整合展示出来。
可以怎么做？
如果你的直播间的人不多，比如少于 1000 人，并且请求并发量也不高，那这时可以直接通过服务间 RPC 调用组装数据，然后实时返回，这种方案最简单、直接。
但如果直播间人数大于10000，或者并发量很高，这个时候上面的方式就不行了，因为单次请求就比较耗费资源，这个时候你稍微改进方案就可以支持业务场景了：
- 定时任务：1分钟、2分钟定时跑数据到结果表
- 数据怎么跑？还是可以通过服务间 RPC 的方式，组装好数据存入结果集中。
你看，改动点在哪里？把原来实时查询返回的操作，改成定时跑批，写入结果表。然后从结果表查询数据。
一个小改动足以支撑大部分业务场景！!
Doris 分布式查询
作为一款分布式数据库，其目标是高并发、大吞吐。
因此在笔者以前的业务场景中，使用了 doris 来支持部分大表 JOIN 查询的方式。
通过微批定时操作，利用 doris JOIN 查询能力，将数据结果查询至指定的结果表中。
之后，业务接口直接从结果表查询数据。
...
当然，这种微批查询的方式还有很多，有兴趣的小伙伴可以补充说明。
同步方案
如果说你的业务场景数据量级大、实时性要求比较高，那么同步方案可能更加适合你。
最常见的是监听 binlog 日志，比如大名鼎鼎的 Canal 组件，本质是模拟 MySQL 的从库，从而实时监听到 binlog 消息，经过简单处理后往下游传递数据。
那监听到数据后，写入哪里呢？
- MySQL
- ES
- Kafka
- Redis
- ...
很多，具体看你的业务场景和使用习惯。
接下来，笔者以场景的写入 ES 为例，讲解整体流程：
kafka 对于监听 binlog 这种数据量级比较大的优势就出来了，通过 canal 监听 binlog 并输出到 kafka，之后 kafka 的下游使用就很灵活了，可以直接是业务系统，也可以是基础平台...
通用的 ES 同步方案
通过将 Kafka 消息直接输出到 ES 很简单。我们应该考虑，如何把这一步进行抽象，将这块能力独立出来。
即，假设我们定义一个 ES 基础平台，这个平台负责维护业务的数据，并且要方便业务对接并使用：
- 方案一：推模式，即，业务系统自行监听 kafka 消息，并推送到 ES 平台（ES基础平台提供标准的推送接口）
- 方案二：拉模式，即，ES基础平台监听 kafka 消息，业务系统只需提供接口，获取业务数据（一般是主键id）
以上两种方式都能很轻易的处理复杂的业务取数逻辑，又能将存储数据至 ES 这块能力真正独立出去。
当然，最重要的是，能实时监听数据变化，并作出更新动作！！！
小结
以上几种方案比较常见，笔者也在实际业务中都使用过，技术无优劣之分，能满足业务需求、并留有一定的扩展空间，都是不错的方案，你可以按需选择。