The original article is reprinted from liu Yue’s Technology blog v3u.cn/a_id_104

At present, the HTTP interface solution based on JSON-drF framework similar to Django is very popular in the market. People are also keen to use it in the case of few interfaces and less interaction between systems. The advantages of HTTP interface are simple, direct, convenient development, low threshold, and the use of ready-made HTTP protocol for transmission.

However, things often have two sides. If it is a large website with many internal subsystems and interfaces, the benefits of RPC framework will be shown. The first is the long link, which does not have to shake hands for three times and wave hands for four times like HTTP for each communication, reducing the network overhead. Secondly, RPC frameworks generally have registries and rich monitoring management. Publishing, offline interfaces, dynamic extensions, etc., are unaware and unified operations for callers. The third one is security. Finally, the recently popular servitization architecture, servitization governance, RPC framework is a strong support.

In terms of complexity, an RPC framework is certainly superior to a simple HTTP interface. However, there is no doubt that due to the limitation of HTTP protocol, HTTP interface needs to have HTTP request header, resulting in the efficiency or security of transmission is not as good as RPC. Currently, popular RPC frameworks such as Dubbo/Hessian Thrift are on the market. However, I prefer Facebook’s Thrift open source framework, which has received rave reviews on Github, and this time we are using Thrift based thriftpy2 framework.

Thrift is an interface description language and binary communication protocol that is used to define and create cross-language services, as described in Wikipedia. The Thrift command line generates code in a variety of languages, such as OC, Java, C++, JS, etc. Then you can call these codes and complete the communication between the client and the server. You do not need to write the network request, data parsing, etc.

In fact, in my actual teaching work, I mainly consider these two advantages:

The RPC. By simply defining the Thrift description language file, you can use the Thrift -gen command to generate codes in multiple languages, including network communication and data codec functions. This eliminates the tedious code of the front and background, and also unifies the implementation logic of the front and background.

Thrift binary data is encoded more compactly than JSON, reducing the transfer of useless data.

Installation:

pip3 install thriftpy2
Copy the code

The thrift communication file is defined first. Both the server and clinet sides communicate based on this file

service PingPong {
    string ping(),
    string check_login(
        1: string username,
        2: string password
    ),
}
Copy the code

As you can see, we define two methods, one with and one without parameters. The first method is used to check whether the interface communicates successfully, which is the traditional ping command. The second method, as the name implies, is user login

Then create a thrift_server.py to create the server code

import thriftpy2
pingpong_thrift = thriftpy2.load("pingpong.thrift", module_name="pingpong_thrift")

from thriftpy2.rpc import make_server

class Dispatcher(object):
    
    def ping(self):
        return "pong"

    def check_login(self,username,password):
        print(username,password)
        return '123'

server = make_server(pingpong_thrift.PingPong, Dispatcher(), '127.0.0.1', 6000)
server.serve()
Copy the code

The server first reads the communication file, then sets up a service that listens on port 6000 and waits for the client to request it. In fact, the server method is where most of the business logic is written.

Then create a thrift_client.py file and write the client code

import thriftpy2
pingpong_thrift = thriftpy2.load("pingpong.thrift", module_name="pingpong_thrift")

from thriftpy2.rpc import make_client

client = make_client(pingpong_thrift.PingPong, '127.0.0.1', 6000).print(client.ping())

print(client.check_login('admin'.'123456'))
Copy the code

We see that the client also reads the communication file, and calls the parameters in strict accordance with the method invocation of the communication file to obtain the return value

Run the server side service

python3 thrift_server.py
Copy the code

Then run the python3 thrift_client.py client script

You can see that the server and client can communicate

It’s pretty simple, but one of the things I’m talking about here is the Thrift codec. We know that the traditional HTTP interface uses JSON as the data medium, and an object in JSON looks something like this: {“key”:”content”}, but in fact this object only “content” is the data we really want, and the string “key” is not really needed, just to make a mark, so that we can find “content”. Thrift eliminates the “key” superfluous string.

The attribute name in the structure that defines thrift is actually ignored in the thrift data binary codec (thrift’s JSON codec is not validated) and serves only as the attribute name of the generated OC code class. This also explains why Thrift’s binary encoding is much less traffic intensive than the usual JSON. But it also shows that as long as we keep the order of struct attributes the same when we define structs in the.thrift file, even if the two parties are using different attribute names, there’s no problem.

Thrift may be the answer you’re looking for as the number of concurrent requests increases and simple HTTP certainly doesn’t work.

The original article is reprinted from liu Yue’s Technology blog v3u.cn/a_id_104