rpc与普通api接口的区别？为什么rpc比http快

大家好，感谢邀请，今天来为大家分享一下rpc与普通api接口的区别的问题，以及和为什么rpc比http快的一些困惑，大家要是还不太明白的话，也没有关系，因为接下来将为大家分享，希望可以帮助到大家，解决大家的问题，下面就开始吧！

rpc服务的可用性

RPC（RemoteProcedureCall）是远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。简单的理解是一个节点请求另一个节点提供的服务

RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

微服务架构实践中，服务是如何通信的

微服务之间的通信，一般都是借助于微服务框架完成，一般有REST风格的api通信，和微服务框架结合的RPC.

所谓的REST风格的api通常来讲就是HTTP结合来使用，但是要遵循REST规范的HTTP有如下特征.

统一接口

无状态

缓存

客户端-服务器

分层系统

按需代码（可选）

RPC(RemoteProcedureCall)远程过程调用是一个计算机通信协议。我们一般的程序调用是本地程序内部的调用，RPC允许你像调用本地函数一样去调用另一个程序的函数，这中间会涉及网络通信和进程间通信，但你无需知道实现细节，RPC框架为你屏蔽了底层实现。RPC是一种服务器-客户端（Client/Server）模式，经典实现是一个通过「发送请求-接受回应」进行信息交互的系统。

RPC通信通常和微服务框架结合，框架会定于消息的序列化格式，比如谷歌的gRPC框架就是利用protobuff序列化，来序列化消息之后通信。

Dubbo

是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。ApacheDubbo|?d?b??|是一款高性能、轻量级的开源JavaRPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。2011年末对外开源，仅支持Java语言。

官网：http://dubbo.apache.org/zh-cn/

Dubbo架构图|图片来源dubbo.apache.org

Tars

腾讯内部使用的微服务架构TAF（TotalApplicationFramework）多年的实践成果总结而成的开源项目。仅支持C++语言，目前在腾讯内部应用也非常广泛。2017年对外开源，仅支持C++语言。

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

TARS架构图|来源github.com/TarsCloud

「本命鹅厂TARS框架介绍PPT已下载，不想自己麻烦去找的同学，在我公众号「后端技术学堂」回复「tars」获取。」

Motan

是新浪微博开源的一个Java框架。Motan在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用。于2016年对外开源，仅支持Java语言。

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

Motan框架|图片来源github.com/weibocom/motan

gRPC

是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(ProtocolBuffers)序列化协议开发。本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。2015年对外开源的跨语言RPC框架，支持多种语言。

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

gRPC架构图|图片来源www.grpc.io

thrift

最初是由Facebook开发的内部系统跨语言的高性能RPC框架，2007年贡献给了Apache基金，成为Apache开源项目之一，跟gRPC一样，Thrift也有一套自己的接口定义语言IDL，可以通过代码生成器，生成各种编程语言的Client端和Server端的SDK代码，支持多种语言。

thrift架构|图片来源wikimedia

创作不易，看到这里动动手指，点赞「三连」是对我持续创作的最大支持，我们下篇文章再见！

文章每周持续更新，可以微信搜索公众号「后端技术学堂」提前看，或在公众号回复「资料」有我给你准备的各种编程学习资料，我们下期见！

Windows下进程间通讯的几个比较

1进程与进程通信

进程是装入内存并准备执行的程序，每个进程都有私有的虚拟地址空间，由代码、数据以及它可利用的系统资源(如文件、管道等)组成。多进程/多线程是Windows操作系统的一个基本特征。MicrosoftWin32应用编程接口(ApplicationProgrammingInterface,API)提供了大量支持应用程序间数据共享和交换的机制，这些机制行使的活动称为进程间通信(InterProcessCommunication,IPC)，进程通信就是指不同进程间进行数据共享和数据交换。

正因为使用Win32API进行进程通信方式有多种，如何选择恰当的通信方式就成为应用开发中的一个重要问题，下面本文将对Win32中进程通信的几种方法加以分析和比较。

2进程通信方法

2.1文件映射

文件映射(Memory-MappedFiles)能使进程把文件内容当作进程地址区间一块内存那样来对待。因此，进程不必使用文件I/O操作，只需简单的指针操作就可读取和修改文件的内容。

Win32API允许多个进程访问同一文件映射对象，各个进程在它自己的地址空间里接收内存的指针。通过使用这些指针，不同进程就可以读或修改文件的内容，实现了对文件中数据的共享。

应用程序有三种方法来使多个进程共享一个文件映射对象。

(1)继承：第一个进程建立文件映射对象，它的子进程继承该对象的句柄。

(2)命名文件映射：第一个进程在建立文件映射对象时可以给该对象指定一个名字(可与文件名不同)。第二个进程可通过这个名字打开此文件映射对象。另外，第一个进程也可以通过一些其它IPC机制(有名管道、邮件槽等)把名字传给第二个进程。

(3)句柄复制：第一个进程建立文件映射对象，然后通过其它IPC机制(有名管道、邮件槽等)把对象句柄传递给第二个进程。第二个进程复制该句柄就取得对该文件映射对象的访问权限。

文件映射是在多个进程间共享数据的非常有效方法，有较好的安全性。但文件映射只能用于本地机器的进程之间，不能用于网络中，而开发者还必须控制进程间的同步。

2.2共享内存

Win32API中共享内存(SharedMemory)实际就是文件映射的一种特殊情况。进程在创建文件映射对象时用0xFFFFFFFF来代替文件句柄(HANDLE)，就表示了对应的文件映射对象是从操作系统页面文件访问内存，其它进程打开该文件映射对象就可以访问该内存块。由于共享内存是用文件映射实现的，所以它也有较好的安全性，也只能运行于同一计算机上的进程之间。

2.3匿名管道

管道(Pipe)是一种具有两个端点的通信通道：有一端句柄的进程可以和有另一端句柄的进程通信。管道可以是单向－一端是只读的，另一端点是只写的；也可以是双向的一管道的两端点既可读也可写。

匿名管道(AnonymousPipe)是在父进程和子进程之间，或同一父进程的两个子进程之间传输数据的无名字的单向管道。通常由父进程创建管道，然后由要通信的子进程继承通道的读端点句柄或写端点句柄，然后实现通信。父进程还可以建立两个或更多个继承匿名管道读和写句柄的子进程。这些子进程可以使用管道直接通信，不需要通过父进程。

匿名管道是单机上实现子进程标准I/O重定向的有效方法，它不能在网上使用，也不能用于两个不相关的进程之间。

2.4命名管道

命名管道(NamedPipe)是服务器进程和一个或多个客户进程之间通信的单向或双向管道。不同于匿名管道的是命名管道可以在不相关的进程之间和不同计算机之间使用，服务器建立命名管道时给它指定一个名字，任何进程都可以通过该名字打开管道的另一端，根据给定的权限和服务器进程通信。

命名管道提供了相对简单的编程接口，使通过网络传输数据并不比同一计算机上两进程之间通信更困难，不过如果要同时和多个进程通信它就力不从心了。

2.5邮件槽

邮件槽(Mailslots)提供进程间单向通信能力，任何进程都能建立邮件槽成为邮件槽服务器。其它进程，称为邮件槽客户，可以通过邮件槽的名字给邮件槽服务器进程发送消息。进来的消息一直放在邮件槽中，直到服务器进程读取它为止。一个进程既可以是邮件槽服务器也可以是邮件槽客户，因此可建立多个邮件槽实现进程间的双向通信。

通过邮件槽可以给本地计算机上的邮件槽、其它计算机上的邮件槽或指定网络区域中所有计算机上有同样名字的邮件槽发送消息。广播通信的消息长度不能超过400字节，非广播消息的长度则受邮件槽服务器指定的最大消息长度的限制。

邮件槽与命名管道相似，不过它传输数据是通过不可靠的数据报(如TCP/IP协议中的UDP包)完成的，一旦网络发生错误则无法保证消息正确地接收，而命名管道传输数据则是建立在可靠连接基础上的。不过邮件槽有简化的编程接口和给指定网络区域内的所有计算机广播消息的能力，所以邮件槽不失为应用程序发送和接收消息的另一种选择。

2.6剪贴板

剪贴板(ClippedBoard)实质是Win32API中一组用来传输数据的函数和消息，为Windows应用程序之间进行数据共享提供了一个中介，Windows已建立的剪切(复制)－粘贴的机制为不同应用程序之间共享不同格式数据提供了一条捷径。当用户在应用程序中执行剪切或复制操作时，应用程序把选取的数据用一种或多种格式放在剪贴板上。然后任何其它应用程序都可以从剪贴板上拾取数据，从给定格式中选择适合自己的格式。

剪贴板是一个非常松散的交换媒介，可以支持任何数据格式，每一格式由一无符号整数标识，对标准(预定义)剪贴板格式，该值是Win32API定义的常量；对非标准格式可以使用RegisterClipboardFormat函数注册为新的剪贴板格式。利用剪贴板进行交换的数据只需在数据格式上一致或都可以转化为某种格式就行。但剪贴板只能在基于Windows的程序中使用，不能在网络上使用。

2.7动态数据交换

动态数据交换(DDE)是使用共享内存在应用程序之间进行数据交换的一种进程间通信形式。应用程序可以使用DDE进行一次性数据传输，也可以当出现新数据时，通过发送更新值在应用程序间动态交换数据。

DDE和剪贴板一样既支持标准数据格式(如文本、位图等)，又可以支持自己定义的数据格式。但它们的数据传输机制却不同，一个明显区别是剪贴板操作几乎总是用作对用户指定操作的一次性应答－如从菜单中选择Paste命令。尽管DDE也可以由用户启动，但它继续发挥作用一般不必用户进一步干预。DDE有三种数据交换方式：

(1)冷链：数据交换是一次性数据传输，与剪贴板相同。

(2)温链：当数据交换时服务器通知客户，然后客户必须请求新的数据。

(3)热链：当数据交换时服务器自动给客户发送数据。

DDE交换可以发生在单机或网络中不同计算机的应用程序之间。开发者还可以定义定制的DDE数据格式进行应用程序之间特别目的IPC，它们有更紧密耦合的通信要求。大多数基于Windows的应用程序都支持DDE。

2.8对象连接与嵌入

应用程序利用对象连接与嵌入(OLE)技术管理复合文档(由多种数据格式组成的文档)，OLE提供使某应用程序更容易调用其它应用程序进行数据编辑的服务。例如，OLE支持的字处理器可以嵌套电子表格，当用户要编辑电子表格时OLE库可自动启动电子表格编辑器。当用户退出电子表格编辑器时，该表格已在原始字处理器文档中得到更新。在这里电子表格编辑器变成了字处理器的扩展，而如果使用DDE，用户要显式地启动电子表格编辑器。

同DDE技术相同，大多数基于Windows的应用程序都支持OLE技术。

2.9动态连接库

Win32动态连接库(DLL)中的全局数据可以被调用DLL的所有进程共享，这就又给进程间通信开辟了一条新的途径，当然访问时要注意同步问题。

虽然可以通过DLL进行进程间数据共享，但从数据安全的角度考虑，我们并不提倡这种方法，使用带有访问权限控制的共享内存的方法更好一些。

2.10远程过程调用

Win32API提供的远程过程调用(RPC)使应用程序可以使用远程调用函数，这使在网络上用RPC进行进程通信就像函数调用那样简单。RPC既可以在单机不同进程间使用也可以在网络中使用。

由于Win32API提供的RPC服从OSF-DCE(OpenSoftwareFoundationDistributedComputingEnvironment)标准。所以通过Win32API编写的RPC应用程序能与其它操作系统上支持DEC的RPC应用程序通信。使用RPC开发者可以建立高性能、紧密耦合的分布式应用程序。

2.11NetBios函数

Win32API提供NetBios函数用于处理低级网络控制，这主要是为IBMNetBios系统编写与Windows的接口。除非那些有特殊低级网络功能要求的应用程序，其它应用程序最好不要使用NetBios函数来进行进程间通信。

2.12Sockets

WindowsSockets规范是以U.C.Berkeley大学BSDUNIX中流行的Socket接口为范例定义的一套Windows下的网络编程接口。除了BerkeleySocket原有的库函数以外，还扩展了一组针对Windows的函数，使程序员可以充分利用Windows的消息机制进行编程。

现在通过Sockets实现进程通信的网络应用越来越多，这主要的原因是Sockets的跨平台性要比其它IPC机制好得多，另外WinSock2.0不仅支持TCP/IP协议，而且还支持其它协议(如IPX)。Sockets的唯一缺点是它支持的是底层通信操作，这使得在单机的进程间进行简单数据传递不太方便，这时使用下面将介绍的WM_COPYDATA消息将更合适些。

2.13WM_COPYDATA消息

WM_COPYDATA是一种非常强大却鲜为人知的消息。当一个应用向另一个应用传送数据时，发送方只需使用调用SendMessage函数，参数是目的窗口的句柄、传递数据的起始地址、WM_COPYDATA消息。接收方只需像处理其它消息那样处理WM_COPYDATA消息，这样收发双方就实现了数据共享。

WM_COPYDATA是一种非常简单的方法，它在底层实际上是通过文件映射来实现的。它的缺点是灵活性不高，并且它只能用于Windows平台的单机环境下。

rpc是什么意思

RPC是指远程过程调用（RemoteProcedureCall），是一种计算机网络技术，用于实现分布式系统中不同计算机上的进程之间的通信与调用。

通过RPC，客户端可以请求远程服务器上的一个指定的函数或方法，并等待结果返回，使用起来非常方便。它适用于各种类型的应用程序，包括在线游戏、电子商务和金融系统等。RPC最早由SunMicrosystems开发，现在已经成为了大量分布式应用程序的基础。它可以充分利用网络资源，提高应用程序的性能和可扩展性，是计算机网络领域中的一项重要技术。

rpc原理及实现

RPC（RemoteProcedureCall，远程过程调用）是一种通过网络在不同计算机之间调用函数或方法的技术。它允许一个程序通过网络调用另一个程序中的函数或方法，就像调用本地函数一样。

RPC的原理如下：

定义接口：定义远程过程接口，包括函数名、参数和返回值等信息。

实现接口：在本地计算机上实现远程过程接口，并将其编译为二进制格式。

服务器端：将远程过程接口发布到网络上，以便其他计算机可以调用它。

客户端：通过网络调用远程过程接口。客户端需要知道远程过程接口的地址和端口号，以及函数名和参数等信息。

实现调用：客户端通过网络将调用请求发送给服务器端，服务器端接收请求并执行远程过程，然后将结果返回给客户端。

RPC的实现方式有很多种，常见的包括：

基于HTTP的RPC：通过HTTP协议传输RPC请求和响应。例如，RESTfulAPI就是一种基于HTTP的RPC实现方式。

基于TCP的RPC：通过TCP协议传输RPC请求和响应。例如，gRPC就是一个基于TCP的RPC框架。

基于UDP的RPC：通过UDP协议传输RPC请求和响应。例如，Ice和Nanomsg都是基于UDP的RPC实现方式。

基于WebSocket的RPC：通过WebSocket协议传输RPC请求和响应。例如，WebSocketRPC就是一种基于WebSocket的RPC实现方式。

基于其他协议的RPC：除了上述常见的协议外，还有一些其他的协议可以用于实现RPC，例如，FTP、SMTP等。

总之，RPC的原理是通过网络在不同计算机之间调用函数或方法，实现方式有很多种，常见的包括基于HTTP、TCP、UDP、WebSocket等协议的RPC。

OK，关于rpc与普通api接口的区别和为什么rpc比http快的内容到此结束了，希望对大家有所帮助。