Business processing method, apparatus, device, and storage medium

Abstract

This application provides a business processing method, apparatus, device, and storage medium, applicable to the distributed domain. The method includes: a business server obtaining a business processing request corresponding to a target business through the current application; determining the downstream application to be invoked by the current application based on the target business; determining the device types of multiple target deployment devices where the downstream applications reside; determining the traffic ratio of the downstream application across the multiple target deployment devices based on the device type of each target deployment device; and then, according to the traffic ratio, invoking the downstream applications deployed on the multiple target deployment devices to perform business processing, thereby obtaining the business processing result. This application can achieve traffic distribution for business processing requests based on device type, reducing the impact on deployment devices and improving the reliability of business processing when the number of business processing requests is large.

Description

Technical Field

[0001] This application relates to the field of distributed systems, and more particularly to a business processing method, apparatus, device, and storage medium. Background Technology

[0002] With the popularization of distributed system architecture, more and more enterprises are shifting their application systems from monolithic applications to distributed applications, increasing the complexity of coordinating multiple systems.

[0003] In a distributed application system, applications can call each other in the order of invocation. Typically, the caller can initiate a business processing request for the target business to the specified business server based on information such as the IP address of the business server. That is, there is only one link from the client to the multiple business servers corresponding to the target business (there is a calling relationship between each business server), meaning that the traffic of the business processing request is routed along a single link.

[0004] However, when the number of business processing requests is large, the above method puts a heavy burden on the business server of this link, resulting in low reliability of business processing. Summary of the Invention

[0005] This application provides a business processing method, apparatus, device, and storage medium to solve the problem that when the number of business processing requests is large, the above method puts a heavy burden on the business server of this link and the reliability of business processing is low.

[0006] Firstly, this application provides a business processing method applied to a business server, the method comprising:

[0007] Obtain the business processing request corresponding to the target business through the current application;

[0008] Based on the target business, determine the downstream application to be invoked by the current application;

[0009] Determine the device types of the multiple target deployment devices where the downstream application resides;

[0010] Based on the device type of each target deployment device, determine the traffic proportion of the downstream application across the multiple target deployment devices;

[0011] According to the stated traffic ratio, downstream applications deployed in the multiple target deployment devices are invoked to perform business processing and obtain business processing results.

[0012] Secondly, this application provides a business processing method applied to an operation and maintenance server, the method comprising:

[0013] Displays the interface for creating routing rules;

[0014] In the Create Routing Rule interface, create a routing rule. The routing rule includes multiple device types and the traffic ratio of the target application for each device type.

[0015] Determine the business server corresponding to the routing rule;

[0016] Send the routing rules to the business server.

[0017] Thirdly, this application provides a business processing apparatus, comprising:

[0018] The acquisition module is used to obtain the business processing request corresponding to the target business through the current application.

[0019] The first determining module is used to determine the downstream application to be invoked by the current application based on the target business.

[0020] The second determining module is used to determine the device type of multiple target deployment devices where the downstream application is located;

[0021] The third determining module is used to determine the traffic ratio of the downstream application in the multiple target deployment devices based on the device type of each target deployment device;

[0022] The processing module is used to call the downstream applications deployed in the multiple target deployment devices to perform business processing according to the traffic ratio, and obtain the business processing result.

[0023] Fourthly, this application provides a business processing apparatus, comprising:

[0024] The display module is used to show the interface for creating routing rules;

[0025] A creation module is used to create routing rules in the creation routing rule interface. The routing rules include multiple device types and the traffic ratio of the target application for each device type.

[0026] The determination module is used to determine the business server corresponding to the routing rule;

[0027] The sending module is used to send the routing rules to the business server.

[0028] Fifthly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0029] The memory stores computer-executed instructions;

[0030] The processor executes computer execution instructions stored in the memory to implement the business processing method as described in the first or second aspect.

[0031] Sixthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, are used to implement the business processing method as described in the first or second aspect.

[0032] In a seventh aspect, this application provides a computer program product, including a computer program, which, when executed by a computer, is used to implement the business processing method described in the first or second aspect.

[0033] This application provides a business processing method, apparatus, device, and storage medium. A business server obtains a business processing request corresponding to a target business from the current application. Then, based on the target business, it determines the downstream applications to be invoked by the current application and identifies the device types of multiple target deployment devices where the downstream applications reside. Based on the device type of each target deployment device, it determines the traffic ratio of the downstream applications across the multiple target deployment devices. Finally, according to the traffic ratio, it invokes the downstream applications deployed on the multiple target deployment devices to perform business processing and obtain the business processing result. This application can achieve traffic distribution for business processing requests based on device type, reducing the impact on deployment devices and improving the reliability of business processing when the number of business processing requests is large. Attached Figure Description

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

[0035] Figure 1 This is a schematic diagram illustrating one application scenario to which this application applies;

[0036] Figure 2 A schematic diagram illustrating calls between applications as exemplified in this application;

[0037] Figure 3 A flowchart illustrating a business processing method provided in Embodiment 1 of this application;

[0038] Figure 4 A flowchart illustrating another business processing method provided in Embodiment 2 of this application;

[0039] Figure 5 This is a schematic diagram illustrating how a business server calls a target device in a disaster recovery data center to process a business processing request, as an example of this application.

[0040] Figure 6 This is a diagram illustrating another example of how a business server in this application calls the target device in the disaster recovery data center to process a business request.

[0041] Figure 7 Signaling flowchart for yet another service processing method provided in Embodiment 3 of this application;

[0042] Figure 8 This is a schematic diagram of an interface for creating routing rules, as exemplified in this application.

[0043] Figure 9 This is a schematic diagram of the structure of a business processing device provided in Embodiment 4 of this application;

[0044] Figure 10 This is a schematic diagram of the structure of a business processing device provided in Embodiment 5 of this application;

[0045] Figure 11 This is a schematic diagram of the structure of an electronic device provided in Embodiment Six of this application.

[0046] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0047] 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 denote 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.

[0048] It should be noted that the business processing methods, apparatus, equipment and storage media provided in this application can be used in the distributed field, or in any field other than the distributed field. The application fields of the business processing methods, apparatus, equipment and storage media provided in this application are not limited.

[0049] With the popularization of distributed system architecture, more and more enterprises are shifting their application systems from monolithic applications to distributed applications, increasing the complexity of coordinating multiple systems.

[0050] Currently, applications in a distributed application system can call each other in the order of invocation. Typically, the caller can initiate a business processing request for the target business to the specified business server based on information such as the IP address of the business server. That is, there is only one link from the client to the multiple business servers corresponding to the target business (there is a calling relationship between each business server), meaning that the traffic of the business processing request is routed along a single link.

[0051] However, when the number of business processing requests is large, the above method puts a lot of pressure on the business server of this link, which can easily cause business paralysis.

[0052] Therefore, this application provides a business processing method. After the business server obtains the business processing request of the target business through the current application, it can call the downstream applications deployed on multiple deployment devices to perform business processing according to the traffic ratio of the downstream applications to be called by the current application on multiple deployment devices, and obtain the business processing result. This application can realize the traffic distribution of business processing requests according to the device type. When the number of business processing requests is large, the impact on the deployment devices can be reduced, thereby reducing the possibility of business paralysis, that is, improving the reliability of business processing.

[0053] To more clearly explain this application, the following is a description of the terms used in the embodiments of this application:

[0054] An application can typically be composed of multiple components, each representing a different functional module (which may be referred to as a business in this application). Each component includes multiple microservice applications. For example, an application may include functional modules such as "deposit business" and "credit card business". The "deposit business" may also include multiple microservice applications that provide services to users.

[0055] Gateway application: This can be an application used for communication between components. That is, calls between components need to be made through a gateway application.

[0056] Non-gateway applications: These refer to applications within components, i.e., ordinary microservice applications.

[0057] To facilitate understanding, the following will be combined with... Figure 1 The examples illustrate the application scenarios to which the embodiments of this application are applicable.

[0058] Figure 1 Please refer to the diagram illustrating one application scenario to which this application applies. Figure 1 It includes: maintenance server 101, business server A102, business server B103, and business server C104. Maintenance server 101, business server A102, business server B103, and business server C104 can communicate with each other via the Internet.

[0059] In one possible implementation, the current application is deployed in business server A102, the downstream application of the current application is deployed in business server B103, and the downstream application of the current application is deployed in business server C104. There is a calling relationship between the current application and the downstream application. For example, the application calling order is the current application and the downstream application, that is, the current application calls the downstream application.

[0060] The operations and maintenance server 101 can be used to establish routing rules for target applications. The operations and maintenance server 101 can send routing rules to the business server where the preset application resides. Taking the current application as an example, if the downstream application is the target application, then the current application can be the preset application. Therefore, the operations and maintenance server 101 can send routing rules to the business server 102.

[0061] It is understood that there can be multiple business servers A102, B103, and C104, which are not shown in the figure.

[0062] For example, to more clearly describe the calls between applications, please refer to... Figure 2 , Figure 2 This section explains the calls between applications. The current application in Component 2 can receive business processing requests initiated by the caller in Component 1. Then, according to the routing rules sent by the operations and maintenance platform, it routes the traffic of the business processing requests to downstream applications A in different deployment devices according to different traffic ratios. Figure 2 In this context, x% of traffic corresponds to one link, and y% of traffic corresponds to another link, and so on. Figure 2 Taking the link corresponding to x% of the traffic in the diagram as an example, after the x% traffic of the business processing request is routed to the downstream application A, the downstream application A will route the x% traffic of the business processing request to the downstream application of A in this link. Here, for the sake of simplicity, only the downstream application A and its downstream applications are shown as examples. In actual applications, there may be other downstream applications of A, which are not shown in the diagram.

[0063] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0064] Figure 3 This is a flowchart illustrating a business processing method provided in Embodiment 1 of this application. This method can be executed by a business server or by a business processing device located within the business server. This device can be a chip, a chip module, or an integrated development environment (IDE), etc. The following example uses a business server. Figure 3 The method includes the following steps:

[0065] S301. Obtain the business processing request corresponding to the target business through the current application.

[0066] The business server can obtain the business processing request corresponding to the target business through the current application. The number of business processing requests can be one or more.

[0067] In one possible implementation, the caller initiating the business processing request can be an application in an upstream component of the component where the current application resides.

[0068] In another possible implementation, the caller initiating the business processing request can be the upstream application of the current application. It can be understood that the upstream application of the current application belongs to the same component as the current application.

[0069] S302. Based on the target business, determine the downstream applications that the current application needs to call.

[0070] After receiving a business processing request, the business server can determine the downstream application to be called by the current application based on the target business.

[0071] For example, the business server can obtain application information for multiple applications of the target business from the registry center database. This application information may include the application's identifier and the identifiers of each application's downstream applications. The registry center database contains multiple applications for multiple businesses. After obtaining the application information for the target business's multiple applications, the business server can determine the downstream application to be invoked by the current application among these applications.

[0072] S303. Determine the device type of the multiple target deployment devices where the downstream application is located.

[0073] After determining the downstream application to be invoked by the current application, the business server can determine the device type of multiple target deployment devices where the downstream application is located.

[0074] In this application embodiment, a server is the smallest unit of application deployment, a physical unit includes multiple servers, and a data center may include multiple physical units.

[0075] For example, the device type can be determined based on the preset tags in the device information of the target deployment device. Deployment devices with the same preset tags in their device information have the same device type. For example, target deployment devices with tag A in their device information have the same device type, that is, they are the same type of device. Target deployment devices with tag B in their device information also have the same device type.

[0076] S304. Determine the traffic ratio of downstream applications across multiple target deployment devices based on the device type of each target deployment device.

[0077] In this embodiment, the traffic ratios corresponding to target deployment devices of different device types are different. After determining the device types of multiple target deployment devices where downstream applications reside, the business server can determine the traffic ratio of downstream applications in multiple target deployment devices based on the device type of each target deployment device.

[0078] S305. Based on the traffic ratio, call the downstream applications deployed in multiple target deployment devices to perform business processing and obtain the business processing results.

[0079] The business server can call downstream applications deployed on multiple target deployment devices to perform business processing based on the traffic ratio, and obtain the business processing results corresponding to the business processing requests.

[0080] For example, the service server can route service processing request traffic to a target deployment device that includes tag A in the device information at a rate of x%, and can route service processing request traffic to a target deployment device that includes tag B in the device information at a rate of y%. Here, the sum of x% and y% is 100%, for example, x can be 20 and y can be 80.

[0081] In this embodiment, the service server obtains the service processing request corresponding to the target service through the current application, then determines the downstream application to be called by the current application based on the target service, and determines the device types of multiple target deployment devices where the downstream applications are located. Based on the device type of each target deployment device, the traffic ratio of the downstream application in the multiple target deployment devices is determined. Then, according to the traffic ratio, the downstream applications deployed in the multiple target deployment devices are called to perform service processing, and the service processing result is obtained. This application can realize the traffic distribution of service processing requests according to device type, which can reduce the impact on deployment devices and improve the reliability of service processing when the number of service processing requests is large.

[0082] The following describes another business processing method provided in this application through Embodiment 2.

[0083] Figure 4 This is a flowchart illustrating another business processing method provided in Embodiment 2 of this application. This method can be executed by a business server or by a distributed application deployment device located within the business server. This device can be a chip, a chip module, an IDE, etc. The following uses a business server as an example. Figure 4 The method includes the following steps:

[0084] S401. Obtain the business processing request corresponding to the target business through the current application.

[0085] S402. Based on the target business, determine the downstream applications that the current application needs to call.

[0086] For a detailed description of S401 and S402, please refer to the above embodiments, which will not be repeated here.

[0087] S403. Determine the device type of multiple target deployment devices where downstream applications reside.

[0088] In one possible implementation, the business server can obtain the device types of multiple deployment devices for downstream applications from the registry center database. Specifically, the business server retrieves device information for multiple deployment devices of the downstream application in multiple physical units from the registry center database, and each device information can include the device type. For example, the device type can be determined by a preset tag or by other methods. Then, the business server determines the device types of multiple target deployment devices from the device types of the multiple deployment devices.

[0089] In one possible implementation, the business server can obtain device information of multiple deployed devices of downstream applications in multiple physical units from the registry center database, and then determine the target physical unit from the multiple physical units according to the identifier of the target physical unit in the target routing rule, and then determine the target deployment device from the deployed devices in the target physical unit.

[0090] S404. Obtain at least one routing rule, which includes multiple device types and the traffic ratio of downstream applications for each device type.

[0091] The business server can obtain at least one routing rule.

[0092] In one possible implementation, the business server can store at least one routing rule, which is sent by the operations and maintenance server. The routing rule includes multiple device types and the traffic proportion of downstream applications for each device type. For example, the multiple device types can be represented by different preset tags.

[0093] S405. In at least one routing rule, determine the target routing rule.

[0094] The business server stores at least one routing rule, and the business server can determine the target routing rule from at least one routing rule.

[0095] In one possible implementation, the business server can determine the priority of at least one routing rule. Specifically, each routing rule includes a priority value, for example, the priority value is represented by a number, with smaller values ​​indicating higher priority. The business server can then use the highest-priority routing rule from the at least one routing rule as the target routing rule.

[0096] S406. Based on the device type of each target deployment device, determine the traffic ratio of downstream applications across multiple target deployment devices in the target routing rules.

[0097] After determining the target routing rules, the business server can determine the traffic ratio of downstream applications on multiple target deployment devices based on the multiple device types in the target routing rules and the traffic ratio of downstream applications on each device type, according to the device type of each target deployment device.

[0098] For example, the target routing rule includes device type 1 and device type 2, where device type 1 corresponds to 20% of the traffic and device type 2 corresponds to 80% of the traffic. For instance, if there are 10 target deployed devices (a, b, c, d, e, f, g, i, j, k), with 4 (d, e, f, g) being device type 1 and 6 (a, b, c, i, j, k) being device type 2, then the business server can determine that the traffic proportion corresponding to these 4 (d, e, f, g) target deployed devices is 20%, and the traffic proportion corresponding to these 6 (a, b, c, i, j, k) target deployed devices is 80%.

[0099] S407. Based on the traffic ratio, call the downstream applications deployed in multiple target deployment devices to perform business processing and obtain the business processing results.

[0100] Once the traffic ratio is determined, the business server can call downstream applications deployed on multiple target deployment devices to perform business processing and obtain the business processing results.

[0101] Taking the example in S406, the business server can route 20% of the traffic of the business processing request to the above 4 target deployment devices (d, e, f, g), and at the same time route 80% of the traffic of the business processing request to the above 6 target deployment devices (a, b, c, i, j, k).

[0102] In one possible implementation, if a downstream application deployed on the first of multiple target deployment devices fails during business processing, the business server can also call the target device in the disaster recovery data center to process the business processing request. Each device in the disaster recovery data center includes at least one routing rule, and the devices in the disaster recovery data center have the same configuration as the multiple target deployment devices.

[0103] For example, Figure 5 This is a schematic diagram illustrating how a business server calls a target device in a disaster recovery data center to process a business request, as an example of this application. Figure 6This is a schematic diagram illustrating another example of a business server calling a target device in a disaster recovery data center to process a business request. The devices in the disaster recovery data center have the same configuration as the multiple target deployment devices. If the downstream application deployed by the first deployment device fails, the business server can route the traffic of the business processing request to the application on the target device in the disaster recovery data center. The deployment of the target device in the disaster recovery data center is the same as the deployment of the first deployment device in its own data center, and the application deployed on the target device is the same as the application deployed on the first deployment device.

[0104] As can be seen from the figure, Figure 5 If the downstream application is a gateway application, then the traffic of business processing requests can be directly routed to the application in the target device in the disaster recovery data center. Figure 6 If the downstream applications are not gateway applications, the business server needs to route the traffic of business processing requests to the gateway application in the disaster recovery data center, and then the gateway application will route the traffic of business processing requests to the application on the target device.

[0105] In this embodiment, the business server obtains the business processing request corresponding to the target business through the current application, then determines the downstream application to be called by the current application based on the target business, and determines the device types of multiple target deployment devices where the downstream application is located. Next, it obtains at least one routing rule, and within this rule, determines a target routing rule. Based on the device type of each target deployment device, the target routing rule determines the traffic ratio of the downstream application across the multiple target deployment devices. Then, according to the traffic ratio, it calls the downstream applications deployed on the multiple target deployment devices to perform business processing, obtaining the business processing result. This application can achieve traffic distribution for business processing requests based on device type, reducing the impact on deployment devices and improving the reliability of business processing when the number of business processing requests is large.

[0106] The following describes another business processing method provided in Embodiment 3 of this application. Specifically, the interaction between the operation and maintenance server and the business server will be described.

[0107] Figure 7 The signaling flowchart for another service processing method provided in Embodiment 3 of this application is shown in the reference diagram. Figure 7 The method includes the following steps:

[0108] S701, the operation and maintenance server displays the interface for creating routing rules.

[0109] The operations and maintenance administrator can click "Create New Routing Rule" on the corresponding interface to be redirected to the routing rule creation page.

[0110] On the S702 maintenance server, create routing rules in the routing rule creation interface.

[0111] The operations and maintenance administrator can create routing rules through the routing rule creation interface on the operations and maintenance server. The routing rules include multiple device types and the traffic ratio of the target application for each device type.

[0112] S703, the operation and maintenance server determines the business server corresponding to the routing rule.

[0113] In one possible implementation, the routing rule may also include a caller parameter, that is, the operation and maintenance server can determine the preset application of the target application based on the caller parameter, and then determine the deployment device where the preset application is located as the business server corresponding to the routing rule. The caller parameter includes the application type of the preset application.

[0114] Specifically, if the target application is a gateway application, the default application can be any one of the following: the upstream application of the target application, an application in the upstream component of the component containing the target application, or a specified application. In other words, if the target application is a gateway application, routing rules can be sent to any one of the following applications on the deployment device: the upstream application of the target application, an application in the upstream component of the component containing the target application, or a specified application.

[0115] If the target application is a non-gateway application, the default application is either the upstream application of the target application or a specified application. In other words, if the target application is a non-gateway application, routing rules can be sent to the deployment device where either the upstream application or the specified application is located.

[0116] Specifically, the upstream application of the target application, the application in the upstream component of the component where the target application is located, and the specified application can be determined by preset tags, and the deployment device of the upstream application of the target application, the application in the upstream component of the component where the target application is located, or the specified application is located in the specified physical unit.

[0117] For example, such as Figure 8 As shown, Figure 8 This is a schematic diagram of the interface for creating routing rules. The application type of the preset application in the caller parameters can be a component, an application, or a custom application. Each application type includes a matching relationship and a tag value. The matching relationship can be any one of equal to, not equal to, contain, or not contain.

[0118] For the option with the application type being component, the matching relationship can be equal to, and the label value can be the name of the component.

[0119] For the option with the application type "application", the matching relationship can be "equal to", and the tag value can be the name of the application.

[0120] For the option of application type is custom application, the matching relationship can be any of the following: equal to, not equal to, contain, and not contain. The tag value can be a preset tag value, such as tag1. That is, the application information that is equal to, not equal to, contains, or does not contain tag1 is a custom application.

[0121] For example, if the application type in the routing rule is a component, and since this component is the upstream component of the component where the current application is located, the tag value can be set to the name 1 of the upstream component, and the matching relationship is equal to. Then, the default application is all applications in the upstream component with name 1.

[0122] For example, if the application type in the routing rule is "application", and since this application is the upstream application of the current application, the tag value can be set to the name 2 of the upstream application, and the matching relationship is equal to. Therefore, the default application is the application whose application name is name 2.

[0123] For example, if the application type in the routing rule is a custom application, since the application is a specified application, the tag value can be a preset tag value, such as tag1. The matching relationship is not equal to. So, for example, if the application information of a certain application includes tag2 and tag3, and tag2 and tag3 are not equal to tag1, that is, tag1 does not exist in the application information, then it can be determined that the application is a preset application.

[0124] exist Figure 8 In addition, routing rules can also include the rule name, the rule's availability status (available or unavailable), and priority.

[0125] In one possible implementation, the routing rules may also include application information of the target application, which includes the name of the component where the target application resides, the application name of the target application, and the identifier of the physical unit where the target application resides. Figure 8 The destination parameter is the application information of the target application. The device type of the deployment device can be determined based on the preset tags in the device information of the deployment device where the target application is located.

[0126] by Figure 8 For example, if the preset tag in the device information of the deployment device where the target application is located is tagA, then the traffic ratio corresponding to that device is 80%. If the preset tag in the device information of the deployment device where the target application is located is tagB, then the traffic ratio corresponding to that device is 20%. For details on calling the target application according to the traffic ratio, please refer to the above embodiment two, which will not be repeated here. The downstream application in embodiment two can be understood as the target application in this embodiment.

[0127] It's understandable that when operations and maintenance personnel create routing rules through the operations and maintenance server, they can set corresponding traffic tags based on the performance and computing power of the devices deployed to the target application, enabling higher-performance devices to handle more business processing requests. Correspondingly, the preset tag values ​​will also be added to the device information of the devices deployed to the target application.

[0128] S704. The operation and maintenance server sends the routing rules to the business server corresponding to the routing rules.

[0129] S705, the operations and maintenance server sends routing rules to the servers in the disaster recovery data center.

[0130] The operation and maintenance server can send routing rules to the devices in the disaster recovery data center (i.e., all servers in the disaster recovery data center). The disaster recovery data center is used as a backup data center when the deployment device of the target application fails during business processing. The devices in the disaster recovery data center have the same configuration as the deployment device of the target application. It can be understood that the devices mentioned in this application can be considered as servers.

[0131] In this embodiment, the operations and maintenance server can create routing rules, determine the corresponding business servers, and send the routing rules to the business servers. This allows the business servers to process application calls for business processing requests according to the routing rules. This application can distribute traffic for business processing requests based on device type, reducing the impact on deployed devices and improving the reliability of business processing when the number of business processing requests is large.

[0132] Figure 9 This is a schematic diagram of a service processing apparatus provided in Embodiment 4 of this application. (Reference) Figure 9 The device 90 includes: an acquisition module 901, a first determination module 902, a second determination module 903, a third determination module 904, and a processing module 905.

[0133] The acquisition module 901 is used to obtain the business processing request corresponding to the target business through the current application.

[0134] The first determining module 902 is used to determine the downstream application to be called by the current application based on the target business.

[0135] The second determination module 903 is used to determine the device type of multiple target deployment devices where the downstream application is located.

[0136] The third determination module 904 is used to determine the traffic ratio of downstream applications across multiple target deployment devices based on the device type of each target deployment device.

[0137] Processing module 905 is used to call downstream applications deployed in multiple target deployment devices to perform business processing according to the traffic ratio, and obtain the business processing results.

[0138] In one possible implementation, the third determining module 904 is specifically used for:

[0139] Obtain at least one routing rule, which includes multiple device types and the traffic ratio of downstream applications for each device type.

[0140] In at least one routing rule, determine the target routing rule.

[0141] Based on the device type of each target deployment device, the target routing rules determine the proportion of traffic from downstream applications across multiple target deployment devices.

[0142] In one possible implementation, the third determining module 904 is specifically used for:

[0143] Determine the priority of each routing rule.

[0144] The highest priority routing rule among at least one routing rule is selected as the target routing rule.

[0145] In one possible implementation, the second determining module 903 is specifically used for:

[0146] Retrieve the device types of multiple deployed devices for downstream applications from the registry center database.

[0147] Determine the device types of multiple target deployment devices from among the device types of multiple deployed devices.

[0148] In one possible implementation, device 90 further includes a calling module, which is specifically used for:

[0149] The target device in the disaster recovery data center is invoked to process the business processing request. Each device in the disaster recovery data center includes at least one routing rule, and the devices in the disaster recovery data center have the same configuration as the multiple target deployment devices.

[0150] The apparatus in this embodiment can be used to execute the technical solutions of the above method embodiments. The specific implementation methods and technical effects are similar, and will not be described again here.

[0151] Figure 10 This is a schematic diagram of a service processing apparatus provided in Embodiment 5 of this application. (Reference) Figure 10 The device 100 includes: a display module 1001, a creation module 1002, a determination module 1003, and a sending module 1004.

[0152] Display module 1001 is used to display the interface for creating routing rules.

[0153] The creation module 1002 is used to create routing rules in the routing rule creation interface. The routing rules include multiple device types and the traffic ratio of the target application for each device type.

[0154] The determination module 1003 is used to determine the business server corresponding to the routing rule.

[0155] The sending module 1004 is used to send routing rules to the business server.

[0156] In one possible implementation, the determining module 1003 is specifically used for:

[0157] Based on the caller parameters, determine the preset application for the target application. The caller parameters include the application type of the preset application.

[0158] The deployment device where the preset application is located is identified as the business server corresponding to the routing rule.

[0159] In one possible implementation, if the target application is a gateway application, the default application is any one of the upstream application of the target application, the application in the upstream component of the component where the target application is located, or a specified application.

[0160] If the target application is a non-gateway application, the default application is the upstream application of the target application or a specified application.

[0161] In one possible implementation, the sending module 1004 is further configured to:

[0162] The routing rules are sent to the devices in the disaster recovery data center. The disaster recovery data center is used as a backup data center when the deployment devices of the target application fail during business processing. The devices in the disaster recovery data center have the same configuration as the deployment devices of the target application.

[0163] Figure 11 This is a schematic diagram of the structure of an electronic device provided in Embodiment Six of this application, as shown below. Figure 11 As shown, the electronic device 110 may include at least one processor 1101 and a memory 1102.

[0164] The memory 1102 is used to store programs. Specifically, the program may include program code, which includes computer-executable instructions.

[0165] The memory 1102 may include random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device.

[0166] The processor 1101 is used to execute computer execution instructions stored in the memory 1102 to implement the method described in the foregoing method embodiments. The processor 1101 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0167] Optionally, the electronic device 110 may also include a communication interface 1103. In specific implementations, if the communication interface 1103, memory 1102, and processor 1101 are implemented independently, they can be interconnected via a bus to complete communication. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not imply that there is only one bus or one type of bus.

[0168] Optionally, in a specific implementation, if the communication interface 1103, memory 1102 and processor 1101 are integrated on a single chip, then the communication interface 1103, memory 1102 and processor 1101 can communicate through an internal interface.

[0169] Electronic device 110 can be a chip, chip module, IDE, server, etc.

[0170] The electronic device in this embodiment can be used to execute the technical solutions of the above method embodiments. The specific implementation methods and technical effects are similar, and will not be repeated here.

[0171] Embodiment 7 of this application provides a computer-readable storage medium, which may include various media capable of storing computer-executable instructions, such as USB flash drives, portable hard drives, read-only memory (ROM), RAM, disks, or optical discs. Specifically, the computer-readable storage medium stores computer-executable instructions, which, when executed by a computer, cause the technical solution shown in the above method embodiment to be executed. The specific implementation and technical effects are similar and will not be repeated here.

[0172] This application provides a computer program product in embodiment eight, which includes a computer program. When the computer program is executed by a computer, the technical solution shown in the above method embodiment is executed. The specific implementation method and technical effect are similar, and will not be repeated here.

[0173] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0174] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A business processing method, characterized in that, Applied to a business server, the method includes: Obtain the business processing request corresponding to the target business through the current application; Based on the target business, application information of multiple applications of the target business is obtained from the registry center database. Among the multiple applications, the downstream application to be called by the current application is determined. The application information includes the application identifier and the identifier of the downstream application of each application. Obtain the device types of multiple deployment devices of the downstream application from the registry center database; From the device types of the plurality of deployed devices, determine the device types of the plurality of target deployed devices; Obtain at least one routing rule, wherein the routing rule includes multiple device types and the traffic ratio of the downstream application for each device type; In at least one routing rule, determine the target routing rule; Based on the device type of each target deployment device, the traffic ratio of the downstream application in the multiple target deployment devices is determined in the target routing rule. The routing rule is created by the operation and maintenance server in the routing rule creation interface. The preset application of the target application is determined according to the caller parameters. The caller parameters include the application type of the preset application. After determining the deployment device where the preset application is located as the business server corresponding to the routing rule, the routing rule is sent to the business server. According to the traffic ratio, downstream applications deployed in the multiple target deployment devices are invoked to perform business processing and obtain business processing results; If a downstream application deployed on the first of the plurality of target deployment devices malfunctions during business processing; The method further includes: The target device in the disaster recovery data center is invoked to process the service request. Each device in the disaster recovery data center includes at least one routing rule, and the devices in the disaster recovery data center have the same configuration as the multiple target deployment devices.

2. The method according to claim 1, characterized in that, Determining the target routing rule in at least one routing rule includes: Determine the priority of each routing rule; The routing rule with the highest priority among the at least one routing rule is determined as the target routing rule.

3. A business processing method, characterized in that, Applied to operation and maintenance servers, the method includes: Displays the interface for creating routing rules; In the Create Routing Rule interface, create a routing rule. The routing rule includes multiple device types and the traffic ratio of the target application for each device type. The routing rule also includes caller parameters, based on which a preset application is determined to call the target application, and the caller parameters include the application type of the preset application; The deployment device where the preset application is located is determined as the business server corresponding to the routing rule; The routing rules are sent to the business server so that the business server can obtain the business processing request corresponding to the target business through the current application; according to the target business, the application information of multiple applications of the target business is obtained from the registry center database, and the downstream application to be called by the current application is determined from the multiple applications; the device types of multiple deployment devices of the downstream application are obtained from the registry center database; the device types of multiple target deployment devices are determined from the device types of the multiple deployment devices; according to the device type of each target deployment device, the traffic ratio of the downstream application in the multiple target deployment devices is determined in the target routing rules; according to the traffic ratio, the downstream application deployed in the multiple target deployment devices is called to perform business processing to obtain the business processing result; if the downstream application deployed in the first deployment device among the multiple target deployment devices fails during business processing, the business server calls the target device in the disaster recovery data center to perform business processing for the business processing request, and each device in the disaster recovery data center includes at least one routing rule, and the devices in the disaster recovery data center have the same configuration as the multiple target deployment devices.

4. The method according to claim 3, characterized in that, If the target application is a gateway application, the preset application is any one of the upstream application of the target application, the application in the upstream component of the component where the target application is located, and the specified application. If the target application is a non-gateway application, the preset application is the upstream application of the target application or a designated application.

5. The method according to claim 3 or 4, characterized in that, The method further includes: The routing rules are sent to the devices in the disaster recovery data center, which serves as a backup data center when the deployment device of the target application fails during business processing. The devices in the disaster recovery data center have the same configuration as the deployment device of the target application.

6. A business processing apparatus, characterized in that, include: The acquisition module is used to obtain the business processing request corresponding to the target business through the current application. The first determining module is used to obtain application information of multiple applications of the target business from the registration center database according to the target business, and determine the downstream application to be called by the current application among the multiple applications. The application information includes the identifier of the application and the identifier of the downstream application of each application. The second determining module is used to obtain the device types of multiple deployment devices of the downstream application from the registration center database; and determine the device types of multiple target deployment devices from the device types of the multiple deployment devices. The third determining module is used to obtain at least one routing rule, which includes multiple device types and the traffic ratio of the downstream application corresponding to each device type; determine a target routing rule in the at least one routing rule; and determine the traffic ratio of the downstream application in the multiple target deployment devices in the target routing rule according to the device type of each target deployment device. The routing rule is created by the operation and maintenance server in the routing rule creation interface, and the preset application of the target application is determined according to the caller parameters, which include the application type of the preset application. After determining the deployment device where the preset application is located as the business server corresponding to the routing rule, the module sends the routing rule to the business server. The processing module is used to call the downstream applications deployed in the multiple target deployment devices to perform business processing according to the traffic ratio, and obtain the business processing result; If a downstream application deployed on the first of the plurality of target deployment devices malfunctions during business processing; Calling the module, specifically used for: The target device in the disaster recovery data center is invoked to process the service request. Each device in the disaster recovery data center includes at least one routing rule, and the devices in the disaster recovery data center have the same configuration as the multiple target deployment devices.

7. A business processing device, characterized in that, include: The display module is used to show the interface for creating routing rules; A creation module is used to create routing rules in the creation routing rule interface. The routing rules include multiple device types and the traffic ratio of the target application for each device type. The determination module is used to determine the preset application to call the target application based on the caller parameters, wherein the caller parameters include the application type of the preset application; The deployment device where the preset application is located is determined as the business server corresponding to the routing rule; The sending module is used to send the routing rules to the business server so that the business server can obtain the business processing request corresponding to the target business through the current application; Based on the target business, obtain application information of multiple applications of the target business from the registry center database, and determine the downstream application to be called by the current application from among the multiple applications; Obtain the device types of multiple deployment devices of the downstream application from the registry center database; determine the device types of multiple target deployment devices from the device types of the multiple deployment devices; Based on the device type of each target deployment device, the traffic ratio of the downstream application in the multiple target deployment devices is determined in the target routing rules; according to the traffic ratio, the downstream applications deployed in the multiple target deployment devices are invoked to perform business processing and obtain the business processing result; If a downstream application deployed on the first of the plurality of target deployment devices fails during business processing, the business server calls the target device in the disaster recovery data center to process the business processing request. Each device in the disaster recovery data center includes at least one routing rule, and the devices in the disaster recovery data center have the same configuration as the plurality of target deployment devices.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the business processing method as described in claim 1 or 2, or the business processing method as described in claim 3 or 4.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the business processing method as described in claim 1 or 2, or the business processing method as described in claim 3 or 4.

Images