protobuf和json哪个快 微服务调用为啥用RPC框架，http不更简单吗？
微服务调用为啥用RPC框架，http不更简单吗？
简单点，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等待时间就会越小。所以，在具体应用层面有很多可探讨的技术，可以根据自己的硬件能力来选择相应的技术就可以了！
欢迎热爱技术的人来探讨！
如何优化很长的JSON数据？
现在主流的网络请求中都采用JSON作为其数据交互格式，这主要是因为JSON有以下优势：
数据格式简单，易于读写，格式都是压缩的，占用带宽小；
易于解析，客户端JS很容易JSON数据进行解析和编辑；
支持大多数后端语言，大大简化了服务端和前端交互时的代码开发量，且易于维护；
但如果在开发过程中，把很长很大的JSON数据在前后端传输，那就说明设计工作没做好，应该尽量避免这种数据传输，但也可以从下面几个方面进行下优化：
优化json数据的key-value的长度，尽量简洁易懂即可；
异步分批加载，建设大数据量造成前端页面卡死；
前端增加销毁机制，可以一边加载，一边销毁；
使用解析和压缩性能高的JSON解析工具；
在 Skylake 处理器上，各种解析器解析同一个大数据量的JSON文件的速度（以 GB/s 为单位）如下所示：
protobuf和json哪个快 json和protobuf的区别 gson和jackson
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
