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

系统如果组件比较多，在做技术选型时，组件通信该选择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远程调用，属于程序内部之间，cs关系密切。
   http，适合不同组件, cs关系独立。

2. 连接数
   rpc叫调用，频繁连接的场景不适合它
   http的应用的web环境，本就是频繁连接的场景

《寿康宝鉴》有声书
http://v.youku.com/v_show/id_XMzYxMzA4NDY2MA
寿康宝鉴百话有声书(mp3)
百度网盘 https://pan.baidu.com/s/1rs5k7RTB9DxgdCuG-mSzog 密码 9lf1