rpc是哪个国家，prc？
引言
即时通讯网官方技术群和社区里，经常有开发者在纠结怎么开发IM集群，虽然真正的使用人数，可能用个人电脑单机都能支撑。
你也许会说，明明不需要用到IM集群，干吗要自找麻烦？答曰：“老板说这个得有！”、“万一产品做成了，用户量达到百万、千万级呢？”，各种回答，反此种种。总之，IM集群就是得整一个（先甭管用不用的上…）。
当然，玩笑归玩笑，真正要做到可投入到生产级别的IM集群系统，难度还是相当大的。必竟IM这种长连接应用相比传统Http这种短连接应用太不标准。
我们以一个典型的IM聊天消息传输为例：
假设存在两个正在聊天的用户（用户A和用户B），当A连接的是IM集群中的IM实例1、B连接的是IM集群中的IM实例2，此时当用户A向用户B发送一条聊天消息时，这条消息应该如何传递呢？
我们梳理一下上面这个例子的消息流转过程：
1）IM聊天消息首先会由用户A发往IM实例1；2）IM实例1会将此条消息转交给IM实例2；3）IM实例2会将此条消息最终投递给连接在本实例上的用户B。
如上述流程所示，这就是一个IM集群系统中典型的聊天消息投递过程。
那么，这其中涉及到一个关键步骤：即第2）步中如何实现“IM实例1会将此条消息转交给IM实例2”？
此时，RPC技术出场了！
▲ 上图是个典型的分布式IM架构，注意中间的“RPC通信”字样（本图引用自《基于Go的马蜂窝旅游网分布式IM系统技术实践》）
本文将以通俗易懂的白话形式，帮你快速理解IM集群中的关键技术——RPC。
正文概述
限于篇幅原因，本文不会深入展开RPC的底层技术原理，会尽量用通俗白话的方式对概念性的东西进行讲解。
通过本文你将主要了解到以下内容：
1）什么是RPC；2）为什么需要RPC；3）RPC的重要组件；4）常见RPC框架和各自特点。
什么是RPC？
RPC 是1984年代由 Andrew D. Birrell & Bruce Jay Nelson 提出的（见二位大佬的论文《Implementing Remote Procedure Calls》），所以它并不是最近才有的技术概念。
关于RPC的介绍，正经的资料上大概是这样介绍的：
RPC（Remote Procedure Call）远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。
大白话理解RPC就是：RPC让你用别人家的东西就像自己家的一样。
看得我似懂非懂，于是我不得不问几个问题：
1）为啥要用别人家的东西——请求其他服务)；2）我怎么可以借到别人家的东西——其他服务调用；3）要是借用的话哪种形式更好——确定一个合适的调用方法）；4）怎么让我用别人东西像自己的一样——屏蔽底层细节透明通信）。
在解答这些问题之前，我们必须达到一个共识问题：RPC只是一种通信模式，和http并不冲突对立，相反http可以作为RPC传输数据的一种协议，把RPC当作一种模式和思想，我们才能更好地理解它。
更严谨的RPC基础知识介绍，请阅读：《即时通讯新手入门：快速理解RPC技术——基本概念、原理和用途》。
为什么需要RPC？
以大家最熟悉的电商系统为例，这样规模的分布式系统，需要拆分出用户服务、商品服务、优惠券服务、支付服务、订单服务、物流服务、售后服务等等。这些服务之间都相互调用，这时内部调用最好使用 RPC ，同时每个服务都可以独立部署，独立上线。
也就说当我们的项目太大，需要解耦服务，扩展性强、部署灵活，这时就要用到 RPC ，这主要是解决了分布式系统中，服务与服务之间的调用问题。
▲ 上图中的分布系统内部，就是用RPC实现的（本图引用自《从新手到架构师，一篇就够：从100到1000万高并发的架构演进之路》）
对于IM集群这样的分布式系统来说，不同IM实例间的用户聊天消息，就是通过RPC进行流转的。
为什么不直接使用HTTP，而要搞RPC？
在日常业务中我们可以把功能封装成静态库、动态库、sdk、独立服务等，最常见也最方便的还是HTTP这种形式的调用。
HTTP服务把需要提供的服务暴露成接口（也就是通常所说的http rest接口啦），使用方直接按约定的HTTP方法和URI进行数据交互。
我们都知道HTTP协议是应用层协议，是个非常标准的协议，在HTTP协议之下还有网络层、传输层、数据链路层等，一个数据包packet除了净荷payload之外还有很多header，由于标准和通用性的设计目标也使得HTTP一次数据交互真正传输的payload只是其中一部分。
HTTP是我们用的最多最熟悉的交互模式，在系统内部各个服务之间接口较少，交互不多的情况下工作得还不错。
但如果在内部系统调用很复杂的前提下，HTTP调用的效率和安全性就不那么理想了。
以IM系统为例，单个IM实例的吞吐效率至少可以达到几万甚至数十万QPS，使用HTTP这种短连接（调用时建立socket连接，完成后释放连接）方式显的相当低效（每次调用都要重新经历TCP的3次握手、4次挥手过程），在分布式的情况下势必拉低整个IM集群的吞吐效率。而对于RPC，这种socket长连接方式对于高性能场景来说，效果是显而易见的。
更重要的是面对众多的服务我们需要的不仅仅是一个通信方式，而是一个内部服务的管理系统，这也就是我们今天说的RPC框架。注意：RPC是一种模式策略和框架，并不是单纯的通信协议。
题外话：实际上，HTTP在RPC系统中，并不是个你死我活的关系，必竟HTTP只是个通信协议，而HTTP有某些性能要求不敏感的场景来说，是完全可以作为RPC的具体实现协议之一来使用的。
RPC的调用过程是什么样的？
▲ 典型的RPC调用过程
如上图所示，一个典型的RPC调用过程是这样（过程序号对应上图中的数字）：
1）客户端（client）以本地调用方式调用服务；2）客户端存根（client stub）接收到调用后，负责将方法、参数等组装成能够进行网络传输的消息体（将消息体对象序列化为二进制）；3）客户端通过 sockets 将消息发送到服务端；4）服务端存根（server stub）收到消息后进行解码（将消息对象反序列化）；5）服务端存根（server stub）根据解码结果调用本地的服务；6）本地服务执行并将结果返回给服务端存根（server stub）；7）服务端存根（server stub）将返回结果打包成消息（将结果消息对象序列化）；8）服务端（server）通过 sockets 将消息发送到客户端；9）客户端存根（client stub）接收到结果消息，并进行解码（将结果消息发序列化）；10）客户端（client）得到最终结果。
RPC的作用，其实就是要把上述2、3、4、7、8、9 这些步骤都封装起来。是不是很神奇？
关于HTTP和RPC的一些争议
HTTP和RPC是两个很容易混淆的概念，对于刚开始接触RPC的人来说，通常都会困惑：有HTTP了为什么还要用RPC？
在知乎上看到了这个很有趣的问题：《既然有http请求，为什么还要用rpc?》
其中一个大佬的回答感觉很有意思：
换个角度来说：HTTP 与 RPC 的关系就好比普通话与方言的关系。要进行跨企业服务调用时，往往都是通过 HTTP API，也就是普通话，虽然效率不高，但是通用，没有太多沟通的学习成本。但是在企业内部还是 RPC 更加高效，同一个企业公用一套方言进行高效率的交流，要比通用的 HTTP 协议来交流更加节省资源。整个中国有非常多的方言，正如有很多的企业内部服务各有自己的一套交互协议一样。虽然国家一直在提倡使用普通话交流，但是这么多年过去了，你回一趟家乡探个亲什么的就会发现身边的人还是流行说方言。
如果再深入一点说，普通话本质上也是一种方言，只不过它是官方的方言，使用最为广泛的方言，相比而言其它方言都是小语种，小语种之中也会有几个使用比较广泛比较特色的方言占比也会比较大。这就好比开源 RPC 协议中Protobuf和 Thrift 一样，它们两应该是 RPC 协议中使用最为广泛的两个。
总之：RPC是一种编程模式和概念，并不是非常具体的一种技术，实际上和HTTP没有明确的冲突，HTTP可以作为RPC传输协议，原因还是RPCpid际上是一种内部服务框架而不是一个具体的通信协议，它可以涉及服务注册、服务治理、服务发现、熔断机制、负载均衡等。
典型的RPC框架
一个典型RPC框架中，包含了服务发现、负载、容错、网络传输、序列化等组件，其中“RPC 协议”就指明了程序如何进行网络传输和序列化。
▲ 一个典型的 RPC 架构原理图（本图引用自《即时通讯新手入门：快速理解RPC技术——基本概念、原理和用途》）
▲ 著名RPC框架Dubbo的架构图（本图引用自《即时通讯新手入门：快速理解RPC技术——基本概念、原理和用途》）
一个 RPC 最重要的功能模块，就是上图中的”RPC 协议”部分：
其中的序列化和反序列化的意思是：
1）序列化：将数据结构或对象转换成二进制串的过程；2）反序列化：将序列化中所生成的二进制串转换成数据结构或者对象的过程。
在网络消息传输中可以基于TCP、UDP、http来实现，各自都有各自的特点。
基于 TCP 实现的 RPC 调用，能够灵活对协议字段进行定制，减少网络开销提高性能，实现更大的吞吐量和并发数，但要关注底层细节，在进行数据解析时更加复杂一些（比如最受欢迎的Protobuf的使用）。
基于 HTTP 实现的 RPC 可以使用 JSON 和 XML 格式的请求或响应数据，解析工具很成熟，在其上进行二次开发会非常便捷和简单。但是 HTTP 是上层协议，所占用的字节数会比使用 TCP 协议传输所占用的字节数更高。
对于其他部分，本文不再展开。
市面上常见的RPC框架及其特点
常见 RPC 技术和框架有：
1）应用级的服务框架：阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。2）远程通信协议：RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。3）通信框架：MINA 和 Netty。
目前流行的开源 RPC 框架还是比较多的，有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的 gRPC、Twitter 的 Finagle 等。
下面重点介绍当前最流行的三种RPC框架主要特点：
1）gRPC：是 Google 公布的开源软件，基于最新的 HTTP 2.0 协议，并支持常见的众多编程语言。RPC 框架是基于 HTTP 协议实现的，底层使用到了 Netty 框架的支持；2）Thrift：是 Facebook 的开源 RPC 框架，主要是一个跨语言的服务开发框架。用户只要在其之上进行二次开发就行，应用对于底层的 RPC 通讯等都是透明的。不过这个对于用户来说需要学习特定领域语言这个特性，还是有一定成本的；3）Dubbo：是阿里集团开源的一个极为出名的 RPC 框架，在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是极其鲜明的特色。
本文小结
小结一下，简单地理解RPC就是：
RPC就是从一台机器（客户端）上通过参数传递的方式调用另一台机器（服务器）上的一个函数或方法（可以统称为服务）并得到返回的结果。
RPC会隐藏底层的通讯细节（不需要直接处理Socket通讯或Http通讯）。
RPC是一个请求响应模型。客户端发起请求，服务器返回响应（类似于Http的工作方式）。
RPC在使用形式上像调用本地函数（或方法）一样去调用远程的函数（或方法）。
以上就是小编关于【RpC是哪个国家的缩写】的分享，希望对你有用。
网友提问：
rpc是哪个国家，RpC是哪个国家的缩写？
微服务调用为什么用RPC框架，
优质回答：
简单点，HTTP是协议，RPC是概念！实现RPC可以基于HTTP协议（Feign），TCP协议(Netty)，RMI协议（Soap），WebService（XML—RPC）框架。传输过程中，也因为序列化方式的不同，又有一些框架和协议，比如Dubbo中的Dubbo协议，gRpc—Protobuf序列化协议等等。其实，都是基于远程调用的概念，何为远程调用？
重点是，RPC就是远程调用，远程调用就是客户端把调用的接口，参数，参数类型，方法，返回值，返回值类型等（这些称为方法签名），通过如上的协议，发送给服务端，告知服务端需要调用的接口方法，这个过程就是RPC的实现过程！HTTP和RPC是不同层面的两个东西！
性能方面，HTTP本身是基于TCP协议的，属于应用层协议，所以HTTP协议本身在实现过程中就会占用大量的资源（内存，带宽等），性能上肯定没有通过TCP直接实现RPC协议快，不管HTTP如何优化肯定的是不如TCP的！而TCP则是依靠字节码，现在普遍采用的是将客户端调用的接口信息，序列化的方式发送给服务端，序列化框架又包含很多（Hession，Protobuf，Kryo等等，序列化性能最高的是Kryo，序列化后字节码最小的是Protobuf），序列化后的字节码越小，占用带宽越少，序列化时间越短，线程IO等待时间就会越小。所以，在具体应用层面有很多可探讨的技术，可以根据自己的硬件能力来选择相应的技术就可以了！
欢迎热爱技术的人来探讨！
其他网友观点
基本都是复制黏贴，全是一个答案，没看到有真正深入思考过的答案，还是我来说说吧。
前言：其实计算机里面的很多概念都是来源于现实世界的，通过现实里面具体的例子来理解RPC。A：代表一栋大楼（相当于一个大的服务端内网集群），B：代表大楼内的一个个房间（每个房间相当于一个应用框架)，C：代表人员管理机构（相当于楼管处或者各级人口管理部门）。首先，在项目架构比较简单的时候，可能一个项目就一个统一的框架，一种语言，这时候我们程序里面的一个方法里面可能会调用N个其他的方法，但因为都是在同一个框架内，都属于框架级的内部调用，这个时候自然用不到RPC，RESTful足以满足当前场景。 但是当你的项目架构越来越复杂，访问量越来越多的时候，可能上了N多框架，N个语言，当你在业务里面调用其他框架的方法或者调用其他独立部署的服务的时候，自然没法像最初那样直接在框架/容器的内部去调用，当这种框架和容器间的这种调用量不是很大的时候依然可以选择用RESTful方式去调用，但是当这种调用量很大，服务很多的时候，RESTful显然是无法满足需求的。
打个比方，最初的内部调用相当于你要找的人和你在同一个房间内，直接就可以找到。但当要找的人分散在大楼的各个房间的时候，你怎么找他呢？你可以去区里人口部门查，查不到去市里 – 省里 – 国家人口管理部门查，最终肯定总能找到他，但这样的方式是不是效率很低，路径很长？所以这个时候就来了RPC解决了这个问题，我们在该大楼一楼建立了统一的楼管处（服务注册中心），该出记录了大楼里面每个人的详细信息，每个人要先去登记（服务注册），要查的时候直接去楼管处查（服务发现）就可以了。当然你可以直接走路（HTTP协议）去查，也可以直接打电话（TCP协议）去楼管处查，也可以微信群（自定义协议）去查。 首先该楼管处记录的信息量非常小（只记录你们大楼的人），非常垂直和精确，所以你去查的速度会非常快，路径会非常短。 如果你还用传统RESTful的方式，首先查找范围会非常大，因为你根本不知道这个人到底在哪里，他可能在你们大楼内，也可能在本市某个角落的大楼里面，还可能在几千公里外的另一个城市，你查找的目标范围会非常大，路径会非常长，不确定性非常大。所以最终的效率肯定是非常低的。
完整的 RPC 框架
在一个典型 RPC 的使用场景中，包含了服务发现、负载、容错、网络传输、序列化等组件，其中“RPC 协议”就指明了程序如何进行网络传输和序列化。
图完整 RPC 架构图
RPC和RESTful的区别
RPC的优势：
是查找的精确性，快速性，短路径，和确定性，因为属于内网查询，独立的注册中心，所以查找的速度更快。
而且由于做了精简和优化，删去了RESTful方式里面很多多余的信息，比如Header，而且做了压缩和序列化，通过二进制方式传输，传输的内容更少，传输的速度也更快。
环节和流程更少，因为RESTful需要经过路由，负载均衡，网关，防火墙和一系列的身份识别和校验，就像大楼内来了个不认识的人，楼管大叔肯定要查你的身份证等等信息核实你的信息。 而且RPC就省去了这些环节，就像你天天出来进去，楼管大妈早就对你很熟了，不需要每次核实你的信息，RPC省去了很多环节。
RESTful的优势：
通用性更好，RESTful可以供任何接入互联网的终端调用，各种平台，各种终端都可以用RESTful传输和交换数据，而且有一套标准和规范的传输格式，所以格式更加标准化和通用化。
调用及测试都很方便。RPC 实现需要实现编码，序列化，网络传输等。而 RESTful 不要关注这些，RESTful 实现更简单。
移植性更好，从一个服务器迁移到另一个服务器，从一个节点迁移到另一个节点，从一个架构移植到另一种架构，都可以轻松完成。
RPC的应用场景：当你的框架和语言种类也比较多，内部子系统较多、接口非常多的情况下，RPC是最佳的选择。RPC更多是内网之间的数据传输，性能消耗低，传输效率高，实现复杂。一般是部署在服务层的分布式系统里面，或者微服务系统。有服务治理，服务限流、服务降级、服务熔断、服务监控等等，类似于大楼里面配了治安处，物业处、后勤处、监控中心等。
长链接。不必每次通信都要像 HTTP 一样去 3 次握手，减少了网络开销。
注册发布机制。RPC 框架一般都有注册中心，有丰富的监控管理;发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。
安全性，没有暴露资源操作。
微服务支持。就是最近流行的服务化架构、服务化治理，RPC 框架是一个强力的支撑。
RESTful的应用场景：数据更多是公网上的传输，主要用于对外的异构环境，浏览器接口调用，App 接口调用，第三方接口调用等。
其他网友观点
RPC名称是远程服务调用。这里面实际是没有限制一定会是tcp，也可以是http或者其他基于tcp协议的服务。
远程服务调用，有多种 ，http的接口调用，基于http的webservice，java中的rmi 实际都算是rpc。为什么都向长连接改动。是因为技术性能的要求越来越高，必然带来这样的发展趋势。
http接口，简单通用，但是调用放需要编写大量的代码去解析返回结果，并且http性能并不高效，除了header的问题之外，早期的http还不能多路复用。
webservice实际上是http协议之上的封装，它更多是为了解决http接口调用需要编写大量客户端解析参数代码产生的，它能帮助少写代码，但无法改善http的性能。
java的rmi 典型的就是ejb 现在新的java程序员可能都没听过这玩意，这也是基于长连接实现，基于java的序列化。它能够解决客户端参数解析的问题，也能多路复用socket 但是ejb本身的复杂性以及java序列化低效的问题导致它也是被放弃，并且它是不能跨语言的。
现在的rpc框架大多都是基于socket长连接，自定义协议实现。采用的序列化方式也会比较高效和跨语言。比如grpc 采用protobuf做序列化，采用http2做传输协议。
从某种意义上来讲，http接口也能算是rpc调用，只是需要更具开发工作量以及性能指标做技术抉择。
其他网友观点
RPC是一种概念，http是RPC实现的一种方式，用http交互其实就已经属于rpc了！
RPC 协议名词解释
在一个典型RPC的使用场景中，包含了服务发现、负载、容错、网络传输、序列化等组件，其中RPC协议就指明了程序如何进行网络传输和序列化 。也就是说一个RPC协议的实现就等于一个非透明的RPC调用，如何做到的的呢？
RPC 协议的组成
1.地址：服务提供者地址
2.端口：协议指定开放的端口
3.运行服务
netty
mina
RMI服务
servlet容器(jetty/tomcat/Jboss)
4.报文编码：协议报文编码 。注①:http 报文编码 。注②:Dubbo 报文编码
5.序列化方式
Hessian2Serialization
DubboSerialization
JavaSerialization
JsonSerialization
RPC协议报文编码与实现详解
1、HTTP协议报文
2、Dubbo协议报文
协议编解码过程
Dubbo 支持的RPC协议列表
1、dubbo
实现描述： 传输服务: mina， netty(默认)， grizzy序列化: dubbo， hessian2(默认)， java， fastjson 自定义报文
连接描述：
单个长连接NIO异步传输
适用场景：
1、常规RPC调用2、传输数据量小 3、提供者少于消费者
2、rmi
实现描述：
传输：java rmi 服务序列化：java原生二进制序列化
连接描述：
多个短连接BIO同步传输
适用场景：
1、常规RPC调用2、与原RMI客户端集成 3、可传少量文件 4、不支持防火墙穿透
3、hessian
实现描述：
传输服务：servlet容器序列化：hessian二进制序列化
连接描述：
基于Http 协议传输，依懒servlet容器配置
适用场景：
1、提供者多于消费者2、可传大字段和文件 3、跨语言调用
4、http
实现描述：
传输服务：servlet容器序列化：http表单
连接描述：
依懒servlet容器配置
适用场景：
1、数据包大小混合
RPC 传输实现
RPC的协议的传输是基于 TCP/IP 做为基础使用Socket 或Netty、mina等网络编程组件实现。但有个问题是TCP是面向字节流的无边边界协议，其只管负责数据传输并不会区分每次请求所对应的消息，这样就会出现TCP协义传输当中的拆包与粘包问题
拆包与粘包产生的原因
们知道tcp是以流动的方式传输数据，传输的最小单位为一个报文段（segment）。tcp Header中有个Options标识位，常见的标识为mss(Maximum Segment Size)指的是，连接层每次传输的数据有个最大限制MTU(Maximum Transmission Unit)，一般是1500比特，超过这个量要分成多个报文段，mss则是这个最大限制减去TCP的header，光是要传输的数据的大小，一般为1460比特。换算成字节，也就是180多字节。
tcp 为 提高性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了之后，再将缓冲中的数据发送到接收方。同理，接收方也有缓冲区这样的机制，来接收数据。这时就会出现以下情况：
应用程序写入的数据大于MSS大小，这将会发生拆包
应用程序写入数据小于MSS大小，这将会发生粘包
接收方法不及时读取套接字缓冲区数据，这将发生粘包。
拆包与粘包解决办法
设置定长消息，服务端每次读取既定长度的内容作为一条完整消息
其他网友观点
首先微服务也有用http的，现在流行的feign，底层就是http，也是我们经常提到的restful编程方式。
Rpc在国内最具有代表的是dubbo，底层可以选择netty进行通讯，速度肯定是比http快的。
但是微服务不是一个简单的调用，涉及到很多方面，比如容错，高并发，熔断，事务等等。普通的http代码是无法解决这些问题的。一般需要很多组件来配合，比如feign就要配合robbin，hystrix等来配合，dubbo也需要zookeeper来配合。
所以这两者在我们的开发中，都很常见。
