Systems and methods for providing cross-microservice query optimization
The object services framework addresses the challenge of managing microservice dependencies by translating cross-microservice queries into optimized database queries, ensuring efficient and cost-effective operation of complex software applications.
Patent Information
- Application Number
- JP2024527236
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2021-11-12
- Filing Date
- 2021-12-21
- Publication Date
- 2026-01-13
- Estimated Expiration
- 2041-12-21
AI Technical Summary
Managing dependencies between microservices in complex software applications that interact and share data is particularly difficult, especially in enterprise applications, as each microservice operates independently but requires access to other microservices' data for proper functioning.
An object services framework that supports loosely coupled microservices by translating cross-microservice queries into optimized single database queries, allowing each microservice to be independently developed and deployed while facilitating query optimization through public APIs and a cross-microservice layer.
Preserves the benefits of a microservices architecture by enabling rapid evolution and independent operation of microservices while optimizing query performance and reducing operational costs by using a shared database cluster.
Smart Images

Figure 0007797638000004 
Figure 0007797638000005 
Figure 0007797638000006
Abstract
Description
[Technical Field]
[0001] (Priority Claim) This application claims priority to U.S. patent application Ser. No. 17 / 525,653, entitled "System and Method for Providing Cross-Microservice Query Optimization," filed November 12, 2021, the contents of which are incorporated herein by reference.
[0002] The embodiments described herein relate generally to cloud computing environments, cloud services, and microservices, and are particularly directed to systems and methods that provide cross-microservice query processing. [Background technology]
[0003] To address rapidly changing software requirements, businesses are increasingly turning to technologies such as microservices to provide software applications that can be rapidly evolved and deployed, easily maintained, and produced in a highly available manner.
[0004] In a microservices-oriented architecture, each microservice can operate relatively independently, with its internal operations accessible to the outside world only through a public interface, including owning its own data model and managing its own data.
[0005] 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.
[0006] According to one embodiment, a system and method for providing cross-microservice query processing is described. The system provides an object services framework that supports the use of microservices that may be loosely coupled but may be related in some way, for example, in that the microservices interact with each other or require access to each other's data 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 services framework can be used, for example, to provide a cross-microservice layer that automatically translates queries that join objects from different microservices into a single database query optimized for use with the database. [Brief explanation of the drawings]
[0007] [Figure 1] FIG. 1 illustrates a system for providing cross-microservice query processing according to one embodiment. [Figure 2] FIG. 1 further illustrates a system for providing cross-microservice query processing according to an embodiment. [Figure 3] FIG. 1 further illustrates a system for providing cross-microservice query processing according to an embodiment. [Figure 4] FIG. 1 further illustrates a system for providing cross-microservice query processing according to an embodiment. [Figure 5] FIG. 1 further illustrates a system for providing cross-microservice query processing according to an embodiment. [Figure 6] FIG. 1 further illustrates a system for providing cross-microservice query processing according to an embodiment. [Figure 7] FIG. 1 further illustrates a system for providing cross-microservice query processing according to an embodiment. [Figure 8] FIG. 1 further illustrates a system for providing cross-microservice query processing according to an embodiment. [Figure 9] FIG. 1 further illustrates a system for providing cross-microservice query processing according to an embodiment. [Figure 10] FIG. 1 illustrates a use case of a system for providing cross-microservice query processing according to one embodiment. [Figure 11] FIG. 10 further illustrates a use case of a system for providing cross-microservice query processing according to an embodiment. [Figure 12] FIG. 10 further illustrates a use case of a system for providing cross-microservice query processing according to an embodiment. [Figure 13] FIG. 10 further illustrates a use case of a system for providing cross-microservice query processing according to an embodiment. [Figure 14] FIG. 10 further illustrates a use case of a system for providing cross-microservice query processing according to an embodiment. [Figure 15] FIG. 1 illustrates a method for providing cross-microservice query processing according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION
[0008] (Detailed explanation) To address rapidly changing software requirements, businesses are increasingly turning to technologies such as microservices to provide software applications that can be rapidly evolved and deployed, easily maintained, and produced in a highly available manner.
[0009] In a microservices-oriented architecture, each microservice can operate relatively independently, with its internal operations accessible to the outside world only through a public interface, including owning 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 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 may be managed by a second microservice. The sales order microservice may need product data to properly operate its validation logic, which may require joining queries for data across different microservices, for example, to retrieve sales orders for products supplied by a particular vendor.
[0012] In the above example, since the corresponding data objects owned by different microservices may be managed in their own independent databases, it can be challenging to answer the question of how to execute such queries in an optimized way without sacrificing the benefits provided by a microservices architecture.
[0013] According to one embodiment, a system and method for providing cross-microservice query processing is described herein. The system provides an object services framework that supports the use of microservices that may be loosely coupled but may be related in some way, for example, in that the microservices interact with each other or require access to each other's data to process queries. Each microservice can be independently developed, deployed, and evolved, and interacts with other microservices through contracts or interfaces that are defined as public APIs and exposed through the framework.
[0014] According to one embodiment, the object services framework can be used to provide a cross-microservices layer that automatically translates queries that join objects from different microservices into a single database query optimized for use with the database, for example.
[0015] According to one embodiment, the described approach preserves the benefits provided by a microservices architecture, e.g., that microservices can be rapidly evolved and operated relatively independently, while providing support for features such as coupled query operations that take advantage of available database (e.g., SQL) optimizations.
[0016] Various embodiments may include, for example, various technical features and advantages of the systems and methods described therein.
[0017] According to one embodiment, an Object Services Framework can be used to manage multiple related microservices to simplify the task of evolving and deploying microservices. Each microservice owner is responsible for defining its own objects, application logic, and database artifacts. Common tasks can be provided by the Object Services Framework, such as providing stateless APIs accessible to external systems as managed cloud services.
[0018] According to one embodiment, uniform management of objects owned by various microservices can be used to foster a cloud-native mindset in developers and users. Each object is associated with an internal implementation and a public contract definition, which facilitates maintaining the components in a backward-compatible manner.
[0019] According to one embodiment, the public contract of a microservice object can be exposed to consumers in a consistent manner. The Object Services Framework manages the definition of the object so that the public contract can be exposed in various forms, such as an open API or a GraphQL schema. The object definitions serve as a repository for discovery and documentation purposes and can be consumed by tools such as object catalogs.
[0020] According to one embodiment, the described approach provides a boundary for infrastructure-level microservices, where each microservice interacts with the database and other microservices through an object services framework, which in turn provides common APIs for each object to execute its business logic.
[0021] According to one embodiment, the described approach allows multiple microservices to utilize a single database cluster. Because all interactions are performed through the object services framework, ensuring the boundaries of each microservice, multiple microservices can utilize a single database cluster that is easier to maintain and back up / restore, reducing operational costs and simplifying the transition from existing monolith systems to a microservices architecture.
[0022] According to 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, optimizations that affect multiple microservices can be added. For example, in the case of a join query that involves objects from different microservices but shares the same database instance, the Object Services framework can identify which database objects are involved and reshape the joined query into a single database SQL query, so that the joined query can be performed in an optimized manner that is transparent to the microservice owner. Furthermore, because microservices continue to own their own database instances, there is no need to rewrite object code to take advantage of the optimization; instead, the infrastructure will simply transform the joined query to take a different form. [Cross-microservice query] As mentioned above, managing dependencies between microservices can be 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 microservices in order to function properly.
[0023] Various approaches to this challenge include data replication and data mashups. With data replication, a microservice can replicate data locally owned by other microservices, thereby turning such joins into more performant local database joins. However, this approach incurs the maintenance cost of replicating the data and can result in incorrect query results because the replicated data can become out of sync.
[0024] Because multiple individual queries may be issued for each microservice involved, using a mashup of data, possible post-processing is required to combine query results outside the database. However, because the data sets pulled from each microservice can be very large, mashup joins can also become very inefficient.
[0025] According to one embodiment, a system and method for providing cross-microservice query processing is described. The system provides an object services framework accessible as a cloud service that supports the use of loosely coupled but related microservices. Each microservice can be deployed and evolved independently, and only interacts 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-microservice layer that automatically translates queries that join objects from different microservices into a single database query optimized for use with the database.
[0026] FIG. 1 illustrates a system for providing cross-microservice query processing according to one embodiment.
[0027] According to one embodiment, the structures and processes shown in FIG. 1 and 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 arrangements and processes described herein may be provided by a cloud computing system or other suitably programmed computer system.
[0029] As shown in FIG. 1 , according to one embodiment, cloud computing environment 100 may operate in a cloud computing infrastructure 102 comprising hardware (e.g., processors, memory) and software resources, and cloud computing infrastructure 102 further comprising one or more cloud interfaces 104 or other application program interfaces (APIs) that provide access to shared cloud infrastructure resources, for example, through one or more load balancers A 106 and B 108.
[0030] According to one embodiment, availability domain 131 can contain or provide access to one or more cloud service instances or microservices.
[0031] For example, according to one embodiment, a request for data may be received in one or more availability domains A 120, B 130 for processing by the microservices 122, 132 themselves. Cloud tenants A 142 and B 144 may be provided with partitions within the cloud infrastructure environment through which the tenants can access their cloud resources.
[0032] According to one embodiment, a client device, such as a computing device 160 having device hardware 162 (e.g., processor, memory) and a graphical user interface 166, enables 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, to create or update cloud services.
[0033] According to one embodiment, object services framework 202 accessible as a cloud service supports the use of loosely coupled but related microservices. Each microservice (e.g., microservice A 210), including microservice implementation 212, can be deployed and evolved independently and can expose one or more APIs (e.g., through REST 218 and gRPC 216) that allow microservice lifecycle operations, such as creating / updating artifacts in database 204 or storage services.
[0034] FIG. 2 further illustrates a system for providing cross-microservice query processing according to one embodiment.
[0035] As shown in FIG. 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] 3 and 4 further illustrate a system for providing cross-microservice query processing according to one embodiment.
[0037] 3 and 4, according to one embodiment, each microservice (e.g., microservice B 220, N 230) can similarly 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. Particular microservices may be loosely coupled but related in some way, for example, in that they interact or require access to each other's data 229, 239 to process (logic, business) object-level requests 217, 227 or queries.
[0038] FIG. 5 further illustrates a system for providing cross-microservice query processing according to one embodiment.
[0039] 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, which includes the 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 with its properties and database tables / views, for example, including tables, columns, and other validation or derived business logic as needed.
[0040] According to one embodiment, the public properties and behaviors defined by each microservice's public contract definition are made accessible to external systems through public APIs and protocols such as REST and gRPC.
[0041] FIG. 6 further illustrates a system for providing cross-microservice query processing according to one embodiment.
[0042] 6, according to one embodiment, collective views associated with microservices and their objects are used to populate (262, 264) the database with cross-service views 250. An example of this is shown in Example 1 below, according to one embodiment. In Example 1, the cross-service views are used in processing object-level queries.
[0043] FIG. 7 further illustrates a system for providing 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 through business object APIs accessible through REST and gRPC. Such business object APIs provide optimizations without the cost of remote call latency and serialization / deserialization.
[0045] According to one embodiment, a cross-microservice layer 260 is provided where, in response to queries that join across multiple microservices, the cross-microservice layer receives object-level queries based on the cross-service view and translates the 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 the database queries.
[0046] According to one embodiment, the cross-microservices layer manages through metadata a catalog of objects supported by the object services framework, including each object's public contract, i.e., how the object can be accessed from outside the environment, and each object's internal implementation, e.g., which tables and columns it uses.
[0047] Furthermore, according to one embodiment, the cross-microservice layer provides routines adapted to receive requests from clients, e.g., via REST or gRPC interfaces, and translate the received requests from object-level queries into physical database (e.g., SQL) queries.
[0048] For example, according to one embodiment, optimal query performance may be achieved by an infrastructure that translates cross-microservice combined queries into a single / optimized database SQL query when related microservices share the same database instance.
[0049] FIG. 8 further illustrates a system for providing cross-microservice query processing according to one embodiment.
[0050] According to one embodiment, by applying an infrastructure to manage interactions between microservices and using an underlying database, the system allows multiple microservices to use the same database cluster while ensuring isolation of the microservices. Using a single database cluster minimizes operational costs, 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 / unique microservice that acts 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 a different microservice.
[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 (by microservice A) through the role.
[0053] FIG. 9 further illustrates a system for providing cross-microservice query processing according to one embodiment.
[0054] For example, according to one embodiment, microservice B may be associated with a database schema or database role 276 that restricts which database artifacts are accessible by the role (by microservice B).
[0055] As described above, according to one embodiment, when the cross-microservice layer is used in response to queries that join across multiple microservices, the cross-microservice layer can receive object-level queries based on the cross-service view and translate the queries into one or more physical database (e.g., SQL) queries that span data or are otherwise independently owned by the various microservices.
[0056] According to one embodiment, the system gives microservices the flexibility to change their database strategies without having to rewrite existing code and without sacrificing functionality or performance, especially for combined queries involving multiple microservices. [Usage example] 10-13 illustrate use cases for a system that provides cross-microservice query processing according to one embodiment.
[0057] As shown in Figures 10-13, according to one embodiment, each microservice (e.g., order microservice 310, product microservice 32) can be deployed and evolved independently, as well as 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 can be created for the 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 with order-level conditions that the order's total amount is greater than 1000 or has lines with a product price greater than 10.
[0061] According to one embodiment, the Object Services Framework maintains business object definitions, including table and column mappings, so that the Object Services Framework can translate such queries into, for example, one or more physical database queries.
[0062] [Table 2]
[0063] According to one embodiment, the system can apply database query optimization, for example, to transform the database queries described above into one query that directly returns a JSON document.
[0064] [Table 3]
[0065] According to one embodiment, since the schemas / roles of one microservice cannot access the tables / views of other microservices, 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 joins between different microservices are required.
[0066] FIG. 14 further illustrates an example use case of a system that provides cross-microservice query processing according to one embodiment.
[0067] As shown in FIG. 14, according to one embodiment, the system enables the use of cross-service views 332 when processing object-level requests or queries (e.g., the example shown in Example 1 above) and when preparing database queries 336 (e.g., the examples shown in Examples 2 and 3 above), including using available database query optimizations as needed. [Cross-microservice query processing] FIG. 15 illustrates a method for providing cross-microservice query processing according to one embodiment.
[0068] As shown in FIG. 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, which includes the properties and behaviors of the microservice object that are accessible by external systems.
[0069] In step 342, for each microservice, the implementation definition provides a mapping between a microservice object with properties and database tables / views, including, for example, tables, columns, and other validation or derivation business logic as needed.
[0070] In step 344, the collective views associated with the microservices and their objects are used to populate the cross-service view into the database.
[0071] In step 346, each microservice is associated with a database schema or database role, which restricts which database artifacts are accessible through the role.
[0072] In step 348, the public properties and behaviors defined by each microservice's public contract definition are made accessible to external systems through public APIs and protocols such as REST and gRPC.
[0073] At step 350, a cross-microservice layer is provided that, in response to queries that join across multiple microservices, receives object-level queries based on the cross-service view and translates the queries into one or more physical database (e.g., SQL) queries, whereby native database SQL optimizations can be leveraged to achieve the desired query optimization.
[0074] According to 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 according to the teachings of the present disclosure. As will be apparent to those skilled in the software arts, appropriate software coding may be readily prepared by skilled programmers based on the teachings of the present disclosure.
[0075] In some embodiments, the teachings herein may include a computer program product that is a non-transitory computer-readable storage medium having stored thereon instructions that can be used to program a computer to perform any of the processes of the present teachings. Examples of such storage media may include, but are not limited to, hard disk drives, hard disks, fixed disks, or other electromechanical data storage devices, floppy disks, optical disks, DVDs, CD-ROMs, microdrives, and magneto-optical disks, ROM, RAM, EPROM, EEPROM, DRAM, VRAM, flash memory devices, magnetic or optical cards, nanosystems, or other types of storage media or devices suitable for non-transitory storage of instructions and / or data.
[0076] The foregoing description has been provided for purposes of illustration and explanation. It is not intended to be exhaustive or to limit the scope of protection to the precise form disclosed. Many modifications and variations will be apparent to those skilled in the art.
[0077] The embodiments were chosen and described to best explain the principles of the present teachings and their practical application, so as to enable those skilled in the art to understand various embodiments and to contemplate various modifications suitable for particular uses. It is intended that the scope be defined by the following claims and their equivalents.
Claims
1. 1. A system for providing cross-microservice query processing, comprising: a computer including one or more processors that provides a cloud computing environment and a plurality of microservices that operate in the cloud computing environment; an object services framework; Each microservice object is associated with metadata that provides its internal implementation definition and its public contract definition. For each microservice, the implementation definition provides a mapping between a microservice object with properties and a database table / view; The collective view associated with the plurality of microservices and their objects is used to populate a cross-service view into a database; Each microservice is associated with a database schema or database role that restricts which database artifacts are accessible through that role. a cross-microservice layer is provided that receives queries based on the cross-service view and translates the queries into one or more database queries in response to queries that join across the microservices.
2. 10. The system of claim 1, wherein the object services framework and the cross-microservices layer automatically translate queries that join objects from different microservices into a single database query optimized for use with the database.
3. 3. The system of claim 1, wherein the object services framework is accessible as a cloud service that supports the use of loosely coupled but related microservices.
4. 4. The system of claim 1, wherein the cross-service view-based object-level query translates the query into one or more database SQL queries that span the metadata or are otherwise independently owned by various of the microservices.
5. 1. A method for providing cross-microservice query processing, comprising: providing, in a computer including one or more processors, a cloud computing environment and a plurality of microservices operating in the cloud computing environment; associating each microservice object with metadata that provides an internal implementation definition and a public contract definition, wherein for each microservice, the implementation definition provides a mapping between the microservice object with properties and database tables / views; using collective views associated with the plurality of microservices to populate a cross-service view into a database, each microservice being associated with a database schema or database role that restricts which database artifacts are accessible through that role; The method further comprises providing a cross-microservice layer, the cross-microservice layer receiving queries based on the cross-service view in response to queries that join across the microservices and translating the queries into one or more database queries.
6. 6. The method of claim 5, wherein an object services framework and the cross-microservices layer automatically translate queries that join objects from different microservices into a single database query optimized for use with the database.
7. 7. The method of claim 6, wherein the object services framework is accessible as a cloud service that supports the use of loosely coupled but related microservices.
8. 8. The method of claim 5, wherein the cross-service view-based object-level query translates the query into one or more database SQL queries that span the metadata or are otherwise independently owned by various of the microservices.
9. A program for causing a computer including one or more processors to execute a method, the method comprising: Providing, in the computer, a cloud computing environment and a plurality of microservices operating therein; associating each microservice object with metadata that provides an internal implementation definition and a public contract definition, wherein for each microservice, the implementation definition provides a mapping between the microservice object with properties and database tables / views; using collective views associated with the plurality of microservices to populate a cross-service view into a database, each microservice being associated with a database schema or database role that restricts which database artifacts are accessible through that role; providing a cross-microservice layer that receives queries based on the cross-service view in response to queries that join across the microservices and translates the queries into one or more database queries.
10. 10. The program of claim 9, wherein an object services framework and the cross-microservices layer automatically translate queries that join objects from different microservices into a single database query optimized for use with the database.
11. 11. The program of claim 10, wherein the object services framework is accessible as a cloud service that supports the use of loosely coupled but related microservices.
12. 12. The program of claim 9, wherein the object-level query based on the cross-service view translates the query into one or more database SQL queries that span the metadata or are otherwise independently owned by various of the microservices.
Citation Information
Patent Citations
Decoupled IoT Application Store System for Virtual Objects Sharing and Discovery
KR1020210090517A
Lightweight DBMS based on functional microservices
US20210303577A1