優點
-
交互方式簡單，一個service就是一個interface。client/server間的交互協議容易統一。
一般成熟的公司都自己維護的RPC框架(比如百度的sofa-pbrpc, google的gRpc，使用它們非常簡單，只需要一個proto文件就可以描述兩邊的協議交互。因為描述文件(proto文件)是確定的，所以兩邊容易保持一致，基本不會出錯。而且大多可用RPC框架生成所有interface的封包、解包代碼，用戶只需要調調函數即可。 -
測試方便。
大多RPC框架是跨語言的，所以可用更方便的腳本語言(如python)寫測試程序，模擬與C/C++程序的交互。
缺點
-
多了一層間接性，出現網絡問題時，debug比較困難。
-
交互方式單一，不能進行復雜的多模塊之間的協議交互。
RPC的描述方式較單一，一般是一應一答。有一些場景沒法用RPC描述，比如有一個服務需要協調多個模塊、服務端主動發通知給客戶端。 -
異常處理困難。
- 如果是同步調用，長時間阻塞怎么辦？
- 如果是異步調用，長時間沒有得到結果怎么辦？
- 如果判斷failure(網絡不通、參數不對、心跳超時)？
可以重試嗎？調用語意：至多一次、至少一次、恰好一次？
一般RPC執行的結果有三種狀態：成功、失敗、超時(未知狀態)。當發生超時時，不知道對端server是收到請求且已經執行了，還是沒收到請求，此時只能通過不斷讀取之前操作的狀態來驗證RPC操作是否成功，然后采取相應的操作。但是如果每次調用RPC都要做各種各樣的異常處理，代碼會不會變得冗長哆嗦？
還有一種處理方法是將操作設計成一種”冪等”操作，就是說，執行多次與執行一次的結果是一樣的，比如說覆蓋寫操作。但是某些客戶操作不方便表示成冪等操作，這時候應該怎么處理呢？