馬鵬堃
不知道題主說的是不是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框架有一定了解了吧，希望對你有所幫助！
我是小冷，一個剛開始創組的小白，希望大家關注、點贊、評論、轉發！
