养花网微服务调用为什么用RPC框架，
优质回答
基本都是复制黏贴，全是一个答案，没看到有真正深入思考过的答案，还是我来说说吧。
前言：其实计算机里面的很多概念都是来源于现实世界的，通过现实里面具体的例子来理解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：Remote Procedure Call，中文意思就是远程过程调用。
那么我们先看看题目中的问题，其实，这个问题本身就是有问题的！
01. 既然有 HTTP ，为什么还要用 RPC ？
HTTP 和 RPC 并不是两个并行的概念，虽然很多书或文章，都介绍 HTTP 和 RPC 是在“应用层”，但实际上可以把应用层细分成多层，RPC 的所处的位置是高于 HTTP 的；HTTP 是网络协议，而RPC 可以看做是一种编程模式或实现方案；
RPC 通常包含传输协议和序列化协议，单说传输协议，RPC 可以建立在 TCP 协议之上（比如 Dubbo），也可以建立在 HTTP 协议之上（比如 gRPC）；如果是基于数据形式分类，RPC 又可以分成基于二进制、XML 和 JSON 三种；
而现在非常流行的开源 RPC 框架，比如上文中提到的Dubbo 和 gRPC 分别出身于阿里和谷歌，它们更多地是封装了服务注册发现、负载均衡、链路跟踪等功能，也可以这么理解，RPC 框架是对服务更高级的封装。
02. RPC VS Restful 风格的 API
如果非要比较的话，可以比较 RPC 和 Restful 风格的 API。
RPC：面向过程，也就是要做一件什么事情，只发送 GET 和 POST 请求；GET 用来查询信息，其他情况下一律用 POST；请求参数是动词。
RESTful：面向资源，这里的资源可以是一段文字、一个文件、一张图片，总之是一个具体的存在，可以使用 GET、POST、DELETE、PUT 请求，对应了增删查改的操作；请求参数是名词。
比如按照id 查找用户：
如果是 RPC 风格的 url 应该是这样的：GET /queryUser？userid=xxx；
而 RESTful 风格通常是这样的：GET /user/{userid}
03. 究竟选择哪一个？
RPC 特别适用于是分布式环境；它让客户端进行远程调用时，可以像调用本地方法一样方便；RPC 框架屏蔽了很多底层的细节，开发人员不需要关注这些细节，比如序列化和反序列化、网络传输协议；一些功能强大的 RPC 框架还提供了连接池管理、负载均衡、故障转移、超时管理、上下文管理器、异步回调、收发包队列、工作线程等功能。
RPC 和 Restful 风格的 API，如果非要争出来个第一第二，那么也要结合具体的使用场景，选择更适合的那个。
如果是偏向内部的 API，提供的 API 很难进行资源的抽象，没有规范的 API 的设计，性能要求更高，这些情况下更适合使用 RPC ；如果偏向外部 API，需要有更为规范的 API 设计，并且 API 天生是以资源为维度展开的，这时候可以选择 Restful 风格的 API。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
什么是RPC框架，为什么需要RPC框架？
优质回答
http协议，也是一种“rpc”协议。
以上就是小编关于rpc是哪个国家缩写的分享，希望对你有用。
