请教下微服务间大批量数据获取一般是如何处理的

直接读 b 库
不让读的话只能说又想马儿跑又不给马儿吃草

oss or 离线数仓，如果在线去拉的话 就算可行，ab 服务的 io 会不会被占满导致其他接口、服务不可用？

获取一批处理一批, 怎么就把业务处理时间拉长了?
你一次获取, 不还是要处理这么多?

要么时间换空间，要么空间换时间
你这又嫌内存占用大又嫌处理时间长的
就算让 a 直接读 b 库，那内存占用无非是从 b 服务器转移到 a 服务器

看看能不能让 a 不依赖 b ，数据分别进 a 、b 服务
如果 a 强依赖 b ，那就别微服务了，把 a 整合进 b ，或者 a 的这一部分功能整合到 b

这事我有经验。
1 、不要在 responseBody 里返回， 那样内存一定会爆。
2 、不要分页查询，两个原因：①不同分页的查询不在一个事务中，会有数据一致性的问题。②当查询到靠后的分页时，耗时直线上升，性能太差。

3 、如果能让 a 直接读库，那是一种解决方案。但如果 b 里有些处理逻辑比较复杂，那你得在 a 中重新实现一遍，重复工作量且代码冗余，不合适。

我们最终采取的方案是：访问数据源时使用游标，一行行读取数据后，通过 http outputstream ，用流式返回。

时间换空间：小批次分批执行
空间换时间：增加内存，大批量执行
中间方案：放在共享存储（例如 nfs ），mmap 读文件，增加消费者进程消费

数据表做数据冗余吧。

@xiaohupro 就是一次查询改为多次查询后比较耗时，不太想引入额外的中间件来处理

@kchenzhi a 服务本地数据源的话是会使用流式查询的，倒是不清楚微服务调用也能使用流式处理的方式，感觉可以参考，谢谢

直接在 b 服务处理数据，再通知或调用 a 服务

定时生成文件给下载地址（这感觉很像对账单）

@kchenzhi #26 `当查询到靠后的分页时，耗时直线上升，性能太差。`
盲猜是不是用的 limit offset 做的分页

@molicloud b 服务只负责从数据库查询数据，不处理具体业务

b 服务查出来往 kafka 里面丢，a 服务消费处理

A 服务提交一个任务给 B 服务，B 服务收到任务后推送数据给 A 服务。两个服务之间的数据完备性检查，你可以使用类似于 TCP 传输的形式。A 服务不用管 B 服务怎么实现的，只需要接收数据就行了，B 服务则需要让 A 服务记录数据完整性的元数据。

不建议走接口 ，ETL 转换调度

@gibber #35 在新建一个 b-analysis 服务，也连和 b 相同的数据库

不要分页，用游标依次写到队列里