CN116775343A - PHP-based high-performance Remote Procedure Call (RPC) system and method - Google Patents

Abstract

The application discloses a PHP-based high-performance Remote Procedure Call (RPC) system and a PHP-based high-performance Remote Procedure Call (RPC) method, wherein most programming languages have good and mature solutions, but no wide mature solution and no corresponding solution exist in the PHP languages at present. The distributed system and the micro-service architecture can be rapidly completed by a plurality of old projects or projects of a single architecture. The application uses swoole to carry out network communication and multi-process monitoring in PHP field, RPC agent conceals details such as parameter encapsulation, serialization, reverse serialization, etc., RPC service processes message of multi-process continuous monitoring RPC agent, and converts the message into original request parameter through reverse serialization, then sends service data to RPC agent through reflection calling and serialization, provides service registration discovery center to uniformly manage service, accesses link tracking to make RPC call process of multiple services clear at a glance, and also can use RPC agent to automatically generate service end call interface, further conceals details of parameter encapsulation, serialization, network transmission, and is friendly to the developer.

Description

PHP-based high-performance Remote Procedure Call (RPC) system and method

Technical Field

The application relates to PHP programming language, RPC (remote procedure call) system and method in the computer technical field.

Background

RPC (remote procedure call), communication and collaboration across network boundaries is implemented in a distributed system. In a distributed system, RPC techniques may be used for inter-service communication, cluster management, task scheduling, and the like. RPC technology is an important means of enabling communication between services in a micro-service architecture. Each micro-service can be used as an independent service, and is mutually called through the RPC, so that decoupling flexibility among the services is realized. RPC technology can help build highly scalable, loosely coupled microservice systems. In Web development, RPC technology may be used for communication between a browser and a server. Through the RPC, the browser can initiate a request to the server and acquire a response, so that data interaction and collaboration of front and rear ends are realized. Common Web development frameworks such as gRPC, JSON-RPC, and the like all use RPC technology. In summary, RPC technology has wide application in many fields, particularly in distributed systems, microservice architecture and Web development. The method can help different components, services or nodes to carry out efficient communication and cooperation, and achieves the expandability, flexibility and performance optimization of the system.

In the above field, most programming languages have good and mature solutions, but at present, PHP languages have no wide mature solutions and corresponding solutions, and there are natural disadvantages in RPC call based on TCP/IP protocol request, in PHP, and long connection cannot be maintained, so performance is not advantageous.

With the development of modern applications, more and more business scales of companies are rising, and a single architecture cannot cope with high load, high concurrency and high availability, and then development period is increased, so that iteration is slow. The traffic of any service in the monomer becomes large, which can result in other services not being accessible. The monolithic architecture also results in increased operating and maintenance costs.

Therefore, the current trend is distributed systems and micro-service architecture. Then RPC (remote procedure call) is a necessary approach to accomplish distributed systems and micro-service architecture. PHP wants to complete distributed system and micro-service architecture, RPC development is imperative.

In view of the current trend of PHP RPC development, there are several types of RPC frameworks, but all under their ecology, such as: hyperf frameworks, both server and client must use Hyperf to implement distributed systems and micro-service architectures. This results in the need to reconstruct and migrate the old project, and the development and trial-and-error costs are very high.

Disclosure of Invention

It is an object of the present application to provide a PHP high performance Remote Procedure Call (RPC) framework. The distributed system and the micro-service architecture can be rapidly completed by a plurality of old projects or projects of a single architecture.

The technical scheme of the application is as follows:

1. the method comprises the steps of providing an actual network protocol and asynchronous and synchronous network transmission communication and a multiprocess mode by a network communication technology based on a switch;

2. parameter encapsulation, serialization and anti-serialization, wherein the request parameters of the RPC client are encapsulated and serialized into binary, and are transmitted to the RPC server through a network, and the server performs the anti-serialization of the binary to obtain the client parameters;

the RPC agent provides various calling modes including asynchronous calling and synchronous calling, acquires parameters, calls the parameter packaging and serialization steps, and performs network transmission communication;

the RPC service processing defines a service interface to be exposed to the client, including a service name, a function name, a parameter type, a return value type and the like, establishes and opens network connection, monitors client information by utilizing a multi-process mode, acquires parameters through anti-serialization and acquisition and acquires data through reflection call, and sends the data back to the client through parameter encapsulation and serialization and network communication;

5. service registration and discovery, registration of service, service discovery, service list return, load balancing, remote call, failure processing, monitoring update, service offline;

6. when the RPC calls, a plurality of services can be called mutually, if one service has a problem, the problem is difficult to check. It is necessary to introduce a link tracking function. The RPC client needs to access the link tracking interface at call time, the interface marks this access with a 64-bit ID, and when the a service calls the B service, a 64-bit ID of the a service is regenerated, and so on. After the call is finished, the service which is called once by the RPC client can be checked;

and 7. The RPC agent is generated, the agent can be automatically generated before the RPC client uses the agent, the service interface including service name, function name, parameter type, return value type and the like is automatically packaged into the called agent class, the details of the bottom layer call can be further reduced, and the calling step is simplified.

Drawings

Fig. 1 is a general architecture diagram of the present application.

Fig. 2 is a schematic diagram of an RPC service processing flow.

Fig. 3 is a schematic flow diagram of an RPC agent.

Fig. 4 is a schematic diagram of a parameter encapsulation process.

Fig. 5 and 6 are schematic diagrams of serialization and deserialization processes.

Fig. 7 and 8 are schematic diagrams of service registration and service discovery processes.

Fig. 9 is a schematic diagram of link tracking.

Detailed Description

The following description of the embodiments of the present application will be made in detail and fully with reference to the accompanying drawings, in which it is evident that the processes described are only some, but not all, of the basic embodiments of the present application.

The application provides a PHP-based high-performance Remote Procedure Call (RPC) system and a PHP-based high-performance Remote Procedure Call (RPC) method, wherein the PHP-based high-performance Remote Procedure Call (RPC) system comprises:

in the general architecture diagram of fig. 1, the technical scheme is uniformly packaged into an RPC middleware, the RPC-proxy is an RPC proxy in the diagram, parameters requested by a client are packaged and serialized and sent to a server, meanwhile, data returned by the server is acquired, the anti-serialization is given to the client, the RPC-common in the diagram stores serialization, anti-serialization, a request parameter object and a response object for packaging, the RPC-Handler in the diagram are processed for service, a message of the client is continuously monitored, the request parameter is acquired by anti-serialization after the message is received, the returned data is packaged and serialized again and sent to the client through reflection and calling of an interface exposed by the server, the RPC-register in the diagram is a service registration and discovery center, the interface exposed by the server is registered, and the client discovers service according to service names;

the workflow in the architecture diagram is as follows:

the method comprises the steps that 1, an S1RP client initiates an RPC request through an agent by using a requested service name, a requested class name, a requested function, parameters and a file and an asynchronous callback function;

s2, in the RPC agent, packaging all parameters in the S1 into a Request object;

s3, packaging and serializing the Request object;

s4, searching the service name in the S1 in the RPC-register, and returning an ip address and a port number;

s5, sending the byte stream in S3 to an RPC-handler for processing through the network transmission capability of swoole;

after receiving byte stream, RPC-handler in S6 obtains class name, function, parameter, file and asynchronous callback function of relevant request through anti-serialization in RPC-common;

s9, acquiring the class and function exposed by the server through reflection calling after determining that the class name, the function, the parameter, the file, the asynchronous callback function and the like of the request are legal in S8, and S10 delivering the data requested by the server to the RPC-handler;

s11, the RPC-handler packages the data requested by the server into a response object through the RPC-common, and sequences the response object;

s12, transmitting the data in S11 to the RPC-proxy for processing through the network transmission capability of swoole;

s13, obtaining server data through RPC-common deserialization, and returning the final data to an RPC client by S14;

after the RPC-handler in s7 starts the service, the exposed interface in the RPC-server is registered in the service center for the RPC proxy to query.

The above is a general architecture diagram of the present application, meaning of each module and working schematic, and the workflow in each module will be described below.

Fig. 2 is a process flow of RPC service in the following manner:

1.A1 is started by command;

a2, initializing configuration information, configuring a service end ip address, ports, the number of working processes, service names, whether to open a registry, the ip address of the registry, a registry port, service weights, an exposed service interface, whether to open a hot update, a catalog for hot update detection, log records, log formats and uploading to a log center;

a3, loading a log recorder, and uniformly uploading a starting log, an access record, an error log and an operation log or configuration log record to a log center;

a4, detecting whether to start hot update, if yes, entering a step A5, otherwise, executing a step A6;

a5, starting hot update, starting a new working process, continuously monitoring whether contents such as a detected directory, a file and the like change in A2 initialization, and automatically sending a signal for restarting the service if the contents change;

a6, detecting whether a service registry is started or not by using the A6, if so, entering the step A7, otherwise, entering the step A8;

a7, uploading the information of the service interface, the service name, the service end ip address, the port and the like exposed by the A2 configuration to a registry, and accessing the service every 10 seconds by the registry to ensure the availability of the service;

a8, starting a process according to the number of working processes configured by the A2, continuously monitoring whether a message from a client exists, if yes, entering a step A9, otherwise, entering a step A10;

a9 continuously monitoring the client signal through a dead loop;

a10 receives the message sent by the client, and deserializes the message;

a11 obtains the actual request parameters, and invokes the exposed service interface configured by A2 through reflection calling;

a12, serializing and transmitting the server data acquired in the A11 to the client again;

a13 clears the buffer memory of the call, if the file parameter exists, the buffer memory of the temporary file is cleared.

Fig. 3 is an RPC proxy flow, which is the following:

when initiating an RPC request, B1 gives the service name, the interface of the service and the parameter of the request to a client agent, and calls the client agent through the agent;

b2, initializing configuration information, and configuring overtime time of client agent processing, whether a registry is started, ip addresses of the registry, ports of the registry and service names capable of being requested;

b3 will initiate a request, if it is an asynchronous request, then B4 will be entered, and if it is an asynchronous request, then B5 will be entered;

b4, starting a new sub-process when the asynchronous request is issued, and monitoring a callback function;

b5, detecting whether a registry is opened in the configuration information of the B2 stage, starting to enter the step B7, otherwise, entering the step B6;

b7 will visit the registry to inquire whether the service exists or not, and obtain the ip address and port of a healthy service;

b6, if the registry is not opened, acquiring the ip address and port of the service in the B2 configuration information;

b8, packaging the parameter information of the B1 stage, the ip address and the port of the service into a Request object and serializing the Request object;

b9, recording the request content of B8 to a link tracking center;

b10, sending the data to a server and acquiring a return result;

b11, when experiencing network reasons or other reasons, may cause a result timeout, the timeout goes to B12, otherwise it goes to B13;

b12, returning default error information to obtain other self-defined information to prevent the client from unresponsiveness;

whether B13 is an asynchronous request or a synchronous request in the step B4, wherein the asynchronous request enters the step B14, and the synchronous request enters the step B15;

b14, starting a callback function in the sub-process to receive the requested data;

b15, performing reverse sequence on the returned data to obtain a returned result;

b16 is subject to relevant logic processing by the client.

FIG. 4 is a flow chart of parameter encapsulation, the process flow is as follows:

c1, when initiating RPC request in the stage of FIG. 3B1, delivering the service name, the interface of the service and the parameter of the request to the client agent, and calling through the agent;

c2 gets the service name in C1;

c3 gets the interface of the service in C1;

c4 gets the requested parameters in C1;

5, C5 judging whether the file parameters are included, entering a step C6 when the file parameters are included, and entering a step C7 when the file parameters are not included;

c6, in the file system, reading the binary value of the file, and packaging the binary value into independent file parameters;

c7, judging whether an asynchronous request is started, wherein the asynchronous request enters a step C8, and the synchronous request enters a step C9;

c8, acquiring an asynchronous callback function, converting the callback function into character information, and packaging the character information into an independent callback type;

c9 encapsulates all parameters, file parameters and parameters of the callback function into a Request object;

c10 proceeds to serialize the Request object in C9 into character information.

Fig. 5 and 6 are schematic diagrams of serialization and deserialization, and the process flow is as follows:

serializing:

d1 loading configuration information;

d2 sets the size of the data boundary;

d3, setting a data packet header;

d4, setting a packet body protocol;

5, if the D5 parameter contains the file parameter, entering D6, otherwise entering D7;

converting the file parameters into size, data packet header and packet body protocol with independent data boundaries in each row in D6;

d7 converting all parameters into byte streams which can be transmitted by the network;

the reverse sequence is essentially a serialized reverse operation, restoring the byte stream transmitted by the network to the requested parameters:

e1 loads configuration information;

e2 continuously receives byte stream data in a process through a loop;

e3, converting the byte stream into a reverse sequence into parameters of an original request according to the set packet header and packet header protocol;

4, E4 determines whether the file parameters are contained, and enters the step E5, and no file parameters enter the step E7;

5, reversing the step D6 in FIG. 5 by E5, and splicing the size, the data packet header and the packet body protocol of each row with independent data boundaries into original parameters row by row;

6, in order to facilitate the use of file parameters, E6 can save the binary content of the file into a temporary directory, and convert the file parameters into directory names of the file;

e7 resolves to Request object.

Fig. 7 and 8 are the flows of service registration and service discovery, as follows:

service registration:

f1 loading configuration information;

f2, detecting whether a registry is opened or not through F1 configuration, opening the registry to enter F3, and ending the process after opening;

f3 uploading the exposed service and the ip address and port of the service to a registry;

service discovery:

g1 loads configuration information;

g2, detecting whether to open the registry through G1 configuration, entering G3 after opening, and ending after opening;

g3 obtains the service name from the request;

g4 requests the registry to obtain health services;

g5 obtains healthy service ip address, service port.

The internal structure of the service registration discovery center includes:

1. registration service: the RPC server registers itself to the service discovery center when starting, including the name, address and other metadata information of the service;

2. service discovery: the client sends a service inquiry request to a service discovery center to request the information of a certain specific service;

3. service list return: the service discovery center returns a list of one or more available RPC service instances to the client. These examples contain the network address of each service and other relevant information;

4. load balancing: the client selects a service instance from the service list as a target according to a certain load balancing strategy (such as polling, random and the like);

5. failure processing: if the call fails or times out, the client can choose to retry other available service instances or perform error handling;

6. monitoring and updating: the client may monitor the update information of the service instance by a subscription mechanism or periodically querying the service discovery center, so as to obtain a changed service list in time;

7. service offline: when the RPC server is closed, it will inform the service discovery center to remove itself from the service list; RPC service discovery may be implemented in a variety of ways, including DNS-based service discovery, configuration center-based service discovery, application-specific service registration and discovery tools (e.g., consul, etcd, zooKeeper, etc.), and so forth. These mechanisms are all intended to help clients to find available RPC services conveniently, improving the reliability and scalability of the system.

Link tracking in the solution of fig. 9: the RPC client needs to access the link tracking interface at call time, the interface marks this access with a 64-bit ID, and when the a service calls the B service, a 64-bit ID of the a service is regenerated, and so on. And after the call is finished, checking which services are called once by the RPC client.

While exemplary embodiments of the present application have been described above, it should be understood that the above-described exemplary embodiments are not limiting, but rather illustrative, and the scope of the present application is not limited thereto. It will be appreciated that modifications and variations to the embodiments of the application may be made by those skilled in the art without departing from the spirit and scope of the application, and that such modifications and variations are intended to be within the scope of the application.

Claims (9)

1. PHP-based high performance Remote Procedure Call (RPC) systems and methods, comprising:

in the PHP field, network transport, parameter encapsulation, serialization and de-serialization, RPC proxy, RPC service processing, service registration and discovery, link tracking, RPC proxy generation.

2. The network transmission of claim 1, wherein the method comprises: the swoole network communication provides protocols of TCP/IP and HTTP, and synchronous and asynchronous communication modes and a swoole-based multi-process model. To enable data transfer between the RPC agent of claim 1 and the RPC service process of claim 1, and the RPC service process of claim 1 handles multi-process listening client messages.

3. The parametric package of claim 1, wherein the method: it is required to encapsulate the service name, the interface of the service, the parameters of the Request, and the parameters of the file of the Request in the RPC agent as claimed in claim 1 into a Request object.

4. Serialization and deserialization according to claim 1, characterized in that the method: the method comprises the steps of encapsulating the parameters in claim 1 into a Request object according to the size, the data packet header and the packet body protocol of the data boundary, and converting binary system into information of the size, the data packet header and the packet body protocol with the independent data boundary of each row if the file parameters are needed, and converting the binary system into a byte stream which can be transmitted through a network. The deserialization then converts the byte stream into the original Request object and file parameters.

5. The RPC agent of claim 1, wherein the method is: the call interface generated by the RPC agent of claim 1 can be used, wherein the related logic of network transmission, parameter encapsulation, serialization and deserialization, service discovery, etc. described in claim 1 is hidden, so that Remote Procedure Call (RPC) is simple, uncomplicated and friendly to the developing personnel.

6. The RPC service process according to claim 1, wherein the method: uploading the interface exposed by the service to a service registry, binding a network address (such as an IP address and a port), monitoring the message of the client by using a swoole multiprocessing model when the service is started, obtaining a Request object by deserializing in the claim 1, reflecting the interface exposed by calling, packaging the returned data into a Response object by the parameter encapsulation in the claim 1, converting the sequence into a byte stream by the claim 1, and transmitting the byte stream to the RPC agent in the claim 1 by using the network transmission in the claim 1.

7. The service registration and discovery of claim 1, wherein: in a distributed system, the process of automatically discovering and locating available RPC services as described above. It can help clients find remote services that can be invoked and provide load balancing and high availability. The method comprises the following steps:

(1) Registration service: the RPC service processing registers the exposed interface to a service discovery center when started, and comprises the name, address and other metadata information of the service;

(2) Service discovery: the RPC agent sends a service inquiry request to a service discovery center to request the information of a specific service;

(3) Service list return: the service discovery center returns a list of one or more available RPC service instances to the RPC proxy. These examples contain the network address of each service and other relevant information;

(4) Load balancing: the RPC agent selects a service instance from a service list as a target according to a certain load balancing strategy (such as polling, random and the like);

(5) Failure processing: if the call fails or times out, the RPC agent can choose to retry other available service instances or perform error processing;

(6) Monitoring and updating: the RPC agent may monitor the update information of the service instance by a subscription mechanism or periodically querying a service discovery center, so as to obtain a changed service list in time;

(7) Service offline: when the RPC service process is turned off, it will inform the service discovery center to remove itself from the service list.

8. The link tracking of claim 1, wherein: when RPC calls, multiple services call each other, and if one service has a problem, it is very difficult to check the problem. It is necessary to introduce a link tracking function. The RPC agent needs to access the link trace interface when calling, the interface marks this access with a 64-bit ID, and when the a service calls the B service, a 64-bit ID of the a service is regenerated, and so on. And directly inquiring which services are called by the RPC agent until the call is finished.

9. The RPC agent generation of claim 1. The method is characterized in that: for further development convenience and hiding details, the proxy object is responsible for encapsulating the request, sending to the server, and processing the response results. According to the service interface definition, the agent class can be automatically generated by using a self-contained tool, so that the code writing of the client is simplified.