RPC（Remote Procedure Call Protocol）遠程過程調用協議。一個通俗的描述是：客戶端在不知道調用細節的情況下，調用存在于遠程計算機上的某個對象，就像調用本地應用程序中的對象一樣。
比較正式的描述是：一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。
那么我們至少從這樣的描述中挖掘出幾個要點：
- RPC是協議：既然是協議就只是一套規范，那么就需要有人遵循這套規范來進行實現。目前典型的RPC實現包括：Dubbo、Thrift、GRPC、Hetty等。這里要說明一下，目前技術的發展趨勢來看，實現了RPC協議的應用工具往往都會附加其他重要功能。
- 網絡協議和網絡IO模型對其透明：既然RPC的客戶端認為自己是在調用本地對象。那么傳輸層使用的是TCP/UDP還是HTTP協議，又或者是一些其他的網絡協議它就不需要關心了。既然網絡協議對其透明，那么調用過程中，使用的是哪一種網絡IO模型調用者也不需要關心。
- 信息格式對其透明：我們知道在本地應用程序中，對于某個對象的調用需要傳遞一些參數，并且會返回一個調用結果。至于被調用的對象內部是如何使用這些參數，并計算出處理結果的，調用方是不需要關心的。那么對于遠程調用來說，這些參數會以某種信息格式傳遞給網絡上的另外一臺計算機，這個信息格式是怎樣構成的，調用方是不需要關心的。
- 應該有跨語言能力：為什么這樣說呢？因為調用方實際上也不清楚遠程服務器的應用程序是使用什么語言運行的。那么對于調用方來說，無論服務器方使用的是什么語言，本次調用都應該成功，并且返回值也應該按照調用方程序語言所能理解的形式進行描述。
為什么要用RPC
其實這是應用開發到一定的階段的強烈需求驅動的。
- 如果我們開發簡單的單一應用，邏輯簡單、用戶不多、流量不大，那我們用不著；
- 當我們的系統訪問量增大、業務增多時，我們會發現一臺單機運行此系統已經無法承受。此時，我們可以將業務拆分成幾個互不關聯的應用，分別部署在各自機器上，以劃清邏輯并減小壓力。此時，我們也可以不需要RPC，因為應用之間是互不關聯的。
- 當我們的業務越來越多、應用也越來越多時，自然的，我們會發現有些功能已經不能簡單劃分開來或者劃分不出來。此時，可以將公共業務邏輯抽離出來，將之組成獨立的服務Service應用 。而原有的、新增的應用都可以與那些獨立的Service應用 交互，以此來完成完整的業務功能。所以此時，我們急需一種高效的應用程序之間的通訊手段來完成這種需求，所以你看，RPC大顯身手的時候來了！其實3描述的場景也是服務化 、微服務 和分布式系統架構 的基礎場景。即RPC框架就是實現以上結構的有力方式。
常用的RPC框架
目前常用的RPC框架如下：
- Thrift：thrift是一個軟件框架，用來進行可擴展且跨語言的服務的開發。它結合了功能強大的軟件堆棧和代碼生成引擎，以構建在 C++, JAVA, Python, php, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 這些編程語言間無縫結合的、高效的服務。
- Dubbo：Dubbo是一個分布式服務框架，以及SOA治理方案。其功能主要包括：高性能NIO通訊及多協議集成，服務動態尋址與路由，軟負載均衡與容錯，依賴分析與降級等。Dubbo是阿里巴巴內部的SOA服務化治理方案的核心框架，Dubbo自2011年開源后，已被許多非阿里系公司使用。
- Spring Cloud：Spring Cloud由眾多子項目組成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系統及微服務常用的工具，如配置管理、服務發現、斷路器、智能路由、微代理、控制總線、一次性token、全局鎖、選主、分布式會話和集群狀態等，滿足了構建微服務所需的所有解決方案。Spring Cloud基于Spring Boot, 使得開發部署極其簡單。
- gRPC：一開始由 google 開發，是一款語言中立、平臺中立、開源的遠程過程調用(RPC)系統。
