core币如何提现(core 币)

发布时间：2024-05-23 19:34:12

OK欧意app

欧意交易app是全球排名第一的虚拟货币交易所。

微服务调用为什么用RPC框架，http不更简单吗？

首先微服务也有用http的，现在流行的feign，底层就是http，也是我们经常提到的restful编程方式。

Rpc在国内最具有代表的是dubbo，底层可以选择netty进行通讯，速度肯定是比http快的。

但是微服务不是一个简单的调用，涉及到很多方面，比如容错，高并发，熔断，事务等等。普通的http代码是无法解决这些问题的。一般需要很多组件来配合，比如feign就要配合robbin，hystrix等来配合，dubbo也需要zookeeper来配合。

所以这两者在我们的开发中，都很常见。

RPC，远程过程调用，通过网络从远程计算机程序上请求服务。浏览器请求 web 服务完成可以理解为就是 RPC 调用，现在你搞清楚了吗？RPC 是概念名词，http 是数据传输协议，这两者是不同的。我们来看看市面上的一些 RPC 框架

gRPC，支持的传输协议 http/2
dubbo，支持的传输协议 Dubbo，http 等

接下来顺便讲下 RPC 框架一般会有的功能

服务注册，微服务启动起来后，肯定要告诉下服务注册中心，本服务已经启动起来
服务发现，通过服务注册中心拿到所有启动起来的服务的服务地址
客户端负载均衡，我现在通过服务注册中心拿到一组服务地址了，总得选择一个，那么应该选择哪个？这时候就需要依赖于负载均衡算法了
传输协议，数据传输前自然是要序列化，然后通过客户端与服务端都支持的协议进行交流，协议可以是自研的协议，也可以是 http 协议

RPC 框架的设计自然不止我讲的这些，但是作为了解其实已经足够了

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调用，只是需要更具开发工作量以及性能指标做技术抉择。

简单点，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：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。