CN107515776B - Method for upgrading service continuously, node to be upgraded and readable storage medium - Google Patents
Method for upgrading service continuously, node to be upgraded and readable storage medium Download PDFInfo
- Publication number
- CN107515776B CN107515776B CN201710588136.2A CN201710588136A CN107515776B CN 107515776 B CN107515776 B CN 107515776B CN 201710588136 A CN201710588136 A CN 201710588136A CN 107515776 B CN107515776 B CN 107515776B
- Authority
- CN
- China
- Prior art keywords
- container
- new version
- version
- group pod
- pod
- 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.)
- Active
Links
Images
Classifications
-
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1469—Backup restoration techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Abstract
The invention discloses a method for continuously upgrading a service, a node to be upgraded and a readable storage medium. The node to be upgraded acquires a first current version container in an operating state, the first current version container is created in a container group Pod, a new version container corresponding to a new version mirror image is created, the new version container is added to the container group Pod, configuration information of the first current version container is acquired from the container group Pod, the configuration information is written into the new version container of the container group Pod, the new version container of the container group Pod is operated, and the first current version container of the container group Pod is deleted. According to the version upgrading mode, because the new version container and the first current version container are packaged in the same Pod, the execution of the service cannot be interrupted in the replacement operation process, the upgrading speed is high, and the technical problem that the service cannot be continuously upgraded at present is solved.
Description
Technical Field
The invention relates to the technical field of containers, in particular to a method for continuously upgrading a service, a node to be upgraded and a readable storage medium.
Background
With the rapid development of the internet, in order to use server resources more reasonably and effectively, most of the markets realize efficient use of machine room resources through a certain server use strategy or resource virtualization, and a container technology belongs to the list, the container technology is used as a server resource sharing mode to realize virtualization of resources, and the running speed and performance of the container technology are superior to those of a virtual machine management program (Hypervisor) in the existing virtualization mode, namely, an intermediate software layer running between a physical server and an operating system.
For container technology, the open source item Docker is a relatively common application mode in the market. Docker is an open-source application container engine, and can realize packaging applications into a portable container, thereby realizing isolation between different applications, but in the scene of upgrading application versions, the existing container platform mostly adopts an automatic operation and maintenance tool to realize copying, issuing configuration files and installation packages, and realizing final version upgrading. However, the upgrading method must interrupt the running current version application to realize the online of the new version application, and the upgrading speed of the upgrading method is not ideal, so that the technical problem that the uninterrupted upgrading of the service cannot be realized well exists.
The above is only for the purpose of assisting understanding of the technical aspects of the present invention, and does not represent an admission that the above is prior art.
Disclosure of Invention
The invention mainly aims to provide a method for upgrading a service without interruption, a node to be upgraded and a readable storage medium, and aims to solve the technical problem that the service can not be upgraded without interruption in the prior art.
In order to achieve the above object, the present invention provides a method for continuously upgrading a service, which comprises the following steps:
a node to be upgraded acquires a first current version container in an operating state, wherein the first current version container is established in a container group Pod;
creating a new version container corresponding to the new version mirror image, and adding the new version container to the container group Pod;
acquiring the configuration information of the first current version container from the container group Pod, and writing the configuration information into the new version container of the container group Pod;
and operating the new version container of the container group Pod and deleting the first current version container of the container group Pod.
Preferably, before the creating of the new version container corresponding to the new version image and the adding of the new version container to the container group Pod, the method further includes:
splitting an application program into application components according to a preset function boundary;
generating a micro-service corresponding to the application component;
obtaining new version mirror images corresponding to the micro-services respectively;
correspondingly, the operating the new version container of the container group Pod specifically includes:
and operating the new version container corresponding to each new version mirror image in the container group Pod.
Preferably, the obtaining of the new version mirror image corresponding to each microservice includes:
responding to a new version mirror image request input by a user, and acquiring a first new version mirror image corresponding to a first micro service, wherein the new version mirror image request is used for upgrading the first micro service;
correspondingly, the operating the new version container corresponding to each new version image in the container group Pod specifically includes:
and operating the first new version container corresponding to the first new version mirror image in the container group Pod.
Preferably, before the creating of the new version container corresponding to the new version image and the adding of the new version container to the container group Pod, the method further includes:
and sending a new version mirror request to a mirror warehouse so that the mirror warehouse sends the new version mirror to the node to be upgraded, and the mirror warehouse stores the new version mirror.
Preferably, after the obtaining the configuration information of the first current version container from the container group Pod, the method further includes:
storing the configuration information of the first current version container into the node to be upgraded;
or the like, or, alternatively,
and storing the configuration information of the first current version container into a preset distributed database.
Preferably, after the new version container of the container group Pod is executed, the method further includes:
when a new version container running the container group Pod fails, acquiring a current version mirror image, and storing the current version mirror image in the node to be upgraded;
creating a second current version container corresponding to the current version mirror image, and adding the second current version container to the container group Pod;
obtaining the stored configuration information of the first current version container from the node to be upgraded or the preset distributed database, and writing the configuration information of the first current version container into a second current version container of the container group Pod;
and operating the second current version container of the container group Pod, and deleting the failed new version container in the container group Pod.
Preferably, after the new version container of the container group Pod is executed and the first current version container of the container group Pod is deleted, the method further includes:
and acquiring the configuration information of the new version container from the new version container of the container group Pod, and storing the configuration information of the new version container to a preset distributed database.
In addition, to achieve the above object, the present invention further provides a node to be upgraded, where the node to be upgraded includes: the system comprises a memory, a processor and a service uninterrupted upgrading program which is stored on the memory and can be operated on the processor, wherein the service uninterrupted upgrading program is configured to realize the steps of the service uninterrupted upgrading method.
In addition, in order to achieve the above object, the present invention further provides a readable storage medium, where a service uninterrupted upgrade program is stored, and the service uninterrupted upgrade program is executed by a processor to implement the steps of the service uninterrupted upgrade method.
In the version upgrading mode, because the new version container and the first current version container are both packaged in the same Pod, the execution of the service is not interrupted in the replacement operation process, the upgrading speed is high, and the technical problem that the service can not be well upgraded uninterruptedly at present is solved.
Drawings
Fig. 1 is a schematic structural diagram of a node to be upgraded in a hardware operating environment according to an embodiment of the present invention;
fig. 2 is a schematic flow chart of a first embodiment of a method for uninterrupted upgrade of services according to the present invention;
fig. 3 is a flowchart illustrating a second embodiment of a method for uninterrupted upgrade of services according to the present invention;
fig. 4 is a flowchart illustrating a third embodiment of a method for uninterrupted upgrade of services according to the present invention;
fig. 5 is a flowchart illustrating a fourth embodiment of a method for uninterrupted upgrade of services according to the present invention.
The implementation, functional features and advantages of the objects of the present invention will be further explained with reference to the accompanying drawings.
Detailed Description
It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
Referring to fig. 1, fig. 1 is a schematic structural diagram of a node to be upgraded in a hardware operating environment according to an embodiment of the present invention.
As shown in fig. 1, the node to be upgraded may include: a processor 1001, such as a CPU, a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. Wherein a communication bus 1002 is used to enable connective communication between these components. The user interface 1003 may comprise a Display screen (Display), and the optional user interface 1003 may also comprise a standard wired interface, a wireless interface. The network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory (e.g., a magnetic disk memory). The memory 1005 may alternatively be a storage device separate from the processor 1001.
The node to be upgraded can be a server or other physical equipment connected with a network, and is used for realizing business calculation, data storage or data exchange and the like, and a plurality of nodes to be upgraded can be built into a cluster to realize efficient use of resources.
Those skilled in the art will appreciate that the architecture shown in FIG. 1 does not constitute a limitation on the node to be upgraded, and may include more or fewer components than shown, or some components in combination, or a different arrangement of components.
As shown in fig. 1, a memory 1005, which is a kind of computer storage medium, may include therein an operating system, a network communication module, a user interface module, and a service uninterrupted upgrade program.
In the node to be upgraded shown in fig. 1, the network interface 1004 is mainly used for connecting to other servers and performing data communication with the other servers; the user interface 1003 is mainly used for connecting a user terminal and performing data communication with the user terminal; the node to be upgraded calls the service uninterrupted upgrade program stored in the memory 1005 through the processor 1001, and executes the following operations:
acquiring a first current version container in a running state, wherein the first current version container is established in a container group Pod;
creating a new version container corresponding to the new version mirror image, and adding the new version container to the container group Pod;
acquiring the configuration information of the first current version container from the container group Pod, and writing the configuration information into the new version container of the container group Pod;
and operating the new version container of the container group Pod and deleting the first current version container of the container group Pod.
Further, the processor 1001 may call the service uninterrupted upgrade program stored in the memory 1005, and further perform the following operations:
splitting an application program into application components according to a preset function boundary;
generating a micro-service corresponding to the application component;
obtaining new version mirror images corresponding to the micro-services respectively;
accordingly, the following operations are also performed:
and operating the new version container corresponding to each new version mirror image in the container group Pod.
Further, the processor 1001 may call the service uninterrupted upgrade program stored in the memory 1005, and further perform the following operations:
responding to a new version mirror image request input by a user, and acquiring a first new version mirror image corresponding to a first micro service, wherein the new version mirror image request is used for upgrading the first micro service;
accordingly, the following operations are also performed:
and operating the first new version container corresponding to the first new version mirror image in the container group Pod.
Further, the processor 1001 may call the service uninterrupted upgrade program stored in the memory 1005, and further perform the following operations:
and sending a new version mirror request to a mirror warehouse so that the mirror warehouse sends the new version mirror to the node to be upgraded, and the mirror warehouse stores the new version mirror.
Further, the processor 1001 may call the service uninterrupted upgrade program stored in the memory 1005, and further perform the following operations:
storing the configuration information of the first current version container into the node to be upgraded;
or the like, or, alternatively,
and storing the configuration information of the first current version container into a preset distributed database.
Further, the processor 1001 may call the service uninterrupted upgrade program stored in the memory 1005, and further perform the following operations:
when a new version container running the container group Pod fails, acquiring a current version mirror image, and storing the current version mirror image in the node to be upgraded;
creating a second current version container corresponding to the current version mirror image, and adding the second current version container to the container group Pod;
obtaining the stored configuration information of the first current version container from the node to be upgraded or the preset distributed database, and writing the configuration information of the first current version container into a second current version container of the container group Pod;
and operating the second current version container of the container group Pod, and deleting the failed new version container in the container group Pod.
Further, the processor 1001 may call the service uninterrupted upgrade program stored in the memory 1005, and further perform the following operations:
and acquiring the configuration information of the new version container from the new version container of the container group Pod, and storing the configuration information of the new version container to a preset distributed database.
Through the scheme, the new version container and the first current version container are packaged in the same Pod, so that the execution of the service cannot be interrupted in the replacement operation process, the upgrading speed is high, and the technical problem that the service cannot be continuously upgraded at present is solved.
Based on the hardware structure, the embodiment of the method for continuously upgrading the service is provided.
Referring to fig. 2, fig. 2 is a flowchart illustrating a first embodiment of a method for uninterrupted upgrade of services according to the present invention.
In a first embodiment, the method for upgrading the service without interruption includes the following steps:
step S10: a node to be upgraded acquires a first current version container in an operating state, wherein the first current version container is established in a container group Pod;
it can be understood that, in a normal operation environment of a service, a first current version container is operated in a node to be upgraded, and the first current version container is pre-created in a container group Pod, and the container can operate an application, and each container is isolated from each other so as to ensure the security of an operation process. The container isolates different processes running on the nodes through a virtualization technology, so that the processes, the processes and a host operating system are isolated from each other and do not influence each other. The mutually isolated processes are called containers, and each container has a set of file system resources and a set of subordinate processes. For the Pod, in a container cluster management system of kubernets, google sources, the Pod creates, schedules and manages the minimum deployment unit for the system, and the common minimum deployment unit is the container. The container group Pod is an arrangement mode of containers, and is suitable for tightly coupled use scenarios, for example, if it can be guaranteed that a group of services are all deployed on a node to be upgraded, the group of services can be arranged in a manner of the container group Pod, and the group of services arranged in this manner can share a network space and a storage volume, that is, the first current version container is arranged in a manner of the container group Pod, so that the first current version container under the container group Pod can more conveniently share and communicate data with other containers under the Pod.
Of course, a plurality of containers may exist under one Pod to share a storage volume space, a network namespace, and the like, so that the plurality of containers under the Pod are more convenient to communicate, and the running first current version container may be created in one container group Pod in advance.
Step S20: creating a new version container corresponding to the new version mirror image, and adding the new version container to the container group Pod;
in a specific implementation, a corresponding container is created through an image, wherein in order to obtain the image, the new version image may be stored locally, or an image request may be made to a server in which the new version image is stored. The mirror image is a uniform view angle of a plurality of read-only layers in the container technology, and the container is a highest layer added for the mirror image, and the highest layer is a readable and writable layer. Therefore, the new version container corresponding to the new version image is created, which can be understood as adding a layer of readable layer on the new version image to adapt to the subsequent actual business processing. Therefore, there is a need to distinguish between a mirror, a container, and a container in a running state, wherein the container in the running state includes the container, an isolated process space, and a process running in the process space. From the actual operation perspective, the new version image can be directly regarded as a file to be used for creating the new version container, that is, the new version container can be understood as a process or an instance of the new version image, and the new version image can include executable files, dependent software, library files, configuration files and the like required by the operation of the new version container. And the new version container is used for replacing the first current version container to process data after the upgrading process is completed.
It will be appreciated that when a new version container corresponding to a new version image is created, the new version container may also be added to the container group Pod, such that the new version container runs in the same Pod as the first current version container. The Pod is understood to be a container group consisting of several containers, and the several containers are closely related to each other, when several containers are in the same Pod, data and communication can be more conveniently shared among the several containers, and the same network command space and network address can be used among the several containers. Therefore, when the new version container and the first current version container are packaged in the same Pod, the new version container and the first current version container can conveniently share data and communication, and the packaging in the same Pod is also a key for realizing uninterrupted upgrade of services.
It will be appreciated that creating containers and running containers may be different commands in the container technology, and also produce different effects. And (3) creating a corresponding new version container according to the new version mirror image, and obtaining the new version container, wherein the new version container is a layer of readable and writable layer added on the new version mirror image in principle, but the new version container does not operate.
It can be understood that when the new version container is run, a run-state container is obtained, and at this time, besides the new version container, there are isolated process spaces and processes running in the process spaces, and therefore, when the new version container is run, the new version container has the capability of executing tasks. Therefore, there is a point in time when the new version container and the old version container will be in a running state at the same time.
Step S30: acquiring the configuration information of the first current version container from the container group Pod, and writing the configuration information into the new version container of the container group Pod;
in a specific implementation, the operation of the container further requires some configuration information, where the configuration information includes at least one of container operation information, container storage information, and a container environment variable, the container operation information refers to an operation state record generated in the operation process of the container, the container storage information refers to a storage location and a storage address of the container, and the configuration information may further include a mount path, a distribution port, process scheduling information, and functional service information of the container. The configuration information already exists in the first current version container, and in order to realize automatic upgrade of the container version and operate the new version container, the new version container is written with the configuration information, and a mode of directly writing the configuration information of the first current version container can be adopted. Moreover, since the first current version container and the new version container are both in the same Pod, the operations of reading and writing configuration information do not affect the first current version container to execute the service.
Step S40: and operating the new version container of the container group Pod and deleting the first current version container of the container group Pod.
In a specific implementation, the new version container in the Pod may be run, and the first current version container in the Pod is deleted, so that the container version is upgraded, and the new version container is used to replace the old version container. However, for a user, in the process of the upgrade, the service will not be interrupted, because the new version container and the first current version container are in the same Pod, and from the use perspective of the user, the minimum usage unit shown to the user is the Pod, and in the process of the user executing the service, the user cannot perceive whether the specifically operating container in the Pod is the new version container or the first current version container, i.e., the old version container, so the service upgrade will not be interrupted, and because there will always exist a container in the operating state in the node to be upgraded, no matter the new version or the current version.
It can be understood that the upgrade mode is fast to execute due to the service characteristics of the container, and the start of the new version container and the deletion of the first current version container are both implemented in seconds, so that the user does not perceive the whole upgrade process.
According to the scheme provided by the embodiment, because the new version container and the first current version container are packaged in the same Pod, the execution of the service cannot be interrupted in the replacement operation process, the upgrading speed is high, and the technical problem that the service cannot be continuously upgraded at present is solved.
Referring to fig. 3, fig. 3 is a flowchart illustrating a second embodiment of the method for uninterrupted upgrade of services according to the present invention, and the second embodiment of the method for uninterrupted upgrade of services according to the present invention is provided based on the embodiment illustrated in fig. 2.
In the second embodiment, before the step S20, the method further includes:
step S201: splitting an application program into application components according to a preset function boundary;
it can be appreciated that in order to more efficiently split applications for agile development and deployment, the application may be split by way of a micro service Architecture (Microservice Architecture) and partitioned into application components that implement a single, distinct function, and the application components collectively function as the original monolithic application. The application program is an integral application program or a business system to be divided, and if the micro-service architecture is not applied to the function division, the application program performs business processing in a single application running mode, namely a common running mode of the current business system. There are various ways for the preset function boundaries, that is, how to better divide the single application program, which is not limited in this embodiment. The preset functional boundary can realize the division of the application components according to a loose coupling high cohesion principle, the service characteristic of the loose coupling high cohesion means that one service independently realizes functions on the basis of reducing dependence on other services as much as possible, and after the division is realized according to the loose coupling and high cohesion principles, the complexity of interaction between modules can be reduced. Moreover, when the actual function is divided, the division can be performed simply for the business function or for the hierarchical architecture.
It should be understood that the split application components represent part of the functionality in the application.
Step S202: generating a micro-service corresponding to the application component;
in a specific implementation, step S201 is to divide the components according to the division architecture, but when the components are implemented in a specific application scenario, specific codes are also needed to implement the functions, so that the application program can be split according to the preset function boundaries, and each function is converted into a code conforming to the micro-service architecture, that is, the micro-service corresponding to the application component is generated.
Step S203: obtaining new version mirror images corresponding to the micro-services respectively;
of course, to accommodate container technology and create containers, the micro-services corresponding to the application components may be generated as a mirror image for execution in the container environment. In other words, by packaging the microservice code, a mirror image that is convenient to deploy at any time can be generated. Moreover, after the corresponding new version mirror image is generated, the new version mirror image can be stored, so that real-time deployment is facilitated, and repeated generation of server resources is prevented.
The step S40 specifically includes:
step S40': and operating the new version container corresponding to each new version mirror image in the container group Pod, and deleting the first current version container of the container group Pod.
It can be understood that after the new version images corresponding to the microservices are generated, the new version containers corresponding to the new version images are created, the new version containers are added to the container group, and then the configuration information is written into the new version containers. Thus, the new version container corresponding to each new version mirror image in the container group can be operated. In contrast to the first embodiment of the method for updating a service without interruption, in this embodiment, a plurality of new version containers are present to respectively implement corresponding application functions, that is, to divide the new version containers into micro services, whereas the first embodiment does not divide the micro services and only has one new version container to implement one single application program. The method for dividing the application program into the plurality of application components and respectively generating the corresponding new version containers has an obvious advantage that the method for dividing the plurality of components and generating the corresponding containers has the advantage that the deployment speed can be increased without coordinating the influence of other service deployments on the service on a business level when upgrading operation and business execution are carried out, so that continuous deployment becomes possible, and the method is also a great advantage of a micro-service architecture.
According to the scheme provided by the embodiment, on the basis that the new version container and the first current version container are packaged in the same Pod in the first embodiment, service execution is not interrupted in the replacement operation process, and meanwhile, the micro-service architecture is adopted in the embodiment to perform function division on the application program and respectively generate the corresponding new version containers, so that the service execution and redeployment speed can be increased.
Referring to fig. 4, fig. 4 is a flowchart illustrating a third embodiment of the method for uninterrupted upgrade of services according to the present invention, and the third embodiment of the method for uninterrupted upgrade of services according to the present invention is provided based on the embodiment illustrated in fig. 3.
In a third embodiment, the step S203 specifically includes:
step S203': responding to a new version mirror image request input by a user, and acquiring a first new version mirror image corresponding to a first micro service, wherein the new version mirror image request is used for upgrading the first micro service;
it can be understood that, when the architecture manner in the second embodiment is adopted to implement function division on a service, that is, the micro-service architecture is used to implement function-oriented service division, which not only facilitates operation and maintenance personnel, but also makes the response of the whole system faster. Moreover, it is easily conceivable that, when a single application program is split into a plurality of microservices according to a functional boundary to generate new version images respectively corresponding to the microservices, a new version container may be upgraded according to the new version images, unlike the first embodiment in which a new version container is upgraded according to a new version image of a single entity.
In a specific implementation, since the corresponding new version images are generated in the second embodiment, when the service upgrade needs only to upgrade part of the functions, only part of the new version images in the new version images can be acquired to upgrade part of the functions, thereby reducing the operation amount and transmission data of the whole service execution. For example, when an operation and maintenance worker upgrades an application component corresponding to a first micro service, a new version image request is sent, and the new version image request is used for upgrading the first micro service, so that the node to be upgraded can acquire a first new version image corresponding to the first micro service. The first new version mirror image can be stored locally at the node to be upgraded or stored in the mirror image warehouse, and the mirror image is acquired by requesting the first new version mirror image from the mirror image warehouse.
The step S20 specifically includes:
step S20': creating a first new version container corresponding to the first new version mirror image, and adding the first new version container to the container group Pod;
it is understood that, unlike step S20, the first new version container corresponding to the first new version image is created in step S20', and the new version containers corresponding to the new version images are created by obtaining the new version images corresponding to the micro services in step S20, so that the number of created containers is different, and only a part of the containers are selectively created in this embodiment.
The step S30 specifically includes:
step S30': acquiring the configuration information of the first current version container from the container group Pod, and writing the configuration information into a first new version container of the container group Pod;
in a specific implementation, after a first new version container is created, configuration information of an old version is written into the created first new version container.
The step S40' specifically includes:
step S40 ″: and operating a first new version container corresponding to the first new version mirror image in the container group Pod, and deleting a first current version container of the container group Pod.
It can be understood that, after the first new version image is acquired, a first new version container corresponding to the first new version image may be created and added to the Pod to run the first new version container in the Pod. Therefore, local upgrading of container services is realized, the traffic of the whole upgrading process is reduced, meanwhile, the container is deployed through the micro-service architecture, the fault tolerance rate is improved, and the service risk is reduced.
In the scheme provided in this embodiment, in response to a new version image request input by a user, a first new version image corresponding to a first micro service is obtained, where the new version image request is used to upgrade the first micro service, a first new version container corresponding to the first new version image is created, the first new version container is added to the container group Pod, configuration information of the first current version container is obtained from the container group Pod, the configuration information is written into the first new version container of the container group Pod, the first new version container of the container group Pod is operated, and the first current version container of the container group Pod is deleted. The version upgrading method accelerates the speed of service execution and redeployment on the premise of ensuring that the micro-service architecture is adopted to perform function division on the application program and respectively generate corresponding new version containers in the second embodiment, and meanwhile, partial upgrading of corresponding container services is realized for the functions to be upgraded without global upgrading, so that the operating pressure of the server is reduced, and the method is more convenient and quicker.
Referring to fig. 5, fig. 5 is a schematic flow chart of a fourth embodiment of the method for uninterrupted upgrade of services according to the present invention, and the fourth embodiment of the method for uninterrupted upgrade of services according to the present invention is provided based on the embodiment shown in fig. 2.
In the fourth embodiment, before the step S20, the method further includes:
step S20 ″: and sending a new version mirror request to a mirror warehouse so that the mirror warehouse sends the new version mirror to the node to be upgraded, and the mirror warehouse stores the new version mirror.
It can be understood that the mirror image warehouse is a place for storing the mirror image files in a centralized manner, so that the node to be upgraded can conveniently acquire the mirror image, and when the node to be upgraded uses the mirror image, the node to be upgraded sends a new version mirror image request to the mirror image warehouse, so that the mirror image warehouse sends the new version mirror image to the node to be upgraded. By adopting the mirror image warehouse to store the mirror images, the nodes can conveniently and quickly acquire the mirror images to realize the creation of the container, and the storage space for storing the mirror images is also saved.
Before the step S40, the method further includes:
step S40': storing the configuration information of the first current version container into the node to be upgraded;
or the like, or, alternatively,
and storing the configuration information of the first current version container into a preset distributed database.
In a specific implementation, in order to flexibly cope with the creation and operation failure of the new version container, the configuration information of the first current version container may be saved, and when the new version container in the container group Pod fails to operate, the saved configuration information of the current version container may be used to restore the current version container again, that is, the current version container is rolled back to a state before the service upgrade. In addition, the configuration information may be stored in multiple ways, for example, the configuration information of the first current version container may be directly stored locally, or the configuration information may also be stored in a preset distributed database, and both the two storage ways are convenient and fast in invoking the stored configuration information.
Certainly, the preset distributed database may be selected from various databases, the preset distributed database in this embodiment may be an ETCD database, the ETCD is an open-source and highly-available key-value storage system and is mainly used for shared configuration and service discovery, and in this embodiment, the shared configuration characteristic of the ETCD may be applied to implement that other nodes in a cluster including a node to be upgraded may also share the data through the ETCD database, and naturally, the node to be upgraded may also conveniently acquire the configuration information.
After the step S40, the method further includes:
step S401: when a new version container running the container group Pod fails, acquiring a current version mirror image, and storing the current version mirror image in the node to be upgraded;
it can be understood that, in order to prevent the new version container from failing to be trained and executed, the service risk can be avoided by saving the configuration information of the first current version container in advance and setting a backup rollback mechanism. Therefore, when a new version container running the container group Pod fails, the current version mirror image is acquired to regenerate the corresponding current version container, and the business process is restored to the state before upgrading. The current version mirror image can be stored in the node to be upgraded, and of course, the current version mirror image can also be stored in the mirror image warehouse as the new version mirror image, and is convenient to pull for creating the corresponding container when needed.
Step S402: creating a second current version container corresponding to the current version mirror image, and adding the second current version container to the container group Pod;
in a specific implementation, in order to restore the service state to the state before the upgrade, the current version container is created again, that is, the second current version container is created, and then the second version container is also added to the Pod, because the first current version container is also originally in the Pod.
Step S403: obtaining the stored configuration information of the first current version container from the node to be upgraded or the preset distributed database, and writing the configuration information of the first current version container into a second current version container of the container group Pod;
it should be understood that after the created second current version container is obtained, the second current version container is different from the first current version container in a running state because the second current version container is not started and has no configuration information. The configuration information previously saved in the node to be upgraded or the ETCD database may be written to the second current version container.
Step S404: and operating the second current version container of the container group Pod, and deleting the failed new version container in the container group Pod.
It can be understood that the second current version container of the container group Pod may be run, and at this time, the second current version container in the running state is consistent with the first current version container in the running state, so that the state of returning to the state before the upgrade is failed is realized. In order to reduce the operation amount of the service and prevent the running of the node to be upgraded from stopping, the failed new version container can be deleted.
It is to be understood that the description of steps S401 to S404 as occurring after step S40 is merely for convenience of understanding, and steps S401 to S404 are a backup rollback mechanism for timely disaster relief of the operating environment when the new version container fails, and the occurrence time for triggering the backup rollback mechanism is not limited in this embodiment. Moreover, the backup rollback mechanism is arranged, so that the availability and the fault tolerance of the upgrading mode can be improved, and the risk of the downtime of the nodes is reduced.
Further, in order to facilitate next version upgrade, after the new version container of the container group Pod is operated and the first current version container of the container group Pod is deleted, the method further includes obtaining configuration information of the new version container from the new version container of the container group Pod, and storing the configuration information of the new version container in a preset distributed database.
It will be appreciated that the distributed database is used to distributively share configuration, storage configuration and service discovery. Each node in the ETCD database stores complete data, and the data of each node is guaranteed to be consistent all the time through a transmission protocol in the ETCD. In this embodiment, after the first current version container is deleted, the configuration information of the new version container is saved in the ETCD database, so that the new version container is managed and analyzed and restored.
According to the scheme provided by the embodiment, when a new version container operating the container group Pod fails, the second current version container in the operating state is generated through the current version mirror image and the configuration information of the first current version container which is stored in advance, and the second current version container in the operating state is consistent with the first current version container which is in the operating state before upgrading, so that the operating state is returned to the state before upgrading when the operating failure occurs, the disaster recovery level of equipment in the upgrading process is improved, and the fault tolerance rate of the service upgrading process is improved on the premise of ensuring the stability of the service upgrading process.
In addition, an embodiment of the present invention further provides a readable storage medium, where a service uninterrupted upgrade program is stored on the readable storage medium, and when executed by a processor, the service uninterrupted upgrade program implements the following operations:
a node to be upgraded acquires a first current version container in an operating state, wherein the first current version container is established in a container group Pod;
creating a new version container corresponding to the new version mirror image, and adding the new version container to the container group Pod;
acquiring the configuration information of the first current version container from the container group Pod, and writing the configuration information into the new version container of the container group Pod;
and operating the new version container of the container group Pod and deleting the first current version container of the container group Pod.
Further, when executed by the processor, the uninterrupted service upgrade program further implements the following operations:
splitting an application program into application components according to a preset function boundary;
generating a micro-service corresponding to the application component;
obtaining new version mirror images corresponding to the micro-services respectively;
accordingly, the following operations are also implemented:
and operating the new version container corresponding to each new version mirror image in the container group Pod.
Further, when executed by the processor, the uninterrupted service upgrade program further implements the following operations:
responding to a new version mirror image request input by a user, and acquiring a first new version mirror image corresponding to a first micro service, wherein the new version mirror image request is used for upgrading the first micro service;
accordingly, the following operations are also implemented:
and operating the first new version container corresponding to the first new version mirror image in the container group Pod.
Further, when executed by the processor, the uninterrupted service upgrade program further implements the following operations:
and sending a new version mirror request to a mirror warehouse so that the mirror warehouse sends the new version mirror to the node to be upgraded, and the mirror warehouse stores the new version mirror.
Further, when executed by the processor, the uninterrupted service upgrade program further implements the following operations:
storing the configuration information of the first current version container into the node to be upgraded;
or the like, or, alternatively,
and storing the configuration information of the first current version container into a preset distributed database.
Further, when executed by the processor, the uninterrupted service upgrade program further implements the following operations:
when a new version container running the container group Pod fails, acquiring a current version mirror image, and storing the current version mirror image in the node to be upgraded;
creating a second current version container corresponding to the current version mirror image, and adding the second current version container to the container group Pod;
obtaining the stored configuration information of the first current version container from the node to be upgraded or the preset distributed database, and writing the configuration information of the first current version container into a second current version container of the container group Pod;
and operating the second current version container of the container group Pod, and deleting the failed new version container in the container group Pod.
Further, when executed by the processor, the uninterrupted service upgrade program further implements the following operations:
and acquiring the configuration information of the new version container from the new version container of the container group Pod, and storing the configuration information of the new version container to a preset distributed database.
Through the scheme, the new version container and the first current version container are packaged in the same Pod, so that the execution of the service cannot be interrupted in the replacement operation process, the upgrading speed is high, and the technical problem that the service cannot be continuously upgraded at present is solved.
It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or system. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or system that comprises the element.
The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments. The usage of the words first, second, third, etcetera herein does not indicate any ordering. These words may be interpreted as names.
Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which is stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (such as a mobile phone, a computer, a server, an air conditioner, or a network device) to execute the method according to the embodiments of the present invention.
The above description is only a preferred embodiment of the present invention, and not intended to limit the scope of the present invention, and all modifications of equivalent structures and equivalent processes, which are made by using the contents of the present specification and the accompanying drawings, or directly or indirectly applied to other related technical fields, are included in the scope of the present invention.
Claims (9)
1. A method for upgrading a service without interruption, the method comprising the steps of:
a node to be upgraded acquires a first current version container in a running state, wherein the first current version container is established in a container group Pod, and the container group Pod is suitable for a tightly coupled use scene;
creating a new version container corresponding to the new version mirror image, and adding the new version container to the container group Pod;
acquiring the configuration information of the first current version container from the container group Pod, and writing the configuration information into the new version container of the container group Pod;
operating the new version container of the container group Pod and deleting the first current version container of the container group Pod;
wherein, after the configuration information of the first current version container is acquired from the container group Pod, the method further includes:
storing the configuration information of the first current version container into the node to be upgraded;
or the like, or, alternatively,
and storing the configuration information of the first current version container into a preset distributed database.
2. The method of claim 1, wherein before creating a new version container corresponding to a new version image and adding the new version container to the container group Pod, the method further comprises:
splitting an application program into application components according to a preset function boundary;
generating a micro-service corresponding to the application component;
obtaining new version mirror images corresponding to the micro-services respectively;
correspondingly, the operating the new version container of the container group Pod specifically includes:
and operating the new version container corresponding to each new version mirror image in the container group Pod.
3. The method of claim 2, wherein the obtaining of the new version image corresponding to each of the microservices comprises:
responding to a new version mirror image request input by a user, and acquiring a first new version mirror image corresponding to a first micro service, wherein the new version mirror image request is used for upgrading the first micro service;
correspondingly, the operating the new version container corresponding to each new version image in the container group Pod specifically includes:
and operating the first new version container corresponding to the first new version mirror image in the container group Pod.
4. The method of claim 1, wherein before creating a new version container corresponding to a new version image and adding the new version container to the container group Pod, the method further comprises:
and sending a new version mirror request to a mirror warehouse so that the mirror warehouse sends the new version mirror to the node to be upgraded, and the mirror warehouse stores the new version mirror.
5. The method of claim 1, wherein the configuration information comprises at least one of container run information, container store information, and container environment variables.
6. The method of claim 1, wherein after the running the new version container of the container group Pod, the method further comprises:
when a new version container running the container group Pod fails, acquiring a current version mirror image, and storing the current version mirror image in the node to be upgraded;
creating a second current version container corresponding to the current version mirror image, and adding the second current version container to the container group Pod;
obtaining the stored configuration information of the first current version container from the node to be upgraded or the preset distributed database, and writing the configuration information of the first current version container into a second current version container of the container group Pod;
and operating the second current version container of the container group Pod, and deleting the failed new version container in the container group Pod.
7. The method of any of claims 1 through 6, wherein after the running of the new version container of the container group Pod and the deletion of the first current version container of the container group Pod, the method further comprises:
and acquiring the configuration information of the new version container from the new version container of the container group Pod, and storing the configuration information of the new version container to a preset distributed database.
8. A node to be upgraded, comprising: memory, a processor and a non-stop service upgrade program stored on the memory and executable on the processor, the non-stop service upgrade program when executed by the processor implementing the steps of the non-stop service upgrade method according to any one of claims 1 to 7.
9. A readable storage medium, characterized in that the readable storage medium has stored thereon a service uninterrupted upgrade program, which when executed by a processor implements the steps of the service uninterrupted upgrade method according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710588136.2A CN107515776B (en) | 2017-07-18 | 2017-07-18 | Method for upgrading service continuously, node to be upgraded and readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710588136.2A CN107515776B (en) | 2017-07-18 | 2017-07-18 | Method for upgrading service continuously, node to be upgraded and readable storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107515776A CN107515776A (en) | 2017-12-26 |
| CN107515776B true CN107515776B (en) | 2021-04-09 |
Family
ID=60722579
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710588136.2A Active CN107515776B (en) | 2017-07-18 | 2017-07-18 | Method for upgrading service continuously, node to be upgraded and readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107515776B (en) |
Families Citing this family (35)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110119308B (en) * | 2018-02-07 | 2021-06-04 | 北京零研科技有限公司 | System for managing large-scale container applications |
| CN108683516B (en) * | 2018-03-14 | 2021-09-10 | 聚好看科技股份有限公司 | Application instance upgrading method, device and system |
| CN110633096B (en) * | 2018-06-21 | 2023-09-15 | 阿里巴巴集团控股有限公司 | Node control method and device, version control method and device and distributed system |
| CN110716826B (en) * | 2018-07-13 | 2023-11-24 | 阿里巴巴集团控股有限公司 | Cloud disk upgrading and scheduling method, cloud host, scheduling device and system |
| CN109101342B (en) * | 2018-07-20 | 2020-07-10 | 北京百度网讯科技有限公司 | Distributed job coordination control method and device, computer equipment and storage medium |
| CN109165082A (en) * | 2018-08-21 | 2019-01-08 | 赛尔网络有限公司 | System smooth upgrading method based on container |
| CN109150608A (en) * | 2018-08-22 | 2019-01-04 | 苏州思必驰信息科技有限公司 | Interface service upgrade method and system for voice dialogue platform |
| CN109347652A (en) * | 2018-08-31 | 2019-02-15 | 北京奇艺世纪科技有限公司 | The service management and device of server cluster |
| CN109597605A (en) * | 2018-10-22 | 2019-04-09 | 平安科技（深圳）有限公司 | Using micro services dispositions method, device, storage medium and terminal device |
| CN109462657A (en) * | 2018-11-28 | 2019-03-12 | 中国科学院国家天文台 | A kind of expansible long-range observatory's system |
| CN109582441A (en) * | 2018-11-30 | 2019-04-05 | 北京百度网讯科技有限公司 | For providing system, the method and apparatus of container service |
| CN111324361A (en) * | 2018-12-14 | 2020-06-23 | 中国移动通信集团北京有限公司 | Application upgrading method and device |
| CN110286930B (en) * | 2019-06-27 | 2021-08-20 | 腾讯科技（深圳）有限公司 | Cloud platform upgrading method and device, terminal and storage medium |
| CN110569109B (en) * | 2019-09-11 | 2022-05-31 | 广州虎牙科技有限公司 | Container updating method, control node and edge node |
| US20210117859A1 (en) * | 2019-10-20 | 2021-04-22 | Nvidia Corporation | Live updating of machine learning models |
| CN110781001B (en) * | 2019-10-23 | 2023-03-28 | 广东浪潮大数据研究有限公司 | Kubernetes-based container environment variable checking method |
| CN111241540A (en) * | 2020-01-16 | 2020-06-05 | 南京领行科技股份有限公司 | Service processing method and device |
| CN111552494B (en) * | 2020-04-24 | 2021-05-11 | 星环信息科技(上海)股份有限公司 | Method, device, system and medium for managing container group |
| CN111552496B (en) * | 2020-05-07 | 2021-07-20 | 上海道客网络科技有限公司 | System and method for realizing seamless upgrade of sidecar based on temporary container addition |
| CN111522569B (en) * | 2020-05-09 | 2023-08-18 | 中瓴智行(成都)科技有限公司 | Hypervisor-based embedded multi-system upgrading method and computer readable storage medium |
| CN111666088A (en) * | 2020-06-07 | 2020-09-15 | 中信银行股份有限公司 | Pod replacement method and device, electronic equipment and computer-readable storage medium |
| CN111897558A (en) * | 2020-07-23 | 2020-11-06 | 北京三快在线科技有限公司 | Kubernets upgrading method and device for container cluster management system |
| CN111880816A (en) * | 2020-07-24 | 2020-11-03 | 北京浪潮数据技术有限公司 | Kubernetes working load upgrading method, device and equipment |
| CN112199106B (en) * | 2020-10-20 | 2022-08-26 | 新华三信息安全技术有限公司 | Cross-version upgrading method and device and electronic equipment |
| CN112434008A (en) * | 2020-11-18 | 2021-03-02 | 星环信息科技(上海)股份有限公司 | Distributed database upgrading method, device and medium |
| CN112486536A (en) * | 2020-11-30 | 2021-03-12 | 山东浪潮通软信息科技有限公司 | Container-based application program upgrading method, device and medium |
| CN112799777B (en) * | 2020-12-31 | 2024-04-05 | 深圳软通动力信息技术有限公司 | Preheating scheduling method in assembly line |
| CN113132154B (en) * | 2021-03-23 | 2023-01-31 | 北京网聚云联科技有限公司 | eBPF technology-based containerized application smooth upgrading method and system |
| CN113590146B (en) * | 2021-06-04 | 2023-10-27 | 聚好看科技股份有限公司 | Server and container upgrading method |
| CN113672253B (en) * | 2021-07-29 | 2023-11-14 | 华人运通(上海)云计算科技有限公司 | Access method, device, equipment and medium for micro-service system of vehicle |
| CN113626054A (en) * | 2021-08-16 | 2021-11-09 | 聚好看科技股份有限公司 | Business service updating method and device |
| CN113448609B (en) * | 2021-08-30 | 2021-11-19 | 恒生电子股份有限公司 | Container upgrading method, device, equipment and storage medium |
| CN113760461B (en) * | 2021-09-07 | 2023-09-05 | 新华智云科技有限公司 | Version upgrading method and computer readable storage medium |
| CN116931976A (en) * | 2022-04-02 | 2023-10-24 | 中兴通讯股份有限公司 | Micro service management method, electronic device and computer readable storage medium |
| CN116089154A (en) * | 2023-04-10 | 2023-05-09 | 苏州浪潮智能科技有限公司 | Cloud native application fault processing method, system, equipment and computer medium |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104410672A (en) * | 2014-11-12 | 2015-03-11 | 华为技术有限公司 | Method of upgrading network function virtualization application as well as method and device for forwarding business |
| CN106528224A (en) * | 2016-11-03 | 2017-03-22 | 腾讯科技（深圳）有限公司 | Content updating method and system for Docker container, and server |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100471134C (en) * | 2006-10-20 | 2009-03-18 | 华为技术有限公司 | Method, device for upgrading telecommunication equipment and upgrading engine unit |
| US9641964B2 (en) * | 2014-09-03 | 2017-05-02 | CloudLeaf, Inc. | Systems, methods and devices for asset status determination |
| US20160259811A1 (en) * | 2015-03-06 | 2016-09-08 | Superna Business Consulting, Inc. | Method and system for metadata synchronization |
| US9575797B2 (en) * | 2015-03-20 | 2017-02-21 | International Business Machines Corporation | Virtual machine migration between hypervisor virtual machines and containers |
| KR102294568B1 (en) * | 2015-08-19 | 2021-08-26 | 삼성에스디에스 주식회사 | Method and apparatus for security checking of image for container |
| CN105162884A (en) * | 2015-09-25 | 2015-12-16 | 浪潮(北京)电子信息产业有限公司 | Cloud management platform based on micro-service architecture |
| CN105740048B (en) * | 2016-01-26 | 2019-03-08 | 华为技术有限公司 | A kind of mirror image management method, apparatus and system |
| CN106293820B (en) * | 2016-08-02 | 2019-06-14 | 山东大学 | Exploitation test O&M integral system |
| CN106598789B (en) * | 2016-11-30 | 2020-02-21 | 成都华为技术有限公司 | Container service disaster tolerance method and device, production site and disaster recovery site |
| CN106686132A (en) * | 2017-02-06 | 2017-05-17 | 郑州云海信息技术有限公司 | Yunhai system deployment method and system |
-
2017
- 2017-07-18 CN CN201710588136.2A patent/CN107515776B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104410672A (en) * | 2014-11-12 | 2015-03-11 | 华为技术有限公司 | Method of upgrading network function virtualization application as well as method and device for forwarding business |
| CN106528224A (en) * | 2016-11-03 | 2017-03-22 | 腾讯科技（深圳）有限公司 | Content updating method and system for Docker container, and server |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107515776A (en) | 2017-12-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107515776B (en) | Method for upgrading service continuously, node to be upgraded and readable storage medium | |
| CN111966305B (en) | Persistent volume allocation method and device, computer equipment and storage medium | |
| US11226847B2 (en) | Implementing an application manifest in a node-specific manner using an intent-based orchestrator | |
| CN107967159B (en) | Method for configuring file application and server | |
| US20210048995A1 (en) | Conversion and restoration of computer environments to container-based implementations | |
| US8230264B2 (en) | System evaluation apparatus | |
| EP2825973B1 (en) | Network resource deployment for cloud-based services | |
| CN112099918A (en) | Live migration of clusters in containerized environments | |
| JP5298763B2 (en) | Virtual system control program, method and apparatus | |
| CN111338854A (en) | Kubernetes cluster-based method and system for quickly recovering data | |
| SG189385A1 (en) | High availability of machines during patching | |
| WO2012054219A1 (en) | Online database availability during upgrade | |
| KR20110030447A (en) | Synchronizing virtual machine and application life cycles | |
| KR20140025503A (en) | Replaying jobs at a secondary location of a service | |
| CN109240716B (en) | Big data platform version management and rapid iterative deployment method and system | |
| WO2019154202A1 (en) | Security protection method and apparatus | |
| CN103176831A (en) | Virtual machine system and management method thereof | |
| CN107465709B (en) | Distributed mirror image construction task method, device and system | |
| CN111884834A (en) | Zookeeper-based distributed system upgrading method and system and computer equipment | |
| US9092292B2 (en) | Shared application binary storage | |
| CN113296891A (en) | Multi-scene knowledge graph processing method and device based on platform | |
| US20200133709A1 (en) | System and method for content - application split | |
| CN116028163A (en) | Method, device and storage medium for scheduling dynamic link library of container group | |
| US20180341475A1 (en) | Just In Time Deployment with Package Managers | |
| JP5574905B2 (en) | Module distribution system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |