序列化相关实践
Protobuf
当前grpc所使用的序列化方式。
protoc.exe –proto_path=....\examples –cpp_out=....\examples ....\examples\addressbook.proto
该命令中–proto_path参数表示.proto消息定义文件路径(如果在当前目录下,则可以省略),–cpp_out表示输出c++类的路径(–java_out表示输出的是java文件的路径),后面接着是*.proto消息定义文件。
2,编译后的java文件,存储了生成的数据访问类。可以使用相关接口进行数据的操作。
protoc.exe –java_out .\gen\java common.proto
Fastjson
fastjson的key是根据javabean里面的getter和setter方法来的,不是根据属性名的,所以会出现这个问题,你在属性的get和set方法上面写上标注,说明转成什么就行了
private String newName;
@JSONField(name="new_name")
public String getNewName()
{
return newName;
}
@JSONField(name="new_name")
public void setNewName(String newName)
{
this.newName= newName
}
fastjson 过滤多余的字段,填入的参数是需要序列化的
SimplePropertyPreFilter filter = new SimplePropertyPreFilter(实体类.class, "字段名","字段名");
//SimplePropertyPreFilter filter = new SimplePropertyPreFilter(实体类.class, 数组.String[]);
JSON.toJSONString(list, filter);
如果字段为空值,fastjson反序列化时会丢失。需要增加feature:SerializerFeature.WriteMapNullValue
Gson
默认编码时,一个字符会编码为2-3个字节,导致实际发送的数据长度是原有的3倍,需要使用base64编码。jackson不存在该问题。经过几年改进不确定是否优化了该问题,可以作为fastjson的替代品。
public static class ByteArrayTypeAdapter implements JsonSerializer<byte[]>,
JsonDeserializer<byte[]> {
Override
public byte[] deserialize(JsonElement json, Type typeOfT,
JsonDeserializationContext context) {
String str = json.getAsString();
return Base64.decode(str.getBytes());
}
1@Override
public JsonElement serialize(byte[] src, Type typeOfSrc,
JsonSerializationContext context) {
String str = new String(Base64.encode(src));
return new JsonPrimitive(str);
}
}
Thrift
E:\sourcecode\mule_hz\common\rpc_mule\trunk\src\thriftFile>thrift-0.9.0.exe -gen java -out ../main/java response.thrift
Thrift通过一个中间语言(IDL, 接口定义语言)来定义RPC的接口和数据类型,然后通过一个编译器生成不同语言的代码(目前支持C++,Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk和OCaml),并由生成的代码负责RPC协议层和传输层的实现。 Thrift实际上是实现了C/S模式,通过代码生成工具将接口定义文件生成服务器端和客户端代码(可以为不同语言),从而实现服务端和客户端跨语言的支持。用户在Thirft描述文件中声明自己的服务,这些服务经过编译后会生成相应语言的代码文件,然后用户实现服务(客户端调用服务,服务器端提服务)便可以了。其中protocol(协议层, 定义数据传输格式,可以为二进制或者XML等)和transport(传输层,定义数据传输方式,可以为TCP/IP传输,内存共享或者文件共享等)被用作运行时库。
支持的数据传输格式、数据传输方式和服务模型
支持的传输格式
- TBinaryProtocol – 二进制格式.
- TCompactProtocol – 压缩格式
- TJSONProtocol – JSON格式
- TSimpleJSONProtocol –提供JSON只写协议, 生成的文件很容易通过脚本语言解析。
- TDebugProtocol – 使用易懂的可读的文本格式,以便于debug
支持的数据传输方式
- TSocket -阻塞式socker
- TFramedTransport – 以frame为单位进行传输,非阻塞式服务中使用。
- TFileTransport – 以文件形式进行传输。
- TMemoryTransport – 将内存用于I/O. java实现时内部实际使用了简单的ByteArrayOutputStream。
- TZlibTransport – 使用zlib进行压缩, 与其他传输方式联合使用。当前无java实现。
支持的服务模型
- TSimpleServer – 简单的单线程服务模型,常用于测试
- TThreadPoolServer – 多线程服务模型,使用标准的阻塞式IO。
- TNonblockingServer – 多线程服务模型,使用非阻塞式IO(需使用TFramedTransport数据传输方式)
.thrift文件编写
一般将服务放到一个.thrift文件中,服务的编写语法与C语言语法基本一致,在.thrift文件中有主要有以下几个内容:变量声明、数据声明(struct)和服务接口声明(service, 可以继承其他接口)。
代码生成
- 要生成C++代码:./thrift –gen cpp tutorial.thrift,结果代码存放在gen-cpp目录下
- 要生成java代码:./thrift –gen java tutorial.thrift,结果代码存放在gen-java目录下