Terminal cross-machine service processing method and related equipment

Abstract

The invention discloses a terminal cross-machine service processing method and related equipment, and relates to the technical field of terminals.The method comprises the steps that a service request sent by a source terminal is received, and registration information of a corresponding target terminal is obtained from a registration center based on the service request; and based on the registration information of the target terminal, forwarding a service request to the target terminal for processing by the target terminal, receiving processing data correspondingly processed by the target terminal, and forwarding the processing data to the source terminal, and the source terminal and the target terminal do not need to maintain corresponding service discovery logic and service registration information at own nodes. The technical problems that in the prior art, terminal cross-machine service processing is high in cost, stability is difficult to guarantee, and large-scale and dynamic application requirements are difficult to meet are solved.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a terminal cross-device service processing method and related equipment. Background Technology

[0002] Currently, terminal registration and discovery mainly rely on traditional local area network (LAN) networking. While this method can achieve interconnection between terminals to a certain extent, it requires a significant investment of manpower and time for configuration and management. In other words, when handling cross-device services, the current LAN networking method requires each terminal node to maintain the corresponding service (such as business) discovery logic (while also maintaining service registration information). The lack of a unified backend management mechanism leads to high business processing costs and difficulty in ensuring stability, making it difficult to adapt to the needs of large-scale, dynamic applications. Summary of the Invention

[0003] The main purpose of this application is to provide a terminal cross-device service processing method and related equipment, which aims to solve the technical problems in the current technology of terminal cross-device service processing, which is characterized by high cost, difficulty in ensuring stability, and inability to adapt to the needs of large-scale and dynamic applications.

[0004] To achieve the above objectives, this application proposes a terminal cross-device service processing method, applied to cross-device transaction services, the terminal cross-device service processing method comprising: Receive a service request sent by the source terminal, and obtain the registration information of the corresponding target terminal from the registration center based on the service request; Based on the registration information of the target terminal, the service request is forwarded to the target terminal for processing, and the processed data corresponding to the target terminal is received to forward the processed data to the source terminal. Neither the source terminal nor the target terminal needs to maintain the corresponding service discovery logic and service registration information on their own nodes.

[0005] In one embodiment, prior to the step of receiving the service request sent by the source terminal, the procedure includes: The system receives a source terminal connection request distributed by a preset virtual machine F5 based on a load balancing strategy, determines a service instance based on the connection request, establishes a connection channel between the service instance and the source terminal, and receives connection information sent by the source terminal based on the connection channel; wherein, the connection information includes the terminal number and the service SLB IP address; The service instance sends connection information to the registry center, which then registers the connection information so that the registry center can monitor and manage the source terminal through a TCP keep-alive mechanism after the terminal starts up.

[0006] In one embodiment, the step of forwarding the service request to the target terminal includes: Parse the business request to obtain the instruction data corresponding to the business request and the corresponding first data format; The binary object serialization library based on MessagePack performs format conversion on the instruction data of the first data format to obtain instruction data of a unified format. The protocol type of the business request is determined. If the protocol type is HTTP, the HTTP protocol type is converted into TCP or RPC protocol type based on the self-built clientProxy service, and the unified format instruction data corresponding to the business request is sent to the target terminal based on TCP or RPC protocol type.

[0007] In one embodiment, the step of parsing the service request includes: Obtain the instruction type of the business request. The instruction type of the business request is different for different business scenarios. Moreover, the instruction types of different business requests are independent, and modifying the instruction type of any business request will not affect other business requests. Based on the instruction type of the business request, the corresponding strategy mode and template mode are obtained to parse the business request, so as to meet the docking requirements of multiple business requests under different business types. Different business types are set with different templates, and the corresponding instruction format is implemented according to the template.

[0008] In one embodiment, when executing a cross-machine transaction event corresponding to a business request, the corresponding front-end interface is locked and other operations are prohibited. Furthermore, a Redis synchronization lock is used to notify the same target terminal that only one instruction corresponding to a business request of the same type can be executed at the same time.

[0009] In one embodiment, the step of forwarding the service request to the target terminal based on the registration information of the target terminal includes: Based on the registration information of the target terminal, query the registration center for the target terminal's busy / idle status; When the target terminal is not in a busy state, the service request is forwarded to the target terminal. Before the service request is processed, the status of the target terminal is queried from the registration center at preset time intervals. If the target terminal is found to be heartbeat inactive, the corresponding abnormal information is sent to the source terminal. The registration center monitors and manages the health status of the target terminal through a TCP keep-alive mechanism.

[0010] In one embodiment, the source terminal includes different types of terminal devices, including mainframes, card readers, WinPads, and AndroidPads.

[0011] Furthermore, to achieve the above objectives, this application also proposes a terminal cross-device service processing apparatus, which includes: The receiving module is used to receive service requests sent by the source terminal and obtain the registration information of the corresponding target terminal from the registration center based on the service requests. The sending module is used to forward the service request to the target terminal based on the registration information of the target terminal for processing, and to receive the corresponding processed data from the target terminal to forward the processed data to the source terminal. Neither the source terminal nor the target terminal needs to maintain the corresponding service discovery logic and service registration information on their own nodes.

[0012] In addition, to achieve the above objectives, this application also proposes a terminal cross-device service processing device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the terminal cross-device service processing steps as described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of terminal cross-device service processing as described above.

[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of cross-terminal service processing as described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: Compared to related technologies that use local area network (LAN) topology, which requires each terminal node to maintain its own service discovery logic (such as business information) and service registration information when handling cross-machine services, resulting in high processing costs and unstable performance, this application addresses the issue by receiving a business request from a source terminal, obtaining the corresponding target terminal's registration information from a registration center based on the request, forwarding the business request to the target terminal for processing, and receiving the processed data from the target terminal before forwarding it back to the source terminal. Neither the source nor the target terminal needs to maintain its own service discovery logic or service registration information. It is understood that in this application, the end node does not need to maintain the corresponding service (such as business) discovery logic (at the same time, it does not need to maintain the service registration information of its own node). Instead, the cross-machine transaction service uniformly receives business processing requests from different source terminals (the cross-machine transaction service maintains the corresponding service (such as business) discovery logic), and then obtains the registration information of the corresponding target terminal from the registration center based on the business request. In this way, it finds the target terminal corresponding to the business processing request so that the target terminal can perform the corresponding data processing. It is understood that the cross-machine transaction service obtains the registration information of the corresponding target terminal from the registration center. That is, in this application, the registration center uniformly manages the service registration information. After receiving the business processing request through the cross-machine transaction service (the cross-machine transaction service uniformly sets the corresponding service (such as business) discovery logic), it can communicate with the uniformly managed registration center. In this way, it can quickly find the target terminal corresponding to the business request so that it can perform business processing. In this way, it can reduce the business processing cost (it does not need to maintain each terminal) and the stability can be better guaranteed and adaptable to the needs of large-scale and dynamic applications (the unified registration terminal can cope with the needs of large-scale applications). Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a first flowchart illustrating an embodiment of the terminal cross-device service processing method of this application. Figure 2This is a schematic diagram of the system architecture involved in the terminal cross-device service processing method of this application; Figure 3 This is a schematic diagram of the business process involved in Embodiment 1 of the terminal cross-device service processing method of this application; Figure 4 This is a schematic diagram related to registration involved in Embodiment 1 of the terminal cross-device service processing method of this application; Figure 5 This is a schematic diagram of the module structure of the terminal cross-device service processing device according to an embodiment of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the terminal cross-device service processing method in the embodiments of this application; Figure 7 This is a schematic diagram of the protocol conversion involved in the terminal cross-device service processing method in the embodiments of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] The main solution of this application embodiment is: applied to cross-machine transaction services, the terminal cross-machine business processing method includes: Receive a service request sent by the source terminal, and obtain the registration information of the corresponding target terminal from the registration center based on the service request; Based on the registration information of the target terminal, the service request is forwarded to the target terminal for processing, and the processed data corresponding to the target terminal is received to forward the processed data to the source terminal. Neither the source terminal nor the target terminal needs to maintain the corresponding service discovery logic and service registration information on their own nodes.

[0023] Compared to related technologies that use local area network (LAN) topology, which requires each terminal node to maintain its own service discovery logic (such as business information) and service registration information when handling cross-machine services, resulting in high processing costs and unstable performance, this application addresses the issue by receiving a business request from a source terminal, obtaining the corresponding target terminal's registration information from a registration center based on the request, forwarding the business request to the target terminal for processing, and receiving the processed data from the target terminal before forwarding it back to the source terminal. Neither the source nor the target terminal needs to maintain its own service discovery logic or service registration information. It is understood that in this application, the end node does not need to maintain the corresponding service (such as business) discovery logic (at the same time, it does not need to maintain the service registration information of its own node). Instead, the cross-machine transaction service uniformly receives business processing requests from different source terminals (the cross-machine transaction service maintains the corresponding service (such as business) discovery logic), and then obtains the registration information of the corresponding target terminal from the registration center based on the business request. In this way, it finds the target terminal corresponding to the business processing request so that the target terminal can perform the corresponding data processing. It is understood that the cross-machine transaction service obtains the registration information of the corresponding target terminal from the registration center. That is, in this application, the registration center uniformly manages the service registration information. After receiving the business processing request through the cross-machine transaction service (the cross-machine transaction service uniformly sets the corresponding service (such as business) discovery logic), it can communicate with the uniformly managed registration center. In this way, it can quickly find the target terminal corresponding to the business request so that it can perform business processing. In this way, it can reduce the business processing cost (it does not need to maintain each terminal) and the stability can be better guaranteed and adaptable to the needs of large-scale and dynamic applications (the unified registration terminal can cope with the needs of large-scale applications).

[0024] It should be noted that the executing entity in this embodiment can be a computing service device with terminal cross-device service processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or terminal cross-device service processing device capable of implementing the above functions. The following description uses a terminal cross-device service processing device as an example to illustrate this embodiment and the subsequent embodiments.

[0025] Based on this, embodiments of this application provide a terminal cross-device service processing method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the terminal cross-device service processing method of this application.

[0026] In this embodiment, applied to cross-machine transaction services, the terminal cross-machine service processing method includes steps S10~S20: Step S10: Receive a service request sent by the source terminal, and obtain the registration information of the corresponding target terminal from the registration center based on the service request; It should be noted that the executing entity in this embodiment is a terminal cross-device service processing device, which belongs to the cross-device transaction service. Specifically, this cross-device transaction service can be connected to a registration center, such as... Figure 2 As shown in the business process diagram, the cross-machine transaction service also communicates with different terminals.

[0027] In this embodiment, the overall architecture of the cross-machine transaction service and the registration center, etc., is as follows: Figure 3 As shown.

[0028] That is, in this embodiment, the overall architecture includes a terminal entity layer, which includes a source terminal and a target terminal. The source terminal includes different types of terminal devices, such as mainframes, card readers, WinPads, and AndroidPads.

[0029] It should be noted that the target terminal can also be different types of terminal devices, including mainframes, card readers, WinPads, and AndroidPads.

[0030] In this embodiment, the overall architecture also includes a network layer, which includes SLB (Server Load Balancing) and F5 (Load Balance). That is, the terminal entity layer communicates with the cloud service layer through different server load balancing strategies or load balancing routes in the network layer.

[0031] In this embodiment, the cloud service layer includes a registration center and cross-machine transaction services.

[0032] In this embodiment, the registration center is used to perform real-time health monitoring on the terminal entity layer, wherein the real-time health monitoring includes heartbeat monitoring and operation status monitoring.

[0033] In this embodiment, the cross-machine transaction service is used for forwarding or transmitting instruction data. The instruction parsing engine in the cross-machine transaction service can perform standardized parsing of instructions according to the instruction template.

[0034] In this embodiment, a specific application scenario may be: First, currently, terminal registration and discovery mainly rely on traditional local area network (LAN) networking. While this method can achieve interconnection between terminals to a certain extent, it requires a significant investment of manpower and time for configuration and management. In other words, the current LAN networking method, when handling cross-device services, requires each terminal node to maintain the corresponding service (such as business) discovery logic (while also maintaining service registration information). The lack of a unified backend management mechanism leads to high business processing costs and difficulty in ensuring stability, making it difficult to adapt to the needs of large-scale, dynamic applications.

[0035] Secondly, in practical applications, different types of terminal devices (such as mainframes, card readers, WinPads, AndroidPads, etc.) employ different communication protocols, such as HTTP and TCP communication. This diversity of communication methods poses significant challenges to system compatibility, reducing system scalability and the consistency of user experience. Third, in business scenarios involving multiple terminal collaborations, the current device has shortcomings in the rapid transmission of transaction instructions and the handling of anomalies. For example, the card issuance business involves multiple nodes (business end, terminal entity, backend service, etc.), and the transmission environment between each node is complex, which can easily lead to transaction interruptions or delays, affecting user experience and business processing efficiency. Fourth, the current transaction process is inefficient and unstable: the current cross-machine transaction process lacks a sound exception handling mechanism, which makes it difficult to cope with various abnormal situations in complex transmission environments, resulting in unstable transaction processes and poor user experience. Fifth, the development and maintenance of cross-machine transaction functions currently require a large amount of manpower, especially when the business expands, it is necessary to carry out complex adaptation development for different machine models and business scenarios, which increases development costs and maintenance burden; Sixth, low resource utilization: The current deployment and resource management of cross-machine transaction functions are relatively decentralized, making it difficult to achieve efficient resource utilization and unified management, resulting in resource waste and low operation and maintenance efficiency.

[0036] In this embodiment, to solve one or more of the above problems, a terminal cross-device service processing method is proposed. Specifically, the terminal cross-device service processing device first receives a service request sent by the source terminal. The service request may be a card opening service request or a loan service request, etc., and is not specifically limited.

[0037] In this embodiment, specifically, the terminal cross-device service processing device may first receive the service request sent by the source terminal in the following ways: Method 1: Cross-machine transaction service instances receive business requests sent by the source terminal based on different transmission protocols. The specific transmission protocol can be HTTP or TCP, etc., without any limitation. Method 2: The service instance of cross-machine transaction service receives service requests sent by the source terminal based on different transmission paths, where the transmission path includes the transmission path of the constructed long connection or the transmission path of the constructed short connection. Method 3: The service instance of the cross-machine transaction service receives the service request sent by the source terminal based on the principle of proximity.

[0038] In other words, in this embodiment, it should be noted that the cross-machine transaction service is composed of multiple instances (such as multiple server-side instances), and the cross-machine transaction service can be deployed in different regions.

[0039] In this embodiment, if the cross-machine transaction service detects a service request, it first determines the address of the source terminal corresponding to the service request, and then processes the service request according to the nearest cross-machine transaction service instance corresponding to the address of the source terminal. This avoids resource waste caused by transmission.

[0040] In this embodiment, after receiving a service request sent by the source terminal, the service instance of the cross-machine transaction service obtains the registration information of the corresponding target terminal from the registration center based on the service request. That is, in this embodiment, before the source terminal sends the service request, each terminal (including the target terminal) has already registered in the registration center.

[0041] In this embodiment, each terminal can register with the registration center based on its terminal number and service SLB IP, and the registration center will monitor and manage it uniformly.

[0042] In this embodiment, each terminal can register with the registration center based on its terminal number and service SLB IP address in the following ways: Method 1: The registration function of each terminal is completely offloaded to the cloud service layer. That is, each terminal only needs to establish a connection channel with the cross-machine transaction service. The cross-machine transaction service registers the connection information (terminal number and service SLB IP) with the registration center, which then monitors and manages it uniformly (heartbeat keep-alive with the registration center). Method 2: During the registration phase, each terminal still applies for registration directly to the registration center, which then monitors and manages the terminals (by maintaining a heartbeat connection with the registration center).

[0043] In this embodiment, before the step of receiving the service request sent by the source terminal, the following steps are included: Step S01: Receive a source terminal connection request distributed by a preset virtual machine F5 based on a load balancing strategy; determine a service instance based on the connection request; establish a connection channel between the service instance and the source terminal; and receive connection information sent by the source terminal based on the connection channel; wherein, the connection information includes the terminal number and the service SLB IP address; In this embodiment, as Figure 4 As shown, after the source terminal or target terminal starts, the cross-machine transaction service receives the source terminal connection request distributed by the preset virtual machine F5 based on the load balancing strategy. That is, in this embodiment, the request is distributed through the load balancing strategy. Then, the service instance of the cross-machine transaction service receives the source terminal connection request. Based on the service instance, a connection channel is established with the source terminal, and the connection information sent by the source terminal is received based on the connection channel. The connection information includes the terminal number and the service SLB IP address. That is, in this embodiment, the source terminal establishes a long connection with the cross-machine transaction service, and the connection information sent by the source terminal is received based on the connection channel of the long connection.

[0044] That is, such as Figure 4 As shown, terminals 1, 2, and N are distributed to service instances of the cross-machine transaction service via long connections through a load balancing strategy. Then, the service instances of the cross-machine transaction service register the corresponding terminal number and service SLB IP address with the registration center.

[0045] Step S02: Based on the service instance, the connection information is sent to the registration center so that the registration center can register the connection information and monitor and manage the source terminal through the TCP keep-alive mechanism after the terminal is started.

[0046] In this real-time event, the service instance sends connection information to the registration center. Specifically, the service instance sends the terminal number and the connected service instance SLAB IP to the registration center via a short HTTP connection for registration.

[0047] In this embodiment, it should be noted that there can be different instances of the registry center. The service instance sends the connection information to the nearest registry center instance to avoid wasting resources.

[0048] In this embodiment, it should be noted that the registry center may have a management instance for managing the registry center instance. That is, the registry center is extracted with a management instance to avoid confusion in the registry center.

[0049] In this embodiment, the cross-machine transaction service also has a corresponding management instance for managing the cross-machine transaction service instance. That is, the cross-machine transaction service is extracted with a management instance to avoid confusion in the cross-machine transaction service.

[0050] In this embodiment, after the connection information is sent to the registration center based on the service instance, the registration center registers the connection information so that the registration center can monitor and manage the source terminal through the TCP keep-alive mechanism after the terminal is started.

[0051] In this embodiment, the registration center may send information to the registered terminals every 20 seconds after the terminal is started to ensure that the corresponding terminal is in a healthy state.

[0052] In this embodiment, the terminal directly requests the cross-machine transaction service. The cross-machine transaction service obtains the target terminal's registration information from the registry center and then transmits the instruction data to the service instance connected to the target terminal. In this mode, the target terminal does not need to maintain service discovery logic and service registration information on its own node.

[0053] Step S20: Based on the registration information of the target terminal, the service request is forwarded to the target terminal for processing, and the processed data corresponding to the target terminal is received, so as to forward the processed data to the source terminal. Neither the source terminal nor the target terminal needs to maintain the corresponding service discovery logic and service registration information on their own nodes.

[0054] In this embodiment, the service instance of the cross-machine transaction service forwards the service request to the target terminal based on the registration information of the target terminal, so that the target terminal can process it, and receives the corresponding processed data from the target terminal, so as to forward the processed data to the source terminal. Neither the source terminal nor the target terminal needs to maintain the corresponding service discovery logic and service registration information on their own nodes.

[0055] In this embodiment, the service instance of the cross-machine transaction service determines the specific target terminal based on the registration information of the target terminal, forwards the service request to the target terminal (which may involve a first protocol conversion) for the target terminal to process, and receives the corresponding processed data from the target terminal to forward the processed data to the source terminal (which may involve a second protocol conversion).

[0056] In this embodiment, the step of forwarding the service request to the target terminal based on the registration information of the target terminal includes: Step S21: Based on the registration information of the target terminal, query the registration center for the busy / idle status of the target terminal; In this embodiment, the registration information of the target terminal is used to query the registration center for the target terminal's busy / idle status, where busy / idle status includes either a busy state or an idle state.

[0057] Step S22: When the target terminal is not in a busy state, the service request is forwarded to the target terminal. Before the service request is processed, the status of the target terminal is queried from the registration center at preset time intervals. If the heartbeat of the target terminal is found to be inactive, the corresponding abnormal information is sent to the source terminal. The registration center monitors and manages the health status of the target terminal through a TCP keep-alive mechanism.

[0058] In this embodiment, when the target terminal is not in a busy state, the service request is forwarded to the target terminal and will not be processed until the service request is completed. However, if the target terminal is in a busy state, the service request will not be forwarded to the target terminal temporarily to avoid the crash of the corresponding instance service.

[0059] In this embodiment, it should be noted that before the service request is processed, the status of the target terminal is queried from the registration center at preset time intervals. If the heartbeat of the target terminal is found to be inactive, the corresponding abnormal information is sent to the source terminal (to avoid the source terminal from waiting for the processing of the corresponding service request indefinitely).

[0060] In other words, in this embodiment, there is a complete exception handling mechanism in the current cross-machine transaction process to deal with various abnormal situations in the complex transmission environment, which may lead to unstable transaction process and poor user experience.

[0061] In other words, in this embodiment, by monitoring and managing the health status of the target terminal through the registration center, various abnormal situations can be avoided.

[0062] In other words, in this embodiment, it should be noted that neither the source terminal nor the target terminal needs to maintain the corresponding service discovery logic and service registration information on their own nodes. That is, the service discovery logic is maintained by the cross-machine transaction service, and the service registration information is maintained by the registration center.

[0063] Compared to related technologies that use local area network (LAN) topology, which requires each terminal node to maintain its own service discovery logic (such as business information) and service registration information when handling cross-machine services, resulting in high processing costs and unstable performance, this application addresses the issue by receiving a business request from a source terminal, obtaining the corresponding target terminal's registration information from a registration center based on the request, forwarding the business request to the target terminal for processing, and receiving the processed data from the target terminal before forwarding it back to the source terminal. Neither the source nor the target terminal needs to maintain its own service discovery logic or service registration information. It is understood that in this application, the end node does not need to maintain the corresponding service (such as business) discovery logic (at the same time, it does not need to maintain the service registration information of its own node). Instead, the cross-machine transaction service uniformly receives business processing requests from different source terminals (the cross-machine transaction service maintains the corresponding service (such as business) discovery logic), and then obtains the registration information of the corresponding target terminal from the registration center based on the business request. In this way, it finds the target terminal corresponding to the business processing request so that the target terminal can perform the corresponding data processing. It is understood that the cross-machine transaction service obtains the registration information of the corresponding target terminal from the registration center. That is, in this application, the registration center uniformly manages the service registration information. After receiving the business processing request through the cross-machine transaction service (the cross-machine transaction service uniformly sets the corresponding service (such as business) discovery logic), it can communicate with the uniformly managed registration center. In this way, it can quickly find the target terminal corresponding to the business request so that it can perform business processing. In this way, it can reduce the business processing cost (it does not need to maintain each terminal) and the stability can be better guaranteed and adaptable to the needs of large-scale and dynamic applications (the unified registration terminal can cope with the needs of large-scale applications).

[0064] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Based on this, the step of forwarding the service request to the target terminal includes: Step A1: Parse the service request to obtain the instruction data corresponding to the service request and the corresponding first data format; In this embodiment, after receiving a business request, the cross-machine transaction service needs to first parse the business request, and then obtain the instruction data corresponding to the business request and the corresponding first data format.

[0065] The cross-machine transaction service can parse the business request in the following ways: Method 1: Parse the service request according to the parsing message method.

[0066] Method 2: The step of parsing the business request includes: Step B1: Obtain the instruction type of the business request. The instruction type of the business request is different for different business scenarios. Moreover, the instruction types of different business requests are independent, and modifying the instruction type of any business request will not affect other business requests. Step B2: Based on the instruction type of the business request, obtain the corresponding strategy mode and template mode to parse the business request, so as to meet the docking requirements of multiple business requests under different business types. Different business types are set with different templates, and the corresponding instruction format is implemented according to the template.

[0067] In this embodiment, based on the instruction type of the business request, the corresponding strategy mode and template mode are obtained to parse the business request, so as to meet the docking requirements of multiple business requests under different business types. Different business types correspond to different templates, and the corresponding instruction formats are implemented according to the templates. That is, in this embodiment, the strategy mode and template mode are used to uniformly manage and parse instructions to cope with the access requirements of multiple instructions under various business types, achieving flexible and ever-changing business instruction docking and reducing development and change costs.

[0068] Specifically, in this embodiment, the standardized instruction parsing (parsing the business request according to the strategy pattern and template pattern) can be performed in the following ways: Parsing the business request or standardized instruction format using the strategy pattern can be as follows: Based on the business scenario, the instructions are divided into two categories: INSTRUC (general business) and REMOTE (remote maintenance) to ensure that different business instructions are independent and that modifying one type of instruction will not affect other businesses.

[0069] Parsing the business request using a template pattern or a standardized template pattern instruction format can be: Different instruction templates (such as HANDREQ, CARDACT, etc.) are set according to the business type. Each business subtype implements the instruction format according to the template to ensure that the sub-class instructions are independent and that modifications do not affect other sub-classes.

[0070] Based on the instruction type of the business request, the corresponding strategy mode and template mode are obtained to parse the business request, so as to meet the docking requirements of multiple business requests under different business types, improve the flexibility and maintainability of instruction management, reduce development costs, and maintain the stability and compatibility of the device.

[0071] Specifically, if the business request is a card application, the strategy mode and template mode of the business request are obtained. The strategy mode is a general business mode. Based on the template mode corresponding to the general business mode, the business request is parsed. Specifically, according to the HANDREQ instruction template, the data in the business request is filled in in a targeted manner to obtain the instruction data corresponding to the business request and the corresponding first data format; this facilitates the subsequent forwarding and integration of instructions.

[0072] In this embodiment, the data format can be a structured data format or an unstructured data format.

[0073] Step A2: Based on the MessagePack binary object serialization library, the instruction data in the first data format is converted to obtain instruction data in a unified format. Step A3: Determine the protocol type of the business request. If the protocol type is HTTP, convert the HTTP protocol type into TCP or RPC protocol type based on the self-built clientProxy service, and send the unified format instruction data corresponding to the business request to the target terminal based on the TCP or RPC protocol type.

[0074] In this embodiment, it should be noted that many business processes are long and involve multiple nodes such as the business end, terminal entity, and backend service. The transmission environment between each node is different, and some transmission environments are complex. Therefore, in this embodiment, different data transmission methods can be selected according to the communication environment between each node to ensure fast and stable cross-machine forwarding.

[0075] In this embodiment, the instruction data of the first data format is also converted based on the MessagePack binary object serialization library to obtain instruction data of a unified format: In other words, since different terminal applications use different development languages ​​and communication methods, this embodiment uses MessagePack's binary object serialization library to define a unified data format and solve the cross-language data alignment problem.

[0076] In this embodiment, the binary object serialization library based on MessagePack is used to convert the instruction data of the first data format to obtain instruction data of a unified format. Based on this, this embodiment not only realizes cross-language communication, but also reduces network resource consumption and speeds up network transmission rate by using instruction data of a unified format (which reduces the size of data objects compared with the commonly used JSON data format).

[0077] In this embodiment, the HTTP request is converted into a TCP transmission, overcoming the container platform's limitation on short HTTP connections and achieving cross-machine transaction service compatibility with clients of multiple machine types and operating systems. This design maintains the consistency of external communication of the service, avoids excessive coupling with the client, and focuses on the efficient processing of cross-machine transaction business.

[0078] That is, such as Figure 7 As shown, in this embodiment, the protocol type of the service request is determined. If the protocol type is HTTP, the HTTP protocol type is converted into TCP or RPC protocol type based on the self-built clientProxy service, and the unified format instruction data corresponding to the service request is sent to the target terminal based on TCP or RPC protocol type.

[0079] In other words, in this embodiment, communication uses TCP / IP-based RPC service instead of HTTP, reducing message encapsulation and improving communication speed.

[0080] In this embodiment, the service request is parsed to obtain the corresponding instruction data and the corresponding first data format. Based on the MessagePack binary object serialization library, the instruction data in the first data format is converted to a unified format instruction data. The protocol type of the service request is determined. If the protocol type is HTTP, the HTTP protocol type is converted to TCP or RPC protocol type using a self-built clientProxy service. The unified format instruction data corresponding to the service request is then sent to the target terminal based on the TCP or RPC protocol type. This maintains the consistency of external service communication, avoids excessive coupling with the client, and focuses on the efficient processing of cross-machine transaction services.

[0081] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. On this basis, when executing the cross-machine transaction event corresponding to the business request, the corresponding front-end interface is locked and other operations are prohibited. Moreover, a Redis synchronization lock is used to notify the same target terminal that only one instruction corresponding to the same type of business request can be executed at the same time.

[0082] In this embodiment, the cross-machine transaction service also provides a stable and independent transaction process control mechanism, specifically: a transaction locking mechanism. In other words, the cross-machine transaction service provides a visual counter. The terminal corresponding to the visual counter adopts the observer mode. In the observer mode, the terminal can observe cross-machine transaction events and lock the corresponding front-end interface to prevent other operations and ensure that cross-machine transactions are executed first. The server uses Redis synchronization locks to ensure that only one instruction of the same type is executed at the same time for the same target terminal.

[0083] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the cross-device service processing of the terminal in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0084] This application also provides a terminal cross-device service processing device, please refer to... Figure 5 The terminal cross-device service processing device includes: The receiving module 10 is used to receive a service request sent by the source terminal and obtain the registration information of the corresponding target terminal from the registration center based on the service request. The sending module 20 is used to send communication data corresponding to the service request to the target terminal based on the registration information of the target terminal, so that the target terminal can process it, and to receive the corresponding processed data from the target terminal so as to forward the processed data to the source terminal. Neither the source terminal nor the target terminal needs to maintain the corresponding service discovery logic and service registration information on their own nodes.

[0085] In one embodiment, the terminal cross-device service processing device is used to implement: The system receives a source terminal connection request distributed by a preset virtual machine F5 based on a load balancing strategy, determines a service instance based on the connection request, establishes a connection channel between the service instance and the source terminal, and receives connection information sent by the source terminal based on the connection channel; wherein, the connection information includes the terminal number and the service SLB IP address; The service instance sends connection information to the registry center, which then registers the connection information so that the registry center can monitor and manage the source terminal through a TCP keep-alive mechanism after the terminal starts up.

[0086] In one embodiment, the terminal cross-device service processing device is used to implement: Parse the business request to obtain the instruction data corresponding to the business request and the corresponding first data format; The binary object serialization library based on MessagePack performs format conversion on the instruction data of the first data format to obtain instruction data of a unified format. The protocol type of the business request is determined. If the protocol type is HTTP, the HTTP protocol type is converted into TCP or RPC protocol type based on the self-built clientProxy service, and the unified format instruction data corresponding to the business request is sent to the target terminal based on TCP or RPC protocol type.

[0087] In one embodiment, the terminal cross-device service processing device is used to implement: Obtain the instruction type of the business request. The instruction type of the business request is different for different business scenarios. Moreover, the instruction types of different business requests are independent, and modifying the instruction type of any business request will not affect other business requests. Based on the instruction type of the business request, the corresponding strategy mode and template mode are obtained to parse the business request, so as to meet the docking requirements of multiple business requests under different business types. Different business types are set with different templates, and the corresponding instruction format is implemented according to the template.

[0088] In one embodiment, when executing a cross-machine transaction event corresponding to a business request, the corresponding front-end interface is locked and other operations are prohibited. Furthermore, a Redis synchronization lock is used to notify the same target terminal that only one instruction corresponding to a business request of the same type can be executed at the same time.

[0089] In one embodiment, the terminal cross-device service processing device is used to implement: Based on the registration information of the target terminal, query the registration center for the target terminal's busy / idle status; When the target terminal is not in a busy state, the service request is forwarded to the target terminal. Before the service request is processed, the status of the target terminal is queried from the registration center at preset time intervals. If the target terminal is found to be heartbeat inactive, the corresponding abnormal information is sent to the source terminal. The registration center monitors and manages the health status of the target terminal through a TCP keep-alive mechanism.

[0090] In one embodiment, the source terminal includes different types of terminal devices, including mainframes, card readers, WinPads, and AndroidPads.

[0091] The terminal cross-device service processing apparatus provided in this application, employing the terminal cross-device service processing method in the above embodiments, can solve the technical problems of terminal cross-device service processing apparatus. Compared with the prior art, the beneficial effects of the terminal cross-device service processing apparatus provided in this application are the same as the beneficial effects of the terminal cross-device service processing method provided in the above embodiments, and other technical features in the terminal cross-device service processing apparatus are the same as the features disclosed in the methods of the above embodiments, and will not be repeated here.

[0092] This application provides a terminal cross-device service processing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the terminal cross-device service processing method in the above embodiment 1.

[0093] The following is for reference. Figure 6 The diagram illustrates a structural schematic of a terminal cross-device service processing device suitable for implementing embodiments of this application. The terminal cross-device service processing device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, tablets, digital broadcast receivers, PDAs (Personal Digital Assistants), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The terminal cross-device service processing device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0094] like Figure 6As shown, the terminal cross-device service processing device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the terminal cross-device service processing device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the terminal cross-device service processing equipment to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows terminal cross-device service processing equipment with various systems, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0095] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0096] The terminal cross-device service processing device provided in this application, employing the terminal cross-device service processing method in the above embodiments, can solve the technical problems. Compared with the prior art, the beneficial effects of the terminal cross-device service processing device provided in this application are the same as the beneficial effects of the terminal cross-device service processing method provided in the above embodiments, and other technical features in this terminal cross-device service processing device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0097] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0098] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0099] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the terminal cross-device service processing method in the above embodiments.

[0100] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0101] The aforementioned computer-readable storage medium may be included in the terminal cross-device service processing device; or it may exist independently and not be assembled into the terminal cross-device service processing device.

[0102] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the terminal cross-device service processing device, the terminal cross-device service processing device: collects access information from different application sources through an access collection program and stores the access information in a message queue, wherein the access collection program is deployed in the runtime environment of the application; performs service call dependency deduction on the access information in the message queue to obtain the call relationship between the different applications, and generates an application topology architecture based on the call relationship.

[0103] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0104] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0105] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0106] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described terminal cross-device service processing method, thereby solving the technical problem of terminal cross-device service processing. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the terminal cross-device service processing method provided in the above embodiments, and will not be repeated here.

[0107] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the terminal cross-device service processing method described above.

[0108] The computer program product provided in this application can solve the technical problem of cross-terminal service processing. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the cross-terminal service processing method provided in the above embodiments, and will not be repeated here.

[0109] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A terminal cross-device service processing method, characterized in that, Applied to cross-machine transaction services, the terminal cross-machine business processing method includes: Receive a service request sent by the source terminal, and obtain the registration information of the corresponding target terminal from the registration center based on the service request; Based on the registration information of the target terminal, the service request is forwarded to the target terminal for processing, and the processed data corresponding to the target terminal is received to forward the processed data to the source terminal. Neither the source terminal nor the target terminal needs to maintain the corresponding service discovery logic and service registration information on their own nodes.

2. The terminal cross-device service processing method as described in claim 1, characterized in that, Before the step of receiving the service request sent by the source terminal, the following steps are included: The system receives a source terminal connection request distributed by a preset virtual machine F5 based on a load balancing strategy, determines a service instance based on the connection request, establishes a connection channel between the service instance and the source terminal, and receives connection information sent by the source terminal based on the connection channel; wherein, the connection information includes the terminal number and the service SLB IP address; The service instance sends connection information to the registry center, which then registers the connection information so that the registry center can monitor and manage the source terminal through a TCP keep-alive mechanism after the terminal starts up.

3. The terminal cross-device service processing method as described in claim 1, characterized in that, The step of forwarding the service request to the target terminal includes: Parse the business request to obtain the instruction data corresponding to the business request and the corresponding first data format; The binary object serialization library based on MessagePack performs format conversion on the instruction data of the first data format to obtain instruction data of a unified format. The protocol type of the business request is determined. If the protocol type is HTTP, the HTTP protocol type is converted into TCP or RPC protocol type based on the self-built clientProxy service, and the unified format instruction data corresponding to the business request is sent to the target terminal based on TCP or RPC protocol type.

4. The terminal cross-device service processing method as described in claim 3, characterized in that, The step of parsing the service request includes: Obtain the instruction type of the business request. The instruction type of the business request is different for different business scenarios. Moreover, the instruction types of different business requests are independent, and modifying the instruction type of any business request will not affect other business requests. Based on the instruction type of the business request, the corresponding strategy mode and template mode are obtained to parse the business request, so as to meet the docking requirements of multiple business requests under different business types. Different business types are set with different templates, and the corresponding instruction format is implemented according to the template.

5. The terminal cross-device service processing method as described in claim 1, characterized in that, When executing a cross-machine transaction event corresponding to a business request, the corresponding front-end interface is locked and other operations are prohibited. Furthermore, a Redis synchronization lock is used to notify the same target terminal that only one instruction corresponding to the same type of business request can be executed at the same time.

6. The terminal cross-device service processing method as described in claim 1, characterized in that, The step of forwarding the service request to the target terminal based on the registration information of the target terminal includes: Based on the registration information of the target terminal, query the registration center for the target terminal's busy / idle status; When the target terminal is not in a busy state, the service request is forwarded to the target terminal. Before the service request is processed, the status of the target terminal is queried from the registration center at preset time intervals. If the target terminal is found to be heartbeat inactive, the corresponding abnormal information is sent to the source terminal. The registration center monitors and manages the health status of the target terminal through a TCP keep-alive mechanism.

7. The terminal cross-device service processing method as described in claim 1, characterized in that, The source terminal includes different types of terminal devices, including mainframes, card readers, WinPads, and AndroidPads.

8. A terminal cross-device service processing device, characterized in that, The terminal cross-machine business processing device, applied to cross-machine transaction services, includes: The receiving module is used to receive service requests sent by the source terminal and obtain the registration information of the corresponding target terminal from the registration center based on the service requests. The sending module is used to forward the service request to the target terminal based on the registration information of the target terminal for processing, and to receive the corresponding processed data from the target terminal to forward the processed data to the source terminal. Neither the source terminal nor the target terminal needs to maintain the corresponding service discovery logic and service registration information on their own nodes.

9. A terminal cross-device service processing device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the terminal cross-device service processing method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the terminal cross-device service processing method as described in any one of claims 1 to 7.

Images