hessian序列化优缺点 微服务调用为啥用RPC框架，http不更简单吗？

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

简单一点，HTTP是协议，RPC是概念！RPC可以基于HTTP协议（feign）、TCP协议（netty）、RMI协议（soap）和web服务（XML-RPC）框架实现。在传输过程中，由于序列化方法的不同，也出现了一些框架和协议，如Dubbo中的Dubbo协议、grpc protobuf序列化协议等。实际上，它们都是基于远程调用的概念。什么是远程呼叫？

关键是RPC是远程调用。远程调用是客户端通过上述协议向服务器发送接口、参数、参数类型、方法、返回值、返回值类型等（称为方法签名），通知服务器要调用的接口方法。这个过程就是RPC的实现过程！HTTP和RPC是两码事

！在性能方面，HTTP本身是基于TCP协议的，属于应用层协议，所以HTTP协议本身在实现过程中会占用大量的资源（内存、带宽等）。在性能方面，它肯定不如直接通过TCP实现的RPC协议快。不管HTTP有多优化，它绝对没有TCP那么快！另一方面，TCP依赖于字节码。目前常用的是将客户端调用的接口信息以序列化的方式发送到服务器端。序列化框架包括许多内容（Hession、protobuf、kryo等）。Kryo具有最高的序列化性能，protobuf具有序列化后最小的字节码）。序列化后的字节码越小，占用的带宽越小，序列化时间越长，线程IO延迟越短，线程IO延迟越小。因此，在具体的应用层，有很多技术可以讨论。您可以根据自己的硬件能力选择相应的技术

！欢迎热爱科技的人们来探索

有Protocol buffer这种轻便的序列化反序列化工具，Json为什么还会大量使用？

原因很简单：

1、JSON是JavaScript本机支持，没有外部依赖项

2、JSON具有人眼可读性

3、开发人员懒惰

关于序列化协议和框架，估计可以创建一个百科全书，如：XML、JSON、bson、Hessian、，协议缓冲区…

有很多不受欢迎的，排名不分先后。

虽然有各种各样的协议和框架，但序列化本质上可以分为两种类型：

二进制协议的优点是体积小、效率高。例如，协议缓冲区可以用来将数据压缩成位，序列化和反序列化具有良好的性能，非常适合各种系统通信和接口调用。

但问题也在这里，二进制数据几乎没有可读性，所以在程序的开发和调试中，更让程序员痛苦，尤其是频繁变化的数据结构。

文本协议恰恰相反，数据量大，性能差，但能满足可读性要求。例如，我们可以很容易地理解JSON或人肉结构数据的一部分。对于快速开发和web开发来说，它可以提高开发效率，开发人员不必过于关注协议或框架，只关注业务。

我的观点如下：

1。对于具有稳定服务和高性能要求的场景，应优先考虑二进制序列化协议，如协议缓冲区

2。对于性能要求低、业务更改频繁的场景，应优先考虑JSON和XML等文本协议

区别：

Dubbo默认协议：

单TCP长连接，Hessian二进制序列化和NiO异步通信

适用于小数据包和大并发服务调用，并且服务使用者的数量远远大于服务提供者的数量

不适用于传输大数据包

Hessian协议：

底层HTTP通信，servlet公开服务，Dubbo默认嵌入式jetty作为服务器实现

可以与本机Hessian服务进行互操作

通信效率高于WebService和Java可序列化接口应针对自身的可序列化参数和返回值，以及list、map、，数字、日期、日历等

适合传输大数据包，提供商多于消费者，提供商压力更大。

hessian与dubbo协议的区别？

Java的序列化性能正常，没有达到不可接受的水平。如果这成为性能瓶颈，我们可以考虑使用其他序列化框架。

众所周知的序列化框架如下：

高性能，需要对bean进行一些简单的修改；

基于protobuf，需要静态编译；

与上述两种框架相比，开发更容易，性能更低。

希望能对您有所帮助。