Java中RPC框架及常用序列化协议

1、Java中序列化与反序列化相关

序列化框架

类型

特点

ProtoBuf

跨平台、跨语言

自定义协议类型,tag[value]形式进行存储,提前预定义字段类型及长度,小整数基于varint记性存储减少存储空间,长整型基于zigzag存储。

  • 跨语言 跨平台,语言中立的数据描述格式,默认提供了生成多种语言的 Compiler 工具。

  • 安全性,由于反序列化的范围和输出内容格式都是 Compiler 在编译时预生成的,因此绕过了类似 Java Deserialization Vulnarability 的问题。

  • 二进制 高性能

  • 强类型

  • 字段变更向后兼容

kryo

基于java语言的序列化方式

类似protobuf,对小整数友好,基于java语言

json/gson

基于json格式的序列化,跨语言

Jackson2/fastJson/gson,相比xml减少属性描述,校验基于接口。通用的 Json 有固有的性能问题

Hessian2

跨语言

xml

基于xml通用格式

字段属性都需定义描述,传输成本较大

2、常用分布式一致性算法

rpc框架

特点

paxos

目标是实现一致性数据状态机

zookeeper

基于PAXOS实现的ZAB(zookeeper atomic broadcast)算法,目标是实现分布式数据的一致性

raft

redis-sentinel中实现分布式数据一致性

3、常用RPC协议对比

rpc框架

优点

缺点

dubbo

dubbo直接定义在tcp传输协议上的,由于TCP全双工给dubbo提供了很大灵活性

rpc协议普遍都是定制化的私有协议,dubbo一样,协议通用性方面存在问题:扩展性不够好,java版本存在冗余,语言绑定,不够精简与通用

http/1.1

直接构建在http协议上解决方案就有更好通用性。

  1. HTTP 的语义和可扩展性能很好的满足 RPC 调用需求。

  1. 通用性,HTTP 协议几乎被网络上的所有设备所支持,具有很好的协议穿透性。

  • 典型的 Request – Response 模型,一个链路上一次只能有一个等待的 Request 请求

  • HTTP/1 支持 Keep-Alive 链接,避免了链接重复创建开销

  • 无直接 Server Push 支持,需要使用 Polling Long-Polling 等变通模式

http/2

http/2保留http/1.1所有语义,在通信模型与传输效率有更大改进

  • 支持单条链路上的 Multiplexing,相比于 Request - Response 独占链路,基于 Frame 实现更高效利用链路

  • Request - Stream 语义,原生支持 Server Push 和 Stream 数据传输

  • Flow Control,单条 Stream 粒度的和整个链路粒度的流量控制

  • 头部压缩 HPACK

  • Binary Frame

  • 原生 TLS 支持

gRPC

HTTP 及 TCP 协议之上构建 RPC 协议各自的优缺点,相比于 Dubbo 构建于 TPC 传输层之上,Google 选择将 gRPC 直接定义在 HTTP/2 协议之上。

  • Coverage & Simplicity,协议设计和框架实现要足够通用和简单,能运行在任何设备之上,甚至一些资源首先的如 IoT、Mobile 等设备。

  • Interoperability & Reach,要构建在更通用的协议之上,协议本身要能被网络上几乎所有的基础设施所支持。

  • General Purpose & Performant,要在场景和性能间做好平衡,首先协议本身要是适用于各种场景的,同时也要尽量有高的性能。

  • Payload Agnostic,协议上传输的负载要保持语言和平台中立。

  • Streaming,要支持 Request - Response、Request - Stream、Bi-Steam 等通信模型。

  • Flow Control,协议自身具备流量感知和限制的能力。

  • Metadata Exchange,在 RPC 服务定义之外,提供额外附加数据传输的能力。

在这样的设计理念指导下,gRPC 最终被设计为一个跨语言、跨平台的、通用的、高性能的、基于 HTTP/2 的 RPC 协议和框架

易用性不足以及服务治理能力欠缺

thrift

下面是 Thrift 的主要组件:

 Thrift 的接口定义语言(IDL)——用来定义你的服务,并且编排你的服务将要发送和接收的任何自定义类型;

 协议——用来控制将数据元素编码/解码为一个通用的二进制格式(如 Thrift 的二进制协议或者 JSON);

 传输—提供了一个用于读/写不同媒体(如 TCP 套接字、管道、内存缓冲区)的通用接口;

 Thrift 编译器——解析 Thrift 的 IDL 文件以生成用于服务器和客户端的存根代码,以及在IDL 中定义的自定义类型的序列化/反序列化代码;

 服务器实现—处理接受连接、从这些连接中读取请求、派发调用到实现了这些接口的对象,以及将响应发回给客户端;

 客户端实现——将方法调用转换为请求,并将它们发送给服务器。

参考文档:

Dubbo 在跨语言和协议穿透性方向上的探索:支持 HTTP/2 gRPC 和 Protobuf | Apache Dubbohttps://dubbo.apache.org/zh/blog/2019/10/28/dubbo-%E5%9C%A8%E8%B7%A8%E8%AF%AD%E8%A8%80%E5%92%8C%E5%8D%8F%E8%AE%AE%E7%A9%BF%E9%80%8F%E6%80%A7%E6%96%B9%E5%90%91%E4%B8%8A%E7%9A%84%E6%8E%A2%E7%B4%A2%E6%94%AF%E6%8C%81-http/2-grpc-%E5%92%8C-protobuf/

Protocol Buffer Basics: Java  |  Protocol Buffers  |  Google Developershttps://developers.google.cn/protocol-buffers/docs/javatutorial

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值