System and method for orchestrating microservice external dependency complexity

Abstract

The application discloses a system and method for solving the complexity of external dependence of microservices by means of orchestration, which comprises an information base, a low-code front-end editor, a flow file, an orchestrable framework and an independent dynamic library, wherein the low-code front-end editor, the flow file and the independent dynamic library are connected with the information base, the flow file is further connected with the low-code front-end editor and the orchestrable framework respectively, and the orchestrable framework is further connected with the independent dynamic library. The monomer in the microservice is further split into API and flow, so that the core business and external dependence are decoupled. Meanwhile, the API is arranged by the low-code front-end editor to generate the flow, so that the external dependence can be flexibly selected without changing the core business logic, and the external dependence which is not needed does not need to be programmed into the microservice image, thereby saving the storage and memory space.

Description

Technical Field

[0001] This invention relates to the field of microservices technology, and more specifically, to a system and method for resolving the complexity of external dependencies of microservices through orchestration. Background Technology

[0002] like Figure 1 Currently, microservices rely on numerous external services, with various options available. For example, configuration centers can be Etcd, Zookeeper, Spring Cloud Config, Apollo, or Nacos, while message queues can be RabbitMQ or Kafka. To ensure compatibility across different user environments, the microservice effectively becomes a monolith, requiring all external dependencies and core business logic to be compiled together and their selections recorded in configuration files. This leads to a continuous increase in executable file size and runtime memory consumption. Furthermore, if multiple microservices use the same dependency, all microservices need to be recompiled when that dependency is upgraded. Additionally, user environments may exhibit different dependency invocation orders; for instance, a value might be retrieved from dependency A and then applied to dependency B, or vice versa. These scenarios cannot be exhaustively addressed through configuration files, continuously increasing configuration complexity. Summary of the Invention

[0003] To address the problems existing in the prior art, this invention provides a system and method for resolving the complexity of external dependencies of microservices through orchestration.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: a system for resolving the complexity of external dependencies of microservices through orchestration, comprising: an information repository, a low-code front-end editor, a flow file, an orchestration framework, and an independent dynamic library. The low-code front-end editor, the flow file, and the independent dynamic library are all connected to the information repository. The flow file is also connected to the low-code front-end editor and the orchestration framework, respectively. The orchestration framework is also connected to the independent dynamic library.

[0005] Furthermore, the programmable framework includes: a starter, an API / flow library, and a core API, wherein the starter is connected to the core API and the API / flow library respectively.

[0006] Furthermore, the launcher is connected to an independent dynamic library and a flow file, respectively.

[0007] Furthermore, the core APIs include: startMain, loadLibrary, loadFlow, runApi, and runFlow. startMain is used to read the main flow from the flow file and, according to the main flow's arrangement, calls the relevant functions in the API / flow library. loadLibrary is used to read the required dynamic libraries and flows from independent dynamic libraries and stores the API information within the dynamic libraries into the API / flow library. loadFlow is used to read the required flow files and store the flow's functionality into the API / flow library. runApi is used to execute external APIs. runFlow is used to execute flows.

[0008] This invention also provides a method for working with the system that resolves the complexity of external dependencies in microservices through orchestration, specifically including the following steps:

[0009] Step S1: Arrange the flow using a low-code front-end editor;

[0010] Step S2: Start the programmable framework, load the main flow in the flow file, and continue to load independent dynamic libraries and other flows in the flow file according to the arrangement of the main flow;

[0011] Step S3: Execute external APIs or flows through the core business code in the independent dynamic library.

[0012] Further, step S1 includes the following sub-steps:

[0013] Step S1.1: Compile an independent dynamic library and provide an API interface;

[0014] Step S1.2: Fill the API information into the information database;

[0015] Step S1.3: The low-code front-end editor reads API information from the information repository to facilitate drag-and-drop and editing;

[0016] Step S1.4: Create a flow file using a low-code front-end editor;

[0017] Step S1.5: The low-code front-end editor writes the layout into the flow file based on the editing results;

[0018] Step S1.6: The low-code front-end editor fills the information written into the orchestrated flow file into the information database.

[0019] Further, step S2 includes the following sub-steps:

[0020] Step S2.1: The caller starts the orchestration framework and passes the main flow path in the flow file to the initiator;

[0021] Step S2.2: The initiator loads the main flow and performs parsing;

[0022] Step S2.3: According to the definition of the main flow, call loadLibrary, pass in the list of dynamic libraries to be loaded, load the required dynamic libraries, obtain the API information in them, and store the API information in the API / flow library;

[0023] Step S2.4: According to the definition of the main flow, call loadFlow, pass in the list of flow files to be loaded, load the required flow files, and store the flow information in the API / flow library;

[0024] Step S2.5: According to the definition of the main flow, call runAPI or runFlow to invoke the business logic.

[0025] Furthermore, in step S3, when the core business code executes an external API, the specific process is as follows:

[0026] i. In the core business code, pass in the required API name and parameters through runApi, and store the API name and parameters in the information database;

[0027] ii. When orchestrating the main flow, pass the name of the dynamic library corresponding to the dependent API as a parameter to loadLibrary;

[0028] iii. At startup, the corresponding dynamic library is loaded and the API information is written to the API / flow library; at runtime, runApi is called to find the API information in the API / flow library and execute it.

[0029] Furthermore, in step S3, when the core business code executes the flow, the specific process is as follows:

[0030] i. In the core business code, pass in the required flow name and parameters through runFlow, and store the flow name and parameters in the information database;

[0031] ii. When orchestrating the main flow, pass the name of the dynamic library corresponding to the dependent API as a parameter to loadLibrary, and pass the file name of the flow corresponding to the dependent flow as a parameter to loadFlow;

[0032] iii. At startup, the corresponding flow file is loaded and the flow information is written to the flow library; at runtime, runFlow is called to search for the flow information in the API / flow library and execute it.

[0033] Compared with the prior art, the present invention has the following beneficial effects: The present invention further decomposes the monolith in microservices into APIs and flows, thereby decoupling the core business and external dependencies; at the same time, the APIs are orchestrated by a low-code front-end editor to generate flows, so that external dependencies can be flexibly selected without changing the core business logic, and unnecessary external dependencies do not need to be included in the microservice image, thereby saving storage and memory space. Attached Figure Description

[0034] Figure 1 A framework diagram for resolving complex external dependencies in existing single microservices;

[0035] Figure 2 This is a framework diagram of the system for resolving the complexity of external dependencies of microservices through orchestration, as described in this invention.

[0036] Figure 3 This is a flowchart of the flow arrangement using a low-code front-end editor in this invention;

[0037] Figure 4 This is a flowchart of the programmable framework startup process in this invention;

[0038] Figure 5 This diagram illustrates how different message queue dynamic libraries are loaded on demand in the main flow and the corresponding APIs in the dynamic libraries are executed.

[0039] like Figure 6 This is a diagram illustrating the core business logic that depends on the main flow. Detailed Implementation

[0040] The technical solution of the present invention will be further explained and described below with reference to the accompanying drawings and embodiments.

[0041] like Figure 2This is a framework diagram of the system for resolving the complexity of external dependencies in microservices through orchestration, as described in this invention. The system includes: an information repository, a low-code front-end editor, flow files, an orchestratable framework, and independent dynamic libraries. The information repository contains API information and flow information, specifically including fields such as type, name, function, the dynamic library where the API resides, the names of input / return parameters, and dependent APIs and flows. API information is filled in by developers after writing the API, while flow information is automatically generated by the low-code front-end editor after editing the flow. Based on the information repository, the low-code front-end editor allows users to generate the final flow through drag-and-drop editing. The flow content is stored in a flow file, and the flow information is filled into an information table. The flow file contains: a main flow and other flows. The main flow initializes external dependencies at startup and eventually enters the user's core business logic. For the same type of interface but different underlying implementations, a fixed-name flow is called in the core business logic to shield the underlying implementation for different user needs. For non-core business logic with different requirements, specific business requirements are implemented in the flow. Other flows, such as those for message queues like Kafka and RabbitMQ, allow the core business logic to call only a unified message queue sending flow, but internally, the Kafka API or RabbitMQ API can be encapsulated according to customer needs. Additionally, there are flows for pre / post processes; for example, when a transaction fails, some users may choose to send SMS alerts, while others may choose to send email alerts. In this invention, independent dynamic libraries are not compiled with the orchestration framework, and the orchestration framework does not depend on independent dynamic libraries. Internally, they are loaded on demand at the underlying level according to the main flow orchestration, greatly saving storage space and memory. These APIs also call other APIs and flows, but not directly through function calls; instead, they are called through the orchestration system, avoiding compile-time dependencies. The orchestration framework is responsible for loading and parsing the main flow, and then loading other flows and dynamic libraries on demand according to the main flow orchestration, and executing various initializations and business logic. Therefore, the low-code front-end editor, flow files, and independent dynamic libraries are all connected to the information repository. The flow files are also connected to the low-code front-end editor and the orchestration framework, and the orchestration framework is also connected to the independent dynamic libraries. This invention further decomposes the monoliths in microservices into APIs and flows, thereby decoupling core business and external dependencies. At the same time, the low-code front-end editor orchestrates APIs to generate flows, allowing for flexible selection of external dependencies without changing the core business logic. Unnecessary external dependencies do not need to be incorporated into the microservice image, thus saving storage and memory space.

[0042] The programmable framework in this invention includes: a launcher, an API / flow library, and a core API. The launcher is responsible for system initialization and executes the main flow by calling the core API. The API / flow library is the result of loading dynamic libraries and flow files using the core API. The core API can be used to call API / flows within the API code or flow. Therefore, the launcher is connected to the core API and the API / flow library, and also to independent dynamic libraries and flow files.

[0043] The core APIs in this invention include: startMain, loadLibrary, loadFlow, runApi, and runFlow. startMain is used to read the main flow from the flow file and call the relevant functions in the API / flow library according to the arrangement of the main flow. loadLibrary is used to read the required dynamic libraries and flows from the independent dynamic libraries and store the API information in the dynamic libraries into the API / flow library. loadFlow is used to read the required flow files and store the functions of the flows into the API / flow library. runApi is used to execute external APIs. runFlow is used to execute flows.

[0044] This invention also provides a method for resolving the complexity of external dependencies in microservices through orchestration, specifically including the following steps:

[0045] Step S1: Arrange the flow using a low-code front-end editor; such as... Figure 3 Specifically, it includes the following sub-steps:

[0046] Step S1.1: Compile an independent dynamic library and provide an API interface;

[0047] Step S1.2: Fill the API information into the information database;

[0048] Step S1.3: The low-code front-end editor reads API information from the information repository to facilitate drag-and-drop and editing;

[0049] Step S1.4: Create a flow file using a low-code front-end editor;

[0050] Step S1.5: The low-code front-end editor writes the layout into the flow file based on the editing results;

[0051] Step S1.6: The low-code front-end editor fills the information written into the orchestrated flow file into the information database, making it easy to call another existing flow in one flow.

[0052] Step S2: Start the programmable framework, load the main flow from the flow file, and continue loading independent dynamic libraries and other flows from the flow file according to the arrangement of the main flow; such as Figure 4 Specifically, it includes the following sub-steps:

[0053] Step S2.1: The caller starts the orchestration framework and passes the main flow path in the flow file to the initiator;

[0054] Step S2.2: The initiator loads the main flow and performs parsing;

[0055] Step S2.3: According to the definition of the main flow, call loadLibrary, pass in the list of dynamic libraries to be loaded, load the required dynamic libraries, obtain the API information in them, and store the API information in the API / flow library;

[0056] Step S2.4: According to the definition of the main flow, call loadFlow, pass in the list of flow files to be loaded, load the required flow files, and store the flow information in the API / flow library;

[0057] Step S2.5: According to the definition of the main flow, call runAPI or runFlow to invoke the business logic.

[0058] Step S3: Execute external APIs or flows through the core business code in an independent dynamic library; specifically,

[0059] When the core business code executes an external API, the specific process is as follows:

[0060] i. In the core business code, pass in the required API name and parameters through runApi, and store the API name and parameters in the information database;

[0061] ii. When orchestrating the main flow, pass the name of the dynamic library corresponding to the dependent API as a parameter to loadLibrary;

[0062] iii. At startup, the corresponding dynamic library is loaded and the API information is written to the API / flow library; at runtime, runApi is called to find the API information in the API / flow library and execute it.

[0063] When the core business logic executes the flow, the specific process is as follows:

[0064] i. In the core business code, pass in the required flow name and parameters through runFlow, and store the flow name and parameters in the information database;

[0065] ii. When orchestrating the main flow, pass the name of the dynamic library corresponding to the dependent API as a parameter to loadLibrary, and pass the file name of the flow corresponding to the dependent flow as a parameter to loadFlow;

[0066] iii. At startup, the corresponding flow file is loaded and the flow information is written to the flow library; at runtime, runFlow is called to search for the flow information in the API / flow library and execute it.

[0067] Example

[0068] The developers created a small-amount, password-free payment program. It receives requests from a message queue, retrieves the user's maximum small-amount, password-free payment limit, and executes different user-defined business processes based on a comparison between two users. The pseudocode includes: receiving requests from the message queue, retrieving the user's maximum small-amount, password-free payment limit; if the deduction amount > the maximum limit, the deduction fails; otherwise, the deduction succeeds.

[0069] There are two customers, A and B, whose dependencies on surrounding components and business processes differ significantly, as shown in Table 1. In the traditional development model, a large amount of configuration is required for different user choices. At the same time, dependencies such as Kafka, RabbitMQ, SMS, and email need to be compiled into the application, increasing the application size. When more customers are introduced, the continuous new dependency requirements may lead to uncontrollable expansion of configuration and application size.

[0070] Table 1: Comparison of Customer Needs between Customer A and Customer B

[0071]

[0072] After using this invention to resolve the complexity of external dependencies in microservices, all external dependencies are abstracted into external flows, described as: runFlow (receive requests from the message queue), runFlow (obtain the user's maximum small-amount password-free limit), if the deduction amount > the maximum limit, runFlow (deduction failed); otherwise, runFlow (deduction succeeded). The API information of users A and B is extracted using the method of this invention, as shown in Table 2.

[0073] Table 2: API Information

[0074]

[0075] like Figure 5User A needs a Kafka queue, so only the Kafka dynamic library needs to be loaded, not the RabbitMQ dynamic library. User B also needs a RabbitMQ queue, so only the RabbitMQ dynamic library needs to be loaded, not the Kafka dynamic library. User A needs to send SMS messages, so only the ShortMessage dynamic library needs to be loaded, not the Email dynamic library. User B needs to send emails, so only the Email dynamic library needs to be loaded, not the ShortMessage dynamic library. Based on user needs, different main flows were built for users A and B, as shown in Table 3.

[0076] Table 3: Building the main flow based on customer needs

[0077]

[0078] like Figure 6 The core user business logic will abstract its external dependencies into flows, and dependency differences will be implemented within these flows. This way, the core user business logic does not need to be developed and compiled separately for different users, thus saving storage and memory space. The following will explain each of the four flows in detail.

[0079] Table 4: Comparison of the receive request flow files of users A and B based on user requirements.

[0080]

[0081] Table 5: Comparison of the maximum amount that users A and B can obtain for small-amount password-free transactions based on user needs.

[0082]

[0083] Table 6: Comparison of successful deductions for users A and B based on user needs.

[0084]

[0085] Table 7: Comparison of payment failures for users A and B based on user needs.

[0086]

[0087] The above are merely preferred embodiments of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should be considered within the scope of protection of the present invention.

Claims

1. A working method for resolving the complexity of external dependencies in microservices through orchestration, characterized in that, Specifically, the steps include the following: Step S1: Arrange the flow using a low-code front-end editor; including the following sub-steps: Step S1.1: Compile an independent dynamic library and provide an API interface; Step S1.2: Fill the API information into the information database; Step S1.3: The low-code front-end editor reads API information from the information repository to facilitate drag-and-drop and editing; Step S1.4: Create a flow file using a low-code front-end editor; Step S1.5: The low-code front-end editor writes the layout into the flow file based on the editing results; Step S1.6: The low-code front-end editor fills the information written into the orchestrated flow file into the information database; Step S2: Start the programmable framework, load the main flow from the flow file, and continue loading independent dynamic libraries and other flows from the flow file as needed, based on the arrangement of the main flow; including the following sub-steps: Step S2.1: The caller starts the orchestration framework and passes the main flow path in the flow file to the initiator; Step S2.2: The initiator loads the main flow and performs parsing; Step S2.3: According to the definition of the main flow, call loadLibrary, pass in the list of dynamic libraries to be loaded, load the required dynamic libraries, obtain the API information in them, and store the API information in the API / flow library; Step S2.4: According to the definition of the main flow, call loadFlow, pass in the list of flow files to be loaded, load the required flow files, and store the flow information in the API / flow library; Step S2.5: According to the definition of the main flow, call runAPI or runFlow to invoke the business logic; Step S3: Execute external APIs or flows through the core business code in the independent dynamic library.

2. The working method for resolving the complexity of external dependencies in microservices through orchestration as described in claim 1, characterized in that, In step S3, when the core business code executes an external API, the specific process is as follows: i. In the core business code, pass in the required API name and parameters through runApi, and store the API name and parameters in the information database; ii. When orchestrating the main flow, pass the name of the dynamic library corresponding to the dependent API as a parameter to loadLibrary; iii. At startup, the corresponding dynamic library is loaded and the API information is written to the API / flow library; at runtime, runApi is called to find the API information in the API / flow library and execute it.

3. The working method for resolving the complexity of external dependencies in microservices through orchestration as described in claim 1, characterized in that, In step S3, when the core business code executes the flow, the specific process is as follows: i. In the core business code, pass in the required flow name and parameters through runFlow, and store the flow name and parameters in the information database; ii. When orchestrating the main flow, pass the name of the dynamic library corresponding to the dependent API as a parameter to loadLibrary, and pass the file name of the flow corresponding to the dependent flow as a parameter to loadFlow; iii. At startup, the corresponding flow file is loaded and the flow information is written to the flow library; at runtime, runFlow is called to search for the flow information in the API / flow library and execute it.

4. A system that applies the working method for resolving the complexity of external dependencies of microservices through orchestration as described in any one of claims 1-3, characterized in that, include: The system includes an information repository, a low-code front-end editor, flow files, an editable framework, and an independent dynamic library. The low-code front-end editor, flow files, and independent dynamic libraries are all connected to the information repository. The flow files are also connected to the low-code front-end editor and the editable framework, and the editable framework is also connected to the independent dynamic library.

5. The system for resolving the complexity of external dependencies in microservices through orchestration as described in claim 4, characterized in that, The programmable framework includes: a starter, an API / flow library, and a core API, wherein the starter is connected to the core API and the API / flow library respectively.

6. The system for resolving the complexity of external dependencies in microservices through orchestration as described in claim 5, characterized in that, The launcher is connected to an independent dynamic library and a flow file, respectively.

7. The system for resolving the complexity of external dependencies in microservices through orchestration as described in claim 5, characterized in that, The core APIs include: startMain, loadLibrary, loadFlow, runApi, and runFlow. startMain reads the main flow from the flow file and calls relevant functions in the API / flow library according to the main flow's arrangement. loadLibrary reads the required dynamic libraries and flows from independent dynamic libraries and stores the API information from the dynamic libraries into the API / flow library. loadFlow reads the required flow files and stores the flow's functionality into the API / flow library. runApi executes external APIs. runFlow executes flows.

Images