RPC ： 远程过程调用 remote produce call
网上解释，直接基于TPC/IP协议 ，效率优于HTTP
疑问1：网上又有很多基于HTTP的RPC框架 ， 这个和Rest API有什么区别吗？
疑问2：是不是基于TCP的RPC框架，就等于说客户要使用就要装客户端？
不知道你这个问题是否已经解决, 如果还没有解决的话:
- 你可以看下这个问题的回答https://ask.csdn.net/questions/662787
- 这篇博客你也可以参考下：设计RPC框架应考虑的问题
- 这篇博客也不错, 你可以看下设计RPC框架应考虑的问题
- 除此之外, 这篇博客: RPC框架基础概念篇中的 2.2.1 序列化协议选型上有什么需要考虑的？ 部分也许能够解决你的问题, 你可以仔细阅读以下内容或者直接跳转源博客中阅读:
常见序列化协议对比
据我个人的了解（我是菜鸡硕士生，别全信我啊！），适合序列化的协议就是Json、Hessian、protobuf。
Json协议是典型的Key-Value明文协议，用起来相当方便，但是用Json序列化后的空间开销比较大，性能不行。所以Json pass掉。
Hessian是动态类型、二进制、紧凑的、可跨语言移植的一种序列化框架，序列化后的二进制数据比JSON紧凑高效多了。而且Hessian的兼容性和通用性也比较强，所以Hessian也很适合采用。（个人没用过Hessian，都是网上看的段子。）
Protobuf序列化体积比Json和Hessian小很多，序列化和反序列化速度也很快，消息格式升级和兼容性也不错。不过这不意味着Protobuf就一定全方位比Hessian强。还是要看具体场景的，对于具有反射和动态能力的语言来说，protobuf用起来就比较费劲。（关于这一点说法，我个人没有研究过，不是很懂Java）
序列化协议选型问题：
其实序列化协议还挺多的，比如kryo和Message pack，那么在选择序列化协议中需要考虑什么？
- 序列化和反序列化的性能效率和空间开销
这一点的确是一个重要因素，序列化与反序列化过程是 RPC 调用的一个必经过程，那么序列化与反序列化的性能和效率就会直接影响到 RPC 框架整体的性能和效率以及网络传输的效率。 - 序列化协议的通用性和兼容性
其实这一点我目前还没有涉及过，只是从业内专业人士那里了解来的。比如在业务上，服务提供方将入参加入一个属性之后，服务调用方不能正常调用了，升级RPC版本后发起调用时直接报序列化异常了。
在序列化协议选择上，序列化协议的通用性和兼容性的优先级应该高于序列化和反序列化的性能效率和空间开销。当然了，你的序列化和反序列化性能效率和空间开销不能太拉跨。序列化协议在版本升级后的兼容性是否良好，是否跨平台和跨语言，是否支持更多的对象类型等，这些是优先考虑的。 - 序列化协议的安全性
除了通用性和兼容性，还有就是协议安全性。这个因素的优先级是大于等于通用兼容性的。如果存在漏洞，那危险性可想而知了。 - 总结：
从以上三个角度出发，Hessian和Protobuf基本满足上述要求。Hessian在使用上更加方便，对象兼容性好；Protobuf则更加高效、通用性上也更有优势。而二者在安全性上都做的比较好。（为什么比较好，我暂时还不得知，这里继续挖坑，回头填！）
如果你已经解决了该问题, 非常希望你能够分享一下解决方案, 写成博客, 将相关链接放在评论区, 以帮助更多的人 ^-^