A system and method for providing cross-microservice query optimization.

Abstract

This invention provides a system and method for providing cross-microservice query processing. [Solution] A system providing an object service framework 202 that supports the use of microservices A210 that interact with each other or request access to each other's data to process queries, wherein each microservice can be independently developed, deployed and evolved, and interacts with other microservices through contracts and interfaces defined as public APIs and exposed through the framework. The framework is used to provide a cross-microservice layer that automatically translates queries that combine objects from different microservices into a single database query optimized for use in that database.

Description

Technical Field

[0001] (Claim of Priority) This application claims priority to U.S. Patent Application titled "System and Method for Providing Cross-Micro-Service Query Optimization" with Application No. 17 / 525,653, filed with the Office on November 12, 2021, and the above application and its content are hereby incorporated by reference.

[0002] The embodiments described herein generally relate to cloud computing environments, cloud services, and microservices, and particularly to systems and methods for providing cross-microservice query processing.

Background Art

[0003] To address rapidly changing software requirements, companies are increasingly interested in technologies such as microservices that can provide software applications that can be rapidly developed, deployed, easily maintained, and highly available.

[0004] In a microservices-oriented architecture, each microservice can operate relatively independently using internal operations that are only accessible to external entities through a public interface, including having its own data model and managing its own data.

[0005] However, when used with complex software applications that interact or share data, such as enterprise applications, it becomes particularly difficult to manage the dependencies between microservices. For example, one microservice may need to receive data from one or more other microservices in order to function properly.

[0006] A system and method for providing cross-microservice query processing is described according to one embodiment. The system provides an object service framework that supports the use of microservices that may be loosely coupled but related in some way, for example, microservices that interact with each other or that request access to each other's data in order to process queries. Each microservice can be independently developed, deployed, and evolved, and interacts with other microservices through contracts and interfaces defined as public APIs and exposed through the framework. The object service framework may be used to provide a cross-microservice layer that, for example, automatically translates queries that combine objects from different microservices into a single database query optimized for use in that database. [Brief explanation of the drawing]

[0007] [Figure 1] This figure shows a system that provides cross-microservice query processing according to one embodiment. [Figure 2] This figure further illustrates a system that provides cross-microservice query processing according to one embodiment. [Figure 3] This figure further illustrates a system that provides cross-microservice query processing according to one embodiment. [Figure 4] This figure further illustrates a system that provides cross-microservice query processing according to one embodiment. [Figure 5] This figure further illustrates a system that provides cross-microservice query processing according to one embodiment. [Figure 6] This figure further illustrates a system that provides cross-microservice query processing according to one embodiment. [Figure 7] This figure further illustrates a system that provides cross-microservice query processing according to one embodiment. [Figure 8] This figure further illustrates a system that provides cross-microservice query processing according to one embodiment. [Figure 9] This figure further illustrates a system that provides cross-microservice query processing according to one embodiment. [Figure 10] This figure shows an example of using a system that provides cross-microservice query processing according to one embodiment. [Figure 11] This figure further illustrates an example of using a system that provides cross-microservice query processing according to one embodiment. [Figure 12] This figure further illustrates an example of using a system that provides cross-microservice query processing according to one embodiment. [Figure 13] This figure further illustrates an example of using a system that provides cross-microservice query processing according to one embodiment. [Figure 14] This figure further illustrates an example of using a system that provides cross-microservice query processing according to one embodiment. [Figure 15] This figure shows a method for providing cross-microservice query processing according to one embodiment. [Modes for carrying out the invention]

[0008] (Detailed explanation) To address rapidly changing software demands, enterprises are increasingly drawn to technologies like microservices, which provide software applications that can be generated with rapid development and deployment capabilities, ease of maintenance, and high availability.

[0009] In a microservices-oriented architecture, each microservice can operate relatively independently, using internal operations that are accessible to external entities only through public interfaces, including possessing its own data model and managing its own data.

[0010] However, when used with complex software applications that interact and share data, such as enterprise applications, managing dependencies between microservices becomes particularly difficult. For example, one microservice may need to receive data from one or more other microservices in order to function properly.

[0011] For example, in a sales-oriented enterprise application, sales orders may be managed by a first microservice, and products by a second microservice. The sales order microservice may require product data for its validation logic to function properly, which may necessitate combining queries for data across different microservices to retrieve sales orders for products supplied by a specific vendor, for example.

[0012] In the example above, the corresponding data objects are owned by different microservices. Since these queries may be managed within their own independent databases, the challenge lies in how to execute such queries in an optimized manner without sacrificing the benefits provided by the microservices architecture.

[0013] According to one embodiment, a system and method for providing cross - microservice query processing are described herein. The system provides an object service framework that supports the use of microservices that may be loosely coupled but are related in some way, for example, related in that microservices interact with each other or request access to each other's data in order to process a query. Each microservice can independently evolve, deploy, and progress, and interacts with other microservices through contracts or interfaces defined as public APIs and exposed through the framework.

[0014] According to one embodiment, the object service framework can be used to provide a cross - microservice layer that, for example, automatically converts queries that combine objects of different microservices into a single database query optimized for use in its database.

[0015] According to one embodiment, the described approach retains the benefits provided by the microservice architecture, such as the ability for microservices to evolve rapidly and operate relatively independently, while providing support for features such as combined query operations that utilize available database (e.g., SQL) optimizations.

[0016] In various embodiments, for example, various technical features and advantages of the systems and methods described therein may be included.

[0017] According to one embodiment, an object service framework can be used to manage multiple related microservices in order to simplify the work of microservices such as development and deployment. Each microservice owner is responsible for defining its own objects, application logic, and database artifacts. Common tasks can be provided by the object service framework when providing stateless APIs accessible to external systems as managed cloud services, for example.

[0018] According to one embodiment, the uniform management of objects owned by various microservices can be used to develop cloud-native mindsets in developers and users. Each object is associated with an internal implementation and a public contract definition, which facilitates the maintenance of components in a backward-compatible manner.

[0019] According to one embodiment, the public contracts of microservice objects can be exposed to consumers in a consistent manner. Since the object service framework manages the definition of objects, it can expose the public contracts in various forms, such as in the form of open APIs or GraphQL schemas. The object definition serves as a repository for discovery and documentation purposes and can be utilized by tools such as an object catalog.

[0020] According to one embodiment, the described approach provides boundaries for infrastructure-level microservices. Each microservice interacts with databases and other microservices through the object service framework. On the other hand, the object service framework provides common APIs so that each object can execute its business logic. work interacts with databases and other microservices. On the one hand, the object service framework provides common APIs so that each object can execute its business logic.

[0021] According to one embodiment, the described approach makes it possible for multiple microservices to utilize a single database cluster. Since all interactions are performed through an object services framework and the boundaries of each microservice are clearly defined, multiple microservices can utilize a single database cluster that is easier to maintain and back up / restore, reduces operational costs, and simplifies the migration from existing monolithic systems to microservice architectures.

[0022] In one embodiment, the described approach can be used to automatically perform query optimization. Because the object services framework manages object definitions and interactions with other microservices and external systems, it can add optimizations that act on multiple microservices. For example, in a joined query case that contains objects from different microservices but shares the same database instance, the object services framework can identify which database objects are included and then transform the joined query into a single database SQL query, so that the joined query can function in an optimized way that is transparent to the microservice owner. Furthermore, since microservices continue to own their own database instances, there is no need to rewrite object code to leverage the optimizations; instead, the infrastructure will simply transform the joined query into a different form. [Cross-microservice queries] As described above, managing dependencies between microservices becomes particularly difficult when used with complex software applications that interact and share data, such as enterprise applications. For example, one microservice may need to receive data from one or more other microservices in order to function properly.

[0023] Various approaches to this challenge include data replication and data mashup. Microservices can use data replication to replicate data locally owned by other microservices, and as a result, such joins can transform into more efficient local database joins. However, this approach incurs maintenance costs for replicating data, and the replicated data may become out of sync, potentially leading to incorrect query results.

[0024] Since multiple individual queries may have been issued to each included microservice using a data mashup, post-processing is required to combine the query results outside the database. However, because the datasets extracted from each microservice can become very large, mashup joins can also be very inefficient.

[0025] A system and method for providing cross-microservice query processing is described according to one embodiment. The system provides an object service framework accessible as a cloud service that supports the use of loosely coupled but related microservices. Each microservice can be deployed and evolve independently and interacts only with other microservices through contracts or interfaces defined as public APIs and exposed through the framework. The framework can be used, for example, to provide a cross-microservices layer that automatically translates queries combining objects from different microservices into a single database query optimized for use with that database.

[0026] Figure 1 shows a system that provides cross-microservice query processing according to one embodiment.

[0027] According to one embodiment, the configuration and process shown in Figure 1, and what is further described herein with respect to various embodiments, may be provided as software or program code executable by a computer system or other type of processing device.

[0028] For example, according to one embodiment, the configuration and processing described herein may be provided by a cloud computing system or other appropriately programmed computer system.

[0029] As shown in Figure 1, according to one embodiment, the cloud computing environment 100 can operate on a cloud computing infrastructure 102 comprising hardware (e.g., processor, memory) and software resources, the cloud computing infrastructure 102 further comprising one or more cloud interfaces 104 or other application programming interfaces (APIs) that provide access to shared cloud infrastructure resources, for example, through one or more load balancers A106 and B108.

[0030] In one embodiment, the availability domain 131 may include or provide access to one or more cloud service instances or microservices.

[0031] For example, according to one embodiment, data requests may be received in one or more availability domains A120, B130 for processing by the microservices 122, 132 themselves. Cloud tenants A142 and B144 may have partitions within the cloud infrastructure environment from which tenants can access their cloud resources.

[0032] According to one embodiment, for example, a computing device 160 having device hardware 162 (e.g., a processor, memory), and a client device such as a graphical user interface 166 enable a user 168 or administrator to communicate with a cloud computing environment over a network such as a wide area network, a local area network, or the internet for the creation or updating of cloud services.

[0033] According to one embodiment, an object service framework 202 accessible as a cloud service supports the use of loosely coupled but related microservices. Each microservice (e.g., microservice A210), including the microservice implementation 212, can be deployed and evolved independently and can expose microservice lifecycle operations to one or more APIs (e.g., through REST218 and gRPC216) that allow generating / updating artifacts in, for example, a database 204 or a storage service.

[0034] Figure 2 further illustrates a system that provides cross-microservice query processing according to one embodiment.

[0035] As shown in Figure 2, according to one embodiment, a microservice implementation may include one or more microservice objects A1, A2, or (logic, business) objects that provide the logic or functionality of the microservice.

[0036] Figures 3 and 4 further illustrate a system that provides cross-microservice query processing according to one embodiment.

[0037] As shown in Figures 3 and 4, according to one embodiment, each microservice (e.g., microservices B220, N230) may be deployed and evolved independently, including having its own microservice implementation 222,232 exposed through REST 228 and gRPC 226, and accessing its database artifacts. Certain microservices may be loosely coupled but related in some way, for example, in that they interact with each other or request access to each other's data 229,239 to process (logic, business) object-level requests 217,227 or queries.

[0038] Figure 5 further illustrates a system that provides cross-microservice query processing according to one embodiment.

[0039] As shown in Figure 5, according to one embodiment, each microservice object is associated with metadata that provides (a) an internal implementation definition 213 and (b) a public contract definition 214, the public contract definition including properties and behaviors of the microservice object that are accessible by external systems. For each microservice, the implementation definition provides a mapping between the microservice object having properties and database tables / views that include, for example, tables, columns, and, if necessary, other validation or derived business logic.

[0040] In one embodiment, the public properties and behaviors defined by the public contract definition of each microservice are made accessible to external systems through public APIs and protocols such as REST and gRPC.

[0041] Figure 6 further illustrates a system that provides cross-microservice query processing according to one embodiment.

[0042] As shown in Figure 6, according to one embodiment, a collective view associated with microservices and their objects is used to populate its database (262, 264) with a cross-service view 250. An example of this is shown in Example 1 below, which follows one embodiment. In Example 1, the cross-service view is used to process object-level queries.

[0043] Figure 7 further illustrates a system that provides cross-microservice query processing according to one embodiment.

[0044] As shown in Figure 7, according to one embodiment, each microservice is associated with a database schema or database role, restricting which database artifacts are accessible through the role. Different microservices may interact with each other through business object APIs accessible via REST and gRPC. Such business object APIs are remote call latency and serial Provides optimization without the cost of riseration / deserialization.

[0045] According to one embodiment, a cross-microservices layer 260 is provided, which, in response to queries joined across multiple microservices, receives object-level queries based on a cross-services view and translates those queries into one or more physical database (e.g., SQL) queries 270 using a read / only schema 272. Native database (e.g., SQL) optimizations can then be leveraged to process those database queries.

[0046] In one embodiment, the cross-microservices layer manages a catalog of objects supported by the object services framework through metadata, including the public contract of each object, i.e., how the object can be accessed from outside the environment, and the internal implementation of each object, such as which tables and columns to use.

[0047] Furthermore, according to one embodiment, the cross-microservices layer receives requests from clients, for example, via a REST or gRPC interface, and provides routines adapted to translate the received requests from object-level queries to physical database (e.g., SQL) queries.

[0048] For example, according to one embodiment, optimal query performance can be achieved by an infrastructure that translates cross-microservice combined queries into a single / optimized database SQL query when the relevant microservices share the same database instance.

[0049] Figure 8 further illustrates a system that provides cross-microservice query processing according to one embodiment.

[0050] In one embodiment, by applying an infrastructure to manage the interactions between microservices and using an underlying database, the system enables multiple microservices to utilize the same database cluster while simultaneously ensuring the isolation of microservices. By utilizing a single database cluster, operational costs are minimized instead of forcing each microservice to have its own database instance.

[0051] As shown in Figure 8, according to one embodiment, each database artifact is associated with a single / specific microservice acting as its owner. Different microservices do not share access to a single database object. This means that a given microservice is restricted from directly accessing database artifacts owned by different microservices.

[0052] For example, according to one embodiment, microservice A may be associated with a database schema or database role 274 that restricts which database artifacts are accessible through a role (by microservice A).

[0053] Figure 9 further illustrates a system that provides cross-microservice query processing according to one embodiment.

[0054] For example, according to one embodiment, microservice B restricts which database artifacts are accessible by role (by microservice B). It may be associated with a database schema or database role 276.

[0055] As described above, according to one embodiment, when the cross-microservices layer is used in response to queries that are joined across multiple microservices, the cross-microservices layer can receive object-level queries based on a cross-service view and can translate those queries into queries for one or more physical databases (e.g., SQL) that span data or are independently owned by the various microservices.

[0056] According to one embodiment, the system does not require rewriting existing code and further grants microservices the flexibility to change their database strategy without sacrificing functionality or performance, particularly coupled queries involving multiple microservices. [Usage example] Figure 10-13 shows an example of a system that provides cross-microservice query processing according to one embodiment.

[0057] As shown in Figure 10-13, according to one embodiment, each microservice (e.g., order microservice 310, product microservice 32) can be independently deployed and evolved, including having its own microservice implementation exposed through REST 318, 328 and gRPC 316, 325, and accessing artifacts in a database.

[0058] In this example according to one embodiment, an object-level query may be created against an order object, for example, using a cross-service view.

[0059] [Table 1]

[0060] The JSON example described above represents a query that returns orders and lines based on order-level conditions where the total amount of the order exceeds 1000 or the line has a product price greater than 10.

[0061] According to one embodiment, the object service framework maintains business object definitions, including table and column mappings, so that such queries can be translated into, for example, one or more physical database queries.

[0062] [Table 2]

[0063] According to one embodiment, the system can apply database query optimization to, for example, transform the database queries described above into a single query that directly returns a JSON document.

[0064] [Table 3]

[0065] According to one embodiment, a schema / role for one microservice cannot access tables / views for other microservices; therefore, a global read-only schema / role is used to execute such queries. The object services framework automatically switches to this global read-only schema / role only when a join between different microservices is requested.

[0066] Figure 14 further illustrates an example of the use of a system that provides cross-microservice query processing according to one embodiment.

[0067] As shown in Figure 14, according to one embodiment, the system can use a cross-service view 332 when processing object-level requests or queries (for example, the example shown in Example 1 above) and when preparing database queries 336 (for example, the examples shown in Examples 2 and 3 above), including using database query optimizations available as needed. [Cross-microservice query processing] Figure 15 shows a method for providing cross-microservice query processing according to one embodiment.

[0068] As shown in Figure 15, according to one embodiment, in step 340, each microservice object is associated with metadata that provides (a) an internal implementation definition and (b) a public contract definition, the public contract definition including properties and behaviors of the microservice object that are accessible by an external system.

[0069] In step 342, for each microservice, the implementation definition provides a mapping between a microservice object with properties and a database table / view containing, for example, tables, columns, and, if necessary, other validation or derived business logic.

[0070] In step 344, the collective views associated with the microservices and their objects are used to populate the database with cross-service views.

[0071] Step 346 involves associating each microservice with a database schema or database role, restricting which database artifacts are accessible through that role.

[0072] In step 348, the public properties and behaviors defined by the public contract definition of each microservice are made accessible to external systems through public APIs and protocols such as REST and gRPC.

[0073] In step 350, a cross-microservices layer is provided. In response to queries that are joined across multiple microservices, the cross-microservices layer receives object-level queries based on a cross-service view and translates those queries into one or more physical database (e.g., SQL) queries. Native database SQL optimizations can then be leveraged to achieve the desired query optimizations.

[0074] In various embodiments, the teachings herein may be conveniently implemented using one or more conventional general-purpose or specialized computers, computing devices, machines, or microprocessors including one or more processors, memory, and / or computer-readable storage media programmed in accordance with the teachings herein. As will be apparent to those skilled in the software art, appropriate software coding can be readily prepared by a skilled programmer based on the teachings herein.

[0075] In some embodiments, the teachings herein may include a computer program product which is a non-temporary computer-readable storage medium (media) having stored instructions that can be used to program a computer to perform any of the operations of these teachings. Examples of such storage mediums may include, but are not limited to, hard disk drives, hard disks, hard drives, fixed disks, or other electromechanical data storage devices, floppy disks, optical disks, DVDs, CD-ROMs, microdrives, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems, or other types of storage media or devices suitable for the non-temporary storage of instructions and / or data.

[0076] The foregoing description is provided for the purposes of the drawings and explanations. It is not intended to be exhaustive, nor does it limit the scope of protection to the disclosed form itself. Many modifications and variations will be readily apparent to those skilled in the art.

[0077] The embodiments have been selected and described to best illustrate the principles of this teaching and their practical applications. This will enable those skilled in the art to understand the various embodiments and to consider various modifications suitable for specific uses. The scope is intended to be defined by the following claims and equivalents.

Claims

1. A system that provides cross-microservice query processing, A computer including one or more processors that provides a cloud computing environment and multiple microservices that operate in the cloud computing environment, It includes an object service framework, Each microservice object is associated with metadata that provides internal implementation definitions and public contract definitions. For each microservice, the implementation definition provides a mapping between a microservice object with properties and a database table / view. The aforementioned multiple microservices and the collective views associated with their objects are used to populate the database with a cross-service view. Each microservice is associated with a database schema or database role that restricts which database artifacts are accessible through that role. A system that provides a cross-microservice layer that, in response to queries joined across the aforementioned multiple microservices, receives queries based on the cross-service view and translates the queries into one or more database queries.

2. The system according to claim 1, wherein the object service framework and the cross-microservice layer automatically translate queries that combine objects from different microservices into a single database query optimized for use in the database.

3. The system according to claim 1, wherein the object service framework is accessible as a cloud service that supports the use of loosely coupled but related microservices.

4. The system according to claim 1, wherein the object-level query based on the cross-service view translates the query into one or more database SQL queries that pass over the data or are independently owned by various microservices.

5. A method for providing cross-microservice query processing, To provide a cloud computing environment and multiple microservices operating in the cloud computing environment on a computer including one or more processors, Each microservice object is associated with metadata that provides an internal implementation definition and a public contract definition, and for each microservice, the implementation definition provides a mapping between the microservice object having properties and a database table / view. The system further comprises using a collective view associated with the multiple microservices to populate the database with a cross-service view, where each microservice is associated with a database schema or database role that restricts which database artifacts are accessible through the role. A method further comprising providing a cross-microservices layer, wherein the cross-microservices layer receives queries based on the cross-services view in response to queries joined across the plurality of microservices, and translates the queries into one or more database queries.

6. The object service framework and the cross-microservice layer are different The method according to claim 5, which automatically converts a query that joins objects of a microservice into a single database query optimized for use with the database.

7. The method according to claim 5, wherein the object service framework is accessible as a cloud service that supports the use of loosely coupled but related microservices.

8. The method according to claim 5, wherein the object-level query based on the cross-service view is translated into one or more database SQL queries that pass over the data or are independently owned by various microservices.

9. A non-temporary computer-readable storage medium having a command to cause a computer to perform a method when read and executed by a computer including one or more processors, wherein the method is To provide a cloud computing environment and multiple microservices operating within it on a computer containing one or more processors, Each microservice object is associated with metadata that provides an internal implementation definition and a public contract definition, and for each microservice, the implementation definition provides a mapping between the microservice object having properties and a database table / view. The system further comprises using a collective view associated with the multiple microservices to populate the database with a cross-service view, where each microservice is associated with a database schema or database role that restricts which database artifacts are accessible through the role. A non-transient, computer-readable storage medium further comprising providing a cross-microservices layer, the cross-microservices layer receiving queries based on the cross-service view in response to queries coupled across the plurality of microservices, and translating the queries into one or more database queries.

10. The object service framework and the cross-microservice layer automatically translate queries that combine objects from different microservices into a single database query optimized for use in the database, according to claim 9, on a non-temporary computer-readable storage medium.

11. The non-transient computer-readable storage medium according to claim 9, wherein the object service framework is accessible as a cloud service supporting the use of loosely coupled but related microservices.

12. The non-temporary computer-readable storage medium according to claim 9, wherein the object-level query based on the cross-service view translates the query into one or more database SQL queries that pass over the data or are independently owned by various microservices.

Images