在微服务中是用队列好还是 RPC 好

2019-07-04 18:11:01 +08:00
 springmarker

个人浅薄的认识，在大多数场景下可以用队列替换 RPC(指代通常的 RPC，不是由队列实现的 RPC)。
队列的优点：
1.消息可以堆积，只要队列稳定，消息丢失的概率就比直接 RPC 低。
2.由接收端主动获取消息的话，负载就由接收端控制了，不会像 RPC 一样无法均衡的负载。
3.没有类似 Zookeeper 的注册中心，发送端和接收端只要面对队列就可以，发送端不用同时面对注册中心和多个接收端。

缺点的话就是性能不如直接 RPC、需要手动写异步转同步。

我看很多微服务都用的是 GRPC 和 Dubbo 之类的 RPC，甚至 Spring Cloud 的 RPC，如果替换成队列会有什么影响吗？不需要高性能的场景下可以互相替换吗？

本人了解甚少，上面都是班门弄斧的瞎说，如有不对，希望大神能指教一二。

16826 次点击
所在节点    程序员
129 条回复
passerbytiny
2019-07-05 14:57:11 +08:00
@springmarker #112 举个例子。
生产者：1 分 0 秒发送消息一，张三把自己的性别改成女； 1 分 10 秒发送消息二，张三反悔了，把性别改回男。
消费者一，1 分 0 秒收到消息一，因为线程阻塞，1 分 15 秒才开始执行，1 分 17 秒执行完成。
消费者二，1 分 10 秒收到消息二，立刻执行，1 分 12 秒执行完成，数据已同步保存到数据库。
最终的结果是，虽然先改女后改男，消息也是顺序接受的，但执行顺序是先改男后改女，执行顺序与发出顺序不一样。

我大致浏览了第一页的回复，发现你的回复一直是高姿态的回复，翻页之后也没有变化。这种情况虽然没什么不对，但是我已经没有继续讨论的积极性了。
springmarker
2019-07-05 15:09:27 +08:00
@passerbytiny #121 一般这种 web 改性别都是需要同步了吧，而且这种情况用传统 RPC 不也一样吗，消费者也可能不是一个消费者，消费速度也不一定一样，RPC 收到的顺序也不一定是按顺序的，这就涉及到分布式锁的问题了吧。
额，我的姿态很高吗？我平常打字容易口语化吧。
yc8332
2019-07-05 15:34:31 +08:00
完全不同的东西怎么能凑一起比较呢。。。。
jswh
2019-07-05 17:13:57 +08:00
单纯从业务上考虑。如果业务之间的归属一个 transaction 里面的，用 rpc。如果业务之间不是同一个 transaction 只不过是流水线关系的数据传递，用队列。
langxuan
2019-07-05 18:10:49 +08:00
@springmarker 可以认为 RPC 的堆积是实现了某种程度的背压
ErrorMan
2019-07-06 09:45:16 +08:00
@springmarker #22 用队列实现 RPC，那这个还是被视为 RPC。另外看了你的回复感觉你就是怎么样都想把队列往 RPC 里塞，如果你非得塞，可以这么做，做出来也没什么毛病。但是从设计模型上来讲，RPC 模型依然是同步模型，就是说调用你实现的人是把它当同步来使用的，你底层实现成异步同步用不用队列什么的对人家没区别，互相之间都是黑盒。所以不要纠结于用不用队列，对使用者来说没区别，顶多说你实现的 RPC 版本有队列的特性，仅此而已。。总的说设计模型和实现模型是两码事，如果不好好弄清楚他们的关系你会继续钻这个牛角尖。
tenghuanhe
2019-07-06 10:49:38 +08:00
记得 hn 上也有关于这个话题的大讨论，待会我找找链接贴过来
diyazhu
2019-07-09 10:05:45 +08:00
@tenghuanhe 找到了咩
KyoChou
2020-07-30 10:36:38 +08:00
看到了就回复一下吧. 我们有个基于 GRPC 的项目, 每小时的调用日志就有上 10G. 后来为了做分布式, 转成了通过消息(nats)的 request-reply 方式通信, 没有一点问题.

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/580080

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX