Tars-php: PHP builds a high-performance RPC framework

TARS is a complete solution that includes operations, platforms, communication frameworks, common components, and unified protocols. The latest TARS interface is divided into two parts: Service management and operation management. Service management can easily manage different services, while operation management can deploy services, expand and create templates. These are the capabilities of the TARS operation and platform, in addition to the many common components built in, provided as a service, including the usual configuration center, logging center, notification center, feature reporting, and master.

TARS uses a binary protocol with its own syntax independent of the language. The above is the basic style of the protocol, in which the two custom structure LoginInfo and ProfileInfo, can be arbitrarily combined with multiple base types. The lower interface declares the actual interface to call, using the structure defined above, and the out keyword in the argument list identifies the output Info. This gives us a convention interface file, which we can then use tools to translate into actual code for easy development.

In addition to binary protocol, we also design a set of communication protocol, including protocol version, request ID, server routing information, interface information, binary packet.

Overall, TARS is a suite of microservices solutions. Microservices include automatic service discovery, intelligent scheduling, disaster recovery and fault tolerance, flexible fuse, routing and gray scale. Support the private binary protocol, you can also support the JSON protocol by starting HTTP service. TARS already has good support for multiple languages, and is also compatible with some very user-friendly o&M systems.

To design a TARS PHP solution, several requirements must be met. First, it must be fully functional, able to standard the existing C++, Java, NodeJS system functions; Second, keep the whole program flexible so that more people can use it; The third is lightweight design, so far, plug and play; Finally, it can lead to high performance.

The figure above shows the composition of the overall scheme, which is mainly divided into 4 parts. The first piece is the TARS client, because our initial requirement was to use PHP to access the existing TARS service in C++ and Java. The second piece is TARS Server. Here, we hope to meet everyone’s needs as much as possible, allowing some common servers to be three-in-one while remaining flexible and lightweight. The third piece is a performance improvement TARS EXT extension, which is responsible for unpacking the underlying binary. The fourth block is development efficiency. TARS has automatic generation tools for almost every language, whether client side or server side.

The TARS Client now has all of these features. Automatic addressing allows you to know the name of the service instead of the address of the service. Each service has App name, Server name and the master, through which you can know the specific location of the service. Main call reporting means that all service running status is reported by the client. In this way, you can view all service status on the Server page. We also provide the ability to log remotely, in a send-and-don ‘t-receive form. Then there are three different capabilities for sending services, namely socket access, Swoole synchronization, and swoole coroutines.

The above is the overall structure of TARS Client. In the middle is the Client Server, which relies on PHP extensions, with three access methods on the left and various services on the right. Each time a request is made, the master service is called to cache the list, usually in a Swoole table or local file. When a service is started, a timer is used to determine when the service will expire. After obtaining the address, the RPC request is made. After the request is complete, the main call is reported, including the time consuming, failure rate, and timeout rate. Remote logs can also be written if necessary.

PHP extensions are designed to ensure high performance and stability. Because the string operation of binary protocol involves a lot of memory copy and allocation, so our initial solution is to use C implementation, but later found that this solution has some shortcomings. Finally, for the sake of performance, PHP extensions were introduced, and the integration of packaging and unpacking with codec was carried out to reduce the number of API calls from PHP. In terms of stability, we do multi-version build tests every time we submit code. Based on our online experience, we also added Valgrind memory test, and the current code test coverage basically reaches 80%.

By comparing the data in the figure above, it is clear that PHP extensions bring benefits.

Apache plus PHP is probably the traditional PHP Server model that most of you are familiar with. Later, with the popularity of Nginx, Nginx plus PHP-FPM has emerged. But then we moved on to Swoole for the benefit of performance, and with Swoole 2.0 came coroutine capabilities.

Our Server includes tars-HTTP-server, tars-timer-Server and Tars-TCP-server. The HTTP Server provides some basic functions, the TIMER Server does some scheduled tasks, and the TCP Server is designed to provide a high-performance RPC service.

When the Server is started, it initializes, parses the configurations delivered by the platform, and registers the service. After that, it reports to the main control every one minute to inform the main control that the Server is alive. If any problem is found, the main control starts the service again. TARS also supports setting up configurations on the platform for distribution to various services, which automatically pull configurations from TARS Config.

TARS TCP Server can use any version of Swoole 1.0 or 2.0, but the PHP version must be above 5.6. It is very flexible in configuration, either delivering Swoole’s configuration to the service via the platform or specifying the service entry. Core implementation is based on the annotation routing, TARS at the time of receipt of a request will receive a package, the package contains the calling service and interface information, Server after know this information will need to use the parameters of the pre-generated ways on the annotation and service when they start parsing really calling these annotations into PHP array. We also provide an administrative port that needs to be launched in addition to receiving other administrative requests from the platform.

We only implemented a relatively simple version of TARS HTTP Server that provides a variety of basic functions, including GET/POST requests, Cookie/Status returns, basic routing, file upload, and Service Detect.

The figure above shows some of the data we obtained from the manometry.

Development efficiency has always been a concern for TARS. From the perspective of development mode, first of all, the Server will agree a protocol to indicate the interface that the service needs to provide and generate a file, namely the TARS file in the figure. The TARS2PHP tool then generates the server interface code and client invocation code from this file. The server then implements the actual business logic based on the interface code, and finally the two sides can be combined. The whole process is decoupled and doesn’t take much time to make client calls.

Here mainly introduces TARS PHP in the application of reading articles. The first is the access layer, which uses Nginx in conjunction with Spartan (TARS in our internal system), which makes it easy to expand seamlessly. To achieve this decoupling, we also introduced TARS Node HTTP, which precipitates all template renderings into the nodeJS layer. Nginx AJAX requests then arrive at the TARS PHP HTTP, and the number of concurrent transactions at this layer would be around 2,000 in a real scenario. The next layer is the microservice layer. We use PHP and JAVA to make some TCP microservices of TARS. Its interaction with HTTP is based on TCP asynchronous plus coroutine scheme.

From the actual data, at present, there are about ten Node HTTP services, more than 40 logical API layer PHP services and timing services, and more than 100 background TCP services, each invocation of more than 100 million levels.

Modular design