大家好，感謝邀請，今天來為大家分享一下rpc與普通api接口的區(qū)別的問題，以及和為什么rpc比http快的一些困惑，大家要是還不太明白的話，也沒有關(guān)系，因為接下來將為大家分享，希望可以幫助到大家，解決大家的問題，下面就開始吧！

rpc服務(wù)的可用性

RPC（RemoteProcedureCall）是遠(yuǎn)程過程調(diào)用，它是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計算機(jī)程序上請求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。簡單的理解是一個節(jié)點請求另一個節(jié)點提供的服務(wù)

RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)通信模型中，RPC跨越了傳輸層和應(yīng)用層。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。

微服務(wù)架構(gòu)實踐中，服務(wù)是如何通信的

微服務(wù)之間的通信，一般都是借助于微服務(wù)框架完成，一般有REST風(fēng)格的api通信，和微服務(wù)框架結(jié)合的RPC.

所謂的REST風(fēng)格的api通常來講就是HTTP結(jié)合來使用，但是要遵循REST規(guī)范的HTTP有如下特征.

統(tǒng)一接口

無狀態(tài)

緩存

客戶端-服務(wù)器

分層系統(tǒng)

按需代碼（可選）

RPC(RemoteProcedureCall)遠(yuǎn)程過程調(diào)用是一個計算機(jī)通信協(xié)議。我們一般的程序調(diào)用是本地程序內(nèi)部的調(diào)用，RPC允許你像調(diào)用本地函數(shù)一樣去調(diào)用另一個程序的函數(shù)，這中間會涉及網(wǎng)絡(luò)通信和進(jìn)程間通信，但你無需知道實現(xiàn)細(xì)節(jié)，RPC框架為你屏蔽了底層實現(xiàn)。RPC是一種服務(wù)器-客戶端（Client/Server）模式，經(jīng)典實現(xiàn)是一個通過「發(fā)送請求-接受回應(yīng)」進(jìn)行信息交互的系統(tǒng)。

RPC通信通常和微服務(wù)框架結(jié)合，框架會定于消息的序列化格式，比如谷歌的gRPC框架就是利用protobuff序列化，來序列化消息之后通信。

Dubbo

是阿里巴巴公司開源的一個Java高性能優(yōu)秀的服務(wù)框架，使得應(yīng)用可通過高性能的RPC實現(xiàn)服務(wù)的輸出和輸入功能，可以和Spring框架無縫集成。ApacheDubbo|?d?b??|是一款高性能、輕量級的開源JavaRPC框架，它提供了三大核心能力：面向接口的遠(yuǎn)程方法調(diào)用，智能容錯和負(fù)載均衡，以及服務(wù)自動注冊和發(fā)現(xiàn)。2011年末對外開源，僅支持Java語言。

官網(wǎng)：http://dubbo.apache.org/zh-cn/

Dubbo架構(gòu)圖|圖片來源dubbo.apache.org

Tars

騰訊內(nèi)部使用的微服務(wù)架構(gòu)TAF（TotalApplicationFramework）多年的實踐成果總結(jié)而成的開源項目。僅支持C++語言，目前在騰訊內(nèi)部應(yīng)用也非常廣泛。2017年對外開源，僅支持C++語言。

源碼：https://github.com/TarsCloud/Tars/

TARS架構(gòu)圖|來源github.com/TarsCloud

「本命鵝廠TARS框架介紹PPT已下載，不想自己麻煩去找的同學(xué)，在我公眾號「后端技術(shù)學(xué)堂」回復(fù)「tars」獲取?！?/p>

Motan

是新浪微博開源的一個Java框架。Motan在微博平臺中已經(jīng)廣泛應(yīng)用，每天為數(shù)百個服務(wù)完成近千億次的調(diào)用。于2016年對外開源，僅支持Java語言。

官方指南：https://github.com/weibocom/motan/wiki/zh_userguide

Motan框架|圖片來源github.com/weibocom/motan

gRPC

是Google開發(fā)的高性能、通用的開源RPC框架，其由Google主要面向移動應(yīng)用開發(fā)并基于HTTP/2協(xié)議標(biāo)準(zhǔn)而設(shè)計，基于ProtoBuf(ProtocolBuffers)序列化協(xié)議開發(fā)。本身它不是分布式的，所以要實現(xiàn)上面的框架的功能需要進(jìn)一步的開發(fā)。2015年對外開源的跨語言RPC框架，支持多種語言。

中文教程：https://doc.oschina.net/grpc?t=58008

gRPC架構(gòu)圖|圖片來源www.grpc.io

thrift

最初是由Facebook開發(fā)的內(nèi)部系統(tǒng)跨語言的高性能RPC框架，2007年貢獻(xiàn)給了Apache基金，成為Apache開源項目之一，跟gRPC一樣，Thrift也有一套自己的接口定義語言IDL，可以通過代碼生成器，生成各種編程語言的Client端和Server端的SDK代碼，支持多種語言。

thrift架構(gòu)|圖片來源wikimedia

創(chuàng)作不易，看到這里動動手指，點贊「三連」是對我持續(xù)創(chuàng)作的最大支持，我們下篇文章再見！

文章每周持續(xù)更新，可以微信搜索公眾號「后端技術(shù)學(xué)堂」提前看，或在公眾號回復(fù)「資料」有我給你準(zhǔn)備的各種編程學(xué)習(xí)資料，我們下期見！

Windows下進(jìn)程間通訊的幾個比較

1進(jìn)程與進(jìn)程通信

進(jìn)程是裝入內(nèi)存并準(zhǔn)備執(zhí)行的程序，每個進(jìn)程都有私有的虛擬地址空間，由代碼、數(shù)據(jù)以及它可利用的系統(tǒng)資源(如文件、管道等)組成。多進(jìn)程/多線程是Windows操作系統(tǒng)的一個基本特征。MicrosoftWin32應(yīng)用編程接口(ApplicationProgrammingInterface,API)提供了大量支持應(yīng)用程序間數(shù)據(jù)共享和交換的機(jī)制，這些機(jī)制行使的活動稱為進(jìn)程間通信(InterProcessCommunication,IPC)，進(jìn)程通信就是指不同進(jìn)程間進(jìn)行數(shù)據(jù)共享和數(shù)據(jù)交換。

正因為使用Win32API進(jìn)行進(jìn)程通信方式有多種，如何選擇恰當(dāng)?shù)耐ㄐ欧绞骄统蔀閼?yīng)用開發(fā)中的一個重要問題，下面本文將對Win32中進(jìn)程通信的幾種方法加以分析和比較。

2進(jìn)程通信方法

2.1文件映射

文件映射(Memory-MappedFiles)能使進(jìn)程把文件內(nèi)容當(dāng)作進(jìn)程地址區(qū)間一塊內(nèi)存那樣來對待。因此，進(jìn)程不必使用文件I/O操作，只需簡單的指針操作就可讀取和修改文件的內(nèi)容。

Win32API允許多個進(jìn)程訪問同一文件映射對象，各個進(jìn)程在它自己的地址空間里接收內(nèi)存的指針。通過使用這些指針，不同進(jìn)程就可以讀或修改文件的內(nèi)容，實現(xiàn)了對文件中數(shù)據(jù)的共享。

應(yīng)用程序有三種方法來使多個進(jìn)程共享一個文件映射對象。

(1)繼承：第一個進(jìn)程建立文件映射對象，它的子進(jìn)程繼承該對象的句柄。

(2)命名文件映射：第一個進(jìn)程在建立文件映射對象時可以給該對象指定一個名字(可與文件名不同)。第二個進(jìn)程可通過這個名字打開此文件映射對象。另外，第一個進(jìn)程也可以通過一些其它IPC機(jī)制(有名管道、郵件槽等)把名字傳給第二個進(jìn)程。

(3)句柄復(fù)制：第一個進(jìn)程建立文件映射對象，然后通過其它IPC機(jī)制(有名管道、郵件槽等)把對象句柄傳遞給第二個進(jìn)程。第二個進(jìn)程復(fù)制該句柄就取得對該文件映射對象的訪問權(quán)限。

文件映射是在多個進(jìn)程間共享數(shù)據(jù)的非常有效方法，有較好的安全性。但文件映射只能用于本地機(jī)器的進(jìn)程之間，不能用于網(wǎng)絡(luò)中，而開發(fā)者還必須控制進(jìn)程間的同步。

2.2共享內(nèi)存

Win32API中共享內(nèi)存(SharedMemory)實際就是文件映射的一種特殊情況。進(jìn)程在創(chuàng)建文件映射對象時用0xFFFFFFFF來代替文件句柄(HANDLE)，就表示了對應(yīng)的文件映射對象是從操作系統(tǒng)頁面文件訪問內(nèi)存，其它進(jìn)程打開該文件映射對象就可以訪問該內(nèi)存塊。由于共享內(nèi)存是用文件映射實現(xiàn)的，所以它也有較好的安全性，也只能運(yùn)行于同一計算機(jī)上的進(jìn)程之間。

2.3匿名管道

管道(Pipe)是一種具有兩個端點的通信通道：有一端句柄的進(jìn)程可以和有另一端句柄的進(jìn)程通信。管道可以是單向－一端是只讀的，另一端點是只寫的；也可以是雙向的一管道的兩端點既可讀也可寫。

匿名管道(AnonymousPipe)是在父進(jìn)程和子進(jìn)程之間，或同一父進(jìn)程的兩個子進(jìn)程之間傳輸數(shù)據(jù)的無名字的單向管道。通常由父進(jìn)程創(chuàng)建管道，然后由要通信的子進(jìn)程繼承通道的讀端點句柄或?qū)懚它c句柄，然后實現(xiàn)通信。父進(jìn)程還可以建立兩個或更多個繼承匿名管道讀和寫句柄的子進(jìn)程。這些子進(jìn)程可以使用管道直接通信，不需要通過父進(jìn)程。

匿名管道是單機(jī)上實現(xiàn)子進(jìn)程標(biāo)準(zhǔn)I/O重定向的有效方法，它不能在網(wǎng)上使用，也不能用于兩個不相關(guān)的進(jìn)程之間。

2.4命名管道

命名管道(NamedPipe)是服務(wù)器進(jìn)程和一個或多個客戶進(jìn)程之間通信的單向或雙向管道。不同于匿名管道的是命名管道可以在不相關(guān)的進(jìn)程之間和不同計算機(jī)之間使用，服務(wù)器建立命名管道時給它指定一個名字，任何進(jìn)程都可以通過該名字打開管道的另一端，根據(jù)給定的權(quán)限和服務(wù)器進(jìn)程通信。

命名管道提供了相對簡單的編程接口，使通過網(wǎng)絡(luò)傳輸數(shù)據(jù)并不比同一計算機(jī)上兩進(jìn)程之間通信更困難，不過如果要同時和多個進(jìn)程通信它就力不從心了。

2.5郵件槽

郵件槽(Mailslots)提供進(jìn)程間單向通信能力，任何進(jìn)程都能建立郵件槽成為郵件槽服務(wù)器。其它進(jìn)程，稱為郵件槽客戶，可以通過郵件槽的名字給郵件槽服務(wù)器進(jìn)程發(fā)送消息。進(jìn)來的消息一直放在郵件槽中，直到服務(wù)器進(jìn)程讀取它為止。一個進(jìn)程既可以是郵件槽服務(wù)器也可以是郵件槽客戶，因此可建立多個郵件槽實現(xiàn)進(jìn)程間的雙向通信。

通過郵件槽可以給本地計算機(jī)上的郵件槽、其它計算機(jī)上的郵件槽或指定網(wǎng)絡(luò)區(qū)域中所有計算機(jī)上有同樣名字的郵件槽發(fā)送消息。廣播通信的消息長度不能超過400字節(jié)，非廣播消息的長度則受郵件槽服務(wù)器指定的最大消息長度的限制。

郵件槽與命名管道相似，不過它傳輸數(shù)據(jù)是通過不可靠的數(shù)據(jù)報(如TCP/IP協(xié)議中的UDP包)完成的，一旦網(wǎng)絡(luò)發(fā)生錯誤則無法保證消息正確地接收，而命名管道傳輸數(shù)據(jù)則是建立在可靠連接基礎(chǔ)上的。不過郵件槽有簡化的編程接口和給指定網(wǎng)絡(luò)區(qū)域內(nèi)的所有計算機(jī)廣播消息的能力，所以郵件槽不失為應(yīng)用程序發(fā)送和接收消息的另一種選擇。

2.6剪貼板

剪貼板(ClippedBoard)實質(zhì)是Win32API中一組用來傳輸數(shù)據(jù)的函數(shù)和消息，為Windows應(yīng)用程序之間進(jìn)行數(shù)據(jù)共享提供了一個中介，Windows已建立的剪切(復(fù)制)－粘貼的機(jī)制為不同應(yīng)用程序之間共享不同格式數(shù)據(jù)提供了一條捷徑。當(dāng)用戶在應(yīng)用程序中執(zhí)行剪切或復(fù)制操作時，應(yīng)用程序把選取的數(shù)據(jù)用一種或多種格式放在剪貼板上。然后任何其它應(yīng)用程序都可以從剪貼板上拾取數(shù)據(jù)，從給定格式中選擇適合自己的格式。

剪貼板是一個非常松散的交換媒介，可以支持任何數(shù)據(jù)格式，每一格式由一無符號整數(shù)標(biāo)識，對標(biāo)準(zhǔn)(預(yù)定義)剪貼板格式，該值是Win32API定義的常量；對非標(biāo)準(zhǔn)格式可以使用RegisterClipboardFormat函數(shù)注冊為新的剪貼板格式。利用剪貼板進(jìn)行交換的數(shù)據(jù)只需在數(shù)據(jù)格式上一致或都可以轉(zhuǎn)化為某種格式就行。但剪貼板只能在基于Windows的程序中使用，不能在網(wǎng)絡(luò)上使用。

2.7動態(tài)數(shù)據(jù)交換

動態(tài)數(shù)據(jù)交換(DDE)是使用共享內(nèi)存在應(yīng)用程序之間進(jìn)行數(shù)據(jù)交換的一種進(jìn)程間通信形式。應(yīng)用程序可以使用DDE進(jìn)行一次性數(shù)據(jù)傳輸，也可以當(dāng)出現(xiàn)新數(shù)據(jù)時，通過發(fā)送更新值在應(yīng)用程序間動態(tài)交換數(shù)據(jù)。

DDE和剪貼板一樣既支持標(biāo)準(zhǔn)數(shù)據(jù)格式(如文本、位圖等)，又可以支持自己定義的數(shù)據(jù)格式。但它們的數(shù)據(jù)傳輸機(jī)制卻不同，一個明顯區(qū)別是剪貼板操作幾乎總是用作對用戶指定操作的一次性應(yīng)答－如從菜單中選擇Paste命令。盡管DDE也可以由用戶啟動，但它繼續(xù)發(fā)揮作用一般不必用戶進(jìn)一步干預(yù)。DDE有三種數(shù)據(jù)交換方式：

(1)冷鏈：數(shù)據(jù)交換是一次性數(shù)據(jù)傳輸，與剪貼板相同。

(2)溫鏈：當(dāng)數(shù)據(jù)交換時服務(wù)器通知客戶，然后客戶必須請求新的數(shù)據(jù)。

(3)熱鏈：當(dāng)數(shù)據(jù)交換時服務(wù)器自動給客戶發(fā)送數(shù)據(jù)。

DDE交換可以發(fā)生在單機(jī)或網(wǎng)絡(luò)中不同計算機(jī)的應(yīng)用程序之間。開發(fā)者還可以定義定制的DDE數(shù)據(jù)格式進(jìn)行應(yīng)用程序之間特別目的IPC，它們有更緊密耦合的通信要求。大多數(shù)基于Windows的應(yīng)用程序都支持DDE。

2.8對象連接與嵌入

應(yīng)用程序利用對象連接與嵌入(OLE)技術(shù)管理復(fù)合文檔(由多種數(shù)據(jù)格式組成的文檔)，OLE提供使某應(yīng)用程序更容易調(diào)用其它應(yīng)用程序進(jìn)行數(shù)據(jù)編輯的服務(wù)。例如，OLE支持的字處理器可以嵌套電子表格，當(dāng)用戶要編輯電子表格時OLE庫可自動啟動電子表格編輯器。當(dāng)用戶退出電子表格編輯器時，該表格已在原始字處理器文檔中得到更新。在這里電子表格編輯器變成了字處理器的擴(kuò)展，而如果使用DDE，用戶要顯式地啟動電子表格編輯器。

同DDE技術(shù)相同，大多數(shù)基于Windows的應(yīng)用程序都支持OLE技術(shù)。

2.9動態(tài)連接庫

Win32動態(tài)連接庫(DLL)中的全局?jǐn)?shù)據(jù)可以被調(diào)用DLL的所有進(jìn)程共享，這就又給進(jìn)程間通信開辟了一條新的途徑，當(dāng)然訪問時要注意同步問題。

雖然可以通過DLL進(jìn)行進(jìn)程間數(shù)據(jù)共享，但從數(shù)據(jù)安全的角度考慮，我們并不提倡這種方法，使用帶有訪問權(quán)限控制的共享內(nèi)存的方法更好一些。

2.10遠(yuǎn)程過程調(diào)用

Win32API提供的遠(yuǎn)程過程調(diào)用(RPC)使應(yīng)用程序可以使用遠(yuǎn)程調(diào)用函數(shù)，這使在網(wǎng)絡(luò)上用RPC進(jìn)行進(jìn)程通信就像函數(shù)調(diào)用那樣簡單。RPC既可以在單機(jī)不同進(jìn)程間使用也可以在網(wǎng)絡(luò)中使用。

由于Win32API提供的RPC服從OSF-DCE(OpenSoftwareFoundationDistributedComputingEnvironment)標(biāo)準(zhǔn)。所以通過Win32API編寫的RPC應(yīng)用程序能與其它操作系統(tǒng)上支持DEC的RPC應(yīng)用程序通信。使用RPC開發(fā)者可以建立高性能、緊密耦合的分布式應(yīng)用程序。

2.11NetBios函數(shù)

Win32API提供NetBios函數(shù)用于處理低級網(wǎng)絡(luò)控制，這主要是為IBMNetBios系統(tǒng)編寫與Windows的接口。除非那些有特殊低級網(wǎng)絡(luò)功能要求的應(yīng)用程序，其它應(yīng)用程序最好不要使用NetBios函數(shù)來進(jìn)行進(jìn)程間通信。

2.12Sockets

WindowsSockets規(guī)范是以U.C.Berkeley大學(xué)BSDUNIX中流行的Socket接口為范例定義的一套Windows下的網(wǎng)絡(luò)編程接口。除了BerkeleySocket原有的庫函數(shù)以外，還擴(kuò)展了一組針對Windows的函數(shù)，使程序員可以充分利用Windows的消息機(jī)制進(jìn)行編程。

現(xiàn)在通過Sockets實現(xiàn)進(jìn)程通信的網(wǎng)絡(luò)應(yīng)用越來越多，這主要的原因是Sockets的跨平臺性要比其它IPC機(jī)制好得多，另外WinSock2.0不僅支持TCP/IP協(xié)議，而且還支持其它協(xié)議(如IPX)。Sockets的唯一缺點是它支持的是底層通信操作，這使得在單機(jī)的進(jìn)程間進(jìn)行簡單數(shù)據(jù)傳遞不太方便，這時使用下面將介紹的WM_COPYDATA消息將更合適些。

2.13WM_COPYDATA消息

WM_COPYDATA是一種非常強(qiáng)大卻鮮為人知的消息。當(dāng)一個應(yīng)用向另一個應(yīng)用傳送數(shù)據(jù)時，發(fā)送方只需使用調(diào)用SendMessage函數(shù)，參數(shù)是目的窗口的句柄、傳遞數(shù)據(jù)的起始地址、WM_COPYDATA消息。接收方只需像處理其它消息那樣處理WM_COPYDATA消息，這樣收發(fā)雙方就實現(xiàn)了數(shù)據(jù)共享。

WM_COPYDATA是一種非常簡單的方法，它在底層實際上是通過文件映射來實現(xiàn)的。它的缺點是靈活性不高，并且它只能用于Windows平臺的單機(jī)環(huán)境下。

rpc是什么意思

RPC是指遠(yuǎn)程過程調(diào)用（RemoteProcedureCall），是一種計算機(jī)網(wǎng)絡(luò)技術(shù)，用于實現(xiàn)分布式系統(tǒng)中不同計算機(jī)上的進(jìn)程之間的通信與調(diào)用。

通過RPC，客戶端可以請求遠(yuǎn)程服務(wù)器上的一個指定的函數(shù)或方法，并等待結(jié)果返回，使用起來非常方便。它適用于各種類型的應(yīng)用程序，包括在線游戲、電子商務(wù)和金融系統(tǒng)等。RPC最早由SunMicrosystems開發(fā)，現(xiàn)在已經(jīng)成為了大量分布式應(yīng)用程序的基礎(chǔ)。它可以充分利用網(wǎng)絡(luò)資源，提高應(yīng)用程序的性能和可擴(kuò)展性，是計算機(jī)網(wǎng)絡(luò)領(lǐng)域中的一項重要技術(shù)。

rpc原理及實現(xiàn)

RPC（RemoteProcedureCall，遠(yuǎn)程過程調(diào)用）是一種通過網(wǎng)絡(luò)在不同計算機(jī)之間調(diào)用函數(shù)或方法的技術(shù)。它允許一個程序通過網(wǎng)絡(luò)調(diào)用另一個程序中的函數(shù)或方法，就像調(diào)用本地函數(shù)一樣。

RPC的原理如下：

定義接口：定義遠(yuǎn)程過程接口，包括函數(shù)名、參數(shù)和返回值等信息。

實現(xiàn)接口：在本地計算機(jī)上實現(xiàn)遠(yuǎn)程過程接口，并將其編譯為二進(jìn)制格式。

服務(wù)器端：將遠(yuǎn)程過程接口發(fā)布到網(wǎng)絡(luò)上，以便其他計算機(jī)可以調(diào)用它。

客戶端：通過網(wǎng)絡(luò)調(diào)用遠(yuǎn)程過程接口。客戶端需要知道遠(yuǎn)程過程接口的地址和端口號，以及函數(shù)名和參數(shù)等信息。

實現(xiàn)調(diào)用：客戶端通過網(wǎng)絡(luò)將調(diào)用請求發(fā)送給服務(wù)器端，服務(wù)器端接收請求并執(zhí)行遠(yuǎn)程過程，然后將結(jié)果返回給客戶端。

RPC的實現(xiàn)方式有很多種，常見的包括：

基于HTTP的RPC：通過HTTP協(xié)議傳輸RPC請求和響應(yīng)。例如，RESTfulAPI就是一種基于HTTP的RPC實現(xiàn)方式。

基于TCP的RPC：通過TCP協(xié)議傳輸RPC請求和響應(yīng)。例如，gRPC就是一個基于TCP的RPC框架。

基于UDP的RPC：通過UDP協(xié)議傳輸RPC請求和響應(yīng)。例如，Ice和Nanomsg都是基于UDP的RPC實現(xiàn)方式。

基于WebSocket的RPC：通過WebSocket協(xié)議傳輸RPC請求和響應(yīng)。例如，WebSocketRPC就是一種基于WebSocket的RPC實現(xiàn)方式。

基于其他協(xié)議的RPC：除了上述常見的協(xié)議外，還有一些其他的協(xié)議可以用于實現(xiàn)RPC，例如，F(xiàn)TP、SMTP等。

總之，RPC的原理是通過網(wǎng)絡(luò)在不同計算機(jī)之間調(diào)用函數(shù)或方法，實現(xiàn)方式有很多種，常見的包括基于HTTP、TCP、UDP、WebSocket等協(xié)議的RPC。

OK，關(guān)于rpc與普通api接口的區(qū)別和為什么rpc比http快的內(nèi)容到此結(jié)束了，希望對大家有所幫助。