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目录下