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

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

不是的， 你裝的操作系統(tǒng)進(jìn)程間通信大量的大用rpc技術(shù)，因?yàn)楫?dāng)軟件復(fù)雜到一定程度時(shí)需要通過(guò)模塊化解耦，便于分別升級(jí)維護(hù)，便于團(tuán)隊(duì)開(kāi)發(fā)。

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

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

rpc是否可以跨語(yǔ)言？

當(dāng)然沒(méi)問(wèn)題，跨平臺(tái)跨語(yǔ)言的早就發(fā)明出來(lái)了。但如果用同一種語(yǔ)言的序列化方式，顯然會(huì)更方便也效率更高，成本更低，前提是你沒(méi)有跨語(yǔ)言的要求。

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

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

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

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

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

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

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

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

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