最近开发的一个项目,后端采用thrift框架来提供rpc服务(java语言实现),然后前端采用php语言来生成thrift client调用后台RPC服务。由于某些原因,上周我把thrift定义文件中一个struct名称修改了,当然也没多想,顺手就把java服务端重新编译部署,而php前端的部署未做任何变化,按常规理解,服务契约中的类名,从A改成B,服务的调用方理应同步更新部署,否则感觉应该会出错。
然而,美好的事情就这么发生了,一切运行正常,依旧丝丝顺滑!
再然后,我就开始思考人生,重新理解 thrift内部的序列化与反序列化机制,很快就想明白了,借用之前写过的博客rpc框架之 avro 学习 2 - 高效的序列化中的一张图:
thrift内部存储二进制数据时,为了提高存储效率,每个field都分配了一个数字编号,所以在序列化及反序列化时,其实是只认数字编号,不管名称的,这也正是thrift IDL文件定义struct时,为什么强制要求每个成员都要指定一个在struct本身范围内不重复的数字序号
struct PersonModel {
1: i16 age = 0,
2: string name,
3: bool sex,
4: double salary,
5: byte childrenCount
}
IDL生成的具体语言的源代码中,解析对象时,同样也只看序号,以c#生成的代码为例:
1 public void Read (TProtocol iprot)
2 {
3 iprot.IncrementRecursionDepth();
4 try
5 {
6 TField field;
7 iprot.ReadStructBegin();
8 while (true)
9 {
10 field = iprot.ReadFieldBegin();
11 if (field.Type == TType.Stop) {
12 break;
13 }
14 switch (field.ID)
15 {
16 case 1:
17 if (field.Type == TType.I16) {
18 Age = iprot.ReadI16();
19 } else {
20 TProtocolUtil.Skip(iprot, field.Type);
21 }
22 break;
23 case 2:
24 if (field.Type == TType.String) {
25 Name = iprot.ReadString();
26 } else {
27 TProtocolUtil.Skip(iprot, field.Type);
28 }
29 break;
30 case 3:
31 if (field.Type == TType.Bool) {
32 Sex = iprot.ReadBool();
33 } else {
34 TProtocolUtil.Skip(iprot, field.Type);
35 }
36 break;
37 case 4:
38 if (field.Type == TType.Double) {
39 Salary = iprot.ReadDouble();
40 } else {
41 TProtocolUtil.Skip(iprot, field.Type);
42 }
43 break;
44 case 5:
45 if (field.Type == TType.Byte) {
46 ChildrenCount = iprot.ReadByte();
47 } else {
48 TProtocolUtil.Skip(iprot, field.Type);
49 }
50 break;
51 default:
52 TProtocolUtil.Skip(iprot, field.Type);
53 break;
54 }
55 iprot.ReadFieldEnd();
56 }
57 iprot.ReadStructEnd();
58 }
59 finally
60 {
61 iprot.DecrementRecursionDepth();
62 }
63 }
从上面的case语句可以很清楚的看出,代码内部只认数字序号,不关心名称。
结论:只要不改变struct内部的成员类型和数字编号,struct对应的类名可以放心大胆的修改。