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

[glacial]

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

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

想了一下有两个办法

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

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

有没有好的解决办法.

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

[sagaxu]

冗余

[FreeEx]

网关缓存用户 id 和用户名称，返回的时候修改原先的结构体加上用户名。

[chenqh]

我估计下面会有人推荐用专门的东西来查询这种 sql join 的操作

[qq960826]

看情况，可以两者都提供，

[w4ngzhen]

根据用户名模糊查询，我觉得可以有一个用户服务接口，根据用户名模糊查询得到一批满足条件的用户 id，然后拿着这批 userIds 去订单服务查 where user_id in 的。事实上，无论你的查询条件入口有多么的复杂，你总是可以将这些条件最终转换为你订单表中的字段的。当然这样的缺点是与数据库的通讯会增多，但是你的接口能够更加纯粹。

[w4ngzhen]

接上，这样做还有一个好处是，如果某天你的查询条件增加了比如要根据用户的等级巴拉巴拉之类的来查询。那么你需要做的只是根据用户等级来得到 userIds，然后同上处理。你的 sql 不会有任何修改。

[lihongming]

个人认为，微服务是天然为云服务而生的。在云时代，一切都可以无限横向扩展，以前的很多优化思路都不再适用甚至完全相反了。

具体到楼主的例子，比如你获取了一个 1w 条记录订单列表，需要获取每个订单的用户信息，那你就发起 1w 个并发请求到用户信息服务里去查不就完了吗？

以前我们 join 完了再返回数据是因为数据库 IO 是性能瓶颈，所以要减少查询请求次数。但当你有 1w 台服务器同时为你服务，每台服务器只查一条数据的时候，这还是瓶颈吗？

当然，超大型服务可能还是要考虑服务器数量限制问题，毕竟服务器不是真的无限。但对一般的互联网企业来说，云平台的服务器跟无限的差不多。而且你只需为使用的时间付费，1 台服务器用 1w 秒与 1w 台服务器用 1 秒的价格是一样的。

[dongisking]

@lihongming 这 1w 次请求里耗时挺久的吧？

[lihongming]

@dongisking 没具体测试过，但我一直这么用云，主观感觉速度还是很快的，页面都是秒开。

而且用户再多也是那么快，反正是横向扩展的，用户多少与我无关。无需考虑这些问题可以有效减少开发时间。

当然实际应用不会有 1w 个并发，一般也就几十个。我说 1w 的例子是为了让事情变得更明显，传统思路是时候改变一下了。

[hocgin]

如果是根据 id 查名称之类的话，可以考虑一下我这个做法。https://github.com/hocgin/spring-boot-starters-project/tree/master/spring-boot-named

[hocgin]

@hocgin 这个是 demo https://github.com/hocgin/spring-boot-starters-project/tree/master/spring-boot-samples/named-spring-boot-sample

[lpts007]

@lihongming 你们多少台服务器啊

[reus]

@lihongming 你的钱也能无线横向扩展吗？说得好像用云不要钱似的。带宽，内存，都要真金白银换的，价格也不是线性变化的，尤其是大带宽，贵得很

[est]

拆服务的颗粒度应该以部门或者业务组为单位。除此之外都是瞎 jb 拆。订单和用户分别属于两个领导管吗？是的话就按他们职能拆，不是就别拆了，都一个人一个部门了，你那个体量还不值得去拆。

[blessyou]

还是 2 吧，当你有多个用户服务在不同地域的服务器上部署，1 会慢的离谱，网络耗时贼多。

[winnie2012]

用户名最简单了，不会变，就冗余到订单表，这样查询就一条 SQL 。
要是昵称什么的，昵称修改时需要更新订单表的昵称数据。

[glacial]

@winnie2012 冗余就会涉及到更新, 当我很多个业务表都要关联用户表的时候 ， 用户名变更会 产生更新很多个业务表的需求，一但数据量变大 这种更新也会是一种灾难

[glacial]

@hocgin aop 加注解

[liuzhaowei55]

@reus 那想过没，可能是你的系统还不到需要使用微服务的时候。

[liuzhaowei55]

1，2 两个方案完全不冲突，如果是单次数据量大更应该使用方案 2，如果超大不只你这个模块需要处理这么大数据，其他模块也是存在一样的压力，不用担心很多的，系统的升级都是从实际生产中慢慢演变的，不是一蹴而就的，能直接拿来参考的模型不多