Route scheduling system and method

Abstract

The invention discloses a routing scheduling system and method. The system comprises an aggregation root, a routing domain and a scheduling domain. The aggregation root is used for acquiring a service request message reported by a user; wherein the service request message comprises routing information used for determining a routing key; the routing domain is used for determining a routing result of the service request message according to the service request message and a pre-configured routing key strategy; wherein the routing key strategy is a predicate operation rule between routing keys set by a user; the scheduling domain is used for sending the service request message to the target application according to the routing result; wherein the target application comprises a first target application and a second target application, and the versions of the first target application and the second target application are different. By supporting a complex routing key strategy such as a predicate operation rule between pre-configured routing keys, the granularity control of routing is finer, and the traffic of the service request message can be accurately shunted in any proportion.

Description

Technical Field

[0001] The present invention relates to the technical field of routing scheduling, and in particular to a routing scheduling system and method. Background Art

[0002] With the advancement of technology, more and more financial institutions are migrating their technology stacks. Due to the large client base and wide impact of these institutions, the migration process often involves a phase of running services in parallel with the old and new technology stacks. These organizations typically rely on mature gateway products to achieve smooth traffic scheduling. However, the routing functionality provided by these gateway products often focuses on generality and business independence, lacking the flexibility to support more granular routing functions that are highly relevant to business domains. Summary of the Invention

[0003] The present invention provides a routing scheduling system and method, which can make the granularity control of routing more refined and achieve the effect of accurately diverting the service request message traffic in any proportion.

[0004] In a first aspect, an embodiment of the present invention provides a routing scheduling system, wherein the routing scheduling system includes an aggregate root, a routing domain, and a scheduling domain; wherein,

[0005] The aggregate root is used to obtain the service request message reported by the user; wherein the service request message includes routing information for determining the routing key;

[0006] The routing domain is used to determine the routing result of the service request message according to the service request message and a preconfigured routing key strategy; wherein the routing key strategy is a predicate operation rule between routing keys set by the user;

[0007] The scheduling domain is used to send the service request message to the target application according to the routing result; wherein the target application includes a first target application and a second target application, and the first target application and the second target application have different versions.

[0008] In a second aspect, an embodiment of the present invention further provides a routing scheduling method, which is applied to a routing scheduling system. The method includes:

[0009] Obtaining a service request message reported by a user through an aggregate root; wherein the service request message includes routing information for determining a routing key;

[0010] Determining a routing result of the service request message according to the service request message and a pre-configured routing key strategy through a routing domain; wherein the routing key strategy is a predicate operation rule between routing keys set by the user;

[0011] The service request message is sent to a target application according to the routing result through a scheduling domain; wherein the target application includes a first target application and a second target application, and the first target application and the second target application have different versions.

[0012] An embodiment of the present invention provides a routing and scheduling system, which includes an aggregate root, a routing domain, and a scheduling domain. The aggregate root is used to obtain a service request message reported by a user; the service request message includes routing information for determining a routing key; the routing domain is used to determine a routing result of the service request message based on the service request message and a preconfigured routing key strategy; the routing key strategy is a predicate operation rule between routing keys set by the user; the scheduling domain is used to send the service request message to a target application based on the routing result; the target application includes a first target application and a second target application, and the first target application and the second target application have different versions. By supporting complex routing key strategies such as predicate operation rules between preconfigured routing keys, the granularity control of routing is made more refined, and the service request message traffic can be accurately diverted in any proportion.

[0013] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0015] Figure 1 This is a schematic structural diagram of a routing scheduling system provided by an embodiment of the present invention;

[0016] Figure 2 This is a schematic diagram of the structure of a routing domain provided by an embodiment of the present invention;

[0017] Figure 3 This is a schematic diagram of the structure of a scheduling domain provided by an embodiment of the present invention;

[0018] Figure 4 is a structural diagram of another routing scheduling system provided by an embodiment of the present invention;

[0019] Figure 5 This is a schematic diagram of the structure of a configuration domain provided by an embodiment of the present invention;

[0020] Figure 6 is a structural diagram of another routing scheduling system provided by an embodiment of the present invention;

[0021] Figure 7 This is a schematic diagram of the structure of a decision domain provided by an embodiment of the present invention;

[0022] Figure 8 This is a flow chart of a routing scheduling method provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0023] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0024] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0025] Figure 1 This is a structural diagram of a routing scheduling system provided by an embodiment of the present invention. Figure 1 As shown, the routing and scheduling system 100 includes: an aggregate root 101, a routing domain 102, and a scheduling domain 103; wherein,

[0026] Aggregate root 101 is used to obtain the service request message reported by the user; wherein the service request message includes routing information for determining the routing key.

[0027] The routing domain 102 is used to determine the routing result of the service request message according to the service request message and a pre-configured routing key strategy; wherein the routing key strategy is a predicate operation rule between routing keys set by the user.

[0028] The scheduling domain 103 is used to send the service request message to the target application according to the routing result; wherein the target application includes a first target application and a second target application, and the first target application and the second target application have different versions.

[0029] Routing keys are key parameters or fields that determine how data or requests are routed to specific destinations. Their core goal is to accurately distribute data, messages, or requests to corresponding nodes, services, queues, or slices through specific rules, thereby supporting load balancing, shard management, or business isolation. Routing key policies are user-defined predicate operation rules between routing keys. Predicate operation rules are the core mechanism for determining which requests should be handled by a specific route. Only requests that meet all predicate operation rules are routed to the corresponding target application.

[0030] The target applications include a first target application and a second target application, and the first target application and the second target application are of different versions. Generally, the second target application version is newer than the first target application version. By adjusting the ratio of service request messages routed to the first target application and the second target application, a transition from the first target application to the second target application can be achieved.

[0031] In an embodiment of the present invention, the routing and scheduling system 100 adopts the domain-driven design concept to divide functions and aggregates each domain through the aggregate root 101. At the same time, the aggregate root 101 serves as the access entrance of the routing and scheduling system 100, and is used to obtain the business request message reported by the user. The business request message includes routing information, and the routing information is used to determine the routing key of the business request message. Afterwards, the routing result of the business request message can be determined according to the business request message and the preconfigured routing key strategy through the routing domain 102. Specifically, the routing key of the business request message can be determined first, and then the routing result of the business request message can be determined according to the routing key of the business request message and the predicate operation rules between the routing keys in the preconfigured routing key strategy. Finally, the business request message can be sent to the target application according to the routing result through the scheduling domain 103, so as to achieve accurate diversion of the business request message. By supporting complex routing key strategies such as predicate operation rules between preconfigured routing keys, the granularity control of routing is made more refined, and the business request message traffic sent to the first target application and the second target application can be accurately diverted in any proportion.

[0032] Optionally, the deployment modes of the routing scheduling system 100 include independent mode deployment, sidecar mode deployment and component mode deployment.

[0033] Among them, the independent mode deployment is to deploy the routing scheduling system 100 after the gateway product, and directly take over the business request message traffic. This mode regards the routing scheduling system 100 as an independent layer, and the business request message traffic passes through the hardware load balancing device to reach the gateway layer, and then flows through the aggregate root 101 of the routing scheduling system 100 through the gateway for fine-grained traffic control. The sidecar mode (Sidecar) deployment is to directly deploy the routing scheduling system 100 to the same container as the target application, but it belongs to a different process, and the business request message traffic is taken over by the aggregate root 101. The component deployment mode is to directly publish the routing scheduling system 100 as a JAR package, directly introduce the JAR package into the target application, and call the method in the aggregate root 101 in the application aspect to intercept the business request message traffic.

[0034] In the embodiment of the present invention, each business system can choose independent mode deployment, sidecar mode deployment, component mode deployment, etc. according to its own operating characteristics. The deployment method is flexible, does not invade the original functions of the gateway, does not rely on the function extension interface provided by the gateway product, and will not affect the original network management.

[0035] Alternatively, see Figure 2 The routing domain 102 includes a routing key query unit 201 and a uniform resource identifier positioning unit 202, wherein the routing key query unit 201 is used to determine the routing key of the service request message according to the routing information in the service request message; the uniform resource identifier positioning unit 202 is used to determine the routing result according to the routing key and the routing key policy, and locate the uniform resource identifier corresponding to the routing result.

[0036] Among them, the Uniform Resource Identifier (URI) is a string used to uniquely identify a resource. Its core goal is to provide a standardized way to identify resources in a network or system. It is the cornerstone of Internet resource addressing and identification.

[0037] In this embodiment of the present invention, routing domain 102 includes a routing key query unit 201 and a Uniform Resource Identifier (URI) location unit 202. Routing key query unit 201 is used to determine the routing key of a service request message based on the routing information in the service request message, while URI location unit 202 is used to determine a routing result based on the routing key and routing key policy, and locate the URI corresponding to the routing result. For example, assume that, after analysis, system S decides to switch all query transactions from application A to application B. At the same time, for certain high-risk maintenance transactions, it prioritizes a pilot program for certain customers, switching from application A to application B. In this case, the service request message may include routing information for determining routing keys such as "transaction code" and "customer number." Routing key query unit 201 determines the routing key corresponding to the service request message based on the routing information, such as the transaction code for the transaction type corresponding to the service request message and the customer number corresponding to the service request message. The routing result for the service request message can then be determined based on the preconfigured predicate operation rule "query type OR (high-risk maintenance category, customer number)." Specifically, the logical operator OR in the predicate operation rule expression can be parsed. The first part, "Query Class," is evaluated. If the transaction code corresponding to the business request message is Query Class, the expression evaluates to true, confirming that the routing result for the business request message is Application B, and there's no need to evaluate the second half. If the transaction code corresponding to the business request message is Maintenance Class, the first part evaluates to false, and the second half, "(High-Risk Maintenance Class, Customer Number)," needs to be evaluated. If the transaction code corresponding to the business request message is High-Risk Maintenance Class, and the customer number corresponding to the customer initiating the business request is on the pilot whitelist, the expression evaluates to true, similarly confirming that the routing result for the business request message is Application B. Otherwise, the routing result for the business request message is Application A. Finally, the Uniform Resource Identifier (URI) corresponding to the routing result is located.

[0038] Optionally, the routing key query unit 201 is specifically used to: if the routing information includes a routing key, extract the routing key of the service request message from the routing information through regular matching; if the routing information does not include a routing key, query the routing key of the service request message from the database table through the user identifier in the routing information.

[0039] In an embodiment of the present invention, if the routing information of the service request message includes a routing key, the routing key of the service request message can be extracted from the routing information through regular matching; if the routing information of the service request message does not include a routing key, the routing key of the service request message can be queried from a database table through a user identifier in the routing information. For example, if the service request message includes a user identifier such as a user ID number, account number, or mobile phone number, the routing key of the service request message, such as a customer number, can be queried from a database table through the user identifier such as the user ID number, account number, or mobile phone number.

[0040] Alternatively, see Figure 3 The scheduling domain 103 includes a forwarding scheduling unit 301, a dual-write scheduling unit 302 and a custom scheduling unit 303, wherein the forwarding scheduling unit 301 is used to send the service request message to the first target application or the second target application according to the routing result; the dual-write scheduling unit 302 is used to send the service request message to the first target application and the second target application according to the routing result; the custom scheduling unit 303 is used to send the service request message to the first target application and / or the second target application according to the routing result and the preset scheduling policy.

[0041] In an embodiment of the present invention, the scheduling domain 103 includes a forwarding scheduling unit 301, a dual-write scheduling unit 302, and a custom scheduling unit 303 to implement traffic scheduling for service request messages. Specifically, if the service request message only needs to be sent to the first target application or the second target application, at this time, the service request message can be sent to the first target application or the second target application according to the routing result through the forwarding scheduling unit 301; if the "dual write" or "playback" function of the service needs to be implemented, the service request message can be sent to the first target application and the second target application according to the routing result through the dual-write scheduling unit 302. Specifically, after sending the service request message to the second target application, the service request message can be sent to the first target application; in addition, the present invention also supports custom scheduling of service request messages. At this time, the service request message can be sent to the first target application and / or the second target application according to the routing result and the preset scheduling strategy through the custom scheduling unit 303 to implement a more complex scheduling mode.

[0042] Alternatively, see Figure 4 The routing scheduling system 100 further includes a configuration domain 104, which is used for users to configure routing keys and routing key strategies; wherein routing keys include atomic routing keys and composite routing keys.

[0043] In this embodiment of the present invention, routing and scheduling system 100 also includes a configuration domain 104. Configuration in 104 primarily involves manual configuration of routing and scheduling system 100, including static and dynamic configuration. Static configuration is performed when routing and scheduling system 100 is not running, while dynamic configuration is performed while routing and scheduling system 100 is running, dynamically affecting the functionality of routing and scheduling system 100. Specific configuration items include routing keys and routing key policies. Routing keys include atomic routing keys and composite routing keys. Atomic routing keys are indivisible, while composite routing keys are composed of specific atomic routing keys.

[0044] Alternatively, see Figure 5The configuration domain 104 includes a routing key configuration unit 401 and a routing key policy configuration unit 402, wherein the routing key configuration unit 401 is used for the user to determine the atomic routing key according to the business field, and to determine the composite routing key by combining the atomic routing keys; the routing key policy configuration unit 402 is used for the user to determine the predicate operation rules between routing keys according to the scheduling requirements and generate the routing key policy.

[0045] In an embodiment of the present invention, the configuration domain 104 includes a routing key configuration unit 401 and a routing key policy configuration unit 402, which configure the routing key and routing key policy respectively. Specifically, the routing key configuration unit 401 is used for the user to determine the atomic routing key according to the business field, and to determine the composite routing key by combining the atomic routing keys. For example, for system S, its business field is mainly to provide customer-related online transaction services for the outlets under the jurisdiction of various provinces and cities. According to this business field, the atomic routing key of S can be configured as "transaction code", "customer number", "province and city code", "outlet number", etc. For any atomic routing key, routing can be performed independently. For example, according to the "province and city code", the business request message of a specific province and city can be routed to application B, while the business request messages of other provinces and cities continue to be routed to application A. At the same time, atomic routing keys can be combined to determine a composite routing key. For example, "transaction code" and "customer number" can be combined to form a composite routing key of "(transaction code, customer number)". Through this composite routing key, routing can be performed based on both "transaction code" and "customer number" at the same time, so that the business request messages of some customers under a certain specific transaction can be routed to application B, and when these customers do not conduct this specific transaction, the business request messages of other transactions of these customers can be routed to application A.

[0046] The routing key strategy configuration unit 402 is used to allow users to determine the predicate operation rules between routing keys based on scheduling requirements and generate routing key strategies. For example, "branch number OR customer number" means that routing is divided according to "branch number" or "customer number", so that all customers under a specific branch and other designated customers can participate in the pilot of the new application; another example is "branch number AND customer number", which means that routing is divided according to both "branch number" and "customer number". Its meaning is equivalent to the composite routing key "(branch number, customer number)", that is, only specific customers under a specific branch can participate in the pilot of the new application.

[0047] Compared with traditional solutions, the technical solution of the embodiment of the present invention flexibly divides routes by setting routing keys in combination with business fields. At the same time, it supports complex routing key strategies such as predicate operation rules between routing keys, making the granularity control of routing more refined and able to accurately divert business request message traffic in any proportion.

[0048] Alternatively, see Figure 6 The routing scheduling system 100 also includes an observation domain 105 and a decision domain 106, wherein the observation domain 105 is used to determine the operating indicators of the second target application according to a preset monitoring strategy; wherein the preset monitoring strategy includes at least one of log analysis, indicator monitoring, and link tracking; the decision domain 106 is used to adjust the proportion of business request messages sent to the second target application according to the operating indicators.

[0049] In an embodiment of the present invention, the routing and scheduling system 100 further includes an observation domain 105 and a decision domain 106. The observation domain 105 is used to determine the operating indicators of the second target application, such as response time, throughput, success rate, etc., according to a preset monitoring strategy, so as to promptly discover possible problems with the new version of the application and issue an early warning when necessary. Specifically, the operating indicators of the second target application can be determined through preset monitoring strategies such as log analysis, indicator monitoring, and link tracking. The decision domain 106 determines whether to continue to expand the scope of use of the new version of the application based on the operating indicators, which is specifically manifested in adjusting the proportion of business request messages sent to the second target application based on the operating indicators.

[0050] Alternatively, see Figure 7 The decision domain 106 includes a first decision unit 601 and a second decision unit 602, wherein the first decision unit 601 is used for the user to manually adjust the proportion of business request messages sent to the second target application according to the operation index; the second decision unit 602 is used to automatically adjust the proportion of business request messages sent to the second target application when the operation index reaches a preset threshold.

[0051] In an embodiment of the present invention, the decision domain 106 includes a first decision unit 601 and a second decision unit 602, each of which is used to manually or automatically adjust the proportion of service request messages sent to the second target application. Specifically, if the new version application (i.e., the second target application) performs well in various operational indicators, the first decision unit 601 can be used to manually increase the proportion of service request messages sent to the second target application. If a problem occurs with the new version application, the first decision unit 601 can be used to manually redirect the request to a problem-free application or to roll back the application version. Furthermore, if the new version application's operational indicators meet preset thresholds, such as a 100% transaction success rate and an average response time of less than 100ms during a pilot period (T period), the second decision unit 602 can also be used to automatically increase the proportion of service request messages sent to the second target application. If the number of exceptions in the new version application exceeds a preset threshold, the second decision unit 602 can be used to automatically redirect the request to a problem-free application or to roll back the application version.

[0052] In an embodiment of the present invention, the routing and scheduling system 100 includes an aggregate root 101, a routing domain 102, a scheduling domain 103, a configuration domain 104, an observation domain 105, and a decision domain 106. By adopting domain-driven design, the routing and scheduling system 100 has the characteristics of high cohesion and low coupling, strong reuse capability, and can effectively avoid duplicate construction and waste of resources, thereby achieving efficient resource allocation and doubling of enterprise efficiency.

[0053] Based on the same inventive concept, an embodiment of the present invention further provides a routing scheduling method. Figure 8 A schematic diagram of a routing scheduling method provided by an embodiment of the present invention is shown in FIG. Figure 8 As shown, the method includes the following steps:

[0054] S110. Obtaining a service request message reported by a user through an aggregate root; wherein the service request message includes routing information for determining a routing key;

[0055] S120. Determine a routing result of the service request message according to the service request message and a pre-configured routing key strategy through the routing domain; wherein the routing key strategy is a predicate operation rule between routing keys set by the user;

[0056] S130. Send the service request message to the target application according to the routing result through the scheduling domain; wherein the target application includes a first target application and a second target application, and the first target application and the second target application have different versions.

[0057] The routing scheduling method provided by an embodiment of the present invention obtains a service request message reported by a user through an aggregate root; wherein the service request message includes routing information for determining a routing key; a routing result of the service request message is determined through a routing domain based on the service request message and a preconfigured routing key policy; wherein the routing key policy is a predicate operation rule between routing keys set by the user; and the service request message is sent to a target application through a scheduling domain based on the routing result; wherein the target application includes a first target application and a second target application, and the first target application and the second target application have different versions. By supporting complex routing key policies such as predicate operation rules between preconfigured routing keys, the granularity control of routing is more refined, and the service request message traffic can be accurately diverted in any proportion.

[0058] Note that the above are only preferred embodiments of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and that various obvious changes, readjustments, and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments and may include many other equivalent embodiments without departing from the concept of the present invention. The scope of the present invention is determined by the scope of the appended claims.

Claims

1. A routing scheduling system, characterized in that: The system includes: an aggregate root, a routing domain, and a scheduling domain; wherein, The aggregate root is used to obtain the service request message reported by the user; wherein the service request message includes routing information for determining the routing key; The routing domain is used to determine the routing result of the service request message according to the service request message and a preconfigured routing key strategy; wherein the routing key strategy is a predicate operation rule between routing keys set by the user; The scheduling domain is used to send the service request message to the target application according to the routing result; wherein the target application includes a first target application and a second target application, and the first target application and the second target application have different versions.

2. The system according to claim 1, wherein: The deployment modes of the system include independent mode deployment, sidecar mode deployment and component mode deployment.

3. The system according to claim 1, wherein: The routing domain includes a routing key query unit and a uniform resource identifier location unit, wherein: The routing key query unit is used to determine the routing key of the service request message according to the routing information in the service request message; The uniform resource identifier locating unit is configured to determine the routing result according to the routing key and the routing key strategy, and locate the uniform resource identifier corresponding to the routing result.

4. The system according to claim 3, characterized in that The routing key query unit is specifically used to: If the routing information includes a routing key, extracting the routing key of the service request message from the routing information through regular matching; If the routing information does not include a routing key, the routing key of the service request message is queried from a database table using the user identifier in the routing information.

5. The system according to claim 1, wherein: The scheduling domain includes a forwarding scheduling unit, a dual-write scheduling unit, and a custom scheduling unit, wherein: The forwarding scheduling unit is configured to send the service request message to the first target application or the second target application according to the routing result; The dual-write scheduling unit is configured to send the service request message to the first target application and the second target application according to the routing result; The custom scheduling unit is configured to send the service request message to the first target application and / or the second target application according to the routing result and a preset scheduling policy.

6. The system according to claim 1, wherein: The system further includes a configuration domain, and the configuration domain is used for the user to configure routing keys and routing key strategies; wherein the routing keys include atomic routing keys and composite routing keys.

7. The system according to claim 6, characterized in that The configuration domain includes a routing key configuration unit and a routing key strategy configuration unit, wherein: The routing key configuration unit is configured to allow the user to determine an atomic routing key according to a business domain, and to determine a composite routing key by combining the atomic routing keys; The routing key strategy configuration unit is used for the user to determine the predicate operation rules between routing keys according to scheduling requirements and generate the routing key strategy.

8. The system according to claim 1, wherein: The system also includes an observation domain and a decision domain, wherein: The observation domain is used to determine the operating indicators of the second target application according to a preset monitoring strategy; wherein the preset monitoring strategy includes at least one of log analysis, indicator monitoring, and link tracing; The decision domain is used to adjust the proportion of service request messages sent to the second target application according to the operation indicator.

9. The system according to claim 8, characterized in that The decision domain includes a first decision unit and a second decision unit, wherein: The first decision unit is configured to allow the user to manually adjust the proportion of service request messages sent to the second target application according to the operation indicator; The second decision unit is configured to automatically adjust the proportion of service request messages sent to the second target application when the operation indicator reaches a preset threshold.

10. A routing scheduling method, characterized in that: Applied to a routing scheduling system, the method includes: Obtaining a service request message reported by a user through an aggregate root; wherein the service request message includes routing information for determining a routing key; Determining a routing result of the service request message according to the service request message and a pre-configured routing key strategy through a routing domain; wherein the routing key strategy is a predicate operation rule between routing keys set by the user; The service request message is sent to a target application according to the routing result through a scheduling domain; wherein the target application includes a first target application and a second target application, and the first target application and the second target application have different versions.

Images