FIG. 2 illustrates that consistency groups of a microservice architecture (e.g., microservice architecture 100) may be associated with a respective priority level (e.g., under the column “Priority Level” in the example of FIG. 2). In some instances, the priority level associated with a consistency group may influence resource allocation/utilization modifications triggered by satisfaction of one or more performance parameter thresholds of one or more microservices of the consistency group or of the entire consistency group. In the example of FIG. 2, consistency group 1 is associated with a priority level of 1, consistency group 2 is associated with a priority level of 2, and consistency group 3 is associated with a priority level of 3.

FIG. 1C illustrates additional aspects of the microservice architecture 100, including a message bus 110, monitor engine 120, and an analytical engine 130. The monitor engine 120 and the analytical engine 130 may be implemented as one or more services/executable components within the microservice architecture 100. As will be described in more detail hereinbelow, the monitor engine 120 is configured to collect (e.g., periodically) the performance parameters/metrics/statistics associated with the microservices of the various service categories within the microservice architecture 100. In some implementations, the monitor engine 120 advertises or publishes the resource usage of each microservice within each consistency group for each of the performance parameters (e.g., via the message bus 110 utilizing asynchronous communication using SAGA/routing slip patterns/techniques). The monitor engine 120 may additionally monitor overall system resource utilization (e.g., for the system consistency group that includes all microservices). In some implementations, the monitor engine 120 coordinates and checks distributed transactions across multiple microservices within the microservice architecture 100.

The analytical engine 130 is configured to periodically analyze the performance parameters/metrics/statistics (e.g., by probing via the message bus 110) as advertised or published by the monitor engine 120) associated with the microservices within the microservice architecture 100. The analytical engine 130 interprets the performance statistics of the microservices (e.g., as published to the message bus 110 by the monitor engine 120) with a consistency group paradigm, such as by utilizing correlation ID or trace ID to group microservices into consistency groups based on their associated with particular distributed operations (as discussed herein with reference to FIG. 2). The thresholds discussed hereinabove may further be defined with the consistency groups. In this way, the analytical engine 130 may determine whether any microservice (or entire consistency group) satisfies any thresholds and appropriately respond for every transaction on the microservice architecture 100.

The analysis and/or actions of the analytical engine 130 may utilize routing slip algorithms/techniques to determine and/or issue an appropriate type of throttling or other response (e.g., alerting, dynamically increasing resources, etc.) for microservices (or sets of microservices within consistency groups), based on performance characteristics of the microservices (or sets of microservices within consistency groups) violating permitted limits.

In accordance with the foregoing, FIG. 1D conceptually depicts an example of the monitor engine 120 collecting resource utilization (e.g., performance statistics/metrics) for the various microservices within the service categories of the microservice architecture 100, as indicated by the arrows extending from the service categories toward the message bus 110 and ultimately toward the monitor engine 120. FIG. 1E conceptually depicts an example of the monitor engine 120 publishing the collected resource utilization for the microservices within the microservice architecture to the message bus 110 (as indicated by the arrow extending from the monitor engine 120 to the message bus 110). FIG. 3 illustrates a conceptual representation in the form of a table 300 depicting the resource utilization within the microservice architecture 100 as published by the monitor engine 120 to the message bus 110. The table 300 depicts, for each resource utilization entry, the time of the resource utilization, the microservice name, and the value of the measured parameter (e.g., measured parameters may include, by way of example, CPU usage, memory usage, heap usage, swap usage, number of file descriptors (FDs), number of transmission control protocol connections (TCP connections), jobs distribution, elastic search (ES) latency, garbage collection (GC) pause, garbage collection (GC) latency, and/or others).

FIG. 1E also depicts the analytical engine 130 accessing the resource utilization from the message bus 110 (as indicated by the arrow extending from the message bus 110 to the analytical engine 130). As noted above, the analytical engine 130 determines whether the resource utilization for a microservice (or set of microservices) satisfies one or more parameter thresholds defined by the consistency group with which the microservice (or set of microservices) is associated.

In response to determining that the resource utilization for a particular microservice (or particular set of microservices within a consistency group) satisfies one or more parameter thresholds defined by the consistency group with which the particular microservice (or particular set of microservices) is associated, the analytical engine 130 may perform corrective actions to address the resource over-utilization, which may prevent cascading errors that may result from the resource over-utilization. As indicated herein, the corrective actions may take on various forms. For example, corrective action implemented via an analytical engine 130 may include throttling resource utilization for the particular microservice (or particular set of microservices within a consistency group). Throttling resource allocation may include throttling the concurrency (e.g., number of jobs being processed, number of copies being deleted, number of discovery operations being performed, number of restores being performed, etc.) for the particular microservice (or particular set of microservices associated with a consistency group for a particular distributed operation/transaction), such as by utilizing conditional routing mechanisms to slow down and/or adjust concurrency. Throttling may additionally or alternatively include imposing limits on the resource utilization of the particular microservice (or particular set of microservices), such as by establishing or modifying limits on the number of threads, CPU usage, and/or any other performance parameter(s). Throttling parameters may be determined based upon the parameter thresholds that were determined to be satisfied.

As noted above with reference to FIG. 2, consistency groups may be associated with a respective priority level. In some instances, the analytical engine 130 may consider the priority level for a consistency group in determining how and/or whether to throttle resource utilization for one or more microservices within the consistency group. For instance, where a consistency group is associated with a high priority level (e.g., for critical operations such as responding to a security threat), an analytical model may refrain from throttling resource utilization of one or more microservices within the consistency group in response to detecting excessive resource utilization within the consistency group.

Furthermore, as noted above, the analytical engine 130 may utilize system-wide resource utilization (e.g., resource utilization of a system consistency group that includes all microservices within the microservice architecture) to determine whether and/or how to throttle resources. System resource utilization parameters may include, for example, system CPU usage, system memory usage (e.g., swap and resident memory), input/output processing, network utilization, and/or others. In some implementations, the analytical engine may selectively refrain from throttling resources in response to determining that the resource over-utilization of one or more microservices within one or more consistency groups does not threaten system stability.

Corrective action may additionally or alternatively include implementing a self-healing process to selectively modify (e.g., increase) resource allocation for a particular microservice (or particular set of microservices) within a consistency group. Self-healing operations may be user-defined (e.g., during an onboarding process, based upon service level agreements, etc.) and/or may be based upon hardware characteristics, use cases, available system resources, and/or other factors. For example, a user may define that, in response to detecting excessive computational resource usage by one or more microservices in one or more consistency groups, a self-healing operation may include adding 20% more computational resources to the one or more microservices in the one or more consistency groups.

One will appreciate that a self-healing process may involve other types of parameters, such as memory and/or storage space availability, processing power, number of threads available, and/or others. Furthermore, different self-healing processes may be defined for different consistency groups (e.g., based upon consistency group priority level), and multiple self-healing operations may be defined for the same consistency group (e.g., for responding to satisfaction of different resource utilization parameter thresholds for microservices within the consistency group). Still furthermore, a self-healing process may include dynamically reducing resource allocation for some microservices in some consistency groups (e.g., lower priority consistency groups) to make resources available for allocation toward other microservices in other consistency groups (e.g., higher priority consistency groups).

Corrective action of an analytical engine 130 may be implemented in various ways, such as by utilizing routing slip techniques to issue throttling or facilitate selective modification of resource allocation for one or more microservices within one or more consistency groups. FIG. 1F conceptually depicts the analytical engine 130 issuing corrective action protocols to one or more microservices within the microservice architecture 100 via the message bus 110 (as indicated in FIG. 1F by the arrows extending from the analytical engine 130 toward the message bus 110 and ultimately toward the microservices within service categories A, B, and C of the microservice architecture).

FIGS. 4, 5, and 6 illustrate example methods according to some example embodiments. The operations of the methods discussed herein may be performed utilizing one or more computing entities/devices/systems (see FIG. 3) within the context of a microservice architecture (see FIGS. 1A-1F), as discussed herein. It is noted with respect to the disclosed methods that any operation(s) of any of these methods, may be performed in response to, as a result of, and/or, based upon, the performance of any preceding operation(s). Correspondingly, performance of one or more operations, for example, may be a predicate or trigger to subsequent performance of one or more additional operations. Thus, for example, the various operations that may make up a method may be linked together or otherwise associated with each other by way of relations such as the examples just noted. Finally, and while it is not required, the individual operations that make up the various example methods disclosed herein are, in some embodiments, performed in the specific sequence recited in those examples. In other embodiments, the individual operations that make up a disclosed method may be performed in a sequence other than the specific sequence recited. Some embodiments may omit one or more of the operations discussed herein.

Act 402 of method 400 of FIG. 4 includes obtaining, via a monitor engine, a resource utilization associated with a set of parameters for each microservice within a consistency group, wherein each microservice within the consistency group is associated with a particular distributed operation within the microservice architecture, and wherein the consistency group defines, for each microservice within the consistency group, one or more threshold values associated with each parameter of the set of parameters. In some implementations, the microservice(s) within the consistency group is/are identified based upon a trace ID associated with the particular distributed operation within the microservice architecture. In some instances, each microservice within the consistency group is associated with a service category within the microservice architecture. In some instances, at least one microservice within the consistency group is associated with one or more other consistency groups within the microservice architecture. In some implementations, the set of parameters includes one or more of: processor usage, memory usage, heap usage, swap usage, number of threads, number of file descriptors, number of transmission control protocol connections, jobs distribution, elastic search latency, garbage collection pause, or garbage collection latency. In some instances, at least some of the one or more threshold values are determined based upon one or more service level agreements. In some implementations, the one or more threshold values include one or more soft thresholds and one or more hard thresholds for at least some parameters of the set of parameters. In some instances, the monitor engine publishes the resource utilization associated with the set of parameters for each microservice within the consistency group to a message bus. In some instances, the resource utilization is published to the message bus utilizing routing slip techniques.

Act 404 of method 400 includes determining, via an analytical engine, whether resource utilization satisfies a particular threshold of the one or more threshold values associated with a particular parameter of the set of parameters for a particular microservice within the consistency group. In some implementations, the analytical engine accesses the resource utilization from the message bus to determine whether the resource utilization satisfies the threshold of the one or more threshold values associated with the particular parameter of the set of parameters for the particular microservice within the consistency group. In some implementations, the particular threshold of the one or more threshold values includes a hard threshold of the one or more hard thresholds.

Act 406 of method 400 includes, based upon resource utilization satisfying the particular threshold of the particular parameter for the particular microservice within the consistency group, throttling resource utilization for one or more microservices within the consistency group. Act 406 may include determining throttling parameters for the throttling of resource utilization for the one or more microservices within the consistency group. In some instances, throttling resource utilization for the one or more microservices within the consistency group is further based upon a system consistency group including all microservices within the microservice architecture. The system consistency group may indicate concurrency or total resource usage among all microservices within the microservice architecture. In some instances, satisfaction of the one or more soft thresholds (discussed with reference to act 404) triggers a notification. In some instances, throttling resource utilization includes utilizing routing slip techniques to issue throttling for the particular microservice within the consistency group.

Act 502 of method 500 of FIG. 5 includes obtaining, via a monitor engine, a resource utilization associated with a set of parameters for each microservice within a consistency group, wherein each microservice within the consistency group is associated with a particular distributed operation within the microservice architecture, and wherein the consistency group defines, for each microservice within the consistency group, one or more threshold values associated with each parameter of the set of parameters. The microservice(s) within the consistency group may be identified based upon a trace ID associated with the particular distributed operation within the microservice architecture. In some implementations, each microservice within the consistency group is associated with a service category within the microservice architecture. In some instances, at least one microservice within the consistency group is associated with one or more other consistency groups within the microservice architecture. In some implementations, the set of parameters includes one or more of: processor usage, memory usage, heap usage, swap usage, number of threads, number of file descriptors, number of transmission control protocol connections, jobs distribution, elastic search latency, garbage collection pause, or garbage collection latency. In some instances, at least some of the one or more threshold values are determined based upon one or more service level agreements. In some implementations, the one or more threshold values include one or more soft thresholds and one or more hard thresholds for at least some parameters of the set of parameters. In some instances, the monitor engine publishes the resource utilization associated with the set of parameters for each microservice within the consistency group to a message bus. In some implementations, the resource utilization is published to the message bus utilizing routing slip techniques.

Act 504 of method 500 includes determining, via an analytical engine, whether resource utilization satisfies a particular threshold of the one or more threshold values associated with a particular parameter of the set of parameters for a particular microservice within the consistency group. In some implementations, the analytical engine accesses the resource utilization from the message bus to determine whether the resource utilization satisfies the threshold of the one or more threshold values associated with the particular parameter of the set of parameters for the particular microservice within the consistency group. In some instances, the particular threshold of the one or more threshold values includes a hard threshold of the one or more hard thresholds.

Act 506 of method 500 includes, based upon resource utilization satisfying the particular threshold of the particular parameter for the particular microservice within the consistency group, implementing a self-healing process to selectively modify resource allocation for one or more microservices within the consistency group. In some instances, the self-healing process utilizes routing slip techniques to facilitate selective modification of resource allocation for the one or more microservices within the consistency group. In some implementations, the self-healing process includes dynamically increasing resource allocation for the one or more microservices within the consistency group. In some instances, the self-healing process includes dynamically adjusting (e.g., reducing) resource allocation for one or more services involved with the particular operation within the microservice architecture. The one or more services may be within a different consistency group than the particular microservice, and the one or more services may be selected based upon a priority level associated with the consistency group or the different consistency group. In some implementations, the self-healing process is further based upon a system consistency group including all microservices within the microservice architecture. The system consistency group may indicate concurrency or total resource usage among all microservices within the microservice architecture. In some implementations, wherein satisfaction of the one or more soft thresholds (e.g., discussed with reference to act 504) triggers a notification.

Act 602 of method 600 of FIG. 6 includes obtaining, via a monitor engine, a resource utilization associated with a set of parameters for each microservice within a set of consistency groups, wherein, for each particular consistency group within the set of consistency groups, each microservice within the particular consistency group is associated with a particular distributed operation within the microservice architecture, and wherein each respective consistency group of the set of consistency groups defines, for each microservice within the respective consistency group, one or more threshold values associated with each parameter of the set of parameters. In some implementations, each microservice within the set of consistency groups is associated with a service category within the microservice architecture. In some instances, at least one microservice within the set of consistency groups is associated with multiple consistency groups within the set of consistency groups. In some implementations, the set of parameters includes one or more of: processor usage, memory usage, heap usage, swap usage, number of threads, number of file descriptors, number of transmission control protocol connections, jobs distribution, elastic search latency, garbage collection pause, or garbage collection latency. In some instances, wherein at least some of the one or more threshold values are determined based upon one or more service level agreements. In some implementations, the one or more threshold values include one or more soft thresholds and one or more hard thresholds for at least some parameters of the set of parameters. In some instances, the monitor engine publishes the resource utilization associated with the set of parameters for each microservice within the set of consistency groups to a message bus. In some implementations, the resource utilization is published to the message bus utilizing routing slip techniques.

Act 604 of method 600 includes, for a first consistency group of the set of consistency groups, determining, via an analytical engine, whether first resource utilization satisfies a first particular threshold of the one or more threshold values associated with a first particular parameter of the set of parameters for a first particular microservice within the first consistency group. Act 606 of method 600 includes, for a second consistency group of the set of consistency groups, determining, via the analytical engine, whether second resource utilization satisfies a second particular threshold of the one or more threshold values associated with a second particular parameter of the set of parameters for a second particular microservice within the second consistency group. In some implementations, the first particular threshold and the second particular threshold of the one or more threshold values includes a hard threshold of the one or more hard thresholds. In some instances, the analytical engine accesses the resource utilization from the message bus to determine whether first resource utilization satisfies a first particular threshold of the one or more threshold values associated with a first particular parameter of the set of parameters for a first particular microservice within the first consistency group and whether second resource utilization satisfies a second particular threshold of the one or more threshold values associated with a second particular parameter of the set of parameters for a second particular microservice within the second consistency group.