Target service request processing method and device, equipment, medium and product

Abstract

The invention provides a target service request processing method and device, equipment, a medium and a product, and relates to the field of data processing. According to the specific technical scheme, the request data format of the service data in the service request of the target service, the request type of the service request and the routing parameter table are obtained, the routing parameter table is pushed to each request end and each response end through an application core end, the response ends do not need to maintain the parameter table, the system performance is saved, and the service quality is improved. And the processing efficiency of the target service request is improved. And based on the executable conversion code related to the target request type and the target data format of the target end, performing message conversion on the service request to obtain a request message of the target service. And the request end sends the request message to the target end. And the conversion logic of hard coding does not need to be manually intervened or written. The problem that the data formats of different systems and different services are incompatible is solved, and the processing efficiency of the target service request is improved.

Description

Technical Field

[0001] This application relates to the field of data processing, and more particularly to a method, apparatus, device, medium, and product for processing target service requests. Background Technology

[0002] To enable data interaction between multiple systems and reduce backend load, a front-end system can be configured. Taking the housing provident fund center system and the bank system as an example, the housing provident fund center system has a corresponding front-end system, and the bank system has a corresponding front-end system. Specific business requests between the housing provident fund center and the bank are processed through the front-end system and the bank's front-end system.

[0003] In traditional technologies, when a receiving front-end system receives a service request from another sending front-end system, it usually needs to convert the data in the service request format. Since the receiving front-end system cannot predict changes in the request volume and is limited by its limited hardware resources, the data format conversion in the service request may lead to low request processing efficiency. Summary of the Invention

[0004] This application provides a method, apparatus, device, medium, and product for processing target service requests, which can improve the processing efficiency of target service requests.

[0005] Firstly, a method for processing target business requests is provided, applied to a business processing system. The business processing system includes multiple request endpoints, an application core endpoint, and multiple response endpoints. The first endpoint of the application core endpoint is connected to each request endpoint, and the second endpoint of the application core endpoint is connected to each response endpoint. The method includes: The requesting end obtains the business request for the target service. This request includes business data, the request data format, and the request type. The requesting end retrieves a routing parameter table, which is pushed to each requesting and responding end by the application core. This ensures the accuracy and consistency of routing information and improves the processing accuracy of the target request. The routing parameter table includes the expected request type and expected data format for each of the multiple responding ends linked to the requesting end, providing a basis for accurate subsequent conversion of the target request. The requesting end determines the request priority of the business request and the port load of each responding end. From among the responding ends, it filters out the target end corresponding to the port load matching the request priority, configuring a target end that matches the request priority. This balances the load capacity of the responding ends and the importance of the request, maximizing the processing efficiency of the business request. Load balancing is achieved to prevent overload of a single responding end while ensuring that high-priority services are processed promptly. The requesting end determines the target request type and target data format corresponding to the target end. The target request type is the expected request type of the filtered response end, and the target data format is the expected data format of the filtered response end. It obtains executable conversion code that matches the format differences between the target data format and the request data format, as well as the type differences between the target request type and the request type. This executable conversion code is compiled from predefined message conversion rules. The corresponding conversion code is automatically matched and executed without manual intervention or hard-coded conversion logic. This solves the problem of data format incompatibility between different systems and services, thereby improving the processing efficiency of target business requests. Based on the executable conversion code, the business request is message converted to obtain the target business request message, eliminating the need for the target end to convert the business request itself, saving message conversion time on the target end, improving message conversion efficiency, and thus enhancing the processing efficiency of the target business request. The request message is then sent to the target end.

[0006] This method, on the one hand, optimizes resource utilization through dynamic load balancing, avoiding single-point bottlenecks at the response end, thereby improving the overall system stability and enhancing the processing efficiency of target business requests. On the other hand, when a new request or response end needs to be added, only the routing parameter table uniformly pushed by the application core needs to be updated, and the predefined message conversion rules need to be extended, without modifying the core code of each endpoint. This allows the system to easily adapt to business changes and scale expansion. Furthermore, the request end does not need to care about the specific technical implementation and data format of the downstream response end, but only needs to follow a unified processing framework. The loosely coupled design enables seamless integration of heterogeneous systems using different programming languages ​​and data protocols.

[0007] In one possible implementation of the first aspect, the port load situation includes port load rate; among each responding end, the target end corresponding to the port load situation that matches the request priority is selected, including: obtaining multiple consecutive and non-overlapping load rate intervals configured for port load rate, and multiple consecutive and non-overlapping priority intervals configured for request priority; determining the priority interval sorting of the priority interval where the request priority is located in each priority interval, and for each responding end, the load rate interval where the port load rate of the responding end is located is sorted in the load rate interval sorting of each load rate interval; among each responding end, the target end corresponding to the load rate interval sorting that matches the priority interval sorting is selected.

[0008] In this embodiment, on the one hand, the port load rate and request priority are divided into continuous, non-overlapping intervals, and matching and filtering are performed based on interval sorting, thereby achieving fine-grained load scheduling and improving the processing efficiency of target service requests. On the other hand, this interval matching mechanism can effectively avoid uneven distribution of system resources, ensuring that high-priority requests can be assigned to ports with lower loads for processing, thereby improving the overall response speed and processing capacity of the system.

[0009] In one possible implementation of the first aspect, obtaining executable conversion code that matches the format differences between the target data format and the request data format, and the type differences between the target request type and the request type, includes: obtaining format conversion code configured for the request data format, type conversion code configured for the request type, a preset format difference threshold configured for the format differences between the target data format and the request data format, and a preset type difference threshold configured for the type differences between the target request type and the request type, wherein both the format conversion code and the type conversion code are compiled from predefined message conversion rules; if the format difference is greater than the preset format difference threshold and the type difference is less than or equal to the preset type difference threshold, the format conversion code is determined to be executable conversion code; if the type difference is greater than the preset type difference threshold and the format difference is less than or equal to the preset format difference threshold, the type conversion code is determined to be executable conversion code; if the format difference is greater than the preset format difference threshold and the type difference is greater than the preset type difference threshold, the format conversion code and the type conversion code are concatenated to obtain executable conversion code.

[0010] In this embodiment, based on the degree of format and type differences, the system intelligently selects to use either a single format conversion code or a type conversion code, or concatenates both when the differences are significant, thereby generating the most suitable executable conversion code. This dynamic combination method enhances the system's flexibility in handling different communication formats and request types, avoids code redundancy, and improves conversion efficiency.

[0011] In another possible implementation of the first aspect, the method further includes: the requesting end obtaining a response message of the request message from the target end, wherein the response message includes business parameters and business parameter values; the requesting end determining the adjustment range of the request priority based on the difference between the business parameter threshold configured for the business parameters and the business parameter values; if the business parameter threshold is greater than the business parameter value, the requesting end upgrading the request priority based on the adjustment range; if the business parameter threshold is less than the business parameter value, the requesting end downgrading the request priority based on the adjustment range.

[0012] In this embodiment, on the one hand, the adjustment range of request priority is determined based on the difference between the business parameter threshold configured for the business parameters and the business parameter value. This quantitative determination of the adjustment range allows for accurate adjustment of the request priority of the target business requests, improving the processing efficiency of each request on the response end and thus enhancing overall performance and user experience. On the other hand, a dynamic priority adjustment mechanism based on business parameter feedback is implemented. When the business parameter value is better than the threshold, the request is upgraded; otherwise, it is downgraded. This enables the system to adapt to changes in business status and optimize resource allocation strategies.

[0013] In one possible implementation of the first aspect, sending the request message to the target end includes: the requesting end performing digital signature encryption processing on the request message according to the requesting end's private key to obtain an encrypted message containing the digital signature; and the requesting end sending the encrypted message containing the digital signature to the target end.

[0014] In this embodiment, the requesting end performs digital signature encryption on the request message using its private key, resulting in an encrypted message containing the digital signature. The requesting end sends the encrypted message containing the digital signature to the target end. On the one hand, digital signature encryption of the request message ensures the uniqueness of the identities and authenticity of both communicating parties, effectively preventing the risk of data tampering or theft. On the other hand, compared with other complex security schemes, digital signatures have a higher cost-effectiveness ratio, saving system hardware resources and thus improving the processing efficiency of target business requests.

[0015] In another possible implementation of the first aspect, the method further includes: the target end obtaining the user's user permissions and the target end's access permissions; when both the user permissions and access permissions are greater than preset permissions, the target end performs digital signature verification on the encrypted message containing the digital signature; when the target end passes the digital signature verification of the encrypted message, the target end decrypts the encrypted message containing the digital signature according to the private key of the responding end to obtain the request message.

[0016] In this embodiment, the target end obtains the user's permissions and the target end's access permissions. When both user permissions and access permissions are greater than preset permissions, the target end performs digital signature verification on the encrypted message containing the digital signature. If the target end passes the digital signature verification of the encrypted message, it decrypts the encrypted message containing the digital signature using the responder's private key to obtain the request message. By obtaining access permissions and user permissions, verifying permissions, and performing digital signature verification, multiple layers of security protection are constructed to prevent unauthorized access and message tampering, ensuring the security and integrity of data transmission.

[0017] In another possible implementation of the first aspect, the method further includes: when a new port appears in the business processing system, the application core obtains the expected request type and expected format type of the new port; the application core writes the expected request type and expected format type of the new port into the routing parameter table; and the application core pushes the routing parameter table to each requesting end and each responding end.

[0018] In this embodiment, on the one hand, when a new port is added to the system, the application core automatically updates and synchronizes the routing parameter table, ensuring system scalability. This allows newly added ports to be quickly identified and utilized without interrupting existing services or requiring complex manual configuration. On the other hand, it enables "hot-swappable" service deployment, allowing new ports and service instances to be immediately identified and accepted by the system without downtime. It also supports rapid horizontal scaling to handle sudden traffic surges or business growth, directly enhancing the system's elasticity and scalability.

[0019] Secondly, a processing apparatus for a target service request is provided, the apparatus comprising: The request retrieval module is used to retrieve the business requests of the target business from the requesting end. The business requests include business data, the request data format of the business data, and the request type of the business requests. The parameter table acquisition module is used to acquire the routing parameter table. The routing parameter table is pushed to each requesting end and each responding end through the application core. The routing parameter table includes the expected request type and expected data format of each of the multiple responding ends that have a link relationship with the requesting end. The response filtering module is used to determine the request priority of the business request and the port load of each response terminal, and to filter out the target terminal corresponding to the port load that matches the request priority from each response terminal. The type and format determination module is used to determine the target request type and target data format corresponding to the target end; wherein, the target request type is the expected request type of the filtered response end, and the target data format is the expected data format of the filtered response end; The code acquisition module is used to acquire executable conversion code that matches the format differences between the target data format and the request data format, as well as the type differences between the target request type and the request type; the executable conversion code is obtained by compiling predefined message conversion rules; The message conversion module is used to convert business requests based on executable conversion code to obtain the request message of the target business. The message sending module is used to send request messages to the target end.

[0020] Thirdly, a processing device for a target service request is provided, the method comprising: a memory and at least one processor. The memory is communicatively connected to the processor. The memory is used to store computer program code, the computer program code including computer instructions. When the processor executes the computer instructions, it causes the electronic device to perform the method of the first aspect and any possible implementation thereof.

[0021] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions. When these computer instructions are executed by a processor, they are used to implement the method as described in the first aspect and any possible implementation thereof.

[0022] Fifthly, embodiments of this application provide a computer program product that, when running on a computer / executed by the computer's processor, implements the method described in the first aspect and any possible design thereof. The computer may be a processing device for the target service request described in the third aspect and any possible implementation thereof.

[0023] Understandably, the beneficial effects that the processing apparatus for the target service request of the second aspect, the processing device for the target service request of the third aspect, the computer-readable storage medium of the fourth aspect, and the computer program product of the fifth aspect can achieve can be referred to the beneficial effects of the first aspect and any possible implementation thereof, which will not be repeated here. Attached Figure Description

[0024] Figure 1 This application provides a schematic diagram of the structure of a business processing system according to an embodiment of the present application. Figure 2 A flowchart illustrating a method for processing a target service request provided in an embodiment of this application; Figure 3 A flowchart illustrating a method for determining a target end, provided in an embodiment of this application; Figure 4 A flowchart illustrating a method for determining executable conversion code, provided as an embodiment of this application; Figure 5A structural diagram of a business system and an external system provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a service processing device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a service processing device provided in an embodiment of this application. Detailed Implementation

[0025] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0026] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0027] The technical solutions provided in this application, including the collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data, comply with relevant laws and regulations and do not violate public order and good morals.

[0028] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0029] The method for processing target service requests provided in this application embodiment can be applied to, for example, Figure 1The business processing system 100 shown includes multiple request terminals 101, application core terminals 102, and multiple response terminals 103. The request terminals 101 and response terminals 103 can be referred to as ports. The first end of the application core terminal 102 is linked to each request terminal 101, and the second end of the application core terminal 102 is linked to each response terminal 103. In this business processing system 100, the request terminal 101 obtains the business request of the target business, which includes business data, the request data format of the business data, and the request type of the business request. The request terminal 101 obtains a routing parameter table, which is pushed to each request terminal 101 and each response terminal 103 through the application core terminal 102. The routing parameter table includes the expected request type and expected data format of each of the multiple response terminals 103 linked to the request terminal 101. The request terminal 101 determines the request priority of the business request and the port load of each response terminal 103, and filters out the target terminal corresponding to the port load that matches the request priority from among the response terminals 103. The requesting end 101 determines the target request type and target data format corresponding to the target end. The target request type is the expected request type of the filtered responding end 103, and the target data format is the expected data format of the filtered responding end 103. The requesting end 101 obtains executable conversion code that matches the format differences between the target data format and the request data format, as well as the type differences between the target request type and the request type. The executable conversion code is compiled from predefined message conversion rules. Based on the executable conversion code, the requesting end 101 performs message conversion on the business request to obtain the target business request message. The requesting end 101 then sends the request message to the target end.

[0030] Among them, the request end 101, the application core end 102 and the response end 103 can all be servers. The servers can be implemented by independent servers or by a server cluster composed of multiple servers.

[0031] To enable data interaction between multiple systems and reduce backend pressure, a front-end system is configured for each system. Taking the housing provident fund center system and the bank system as an example, the housing provident fund center system has a corresponding front-end system, and the bank system has a corresponding front-end system. Specific business requests between the housing provident fund center and the bank are processed through the front-end system and the front-end system.

[0032] In traditional technologies, when a receiving front-end system receives a service request from another sending front-end system, it usually needs to convert the data in the service request format. This format conversion process consumes system hardware resources and reduces the processing efficiency of the receiving front-end system's service requests.

[0033] The front-end system typically includes multiple server clusters, each with different data requirements in its business requests. As business grows and the volume of business increases, the server clusters face the problem of low processing efficiency for business requests.

[0034] This application provides a method for processing target business requests. The method obtains the request data format, request type, and routing parameter table of the business data in the target business request. The routing parameter table is pushed to each requesting end and each responding end through the application core, eliminating the need for the responding end to maintain the parameter table, thus saving system performance and improving the processing efficiency of the target business request. Based on executable conversion code related to the target request type and target data format of the target end, the business request is message converted to obtain the target business request message. The requesting end sends the request message to the target end. No manual intervention or hard-coded conversion logic is required. This solves the problem of data format incompatibility between different systems and services, thereby improving the processing efficiency of the target business request.

[0035] In one embodiment, such as Figure 2 As shown, a method for processing target business requests is provided, which can be applied to... Figure 1 The method can be implemented in a business processing system 100, or applied to a cloud computing platform, edge computing device, chip, or computing device, etc. This application embodiment does not limit the specific form of the device executing the method; the method specifically includes: S201, The requesting end obtains the business request for the target business.

[0036] The business request includes business data, the request data format of the business data, and the request type of the business request.

[0037] In some embodiments, the requesting end is Figure 1 The business processing system 100 shown includes multiple request terminals, an application core terminal, and multiple response terminals. The first terminal of the application core terminal is connected to each request terminal, and the second terminal of the application core terminal is connected to each response terminal.

[0038] In this system, the requesting end can be the client that initiates the business request, the application core end can be the application that processes the request, and the response end is the server that receives the server's response. The requesting end and the first application core end, as well as the second application core end and the response end, are connected via network links. There can be multiple requesting ends and multiple response ends; this is not limited here.

[0039] The target business can be a specific business initiated by the requesting end. For example, the specific business initiated by the requesting end can be a business between the housing provident fund center and the bank, such as housing provident fund collection, withdrawal, loan, and settlement. The requesting end can be the corresponding port of the housing provident fund center or the bank. As another example, the specific business initiated by the requesting end can be a file processing business between the requesting end and the server, such as file archiving and cleanup.

[0040] A business request can be a specific request targeting a specific business function. A request can be an instruction initiated by the requesting party, and a business request can be a high-level request targeting a business objective. For example, a business request can be a high-level request targeting a business objective between a housing provident fund center and a bank, such as a housing provident fund collection request, a housing provident fund withdrawal request, a housing provident fund loan request, or a housing provident fund settlement request. Another example is a high-level request targeting a business objective between the requesting party and the server, such as a file archiving and cleanup request.

[0041] Business data can be specific data within a business request. For example, in a housing provident fund collection business request, the business data could include the contributing unit, individual account balance, and contribution details. Similarly, in a file archiving and cleanup business request, the business data could include log file data, data dumping file data, and report file data.

[0042] The request data format can represent the data format corresponding to the business data. Request data formats can include JSON (JavaScript Object Notation, a lightweight data interchange format), key-value pair format, plain text format, XML (Extensible Markup Language), pure binary data format, JSON text format, CSV text format (Comma-Separated Values), etc.

[0043] The request type can represent the type of business request. Request types can include HTTP (Hypertext Transfer Protocol), HTTPS (Hypertext Transfer Protocol Secure), gRPC (gRPC Remote Procedure Call), FTP (File Transfer Protocol), HTTP1 (the first type of HTTP request), HTTP2 (the second type of HTTP request), etc.

[0044] In a specific implementation, the pre-packaged business requests of the target business can be obtained directly.

[0045] In a specific implementation, the preset encapsulation method for the business request and the business data of the target business can be determined. The business data can be encapsulated according to the preset encapsulation method to obtain the business request of the target business.

[0046] For example, based on business data, a request line is set, a request header is configured, and a request body is constructed to obtain a business request under the HTTP request type. Specifically, constructing the request body based on business data includes converting the business data into a string or binary format.

[0047] S202, the requesting end obtains the routing parameter table.

[0048] The routing parameter table is pushed to each requesting end and each responding end through the application core. The routing parameter table includes the expected request type and expected data format of each of the multiple responding ends that are linked to the requesting end.

[0049] In some embodiments, the routing parameter table may record the routing information of each responding end and each requesting end. Specifically, the routing information may include the expected request type and expected data format, IP address set, service type, organization node number, and other data of each of the multiple responding ends that are linked to the requesting end.

[0050] The expected request type can be any type of business request that the responding end can directly process.

[0051] The expected data format can be the request data format of the business data that the responding end can directly process.

[0052] In one specific implementation, the requesting client can directly obtain the routing parameter table from its local machine. The application core can push the routing parameter table to the requesting client, which can then store and retrieve the routing parameter table.

[0053] In a specific implementation, the requesting end can send a parameter table update command to the application core end, and the requesting end can obtain the latest routing parameter table that matches the update command from the application core end.

[0054] S203, the requesting end determines the request priority of the service request and the port load of each responding end, and filters out the target end corresponding to the port load that matches the request priority from each responding end.

[0055] In some embodiments, request priority can characterize the importance of a business request.

[0056] For example, different request priorities can be assigned to different types of business requests based on business needs or service quality requirements. High-priority requests typically require faster responses and more reliable transmission, such as real-time audio and video communication or critical business data. Low-priority requests, on the other hand, may tolerate some latency, such as background file downloads or non-critical updates.

[0057] For example, the request priority of a business request can be determined based on the business type of the target business, the identifier of the requesting end, and business rules.

[0058] In some embodiments, port load can characterize the current workload state of the physical interface on the responding end.

[0059] The target end can be the response end corresponding to the port load situation that matches the request priority of the business request.

[0060] In a specific implementation, port load information includes port load rate, which can be obtained by comparing historical port load rates with request priorities. The estimated port load rate corresponding to a request priority can be determined by multiplying this ratio by the request priority. From among the responding endpoints, the target endpoint with the port load rate that has the smallest difference from the estimated port load rate can be selected.

[0061] In a specific implementation, port load information includes port load rate, and can also obtain multiple consecutive and non-overlapping load rate intervals configured for port load rate, and multiple consecutive and non-overlapping priority intervals configured for request priority; determine the priority interval sorting of the priority interval where the request priority is located in each priority interval, and for each response end, the load rate interval sorting of the port load rate of the response end in each load rate interval; among each response end, filter out the target end corresponding to the load rate interval sorting that matches the priority interval sorting.

[0062] In a specific implementation, a time requirement can also be obtained. This time requirement can be the estimated processing time of a business request, meaning the processing time requirement for the corresponding business request can be obtained in advance. Specifically, among the response endpoints, the response endpoints whose port load matches the longest processing time and request priority can be selected as the target endpoints. For example, if the estimated processing time of a business request is low and the request priority is high, the response endpoint with a low port load rate can be selected as the target endpoint, where port load includes port load rate.

[0063] For example, determining the priority of a business request may specifically include: determining the request priority based on one or more of the following: business impact weight, user experience weight, technical urgency weight, resource consumption weight, or dependency weight. Specifically, the business impact weight can be the degree to which the business request contributes to the organization's core business objectives. The user experience weight can be the degree and scope of the business request's impact on the end-user experience. The technical urgency weight can be the urgency and risk level of the business request at the technical level. The resource consumption weight can be the various resource costs required to implement the business request, typically an inverse weight (the greater the consumption, the lower the priority). The dependency weight can be the position of the business request in the project dependency chain, and the weight corresponding to whether it blocks other important work.

[0064] S204, The requesting end determines the target request type and target data format corresponding to the target end.

[0065] The target request type is the expected request type of the filtered response end, and the target data format is the expected data format of the filtered response end.

[0066] S205, The requesting end obtains executable conversion code that matches the format differences between the target data format and the request data format, as well as the type differences between the target request type and the request type.

[0067] The executable conversion code is obtained by compiling predefined message conversion rules.

[0068] In some embodiments, for differences in the target data format and the request data format, for example, the request data format may be JSON and the target data format may be XML. Since the format differences are significant, the business request can be converted to reduce the time required for the target end to process the data.

[0069] When there's a significant difference between the target request type and the request type—for example, the request type could be HTTP while the target request type could be HTTPS—the business request can be transformed to reduce the time required for the target to process the data.

[0070] Executable conversion code is compiled from predefined message conversion rules. Executable conversion code can be specific code that converts business data into messages. For example, executable conversion code can convert request type A of a business request into request type B of a request message, or convert data format a of a business request into data format b of a request message, or convert data format a of request type A of a business request into data format b of request type B of a request message, while preserving the content and meaning of the business data.

[0071] Message translation rules can be a mapping relationship between messages and requests.

[0072] In one specific embodiment, message conversion rules can be generated based on requests with different request formats and different data formats within those requests. Existing message conversion rules can also be modified to obtain new message conversion rules based on business requirements. Furthermore, new request formats or new data formats can be added to the message conversion rules based on business requirements to obtain new message conversion rules.

[0073] In a specific implementation, the mapping relationship between messages and requests can be determined. Multiple mapping relationships are compiled to obtain executable conversion code.

[0074] In a specific implementation, the following are obtained: format conversion code configured for the request data format, type conversion code configured for the request type, a preset format difference threshold configured for the format differences between the target data format and the request data format, and a preset type difference threshold configured for the type differences between the target request type and the request type. Both the format conversion code and the type conversion code are compiled from predefined message conversion rules. If the format difference is greater than the preset format difference threshold, and the type difference is less than or equal to the preset type difference threshold, the format conversion code is determined to be executable conversion code. If the type difference is greater than the preset type difference threshold, and the format difference is less than or equal to the preset format difference threshold, the type conversion code is determined to be executable conversion code. If both the format difference and type difference are greater than the preset format difference threshold, the format conversion code and the type conversion code are concatenated to obtain the executable conversion code.

[0075] S206, the requesting end performs message conversion on the business request based on the executable conversion code to obtain the request message of the target business.

[0076] In some embodiments, the request message may be a request obtained by formatting and / or type conversion of a business request.

[0077] The request message can be a specific message targeting a particular business transaction. For example, the request message for the target business could be a message for housing provident fund collection, a message for housing provident fund withdrawal, a message for housing provident fund loan, or a message for housing provident fund settlement.

[0078] In a specific implementation, executable conversion code may include type conversion code and format conversion code. The requesting end can perform message conversion on the business request based on the type conversion code and / or format conversion code to obtain the request message of the target business.

[0079] In a specific implementation, if the type difference is greater than a type difference threshold, the business request can be message-converted using type conversion code to obtain the target business request message. Alternatively, if the format difference is greater than a format difference threshold, the business request can be message-converted using format conversion code to obtain the target business request message. Finally, if both the type difference and format difference are greater than the type difference threshold, the business request can be message-converted using both type conversion code and format conversion code to obtain the target business request message.

[0080] For example, executable conversion code may include: standardization code for standardizing protocol parameters, data serialization code for converting the data format in the request body, header management code for adding message headers, and message assembly code for assembling messages. The requesting end performs message conversion on the business request based on the executable conversion code to obtain the request message of the target business. Specifically, this may include: performing message conversion on the business request in sequence based on the standardization code, data serialization code, header management code, and message assembly code to obtain the request message of the target business.

[0081] S207, the requesting end sends the request message to the target end.

[0082] In a specific implementation, the requesting end can send the request message to the target end in a timed, delayed, or real-time manner.

[0083] In a specific implementation, the requesting end can directly send the request message to the target end.

[0084] In a specific implementation, the requesting end can encrypt the request message to obtain an encrypted message, and then send the encrypted message to the target end.

[0085] For example, the requesting end sends a request message to the target end, which may specifically include: the requesting end performing digital signature encryption processing on the request message according to the requesting end's private key to obtain an encrypted message containing the digital signature; and the requesting end sending the encrypted message containing the digital signature to the target end.

[0086] In this embodiment, the service request of the target service in the requesting end is obtained. The service request includes service data, the request data format of the service data, and the request type of the service request. The requesting end obtains a routing parameter table, which is pushed to each requesting end and each responding end through the application core end, ensuring the accuracy and consistency of routing information and improving the processing accuracy of the target request. The routing parameter table includes the expected request type and expected data format of each of the multiple responding ends that are linked to the requesting end, providing a basis for accurate conversion of the target request in the future. The requesting end determines the request priority of the service request and the port load of each responding end, and selects the target end corresponding to the port load that matches the request priority from each responding end. The target end that matches the request priority is configured for the service request, taking into account the load capacity of the responding end and the importance of the request, thereby maximizing the processing efficiency of the service request. Load balancing is achieved to avoid overload of a single responding end, while ensuring that high-priority services can be processed in a timely manner. The requesting end determines the target request type and target data format corresponding to the target end. The target request type is the expected request type of the filtered response end, and the target data format is the expected data format of the filtered response end. It obtains executable conversion code that matches the format differences between the target data format and the request data format, as well as the type differences between the target request type and the request type. This executable conversion code is compiled from predefined message conversion rules. The corresponding conversion code is automatically matched and executed without manual intervention or hard-coded conversion logic. This solves the problem of data format incompatibility between different systems and services, thereby improving the processing efficiency of target business requests. Based on the executable conversion code, the business request is message converted to obtain the target business request message, eliminating the need for the target end to convert the business request itself, saving message conversion time on the target end, improving message conversion efficiency, and thus enhancing the processing efficiency of the target business request. The request message is then sent to the target end.

[0087] This method, on the one hand, optimizes resource utilization through dynamic load balancing, avoiding single-point bottlenecks at the response end, thereby improving the overall system stability and enhancing the processing efficiency of target business requests. On the other hand, when a new request or response end needs to be added, only the routing parameter table uniformly pushed by the application core needs to be updated, and the predefined message conversion rules need to be extended, without modifying the core code of each endpoint. This allows the system to easily adapt to business changes and scale expansion. Furthermore, the request end does not need to care about the specific technical implementation and data format of the downstream response end, but only needs to follow a unified processing framework. The loosely coupled design enables seamless integration of heterogeneous systems using different programming languages ​​and data protocols.

[0088] In one embodiment, such as Figure 3As shown, the port load information includes the port load rate. In step S203 above, the target endpoints corresponding to the port load information matching the request priority are selected from among the responding endpoints. Specifically, this may include: S301, obtain multiple consecutive and non-overlapping load rate ranges configured for port load rate, and multiple consecutive and non-overlapping priority ranges configured for request priority.

[0089] In some embodiments, port load rate can represent how busy a port is in network communication.

[0090] Load rate ranges can be ranges configured for port load rates. Multiple load rate ranges are consecutive but do not overlap. For example, multiple load rate ranges could include less than 40%, greater than or equal to 40% and less than 60%, and greater than or equal to 60%.

[0091] Priority ranges can be ranges configured for request priorities. Multiple priority ranges are contiguous but do not overlap. For example, multiple priority ranges can include less than 0.4, greater than or equal to 0.4 and less than 0.6, and greater than or equal to 0.6.

[0092] S302, determine the priority interval of the request priority in the priority interval sorting of each priority interval, and for each response end, the load rate interval of the response end's port load rate in the load rate interval sorting of each load rate interval.

[0093] In some embodiments, priority interval sorting can represent the order in which the priority interval to which the request priority belongs is within each priority interval. For example, if a service request has a priority of 0.5, and its priority interval is greater than or equal to 0.4 and less than 0.6, the corresponding order for this interval is 2.

[0094] In some embodiments, the load rate interval sorting can represent the order in which the port load rate belongs within each load rate interval. For example, if the port load rate of a certain responding end is 45%, the load rate interval it belongs to is greater than or equal to 40% and less than 60%, and the corresponding order for this interval is 2.

[0095] S303, among each response end, filter out the target end corresponding to the load rate interval sorting that matches the priority interval sorting.

[0096] In some embodiments, matching the priority interval sorting and the load rate interval sorting can mean that the priority interval sorting and the load rate interval sorting are equal, or similar. For example, if the priority interval sorting is first, and the load rate interval sorting is first and second, it can be considered that the priority interval sorting interval and the load rate sorting interval match.

[0097] In this embodiment, on the one hand, the port load rate and request priority are divided into continuous, non-overlapping intervals, and matching and filtering are performed based on interval sorting, thereby achieving fine-grained load scheduling and improving the processing efficiency of target service requests. On the other hand, this interval matching mechanism can effectively avoid uneven distribution of system resources, ensuring that high-priority requests can be assigned to ports with lower loads for processing, thereby improving the overall response speed and processing capacity of the system.

[0098] In one embodiment, such as Figure 4 As shown, in step S205 above, obtaining executable conversion code that matches the format differences between the target data format and the request data format, as well as the type differences between the target request type and the request type, may specifically include: S401, obtain the format conversion code configured for the request data format, the type conversion code configured for the request type, the preset format difference threshold configured for the format difference between the target data format and the request data format, and the preset type difference threshold configured for the type difference between the target request type and the request type.

[0099] The format conversion code and type conversion code are both compiled from predefined message conversion rules.

[0100] In some embodiments, the format conversion code can be compiled from predefined message conversion rules, and can be conversion code configured according to the correspondence between the target data format and the request data format. For example, conversion code to convert XML format to JSON format. Another example is conversion code to convert plain text format to JSON format.

[0101] Type conversion code can be compiled from predefined message conversion rules, or it can be conversion code configured based on the mapping between the target request type and the request type. For example, conversion code to convert HTTP type to HTTPS type.

[0102] The preset format difference threshold and preset type difference threshold can be flexibly selected according to the actual situation, and there is no limitation here.

[0103] In a specific implementation, the format difference between the target data format and the request data format can be determined based on the similarity between their respective format fields. For example, the target data format and the request data format can be JSON text format and CSV text format, respectively. The similarity between the format fields of the JSON text format and the CSV text format can be used to determine the format difference between the JSON text format and the CSV text format, thereby determining the relationship between the format difference and a preset format difference threshold.

[0104] In a specific implementation, the type difference between the target request type and the request type can be determined based on the similarity between their respective type fields. For example, the target request type and the request type can be HTTP1 (the first type of HTTP request) and HTTP2 (the second type of HTTP request), respectively. It can be understood that HTTP1 represents the first version number type of the HTTP request, and HTTP2 represents the second version number type, where the version corresponding to the second version number is higher than the version corresponding to the first version number. The type difference between HTTP1 and HTTP2 can be determined based on the similarity between the type field "HTTP1" of the target request type and the type field "HTTP2" of the request type, and thus the relationship between the type difference and a preset type difference threshold can be determined.

[0105] S402, if the format difference is greater than the preset format difference threshold and the type difference is less than or equal to the preset type difference threshold, the format conversion code is determined to be executable conversion code.

[0106] In this context, a format difference greater than a preset format difference threshold indicates a significant difference between the target data format and the requested data format. If the requesting end does not perform conversion, the responding end will spend considerable time processing the business request. For example, there is a significant difference between plain text format and key-value pair format; if the requesting end does not perform conversion, the responding end will need to perform key-value conversion on the text. Therefore, when the format difference is greater than the preset format difference threshold, but the type difference is less than or equal to the preset type difference threshold, the format conversion code needs to be determined as executable conversion code. This allows for message conversion of the business request based on the executable conversion code.

[0107] For example, the target request type can be HTTP2 (the second type of HTTP request), and the request type can be HTTP1 (the first type of HTTP request). The type difference between the target request type and the request type is less than or equal to a preset type difference threshold. The target data format can be JSON format, and the request data format can be plain text format. The format difference between the target data format and the request data format is greater than a preset format difference threshold. Therefore, the format conversion code needs to be determined as executable conversion code, so that the message conversion of the business request can be performed according to the executable conversion code.

[0108] S403, if the type difference is greater than the preset type difference threshold and the format difference is less than or equal to the preset format difference threshold, the type conversion code is determined to be executable conversion code.

[0109] A type difference greater than a preset type difference threshold indicates a significant difference between the target request type and the request type. If the requesting end does not perform conversion, the responding end will need to perform additional processing on the business request, resulting in considerable time consumption. For example, there is a significant difference between gRPC requests and HTTP requests. If the requesting end does not perform conversion, the responding end needs to convert the gRPC request to an HTTP request through a gRPC gateway. Therefore, when the type difference is greater than the preset type difference threshold, and the format difference is less than or equal to the preset format difference threshold, the type conversion code is determined to be executable conversion code. This allows for message conversion of the business request based on the executable conversion code.

[0110] For example, the target request type can be an HTTP request type, and the request type can be an HTTPS request type. The type difference between the target request type and the request type is greater than a preset type difference threshold. The target data format can be a JSON text format, and the request data format can be a CSV text format. The format difference between the target data format and the request data format is less than or equal to a preset format difference threshold. The type conversion code needs to be determined as executable conversion code, so that the message conversion of the business request can be performed according to the executable conversion code.

[0111] S404: If the format difference is greater than a preset format difference threshold and the type difference is greater than a preset type difference threshold, the format conversion code and the type conversion code are concatenated to obtain executable conversion code.

[0112] In a specific implementation, the format conversion code and the type conversion code are concatenated. This process may include: checking the input and output formats of the format conversion code and the type conversion code respectively; if the input and output formats match, concatenating the code according to the execution order of the format conversion code and the type conversion code respectively to obtain the concatenated code, which can then be executed. In this way, the business request message can be converted according to the executable conversion code.

[0113] For example, the target request type can be an HTTP request type, and the request type can be an HTTPS request type. The type difference between the target request type and the request type is greater than a preset type difference threshold. The target data format can be JSON format, and the request data format can be plain text format. The format difference between the target data format and the request data format is greater than a preset format difference threshold. The code can be concatenated according to the execution order of the format conversion code and the type conversion code to obtain the concatenated code. The conversion code can then be executed, and the message of the business request can be converted according to the executable conversion code.

[0114] In this embodiment, based on the degree of format and type differences, the system intelligently selects to use either a single format conversion code or a type conversion code, or concatenates both when the differences are significant, thereby generating the most suitable executable conversion code. This dynamic combination method enhances the system's flexibility in handling different communication formats and request types, avoids code redundancy, and improves conversion efficiency.

[0115] In one embodiment, the method for processing a target business request further includes: the requesting end obtaining a response message of the request message from the target end, wherein the response message includes business parameters and business parameter values. The requesting end determines the adjustment range of the request priority based on the difference between the business parameter threshold configured for the business parameters and the business parameter values. If the business parameter threshold is greater than the business parameter value, the requesting end upgrades the request priority based on the adjustment range. If the business parameter threshold is less than the business parameter value, the requesting end downgrades the request priority based on the adjustment range.

[0116] In some embodiments, the response message may be a response message to the request message.

[0117] Business parameters can represent parameters related to the execution status of a target business system. Specifically, business parameters can include parameters such as processing time and error rate.

[0118] Business parameter values ​​can represent the values ​​of business parameters. Specifically, business parameter values ​​can be the processing time corresponding to the processing time parameter, or the real-time error rate corresponding to the error rate parameter.

[0119] Business parameter thresholds can be thresholds configured for specific business parameters. For example, a processing time threshold configured for a processing time parameter, or an error rate threshold configured for an error rate parameter.

[0120] For example, the average processing time corresponding to historical business requests can be obtained from the response end, and the average processing time can be determined as the processing time threshold.

[0121] The adjustment range can be interpreted as the degree of change in a single adjustment to the request priority. For example, the adjustment range could be 33%, and adjusting the request priority based on the adjustment range could specifically mean increasing it by 33% or decreasing it by 33%.

[0122] In a specific implementation, business parameter values ​​include processing time and real-time error rate, and business parameter thresholds include processing time thresholds and error rate thresholds. The adjustment range of request priority is determined based on the difference between the processing time threshold and the actual processing time, and the difference between the error rate threshold and the real-time error rate.

[0123] For example, the adjustment range of request priority is determined based on the difference between the processing time threshold of 15s and the processing time of 10s (15 / 10=1.5), and the difference between the error rate threshold of 5% and the real-time error rate of 1% (5 / 1=5).

[0124] In a specific implementation, business parameter values ​​include processing time and real-time error rate, and business parameter thresholds include processing time threshold and error rate threshold. If the processing time threshold is greater than the actual processing time, and the error rate threshold is greater than the real-time error rate threshold, the requesting client escalates the request priority based on the adjustment magnitude.

[0125] For example, the upgrade process could be to multiply the request priority by 3.25 to obtain the upgraded request priority.

[0126] In a specific implementation, business parameter values ​​include processing time and real-time error rate, and business parameter thresholds include processing time threshold and error rate threshold. If the processing time threshold is less than the actual processing time, and the error rate threshold is less than the real-time error rate threshold, the requesting client downgrades the request priority based on the adjustment range.

[0127] In this embodiment, on the one hand, the adjustment range of request priority is determined based on the difference between the business parameter threshold configured for the business parameters and the business parameter value. This quantitative determination of the adjustment range allows for accurate adjustment of the request priority of the target business requests, improving the processing efficiency of each request on the response end and thus enhancing overall performance and user experience. On the other hand, a dynamic priority adjustment mechanism based on business parameter feedback is implemented. When the business parameter value is better than the threshold, the request is upgraded; otherwise, it is downgraded. This enables the system to adapt to changes in business status and optimize resource allocation strategies.

[0128] In one embodiment, sending a request message to the target end includes: the requesting end performing digital signature encryption on the request message based on its private key to obtain an encrypted message containing the digital signature. The requesting end then sends the encrypted message containing the digital signature to the target end.

[0129] In some embodiments, the private key can be an asymmetric encryption private key. The private key corresponds to a public key, and the target end can possess or obtain the requesting end's public key.

[0130] A digital signature can be a hash value obtained by encrypting the data in a request message.

[0131] An encrypted message can be a message obtained by combining a hash value and a request message.

[0132] In a specific implementation, the digital signature encryption process may include: the requesting end can calculate a fixed-length, unique message digest (hash value, i.e., digital signature) from the request message using a preset hash algorithm. The requesting end then encrypts the hash value using its private key to obtain an encrypted message containing the digital signature.

[0133] In a specific implementation, sending encrypted messages can include: transmitting encrypted messages containing digital signatures over a network, with the channel encrypted using the Transport Layer Security (TLS) protocol during network transmission.

[0134] In this embodiment, the requesting end performs digital signature encryption on the request message using its private key, resulting in an encrypted message containing the digital signature. The requesting end sends the encrypted message containing the digital signature to the target end. On the one hand, digital signature encryption of the request message ensures the uniqueness of the identities and authenticity of both communicating parties, effectively preventing the risk of data tampering or theft. On the other hand, compared with other complex security schemes, digital signatures have a higher cost-effectiveness ratio, saving system hardware resources and thus improving the processing efficiency of target business requests.

[0135] In one embodiment, the method for processing the target business request further includes: the target end obtaining the user permissions of the operating user and the access permissions of the target end. If both the user permissions and access permissions are greater than preset permissions, the target end performs digital signature verification on the encrypted message containing the digital signature. If the target end passes the digital signature verification of the encrypted message, the target end decrypts the encrypted message containing the digital signature using the private key of the responding end to obtain the request message.

[0136] In some embodiments, the operator can represent the operator corresponding to the target end.

[0137] User permissions represent the permissions corresponding to the operator. Different operators have different user permissions.

[0138] Access permissions represent the permissions granted to the target endpoint. Different responding endpoints have different access permissions. The level of access permissions indicates the importance of each responding endpoint among all responding endpoints.

[0139] Preset permissions can be preset values ​​configured for user permissions and access permissions.

[0140] For example, if both user permissions and access permissions are greater than preset permissions, the target device performs digital signature verification on the encrypted message containing the digital signature. If either user permission or access permission is less than or equal to the preset permission, an error message indicating a permission error is returned.

[0141] In a specific implementation, digital signature verification of encrypted messages containing digital signatures can specifically include: the target end can verify the digital signature based on a pre-stored public key or the public key of the requesting end.

[0142] In a specific implementation, after the target verifies the encrypted message with a digital signature, the target can decrypt the encrypted message containing the number using the private key of the responding end to obtain the request message.

[0143] For example, access permissions for the responding end can be adjusted. Specifically, the access management records of the responding end can be obtained. These records include the data integrity of the data obtained by the responding end relative to the original data. If the data integrity is higher than the integrity threshold within a preset time period, the access permissions of the responding end can be increased.

[0144] For example, access control can be implemented on the permissions corresponding to operators. Specifically, the operation log information of each operator can be obtained. If abnormal information is found in the operation log information, the user permissions corresponding to the operator can be reduced.

[0145] In this embodiment, the target end obtains the user's permissions and the target end's access permissions. When both user permissions and access permissions are greater than preset permissions, the target end performs digital signature verification on the encrypted message containing the digital signature. If the target end passes the digital signature verification of the encrypted message, it decrypts the encrypted message containing the digital signature using the responder's private key to obtain the request message. By obtaining access permissions and user permissions, verifying permissions, and performing digital signature verification, multiple layers of security protection are constructed to prevent unauthorized access and message tampering, ensuring the security and integrity of data transmission.

[0146] In one embodiment, the method for processing the target business request further includes: if the routing parameter table is updated, the application core pushes the routing parameter table to each requesting end and each responding end; or, if a new port appears in the business processing system, the application core obtains the expected request type and expected format type of the new port. The application core writes the expected request type and expected format type of the new port into the routing parameter table, where the new port includes either a requesting end or a responding end. The application core then pushes the routing parameter table to each requesting end and each responding end.

[0147] In some embodiments, an update to the routing parameter table can indicate a change in the routing information in the routing parameter table. For example, a change in the routing information may include: a change in the expected request type and expected data format of the responding or requesting end, a change in the IP address set, a change in the service type, a change in the organization node number, and other data.

[0148] In some embodiments, the routing parameter table may record the routing information of each responding end and each requesting end. Specifically, the routing information may include the expected request type and expected data format, IP address set, service type, organization node number, and other data of each of the multiple responding ends that are linked to the requesting end.

[0149] In a specific implementation, when the routing parameter table is updated, the application core can push the routing parameter table to each requesting end and each responding end.

[0150] For example, when the IP address of a bank in the routing parameter table changes, the set of IP addresses is updated to obtain the updated routing parameter table. The application core can then push the routing parameter table to each requesting and responding end.

[0151] Adding a port can be either adding a request port or adding a response port.

[0152] In a specific implementation, the application core can poll each port to identify whether there is a new port. If a new port appears in the business processing system, the application core can obtain the expected request type and expected format type of the new port.

[0153] For example, polling each port can specifically include: the application core can poll each port at preset time intervals. Alternatively, the application core can poll each port a fixed number of times at fixed intervals to conserve system resources.

[0154] For example, when a new port is added to the business processing system, the application core can obtain the expected request type and expected format type, IP address, business type and organization node number of the new port, and obtain the updated routing parameter table. The application core can then push the routing parameter table to each requesting end and each responding end.

[0155] For example, the application core can evaluate the business volume of each requesting end and each responding end within a preset time period to obtain the business volume level. If the business volume level is higher than the preset level, it can send a server expansion instruction to the external system. If a new port appears in the business processing system, the application core can obtain the expected request type and expected format type of the new port.

[0156] In a specific implementation, the application core can push the routing parameter table to each requesting and responding end in real time or at preset intervals when the routing parameter table changes.

[0157] In this embodiment, on the one hand, when a new port is added to the system, the application core automatically updates and synchronizes the routing parameter table, ensuring system scalability. This allows newly added ports to be quickly identified and utilized without interrupting existing services or requiring complex manual configuration. On the other hand, it enables "hot-swappable" service deployment, allowing new ports and service instances to be immediately identified and accepted by the system without downtime. It also supports rapid horizontal scaling to handle sudden traffic surges or business growth, directly enhancing the system's elasticity and scalability.

[0158] In one embodiment, such as Figure 5 The diagram shows the architecture of the business system and external systems. The business system includes: a central front-end server 502, an application core 503, and a bank front-end server 504. The external systems include: a central server 501 and a bank server 505.

[0159] In this context, the central front-end server 502 can be the server to which the requesting end belongs, the application core 503 can be the core (server) to which the application core end belongs, and the bank front-end server 504 can be the server to which the responding end (target end) belongs. It can be understood that the central front-end server 502 can also be the server to which the responding end (target end) belongs, and the bank front-end server 504 can also be the server to which the requesting end belongs.

[0160] Central server 501 and central front-end server 502 can belong to the housing provident fund center system. Bank front-end server 504 and bank server 505 can belong to the banking system. The housing provident fund center system and the banking system exchange data through central server 501, central front-end server 502, application core 503, bank front-end server 504, and bank server 505.

[0161] Firstly, in the traditional solution, both the central front-end server 502 and the bank's front-end server 504 need to maintain their own routing parameter tables. When the IP address of a server changes, the administrator needs to manually update the routing parameter tables of all front-end servers, which is both time-consuming and error-prone.

[0162] For example, a centralized routing management strategy can be adopted, where the application core 503 (application core end) maintains a unified routing parameter table and distributes the updated routing parameter table to each front-end server (multiple request ends and multiple response ends) through a real-time update mechanism.

[0163] For example, when a bank's IP address changes, the administrator only needs to update the bank's routing information in the system core to obtain the updated routing parameter table. The application core 503 (application core end) can then push the updated routing parameter table to each requesting end and each responding end.

[0164] For example, when a new port is added to the business processing system, the application core obtains the expected request type and expected format type of the new port, writes the expected request type and expected format type of the new port into the routing parameter table, and pushes the routing parameter table to each requesting end and each responding end.

[0165] The first aspect of the benefits includes: 1. Improved data accuracy: By centrally managing routing parameter tables through Application Core 503, all front-end systems are ensured to use consistent and up-to-date routing information, expected request types, and expected format types, avoiding inconsistencies and errors in routing information caused by decentralized management. 2. Simplified management complexity: The centralized management strategy reduces the number of routing parameter tables that administrators need to maintain, lowering the complexity and workload of system maintenance and improving work efficiency. 3. Real-time performance: Through a real-time update mechanism, Application Core 503 can quickly distribute the latest routing parameters to each front-end system, ensuring that the system always uses the latest routing information, improving system real-time performance and response speed.

[0166] Secondly, processing target business requests may have high time requirements. In traditional solutions, these requests are usually forwarded according to fixed routing rules. However, in some cases, due to unbalanced system load or poor network conditions, these requests may not be processed in a timely manner.

[0167] For example, the central server 501 or the central front-end server 502 can use intelligent routing rules to analyze the request priority, processing time requirements and port load of the target service request in real time, and dynamically select the optimal routing path (determine the target end) for forwarding (for example, the dynamic selection of the optimal path can be referred to step S203 in the aforementioned embodiment).

[0168] The second set of beneficial effects includes: 1. Improved transaction processing efficiency: Intelligent routing rule matching dynamically selects the optimal routing path based on the real-time status of transaction requests and system load, reducing processing and waiting times for target business requests and improving transaction processing efficiency. 2. Load balancing: By analyzing system load through intelligent algorithms and automatically adjusting routing rules, balanced resource utilization is achieved, preventing some front-end systems from being overloaded while others are idle, thus improving overall system performance and stability. 3. Flexibility: Intelligent routing rule matching supports custom routing rules based on business needs, making the system more flexible in adapting to different business scenarios and changing requirements.

[0169] Thirdly, different front-end servers may currently communicate using different data formats and request types. To achieve interconnectivity between these organizations, the system needs to perform message conversion.

[0170] For example, the message conversion engine in the system can obtain executable conversion code that matches the format differences between the target data format and the request data format, as well as the type differences between the target request type and the request type. The executable conversion code is compiled from predefined message conversion rules. The message conversion engine can perform message conversion on the business request based on the executable conversion code to obtain the request message of the target business.

[0171] The third set of beneficial effects includes: 1. Improved message conversion speed: By predefining message conversion rules and compiling them into executable conversion code, the message conversion engine can efficiently and quickly complete message conversion, reducing conversion time and improving system processing efficiency. 2. Reduced error rate: Because the message conversion engine uses predefined rules for conversion, it avoids errors and omissions caused by manually writing conversion code, thus reducing the system's error rate. 3. Scalability: The message conversion engine supports custom extension functions, allowing users to add new conversion rules or modify existing rules according to business needs, meeting the evolving needs of the system.

[0172] Fourthly, with the continuous growth of business volume and the increasing number of institutions, the system needs to continuously optimize routing rules and message conversion strategies to adapt to new business needs.

[0173] For example, the system obtains a response message to the request message from the target end, where the response message includes business parameters and business parameter values. The system determines the adjustment range of the request priority based on the difference between the business parameter threshold configured for the business parameters and the business parameter values. If the business parameter threshold is greater than the business parameter value, the system upgrades the request priority based on the adjustment range. If the business parameter threshold is less than the business parameter value, the system downgrades the request priority based on the adjustment range.

[0174] The fourth beneficial effect includes: 1. Continuous performance improvement: By automatically collecting and analyzing transaction data, the system can continuously optimize routing rules and message conversion strategies, achieving continuous performance improvement and meeting the needs of business growth and changes. 2. Reduced operating costs: The routing optimization mechanism can automatically adjust the use of system resources, maximizing resource utilization, reducing unnecessary resource waste, and lowering system operating costs. 3. Enhanced system stability: By continuously optimizing routing rules and message conversion strategies, the system can better cope with various abnormal situations and emergencies, improving system stability and reliability.

[0175] In this embodiment, innovations such as centralized routing management strategies, intelligent routing rule matching, efficient packet conversion engine, and scalable routing optimization mechanisms significantly improve the system's performance, efficiency, and stability, providing users with a better service experience.

[0176] Figure 6 This is a schematic diagram of the structure of a target service request processing device provided in an embodiment of this application. Figure 6 As shown, the processing device 600 for the target service request includes: a request acquisition module 601, a parameter table acquisition module 602, a response end filtering module 603, a type and format determination module 604, a code acquisition module 605, a message conversion module 606, and a message sending module 607.

[0177] The request acquisition module 601 is used to acquire the business request of the target business in the requesting end. The business request includes business data, the request data format of the business data, and the request type of the business request. The parameter table acquisition module 602 is used to acquire the routing parameter table, wherein the routing parameter table is pushed to each requesting end and each responding end through the application core end. The routing parameter table includes the expected request type and expected data format of each of the multiple responding ends that have a link relationship with the requesting end. The response end filtering module 603 is used to determine the request priority of the business request and the port load of each response end, and to filter out the target end corresponding to the port load that matches the request priority from each response end. The type and format determination module 604 is used to determine the target request type and target data format corresponding to the target end; wherein, the target request type is the expected request type of the filtered response end, and the target data format is the expected data format of the filtered response end; The code acquisition module 605 is used to acquire executable conversion code that matches the format differences between the target data format and the request data format, as well as the type differences between the target request type and the request type; the executable conversion code is obtained by compiling predefined message conversion rules; The message conversion module 606 is used to convert business requests based on executable conversion code to obtain the request message of the target business. The message sending module 607 is used to send request messages to the target end.

[0178] In other embodiments, port load conditions include port load rate; the response end filtering module 603 is further configured to obtain multiple consecutive and non-overlapping load rate intervals configured for port load rate and multiple consecutive and non-overlapping priority intervals configured for request priority; determine the priority interval sorting of the priority interval where the request priority is located in each priority interval, and for each response end, the load rate interval sorting of the load rate interval where the port load rate of the response end is located in each load rate interval; and filter out the target end corresponding to the load rate interval sorting that matches the priority interval sorting among each response end.

[0179] In other embodiments, the code acquisition module 605 is further configured to acquire format conversion code configured for request data format, type conversion code configured for request type, preset format difference threshold configured for format differences between target data format and request data format, and preset type difference threshold configured for type differences between target request type and request type. The format conversion code and type conversion code are both compiled from predefined message conversion rules. If the format difference is greater than the preset format difference threshold and the type difference is less than or equal to the preset type difference threshold, the format conversion code is determined to be executable conversion code. If the type difference is greater than the preset type difference threshold and the format difference is less than or equal to the preset format difference threshold, the type conversion code is determined to be executable conversion code. If the format difference is greater than the preset format difference threshold and the type difference is greater than the preset type difference threshold, the format conversion code and type conversion code are concatenated to obtain executable conversion code.

[0180] In other embodiments, the processing device 600 for the target service request may further include a priority adjustment module, used by the requesting end to obtain a response message of the request message from the target end, wherein the response message includes service parameters and service parameter values; the requesting end determines the adjustment range of the request priority based on the difference between the service parameter threshold configured for the service parameters and the service parameter values; if the service parameter threshold is greater than the service parameter value, the requesting end upgrades the request priority based on the adjustment range; if the service parameter threshold is less than the service parameter value, the requesting end downgrades the request priority based on the adjustment range.

[0181] In other embodiments, the message sending module 607 is further configured to perform digital signature encryption on the request message based on the requester's private key to obtain an encrypted message containing a digital signature; the requester then sends the encrypted message containing the digital signature to the target.

[0182] The target service request processing device provided in this application embodiment can execute the method shown in the above method embodiment. Its implementation principle and beneficial effects can be referred to the relevant description in the method embodiment, and will not be repeated here.

[0183] Figure 7 This is a schematic diagram of the structure of a target service request processing device provided in an embodiment of this application. Figure 7 As shown, the processing device for the target service request includes: a memory 701, a transceiver 702, and at least one processor 703.

[0184] The transceiver 702 is used to interact with other devices to send and receive data. For example, in this embodiment, the transceiver 702 can specifically be used for business request data.

[0185] The memory 701 stores computer program code, which includes computer instructions. These computer instructions run in the processing device for the aforementioned target service request to implement the method shown in the above-described method embodiments. For example, the memory may include high-speed random access memory (RAM), and may also include non-volatile memory (NVM), such as at least one disk storage device, and may also be a USB flash drive, portable hard drive, read-only memory, disk, or optical disc, etc.

[0186] Processor 703 can be a general-purpose processor, including a Central Processing Unit (CPU), a network processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Processor 703 can also be other general-purpose processors. The general-purpose processor can be a microprocessor or any conventional processor.

[0187] The memory 701, transceiver 702, and processor 703 are communicatively connected. For example, the memory 701 and transceiver 702 can be connected to the processor 703 via a system bus to complete communication between them. The system bus can be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, an industry standard architecture (ISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the figure, but this does not mean that there is only one bus or one type of bus.

[0188] Optionally, the memory 701 can be either independent or integrated with the processor 703. When the memory 701 is configured independently, it is connected to the processor 703 via a system bus.

[0189] This application also provides a chip for executing instructions, which is used to execute the technical solution of the target service request processing method in the above embodiments.

[0190] This application also provides a computer-readable storage medium storing computer instructions. When these computer instructions are executed by a processor, they are used to implement the technical solution of the target service request processing method in the above embodiments. Specifically, when the computer instructions are executed by a processor, the target service request processing device can execute the technical solution of the target service request processing method in the above embodiments.

[0191] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium. When the at least one processor executes the computer program, it can implement the technical solution of the target service request processing method in the above embodiments.

[0192] The aforementioned computer-readable storage media can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The computer-readable storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0193] An exemplary computer-readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the computer-readable storage medium can also be a component of the processor. The processor and the computer-readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the computer-readable storage medium can exist as discrete components in an electronic control unit or main control device; this application does not limit this.

[0194] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0195] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.

[0196] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0197] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0198] It should be understood that the steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

[0199] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0200] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for processing target business requests, applied to a business processing system, the business processing system comprising multiple request ends, an application core end, and multiple response ends, wherein a first end of the application core end is connected to each of the request ends, and a second end of the application core end is connected to each of the response ends, characterized in that, The method includes: The requesting end obtains the business request of the target business, and the business request includes business data, the request data format of the business data, and the request type of the business request; The requesting end obtains a routing parameter table, wherein the routing parameter table is pushed to each of the requesting ends and each of the responding ends through the application core end, and the routing parameter table includes the expected request type and expected data format of each of the multiple responding ends that have a link relationship with the requesting end; The requesting end determines the request priority of the service request and the port load of each of the response ends, and among the response ends, the response end whose port load matches the request priority is selected as the target end. The requesting end determines the target request type and target data format corresponding to the target end; wherein, the target request type is the expected request type of the filtered response end, and the target data format is the expected data format of the filtered response end; The requesting end obtains executable conversion code that matches the format differences between the target data format and the request data format, as well as the type differences between the target request type and the request type; the executable conversion code is obtained by compiling predefined message conversion rules; The requesting end performs message conversion on the business request based on the executable conversion code to obtain the request message of the target business; The requesting end sends the request message to the target end.

2. The method according to claim 1, characterized in that, The port load information includes the port load rate; The step of filtering out the target endpoints from among the response endpoints to obtain the target endpoints corresponding to the port load conditions that match the request priority includes: Obtain multiple consecutive and non-overlapping load rate intervals configured for the port load rate, and multiple consecutive and non-overlapping priority intervals configured for the request priority; The priority interval containing the request priority is sorted within the priority intervals of each priority interval, and for each response end, the load rate interval containing the port load rate of the response end is sorted within the load rate intervals of each load rate interval. Among the response terminals, the target terminals corresponding to the load rate interval sorting that matches the priority interval sorting are selected.

3. The method according to claim 1, characterized in that, The executable conversion code that acquires the format differences between the target data format and the request data format, and the type differences between the target request type and the request type, includes: The following steps are taken: obtaining a format conversion code configured for the request data format, a type conversion code configured for the request type, a preset format difference threshold configured for the format difference between the target data format and the request data format, and a preset type difference threshold configured for the type difference between the target request type and the request type, wherein the format conversion code and the type conversion code are both compiled from predefined message conversion rules; If the format difference is greater than the preset format difference threshold, and the type difference is less than or equal to the preset type difference threshold, the format conversion code is determined to be executable conversion code. If the type difference is greater than the preset type difference threshold, and the format difference is less than or equal to the preset format difference threshold, the type conversion code is determined to be the executable conversion code. If the format difference is greater than the preset format difference threshold, and the type difference is greater than the preset type difference threshold, the format conversion code and the type conversion code are concatenated to obtain the executable conversion code.

4. The method according to claim 1, characterized in that, The method further includes: The requesting end obtains a response message of the request message from the target end, wherein the response message includes business parameters and business parameter values, wherein the business parameters include processing time parameters and error rate parameters; The requesting end determines the adjustment range of the request priority based on the difference between the business parameter threshold configured for the business parameter and the business parameter value; If the business parameter threshold is greater than the business parameter value, the requesting end upgrades the request priority based on the adjustment range. If the threshold value of the business parameter is less than the value of the business parameter, the requesting end will downgrade the priority of the request based on the adjustment range.

5. The method according to claim 1, characterized in that, The requesting end sends the request message to the target end, including: The requesting end performs digital signature encryption on the request message based on the requesting end's private key to obtain an encrypted message containing the digital signature; The requesting end sends the encrypted message containing the digital signature to the target end.

6. The method according to claim 5, characterized in that, The method further includes: The target terminal obtains the user permissions of the operating user, as well as the access permissions of the target terminal; When both the user's permissions and the access permissions are greater than the preset permissions, the target terminal performs digital signature verification on the encrypted message containing the digital signature. If the target terminal verifies the encrypted message using the digital signature, the target terminal decrypts the encrypted message containing the digital signature using the private key of the responding terminal to obtain the request message.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: When the routing parameter table is updated, the application core pushes the routing parameter table to each requesting client and each responding client; or... When a new port appears in the business processing system, the application core obtains the expected request type and expected format type of the new port, whereby the new port includes the requesting end or the responding end. The application core writes the expected request type and expected format type of the newly added port into the routing parameter table; The application core pushes the routing parameter table to each requesting end and each responding end.

8. A business processing apparatus, characterized in that, include: The request acquisition module is used to acquire the business request of the target business in the requesting end. The business request includes business data, the request data format of the business data, and the request type of the business request. The parameter table acquisition module is used to acquire the routing parameter table, wherein the routing parameter table is pushed to each of the requesting end and each of the responding end through the application core end, and the routing parameter table includes the expected request type and expected data format of each of the multiple responding ends that have a link relationship with the requesting end; The response end filtering module is used to determine the request priority of the service request and the port load of each response end, and filter out the target end that matches the port load of the request priority from each response end. The type and format determination module is used to determine the target request type and target data format corresponding to the target end; wherein, the target request type is the expected request type of the filtered response end, and the target data format is the expected data format of the filtered response end; The code acquisition module is used to acquire executable conversion code that matches the format differences between the target data format and the request data format, as well as the type differences between the target request type and the request type; the executable conversion code is obtained by compiling predefined message conversion rules; The message conversion module is used to convert the service request into a message based on the executable conversion code to obtain the request message of the target service. The message sending module is used to send the request message to the target terminal.

9. A business processing device, characterized in that, include: A memory and at least one processor; the memory is communicatively connected to the processor; the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, it causes the processing device for the target service request to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

11. A computer program product, characterized in that, When the computer program product is run on a computer / executed by the computer's processor, it implements the method as described in any one of claims 1-7.

Images