Distribution of rules across instances of the rule engine

Abstract

A method for distributing rules across instances of a rule engine is provided. The method includes determining a rule load for each of a plurality of rule sets. Each rule set is associated with a tenant of a plurality of tenants hosted on a multi-tenant system. The method includes combining the rule load for each rule set into an overall rule load. The method also includes distributing the rule sets across a set of rule engine instances such that approximately the same portion of the overall rule load is allocated to each of the rule engine instances in the set of rule engine instances.

Description

Background Art

[0001] The present disclosure relates generally to the field of rule services, and more particularly to the distribution of execution of rules across multiple independent instances of a rule engine.

[0002] Modern rule engines maintain an in-memory model of rule collections to facilitate fast evaluation of rules. In modern microservice environments, rule services often deploy multiple instances of rule engines simultaneously to further facilitate fast evaluation of rules. Summary of the invention

[0003] Embodiments of the present disclosure include methods, computer program products, and systems for distributing rules across independent instances of a rule engine. The method includes determining a rule load for each of a plurality of rule sets. Each rule set is associated with a tenant of a plurality of tenants hosted on a multi-tenant system. The method also includes combining the rule loads into an overall rule load. The method also includes distributing the plurality of rule sets across a set of rule engine instances such that approximately the same portion of the overall rule load is allocated to each of the rule engine instances in the set of rule engine instances.

[0004] The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The accompanying drawings included in the present disclosure are incorporated into the specification and form a part of the specification. They illustrate embodiments of the present disclosure and, together with the description, are used to explain the principles of the present disclosure. The accompanying drawings are only illustrations of typical embodiments and do not limit the present disclosure.

[0006] Figure 1 A block diagram of an example rule execution system according to an embodiment of the present disclosure is shown.

[0007] Figure 2 A flowchart of an example method for assigning rules to a rule engine instance according to an embodiment of the present disclosure is shown.

[0008] Figure 3 A flowchart illustrating an example method for executing a rule request according to an embodiment of the present disclosure is shown;

[0009] Figure 4 A block diagram of an example system for rule distribution optimization and scaling according to an embodiment of the present disclosure is shown.

[0010] Figure 5 A flow chart of an example method for optimizing distribution of rule models according to an embodiment of the present disclosure is shown.

[0011] Figure 6A high-level block diagram of an example computer system according to an embodiment of the present disclosure is shown, which may be used to implement one or more of the methods, tools and modules described herein and any related functionality.

[0012] Figure 7 A cloud computing environment according to an embodiment of the present disclosure is depicted.

[0013] Figure 8 Abstract model layers according to an embodiment of the present disclosure are depicted.

[0014] Although the embodiments described herein are subject to different modifications and alternative forms, the details thereof have been shown in the drawings by way of example and will be described in detail. However, it should be understood that the specific embodiments described should not be considered restrictive. On the contrary, the present invention is intended to cover all modifications, equivalents and substitutes that fall within the spirit and scope of the present invention. DETAILED DESCRIPTION

[0015] Aspects of the present disclosure generally relate to the field of rule services, and more particularly to distributing the execution of rules across independent instances of rule engines. Although the present disclosure is not necessarily limited to such applications, various aspects of the present disclosure may be understood through a discussion of different examples using this context.

[0016] A rule engine can be used to process multiple types of requests and return appropriate responses. A rule engine can utilize a set of rules (each rule having a condition and an associated action) to process data and generate (or filter) results (e.g., select an action based on the processed data). For example, a rule engine can be used as part of a search engine. The search engine performs a request search for specific information in a systematic manner. The search results are then returned to the requester. How the results of the search are presented, such as in what order, is managed by the rule engine. More specifically, the rule engine applies one or more rule sets to the results to determine how the results are presented to the requester. One or more sets of rules differ depending on the goals of the entity that generates the rules.

[0017] For example, in the case of an online retailer, it may be advantageous for the retailer to promote a particular item for one of a variety of reasons. For example, an item may have a limited shelf life, and the retailer may need to sell more items before it expires. Additionally or alternatively, the retailer may receive a specific benefit from selling items from a particular supplier, and is therefore motivated to sell more items from the supplier. In addition or as an alternative, the retailer may want to sell more specific items to make room for new or different items. In each of these example environments and in many other cases, it is advantageous for the retailer to be able to exert some control on how to present a list of search results to the consumer. For example, the retailer may modify the search results so that a particular item is highlighted, shown first, or otherwise more easily attracted to the attention of the consumer. The retailer may exert such control via one or more rule sets applied to the results of a consumer search by a rule engine.

[0018] In a microservices environment, different services (also referred to herein as microservices) are provided to tenants by microservice providers. A tenant may be, for example, an online retailer. The microservices to be provided to a tenant may be, for example, the retrieval of search results or the application of a set of rules. Microservice providers typically operate multi-tenant systems, where a single microservice provider provides microservices to multiple tenants. Such microservice providers may provide such services to tenants via, for example, a shared cloud system.

[0019] In the present disclosure, a microservice provider provides a service that applies a rule set to search results. Thus, the microservice provider maintains a rule execution microservice that executes the tenant's rules upon request. Each tenant in a multi-tenant system may have its own rules or rule sets, which are provided to the microservice provider to be applied during the execution of the requested microservice by the microservice provider. Each rule set is stored in the memory of the microservice provider, so that the microservice provider can quickly recall and apply the rule set for the tenant upon request. Typically, in order to speed up the process of calling and applying different rule sets for different tenants in a multi-tenant system, the microservice provider runs multiple instances of the rule engine in parallel at the same time. Currently, each instance of the rule engine includes all rules for all tenants. In this way, when multiple requests from tenants arrive at the same time or approximately at the same time, different requests can be sent to different instances of the rule engine to distribute the request load as quickly as possible and return responses to the tenants.

[0020] However, one drawback of this current system is the large number of copies of the same rules that must be stored in multiple locations. More specifically, if a multi-tenant microservice provider has 5,000 tenants, and each tenant has an average of 100 rules to be applied, then the 100 rules for the 5,000 tenants must be loaded for each instance of the microservice provider's rule engine. In other words, 500,000 rules must be loaded for each instance of the rule engine. At some point, the number of rules becomes high enough that the cost (e.g., memory consumption) incurred by the system loading so many rules exceeds the benefit provided by loading a copy of each rule for each tenant on each instance of the rule engine.

[0021] One way to manage the number of rules is to divide the tenants evenly between these instances and only load the rules for the tenants assigned to each instance on the corresponding instance. For example, tenants 1-100 can be assigned to instance A of the rule engine, tenants 101-200 can be assigned to instance B of the rule engine, and tenants 201-300 can be assigned to instance C of the rule engine. Then, instance A only stores and applies rules associated with tenants 1-100, instance B only stores and applies rules associated with tenants 101-200, and instance C only stores and applies rules associated with tenants 201-300. Thus, the rule distribution microservice distributes requests from the microservice provider so that any incoming request from any of tenants 1-100 is routed to instance A, any incoming request from any of tenants 101-200 is routed to instance B, and any incoming request from any of tenants 201-300 is routed to instance C.

[0022] However, the execution of all rules does not require the same amount of resources. For example, executing rule sets for some tenants may incur greater actual runtime or loading costs than executing rule sets for other tenants. Thus, evenly distributing the number of tenants across instances of the rule engine does not necessarily evenly distribute the collective burden or load of all tenants across instances of the rule engine. Therefore, dividing tenants evenly between instances may not be the most efficient or effective way to optimize the functionality and resources of a microservice provider.

[0023] Embodiments of the present disclosure can overcome the above and other problems by distributing the execution of rules across independent instances of the rule engine based on the load generated by each tenant. Thus, the microservice provider also maintains a rule distribution microservice that distributes rules, as explained in further detail herein. The load generated by the associated tenant is also referred to herein as the "rule load" generated by that particular tenant. The rule load is determined for each tenant by an algorithm that takes into account factors including, but not limited to: the number of rule evaluation requests by the tenant in a given time period; the average number of rule condition checks performed by the rule engine for each request in the given time period; the average number of actions triggered by the rule engine for each request in the given time period; the average rule evaluation context size for each request in the given time period; the number of conditional facts defined by each tenant; and a complexity configuration value.

[0024] Once the rule load of each tenant is known, the rule load of all tenants can be combined into an overall rule load. The tenants are then distributed across instances of the rule engine so that each instance handles approximately the same portion of the overall rule load. In other words, the tenants are distributed across instances in a way that distributes the cumulative rule load of all tenants as evenly as possible. In this way, the functions and resources of the microservice provider are optimized more effectively and efficiently.

[0025] It should be understood that the above advantages are exemplary advantages and should not be interpreted as limiting. Implementations of the present disclosure may include all, some, or none of the above advantages while remaining within the spirit and scope of the present disclosure. In addition, although the present disclosure describes in detail the application of various embodiments in the context of search engines, it should be understood that embodiments may be directed to other applications of rule engines, and the exemplary embodiments disclosed herein should not be interpreted as limiting.

[0026] Turning now to the accompanying drawings, Figure 1 A block diagram of an example rule execution system 100 according to an embodiment of the present disclosure is shown. The example rule execution system 100 includes a microservice provider 102, a rule distribution microservice 104, a plurality of rule engine instances 106A, 106B, 106C, and 106D (collectively referred to as rule engine instances 106), a rule monitoring component 108, and a plurality of tenants T(n) (collectively referred to as tenants 110). In at least one embodiment of the present disclosure, the microservice provider 102 includes the rule distribution microservice 104. However, in other embodiments of the present disclosure, the microservice provider 102 and the rule distribution microservice 104 are separate and distinct components of the system 100.

[0027] It should be pointed out that Figure 1 The diagram is intended to depict representative major components of the exemplary rule execution system 100. However, in some embodiments, the various components may have more Figure 1Greater or lesser complexity than that represented in Figure 1 Components other than those shown in the drawings, and the number, type, and configuration of such components may vary. For example, although Figure 1 A rule execution system 100 having four rule engine instances 106 is shown, but a suitable computing environment for implementing embodiments of the present disclosure may include any number of rule engine instances. Figure 1 The various models, modules, systems, and components shown in can exist across multiple host devices and remote devices.

[0028] In some embodiments, the rule execution system 100 may be implemented in a cloud computing environment or using one or more cloud computing services. According to various embodiments, the cloud computing environment may include a network-based distributed data processing system that provides one or more cloud computing services. Further, the cloud computing environment may include many computers (e.g., hundreds or thousands of computers or more) that are arranged in one or more data centers and configured to share resources over a network.

[0029] According to various embodiments of the present disclosure, the microservice provider 102 provides microservices to multiple tenants. Figure 1 In the exemplary embodiment shown in FIG. 1 , microservice provider 102 provides services to 4,000 tenants (in Figure 1 In the example of FIG. 1 , the microservice provider 102 provides microservices to more than or less than 4,000 tenants (shown as tenant T1, tenant T2, ..., tenant T4000). In alternative embodiments, the microservice provider 102 may provide microservices to more or less than 4,000 tenants. In the rule execution system 100 discussed herein, the microservice provider 102 acts at least in part as a rule engine, providing rule execution services to each tenant 110. Thus, the microservice provider 102 is provided with a tenant-specific rule set from each tenant 110. Each tenant-specific rule set may have a different number of rules and / or may require a different number of resources to execute those rules.

[0030] In order to improve the efficiency of responding to rule execution requests received from tenants 110, the rules provided to the microservice provider 102 are distributed across rule engine instances 106. Each of the rule engine instances 106 is a copy of at least a portion of a rule engine that is capable of storing, loading, and executing rules when a rule execution request is received from a tenant. The distribution of rules is managed by the rule distribution microservice 104. In particular, the rules are distributed in the following manner: all rules in a tenant-specific rule set associated with a particular tenant 110 are assigned to a single rule engine instance 106. Each rule engine instance 106 is responsible for storing, loading, and executing the rules to which it has been assigned.

[0031] According to various embodiments of the present disclosure, a subset of a rule set is assigned to each rule engine instance 106, rather than allocating all rules to each rule engine instance 106. Specifically, each rule engine instance 106 is assigned a rule set involving a subset of tenants 110, rather than each rule engine instance 106 being assigned a rule set for all tenants 110.

[0032] More specifically, and with reference to Figure 2 , how to assign rule sets to rule engine instances 106 is managed by method 200. First, at operation 204, an in-memory rule evaluation model is generated for each tenant 110. The in-memory rule evaluation model may also be referred to herein as a rule evaluation model, an in-memory model, or a rule model. In at least one embodiment of the present disclosure, the rule model is generated by the rule distribution microservice 104. In at least some embodiments of the present disclosure, each rule model specifies how to apply a rule set to a provided data set.

[0033] At operation 208, a workload is calculated for each rule model. Because a rule model is generated for each tenant 110, the workload calculated for the rule model is also the workload of the associated tenant. The workload represents the impact or burden that executing the rule model has on the microservice engine. In this case, the microservice engine is a rule engine. The workload of each rule model is calculated based on multiple aspects of the rule model, such as the number of rules in the rule model, the number and complexity of conditions associated with each rule, the average expected number of rule evaluation requests, and the complexity of the rule evaluation context.

[0034] According to at least one embodiment of the present disclosure, a specific algorithm for calculating the workload of a rule model is as follows:

[0035] W(T)=r(t)*c(t)*a(t)*(x+s(t) / f)

[0036] In the algorithm, variable W(T) represents the workload of the tenant. Variable r(t) represents the number of rule evaluation requests received by the rule engine from the tenant in a given time period (t). According to at least one embodiment of the present disclosure, the given time period (t) may be, for example, two minutes. Variable c(t) represents the average number of rule conditions that the rule engine considers to answer those requests. Variable a(t) represents the average number of actions triggered by the rule engine to answer those requests in a given time period (t). Variable s(t) represents the average rule evaluation context size of those requests in a given time period. According to at least one embodiment of the present disclosure, the evaluation context may be, for example, a fact value. Thus, the average rule evaluation context size per request may be, for example, the number of fact values ​​passed to the rule evaluation request in a given time period (t). Variable f represents the number of conditional facts defined by the tenant. According to at least one embodiment of the present disclosure, conditional facts may include, but are not limited to, for example, user segments, geographic locations, referrers, client device types, gender, or age. Variable x represents a complexity configuration value, which may be used to adjust the workload. According to at least one embodiment of the present disclosure, the default value of variable x is 1.

[0037] According to at least one embodiment of the present disclosure, the rule monitoring component 108 is a tracking component that measures the rule load generated by a specific tenant on the rule engine. Thus, when operating the microservice system 100, the rule monitoring component 108 receives data related to: the number of rule evaluation requests per tenant in a given time period; the average number of rule condition checks performed per request in the given time period; the average number of actions triggered per request in the given time period; the average rule evaluation context size per request in the given time period; and / or the number of conditional facts defined per tenant.

[0038] Once the workload of each rule model is determined, the method 200 proceeds to operation 212, where those workloads are used to distribute the rule model between the orchestrated microservice engine set (such as, for example, the rule engine instance 106) to optimize the functions and resources of the microservice provider. More specifically, the workload calculated for all tenants 110 is considered to generate an in-memory rule engine distribution model. Based on the in-memory rule engine distribution model, the rule set is distributed on the rule engine instance 106 in a manner that the workload of all tenants 110 is distributed as evenly as possible on the rule engine instance 106. In other words, the number of tenants 110 or associated rule sets assigned to each rule engine instance 106 can be changed, but the workload assigned to each rule engine instance 106 is as equal as possible. Therefore, each rule engine instance 106 is processing approximately the same portion of the overall workload. Therefore, available system resources are optimized by distributing as evenly as possible on the rule engine instance 106.

[0039] For example, execution of method 200 may result in the rules of tenants T1-T30 and tenants T700-T2000 being assigned to rule engine instance A106A, the rules of tenants T31-T699 and tenants T2001-T2500 being assigned to rule engine instance B106B, the rules of tenants T2501-T3225 and tenants T3900-T4000 being assigned to rule engine instance C106C, and the rules of tenants T3226-T3899 being assigned to rule engine instance D106D.

[0040] It should be noted that the above is an example distribution. Other distributions based on other factors (such as user settings, relative processing power of nodes hosting different engines, etc.) are also possible. For example, in at least some embodiments of the present disclosure, the distribution of rule models can be determined based on the available resources and / or capabilities of a single rule engine instance. For example, a particular rule engine instance may be on a server with more memory. Therefore, this particular rule engine instance can access larger memory resources than other rule engine instances. As such, it may be advantageous to distribute rule models so that larger portions are processed by a particular rule engine instance, rather than distributing the rule models roughly evenly across all rule engine instances.

[0041] In at least one embodiment of the present disclosure, the distribution or redistribution of tenants 110 on rule engine instances 106 based on an in-memory rule engine distribution model can be achieved by changing the allocation of the tenant from its corresponding source rule engine instance 106 to the corresponding target rule engine instance 106. For example, changing the allocation of tenant T31 from rule engine instance A 106A to rule engine instance B 106B includes bootstrapping the rule model of tenant T31 on the target instance (in this case, rule engine instance B 106B) and then modifying the corresponding entry in the mapping table. Then, the rule model of tenant T31 is removed from the source instance (in this case, rule engine instance A 106A) and the corresponding entry in the mapping table is modified accordingly.

[0042] According to some embodiments of the present disclosure, once the workload has been distributed across the rule engine instances 106 (such as by the method 200 described above), rule requests can be processed based on Figure 3 The method 300 shown in is executed. The method 300 begins at operation 304, where a rule execution request is received from a tenant 110. In at least one embodiment of the present disclosure, the incoming rule execution request is received by the microservice provider 102, and the rule distribution microservice 104 then receives the incoming rule execution request from the microservice provider 102.

[0043] For illustrative purposes, in one example, a consumer may search for widgets in a product website. Tenant T5 is associated with the product website and receives search results from the search service provider. Tenant T5 then sends those search results along with a rule execution request to the microservice provider 102. In this example, at operation 304, the incoming rule execution request is a request for the microservice provider 102 to apply rules specific to tenant T5 to the search results and return a preferred search result presentation to be presented to the consumer.

[0044] At operation 308, the most appropriate rule engine instance 106 for providing a response to the received request is selected based on the in-memory rule engine distribution model discussed above. In at least one embodiment of the present disclosure, the most appropriate rule engine instance 106 is selected by the rule distribution microservice 104. In at least one embodiment of the present disclosure, the rule distribution microservice 104 analyzes the incoming request and applies criteria for determining the distribution of rule sets among the rule engine instances 106 to select the appropriate rule engine instance 106 to which the request is to be sent.

[0045] In at least one alternative embodiment of the present disclosure, the above-described mapping table may be used to identify the most appropriate rule engine instance 106. For example, the most appropriate rule engine instance 106 may be identified by determining which tenant is associated with the request, looking up in the mapping table to identify which rule engine instance 106 is associated with the tenant, and then sending the request to the identified rule engine instance 106.

[0046] Continuing with the illustrative example, the rule distribution microservice 104 selects a rule engine instance 106 that has a copy of the tenant-specific rules for tenant T5. In this example, rule engine instance A 106A has a copy of the tenant-specific rules for tenant T5. Therefore, at operation 308, the rule distribution microservice 104 selects rule engine instance A 106A.

[0047] At operation 312, the rule execution request is routed to the selected rule engine instance 106. In at least one embodiment of the present disclosure, the rule execution request is routed by the rule distribution microservice 104. In the illustrative example, the rule execution request from tenant T5 is routed to the selected rule engine instance 106A. In at least one embodiment of the present disclosure, the search results are sent to the selected rule engine together with the rule execution request.

[0048] At operation 316, the rule execution request is executed. In at least one embodiment of the present disclosure, the rule execution request is executed by the specified rule engine instance 106. In the illustrative example, the rule engine instance 106A executes the requested rule execution request by applying the tenant-specific rules of tenant T5 to the provided search results. The tenant-specific rules for tenant T5 may include, for example, a rule that any results within a specific price range within the search results will be ranked in a specific order in the presentation of the search results. The tenant-specific rules for tenant T5 may further include a rule that any results within a specific price range available within a specific geographic distance of a specific location will be ranked in a specific order in the presentation of the search results.

[0049] At operation 320, the results of the executed rule execution request are returned to the microservice provider 102. In at least one embodiment of the present disclosure, the results of the executed rule execution request are returned to the microservice provider 102 by the rule engine instance 106 that executes the rule execution request. In the illustrative example, the results of the rule execution request executed by the rule engine instance 106A are returned to the microservice provider 102. These results include prioritizing the search results according to the two rules discussed above. The microservice provider 102 can then provide these prioritized results to the tenant T5, and the tenant T5 can present the prioritized results to the consumer.

[0050] At operation 324, an asynchronous message is sent to the rule monitoring component 108. In at least one embodiment of the present disclosure, the asynchronous message is sent by the rule engine instance 106 executing the rule execution request. In at least one embodiment of the present disclosure, the asynchronous message includes the rule metric or information used to determine the rule metric. In the illustrative example, the asynchronous message is sent by the rule engine instance 106A to the rule monitoring component 108 and includes, but is not limited to, the number of rules that are applied during rule execution and the number of conditions or facts that must be checked to execute those rules.

[0051] At operation 328, rule metrics related to the executed rule execution requests are aggregated. In at least one embodiment of the present disclosure, the rule metrics are aggregated by the rule monitoring component 108. In the illustrative example, data including the number of rules applied during rule execution and the number of conditions or facts that must be checked in order to execute those rules is aggregated along with similar data from other rule execution requests received by the micro service provider 102.

[0052] These aggregated rule metrics can then be used to recalculate or update the workload for each rule model or tenant 110. For example, the data in the aggregated rule metrics can be input back into the algorithm provided at operation 208 of method 200. By updating the workload based on data collected during operation of the system 100 and feeding those updated workloads back into the in-memory rule engine distribution model, the distribution of rule models among rule engine instances can be further and repeatedly optimized. For example, in at least one embodiment of the present disclosure, the workload can be updated based on data from the aggregated rule metrics at fixed time intervals.

[0053] According to some embodiments of the present disclosure, once the workload has been initially distributed across the rule engine instances 106 (such as by the method 200 described above), the distribution can be further dynamically optimized over time. Such further rule optimization and scaling can be performed by the system 400, for example Figure 4 The system shown in .

[0054] More specifically, the system 400 includes: substantially similar to the above-mentioned Figure 1 The rule distribution microservice 404 of the rule distribution microservice 104 described above is substantially similar to Figure 1 A plurality of rule engine instances 406 of the rule engine instance 106 described above; and substantially similar to Figure 1 The depicted rule monitoring component 108 is a rule monitoring component 408. The system 400 also includes a rule distribution optimization and scaling component 412 and a rule storage 416.

[0055] According to at least one embodiment of the present disclosure, the rule distribution optimization and scaling component 412 is configured to request aggregated rule metrics from the rule monitoring component 408. The request may be sent, for example, at regular time intervals. In addition, the rule monitoring component 408 is configured to return aggregated rule metrics to the rule distribution optimization and scaling component 412. The requested rule metrics may include data about which rules are executed by which tenant, the memory consumption of each rule, and the central processing unit (CPU) consumption of the average rule execution. In addition, the rule distribution and scaling component 412 is communicatively coupled to the rule distribution microservice 404 so that the rule distribution microservice 404 can receive an updated rule engine distribution model from the rule distribution optimization and scaling component 412. Such an updated rule engine distribution model may then be used for the allocation of subsequent rule sets (such as by method 200) and / or the execution of subsequent rule requests (such as by method 300).

[0056] According to at least one embodiment of the present disclosure, the rule storage 416 is configured to store all rules of all rule models. In other words, the rule storage 416 is configured to act as a microservice provider (such as Figure 1 ) and distributes rules between rule engine instances 406.

[0057] Figure 5 An example method 500 is shown to further optimize the distribution of rule models between a set of orchestrated microservice engines. In at least some embodiments of the present disclosure, the method 500 is performed using the system 400. The method 500 begins with a workload distributed across rule engine instances 106, such as by the method 200 described above.

[0058] At operation 504, aggregated rule metrics are requested from the rule monitoring component 408. In at least one embodiment of the present disclosure, the rule distribution optimization and scaling component 412 requests aggregated rule metrics from the rule monitoring component 408. In at least one embodiment of the present disclosure, the rule distribution optimization and scaling component 412 requests rule aggregate metrics at fixed intervals. Specifically, the requested aggregated rule metrics may include, but are not limited to: which rules are executed by which tenant; memory consumption of each rule; and CPU consumption of average rule execution.

[0059] At operation 508, the allocation between the rule models and the rule engine instances 406 is recalculated. In at least one embodiment of the present disclosure, the rule models are loaded from the rule store 416. In at least one embodiment of the present disclosure, the rule distribution optimization and scaling component 412 recalculates the allocation between the rule models (loaded from the rule store) and the rule engine instances 406 to achieve balanced central processing unit and memory consumption across the rule engine instances 406. In at least one embodiment of the present disclosure, if the expected memory and CPU consumption is above a higher predetermined value, the rule distribution optimization and scaling component 412 instantiates additional rule engine instances 406. However, if the memory and CPU consumption is below a lower predetermined value, the rule distribution optimization and scaling component 412 shuts down the rule engine instances 406 to free up system resources.

[0060] At operation 512 , the updated rule engine distribution model is sent to the rule distribution microservice 404 . In at least one embodiment of the present disclosure, the rule distribution optimization and scaling component 412 sends the updated rule engine distribution model to the rule distribution microservice 404 .

[0061] At operation 516, a request is sent to each rule engine instance 406, the request having an identification of the corresponding rule that each rule engine instance 406 needs to load and / or have available in memory. In at least one embodiment of the present disclosure, the rule distribution optimization and scaling component 412 sends a request to each rule engine instance 406, the request having an identification of the rule that each rule engine instance 406 needs to load and / or have available in memory.

[0062] In at least one embodiment of the present disclosure, machine learning can be used to predict the expected rule load for each tenant. For example, based on the time of day or another quantitative variable, the rule load of a tenant may fluctuate. These fluctuations can be detected by a clock or sensor configured to detect the quantitative variable. Such predictions enable the system to preemptively distribute or redistribute rule models in a manner that prevents the re-occurrence of high load on a particular rule engine instance.

[0063] In at least one embodiment of the present disclosure, the execution of rules can be analyzed to identify those rules that are typically executed together. This factor can be used for the management of rule distribution across rule engine instances.

[0064] See now Figure 6 , shown is a high-level block diagram of an example computer system 601 according to an embodiment of the present disclosure, which can be used to implement one or more of the methods, tools and modules described herein and any related functions (e.g., using one or more processor circuits or computer processors of the computer). In some embodiments, the main components of the computer system 601 may include one or more CPUs 602, a memory subsystem 604, a terminal interface 612, a storage interface 616, an I / O (input / output) device interface 614, and a network interface 618, all of which can be directly or indirectly communicatively coupled for inter-component communication via a memory bus 603, an I / O bus 608, and an I / O bus interface unit 610.

[0065] Computer system 601 may include one or more general purpose programmable central processing units (CPUs) 602A, 602B, 602C, and 602D, collectively referred to herein as CPUs 602. In some embodiments, computer system 601 may include multiple processors typical of relatively large systems; however, in other embodiments, computer system 601 may instead be a single CPU system. Each CPU 602 may execute instructions stored in a memory subsystem 604 and may include one or more levels of on-board cache.

[0066] The system memory 604 may include a computer system readable medium in the form of a volatile memory, such as a random access memory (RAM) 622 or a cache memory 624. The computer system 601 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 626 may be configured to read or write from a non-removable, non-volatile magnetic medium (such as a "hard drive"). Although not shown, a disk drive for reading from or writing to a removable non-volatile disk (e.g., a "floppy disk"), or an optical drive for reading from or writing to a removable non-volatile optical disk (such as a CD-ROM, DVD-ROM or other optical media) may be provided. In addition, the memory 604 may include a flash memory, such as a flash stick drive or a flash drive. The memory device may be connected to the memory bus 603 via one or more data media interfaces. The memory 604 may include at least one program product having a set (e.g., at least one) of program modules that are configured to perform the functions of different embodiments.

[0067] One or more programs / utilities 628 (each having at least one set of program modules 1030) may be stored in memory 604. Programs / utilities 628 may include a hypervisor (also referred to as a virtual machine monitor), one or more operating systems, one or more application programs, other program modules, and program data. Each or some combination of the operating system, one or more application programs, other program modules, and program data may include an implementation of a network environment. Program modules 1030 generally perform the functions or methods of different embodiments.

[0068] Although the memory bus 603 is Figure 6 603, but in some embodiments, the memory bus 603 may include multiple different buses or communication paths, which may be arranged in any of a variety of forms, such as point-to-point links in a hierarchical, star or network configuration, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration. In addition, although the I / O bus interface 610 and the I / O bus 608 are shown as a single corresponding unit, in some embodiments, the computer system 601 may include multiple I / O bus interface units 610, multiple I / O buses 608, or both. Further, although multiple I / O interface units are shown to separate the I / O bus 608 from different communication paths running to different I / O devices, in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0069] In some embodiments, computer system 601 may be a multi-user mainframe computer system, a single-user system, or a server computer or similar device with little or no direct user interface but receiving requests from other computer systems (clients). Further, in some embodiments, computer system 601 may be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a phone, a smart phone, a network switch or router, or any other suitable type of electronic device.

[0070] It should be pointed out that Figure 6 The diagram is intended to depict representative major components of an exemplary computer system 601. However, in some embodiments, individual components may have more Figure 6 The greater or lesser complexity represented in , may exist different from Figure 6 Components other than those shown in Figure 6 Components other than those shown in the drawings may be included, and the number, type, and configuration of such components may vary.

[0071] It is understood in advance that although the present disclosure includes detailed descriptions about cloud computing, the implementation of the teachings described herein is not limited to cloud computing environments. Instead, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0072] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be quickly provisioned and released with minimal management effort or interaction with service providers. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0073] Features are as follows:

[0074] On-demand self-service: Cloud consumers can automatically and unilaterally provision computing capabilities, such as server time and network storage, on demand without requiring human interaction with the service provider.

[0075] Broad network access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use with heterogeneous thin-client platforms or thick-client platforms (e.g., mobile phones, laptops, and PDAs).

[0076] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. There is a sense of location independence, as consumers typically do not have control or knowledge of the exact location of the resources provided, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0077] Rapid elasticity: The ability to quickly and elastically provision capacity (in some cases automatically) to quickly scale down and quickly release capacity to quickly scale up. To the consumer, the capacity available for provisioning generally appears unlimited and can be purchased in any quantity at any time.

[0078] Metered Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to providers and consumers of the utilized services.

[0079] The service model is as follows:

[0080] Software as a Service (SaaS): The capability provided to the consumer is to use the provider's applications running on a cloud infrastructure. The applications can be accessed from different client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0081] Platform as a Service (PaaS): The capability provided to consumers is to deploy applications created or acquired by consumers using programming languages ​​and tools supported by the provider onto the cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure including networks, servers, operating systems or storage, but have control over the deployed applications and possible configuration of the application hosting environment.

[0082] Infrastructure as a Service (IaaS): The capabilities provided to consumers are the provision of processing, storage, networking, and other basic computing resources, where consumers can deploy and run arbitrary software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but have control over the operating system, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0083] The deployment model is as follows:

[0084] Private Cloud: Cloud infrastructure is operated only for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0085] Community cloud: The cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0086] Public cloud: Cloud infrastructure is available to the public or large industry groups and is owned by an organization that sells cloud services.

[0087] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0088] Cloud computing environments are service-oriented and focus on statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is the infrastructure that includes a network of interconnected nodes.

[0089] See now Figure 7 , depicts an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which a local computing device used by a cloud consumer can communicate, such as, for example, a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automobile computer system 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as a private cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service for which the cloud consumer does not need to maintain resources on a local computing device. It should be understood that Figure 7 The types of computing devices 54A-N shown in are intended to be illustrative only, and computing node 10 and cloud computing environment 50 may communicate with any type of computerized device over any type of network and / or network addressable connection (eg, using a web browser).

[0090] See now Figure 8 , showing the cloud computing environment 50 ( Figure 7 ) provides a set of functional abstraction layers. It should be understood in advance that Figure 8 The components, layers, and functions shown in are intended to be illustrative only, and embodiments of the present invention are not limited thereto. As described, the following layers and corresponding functions are provided:

[0091] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: mainframes 61; servers based on RISC (Reduced Instruction Set Computer) architecture 62; servers 63; blade servers 64; storage devices 65; and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0092] Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71 ; virtual storage 72 ; virtual networks 73 , including virtual private networks; virtual applications and operating systems 74 ; and virtual clients 75 .

[0093] In one example, the management layer 80 may provide the functionality described below. Resource provisioning 81 provides dynamic procurement of computing resources and other resources for performing tasks within a cloud computing environment. Metering and pricing 82 provides cost tracking when resources are utilized within a cloud computing environment, and bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides cloud computing resource allocation and management so that the required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides pre-scheduling and procurement of cloud computing resources in anticipation of future demand according to the SLA.

[0094] The workload layer 90 provides examples of functions that can take advantage of a cloud computing environment. Examples of workloads and functions that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics processing 94; transaction processing 95; and mobile desktop 96.

[0095] In addition to the above-described embodiment, other embodiments with fewer operating steps, more operating steps or different operating steps are contemplated. In addition, some embodiments can perform some or all of the above operating steps in different orders. In addition, multiple operations can occur simultaneously or occur as the internal part of a larger process. Module is illustratively listed and described according to an embodiment, and does not mean the exclusivity of the necessity or other potential modules (or the function / purpose applied to a specific module) indicating a specific module.

[0096] In the above, reference is made to various embodiments. However, it should be understood that the present disclosure is not limited to the specifically described embodiments. On the contrary, no matter whether the features and elements are related to different embodiments, it is contemplated that any combination of the features and elements is implemented and practiced. Without departing from the scope and spirit of the described embodiments, many modifications and changes may be apparent to those of ordinary skill in the art. In addition, although the embodiments of the present disclosure may achieve advantages that are superior to other possible solutions or superior to the prior art, whether a particular advantage is achieved by a given embodiment does not limit the present disclosure. Therefore, the described aspects, features, embodiments and advantages are merely illustrative and are not considered to be elements or limitations of the appended claims unless explicitly stated in the claims.

[0097] The present invention may be a system, method, and / or computer program product. The computer program product may include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon for causing a processor to perform various aspects of the present invention.

[0098] Computer readable storage medium can be a tangible device that can retain and store instructions used by an instruction execution device. Computer readable storage medium can be, for example but not limited to, electronic storage device, magnetic storage device, optical storage device, electromagnetic storage device, semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer readable storage medium includes the following: portable computer disk, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanical encoding device such as punch card or a protruding structure in a groove with instructions recorded thereon, and any suitable combination of the above. Computer readable storage medium as used herein should not be interpreted as a temporary signal itself, such as radio waves or other free propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (e.g., light pulses passing through fiber optic cables) or electrical signals emitted by wires.

[0099] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device or to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0100] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and conventional procedural programming languages ​​(such as "C" programming languages ​​or similar programming languages). The computer-readable program instructions can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer, partially on the remote computer, or completely on the remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network (including local area network (LAN) or wide area network (WAN)), or can be connected to an external computer (for example, using an Internet service provider through the Internet). In certain embodiments, the electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA) or a programmable logic array (PLA) can be executed by using the state information of the computer-readable program instructions to personalize the electronic circuit to perform computer-readable program instructions, so as to perform various aspects of the present invention.

[0101] This article describes various aspects of the present invention with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to embodiments of the present invention. It should be understood that each box of the flowchart and / or block diagram and the combination of boxes in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0102] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more boxes of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which instructions cause the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable storage medium in which the instructions are stored includes a manufactured product containing instructions for implementing aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0103] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so as to cause a series of operating steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable apparatus, or other device to implement the functions / actions specified in the flowchart and / or block diagram or multiple boxes.

[0104] The flow chart and block diagram in the accompanying drawings show the architecture, function and operation of the possible implementation of the system, method and computer program product according to different embodiments of the present invention. To this end, each box in the flow chart or block diagram may represent a module, segment or part of an instruction, which includes one or more executable instructions for realizing a specified logical function. In some alternative implementations, the function marked in the box may not occur in the order marked in the figure. For example, the two boxes shown in succession can actually be completed as a step, and are executed simultaneously, substantially simultaneously, in a partially or completely overlapping manner in time, or the boxes can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0105] The terms used herein are only used for the purpose of describing specific embodiments, and are not intended to limit different embodiments. As used herein, unless the context clearly indicates otherwise, the singular forms "one", "a kind of" and "the" are intended to also include plural forms. It should also be understood that when the terms "include" and / or "comprise" are used in this specification, they specify the presence of the features, wholes, steps, operations, elements and / or parts, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, parts and / or their combinations. In the previous detailed description of the example embodiments of each embodiment, reference is made to the accompanying drawings (where the same numbers represent the same elements), which form a part thereof, and in which specific example embodiments that can practice each embodiment are shown by way of illustration. These embodiments are described in sufficient detail to enable those skilled in the art to practice these embodiments, but without departing from the scope of different embodiments, other embodiments can be used and logical, mechanical, electrical and other changes can be made. In the previous description, many specific details are set forth to provide a thorough understanding of different embodiments. However, different embodiments can be practiced without these specific details. In other examples, in order not to obscure the embodiments, well-known circuits, structures and technologies are not shown in detail.

[0106] As used herein, "plurality" when used with reference to an item means one or more items. For example, "plurality of different types of networks" is one or more different types of networks.

[0107] When different reference numerals include a common numeral followed by a different letter (e.g., 100a, 100b, 100c) or a punctuation mark followed by a different number (e.g., 100-1, 100-2, or 100.1, 100.2), the use of only the reference character without a letter or subsequent number (e.g., 100) may refer to the group of elements as a whole, any subset of the group, or an example sample of the group.

[0108] Further, when used with a list of items, the phrase "at least one of" means that different combinations of one or more of the listed items can be used, and only one of each item in the list may be required. In other words, "at least one of" means that any combination of items and multiple items in the list can be used, but not all items in the list are required. An item can be a specific object, thing, or category.

[0109] For example, but not limited to, "at least one of item A, item B, or item C" may include item A, item A and item B, or item B. This example may also include item A, item B, and item C, or item B and item C. Of course, there may be any combination of these items. In some illustrative examples, "at least one" may be, for example, but not limited to, two items A; one item B; and ten items C; four items B and seven items C; or other suitable combinations.

[0110] Different instances of the word "embodiment" as used in this specification do not necessarily refer to the same embodiment, but they may refer to the same embodiment. Any data and data structures shown or described herein are examples only, and in other embodiments, different amounts of data, data types, fields, the number and type of fields, field names, rows, records, entries, or data organizations may be used. In addition, any data may be combined with logic so that a separate data structure may not be required. Therefore, the foregoing detailed description should not be considered to have a restrictive meaning.

[0111] The description of different embodiments of the present disclosure has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or technical improvements to technologies found in the marketplace, or to enable those of ordinary skill in the art to understand the embodiments disclosed herein.

[0112] Although the present invention has been described in terms of specific embodiments, it is contemplated that changes and modifications will become apparent to those skilled in the art. Therefore, the following claims are intended to be interpreted as covering all such changes and modifications that fall within the true spirit and scope of the present invention.

Claims

1. A method for rule distribution, comprising: determining a rule load for each of a plurality of rule sets, wherein each rule set is associated with a tenant of a plurality of tenants hosted on the multi-tenant system, the rule load for each rule set being a sum of loads generated by the tenants associated with the rule set; combining the rule loads into a total rule load; Distribute the multiple rule sets on each rule engine instance in the set of rule engine instances, such that: Each rule engine instance is assigned a rule set corresponding to a tenant subset of the plurality of tenants, the tenant subset including more than one tenant and less than all tenants, The total rule load is distributed as evenly as possible on each rule engine instance in the rule engine instance set, For each rule set, all rules of that rule set are assigned to the same rule engine instance, and For each rule engine instance, only the rules of the rule set assigned to the rule engine instance are loaded onto the rule engine instance; receiving a rule execution request associated with a first tenant in the subset of tenants; Routing the rule execution request to a first rule engine instance in the set of rule engine instances to which a rule set corresponding to the first tenant has been assigned; executing the rule execution request by applying a rule set corresponding to the first tenant to execute the rule; determining rule metrics for execution of at least one rule execution request at regular time intervals; and Based on the rule metrics, the plurality of rule sets are distributed across a set of rule engine instances such that substantially the same portion of the total rule load is allocated to each rule engine instance in the set of rule engine instances.

2. The method according to claim 1, wherein: The multiple rule sets are maintained by the microservice provider.

3. The method according to claim 2, wherein: The set of rule engine instances is deployed by the microservice provider.

4. The method according to any one of claims 1 to 3, wherein: Determining the rule load of each rule set includes: determining a number of requests made by the corresponding tenant; and Determine the average number of actions triggered per request.

5. The method according to any one of claims 1 to 3, wherein: Determining the rule load of each rule set includes: determining a number of requests made by the corresponding tenant; and Identify multiple criteria to be considered to answer each request.

6. The method according to claim 5, wherein: sending the number of requests made by the respective tenants and the number of conditions to be considered to answer each request to a rules monitoring component; and The rule monitoring component aggregates these quantities for each rule set.

7. The method according to claim 6, further comprising: obtaining the number of the aggregations from the rule monitoring component; as well as Based on the aggregated number, the rule set is redistributed across the set of rule engine instances such that substantially the same portion of the total rule load is assigned to each rule engine instance in the set of rule engine instances.

8. A computer program product comprising a computer-readable storage medium having program instructions contained therein, the program instructions being executable by a processor to cause the processor to perform a method comprising: determining a rule load for each of a plurality of rule sets, wherein each rule set is associated with a tenant of a plurality of tenants hosted on the multi-tenant system, the rule load for each rule set being a sum of loads generated by the tenants associated with the rule set; combining the rule loads into a total rule load; Distribute the multiple rule sets on each rule engine instance in the set of rule engine instances, such that: Each rule engine instance is assigned a rule set corresponding to a tenant subset of the plurality of tenants, the tenant subset including more than one tenant and less than all tenants, The total rule load is distributed as evenly as possible on each rule engine instance in the rule engine instance set, For each rule set, all rules of that rule set are assigned to the same rule engine instance, and For each rule engine instance, only the rules of the rule set assigned to the rule engine instance are loaded onto the rule engine instance; receiving a rule execution request associated with a first tenant in the subset of tenants; Routing the rule execution request to a first rule engine instance in the set of rule engine instances to which a rule set corresponding to the first tenant has been assigned; executing the rule execution request by applying a rule set corresponding to the first tenant to execute the rule; determining rule metrics for execution of at least one rule execution request at regular time intervals; and Based on the rule metrics, the plurality of rule sets are distributed across a set of rule engine instances such that substantially the same portion of the total rule load is allocated to each rule engine instance in the set of rule engine instances.

9. The computer program product according to claim 8, wherein: The multiple rule sets are maintained by the microservice provider.

10. The computer program product according to claim 9, wherein: The set of rule engine instances is deployed by the microservice provider.

11. The computer program product according to any one of claims 8 to 10, wherein: Determining the rule load of each rule set includes: determining a number of requests made by the corresponding tenant; and Determine the average number of actions triggered per request.

12. The computer program product according to any one of claims 8 to 10, wherein: Determining the rule load of each rule set includes: determining a number of requests made by the corresponding tenant; and Identify multiple criteria to be considered to answer each request.

13. The computer program product of claim 12, wherein: sending the number of requests made by the respective tenants and the number of conditions to be considered to answer each request to a rules monitoring component; and The rule monitoring component aggregates these quantities for each rule set.

14. The computer program product of claim 13, further comprising: obtaining the aggregate quantity from the rule monitoring component; as well as Based on the aggregate quantity, the rule set is redistributed across the set of rule engine instances such that substantially the same portion of the total rule load is assigned to each rule engine instance in the set of rule engine instances.

15. A system for rule distribution, comprising: Memory; as well as A processor is communicatively coupled to the memory, wherein the processor is configured to perform a method comprising: determining a rule load for each of a plurality of rule sets, wherein each rule set is associated with a tenant of a plurality of tenants hosted on the multi-tenant system, the rule load for each rule set being a sum of loads generated by the tenants associated with the rule set; combining the rule loads into a total rule load; Distribute the multiple rule sets on each rule engine instance in the set of rule engine instances, such that: Each rule engine instance is assigned a rule set corresponding to a tenant subset of the plurality of tenants, the tenant subset including more than one tenant and less than all tenants, The total rule load is distributed as evenly as possible on each rule engine instance in the rule engine instance set, For each rule set, all rules of that rule set are assigned to the same rule engine instance, and For each rule engine instance, only the rules of the rule set assigned to the rule engine instance are loaded onto the rule engine instance; receiving a rule execution request associated with a first tenant in the subset of tenants; Routing the rule execution request to a first rule engine instance in the set of rule engine instances to which a rule set corresponding to the first tenant has been assigned; executing the rule execution request by applying a rule set corresponding to the first tenant to execute the rule; determining rule metrics for execution of at least one rule execution request at regular time intervals; and Based on the rule metrics, the plurality of rule sets are distributed across a set of rule engine instances such that substantially the same portion of the total rule load is allocated to each rule engine instance in the set of rule engine instances.

16. The system of claim 15, wherein: The multiple rule sets are maintained by the microservice provider.

17. The system of claim 16, wherein: The set of rule engine instances is deployed by the microservice provider.

18. A system according to any one of claims 15 to 17, wherein: Determining the rule load of each rule set includes: determining a number of requests made by the corresponding tenant; and Determine the average number of actions triggered per request.

19. A system according to any one of claims 15 to 17, wherein: Determining the rule load for each set of rules includes: determining a number of requests made by the corresponding tenant; and Identify multiple criteria to be considered to answer each request.

20. The system of claim 19, further comprising: aggregating the number of requests made by the respective tenants and the number of conditions to be considered to answer each request for each rule set; as well as Based on the aggregate quantity, the rule set is redistributed across the set of rule engine instances such that substantially the same portion of the total rule load is assigned to each rule engine instance in the set of rule engine instances.

Images