70 网友分享了链接
2020-08-24 06:14:47
具体场景 对于公司间的系统调用，如果性能要求在 100ms 以上的服务，基于 XML 的 SOAP 协议是一 个值得考虑的方案。 基于 Web browser 的 Ajax，以及 Mobile app 与服务端之间的通讯，JSON 协议是首选。对于 性能要求不太高，或者以动态类型语言为主，或者传输数据载荷很小的的运用场景，JSON 也是非常不错的选择。 对于调试环境比较恶劣的场景，采用 JSON 或 XML 能够极大的提高调试效率，降低系统开 发成本。 当对性能和简洁性有极高要求的场景，Protobuf，Thrift，Avro 之间具有一定的竞争关系。 对于 T 级别的数据的持久化应用场景，Protobuf 和 Avro 是首要选择。如果持久化后的数据 存储在 hadoop 子项目里，Avro 会是更好的选择。 对于持久层非 Hadoop 项目，以静态类型语言为主的应用场景，Protobuf 会更符合静态类 型语言工程师的开发习惯。由于 Avro 的设计理念偏向于动态类型语言，对于动态语言为主 的应用场景，Avro 是更好的选择。 如果需要提供一个完整的 RPC 解决方案，Thrift 是一个好的选择。 如果序列化之后需要支持不同的传输层协议，或者需要跨防火墙访问的高性能场景， Protobuf 可以优先考虑。 protobuf 的数据类型有多种：bool、double、float、int32、int64、string、bytes、enum、 message。protobuf 的限定符：required: 必须赋值，不能为空、optional:字段可以赋值，也 可以不赋值、repeated: 该字段可以重复任意次数（包括 0 次）、枚举；只能用指定的常量 集中的一个值作为其值； protobuf 的基本规则：每个消息中必须至少留有一个 required 类型的字段、包含 0 个或多 个 optional 类型的字段；repeated 表示的字段可以包含 0 个或多个数据；[1,15]之内的标识 号在编码的时候会占用一个字节（常用），[16,2047]之内的标识号则占用 2 个字节，标识号 一定不能重复、使用消息类型，也可以将消息嵌套任意多层，可用嵌套消息类型来代替 组。 protobuf 的消息升级原则：不要更改任何已有的字段的数值标识；不能移除已经存在的 required 字段，optional 和 repeated 类型的字段可以被移除，但要保留标号不能被重用。 新添加的字段必须是 optional 或 repeated。因为旧版本程序无法读取或写入新增的 required 限定符的字段。 编译器为每一个消息类型生成了一个.java 文件，以及一个特殊的 Builder 类（该类是用来创 建消息类接口的）。如：UserProto.User.Builder builder = UserProto.User.newBuilder();builder.build()； Netty 中的使用：ProtobufVarint32FrameDecoder 是用于处理半包消息的解码类； ProtobufDecoder(UserProto.User.getDefaultInstance())这是创建的 UserProto.java 文件中的解 码类；ProtobufVarint32LengthFieldPrepender 对 protobuf 协议的消息头上加上一个长度为 32 的整形字段，用于标志这个消息的长度的类；ProtobufEncoder 是编码类 将 StringBuilder 转换为 ByteBuf 类型：copiedBuffer()方法