微服务下 服务拆分后 查询问题

[glacial]

比如我有一个用户服务, 一个订单服务.

当我查询订单列表的时候要带出 创建订单的用户名 但是我只有用户的 id, 这个时候就需要转换了。

想了一下有两个办法

1.直接远程调用户服务接口 一个一个的转换 但是这样效率也太低了

2.还是远程调用户服务接口,不同的是传一批要转换的 id ,这样只用调一次就够了, 不过在大数据量下就不太好了

有没有好的解决办法.

还有一个问题 当我想跟据 用户名 模糊查询 相关订单的时候 好像处理起来好麻烦, 本来一条 sql 搞定的事.

[qiukun]

@est 中西结合

[simonlu9]

只能说冗余比较好，之前碰到过一个上传 excel 校验，不知道要调多少 rpc，最后不得不折服丢掉 rpc 改消息队列通知

[wangyzj]

方案 2， 你一次这种查询订单也不会太多

[des]

冗余的话，假如用户修改用户名，下次要带上年龄 /或者其他的怎么搞

[Leigg]

当然是第二种了，批量查询，你再多不可能一次性几万个，分页是常用手段。

[hpeng]

批量查，接口按需分页，内存组装数据。

[kur0d3s]

1. 回调事件 把冗余存在本服务内
2. 搜索引擎 es 之类的 做数据聚合

[latteczy]

> 还有一个问题 当我想跟据 用户名 模糊查询 相关订单的时候 好像处理起来好麻烦, 本来一条 sql 搞定的事.
用户名是会变的，只能实时去查吧。

[xuanbg]

订单列表里面的用户名就是个伪需求。业务部门关心具体某个订单是阿猫还是阿狗？

好吧，真有这种需求的话，聚合查询才是正道。

[menyakun]

从微服务的角度，用户管理和订单管理两个模块分开来的确蛮合理的。

[Jooooooooo]

api 层聚合

[winglight2016]

这个问题类似于 mongodb 这种 nosql 数据库的 document 设计。凡是选择冗余方案都要考虑更新问题，反之就要考虑关联查询的问题。

仅仅考虑 lz 提出的 case，个人建议用户 id 可以作为数组参数一次性请求当前页面所有用户的用户名，或者使用具有唯一性的名称（ tb 订单似乎就是这么搞的）

[lihongming]

@lpts007 具体不知道，我用 AWS，理论上至少有几万台吧

[lihongming]

@reus 带宽什么的仍然是传统思路，serverless 才是真正的云思路。了解一下，你会爱上它的。

[clf]

1 和 2 皆可。
个人认为这样的场景不存在短时间内进行大量数据处理的需求。（可能是我没遇到）
用户名等字段在系统里是作为一个属性存储的，而不是唯一 id 。属性字段往往是给人看的，那么必然不会出现单页面需要显示大量数据的情况。
另外，属性字段可能被用于数据分析，此时数据量是十分巨大的，但数据分析不需要和前端显示一样需要在短时间内完成数据转换。完全有充足的时间进行多次调用。

[MarioLuo]

第二种方式批量获取用户信息，第一种和循环里执行 sql 没有区别应当禁止

用户名模糊查询问题, 用户名变动少可直接冗余，考虑到匹配用户相当多时，不建议先查模糊用户服务的到大量用户 id 。

如果后续订单查询中增加了大量用户相关的查询条件，可考虑使用 es 等数据聚合仓库，冗余了多个服务的数据

[xx6412223]

有些楼层论调真是清奇，好像无限只要 hardware 够就能解决所有问题一样。。。

[lihongming]

@xx6412223 我就是你说的有些楼层。如果我不小心伤到了你的经验，那我只能说声抱歉，然后继续用我的“无限”方案了。毕竟我说的是实战经验，不能因为你不高兴就把系统推了重做不是吗？

我的观点总结起来就一句话——Microservice 依赖于 Serverless 。

不过系统设计最核心的一句话是“一切设计都是妥协”，没有什么绝对正确的方案，就看你的案例适不适合。所以我希望你的观点是在充分了解 Serverless 的原理及其计费方式的情况下产生的，那样至少你明白我方案的利弊，否则咱俩的对话就毫无意义了

[MarioLuo]

@lihongming 不赞成楼主观点，列表页或者导出上万条数据，假设单个 10ms 那么顺序调用总 10s 吧，如果并发执行那不是更复杂了吗，还不如批量组装。总的来说能简单的掉用一次，没有必要调用多次

[lihongming]

@MarioLuo 唉！我觉得我的中文确实退化了，解释了好几遍都没说清楚我的观点。现在完整说一遍吧。

首先呢，楼主是确定使用了微服务架构，这是基本前提。

其次呢，我认为用户和订单分在两个服务里是合理设计，至少是一种常见设计。

有了以上两个前提，我才说，这种场景应该使用 Serverless 云计算。因为云计算可以无限横向扩展，让成千上万台服务器同时为你服务，从而抵消微服务带来的性能损耗，并且不增加服务器成本。

大体就是这样吧，如果还有没说清楚的欢迎帮我细化。

微服务的好处是解耦，并不是追求性能。

Serverless 的好处除了无限横向扩展，还可以降低开发难度，因为程序员基本不用考虑性能瓶颈了。