【经典问题】go本身有很方便的RPC, mqant为啥还要通过rabbitmq来实现rpc
发布于 1 年前 作者 liangdas 1377 次浏览 来自 问答

群主,我还有个疑问,go本身有很方便的RPC, 为啥还要通过rabbitmq来实现或你说的下一版的grpc?

2 回复

最近确实想到了要移植grpc,本来想像起来移植应该比较简单,不过仔细分析以后发现跟我最初设计mqant的rpc通信模式还多少有些冲突。

  1. 金典的RPC通信模式 目前经典的rpc通信基本上都是基于TCP网络通信的,也就是server/client模式

    原理是: server端开启一个tcp监听 client端发起一个tcp请求跟server保持连接

    以后的rpc调用就都通过这个tcp连接来发送和接收 这种模式有几个问题需要处理

    1. tcp连接的断线重连问题
    2. 多server与多client连接管理问题 server=100 client=100 总的tcp连接需要100*100=10000 长期保留如此多的连接操作系统有些吃不消
  2. 微服务http模式 不细说,就是不做tcp长连接,通信一次就断开 以上两种模式都要求服务端做到请求立刻处理和回复

mqant rpc设计模式

mqant rpc采取的是消息队列(rabbitmq)模式,与传统的rpc模式不同之处在于rpc调用和回复是分开的,也就是说rpc消息过来了以后服务器可以不立刻处理,而是放在队列里面根据我服务器的性能情况一个一个来处理。

另外一个区别是有消息队列做中转有以下几个优点

  1. tcp连接数少 一个进程只与rabbitmq保持几个可控的tcp链接,这块性能可控
  2. rpc请求与答复分离,服务端可以做容错和消息分流,比如我可以把服务1关了,把rabbitmq里面的消息发送到服务2去处理,而rpc调用方是不需要关心服务端的实际情况的,只要能在默认过期时间内答复我处理结果就可以了,现在默认超时时间是5秒
  3. 可以实时监测到消息的处理情况,当消息有积压的时候,我们可以新增服务器去减小当前服务器的压力

目前对消息队列做rpc大家最大的顾虑可能是

  1. rabbitmq性能问题

    对于第一个问题我是这样理解的,首先rabbitmq支持集群,就算是单台rabbitmq服务器理论上也能达到数千条/秒的分发量。另外mqant是针对单个模块都可以设置rabbitmq,对于消息量大的模块可以单独给一个rabbitmq去为它服务
    
    与其将rpc性能的不确定性分布到业务机器上去,还不如将这种性能问题归结到单独的rabbitmq模块来定向优化
    
  2. 增加一个rabbitmq可能带来运维成本的上升

    用rabbitmq做rpc可控性应该更高一些,比如传统的rpc因为tcp链接抖动断开重连时带来的异常可能比较难以捕获,虽然用tcp链接前期不需要运维,但当数据量大的时候应该还是会有专人来做这方面的维护工作。
    

当然mqant移植grpc是完全可以实现的,只是可能会失去mqant 默认rpc的一些好处吧

回到顶部