不知道题主说的是不是Java中的PRC框架。下面小冷就说下Java中的集中常见的RPC框架，RPC呢是远程过程调用框架，也就是说两台服务器A,B, 一个应用部署在A服务器上，另一个应用部署在B服务器上，A服务器上的应用想要调用B服务器上的应用提供的方法/函数，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语意和传递调用的参数。提供这种服务的框架我们就叫他RPC框架，RPC是远程过程调用的简称，广泛应用在大规模分布式应用中，作用是有助于系统的垂直拆分，使系统更易拓展。Java中的RPC框架比较多，各有特色，广泛使用的有Hessian、CXF、Dubbo、Dubbox、Spring Cloud、gRPC、thrift等。RPC最显著的特点就是能够跨语言，多端调用。我记得收藏的有一篇博客就是写RPC的，下面我们对比一下以上RPC框架功能比较：
下面是实际应用场景中的选择：
Spring Cloud ： Spring全家桶，用起来很舒服，只有你想不到，没有它做不到。可惜因为发布的比较晚，国内还没出现比较成功的案例，大部分都是试水，不过毕竟有Spring作背书，还是比较看好。
Dubbox： 相对于Dubbo支持了REST，估计是很多公司选择Dubbox的一个重要原因之一，但如果使用Dubbo的RPC调用方式，服务间仍然会存在API强依赖，各有利弊，懂的取舍吧。
Thrift： 如果你比较高冷，完全可以基于Thrift自己搞一套抽象的自定义框架吧。
Montan： 可能因为出来的比较晚，目前除了新浪微博16年初发布的，
Hessian： 如果是初创公司或系统数量还没有超过5个，推荐选择这个，毕竟在开发速度、运维成本、上手难度等都是比较轻量、简单的，即使在以后迁移至SOA，也是无缝迁移。
rpcx/gRPC： 在服务没有出现严重性能的问题下，或技术栈没有变更的情况下，可能一直不会引入，即使引入也只是小部分模块优化使用。
至于项目中用那种rpc框架，这个还是根据项目类型来好一点，如果是一个小型项目的话就没有必要使用，如果是一个中大型的项目的话这个用那种要考虑好，后期更换的话比较麻烦。
从使用场景和功能比较，相信题主对常用的JavaRPC框架有一定了解了吧，希望对你有所帮助！
我是小冷，一个刚开始创组的小白，希望大家关注、点赞、评论、转发！
