Coordinated scheduling system and method for microservices and plugin hybrid architecture

Abstract

This invention relates to the field of microservices, specifically a collaborative scheduling system and method for a hybrid microservice and plugin architecture. The system obtains microservice attributes from cloud-based microservice logs; determines microservice activation strategies based on these attributes and cloud-based resource configurations; determines process processing queues from user-side task logs; identifies user-side microservice request threads based on these queues; retrieves a plugin set from the hybrid plugin architecture based on these threads; converts the plugin set into several plugin packages locally on the user-side; instructs the cloud to perform resource scheduling on the user-side based on the current status of these plugin packages and the microservice activation strategy; and adjusts the plugin loading status on the user-side based on the current process processing status. By providing microservices and centrally identifying requests at both the cloud and user-side levels, the system provides accurate and predictive plugin configurations to the user-side, ensuring task processing reliability and resource utilization efficiency.

Description

Technical Field

[0001] This invention relates to the field of microservices, and in particular to a collaborative scheduling system and method for a hybrid architecture of microservices and plug-ins. Background Technology

[0002] Microservices refer to small-scale services with independent operational capabilities during terminal operation, primarily targeting specific types of data or tasks. Microservices are executed and managed within the terminal through the installation and uninstallation of related plugins. Microservices and plugins complement each other; to support data or tasks that cannot be processed independently during terminal operation, the terminal is typically monitored throughout its operation. When a microservice requirement arises, the corresponding plugin is downloaded and installed, enabling the microservice to run after installation. This microservice implementation method ensures that the terminal's microservice needs are met throughout its operation. However, plugin downloading and installation are time-consuming, and as task complexity increases, the terminal's microservice requirements become increasingly numerous and complex. The "monitoring and downloading plugins simultaneously" approach can disrupt the terminal's main workflow. Therefore, predicting the terminal's microservice requirements and interacting with a hybrid plugin architecture to centrally manage plugin operations is crucial for balancing the terminal's main workflow with microservice loading, ensuring efficient and reliable task processing. Summary of the Invention

[0003] Considering that the existing microservice loading method of "monitoring and downloading plugins simultaneously" on terminals affects the main workflow progress of the terminal and reduces the efficiency and quality of terminal task processing, and also easily leads to repeated or disordered installation and uninstallation of plugins within the terminal, reducing the reliability of terminal task processing and resource utilization efficiency, this invention is proposed to provide a collaborative scheduling system of microservice and plugin hybrid architecture that overcomes or at least partially solves the above problems, including:

[0004] The log analysis module is used to obtain microservice attributes from microservice logs in the cloud;

[0005] The activation strategy determination module is used to determine the microservice activation strategy based on the microservice attributes and the cloud resource configuration.

[0006] The process queue determination module is used to determine the process processing queue from the user's task log;

[0007] The demand thread determination module is used to determine the microservice demand thread of the user terminal based on the process processing queue.

[0008] The plugin retrieval module is used to retrieve a set of plugins from the plugin hybrid architecture based on the microservice requirement thread.

[0009] The plugin conversion module is used to convert the plugin collection into several plugin packages locally on the user's terminal.

[0010] The resource scheduling module is used to instruct the cloud to perform resource scheduling on the user terminal based on the real-time situation of the several plug-in packages on the user terminal and the microservice activation strategy.

[0011] The loading change module is used to change the loading status of the plugin on the user terminal based on the actual process processing status of the user terminal.

[0012] Optionally, the log analysis module is used to obtain microservice attributes from microservice logs in the cloud, including:

[0013] Obtain microservice logs generated after the cloud connects to the current network; wherein the microservice logs include the full-process records of all microservice-related behaviors initiated by the cloud on the network; perform semantic recognition on the full-process records to obtain the microservice attributes of the microservice-related behaviors; wherein the microservice attributes include microservice type and microservice process content;

[0014] The activation strategy determination module is used to determine the microservice activation strategy based on the microservice attributes and the cloud resource configuration, including:

[0015] Based on the microservice attributes, estimate the resources required for each microservice supported by the cloud to maintain normal operation;

[0016] By comparing the resource status with the available resource configuration in the cloud, the resource configuration status within the cloud's resource pool when each microservice is normally activated is determined, thereby generating a microservice activation strategy; wherein the microservice activation strategy includes the resource configuration mode within the resource pool when all microservices supported by the cloud are normally activated.

[0017] Optionally, the processing queue determination module is used to determine the process processing queue from the user's task log, including:

[0018] The active tasks are identified from the user's task logs. The active tasks are then logically decomposed and arranged to obtain the process processing queue of the active tasks. The process processing queue includes a time-series processing queue composed of all independent processes within the active tasks.

[0019] The demand thread determination module is used to determine the microservice demand thread of the user client based on the process processing queue, including:

[0020] The computational stage corresponding to each independent process in the process processing queue is compared with the local computational library configuration on the user terminal to determine the abnormal computational stage where each independent process cannot obtain a response from the computational library; based on the expected completion time of the abnormal computational stage in the independent process, the microservice requirement thread on the user terminal is determined; wherein the microservice requirement thread includes the stage node that the active task execution needs to load external microservices and its microservice requirement attributes.

[0021] Optionally, the plugin retrieval module is used to retrieve a plugin set from the plugin hybrid architecture according to the microservice requirement thread, including:

[0022] Based on the microservice requirement attributes contained in the microservice requirement thread, the plugin hybrid architecture is traversed and queried to determine the plugin storage range that matches the microservice requirement attributes; based on the external status of the plugin storage range, the plugin set is copied and retrieved from the plugin hybrid architecture.

[0023] The plugin conversion module is used to convert the plugin collection into several plugin packages locally on the user's end, including:

[0024] Based on the runtime protocol tag corresponding to the plugin set, the plugin set is converted into several plugin packages locally on the user terminal; wherein each plugin package is compatible with several plugins of the same runtime protocol.

[0025] Optionally, the resource scheduling module is used to instruct the cloud to perform resource scheduling on the user terminal based on the real-time situation of the plurality of plug-in packages on the user terminal and the microservice activation strategy, including:

[0026] Based on the installation time information of the various plugin packages on the user's local machine, determine the actual working time interval of each plugin package on the user's local machine; based on the actual working time interval and the microservice activation strategy, instruct the resource pool in the cloud to perform appropriate resource scheduling;

[0027] The loading change module is used to change the loading status of the plugin on the user client according to the actual process processing status of the user client, including:

[0028] The real-time data throughput during the process processing of the user terminal is obtained to determine whether the user terminal has completed the process processing; based on the completion status of the process processing, the installation status of the plugin on the user terminal remains unchanged or the plugin is uninstalled from the user terminal.

[0029] As one aspect of the present invention, embodiments of the present invention also provide a collaborative scheduling method for a hybrid microservice and plugin architecture, including:

[0030] Step S1: Obtain microservice attributes from microservice logs in the cloud; determine the microservice activation strategy based on the microservice attributes and the resource configuration in the cloud;

[0031] Step S2: Determine the process processing queue from the user's task log; determine the microservice request thread for the user based on the process processing queue;

[0032] Step S3: Based on the microservice requirement thread, retrieve the plugin set from the plugin hybrid architecture; convert the plugin set into several plugin packages locally on the user end;

[0033] Step S4: Based on the real-time status of the several plugin packages on the user's local machine and the microservice activation strategy, instruct the cloud to perform resource scheduling on the user's machine; based on the real-time process processing status of the user's machine, change the loading status of the plugins on the user's machine.

[0034] Optionally, in step S1, microservice attributes are obtained from microservice logs in the cloud; based on the microservice attributes and the resource configuration in the cloud, a microservice activation strategy is determined, including:

[0035] Obtain microservice logs generated after the cloud connects to the current network; wherein the microservice logs include the full-process records of all microservice-related behaviors initiated by the cloud on the network; perform semantic recognition on the full-process records to obtain the microservice attributes of the microservice-related behaviors; wherein the microservice attributes include microservice type and microservice process content;

[0036] Based on the microservice attributes, estimate the resources required for each microservice supported by the cloud to maintain normal operation;

[0037] By comparing the resource status with the available resource configuration in the cloud, the resource configuration status within the cloud's resource pool when each microservice is normally activated is determined, thereby generating a microservice activation strategy; wherein the microservice activation strategy includes the resource configuration mode within the resource pool when all microservices supported by the cloud are normally activated.

[0038] Optionally, in step S2, the process processing queue is determined from the user's task log; based on the process processing queue, the microservice request thread of the user is determined, including:

[0039] The active tasks are identified from the user's task logs. The active tasks are then logically decomposed and arranged to obtain the process processing queue of the active tasks. The process processing queue includes a time-series processing queue composed of all independent processes within the active tasks.

[0040] The computational stage corresponding to each independent process in the process processing queue is compared with the local computational library configuration on the user terminal to determine the abnormal computational stage where each independent process cannot obtain a response from the computational library; based on the expected completion time of the abnormal computational stage in the independent process, the microservice requirement thread on the user terminal is determined; wherein the microservice requirement thread includes the stage node that the active task execution needs to load external microservices and its microservice requirement attributes.

[0041] Optionally, in step S3, according to the microservice requirement thread, a plugin set is retrieved from the plugin hybrid architecture; the plugin set is then converted into several plugin packages locally on the user end, including:

[0042] Based on the microservice requirement attributes contained in the microservice requirement thread, the plugin hybrid architecture is traversed and queried to determine the plugin storage range that matches the microservice requirement attributes; based on the external status of the plugin storage range, the plugin set is copied and retrieved from the plugin hybrid architecture.

[0043] Based on the runtime protocol tag corresponding to the plugin set, the plugin set is converted into several plugin packages locally on the user terminal; wherein each plugin package is compatible with several plugins of the same runtime protocol.

[0044] Optionally, in step S4, based on the real-time status of the several plugin packages on the user's local machine and the microservice activation strategy, the cloud is instructed to perform resource scheduling on the user's machine; based on the real-time process processing status of the user's machine, the loading status of the plugins on the user's machine is changed, including:

[0045] Based on the installation time information of the various plugin packages on the user's local machine, determine the actual working time interval of each plugin package on the user's local machine; based on the actual working time interval and the microservice activation strategy, instruct the resource pool in the cloud to perform appropriate resource scheduling;

[0046] The real-time data throughput during the process processing of the user terminal is obtained to determine whether the user terminal has completed the process processing; based on the completion status of the process processing, the installation status of the plugin on the user terminal remains unchanged or the plugin is uninstalled from the user terminal.

[0047] The beneficial effects of the above-mentioned technical solutions provided in the embodiments of the present invention include at least the following:

[0048] This invention provides a collaborative scheduling system and method for a hybrid microservice and plugin architecture. The system obtains microservice attributes from cloud-based microservice logs; determines microservice activation strategies based on microservice attributes and cloud resource configurations; determines process processing queues from user-side task logs; identifies user-side microservice request threads based on the process processing queues; retrieves a plugin set from the hybrid plugin architecture based on the microservice request threads; converts the plugin set into several plugin packages locally on the user-side; instructs the cloud to perform resource scheduling on the user-side based on the real-time status of the plugin packages on the user-side and the microservice activation strategy; and changes the plugin loading status on the user-side based on the real-time process processing status. By providing microservices and centrally identifying requests at both the cloud and user-side levels, the system provides accurate and predictive plugin configurations to the user-side, ensuring task processing reliability and resource utilization efficiency.

[0049] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings.

[0050] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0051] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0052] Figure 1 This is a schematic diagram of the collaborative scheduling system of the microservice and plug-in hybrid architecture provided in this embodiment of the invention;

[0053] Figure 2 This is a flowchart illustrating the collaborative scheduling method for a hybrid microservice and plugin architecture provided in this embodiment of the invention. Detailed Implementation

[0054] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0055] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0056] Please see Figure 1 As shown in this embodiment, a collaborative scheduling system for a hybrid microservice and plugin architecture is provided. This collaborative scheduling system for a hybrid microservice and plugin architecture includes:

[0057] The log analysis module is used to obtain microservice attributes from microservice logs in the cloud;

[0058] The activation strategy determination module is used to determine the microservice activation strategy based on the microservice attributes and cloud resource configuration.

[0059] The process queue determination module is used to determine the process processing queue from the user's task log;

[0060] The Demand Thread Determination module is used to determine the microservice demand threads on the user side based on the process processing queue.

[0061] The plugin retrieval module is used to retrieve a collection of plugins from the plugin hybrid architecture based on the microservice requirement thread.

[0062] The plugin conversion module is used to convert a collection of plugins into several plugin packages locally on the user's device.

[0063] The resource scheduling module is used to instruct the cloud to schedule resources for the user based on the real-time status of several plugin packages on the user's local machine and the microservice activation strategy.

[0064] The loading change module is used to change the loading status of the plugin on the user's end based on the real-time process of the user's end.

[0065] In the above technical solution, the collaborative scheduling system of the microservice and plug-in hybrid architecture provides microservices and centrally identifies requirements in the cloud and on the user end, and provides accurate and predictable plug-in configurations for the user end, ensuring the reliability of task processing and the efficiency of resource utilization.

[0066] In another embodiment, the log analysis module is used to obtain microservice attributes from microservice logs in the cloud, including:

[0067] Obtain the microservice logs generated after the cloud connects to the current network; the microservice logs include the complete process record of all microservice-related behaviors initiated by the cloud on the network; perform semantic recognition on the complete process record to obtain the microservice attributes of the microservice-related behaviors; the microservice attributes include microservice type and microservice process content;

[0068] The activation strategy determination module is used to determine the microservice activation strategy based on microservice attributes and cloud resource configuration, including:

[0069] Based on the characteristics of microservices, estimate the resources required for each microservice supported in the cloud to maintain normal operation;

[0070] By comparing the available resources with the cloud's available resource configuration, the internal resource configuration status of the cloud's resource pool when each microservice is normally activated is determined, thereby generating a microservice activation strategy; the microservice activation strategy includes the internal resource configuration mode of the resource pool when all cloud-supported microservices are normally activated.

[0071] In the above technical solution, multiple computers and other user terminals located at the lowest layer of the network are the main terminals for processing tasks and requiring the loading of different types of microservices to assist in completing those tasks. The cloud, located at the highest layer of the network, is mainly used to monitor the operation of the user terminals, support a hybrid plug-in architecture, and provide services such as downloading different types of plug-ins. It is understandable that the cloud and the user terminals are located at different layers within the network. As a microservice provider, the cloud needs to ensure that it can accurately activate and trigger the corresponding microservice processes to meet the needs of different user terminals, and guarantee that user terminals receive the resource support to implement the microservices.

[0072] Different types or content microservices require different plugins and have different installation processes. To ensure the cloud can respond promptly and accurately to user-end microservice needs, providing matching plugin downloads and sufficient resource support, the cloud needs a comprehensive understanding of the microservice initiation and response status across the entire network. To this end, we first acquire the microservice logs generated after the cloud connects to the current network. These logs fully record the cloud's actions in response to the microservice requests of all users within the same network. For example, when a user initiates a microservice request, the cloud analyzes the request, searches for suitable plugins within the plugin hybrid architecture, packages and sends the plugin to the user, and records the plugin's local installation on the user's end—a series of processes. This generates a complete record of all microservice-related behaviors. Next, we perform keyword recognition on these records, extracting fields containing microservice names and / or microservice identifiers. Semantic recognition of these fields yields microservice attributes such as the microservice type and microservice process content corresponding to the aforementioned microservice-related behaviors. This provides a basis for subsequently identifying the resource support required for each type of microservice.

[0073] Microservices are small-scale services implemented for specific types of data or tasks. During execution, microservices inevitably require at least one of the following resources: computing power, memory, or bandwidth. For each type of microservice to execute normally, the cloud itself needs to configure at least one of these resources (i.e., the cloud needs to have sufficient idle computing power, memory, or bandwidth resources). As the above analysis shows, the resources required by the cloud for each type of microservice during normal execution should be relatively fixed. Therefore, based on the microservice attributes, the resources required for the normal operation of each type of microservice supported by the cloud (such as the required amount of computing power, memory, or bandwidth) must be estimated. Only when the cloud can meet these resource requirements can the normal operation of each type of service be guaranteed. To distinguish between the resources provided by the cloud to support the normal operation of microservices and other resources within the cloud, a dedicated resource pool is configured for each microservice. Whenever the cloud needs to support the normal operation of a type of microservice, the resource pool will be configured with the corresponding type and quantity of resources to ensure the normal activation of that type of microservice. To this end, by comparing the above resource information with the available resource configuration in the cloud, we can determine the resource configuration status within the cloud resource pool when each microservice is normally activated, and determine the resource configuration mode within the resource pool (i.e., the type and quantity of resource configuration within the resource pool) for each microservice supported by the cloud when it is normally activated. In this way, we can establish a one-to-one correspondence between each type of microservice and the type and quantity of resource configuration within the cloud resource pool, providing an accurate basis for the resource information that the cloud needs to provide when the client initiates a corresponding type of microservice request.

[0074] In another embodiment, a process queue determination module is used to determine the process processing queue from the user's task log, including:

[0075] The active tasks are identified from the user's task logs. The active tasks are then logically decomposed and arranged to obtain the process processing queue for the active tasks. The process processing queue includes a time-series processing queue composed of all independent processes within the active tasks.

[0076] The demand thread determination module is used to determine the microservice demand threads on the user side based on the process processing queue, including:

[0077] The computational stages corresponding to each independent process in the process processing queue are compared with the local computational library configuration on the user end to identify the abnormal computational stages that each independent process cannot obtain a response from the computational library. Based on the expected completion time of the abnormal computational stages in the independent process, the microservice requirement threads on the user end are determined. The microservice requirement threads include the stage nodes that require loading external microservices for active task execution and their microservice requirement attributes.

[0078] In the above technical solution, microservices are used when the user client encounters data and / or task portions that cannot be handled by its local configuration alone. In this case, the user client needs to obtain suitable plugins from the cloud for local installation and borrow appropriate resources from the cloud to ensure the plugins function correctly. Considering the large volume of tasks and data processed by the user client, there may be numerous unprocessable data and / or task portions during the processing of a single task. These unprocessable data and / or task portions may be distributed across different processes within the task. To ensure the user client can properly process the overall task, it is necessary to accurately identify and label each process with microservice requirements, ensuring that the type and / or content of the required microservices are accurately determined for each process.

[0079] To provide reliable and complete microservice support for the entire user-side task processing process, active tasks are identified from the user-side task logs. These active tasks are then logically decomposed and arranged to obtain a process processing queue. This process decomposes active tasks into a time-series processing queue composed of all independent processes. Each independent process corresponds to a relatively independent data portion and / or task portion within the active task. Using each independent process as a unit, and considering the user-side's own computing capabilities, it is determined whether each independent process can be processed normally locally on the user-side. This determines the microservice requirements of each independent process (e.g., whether microservices are needed and / or the type and content of the microservices required). Specifically, the computational stages corresponding to each independent process in the process processing queue are compared with the user-side's local computational library configuration to identify abnormal computational stages where each independent process cannot obtain a response from the computational library. These abnormal computational stages can be, but are not limited to, data portions and / or task portions within each independent process that cannot be processed normally using only the functions and algorithms in the user-side's local computational library. Based on the expected implementation time of the abnormal operation step in the independent process (i.e., the expected processing time of the above-mentioned abnormal operation step in the independent process), the link nodes that need to load external microservices and their microservice requirement attributes when the user executes the active task are determined. This accurately marks the microservice requirements of the entire active task processing process, providing a basis for timely acquisition of appropriate plugins and resources from the cloud.

[0080] In another embodiment, the plugin retrieval module is used to retrieve a set of plugins from the plugin hybrid architecture based on the microservice demand thread, including:

[0081] Based on the microservice requirement attributes contained in the microservice requirement thread, the plugin hybrid architecture is traversed and queried to determine the plugin storage range that matches the microservice requirement attributes; based on the external state of the plugin storage range, the plugin set is copied and retrieved from the plugin hybrid architecture.

[0082] The plugin conversion module is used to convert a collection of plugins into several plugin packages locally on the user's device, including:

[0083] Based on the runtime protocol tag corresponding to the plugin set, the plugin set is converted into several plugin packages on the user's local machine; each plugin package is compatible with several plugins of the same runtime protocol.

[0084] In the above technical solution, as described above, microservices require corresponding plugins to be installed locally on the user's end to execute. To ensure that the correct plugins are installed correctly on the user's end, the plugin hybrid architecture is traversed and queried according to the microservice requirement attributes contained in the microservice requirement thread to determine the plugin storage area that matches the microservice requirement attributes. This plugin storage area stores plugins that assist in completing the corresponding microservice. Then, based on the external connection status of the plugin storage area, the plugin set is copied and retrieved from the plugin hybrid architecture. For example, if the plugin storage area is in a normal external connection state (i.e., the plugin storage area can be read normally), the plugin set is copied and retrieved from the plugin storage area; otherwise, it is not copied and retrieved. This improves the accuracy of plugin retrieval. Furthermore, different plugins within the plugin set retrieved from the plugin hybrid architecture support different operating protocols, and the installation of plugins on the user's end requires the cooperation of the user's local operating protocol. To improve the efficiency of plugin installation within the user client and reduce the load of plugin installation on the user client, the plugin set is converted into several plugin packages locally on the user client based on the runtime protocol tag corresponding to the plugin set. This makes each plugin package compatible with several plugins of the same runtime protocol. In this way, the user client only needs to call the runtime protocol once for each plugin package to complete the installation operation of all plugins in the plugin package.

[0085] In another embodiment, the resource scheduling module is used to instruct the cloud to perform resource scheduling on the user terminal based on the real-time status of several plugin packages on the user terminal and the microservice activation strategy, including:

[0086] Based on the installation time information of several plugin packages on the user's local machine, determine the actual working time range of each plugin package on the user's local machine; based on the actual working time range and the microservice activation strategy, instruct the cloud resource pool to perform appropriate resource scheduling.

[0087] The loading change module is used to change the loading status of the plugin on the user's client based on the real-time progress of the client's process, including:

[0088] Obtain the real-time data throughput during the process processing on the user side to determine whether the user side has completed the process processing; based on the completion status of the process processing, maintain the installation status of the plugin on the user side or uninstall the plugin from the user side.

[0089] In the above technical solution, in actual operation, the user can only access resources from the cloud through the successfully installed plugin on the user's client to handle the aforementioned abnormal operation. Specifically, based on the installation time information of several plugin packages on the user's client, the actual working time interval of each plugin package on the user's client is determined. This actual working time interval refers to the allowed working time interval on the user's client after all plugins under each plugin package are successfully installed. Within this actual working time interval, the corresponding plugin has the permission to access resources from the cloud. Then, based on the actual working time interval and the microservice activation strategy, the cloud resource pool is instructed to perform appropriate resource scheduling. For example, based on the resource configuration mode corresponding to the corresponding type of microservice in the microservice activation strategy and the actual working time interval of the corresponding type of microservice on the user's client, the cloud resource pool is instructed to perform appropriate resource scheduling to ensure that the resource pool has the appropriate type and quantity of resources for the corresponding type of microservice to use. The system also acquires the real-time data throughput (i.e., the amount of real-time input / output data) during the user-side process. If the real-time data throughput is within a preset range, the user-side is considered to have completed process processing; otherwise, it is considered that the user-side has not completed process processing. If process processing is complete, the plugin is uninstalled from the user-side; if process processing is incomplete, the plugin's installation status on the user-side remains unchanged. Through this method, the plugin configuration is provided to the user-side accurately and predictively, ensuring the reliability of task processing and the efficiency of resource utilization.

[0090] Please see Figure 2 As shown, an embodiment of this application provides a collaborative scheduling method for a hybrid microservice and plugin architecture. This collaborative scheduling method for a hybrid microservice and plugin architecture includes:

[0091] Step S1: Obtain microservice attributes from the microservice logs in the cloud; determine the microservice activation strategy based on the microservice attributes and the cloud resource configuration;

[0092] Step S2: Determine the process processing queue from the user's task logs; based on the process processing queue, determine the microservice request threads on the user's end.

[0093] Step S3: Based on the microservice requirement thread, retrieve the plugin collection from the plugin hybrid architecture; convert the plugin collection into several plugin packages locally on the user's end;

[0094] Step S4: Based on the actual status of several plugin packages on the user's local machine and the microservice activation strategy, instruct the cloud to perform resource scheduling on the user's machine; based on the actual process processing status on the user's machine, change the loading status of the plugins on the user's machine.

[0095] In the above technical solution, the collaborative scheduling method of the microservice and plug-in hybrid architecture provides microservices and centrally identifies requirements in the cloud and on the user end, providing accurate and predictable plug-in configurations for the user end, thus ensuring the reliability of task processing and the efficiency of resource utilization.

[0096] In another embodiment, in step S1, microservice attributes are obtained from microservice logs in the cloud; based on the microservice attributes and cloud resource configuration, a microservice activation strategy is determined, including:

[0097] Obtain the microservice logs generated after the cloud connects to the current network; the microservice logs include the complete process record of all microservice-related behaviors initiated by the cloud on the network; perform semantic recognition on the complete process record to obtain the microservice attributes of the microservice-related behaviors; the microservice attributes include microservice type and microservice process content;

[0098] Based on the characteristics of microservices, estimate the resources required for each microservice supported in the cloud to maintain normal operation;

[0099] By comparing the available resources with the cloud's available resource configuration, the internal resource configuration status of the cloud's resource pool when each microservice is normally activated is determined, thereby generating a microservice activation strategy; the microservice activation strategy includes the internal resource configuration mode of the resource pool when all cloud-supported microservices are normally activated.

[0100] In another embodiment, in step S2, the process processing queue is determined from the user's task log; based on the process processing queue, the microservice request thread on the user's end is determined, including:

[0101] The active tasks are identified from the user's task logs. The active tasks are then logically decomposed and arranged to obtain the process processing queue for the active tasks. The process processing queue includes a time-series processing queue composed of all independent processes within the active tasks.

[0102] The computational stages corresponding to each independent process in the process processing queue are compared with the local computational library configuration on the user end to identify the abnormal computational stages that each independent process cannot obtain a response from the computational library. Based on the expected completion time of the abnormal computational stages in the independent process, the microservice requirement threads on the user end are determined. The microservice requirement threads include the stage nodes that require loading external microservices for active task execution and their microservice requirement attributes.

[0103] In another embodiment, in step S3, based on the microservice requirement thread, a plugin collection is retrieved from the plugin hybrid architecture; the plugin collection is then converted into several plugin packages locally on the user end, including:

[0104] Based on the microservice requirement attributes contained in the microservice requirement thread, the plugin hybrid architecture is traversed and queried to determine the plugin storage range that matches the microservice requirement attributes; based on the external state of the plugin storage range, the plugin set is copied and retrieved from the plugin hybrid architecture.

[0105] Based on the runtime protocol tag corresponding to the plugin set, the plugin set is converted into several plugin packages on the user's local machine; each plugin package is compatible with several plugins of the same runtime protocol.

[0106] In another embodiment, in step S4, based on the real-time status of several plugin packages on the user's local machine and the microservice activation strategy, the cloud is instructed to perform resource scheduling on the user's machine; based on the real-time process processing status of the user's machine, the loading status of the plugins on the user's machine is changed, including:

[0107] Based on the installation time information of several plugin packages on the user's local machine, determine the actual working time range of each plugin package on the user's local machine; based on the actual working time range and the microservice activation strategy, instruct the cloud resource pool to perform appropriate resource scheduling.

[0108] Obtain the real-time data throughput during the process processing on the user side to determine whether the user side has completed the process processing; based on the completion status of the process processing, maintain the installation status of the plugin on the user side or uninstall the plugin from the user side.

[0109] The collaborative scheduling method of the microservice and plug-in hybrid architecture of the present invention corresponds to the operation and effect of the above-mentioned collaborative scheduling system of microservice and plug-in hybrid architecture, and will not be described again here.

[0110] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. This disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims. Thus, if these modifications and variations of the invention fall within the scope of the claims of the invention and their equivalents, the invention is also intended to include these modifications and variations.

Claims

1. A collaborative scheduling system with a hybrid architecture of microservices and plugins, characterized in that, include: The log analysis module is used to obtain microservice attributes from microservice logs in the cloud; The activation strategy determination module is used to determine the microservice activation strategy based on the microservice attributes and the cloud resource configuration. The activation strategy determination module is used to determine the microservice activation strategy based on the microservice attributes and the cloud resource configuration, including: Based on the microservice attributes, estimate the resources required for each microservice supported by the cloud to maintain normal operation; By comparing the resource status with the available resource configuration in the cloud, the resource configuration status within the cloud's resource pool when each microservice is normally activated is determined, thereby generating a microservice activation strategy; wherein the microservice activation strategy includes the resource configuration mode within the resource pool when all microservices supported by the cloud are normally activated; The process queue determination module is used to determine the process processing queue from the user's task log; The demand thread determination module is used to determine the microservice demand threads of the user terminal based on the process processing queue; the demand thread determination module is used to determine the microservice demand threads of the user terminal based on the process processing queue, including: The computational steps corresponding to each independent process in the process processing queue are compared with the local computational library configuration on the user end to identify the abnormal computational steps that each independent process cannot obtain a response from the computational library; based on the expected implementation time of the abnormal computational steps in the independent process, the microservice requirement thread on the user end is determined; wherein the microservice requirement thread includes the step nodes that require loading external microservices for active task execution and their microservice requirement attributes. The plugin retrieval module is used to retrieve a set of plugins from the plugin hybrid architecture based on the microservice requirement thread. The plugin conversion module is used to convert the plugin collection into several plugin packages locally on the user's terminal. The resource scheduling module is used to instruct the cloud to perform resource scheduling on the user terminal based on the real-time situation of the several plug-in packages on the user terminal and the microservice activation strategy. The loading change module is used to change the loading status of the plugin on the user terminal based on the actual process processing status of the user terminal.

2. The collaborative scheduling system of microservice and plug-in hybrid architecture as described in claim 1, characterized in that: The log analysis module is used to obtain microservice attributes from microservice logs in the cloud, including: Obtain microservice logs generated after the cloud connects to the current network; wherein the microservice logs include the full-process records of all microservice-related behaviors initiated by the cloud on the network; perform semantic recognition on the full-process records to obtain the microservice attributes of the microservice-related behaviors; wherein the microservice attributes include microservice type and microservice process content.

3. The collaborative scheduling system of microservice and plug-in hybrid architecture as described in claim 1, characterized in that: The processing queue determination module is used to determine the process processing queue from the user's task log, including: The active tasks are identified from the user's task logs, and the active tasks are logically decomposed and arranged to obtain the process processing queue of the active tasks; wherein the process processing queue includes a time-series processing queue composed of all independent processes within the active tasks.

4. The collaborative scheduling system of microservice and plug-in hybrid architecture as described in claim 1, characterized in that: The plugin retrieval module is used to retrieve a set of plugins from the plugin hybrid architecture based on the microservice requirement thread, including: Based on the microservice requirement attributes contained in the microservice requirement thread, the plugin hybrid architecture is traversed and queried to determine the plugin storage range that matches the microservice requirement attributes; based on the external status of the plugin storage range, the plugin set is copied and retrieved from the plugin hybrid architecture. The plugin conversion module is used to convert the plugin collection into several plugin packages locally on the user's end, including: Based on the runtime protocol tag corresponding to the plugin set, the plugin set is converted into several plugin packages locally on the user terminal; wherein each plugin package is compatible with several plugins of the same runtime protocol.

5. The collaborative scheduling system of microservice and plug-in hybrid architecture as described in claim 1, characterized in that: The resource scheduling module is used to instruct the cloud to perform resource scheduling on the user terminal based on the real-time situation of the plurality of plug-in packages on the user terminal and the microservice activation strategy, including: Based on the installation time information of the various plugin packages on the user's local machine, determine the actual working time interval of each plugin package on the user's local machine; based on the actual working time interval and the microservice activation strategy, instruct the resource pool in the cloud to perform appropriate resource scheduling; The loading change module is used to change the loading status of the plugin on the user client according to the actual process processing status of the user client, including: The real-time data throughput during the process processing of the user terminal is obtained to determine whether the user terminal has completed the process processing; based on the completion status of the process processing, the installation status of the plugin on the user terminal remains unchanged or the plugin is uninstalled from the user terminal.

6. A collaborative scheduling method for a hybrid architecture of microservices and plugins, characterized in that, include: Step S1: Obtain microservice attributes from microservice logs in the cloud; Based on the microservice attributes and the cloud resource configuration, determine the microservice activation strategy; In step S1, microservice attributes are obtained from the microservice logs in the cloud; Based on the microservice attributes and the cloud resource configuration, a microservice activation strategy is determined, including: Obtain microservice logs generated after the cloud connects to the current network; wherein the microservice logs include the full-process records of all microservice-related behaviors initiated by the cloud on the network; perform semantic recognition on the full-process records to obtain the microservice attributes of the microservice-related behaviors; wherein the microservice attributes include microservice type and microservice process content; Based on the microservice attributes, estimate the resources required for each microservice supported by the cloud to maintain normal operation; By comparing the resource status with the available resource configuration in the cloud, the resource configuration status within the cloud's resource pool when each microservice is normally activated is determined, thereby generating a microservice activation strategy; wherein the microservice activation strategy includes the resource configuration mode within the resource pool when all microservices supported by the cloud are normally activated; Step S2: Determine the process processing queue from the user's task log; determine the microservice request thread for the user based on the process processing queue; In step S2, the process processing queue is determined from the user's task log; based on the process processing queue, the microservice request thread for the user is determined, including: The active tasks are identified from the user's task logs. The active tasks are then logically decomposed and arranged to obtain the process processing queue of the active tasks. The process processing queue includes a time-series processing queue composed of all independent processes within the active tasks. The computational steps corresponding to each independent process in the process processing queue are compared with the local computational library configuration on the user end to determine the abnormal computational steps that each independent process cannot obtain a response from the computational library; based on the expected completion time of the abnormal computational steps in the independent process, the microservice requirement thread on the user end is determined; wherein the microservice requirement thread includes the step nodes that require loading external microservices for the execution of the active task and their microservice requirement attributes. Step S3: Based on the microservice requirement thread, retrieve the plugin set from the plugin hybrid architecture; convert the plugin set into several plugin packages locally on the user end; Step S4: Based on the real-time status of the several plugin packages on the user's local machine and the microservice activation strategy, instruct the cloud to perform resource scheduling on the user's machine; based on the real-time process processing status of the user's machine, change the loading status of the plugins on the user's machine.

7. The collaborative scheduling method for a hybrid microservice and plugin architecture as described in claim 6, characterized in that: In step S3, based on the microservice requirement thread, the plugin set is retrieved from the plugin hybrid architecture; The plugin collection is converted into several plugin packages locally on the user's device, including: Based on the microservice requirement attributes contained in the microservice requirement thread, the plugin hybrid architecture is traversed and queried to determine the plugin storage range that matches the microservice requirement attributes; based on the external status of the plugin storage range, the plugin set is copied and retrieved from the plugin hybrid architecture. Based on the runtime protocol tag corresponding to the plugin set, the plugin set is converted into several plugin packages locally on the user terminal; wherein each plugin package is compatible with several plugins of the same runtime protocol.

8. The collaborative scheduling method for a hybrid microservice and plugin architecture as described in claim 6, characterized in that: In step S4, based on the real-time status of the several plugin packages on the user's local machine and the microservice activation strategy, the cloud is instructed to perform resource scheduling on the user's machine; based on the real-time process processing status of the user's machine, the loading status of the plugins on the user's machine is changed, including: Based on the installation time information of the various plugin packages on the user's local machine, determine the actual working time interval of each plugin package on the user's local machine; based on the actual working time interval and the microservice activation strategy, instruct the resource pool in the cloud to perform appropriate resource scheduling; The real-time data throughput during the process processing of the user terminal is obtained to determine whether the user terminal has completed the process processing; based on the completion status of the process processing, the installation status of the plugin on the user terminal remains unchanged or the plugin is uninstalled from the user terminal.

Images