服务接口,选择rpc还是http?

妙音 posted @ 2018年6月02日 23:32 in 架构 , 161 阅读
系统如果组件比较多,在做技术选型时,组件通信该选择rpc还是http呢?
有人说rpc性能好,有人偏向http,对此有些疑惑,有必要细细思维一下。
 
  • 从通信内容/功能上看

内容 rpc       http     
字符串 支持 支持
文件 可以支持 支持
对象(序列化) 支持 可以支持
 
http应用于web环境,rpc应用于分布式调度
从功能上看没有太大区别,很多情况下rpc与消息中间件结合通信实现分布式调度
 
  • 从用法上看

两者都是c/s结构,无太大区别
 
  • 从实现上看

类型 底层协议
rpc tcp(zerorpc)/http2(gRPC)
http http1.x/http2
 
  • 从性能上看

1. 听说rpc是长链接,http是三次握手。
长链接虽然,可以减少tcp开销,相对的它会导入新的缺点,是否会对连接数数量有限制呢?
 
2. 假如rpc的性能比http高,无非就是socket多连接了三次。如果http结合非阻塞io服务器(例如tornado),这三次连接开销真没啥消耗。
当然网络也会有一点消耗. 非阻塞io服务器可以将rpc与http的性能差距拉平
 
从链接开销上,比较性能问题,本就是错误,两者是在解决不同问题,所有没有必要在这个问题上纠结。请继续看下面
 
  • 从概念上看

rpc远程调用
http超文本传输协议
 
  • 该如何选择呢?

1. 思考这个问题,应该用最简单的方式,相信协议设计者,会选择最好方式来解决它面临的问题(毕竟协议代表着公认),我们只用关注它解决什么问题。
rpc解决什么问题呢?远程调用。"调用"属于程序内部之间。调用总不可能只传简单参数,会涉及到对象序列化,
这个对象在开发是代码总不会用两套吧,server与client很可能是在一起的属于一个组件.
 
2. 连接数不该是"调用"考虑的事。在创建一个全局连接后,不会再频繁创建连接. 如果rpc作为服务,频繁连接的场景不适合它
 
  • 总结

1.c与s关系
rpc远程调用,属于程序内部之间,c与s关系密切。
http,适合不同组件,c与s关系独立。
 
2.连接数
rpc叫调用,频繁连接的场景不适合它
http的应用的web环境,本就是频繁连接的场景
 
《寿康宝鉴》有声书
寿康宝鉴百话有声书(mp3)
 

登录 *


loading captcha image...
(输入验证码)
or Ctrl+Enter