不知道題主說的是不是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框架，這個還是根據專案型別來好一點，如果是一個小型專案的話就沒有必要使用，如果是一箇中大型的專案的話這個用那種要考慮好，後期更換的話比較麻煩。
不知道題主說的是不是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框架，這個還是根據專案型別來好一點，如果是一個小型專案的話就沒有必要使用，如果是一箇中大型的專案的話這個用那種要考慮好，後期更換的話比較麻煩。