rpc服務(wù)器是不是一般是服務(wù)器內(nèi)部交互用的，這樣有什么好處？

是不是我只有一臺服務(wù)器就沒有必要用rpc?

不是的， 你裝的操作系統(tǒng)進程間通信大量的大用rpc技術(shù)，因為當軟件復(fù)雜到一定程度時需要通過模塊化解耦，便于分別升級維護，便于團隊開發(fā)。

rpc是不是要可以用于遠程的客戶端服務(wù)器通信？

可以的，http-rpc了解下。處理好現(xiàn)在的微服務(wù)也是類似的概念，需要做的是處理好安全，和流量管理的問題，這些都有現(xiàn)成的方案。問題是哪種技術(shù)更適合。

rpc是否可以跨語言？

當然沒問題，跨平臺跨語言的早就發(fā)明出來了。但如果用同一種語言的序列化方式，顯然會更方便也效率更高，成本更低，前提是你沒有跨語言的要求。

RPC從概念上講，不是一種協(xié)議，也不屬于通信的范疇；
而是一種編程技術(shù)，一種代碼封裝方式，目的是提高代碼構(gòu)建和維護效率。

RPC（Remote Procedure Call）把進程間（包括跨服務(wù)器）的通信過程封裝成函數(shù)調(diào)用方式，隱藏復(fù)雜的通信處理細節(jié)，方便使用、簡化代碼；使得調(diào)用者可以像調(diào)用本地函數(shù)那樣調(diào)用其他進程提供的處理過程。

一旦我們把RPC理解為一種代碼封裝技術(shù)，就很容易理解為啥看上去“內(nèi)網(wǎng)用的多”，“客戶端用的少”。
內(nèi)網(wǎng)并不是關(guān)鍵。
關(guān)鍵是RPC在簡化代碼的同時增加了耦合。
如果我們定義兩個實體之間通過HTTP通信（或其他任何協(xié)議），只要雙方遵循HTTP協(xié)議，就沒有問題，和雙方的語言實現(xiàn)沒有任何關(guān)系。
而如果是RPC，那么我們對外部呈現(xiàn)的是函數(shù)接口，這就和語言以及平臺相關(guān)，需要給調(diào)用者提供函數(shù)聲明文件和鏈接庫。

當我們的場景耦合成本比較高時，例如我們構(gòu)建的服務(wù)是提供給團隊之外甚至是公司之外的用戶使用，用RPC就比直接用HTTP麻煩多了——
我們需要提供各種版本，以支持用戶的各種平臺和語言。
即使采用支持多語言的RPC框架，那么這個框架（本質(zhì)是一個代碼庫）也要雙方都引用和依賴，這和直接采用協(xié)議比起來耦合要重的多。

顯然題主所看到的“服務(wù)器內(nèi)網(wǎng)交互用的多“，并不是本質(zhì)，本質(zhì)是：
同一個系統(tǒng)內(nèi)部交互，因為可以采用相同的基礎(chǔ)平臺（或框架），所以可以考慮使用RPC封裝通信過程，以提高代碼構(gòu)建和維護效率，而恰恰系統(tǒng)內(nèi)部交互大都是走內(nèi)網(wǎng)。。。

RPC是點對點之間通信用的一種協(xié)議，這種點對點不僅僅是指服務(wù)器和服務(wù)器之間，你所說的客戶端與服務(wù)器之間的通信，廣義上來說也可以是RPC（遠程過程調(diào)用/遠程方法調(diào)用）。

RPC的方式有很多，常見的各種原始xxxRPC/SOAP/REST/Thrift/gRPC/ProtoBuf等等，根據(jù)使用場景的不同可以劃分為以下幾類：

1. 為業(yè)務(wù)解耦的需要；
2. 為跨語言或者跨平臺的需要；
3. 為服務(wù)化、集群化、負載均衡及可伸縮性的需要；

不同的使用場景，對于RPC的選型和架構(gòu)設(shè)計也不太一樣。