CN117221410A

CN117221410A - Remote communication method, device, equipment and medium based on cross-service server architecture

Info

Publication number: CN117221410A
Application number: CN202310998682.9A
Authority: CN
Inventors: 吴天滈
Original assignee: Guangzhou Sanqi Jiyao Network Technology Co ltd
Current assignee: Guangzhou Sanqi Jiyao Network Technology Co ltd
Priority date: 2023-08-08
Filing date: 2023-08-08
Publication date: 2023-12-12

Abstract

The application discloses a remote communication method, a device, equipment and a medium based on a cross-service server architecture, and belongs to the technical field of computer communication. The method comprises the following steps: receiving a service processing request sent by a client; under the condition that the remote call condition is met, a remote server call interface is called, and a cross-service router is selected through an interface agent based on pre-configured cross-service communication information so as to determine a target remote server; and transmitting parameters required by an interface to the target remote server, wherein the parameters are used for the target remote server to process the service processing request based on the parameters required by the interface, and calling an interface to feed back a processing result to the remote server. According to the scheme, the requests are uniformly distributed to different remote servers, so that the resources of each server can be fully utilized, overload of a single server is avoided, the throughput of the system is improved, and cross-platform service processing is realized.

Description

Remote communication method, device, equipment and medium based on cross-service server architecture

Technical Field

The application belongs to the technical field of computer communication, and particularly relates to a remote communication method, device, equipment and medium based on a cross-service server architecture.

Background

Early game servers typically carried a large number of players, and with the rise of multiplayer online games, players scattered across different servers could not interact with each other. To improve the player's social experience, game developers began to employ a single server model, focusing players into a virtual world.

A single server employs a distributed system architecture that divides the server into multiple regions or instances. Each instance is responsible for processing a portion of the players to reduce server load and improve performance, and is capable of processing player requests, calculating game logic, and updating player status in real-time. And can ensure that all players see the same game state in the same virtual world.

However, today, a single server is used to provide services to players, and as the number of players increases, the server may become overloaded, thereby affecting the performance and stability of the game. Meanwhile, if the number of players reaches the upper limit of the server, a new player cannot enter the game, and the experience of the player is affected. Meanwhile, when the server fails, all players are affected. Therefore, how to make a player play a game between different servers, and still ensure that the player can play the game normally when a single server fails, so that the experience of the player is improved, which is a problem to be solved in the art.

Disclosure of Invention

The embodiment of the application provides a remote communication method, a device, equipment and a medium based on a cross-server architecture, and aims to solve the problems that in the prior art, after the number of players reaches the online, new players cannot enter a game and the players cannot play normally when the single server fails due to the limited load of the single server. Through the remote communication method based on the cross-service server architecture, the requests are uniformly distributed to different remote servers, so that the resources of each server can be fully utilized, overload of a single server is avoided, the throughput of the system is improved, and cross-platform service processing is realized.

In a first aspect, an embodiment of the present application provides a method for telecommunication based on a cross-service server architecture, where the method includes:

receiving a service processing request sent by a client;

under the condition that the remote call condition is met, a remote server call interface is called, and a cross-service router is selected through an interface agent based on pre-configured cross-service communication information so as to determine a target remote server;

and transmitting parameters required by an interface to the target remote server, wherein the parameters are used for the target remote server to process the service processing request based on the parameters required by the interface, and calling an interface to feed back a processing result to the remote server.

Further, before transmitting the parameters required by the interface to the target remote server, which are used for the target remote server to process the service processing request based on the parameters required by the interface, and calling an interface to feed back a processing result to the remote server, the method further comprises:

determining a local execution thread according to the local execution logic of the current server, and determining a specified thread to be executed by the target remote server according to the local execution thread;

transmitting parameters required by an interface to the target remote server, wherein the parameters required by the interface are used for the target remote server to process the service processing request based on the parameters required by the interface, and calling an interface feedback processing result to the remote server, and the method comprises the following steps:

and transmitting parameters required by an interface to the target remote server, wherein the parameters are used for the target remote server to process starting and service processing requests based on a specified thread included in the parameters required by the interface, and calling an interface feedback processing result to the remote server.

Further, before receiving the feedback processing result through the remote server call interface, the method further includes:

And setting the local execution thread to be in a congestion state.

Further, the current server and at least one of the remote servers are also connected to a central server;

correspondingly, the method further comprises the steps of:

determining monitoring indexes of a current server and/or at least one remote server based on preset customized monitoring data;

uploading the monitoring index to the central server for the central server to perform early warning according to the monitoring index, and generating an allocation strategy corresponding to the monitoring index when the monitoring index exceeds a normal range so as to reallocate the service processing request.

Further, after receiving the service processing request sent by the client, the method further includes:

determining the state of a pre-established flow limiting queue, and if the flow limiting queue is in an idle state, putting the service processing request into the flow limiting queue to wait for a thread or a thread pool to process the service processing request;

if the current limiting queue is in a busy state, a resubmitted prompt message is fed back to the client, or the service processing request is put into the current limiting queue when the current limiting queue is in an idle state.

Further, before invoking the remote server invocation interface, the method further comprises:

determining the called target server address according to a preset load balancing strategy and server information of an available server;

and sending an interface calling request to a target server according to the target server address.

Further, before the remote server call interface is called, the method further comprises

And acquiring a communication requirement, determining a network transmission protocol according to the communication requirement, and determining a maximum value of protocol transmission data according to the network transmission protocol.

In a second aspect, an embodiment of the present application provides a service architecture device based on cross-service communication, where the device includes:

the service processing request receiving module is used for receiving a service processing request sent by the client;

the interface calling module is used for calling a remote server calling interface under the condition that a remote calling condition is met, and selecting a cross-service router through an interface proxy based on pre-configured cross-service communication information so as to determine a target remote server;

and the parameter transmission module is used for transmitting parameters required by an interface to the target remote server, and is used for the target remote server to process the service processing request based on the parameters required by the interface and call an interface to feed back a processing result to the remote server.

Further, the apparatus further includes a thread determination module configured to:

the parameter transmission module is used for:

Further, the device further comprises a state setting module, wherein the state setting module is used for:

and setting the local execution thread to be in a congestion state.

correspondingly, the device further comprises an allocation policy determining module, wherein the allocation policy determining module is used for:

Further, the device further comprises a current limit queue processing module, wherein the current limit queue processing module is used for:

Further, the device further comprises a load balancing module, wherein the load balancing module is used for:

Further, the device further includes a communication requirement acquisition module, where the communication requirement acquisition module is configured to:

In a third aspect, an embodiment of the present application provides an electronic device, including a processor, a memory, and a program or instruction stored on the memory and executable on the processor, the program or instruction implementing the steps of the method according to the first aspect when executed by the processor.

In a fourth aspect, embodiments of the present application provide a readable storage medium having stored thereon a program or instructions which when executed by a processor perform the steps of the method according to the first aspect.

In a fifth aspect, an embodiment of the present application provides a chip, where the chip includes a processor and a communication interface, where the communication interface is coupled to the processor, and where the processor is configured to execute a program or instructions to implement a method according to the first aspect.

In the embodiment of the application, a service processing request sent by a client is received; under the condition that the remote call condition is met, a remote server call interface is called, and a cross-service router is selected through an interface agent based on pre-configured cross-service communication information so as to determine a target remote server; and transmitting parameters required by an interface to the target remote server, wherein the parameters are used for the target remote server to process the service processing request based on the parameters required by the interface, and calling an interface to feed back a processing result to the remote server. Through the remote communication method based on the cross-service server architecture, the requests are uniformly distributed to different remote servers, so that the resources of each server can be fully utilized, overload of a single server is avoided, the throughput of the system is improved, and cross-platform service processing is realized.

Drawings

Fig. 1 is a flowchart of a telecommunication method based on a cross-service server architecture according to a first embodiment of the present application;

fig. 2 is a flow chart of a telecommunication method based on a cross-service server architecture according to a second embodiment of the present application;

fig. 3 is a flow chart of a telecommunication method based on a cross-service server architecture according to a third embodiment of the present application;

fig. 4 is a schematic diagram of connection between a central server and other servers according to a third embodiment of the present application;

fig. 5 is a flow chart of a telecommunication method based on a cross-service server architecture according to a fourth embodiment of the present application;

fig. 6 is a schematic structural diagram of a service architecture device based on cross-service communication according to a fifth embodiment of the present application;

fig. 7 is a schematic structural diagram of an electronic device according to a sixth embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the following detailed description of specific embodiments of the present application is given with reference to the accompanying drawings. It is to be understood that the specific embodiments described herein are merely illustrative of the application and are not limiting thereof. It should be further noted that, for convenience of description, only some, but not all of the matters related to the present application are shown in the accompanying drawings. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although a flowchart depicts operations (or steps) as a sequential process, many of the operations can be performed in parallel, concurrently, or at the same time. Furthermore, the order of the operations may be rearranged. The process may be terminated when its operations are completed, but may have additional steps not included in the figures. The processes may correspond to methods, functions, procedures, subroutines, and the like.

The technical solutions of the embodiments of the present application will be clearly described below with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which are obtained by a person skilled in the art based on the embodiments of the present application, fall within the scope of protection of the present application.

The terms first, second and the like in the description and in the claims, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged, as appropriate, such that embodiments of the present application may be implemented in sequences other than those illustrated or described herein, and that the objects identified by "first," "second," etc. are generally of a type, and are not limited to the number of objects, such as the first object may be one or more. Furthermore, in the description and claims, "and/or" means at least one of the connected objects, and the character "/", generally means that the associated object is an "or" relationship.

The following describes in detail a remote communication method, device, equipment and medium based on a cross-service server architecture according to the embodiments of the present application through specific embodiments and application scenarios thereof with reference to the accompanying drawings.

Example 1

Fig. 1 is a flowchart of a telecommunication method based on a cross-service server architecture according to an embodiment of the present application. As shown in fig. 1, the method specifically comprises the following steps:

s101, receiving a service processing request sent by a client.

Firstly, the usage scenario of the scheme may be a scenario in which after the current server receives a service processing request sent by a client, the current server selects an appropriate cross-service router based on pre-configured cross-service communication information under the condition that a remote call condition is satisfied, and after the cross-service router determines a target remote server, the service processing request is transmitted to the target remote server.

Based on the above usage scenario, it can be appreciated that the execution subject of the present application may be the current server, which is not limited herein.

In this solution, the current server may refer to a server to which the player or the client is currently connected, which is also referred to as a local server or an origin server. In a multi-server game, the current server may be the actual game server where the player is located, responsible for handling the player's business process requests. When a player sends a service processing request, the request is firstly sent to a current server, then the current server decides whether cross-service communication is needed according to the needs, and an appropriate cross-service router and a target remote server are selected.

The remote server may refer to a different server than the current server, also referred to as a target server. In a cross-service communication system, the remote server may be a target server that receives the service processing request, which is located on another server. Once the current server decides that the request needs to be processed for cross-service communication, it selects the appropriate cross-service router to determine the target remote server and then transmits the request to the target server.

In this embodiment, the client may be a tool for interaction between a player or a user and a game or an application program, and specifically may be an application program running on a computer, a mobile phone, a tablet computer, or other devices.

A business process request may refer to an operation or task issued by a client that requires a server to process. In a multiplayer online game, the business processing request may be a player's movement instruction, an attack instruction, a prop purchase request, and the like.

The player may issue a business process request through the game client, such as clicking a move button in the game or purchasing props. And then the client sends the service processing request to the current server through a wireless communication technology, and the current server can judge whether the remote call condition is met after receiving the service processing request.

S102, calling a remote server call interface under the condition that a remote call condition is met, and selecting a cross-service router through an interface proxy based on pre-configured cross-service communication information so as to determine a target remote server.

The remote call condition may refer to a condition that, after the current server receives a service processing request of a client, it determines whether the request needs to be sent to another remote server for processing. For example, if the business processing request relates to a resource or service which cannot be provided by the current server, the request needs to be sent to other servers for processing, and the remote call condition is considered to be met; if the business processing request needs to access the data or resources on other servers and needs to be sent to a target server with the data or the resources, the remote call condition is considered to be satisfied; a remote call condition is considered satisfied if the business process request requires communication with other servers, such as data synchronization, remote call, etc.

The remote server call interface may refer to an interface for communicating with other remote servers. This interface may be data transfer over a network so that the current server may interact with other servers.

The pre-configured cross-service communication information may refer to related information pre-set in the system for cross-server communication. Specifically, addresses, port numbers, protocol types, and the like of other servers may be included. The network addresses of other remote servers are specified, so that the target server can be accurately positioned during remote call. A network connection and data transfer may be established by specifying a network port number of the target remote server. The protocol types may include HTTP (Hypertext Transfer Protocol ), TCP (Transmission Control Protocol, transmission control protocol), UDP (User Datagram Protocol ), and the like. The TCP network has low cost and can provide larger throughput, but the bottom layer is complex to realize, the analysis work is larger, the HTTP is simpler to use and is easier to access to other platforms, but the HTTP protocol is an upper layer protocol, and the number of bytes occupied by transmission is higher. And UDP is suitable for scenes with low requirements on the reliability of data transmission and high requirements on real-time property. Based on TCP protocol, the current server can establish Socket link with the remote server, and the Socket link is transmitted through data serialization and deserialization, and is mapped to a designated execution interface according to the interface id carried by the data; based on the HTTP protocol, the current server can directly send a request to a remote server, the request modes include get, post, put and delete, and the remote server makes corresponding processing according to different request modes. Where serialization is the process of converting an object into a binary stream and deserialization is the process of converting a binary into an object. Because the cross-service communication exists in different processes, the cross-service communication cannot be transmitted through the memory, the transmission parameters of the calling party need to be converted into byte streams, and the byte streams are converted into corresponding objects when the remote server reads the byte streams. And the local cross-service communication defines the eight basic types, the set and the codec of the custom object, directly converts the byte array into the object, and improves the data conversion efficiency.

The interface agent may be a middle tier for encapsulating and handling remote server calls. Is responsible for forwarding the request of the current server to other remote servers and handling details of some network communications.

The cross-service router may be a component for selecting a target remote server based on pre-configured cross-service communication information. Is responsible for routing the request to the appropriate remote server.

The target remote server may refer to a remote server that is to process the current request according to the cross-service router selection.

The current server receives the service processing request of the client, can query the pre-stored remote call condition and judge whether the remote call condition is satisfied. If so, a remote server call interface can be called, and a proper cross-service router is selected through an interface agent based on pre-configured cross-service communication information. The cross-service router may then select a target remote server based on the communication information.

On the basis of the above technical solutions, optionally, before the remote server call interface is called, the method further includes:

In this scheme, the preset load balancing policy may refer to an algorithm or rule configured in advance for selecting a target server before the system operates, and the algorithm or rule is used for selecting an appropriate server as the target server according to information such as a load condition, a performance index, a network delay and the like of the server, so as to implement load balancing and optimize system performance.

The server information of the available servers may refer to relevant information of all available servers in the current system, and specifically may include addresses, states, load conditions, and the like of the servers.

The target server address may be a network address of a particular server selected according to a load balancing policy for sending the interface call request to the server for execution.

The current server may obtain relevant information of all available servers, and then, according to a preset load balancing policy, the current server may select a target server using a corresponding algorithm or rule. And according to the selected target server, using the network router for directional addressing, and according to the id of the target server, finding out the corresponding call id to obtain the target service address. When the target server address is obtained, the current server may send an interface call request to the target server using the target server address. The Router can be the address pointing of a server in cross-service communication, is specified on a remote interface method, supports customization, can be expanded according to own requirements, and can be specified in the cross-service communication to communicate with any server through the Router. In addition, a default load balancing cluster route can be provided, and a designated server route is selected in the cluster through algorithms such as weight, minimum active number and the like.

In the scheme, the most suitable target server can be selected through the preset load balancing strategy, so that the load balancing of each server is ensured, the system stability is improved, and the system performance is optimized.

On the basis of the above technical solutions, optionally, before the remote server call interface is called, the method further includes

In this solution, the communication requirement may refer to a requirement that the current server needs to determine communication with the target server before performing remote call, and specifically may include a communication manner, a data format, a transmission rate, security, and the like.

The network transmission protocol may refer to rules and conventions used in transmitting data to ensure that the data is properly transmitted and parsed within the network.

The protocol transmission data maximum may refer to a size limitation of a data packet, i.e., a maximum amount of data allowed to be transmitted in the data packet, when a specific network transmission protocol is used.

The current server can acquire the communication requirement according to the requirement and the characteristic of remote call, and select a proper network transmission protocol according to the communication requirement, for example, if the transmission rate is required to be high and the data security is important, an HTTPS protocol can be used; the HTTP protocol may be selected for use if high transmission rates are required and data security requirements are not high. After determining the transmission protocol, the current server may determine a size limit of the data packet, i.e., a protocol transmission data maximum, according to the selected network transmission protocol.

In the scheme, the communication delay can be reduced and the data transmission efficiency and the communication efficiency can be improved by determining the proper network transmission protocol according to the communication requirement and determining the maximum value of the protocol transmission data. By limiting the data volume of single transmission, the transmission error caused by overlarge data packets can be avoided, and the stability of the system is improved.

S103, transmitting parameters required by an interface to the target remote server, wherein the parameters are used for the target remote server to process the service processing request based on the parameters required by the interface, and calling an interface to feed back a processing result to the remote server.

The parameters required for the interface may include a request method, a request parameter, authentication information, a request identification, and an auxiliary parameter. The request method can specify a specific interface method or operation to be called by the remote server; the request parameters may include input data required for calling the interface, for example, may include service data to be processed, a user ID, an operation type, and the like; if identity authentication or authorization is required, authentication information needs to be transferred, and the authentication information can comprise a token, a secret key or other credential information; the request identification may be used to identify a unique ID of the request, tracking the request and processing results. The auxiliary parameters may include a timestamp, version number, etc.

The processing result may be a response result of the target remote server to the request, and may include a response status code, response data, and error information. The response status code may be a status of the remote server processing the request, such as success, failure, error, etc.; the response data may include service data or processing results processed by the remote server, and may be a single data object or a group of data sets; the error information may be a corresponding error information or error code returned for subsequent processing by the client.

After the current server receives the service processing request, the target remote server can be selected according to the pre-configured cross-service communication information. The business processing request is then converted into a format understandable by the target remote server, and the request data is then sent to the target remote server using a network transport protocol. After receiving the request, the target remote server firstly needs to analyze the request data to obtain a request method and parameters, and then calls a corresponding interface to carry out service processing according to the request method and the parameters. After the process is completed, the target remote server may generate response data, including a response status code, response data, and error information, and then send the response data back to the current server via a network transport protocol.

Example two

Fig. 2 is a flow chart of a telecommunication method based on a cross-service server architecture according to a second embodiment of the present application. As shown in fig. 2, the method specifically comprises the following steps:

s201, receiving a service processing request sent by a client.

S202, calling a remote server call interface under the condition that a remote call condition is met, and selecting a cross-service router through an interface agent based on pre-configured cross-service communication information to determine a target remote server.

S203, determining a local execution thread according to the local execution logic of the current server, and determining a specified thread to be executed by the target remote server according to the local execution thread.

The local execution logic may refer to determining, according to the service logic and the requirement of the local server, a service processing operation to be executed after the current server receives a service processing request sent by the client.

The local execution thread may refer to a thread that is responsible for executing local business logic on the current server, and specifically may be a thread in a thread pool or may be a separate thread.

The specified thread may be a thread specified on the target remote server for executing the remote call request, may be a thread in a thread pool, or may be a separate thread.

A thread dispatcher may be defined in the current server for managing and scheduling execution threads of the remote servers and registering remote service interfaces in the line Cheng Fenfa machine, specifying a pool or thread of execution threads for each interface. And after the current server receives the service processing request, selecting a cross-service router according to the pre-configured cross-service communication information and the interface proxy, and determining a target remote server. And then according to the information of the target remote server, acquiring a corresponding executing thread pool or thread from the thread distributor to determine a specified thread which needs to execute business processing operation on the target remote server. And finally, transmitting the business processing request and the required parameters to a target remote server, and designating the acquired execution thread pool or thread to process the request.

S204, transmitting parameters required by an interface to the target remote server, wherein the parameters are used for the target remote server to process starting and service processing requests based on a specified thread included in the parameters required by the interface, and calling an interface feedback processing result to the remote server.

The parameters required by the interface may be encapsulated into a request object. The request object contains all parameter information to be transmitted to the target remote server, and specifically, may include service data, specified thread information, and the like. The remote invocation framework or the communication library is then invoked to send the request object to the target remote server. And the remote call framework selects a proper communication mode to transmit data according to the pre-configured cross-service communication information. When the target remote server receives the request object, the corresponding specified thread can be started to process the request according to the specified thread information contained in the parameters required by the interface. In particular, the remote interface may be invoked using asynchronous requests, asynchronous callbacks, and synchronous callbacks. The asynchronous request can be executed by a calling server in a logic execution thread, calls a remote interface, selects a router, transmits parameters required by the interface, and the remote server receives and executes the parameters in a specified thread. The asynchronous callback can be executed by the calling server in the logic execution thread, the remote interface is called, the router is selected, parameters required by the interface are transmitted, the remote server receives and executes the parameters in the appointed thread, an execution result is generated, the router is selected, and the execution result is returned. The synchronization callback can be executed by the calling server in the logic execution thread, the remote interface is called, the router is selected, parameters required by the interface are transmitted, the remote server receives and executes the parameters in the appointed thread, an execution result is generated, the router is selected, and the execution result is returned. The caller blocks the thread until no data is received. If the remote server is requested to have no response, the request retry can be performed, namely, the corresponding exception is thrown to the calling party and the exception information is carried, for example, the remote server fails to execute after receiving the request, and the calling party can be notified of the reason of the failure in real time.

In this embodiment, by designating threads, tasks may be allocated to different threads for parallel processing, so as to improve the response speed of the system, and avoid resource contention among multiple threads, and avoid the problem of deadlock or inconsistent data caused by contention. Meanwhile, the resource use condition of each thread can be controlled through the appointed thread, and system breakdown caused by the fact that a certain thread occupies too many resources is avoided.

Based on the above technical solutions, optionally, before receiving the feedback processing result through the remote server call interface, the method further includes:

and setting the local execution thread to be in a congestion state.

In this solution, the local execution thread may be a thread executing on the current server, and is responsible for processing the task or the request received by the current server. For example, when a client makes a request, the request is first received for processing by a local thread of execution on one of the servers. The local execution thread decides whether remote call is needed according to the business logic, if so, a target remote server is selected, and an interface call request is transmitted to the target remote server for execution. The local execution thread is responsible for managing the processing of the request, and specifically may include transmitting parameters to the remote server, receiving processing results from the remote server, and so on.

A thread blocking method, such as a sleep function, may be used in a local execution thread to cause the thread to enter a blocked state for a specified period of time, and to suspend execution. The blocking of the thread can also be realized by using a condition variable, and the local execution thread can continue to execute when a certain condition is met, otherwise, the local execution thread enters a blocking state. Blocking of threads may also be accomplished using a wait for notification mechanism. The native thread may wait for a particular event to occur and otherwise enter a blocking state.

In the scheme, the local execution thread is set to be in a congestion state, so that the concurrent processing quantity of tasks can be limited, the system load is prevented from being too high, and the stability and the resource utilization rate of the system are improved.

Example III

Fig. 3 is a flow chart of a telecommunication method based on a cross-service server architecture according to a third embodiment of the present application. As shown in fig. 3, the current server and at least one of the remote servers are further connected to a central server, and specifically includes the following steps:

s301, determining monitoring indexes of a current server and/or at least one remote server based on preset customized monitoring data.

Fig. 4 is a schematic diagram of connection between a central server and other servers according to the third embodiment of the present application, where, as shown in fig. 4, the central server may be a data aggregation and processing center. The method receives the monitoring data from the game server and performs data statistics, analysis and early warning processing. The central server can monitor the running state, performance index, player behavior and other information of the game server by utilizing the data, and further perform optimization adjustment, fault early warning, abnormality detection and other operations on the game server.

The customized monitoring data may include data such as play activity and server bearers. Play liveness may refer to the degree of user engagement and liveness of different plays or game modules in a game. It can be used to measure the popularity of each play in a game. Player liveness may include the number of active users, the number of games, the average length of the game, and revenue contribution, where the number of active users may be the number of independent users participating in a particular play or game module over a specified period of time. The number of games may be a sum of the number of games for a particular play or game module over a specified period of time. The average game duration may be an average game duration of a player in a particular play or game module over a specified period of time. The revenue contribution may be a revenue contribution from a particular play or game module to the game operation.

The monitoring index may be an important data item obtained by counting, calculating or screening the collected customized monitoring data. For example, an average CPU utilization per minute, an online peak value per hour of the player, a daily transaction amount, and the like may be set as the monitor index.

Appropriate monitoring points can be set on the current server and/or the remote server to collect customized monitoring data, and then the index to be monitored is determined according to the service requirement and the monitoring target. The collected customized monitoring data is stored in a database or data storage system for subsequent processing and analysis. And meanwhile, processing and calculating the data according to the set monitoring index to obtain the required monitoring index data.

S302, uploading the monitoring index to the central server for the central server to perform early warning according to the monitoring index, and generating an allocation strategy corresponding to the monitoring index when the monitoring index exceeds a normal range so as to reallocate the service processing request.

Allocation policies may include forwarding requests to other servers in normal states, increasing or decreasing the weight of processing requests, suspending or terminating request transmissions to certain servers, and so forth.

The current server can upload the collected monitoring index data to the central server through a network and the like. After receiving the uploaded monitoring index data, the central server can perform data processing and analysis, and specifically, can perform real-time monitoring on the data or perform batch processing and analysis according to a certain time interval. And then the central server can judge whether the state of the current server and/or the remote server is normal or not according to the processed monitoring index data. If some monitoring indexes exceed a set threshold or a normal range, the server is considered to be abnormal. When the central server determines that the server state is abnormal, a corresponding service request reassignment policy can be generated according to a preset assignment policy, and the generated assignment policy is sent to a relevant server or a scheduling system. The server or the scheduling system reallocates the service request according to the received policy.

In this embodiment, by uploading the monitoring index to the central server, the central server may obtain the monitoring data of the current server and/or at least one remote service in real time, and early warn when the monitoring index exceeds the normal range, so as to avoid the outbreak of serious game problems such as server crash and memory leakage, and meanwhile, the central service may manage and allocate resources of each game service, so as to improve the server utilization rate and fault tolerance.

Example IV

Fig. 5 is a flowchart of a telecommunication method based on a cross-service server architecture according to a fourth embodiment of the present application. As shown in fig. 5, the method specifically comprises the following steps:

s501, receiving a service processing request sent by a client.

S502, determining the state of a pre-created flow limiting queue, and if the flow limiting queue is in an idle state, putting the service processing request into the flow limiting queue to wait for a thread or a thread pool to process the service processing request.

The pre-created flow-restricting queue may be a data structure created in advance during the system start-up or initialization phase for storing traffic handling requests. In the remote server, according to the service requirement, the current limiting weight can be set for the appointed method on the remote interface method, and the remote server can automatically calculate the calling times of the remote method in the heartbeat time according to the weight. The state of the current limit queue may refer to the current busyness of the current limit queue, and may be classified into an idle state and a busyness state.

A current limit queue may be pre-created and set to an idle state during a system start-up or initialization phase. When the current server receives a service processing request sent by a client, firstly judging the state of a pre-established flow limiting queue, and if the flow limiting queue is in an idle state, indicating that not too many service requests are waiting to be processed currently, and putting new service processing requests into the flow limiting queue. When a business processing request is placed in the flow limiting queue, the request enters a waiting state to wait for a thread or thread pool to process.

S503, if the current limit queue is busy, the submitted prompt information is fed back to the client, or the service processing request is put into the current limit queue when the current limit queue is in idle state.

When the current limiting queue is in a busy state, the current server can feed back a resubmitted prompt message to the client to inform the client that the current system is busy, the request is temporarily refused, and the resubmitted request is suggested later. The client can decide whether the request needs to be submitted again according to the prompt information returned by the server. After the prompt information is fed back to the client, the current server can select to wait for the current limiting queue to be in an idle state and then put the service processing request into the current limiting queue. The wait policy may be implemented by setting a wait time during which the state of the current limit queue is checked until the queue becomes idle, and then placing the request in the queue.

S504, calling a remote server call interface under the condition that the remote call condition is met, and selecting a cross-service router through an interface agent based on pre-configured cross-service communication information to determine a target remote server.

S505, transmitting parameters required by an interface to the target remote server, wherein the parameters are used for the target remote server to process the service processing request based on the parameters required by the interface, and calling an interface to feed back a processing result to the remote server.

In this embodiment, by setting the current limiting queue, early warning can be initiated when the peak value of the queue is reached, and under the condition that the maximum length of the queue is exceeded, a request can be discarded or error information can be returned to control the system load, so that overload breakdown of the system due to excessive requests is prevented, and the stability of the system is improved. And by waiting for a thread or thread pool to process a business process request, excessive consumption of system resources due to frequent request submission can be avoided.

Example five

Fig. 6 is a schematic structural diagram of a service architecture device based on cross-service communication according to a fifth embodiment of the present application. As shown in fig. 6, the method specifically includes the following steps:

a service processing request receiving module 601, configured to receive a service processing request sent by a client;

The interface calling module 602 is configured to call a remote server calling interface when a remote calling condition is met, and select a cross-service router through an interface proxy based on pre-configured cross-service communication information, so as to determine a target remote server;

and the parameter transmission module 603 is configured to transmit parameters required by an interface to the target remote server, and configured to allow the target remote server to process the service processing request based on the parameters required by the interface, and call an interface to feed back a processing result to the remote server.

the parameter transmission module is used for:

and setting the local execution thread to be in a congestion state.

In the embodiment of the application, a service processing request receiving module is used for receiving a service processing request sent by a client; the interface calling module is used for calling a remote server calling interface under the condition that a remote calling condition is met, and selecting a cross-service router through an interface proxy based on pre-configured cross-service communication information so as to determine a target remote server; and the parameter transmission module is used for transmitting parameters required by an interface to the target remote server, and is used for the target remote server to process the service processing request based on the parameters required by the interface and call an interface to feed back a processing result to the remote server. Through the service architecture device based on cross-service communication, the requests are uniformly distributed to different remote servers, so that the resources of each server can be fully utilized, overload of a single server is avoided, the throughput of the system is improved, and cross-platform service processing is realized.

The service architecture device based on cross-service communication in the embodiment of the application can be a device, and can also be a component, an integrated circuit or a chip in a terminal. The device may be a mobile electronic device or a non-mobile electronic device. By way of example, the mobile electronic device may be a mobile phone, a tablet computer, a notebook computer, a palm computer, a vehicle-mounted electronic device, a wearable device, an ultra-mobile personal computer (UMPC), a netbook or a Personal Digital Assistant (PDA), and the non-mobile electronic device may be a server, a network attached storage (NetworkAttachedStorage, NAS), a Personal Computer (PC), a Television (TV), a teller machine, a self-service machine, and the like, and the embodiments of the present application are not limited in particular.

The service architecture device based on cross-service communication in the embodiment of the application can be a device with an operating system. The operating system may be an Android operating system, an ios operating system, or other possible operating systems, and the embodiment of the present application is not limited specifically.

The service architecture device based on cross-service communication provided by the embodiment of the application can realize each process realized by each method embodiment, and in order to avoid repetition, the description is omitted here.

Example six

As shown in fig. 7, the embodiment of the present application further provides an electronic device 700, which includes a processor 701, a memory 702, and a program or an instruction stored in the memory 702 and capable of running on the processor 701, where the program or the instruction implements each process of the above-mentioned service architecture device embodiment based on cross-service communication when being executed by the processor 701, and the process can achieve the same technical effects, and for avoiding repetition, a description is omitted herein.

The electronic device in the embodiment of the application includes the mobile electronic device and the non-mobile electronic device.

Example seven

The embodiment of the application also provides a readable storage medium, on which a program or an instruction is stored, which when executed by a processor, implements each process of the above embodiment of the service architecture device based on cross-service communication, and can achieve the same technical effect, so that repetition is avoided, and no further description is given here.

Wherein the processor is a processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium such as a Read-only memory (ROM), a random access memory (RandomAccessMemory, RAM), a magnetic disk or an optical disk, and the like.

Example eight

The embodiment of the application further provides a chip, which comprises a processor and a communication interface, wherein the communication interface is coupled with the processor, and the processor is used for running programs or instructions to realize the processes of the service architecture device embodiment based on cross-service communication, and the same technical effects can be achieved, so that repetition is avoided, and the description is omitted here.

It should be understood that the chips referred to in the embodiments of the present application may also be referred to as system-on-chip chips, chip systems, or system-on-chip chips, etc.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element. Furthermore, it should be noted that the scope of the methods and apparatus in the embodiments of the present application is not limited to performing the functions in the order shown or discussed, but may also include performing the functions in a substantially simultaneous manner or in an opposite order depending on the functions involved, e.g., the described methods may be performed in an order different from that described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a computer software product stored in a storage medium (e.g. ROM/RAM, magnetic disk, optical disk) comprising instructions for causing a terminal (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the method according to the embodiments of the present application.

The embodiments of the present application have been described above with reference to the accompanying drawings, but the present application is not limited to the above-described embodiments, which are merely illustrative and not restrictive, and many forms may be made by those having ordinary skill in the art without departing from the spirit of the present application and the scope of the claims, which are to be protected by the present application.

The foregoing description is only of the preferred embodiments of the application and the technical principles employed. The present application is not limited to the specific embodiments described herein, but is capable of numerous modifications, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the application. Therefore, while the application has been described in connection with the above embodiments, the application is not limited to the embodiments, but may be embodied in many other equivalent forms without departing from the spirit of the application, the scope of which is set forth in the following claims.

Claims

1. A telecommunication method based on a cross-service server architecture, characterized in that the method is performed by a current server, to which at least one remote server is connected; the method comprises the following steps:

receiving a service processing request sent by a client;

2. The cross-server architecture based telecommunication method as claimed in claim 1, wherein before transmitting the parameters required by the interface to the target remote server for the target remote server to process the service processing request based on the parameters required by the interface and invoking the interface to feed back the processing result to the remote server, the method further comprises:

3. The cross-server architecture based telecommunication method of claim 2, wherein prior to receiving feedback processing results through the remote server call interface, the method further comprises:

And setting the local execution thread to be in a congestion state.

4. The method of claim 1, wherein the current server and at least one of the remote servers are further connected to a central server;

correspondingly, the method further comprises the steps of:

5. The method for cross-server architecture based telecommunication according to claim 1, wherein after receiving a service processing request from a client, the method further comprises:

6. The cross-server architecture based telecommunication method of claim 1, wherein prior to invoking the remote server invocation interface, the method further comprises:

7. The method for cross-server architecture based telecommunications of claim 1, wherein prior to invoking the remote server invocation interface, the method further comprises

8. A remote communication device based on a cross-service server architecture, which is characterized in that the device is configured on a current server, and at least one remote server is connected with the current server; the device comprises:

9. An electronic device comprising a processor, a memory and a program or instruction stored on the memory and executable on the processor, which when executed by the processor, implements the steps of the cross-server architecture based telecommunication method as claimed in any one of claims 1 to 7.

10. A readable storage medium, wherein a program or instructions is stored on the readable storage medium, which when executed by a processor, implements the steps of a cross-server architecture based telecommunication method as claimed in any one of claims 1-7.