系统如果组件比较多，在做技术选型时，组件通信该选择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)