A resource dynamic arrangement system, method and application thereof

Abstract

The present invention discloses a resource dynamic orchestration system, including: a container unit that refers to multiple resources shared by each other, and multiple container units are isolated from each other on threads; the container unit includes a thread pool module, a work queue module, an SQL parsing module and a rejection strategy module; the thread pool module is used for the execution of specific business codes; the work queue module is used to make the work threads in the same container unit execute in an asynchronous manner to improve processing performance; the SQL parsing module is used to parse the business SQL in the microservice, and connect to the data source through Jdbc and execute SQL; the rejection strategy module is used for the strategy that will be executed when the work queue is full, and has built-in direct rejection, exception throwing and direct execution strategies. The present invention provides a lightweight container that does not rely on other third-party technical frameworks and does not need to prepare other basic environments, which greatly improves the speed of early environment construction. At the same time, due to less dependence on third parties, it also reduces the complexity of operation and maintenance.

Description

Technical Field

[0001] The present invention relates to the technical field of resource dynamic scheduling systems, and in particular to a resource dynamic scheduling system, method and application thereof. Background Art

[0002] With the expansion of business and the development of technology, more and more applications are transforming from traditional monolithic architecture to microservice architecture. The characteristic of microservice architecture is to split a business system with multiple functions into service modules with single functions. Each module is an independent process that needs to be deployed separately and requires running resources. When an application has more than 10 microservice modules, how to allocate reasonable system resources to these modules and how to achieve rapid deployment and update of all microservices become difficult problems.

[0003] When multiple microservice processes are put on the same physical machine to run, there will be resource grabbing between processes. For example, if a microservice process has a large number of requests, the microservice will occupy a large amount of CPU and memory. Especially when there is a slow interface in the process, it may even exhaust system resources such as file handles, resulting in system errors such as toomanyopenfiles, which will cause other microservice processes on the physical machine to be unable to use system resources and provide services to the outside world.

[0004] Another problem in the microservice architecture is how to achieve rapid deployment and update of services. When an application has more than 10 microservice modules, and in accordance with the high availability principle of the microservice architecture, the service is generally deployed with 1-2 redundancies. When upgrading certain functions, if there is no responsive automatic deployment mechanism, updating manually will be very chaotic and inefficient. You need to manually kill the microservice processes one by one, then replace the online service package, and finally start the service manually. This process is very cumbersome and inefficient. While consuming a lot of human resources, it is also prone to concurrent problems. For the online system, it is a considerable risk.

[0005] At present, the mainstream technologies related to dynamic resource orchestration are mainly Kubernetes, dockerswarm, Mesos, etc. These technologies provide scheduling of container resources, rapid deployment and expansion of containers, and monitoring of resource usage. Generally speaking, these open source container orchestration technologies can better complete the container management function. However, these open source container orchestration technologies also have the following shortcomings: they rely on container technologies such as Docker, and must first introduce Docker and other containers before they can be used. For some small-scale or closed network scenarios, open source solutions are not very suitable. In addition, Dockerimage is relatively heavy when used. An application with a size of only tens of megabytes will usually become ten or even dozens of times larger when packaged into a docker image. Summary of the invention

[0006] In view of the above problems, the present invention proposes a resource dynamic orchestration system, which solves the problem of relying on container technologies such as Docker, requiring the introduction of containers such as Docker before use, and the fact that open source solutions are not very suitable for some small-scale or closed network scenarios; as well as the relatively serious defect of Docker image when in use.

[0007] The technical solution adopted by the present invention is as follows: The present invention provides a resource dynamic orchestration system, including: a container unit for sharing multiple resources, wherein the multiple container units are isolated from each other on threads; the container unit includes a thread pool module, a work queue module, an SQL parsing module and a rejection strategy module;

[0008] The thread pool module is used for executing specific business codes;

[0009] The work queue module is used to enable the work threads in the same container unit to execute in an asynchronous manner, thereby improving processing performance;

[0010] The SQL parsing module is used to parse the business SQL in the microservice, connect to the data source through Jdbc and execute SQL;

[0011] The rejection policy module is used to provide an execution strategy when the work queue is full, and has built-in direct rejection, exception throwing and direct execution strategies. The present invention introduces lightweight container technology and abandons container technologies such as Docker. The lightweight container technology is built based on the native JVM process. By allocating startup parameters such as the specified thread pool size to each JVM process, each JVM process has independent resource control, which realizes process-level system resource isolation and solves the problem of resource preemption between services. At the same time, due to the abandonment of container technologies such as Docker, lightweight containers are smaller, lighter, and easier to run than Docker, and there will be no problems such as difficulty in image downloading due to network problems.

[0012] The present invention introduces a lightweight container. Because it is implemented based on the JVM process, the container itself is about 10 MB in size and is very light. At the same time, because there is no other third-party dependency, there is no need to deploy other environments during deployment, which greatly reduces the complexity of operation and maintenance. At the same time, the container provides an easy-to-use startup command, which is also convenient for CI / CD integration.

[0013] The lightweight container of the present invention contains an SQL parser and a worker thread pool to run specific business SQL and provide services. For the container, a service is actually a business SQL that can be executed in any container. Through this mechanism, a suitable container can be allocated to the service for execution according to the operating status of the container, such as CPU utilization, memory utilization, etc., to achieve dynamic orchestration of service resources.

[0014] Optionally, the rejection policy module supports custom extensions.

[0015] Optionally, the resource dynamic orchestration system further includes a registration center component and a control center component, wherein the registration center component is used to pull information from the control center component, and the control center component is used to send service allocation information and container management information to the registration center component.

[0016] Optionally, the registration center component includes a container unit, an event list unit, a container registration list unit and a remote call unit;

[0017] The event list unit is used to store the life cycle events of container startup, shutdown, and destruction, and these events can be used to manage the container;

[0018] The container registration list unit is used to register its own information with the registration center when the container is started and keep the information dynamically updated through a long connection. The registered container information will be saved in the container registration list inside the registration center;

[0019] The remote call unit is an interface provided by the registration center to the outside world, and is used to provide a container information query and a container event notification interface, and is also used to integrate the functions of the registration center.

[0020] Optionally, the control center component includes a container information table unit, a service information table unit, a container management unit and a service allocation unit;

[0021] The container information table unit is used to store the information of the container unit;

[0022] The service information table unit is used to store the microservice interface in the form of an array, and each piece of data in the array represents a service instance information;

[0023] The container management unit is used to encapsulate some application program interfaces related to container management;

[0024] The service allocation unit is used to allocate all services in the service information table to the corresponding container units for operation. The allocation methods include random allocation, specified allocation, and intelligent allocation.

[0025] Optionally, the service instance information includes service address, input parameters, output parameters, and version number service information. Currently, the existing mainstream technologies related to dynamic resource orchestration still have the technical problem that "although container orchestration technologies such as Kubernetes are fully functional, such as monitoring, they do not provide a unified page for visualization and usually require third-party integration, which to a certain extent makes the entire project messy and the user experience poor."

[0026] The present invention provides a unified visual management interface and encapsulates the API of the container layer, realizing related functions such as container startup, suspension, destruction, expansion, and monitoring, so that users can manage more intuitively.

[0027] The present invention also discloses a resource dynamic arrangement method, including a container unit isolation method, wherein the container unit isolation method comprises the following steps:

[0028] Determine whether the work queue is full;

[0029] If yes, then run the rejection strategy module;

[0030] If not, it will be handed over to the work queue and monopolize the work queue for processing, and further check whether there are idle resources in the thread pool; if there are idle resources, the thread pool module will be monopolized and the business logic will be executed; if there are no idle resources, it will further check whether there are idle resources in the thread pool and wait in a loop.

[0031] The invention also discloses an application of a resource dynamic orchestration system in a microservice architecture.

[0032] (III) Beneficial effects

[0033] 1. The present invention provides a lightweight container that does not rely on other third-party technical frameworks and does not require the preparation of other basic environments, which greatly improves the speed of early environment construction. At the same time, due to less dependence on third parties, it also reduces the complexity of operation and maintenance and reduces the company's operation and maintenance costs.

[0034] 2. The present invention provides a dynamic resource orchestration mechanism, which makes online services, whether they are released or operated and maintained, intelligent. If combined with automated operation and maintenance tools such as Jenkins, operation and maintenance automation can also be achieved, which greatly reduces the pressure of operation and maintenance. At the same time, it also makes the system more scalable and sufficient to cope with sudden traffic surges and other situations.

[0035] 3. The present invention provides a complete and unified visual management platform. By using the API interface provided by the registration center, control center and container, a set of visual management platforms with complete functions and unified style are integrated, which greatly reduces the management cost of users. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 is a schematic diagram of the logical structure of the resource dynamic arrangement system of embodiment 1 of the present invention;

[0037] Figure 2 It is a structural diagram of a lightweight container of a resource dynamic orchestration system in Example 1 of the present invention;

[0038] Figure 3 This is a logical structure diagram of a container engine of a resource dynamic orchestration system according to Embodiment 1 of the present invention;

[0039] Figure 4 It is a logical structure diagram of the container unit isolation method of the resource dynamic orchestration system in Example 2 of the present invention. DETAILED DESCRIPTION

[0040] The present invention is described in detail below in conjunction with the accompanying drawings.

[0041] In the present invention, SQL is the abbreviation of structured query language, Jdbc is the abbreviation of Java database connection, and API is the abbreviation of application program interface.

[0042] Example 1

[0043] The technical solution adopted by the present invention is as follows:

[0044] As attached Figure 1As shown, a resource dynamic orchestration system includes: the resource dynamic orchestration system includes a resource coordinator, the resource coordinator also includes a registration center component and a control center component, the registration center component is used to pull information from the control center component, and the control center component is used to send service allocation information and container management information to the registration center component. The resource dynamic orchestration technology mainly realizes the control and management of lightweight containers and microservices in containers, and all related work is uniformly controlled and managed by the resource coordinator.

[0045] The registration center component includes a container unit, an event list unit, a container registration list unit and a remote call unit; the event list unit is used to save the container startup, shutdown, and destruction life cycle events, and these events can be used to better manage the container; the container registration list unit is used to register its own information with the registration center when the container is started and keep the information dynamically updated through a long connection, and the registered container information will be saved in the container registration list inside the registration center; the remote call unit is used as an interface provided by the registration center to the outside world, which is used to provide container information query and container event notification interfaces, and is also used to better integrate the functions of the registration center.

[0046] It should be noted that when the container is started, it will register its own information with the registration center and keep the information dynamically updated through a long connection. The registered container information will be saved in the container registration list inside the registration center; the event list mainly saves life cycle events such as container startup, shutdown, and destruction, and these events can be used to better manage the container; the remote call unit is the interface provided by the registration center to the outside world, which provides interfaces such as container information query and container event notification, for better integration of the functions of the registration center.

[0047] The control center component includes a container information table unit, a service information table unit, a container management unit and a service allocation unit; the container information table unit is used to store the information of the container unit; the service information table unit is used to save the microservice interface and save it in the form of an array, and each data in the array represents a service instance information; the container management unit is used to encapsulate some application program interfaces related to container management; the service allocation unit is used to allocate all services in the service information table to the corresponding container units for operation, and the allocation method has built-in random allocation, specified allocation and intelligent allocation.

[0048] It should be noted that the control center periodically pulls container information to the local through the remote call interface provided by the registration center, and saves it to the container information table. Through the container information table, the control center can monitor the running status of the container in real time to facilitate further management of the container; the service information table saves the microservice interface and saves it in the form of an array. Each data in the array represents a service instance information, including service address, input parameters, output parameters, version number and other service information. This part of data is mainly obtained from the microservice registration center, such as nacos, eureka, consul, etc.; the container management module mainly encapsulates some application programming interfaces (APIs) related to container management, including container startup, suspension, destruction, and expansion. The application programming interfaces (APIs) of the above functions provide services to the outside world through Http, and third-party applications can integrate the management functions of the container through the above application programming interfaces (APIs).

[0049] The random allocation method randomly allocates the service to one of the running containers. This method is convenient but also rough, and is suitable for scenarios with small service scale and low request pressure. The specified allocation method allocates the service to certain specified containers. Users need to manually select the specified container. The advantage of this method is that it can be accurately allocated to a certain container and is easy to manage. The disadvantage is that it requires manual operation and is suitable for scenarios with strict service operating environment. The intelligent allocation method combines the convenience of random allocation and the advantages of specified allocation. While being convenient, it can make more reasonable use of server resources. This allocation method evaluates all containers from the dimensions of CPU utilization, memory utilization, network IO status, etc., selects the container with the lowest current resource utilization, and allocates the service to the container, thereby improving the overall resource utilization of the container.

[0050] The resource dynamic orchestration system includes multiple container units that share resources with each other, and the multiple container units are isolated from each other on threads; the container unit includes a thread pool module, a work queue module, an SQL parsing module and a rejection strategy module; the thread pool module is used to execute specific business codes; the work queue module is used to enable the work threads in the same container unit to execute in an asynchronous manner to improve processing performance; the SQL parsing module is used to parse the business SQL in the microservice, and connect to the data source through Jdbc and execute SQL; the rejection strategy module is used to provide an execution strategy when the work queue is full, and has built-in direct rejection, exception throwing and direct execution strategies.

[0051] like Figure 2As shown in the figure, lightweight containers are mainly divided into four layers, from bottom to top, they are hardware, dependent system, container operating environment, and container instance. The hardware layer refers to the hardware resources of the physical machine where the container is located; the dependent system refers to the operating system of the host machine where the container is located, which can be Windows, Linux, or MacOS, etc.; the container operating environment refers to the basic environment for container operation. Since lightweight containers are built based on JVM, the operating environment here is the JVM virtual machine; the top layer is the container instance. Each container instance is a process, including a container engine, which is used to execute all microservice business logic in the container. Microservices contain real business logic code, data source information, etc., and their specific execution depends on the container engine.

[0052] like Figure 3 As shown in the figure, the container engine is composed of multiple container units. The container unit includes a thread pool, in which the working threads are responsible for the execution of specific business codes; the work queue enables the working threads in the container unit to execute asynchronously, improving processing performance; the rejection strategy is the strategy that will be executed when the work queue is full, with built-in direct rejection, exception throwing, direct execution and other strategies, and also supports custom extensions; SQL (Structured Query Language) parsing is the core function provided by the container, through which the business SQL in the microservice can be parsed, and the data source can be connected and SQL executed through Jdbc (Java Database Connection). A container engine can contain multiple container units, and the container units share resources, but the threads are isolated. This design idea can maximize the use of system resources. At the same time, the thread isolation technology is used to reduce the mutual influence between microservices and make the service more stable.

[0053] Example 2

[0054] As attached Figure 4 As shown, the present invention also discloses a resource dynamic arrangement method, including a container unit isolation method, wherein the container unit isolation method comprises the following steps:

[0055] Determine whether the work queue is full;

[0056] If yes, then run the rejection strategy module;

[0057] If not, it will be handed over to the work queue and monopolize the work queue for processing, and further check whether there are idle resources in the thread pool; if there are idle resources, the thread pool module will be monopolized and the business logic will be executed; if there are no idle resources, it will further check whether there are idle resources in the thread pool and wait in a loop.

[0058] If multiple microservices in the existing technology run in one container, there will be a problem of thread resource competition. When a service request is processed slowly, the service will occupy a large number of threads, resulting in the occupation of processing threads of other services and the inability to provide services. When this embodiment is implemented, the thread resources of the container are managed and controlled through the thread pool isolation technology. Each container unit has an exclusive work queue and thread pool for internal microservices to use. When the work queue or thread pool is used abnormally, there is also a corresponding safety mechanism to handle it. The most important thing is that the resources inside each container unit are independent. When a problem occurs, it will only affect the container unit, not other container units.

[0059] The above description is only a preferred embodiment of the present invention, and does not limit the patent protection scope of the present invention. Any equivalent structural transformation made by using the contents of the present invention and the drawings, directly or indirectly used in other related technical fields, is also included in the protection scope of the present invention.

Claims

1. A resource dynamic scheduling system, characterized in that: include: The lightweight container is divided into four layers, from bottom to top: hardware, dependent system, container operating environment, and container instance. The lightweight container is built based on JVM. Each container instance is a process, including a container engine, which is used to execute all microservice business logic in the container. Microservices contain business logic code and data source information; the container engine is composed of multiple container units. Multiple container unit resources are shared with each other, and multiple container units are isolated from each other on threads; the container unit includes a thread pool module, a work queue module, an SQL parsing module and a rejection strategy module; The thread pool module is used for executing specific business codes; The work queue module is used to enable the work threads in the same container unit to execute in an asynchronous manner, thereby improving processing performance; The SQL parsing module is used to parse the business SQL in the microservice, connect to the data source through Jdbc and execute SQL; The rejection strategy module is used to provide an execution strategy when the work queue is full, and has built-in direct rejection, exception throwing and direct execution strategies; it also includes a registration center component and a control center component, the registration center component is used to pull information from the control center component, and the control center component is used to send service allocation information and container management information to the registration center component; The registration center component includes a container unit, an event list unit, a container registration list unit and a remote call unit; The event list unit is used to store the life cycle events of container startup, shutdown, and destruction, and these events can be used to manage the container; The container registration list unit is used to register its own information with the registration center when the container is started and keep the information dynamically updated through a long connection. The registered container information will be saved in the container registration list inside the registration center; The remote call unit is an interface provided by the registration center to the outside world, and is used to provide a container information query and a container event notification interface, and is also used to integrate the functions of the registration center.

2. The resource dynamic arrangement system according to claim 1, characterized in that: The deny policy module supports custom extensions.

3. The resource dynamic arrangement system according to claim 1, characterized in that: The control center component includes a container information table unit, a service information table unit, a container management unit, and a service allocation unit; The container information table unit is used to store the information of the container unit; The service information table unit is used to store the microservice interface in the form of an array, and each piece of data in the array represents a service instance information; The container management unit is used to encapsulate some application program interfaces related to container management; The service allocation unit is used to allocate all services in the service information table to the corresponding container units for operation. The allocation methods include random allocation, specified allocation, and intelligent allocation.

4. The resource dynamic arrangement system according to claim 3, characterized in that: The service instance information includes the service address, input parameters, output parameters, and version number service information.

5. The resource dynamic arrangement system according to claim 1, characterized in that: The resource dynamic orchestration method of the resource dynamic orchestration system includes a container unit isolation method, and the container unit isolation method includes the following steps: Determine whether the work queue is full; If yes, then run the rejection strategy module; If not, it will be handed over to the work queue and monopolize the work queue for processing, and further check whether there are idle resources in the thread pool; if there are idle resources, the thread pool module will be monopolized and the business logic will be executed; if there are no idle resources, it will further check whether there are idle resources in the thread pool and wait in a loop.

6. A resource dynamic orchestration system is applied in a microservice architecture, characterized in that: The resource dynamic orchestration system is the resource dynamic orchestration system described in any one of claims 1 to 5.

Images