Thrift Data Transfer serialization

This is a creation in Article, where the information may have evolved or changed.

Thrift serialization is a better structure than JSON (I haven't studied it yet). But it has a very serious problem: poor compatibility. We have been spoiled by the use of JSON all year round and subconsciously feel that data is compatible by default.

Let's talk about that online problem. I and other departments of the company with Thrift docking, first on a version, I am the caller. Then, two times the upgrade, the cooperation of the Department changed the IDL, the function returns the result structure of the first, inserted a structure, is a structure, the first version of the original position is shaping. Then they went online, and I was in line. All of a sudden, I'm reporting my interface returns 404 (general errors are turned into 404). Then to troubleshoot, found to return a bunch of negative numbers, negative results in the logic behind the problem, even if the return of an integer, is very abnormal.

At this critical moment, our team leader (always him) explained the cause of the bug, which was caused by thrift incompatibility.

struct Pair {1: required string key2: required string value}

The above structure, if parsed into JSON, is shown in the form of a key-value pair, and the name of the field variable is meaningful. And in the thrift, is still the form of key-value pairs, but not with the name of the variable name as a key, but by the sequence number and type as the key, the ordinal determines the position, type determines the parsing mode.

Versioning in Thrift is implemented Viafield identifiers. Thefield header for every member of a struct in Thrift are encoded with a Uniquefield identifier. The combination of Thisfield identifier and its type specifier are used to uniquely identify Thefield. The Thrift definition language supports automatic assignment Offield identifiers, but it's good programming practice to ALW Ays explicitly Specifyfield identifiers.

Previously wrote an article "Golang Development Thrift Interface", this time then with this as the basis for the modification of the experiment. Add a test function that returns the structure we want to experiment with.

Pair helloPair()

Generate Golang packages from IDL:

thrift -v --gen go:package_prefix=go_code/test_thrift Hello1.thrift

In helloimpl.go implementing this new method:

func (h *HelloHandler) HelloPair() (*hello.Pair, error) {p := new(hello.Pair)p.Key = "rowkey"p.Value = "column-family"return p, nil}

To start the service side:

go run helloserver.go helloimpl.go

In the helloclient.go increase call:

res, err := client.HelloPair()fmt.Println(res.String())

The results are as follows:

$ go run helloclient.goPair({Key:rowkey Value:column-family})

The result is correct, below to simulate the error situation. This simulation is simple and modifies the IDL order:

struct Pair {2: required string key1: required string value}

Regenerate IDL again, in order to compare, I named this IDL Hello1.thrift . Then copy the original file and rename it to helloimpl1.go and helloserver1.go . Change the name of the referenced package to hello "go_code/test_thrift/hello1" . Start the server again:

hello "go_code/test_thrift/hello1"

The client does not make any modifications:

$ go run helloclient.goPair({Key:column-family Value:rowkey})

The result is exactly the opposite, amazing there is no ...

Please refer to the complete source code in this article.

Reference documents

1. Thrift of individual combat –thrift-Mumuxinfei

Original link: Thrift data transmission serialization, reproduced please indicate the source!