CN117596290A - Container management method and system based on micro-service - Google Patents
Container management method and system based on micro-service Download PDFInfo
- Publication number
- CN117596290A CN117596290A CN202311576790.3A CN202311576790A CN117596290A CN 117596290 A CN117596290 A CN 117596290A CN 202311576790 A CN202311576790 A CN 202311576790A CN 117596290 A CN117596290 A CN 117596290A
- Authority
- CN
- China
- Prior art keywords
- real
- service
- container
- time
- time container
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000007726 management method Methods 0.000 title claims abstract description 127
- 230000005012 migration Effects 0.000 claims abstract description 5
- 238000013508 migration Methods 0.000 claims abstract description 5
- 230000004044 response Effects 0.000 claims description 15
- 238000000034 method Methods 0.000 claims description 14
- 238000012545 processing Methods 0.000 claims description 13
- 238000012544 monitoring process Methods 0.000 claims description 10
- 238000012795 verification Methods 0.000 claims description 7
- 238000004891 communication Methods 0.000 claims description 6
- 238000013500 data storage Methods 0.000 claims description 5
- 238000006243 chemical reaction Methods 0.000 claims description 3
- 238000013507 mapping Methods 0.000 claims description 3
- 238000012958 reprocessing Methods 0.000 claims description 2
- 239000003795 chemical substances by application Substances 0.000 description 15
- 230000006870 function Effects 0.000 description 12
- 239000008186 active pharmaceutical agent Substances 0.000 description 7
- 230000003993 interaction Effects 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 238000012423 maintenance Methods 0.000 description 3
- 238000013475 authorization Methods 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/30—Profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention provides a container management method and system based on micro-services. The invention uses micro-service management as the whole frame of the system, and the upper micro-service management module communicates with the management modules in the clients to finish the management and control of the non-real-time container platform and the real-time container platform, thereby solving the problem of joint scheduling management of the real-time container and the non-real-time container. And meanwhile, the cross-platform distributed service management, the service migration based on threshold control and exception handling and the service scheduling of various scheduling indexes are supported.
Description
Technical Field
The invention relates to the technical field of micro services, in particular to a container management method and system based on micro services.
Background
The micro-service management architecture is a way to develop a single application using a series of smaller granularity services, each running in its own process, with lightweight ways of communicating between services (typically HTTP APIs). These services are deployed independently through an automated deployment mechanism based on business logic and scope, and centralized management of the services should be minimal, i.e., each service may be written in a different programming language, using different data storage techniques.
Real-time container refers to a container technology application in a Linux embedded operating system. Non-real time containers refer to container technology applications in a simple operating system.
Chinese patent CN112579253a provides a method for implementing a management technique of real-time containers and non-real-time containers based on shadow containers. The control of the containers in the different platforms is completed through the interaction of the shadow containers with the containers in the different platforms.
Disclosure of Invention
The purpose of the invention is that: the problem that the non-real-time container and the real-time container cannot be managed at the same time is solved.
The technical scheme of the invention is to provide a container management method based on micro-service, which is used for managing a real-time container and a non-real-time container which are positioned at a working node, and comprises the following steps:
the data gateway in the micro-service management module is positioned at the main control node and acquires a request from the user terminal; the gateway mapping processing module in the data gateway matches the corresponding route according to the target URL in the request and sends the request to the web processing module in the data gateway; the web processing module adopts a filter chain to transmit the request to the real-time container management module and the non-real-time container management module, the real-time container management module and the non-real-time container management module transmit the request to the proxy service of the real-time container or the non-real-time container positioned at the working node, execute the business logic stored in the request and return the response result to the user terminal; after the user terminal receives the response result, the configuration information server side in the configuration management module acquires a configuration file from the user terminal; the configuration information client in the configuration management module pulls a configuration file in the configuration information server and configures the real-time container and the non-real-time container according to the configuration file; after the real-time container and the non-real-time container acquire the configuration files, an access agent module in the real-time container management module and the non-real-time container management module send the micro-service application state information operated by the configuration files to service providers in the real-time container and the non-real-time container; the service provider uploads the micro-service application state information to a service registration center in the real-time container management module and the non-real-time container management module; the real-time container management module and the service consumer in the non-real-time container management module register with the service registration center and acquire an available service list; the service consumer remotely invokes a service in the list of available services.
Preferably, the micro-service-based container management method further comprises a load balancer located in the real-time container and the non-real-time container, and the load balancer is used for selecting to distribute the load of the services in the available service list according to a load balancing algorithm after the available service list is acquired from the service registry.
Preferably, the filter chain is capable of intercepting and modifying requests before they are forwarded to the proxy service, the modified content including parameter verification, rights verification, traffic monitoring, log output, and protocol conversion.
Preferably, the filter chain is capable of intercepting and reprocessing the response results before they are returned to the user terminal, the processing including modifying the response content or response header, log output and traffic monitoring.
Preferably, the available service list includes service information registered to a service registry.
Preferably, the data gateway is used for performing information interaction with the real-time container management module and the non-real-time container management module; the configuration information server is connected with the user terminal and provides an access interface for configuration information, encryption information and decryption information for the configuration information client; the configuration information client acquires and loads configuration information through the configuration information server.
Preferably, the service consumer remotely invokes the service provided by the service provider through HTTP or message middleware (DDS).
Preferably, the working node is responsible for carrying a real-time operating system and a non-real-time operating system, and corresponding container modules are installed in the real-time operating system and the non-real-time operating system to form a real-time container and a non-real-time container, so that the start of micro-service application is realized.
Preferably, the master control node is responsible for a management node of the whole system operation, and is provided with a data gateway, a configuration management module, a service registration center, a real-time container management module and a non-real-time container management module.
The invention also provides a container management system based on the micro-service, which adopts the container management method based on the micro-service and comprises the following steps:
the micro-service management module is provided with a data gateway and is positioned at an upper layer and is used for receiving a user request, and the user request is subjected to data gateway, configuration information management, service discovery and registration, service remote calling and load balancing, so that the scheduling policy management of the application is realized; the real-time container and the non-real-time container are provided with proxy service and are positioned at the bottom layer and are used for container data storage, container automatic service migration and container life cycle management; and the data gateway is used for carrying out information communication with the proxy service, so that the management of the application between the real-time container and the non-real-time container is realized.
The invention uses micro-service management as the whole frame of the system, and the upper micro-service management module communicates with the management modules in the clients to finish the management and control of the non-real-time container platform and the real-time container platform, thereby solving the problem of joint scheduling management of the real-time container and the non-real-time container. And simultaneously supporting cross-platform distributed service management, service migration based on threshold control and exception handling and service scheduling of various scheduling indexes.
Drawings
FIG. 1 is a system software architecture diagram;
FIG. 2 is a micro-service management module;
FIG. 3 is a data gateway workflow;
FIG. 4 is a configuration information workflow;
fig. 5 is a service discovery registration principle;
FIG. 6 is a client load balancing principle;
FIG. 7 is a non-real time container management module;
fig. 8 is a real-time container management module.
Detailed Description
The invention will be further illustrated with reference to specific examples. It is to be understood that these examples are illustrative of the present invention and are not intended to limit the scope of the present invention. Further, it is understood that various changes and modifications may be made by those skilled in the art after reading the teachings of the present invention, and such equivalents are intended to fall within the scope of the claims appended hereto.
The relative terms and concepts presented herein are as follows:
dock: an open source application container engine.
Kubelet: a proxy component on the kubernetes working node runs on each node.
Pod: a set of logically related containers running on a client node.
In this embodiment, as shown in fig. 1, the micro-service based container management system uses a micro-service architecture, and is mainly divided into three functional modules: the system comprises an upper micro-service management module, a lower real-time container management module and a non-real-time container management module.
The micro service management module is mainly responsible for receiving a user request and completing the scheduling policy management of the application through functions such as a data gateway, configuration information management, service discovery and registration, service remote call and load balancing. The real-time container management module and the non-real-time container management module are mainly responsible for functions of container data storage, container automatic service migration, container life cycle management and the like of the working nodes. The system carries out information communication with proxy service in the working node through a data gateway of the micro service management module, so as to realize the management of the application among different containers. The main functional components and the service ends of the micro-service management module, the real-time container management module and the non-real-time container management module are deployed in the main control node, and the functional components of the containers and the service related clients are mainly deployed in the working node.
As shown in fig. 2, the micro service management module mainly includes a data gateway, a service registry, a current limiting and fusing monitor, a configuration management, a service scheduling, a log, a container management interface, and the like.
As shown in fig. 3, the data gateway is a service set up between the user terminal and the micro service, and is mainly responsible for logic for handling some non-business functions, such as authority verification, monitoring, buffering, request routing, and the like. The data gateway is a unique information interaction interface of the micro service management module, the user terminal firstly sends a request to the data gateway, and then the gateway forwards the request to the micro service example according to the identification information of the request. At present, the data gateway is mainly used for solving the problems of maintaining a large number of service addresses, some cross-domain service request problems and micro-service identity authentication problems of clients when the number of services is large.
The data gateway workflow is as follows: the user terminal sends the request to the data gateway. The data gateway searches for a matched route according to the target URL of the request through the gateway mapping processing module and sends the request information to the web processing module. The web processing module forwards the request to the actual working node proxy service by reading the request information sent by the user terminal and using a designated Filter Chain (Filter Chain), and executes business logic to return a response result. The filter may execute business logic before (pre) or after (post) forwarding the request. A Filter (Filter) may intercept and modify requests before they are forwarded to the worker node service agents, the modifications including parameter verification, rights verification, traffic monitoring, log output, and protocol conversion. The filter may intercept and reprocess the response before it is returned to the user terminal, including modifying the response content or response header, log output, traffic monitoring, etc. And the response is returned to the user terminal in the original path.
As shown in fig. 4, for the micro service system, all services are not supported by the configuration file, and the configuration file is generally managed by each service by itself, but problems such as high management difficulty, low security, poor timeliness and the like are caused. To solve these problems, a special configuration management module is required to uniformly manage all the configurations. The configuration file is generated after the data gateway completes communication. The configuration management module mainly comprises 2 parts, namely a configuration information service end and a configuration information client end, wherein the configuration information service end is a distributed configuration center and is used as an independently operated micro-service application for connecting a user terminal and providing an access interface for acquiring configuration information, encryption information and decryption information for the client end, and the configuration information service end is operated at a main control node; the configuration information client is deployed on each micro service in the micro service architecture, acquires and loads configuration information through the server, and operates in the real-time container working node and the non-real-time container working node.
The configuration information workflow is as follows: and the user terminal submits the configuration file to the configuration information server. The configuration information server (distributed configuration center) is responsible for receiving the configuration information sent by the client and exposing an interface for acquiring the configuration to the configuration information client. The configuration information client pulls the configuration in the configuration information server through the interface exposed by the configuration information server and carries out different configurations on the real-time container and the non-real-time container so as to support the operation of the service and the management of the function.
Configuration information management defaults to using Git to store configuration information, thus naturally supporting version management for micro-service configuration. Configuration content can be conveniently managed and accessed through the Git client tool, and in addition, storage of configuration information by using SVN, localized file system and the like is supported. When the configuration information changes, the micro-service can sense the change of the configuration without restarting through the configuration information server, and automatically acquire and apply the latest configuration through the configuration information client. Through configuration information management, a plurality of configuration environments used by the application are allowed to be managed, and the application can be ensured to be completely configured and supported to normally run after being migrated in the real-time container and the non-real-time container environments.
As shown in fig. 5, after the real-time container and the non-real-time container obtain the configuration files, the micro service application state information running in the container through the configuration files is uploaded through the access agent module. The service discovery and registration uses a C/S architecture, running 2 modules in the master control node and the real-time container work node and the non-real-time container work node. The module operated by the main control node is a service registration center and is mainly used for providing a service registration function, and the module maintains an available service list and stores all available service information registered to the main control node. The real-time container working node and the non-real-time container working node are deployed in each micro service application in the micro service system, interact with the main control node through the access proxy module, and send heartbeat information at regular time so that the main control node obtains the application running states of the real-time container and the non-real-time container.
The specific service registration and discovery flow is as follows: and constructing a service registration center module by using the main control node. The data gateway provides basic information that generates a configuration file that provides discoverable basic information for registration discovery. When the service provider (the real-time container and the non-real-time container of the working node) starts the working node, the information of the current node is communicated with the main control node through the access proxy module and is registered to the service registration center in a service name mode. The service consumer (real-time container microservice application and non-real-time container microservice application) registers with the service registry upon startup. The service consumer obtains a list of available services that contains all of the service information (including the service provider and its own information) registered with the service registry. After obtaining the list of available services, the service consumer remotely invokes the services provided by the service provider via HTTP or message middleware (DDS).
As shown in fig. 6, load balancing is to distribute application requests of users equally to a plurality of working nodes for operation, so as to achieve the purposes of expanding bandwidth, enhancing data processing capacity, increasing throughput, and improving availability and flexibility of the network. Common load balancing modes can be divided into server load balancing and client load balancing, wherein the server load balancing needs to be independent, and the client load balancing is mainly used for determining a specific real-time container and a non-real-time container which are connected through a load balancing algorithm by a client (working node), and the client load balancing is used herein, and because management of different working nodes is involved, the establishment of the client load balancing can enable the system to operate more efficiently.
Client load balancing is to encapsulate load balancing logic onto the working nodes in the form of codes, i.e. the load balancer is located at the working nodes. The working node obtains an available service list provided by the main control node through the service registration center. After the service list is provided, the load balancer selects a master control node instance to access through a load balancing algorithm before the working node sends a request, so that the purpose of load balancing is achieved. In addition, the work node load balancing is to maintain the validity of the work node list through a heartbeat mechanism, and the process is needed to be completed together with a service registration center.
The load balancing mode has the following advantages: the load balancer is located at the working node, and a load balancing server does not need to be independently built. Load balancing is performed before the working node sends the request, so that the working node and the master control node are in a point-to-point communication mode. All working nodes have an available service list, and the list is acquired from a service registration center, so that the change and maintenance are convenient. There are various load balancing algorithms, such as polling, random, minimum connection, etc., and the working node can switch its own load balancing algorithm to meet the actual needs.
As shown in fig. 7, the non-real-time container management module mainly includes a main control node and a working node, both of which run a general linux operating system, and the container engine uses a dock. The main control node comprises the functions of interface service, resource scheduling, cluster state maintenance, cluster data storage and the like; the working node comprises a running agent and an access agent function, the former is responsible for specific container life cycle management, and the latter is responsible for specific allocation of requests of a certain service to Pod on the working node.
The main components of the non-real-time container management module are: data backend, interface services, resource controllers, cluster scheduling, proxy services, and access agents.
Etcd: the data back end is a key value database with consistency and high availability and is used for storing the background database of all cluster data.
Interface service: is an external interface of the whole system, and provides a set of API based on RESTful for clients and other components to call. Providing access to all the operations of adding, deleting, modifying, checking and the like, providing mechanisms of authentication, authorization, access control, API registration, discovery and the like, and performing cluster management and resource quota control.
A resource controller: the components of the control manager (the functions performed by the controller mainly include lifecycle functions and API business logic) running on the master node. And an automatic control center of all the resource objects is responsible for maintaining the state of the cluster.
Cluster scheduling: and the method is responsible for carrying out resource scheduling, and the Pod (the Pod of the newly created unspecified operation node) is scheduled to the corresponding node according to the corresponding scheduling policy.
Proxy service: an agent running on each node (node). It ensures that the containers (containers) are all running in Pod. And the system is responsible for the works of creating, starting, monitoring, restarting, destroying and the like of the Pod, and is also responsible for the management of the Volume and the network. kubelet receives data from the master node and assumes specific container lifecycle management.
Access agent: is a network access agent on a node that is responsible for specifically assigning requests to access a service to Pod on a working node.
One typical process of Pod and service association is as follows: the Pod is created by the Pod controller, providing internal and external access by specific services. The Pod controller defines Pod resource objects through YAML files, where Pod objects are tagged to recognize pods. The service may associate Pod resource objects of the same tag type by tags. Pod creation flow: the user initiates an API request to create a Pod through the Rest API. The interface service writes it to etcd. The cluster scheduling detects the Pod of the unbound node, starts scheduling and updating the node binding of the Pod. The proxy service detects that a new Pod is scheduled, and runs the Pod through the docker. The proxy service obtains the Pod state and updates the Pod state into the interface service.
The main control node is a central hub of the cluster, and the main functions include exposing an API interface, tracking and monitoring health states of other servers, and arranging communication with the other servers. In consideration of the problem of single-point faults, clusters are generally formed in a main-standby mode in actual deployment to improve reliability. In the master control node, cluster scheduling is responsible for scheduling resources, and Pod is scheduled to corresponding machines according to a preset scheduling strategy. Factors considered by the scheduling decisions include resource requirements, latency, load balancing, resource limitations, hardware/software/policy constraints, affinity and anti-affinity specifications, data location, interference between workloads, and last time limit, among others, for individual Pod and Pod sets.
The default scheduling flow considers two steps: firstly, a scheduling process is preselected, namely all target nodes are traversed, and all candidate nodes meeting the requirements (various candidate strategies exist) are screened out. And then determining an optimal node, and calculating the integral of each candidate node by adopting a preferred strategy on the basis, wherein the integral winner is found out.
As shown in fig. 8, the real-time container management module also includes a main control node and a working node, the main control node uses a general linux operating system, and the working node uses a VxWorks embedded operating system. The main control node comprises the functions of interface service, resource scheduling, cluster state maintenance and the like; the working node comprises a running agent and an access agent function, the former is responsible for specific container life cycle management, and the latter is responsible for specific allocation of requests of a certain service to Pod on the working node.
The main components of the real-time container management module are as follows: data backend, interface services, resource controllers, cluster scheduling, proxy services, and access agents.
Data backend: the key value database is a background database which has consistency and high availability and is used for storing all cluster data.
Interface service: the system provides an external interface, a set of RESTful-based APIs for clients and other components to call. An operation portal is provided for all resources, including authentication, authorization, access control, service registration and discovery mechanisms, and cluster management and resource quota control.
A resource controller: the control manager component runs on the main control node and is responsible for maintaining the cluster state, and is an automatic control center of the resource object.
Cluster scheduling: the resource scheduling component is operated on the main control node and is responsible for scheduling the Pod to the corresponding working node for operation according to the set scheduling strategy.
Proxy service: the node operation agent component is operated on each working node and is used for guaranteeing the operation of the container in the Pod and is responsible for management work including creation, starting, monitoring, restarting, destroying, data volume, network and the like of the Pod. The system interacts with the main control node through the interface service, receives data from the main control node, and manages the life cycle of the corresponding container.
Access agent: the node network access agent component also takes on load balancing work. It is responsible for specifically assigning requests to access a certain service to Pod on the working node.
Working node: the method is responsible for carrying a real-time operating system and a non-real-time operating system, and installing container modules in the respective operating systems to form a real-time container and a non-real-time container, so as to realize the starting of micro-service application; and the proxy service module realizes the data interaction between the working node and the main control node. And (3) a main control node: and the management node is responsible for the operation of the whole system, is provided with a data gateway module, a configuration management module, a service discovery registration module and a real-time and non-real-time container management module, and completes the centralized management and scheduling of the real-time container and the non-real-time container through the data processing and interaction among the modules.
The embodiment can meet the requirement of double-container management through the micro-service architecture, and simultaneously has the developability and the customizable performance of management services according to the characteristics of the micro-service architecture, such as openness, modularization, loose coupling and the like. The use of real-time containers is more and the use necessity of the real-time operation systems is more and more combined with the public, so that the defect of the current environment can be effectively overcome by the micro-service management system, and the production is guaranteed.
Claims (10)
1. A method of microservice-based container management for managing real-time and non-real-time containers at a working node, the method comprising the steps of:
the data gateway in the micro-service management module is positioned at the main control node and acquires a request from the user terminal;
the gateway mapping processing module in the data gateway matches the corresponding route according to the target URL in the request and sends the request to the web processing module in the data gateway;
the web processing module adopts a filter chain to transmit the request to the real-time container management module and the non-real-time container management module, the real-time container management module and the non-real-time container management module transmit the request to the proxy service of the real-time container or the non-real-time container positioned at the working node, execute the business logic stored in the request and return the response result to the user terminal;
after the user terminal receives the response result, the configuration information server side in the configuration management module acquires a configuration file from the user terminal;
the configuration information client in the configuration management module pulls a configuration file in the configuration information server and configures the real-time container and the non-real-time container according to the configuration file;
after the real-time container and the non-real-time container acquire the configuration files, an access agent module in the real-time container management module and the non-real-time container management module send the micro-service application state information operated by the configuration files to service providers in the real-time container and the non-real-time container;
the service provider uploads the micro-service application state information to a service registration center in the real-time container management module and the non-real-time container management module;
the real-time container management module and the service consumer in the non-real-time container management module register with the service registration center and acquire an available service list;
the service consumer remotely invokes a service in the list of available services.
2. The method of claim 1, further comprising a load balancer in the real-time container and the non-real-time container for selecting a load balancing allocation of services in the list of available services according to a load balancing algorithm after the list of available services is obtained from the service registry.
3. A microservice-based container management method as claimed in claim 1, wherein the filter chain is capable of intercepting and modifying requests before they are forwarded to the proxy service, the modified content including parameter verification, rights verification, traffic monitoring, log output and protocol conversion.
4. A microservice-based container management method as claimed in claim 1, wherein the filter chain is capable of intercepting and reprocessing response results before they are returned to the user terminal, processing including modifying response content or response header, log output and traffic monitoring.
5. The micro-service based container management method of claim 1, wherein the available service list includes service information registered to a service registry.
6. The microservice-based container management method of claim 1 wherein the data gateway is configured to interact with a real-time container management module and a non-real-time container management module; the configuration information server is connected with the user terminal and provides an access interface for configuration information, encryption information and decryption information for the configuration information client; the configuration information client acquires and loads configuration information through the configuration information server.
7. The micro-service based container management method of claim 1, wherein the service consumer remotely invokes the service provided by the service provider through HTTP or message middleware (DDS).
8. The method for managing containers based on micro-services according to claim 1, wherein the working node is responsible for carrying a real-time operating system and a non-real-time operating system, and installing corresponding container modules in the real-time operating system and the non-real-time operating system to form a real-time container and a non-real-time container, so as to realize the start of micro-service application.
9. The method for managing containers based on micro-services according to claim 1, wherein the master control node is responsible for a management node of an overall system operation, and is provided with a data gateway, a configuration management module, a service registration center, a real-time container management module and a non-real-time container management module.
10. A microservice-based container management system, characterized in that a microservice-based container management method according to any of the claims 1-9 is used, comprising:
the micro-service management module is provided with a data gateway and is positioned at an upper layer and is used for receiving a user request, and the user request is subjected to data gateway, configuration information management, service discovery and registration, service remote calling and load balancing, so that the scheduling policy management of the application is realized;
the real-time container and the non-real-time container are provided with proxy service and are positioned at the bottom layer and are used for container data storage, container automatic service migration and container life cycle management;
and the data gateway is used for carrying out information communication with the proxy service, so that the management of the application between the real-time container and the non-real-time container is realized.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311576790.3A CN117596290A (en) | 2023-11-23 | 2023-11-23 | Container management method and system based on micro-service |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311576790.3A CN117596290A (en) | 2023-11-23 | 2023-11-23 | Container management method and system based on micro-service |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117596290A true CN117596290A (en) | 2024-02-23 |
Family
ID=89917801
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311576790.3A Pending CN117596290A (en) | 2023-11-23 | 2023-11-23 | Container management method and system based on micro-service |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117596290A (en) |
-
2023
- 2023-11-23 CN CN202311576790.3A patent/CN117596290A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10719367B1 (en) | Management of workers executing program code functions | |
| US10778798B2 (en) | Remote service access in a container management system | |
| CN108965468B (en) | Block chain network service platform, chain code installation method thereof and storage medium | |
| US11157304B2 (en) | System for peering container clusters running on different container orchestration systems | |
| US10719369B1 (en) | Network interfaces for containers running on a virtual machine instance in a distributed computing environment | |
| CN112532675B (en) | Method, device and medium for establishing network edge computing system | |
| CN112000448A (en) | Micro-service architecture-based application management method | |
| Bauer et al. | IoT reference architecture | |
| CN102868736B (en) | A kind of cloud computing Monitoring framework design basis ground motion method and cloud computing treatment facility | |
| JP2021518018A (en) | Function portability for service hubs with function checkpoints | |
| WO2019020171A1 (en) | Method, system and options for multi-operator service life cycle management | |
| EP2795849B1 (en) | Method and apparatus for messaging in the cloud | |
| Eidenbenz et al. | Latency-aware industrial fog application orchestration with kubernetes | |
| JP2023500669A (en) | Cloud services for cross-cloud operations | |
| CN111506367A (en) | Multi-cluster artificial intelligence online service method and system | |
| US11729026B2 (en) | Customer activation on edge computing environment | |
| CN115086166B (en) | Computing system, container network configuration method, and storage medium | |
| CN111770130B (en) | Method for efficient collaborative multiplexing of software and hardware resources in block chain distributed networking | |
| CN112995273A (en) | Network call-through scheme generation method and device, computer equipment and storage medium | |
| CN110543315B (en) | Distributed operating system of kbroker, storage medium and electronic equipment | |
| CN112559461A (en) | File transmission method and device, storage medium and electronic equipment | |
| CN110661780A (en) | Wireless city data sharing method and system based on SAAS application | |
| CN112532758B (en) | Method, device and medium for establishing network edge computing system | |
| CN115037757B (en) | Multi-cluster service management system | |
| CN117596290A (en) | Container management method and system based on micro-service |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |