CN112905210B - Server and gray level publishing method - Google Patents
Server and gray level publishing method Download PDFInfo
- Publication number
- CN112905210B CN112905210B CN202110314595.8A CN202110314595A CN112905210B CN 112905210 B CN112905210 B CN 112905210B CN 202110314595 A CN202110314595 A CN 202110314595A CN 112905210 B CN112905210 B CN 112905210B
- Authority
- CN
- China
- Prior art keywords
- micro
- service
- version
- instance
- forwarding rule
- 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
Classifications
-
- 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
-
- 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/10—Protocols in which an application is distributed across nodes in the network
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The embodiment of the application provides a server and a gray level publishing method, wherein the server is configured to: monitoring micro-service update information in the cloud platform cluster; if the micro service update information comprises a version weight proportion, setting a weighted forwarding rule for micro service configuration corresponding to the micro service update information according to the version weight proportion, wherein the weighted forwarding rule is used for determining an instance corresponding to an access request of the micro service. According to the embodiment of the application, the weights are set for the different version examples of the micro service, so that the IPVS can forward the access request of the micro service according to the weights, the number of users accessing the new version of the micro service is not limited by the number of examples, the flexibility and the flow controllability of gray release of the new version of the micro service are improved, and the user experience during updating of the micro service version is improved.
Description
Technical Field
The application relates to the technical field of servers, in particular to a server and a gray level publishing method.
Background
Today, display devices are continuously developed towards intelligentization, functions are more and more, and resources which can be displayed are more and more abundant, which puts higher and higher demands on servers which provide resources for the display devices. In order to improve the data processing capability, a plurality of servers can be deployed into a cluster based on a cloud platform, namely, the cloud platform cluster, and resources deployed on all servers in the cluster are intensively scheduled through a software system, so that high-concurrency access requests can be processed.
Within cloud platform clusters, such as those based on Kubernetes (open source container cluster management system), a large number of micro-services are deployed to implement some specific functionality. Each micro-service may have multiple instances, each deployed on a different server. The cloud platform cluster may be provided with a load balancer that may configure forwarding rules for the micro services such that IPVS (IP Virtual Server, IP virtual service) evenly distributes multiple access requests to the micro services from within the cluster or from outside the cluster to individual instances of the micro services according to the forwarding rules, enabling traffic distribution.
However, after the new version of the micro service is online in the cloud platform cluster, in order to maintain stability of the micro service, the traffic needs to be gradually cut into the new version, that is, gray release needs to be performed, however, according to the load balancing method, whether the traffic is distributed to the old version or the new version depends on the number of the old version and the new version, which puts higher requirements on deployment of the new version and is unfavorable for the promotion of gray release.
Disclosure of Invention
The application provides a server and a gray level release method for solving the technical problem that gray level release is difficult to advance.
In a first aspect, the present application provides a server configured to:
monitoring micro-service update information in the cloud platform cluster;
if the micro service update information comprises a version weight proportion, setting a weighted forwarding rule for micro service configuration corresponding to the micro service update information according to the version weight proportion, wherein the weighted forwarding rule is used for determining an instance corresponding to an access request of the micro service.
In some embodiments, the forwarding rule set according to the version weight proportion to weight the micro service configuration corresponding to the micro service update information includes:
calculating the weight of each instance of the micro service corresponding to the micro service update information according to the version weight proportion and the number of each version instance;
the weighted forwarding rules are configured for the micro-services according to the weight of each instance.
In some embodiments, the computing the weight of each instance of the microservice according to the version weight proportion and the number of each version instance comprises:
obtaining the total weight of each version instance of the micro service according to the version weight proportion;
and obtaining the weight of each instance of the micro service according to the ratio of the total weight of each instance of the micro service to the number of instances of the corresponding version.
In some embodiments, the server is further configured to:
and if the micro service updating information does not comprise the version weight proportion, setting the version weight proportion in the configuration information of the micro service corresponding to the micro service updating information, and configuring a weighted forwarding rule for the micro service according to the micro service updating information and the version weight proportion.
In some embodiments, the server is further configured to:
if the version weight proportion of the micro service update information is cancelled, an unweighted forwarding rule is configured for the micro service corresponding to the micro service update information according to the micro service update information, and the unweighted forwarding rule is used for determining an instance corresponding to the access request of the micro service.
In a second aspect, the present application provides a server configured to:
receiving an access request of an access object as a micro service;
responding to the access request, and acquiring a forwarding rule corresponding to the micro service;
if the forwarding rule is a weighted forwarding rule, forwarding the access request to the instance of the micro service according to a weighted load balancing algorithm;
and if the forwarding rule is an unweighted forwarding rule, forwarding the access request to the micro-service instance according to an unweighted load balancing algorithm.
In a third aspect, the present application provides a gray scale distribution method, including:
monitoring micro-service update information in the cloud platform cluster;
if the micro service update information comprises a version weight proportion, setting a weighted forwarding rule for micro service configuration corresponding to the micro service update information according to the version weight proportion, wherein the weighted forwarding rule is used for determining an instance corresponding to an access request of the micro service.
In some embodiments, the gray scale distribution method further includes:
if the version weight proportion is canceled by the micro service updating information, an unweighted forwarding rule is configured for the micro service corresponding to the micro service updating information according to the micro service updating information, and the unweighted forwarding rule is used for determining an instance corresponding to the access request of the micro service.
The server and the gray level release method provided by the application have the beneficial effects that:
according to the embodiment of the application, the weights are set for the different version examples of the micro service, so that the IPVS can forward the access request of the micro service according to the weights, the number of users accessing the new version of the micro service is not limited by the number of examples, the flexibility and the flow controllability of gray release of the new version of the micro service are improved, and the user experience during updating of the micro service version is improved.
Drawings
In order to more clearly illustrate the technical solution of the present application, the drawings that are needed in the embodiments will be briefly described below, and it will be obvious to those skilled in the art that other drawings can be obtained from these drawings without inventive effort.
A schematic diagram of an operational scenario between a display device and a control apparatus according to some embodiments is schematically shown in fig. 1;
a hardware configuration block diagram of the control apparatus 100 according to some embodiments is exemplarily shown in fig. 2;
a hardware configuration block diagram of a display device 200 according to some embodiments is exemplarily shown in fig. 3;
a schematic diagram of the software configuration in a display device 200 according to some embodiments is exemplarily shown in fig. 4;
an interactive schematic diagram of gray scale distribution according to some embodiments is illustrated in fig. 5;
a forwarding schematic of an access request according to some embodiments is schematically shown in fig. 6;
a forwarding schematic of access requests according to some embodiments is schematically shown in fig. 7.
Detailed Description
For the purposes of making the objects and embodiments of the present application more apparent, an exemplary embodiment of the present application will be described in detail below with reference to the accompanying drawings in which exemplary embodiments of the present application are illustrated, it being apparent that the exemplary embodiments described are only some, but not all, of the embodiments of the present application.
It should be noted that the brief description of the terminology in the present application is for the purpose of facilitating understanding of the embodiments described below only and is not intended to limit the embodiments of the present application. Unless otherwise indicated, these terms should be construed in their ordinary and customary meaning.
The terms first, second, third and the like in the description and in the claims and in the above-described figures are used for distinguishing between similar or similar objects or entities and not necessarily for describing a particular sequential or chronological order, unless otherwise indicated. It is to be understood that the terms so used are interchangeable under appropriate circumstances.
The terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a product or apparatus that comprises a list of elements is not necessarily limited to all elements explicitly listed, but may include other elements not expressly listed or inherent to such product or apparatus.
The term "module" refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware or/and software code that is capable of performing the function associated with that element.
Fig. 1 is a schematic diagram of an operation scenario between a display device and a control apparatus according to an embodiment. As shown in fig. 1, a user may operate the display device 200 through the smart device 300 or the control apparatus 100.
In some embodiments, the control apparatus 100 may be a remote controller, and the communication between the remote controller and the display device includes infrared protocol communication or bluetooth protocol communication, and other short-range communication modes, and the display device 200 is controlled by a wireless or wired mode. The user may control the display device 200 by inputting user instructions through keys on a remote control, voice input, control panel input, etc.
In some embodiments, a smart device 300 (e.g., mobile terminal, tablet, computer, notebook, etc.) may also be used to control the display device 200. For example, the display device 200 is controlled using an application running on a smart device.
In some embodiments, the display device 200 may also perform control in a manner other than the control apparatus 100 and the smart device 300, for example, the voice command control of the user may be directly received through a module configured inside the display device 200 device for acquiring voice commands, or the voice command control of the user may be received through a voice control device configured outside the display device 200 device.
In some embodiments, the display device 200 is also in data communication with a server 400. The display device 200 may be permitted to make communication connections via a Local Area Network (LAN), a Wireless Local Area Network (WLAN), and other networks. The server 400 may provide various contents and interactions to the display device 200. The server 400 may be a cluster, or may be multiple clusters, and may include one or more types of servers.
Fig. 2 exemplarily shows a block diagram of a configuration of the control apparatus 100 in accordance with an exemplary embodiment. As shown in fig. 2, the control device 100 includes a controller 110, a communication interface 130, a user input/output interface 140, a memory, and a power supply. The control apparatus 100 may receive an input operation instruction of a user and convert the operation instruction into an instruction recognizable and responsive to the display device 200, and function as an interaction between the user and the display device 200.
Fig. 3 shows a hardware configuration block diagram of the display device 200 in accordance with an exemplary embodiment.
In some embodiments, display apparatus 200 includes at least one of a modem 210, a communicator 220, a detector 230, an external device interface 240, a controller 250, a display 260, an audio output interface 270, memory, a power supply, a user interface.
In some embodiments the controller includes a processor, a video processor, an audio processor, a graphics processor, RAM, ROM, a first interface for input/output to an nth interface.
In some embodiments, the display 260 includes a display screen component for presenting a picture, and a driving component for driving an image display, for receiving image signals from the controller output, for displaying video content, image content, and a menu manipulation interface, and for manipulating a UI interface by a user.
In some embodiments, the display 260 may be a liquid crystal display, an OLED display, a projection device, and a projection screen.
In some embodiments, communicator 220 is a component for communicating with external devices or servers according to various communication protocol types. For example: the communicator may include at least one of a Wifi module, a bluetooth module, a wired ethernet module, or other network communication protocol chip or a near field communication protocol chip, and an infrared receiver. The display device 200 may establish transmission and reception of control signals and data signals with the external control device 100 or the server 400 through the communicator 220.
In some embodiments, the user interface may be configured to receive control signals from the control device 100 (e.g., an infrared remote control, etc.).
In some embodiments, the detector 230 is used to collect signals of the external environment or interaction with the outside. For example, detector 230 includes a light receiver, a sensor for capturing the intensity of ambient light; alternatively, the detector 230 includes an image collector such as a camera, which may be used to collect external environmental scenes, user attributes, or user interaction gestures, or alternatively, the detector 230 includes a sound collector such as a microphone, or the like, which is used to receive external sounds.
In some embodiments, the external device interface 240 may include, but is not limited to, the following: high Definition Multimedia Interface (HDMI), analog or data high definition component input interface (component), composite video input interface (CVBS), USB input interface (USB), RGB port, or the like. The input/output interface may be a composite input/output interface formed by a plurality of interfaces.
In some embodiments, the modem 210 receives broadcast television signals via wired or wireless reception and demodulates audio-video signals, such as EPG data signals, from a plurality of wireless or wired broadcast television signals.
In some embodiments, the controller 250 and the modem 210 may be located in separate devices, i.e., the modem 210 may also be located in an external device to the main device in which the controller 250 is located, such as an external set-top box or the like.
In some embodiments, the controller 250 controls the operation of the display device and responds to user operations through various software control programs stored on the memory. The controller 250 controls the overall operation of the display apparatus 200. For example: in response to receiving a user command to select a UI object to be displayed on the display 260, the controller 250 may perform an operation related to the object selected by the user command.
In some embodiments, the object may be any one of selectable objects, such as a hyperlink, an icon, or other operable control. The operations related to the selected object are: displaying an operation of connecting to a hyperlink page, a document, an image, or the like, or executing an operation of a program corresponding to the icon.
In some embodiments the controller includes at least one of a central processing unit (Central Processing Unit, CPU), video processor, audio processor, graphics processor (Graphics Processing Unit, GPU), RAM Random Access Memory, RAM), ROM (Read-Only Memory, ROM), first to nth interfaces for input/output, a communication Bus (Bus), and the like.
A CPU processor. For executing operating system and application program instructions stored in the memory, and executing various application programs, data and contents according to various interactive instructions received from the outside, so as to finally display and play various audio and video contents. The CPU processor may include a plurality of processors. Such as one main processor and one or more sub-processors.
In some embodiments, a graphics processor is used to generate various graphical objects, such as: icons, operation menus, user input instruction display graphics, and the like. The graphic processor comprises an arithmetic unit, which is used for receiving various interactive instructions input by a user to operate and displaying various objects according to display attributes; the device also comprises a renderer for rendering various objects obtained based on the arithmetic unit, wherein the rendered objects are used for being displayed on a display.
In some embodiments, the video processor is configured to receive an external video signal, perform video processing such as decompression, decoding, scaling, noise reduction, frame rate conversion, resolution conversion, image composition, etc., according to a standard codec protocol of an input signal, and may obtain a signal that is displayed or played on the directly displayable device 200.
In some embodiments, the video processor includes a demultiplexing module, a video decoding module, an image synthesis module, a frame rate conversion module, a display formatting module, and the like. The demultiplexing module is used for demultiplexing the input audio and video data stream. And the video decoding module is used for processing the demultiplexed video signal, including decoding, scaling and the like. And an image synthesis module, such as an image synthesizer, for performing superposition mixing processing on the graphic generator and the video image after the scaling processing according to the GUI signal input by the user or generated by the graphic generator, so as to generate an image signal for display. And the frame rate conversion module is used for converting the frame rate of the input video. And the display formatting module is used for converting the received frame rate into a video output signal and changing the video output signal to be in accordance with a display format, such as outputting RGB data signals.
In some embodiments, the audio processor is configured to receive an external audio signal, decompress and decode the audio signal according to a standard codec protocol of an input signal, and perform noise reduction, digital-to-analog conversion, and amplification processing to obtain a sound signal that can be played in a speaker.
In some embodiments, a user may input a user command through a Graphical User Interface (GUI) displayed on the display 260, and the user input interface receives the user input command through the Graphical User Interface (GUI). Alternatively, the user may input the user command by inputting a specific sound or gesture, and the user input interface recognizes the sound or gesture through the sensor to receive the user input command.
In some embodiments, a "user interface" is a media interface for interaction and exchange of information between an application or operating system and a user that enables conversion between an internal form of information and a form acceptable to the user. A commonly used presentation form of the user interface is a graphical user interface (Graphic User Interface, GUI), which refers to a user interface related to computer operations that is displayed in a graphical manner. It may be an interface element such as an icon, a window, a control, etc. displayed in a display screen of the electronic device, where the control may include a visual interface element such as an icon, a button, a menu, a tab, a text box, a dialog box, a status bar, a navigation bar, a Widget, etc.
In some embodiments, a system of display devices may include a Kernel (Kernel), a command parser (shell), a file system, and an application program. The kernel, shell, and file system together form the basic operating system architecture that allows users to manage files, run programs, and use the system. After power-up, the kernel is started, the kernel space is activated, hardware is abstracted, hardware parameters are initialized, virtual memory, a scheduler, signal and inter-process communication (IPC) are operated and maintained. After the kernel is started, shell and user application programs are loaded again. The application program is compiled into machine code after being started to form a process.
The system of the display device may include a Kernel (Kernel), a command parser (shell), a file system, and an application program. The kernel, shell, and file system together form the basic operating system architecture that allows users to manage files, run programs, and use the system. After power-up, the kernel is started, the kernel space is activated, hardware is abstracted, hardware parameters are initialized, virtual memory, a scheduler, signal and inter-process communication (IPC) are operated and maintained. After the kernel is started, shell and user application programs are loaded again. The application program is compiled into machine code after being started to form a process.
Referring to FIG. 4, in some embodiments, the system is divided into four layers, from top to bottom, an application layer (referred to as an "application layer"), an application framework layer (Application Framework layer) (referred to as a "framework layer"), a An Zhuoyun row (Android run) and a system library layer (referred to as a "system runtime layer"), and a kernel layer, respectively.
In some embodiments, at least one application program is running in the application program layer, and these application programs may be a Window (Window) program of an operating system, a system setting program, a clock program, or the like; or may be an application developed by a third party developer. In particular implementations, the application packages in the application layer are not limited to the above examples.
The framework layer provides an application programming interface (application programming interface, API) and programming framework for the application. The application framework layer includes a number of predefined functions. The application framework layer corresponds to a processing center that decides to let the applications in the application layer act. Through the API interface, the application program can access the resources in the system and acquire the services of the system in the execution.
As shown in fig. 4, the application framework layer in the embodiment of the present application includes a manager (manager), a Content Provider (Content Provider), and the like, where the manager includes at least one of the following modules: an Activity Manager (Activity Manager) is used to interact with all activities that are running in the system; a Location Manager (Location Manager) is used to provide system services or applications with access to system Location services; a Package Manager (Package Manager) for retrieving various information about an application Package currently installed on the device; a notification manager (Notification Manager) for controlling the display and clearing of notification messages; a Window Manager (Window Manager) is used to manage bracketing icons, windows, toolbars, wallpaper, and desktop components on the user interface.
In some embodiments, the activity manager is used to manage the lifecycle of the individual applications as well as the usual navigation rollback functions, such as controlling the exit, opening, fallback, etc. of the applications. The window manager is used for managing all window programs, such as obtaining the size of the display screen, judging whether a status bar exists or not, locking the screen, intercepting the screen, controlling the change of the display window (for example, reducing the display window to display, dithering display, distorting display, etc.), etc.
In some embodiments, the system runtime layer provides support for the upper layer, the framework layer, and when the framework layer is in use, the android operating system runs the C/C++ libraries contained in the system runtime layer to implement the functions to be implemented by the framework layer.
In some embodiments, the kernel layer is a layer between hardware and software. As shown in fig. 4, the kernel layer contains at least one of the following drivers: audio drive, display drive, bluetooth drive, camera drive, WIFI drive, USB drive, HDMI drive, sensor drive (e.g., fingerprint sensor, temperature sensor, pressure sensor, etc.), and power supply drive, etc.
The hardware or software architecture in some embodiments may be based on the description in the foregoing embodiments, and in some embodiments may be based on other similar hardware or software architectures, so long as the technical solution of the present application may be implemented.
In some embodiments, the servers of the display device may be deployed in a cloud platform cluster environment, where there are a large number of micro services, and the micro services may implement some preset functions, and each micro service may have multiple instances, where the multiple instances are distributed in a container form and run on multiple computing server hosts of the cloud platform. The cloud platform is provided with a load balancer, and can send access requests from the cloud platform cluster to the micro service or access requests from the cloud platform cluster to the micro service to each instance of the micro service in an equalizing manner, and the cloud platform responds to a plurality of access requests through each instance, so that the cloud platform has higher response speed and higher risk resistance compared with the cloud platform responds to a plurality of access requests through a single server.
After a micro service is released on the cloud platform, a developer of the micro service usually maintains and updates an instance of the micro service, namely, upgrades a version of the micro service, so that the micro service can realize a new function or perfect an original function. The user may find some problems when experiencing the new version of the micro service, if the old version of the instance is directly replaced by the new version of the instance, the micro service may be subjected to large-area faults, which is unfavorable for the stability of the micro service, so that in the related art, the new version of the micro service is usually released in a gray level release manner.
In some embodiments, gray scale distribution of micro services proceeds as follows: replacing a small part of old version examples of the micro-service with new version examples; after receiving a plurality of access requests of the micro service, the access requests are uniformly transmitted to an old version instance and a new version instance, so that a small part of users can access the new version of the micro service, and a large part of users access the old version of the micro service; after the small part of users confirm that the new version has no problem, replacing most old version examples of the micro service with new version examples so that most users can access the new version of the micro service; and finally, replacing all old version examples of the micro service with new version examples so that all users can access the new version of the micro service.
In the above-described gray scale release method, whether the user accesses the old version or the new version of the micro service depends on the number of old version instances and the number of new version instances, which puts high demands on the deployment of the instances of the micro service, in practical implementation, it may be difficult for an open person to adjust the number of new version instances and the number of old version instances to appropriate ranges in a short time, which will cause the effect of gray scale release to be difficult to reach the desired level.
In order to solve the technical problems, in some embodiments, a version number may be set for an instance of a micro service, and a forwarding rule is set on a load balancer according to the requirement of gray release, so that the instances of different version numbers have different weights, and after an access request is received, it is determined which instance the access request is forwarded to according to the weight of each version instance, so that the proportion of each version instance does not need to be adjusted to be completely consistent with the proportion of users accessing each version, and convenience of gray release of the micro service is improved.
To achieve the above technical effect, in some embodiments, the interaction process of gray scale distribution may refer to fig. 5, which is an interaction schematic diagram of gray scale distribution according to some embodiments. In fig. 5, the developer is a developer of the micro service, and the server may be one of servers in the cloud platform cluster, where a plurality of functional components of software properties, such as API (Application Programming Interface ) service, kube-proxy, and IPVS, may be disposed on the server. In some embodiments, the API service, kube-proxy, and IPVS may also be provided on different servers within the cloud platform cluster, so long as the interactive functionality shown in fig. 5 is enabled.
The API service can be an application programming interface service arranged on a server, and a developer can create, edit and delete micro-services in the cloud platform cluster through the API service; kube-proxy (load balancer) can monitor micro-service change, and send configuration instruction of forwarding rule to IPVS when micro-service change; the IPVS may configure forwarding rules for access requests of the micro-services according to the configuration instructions.
In some embodiments, the kube-proxy may send a micro-service change reporting instruction to the API service, so that the API service is configured to report all configuration information of the latest micro-service as micro-service update information to the kube-proxy when the micro-service is changed, so that the kube-proxy obtains all configuration information of the latest micro-service according to the micro-service update information, and further controls the forwarding rule of the IPVS update micro-service.
In some embodiments, the API service may be further configured to report the configuration information of the micro service change as micro service update information to the kube-proxy when the micro service changes, so that the kube-proxy obtains the configuration of the micro service change according to the micro service update information, and further controls the forwarding rule of the IPVS update micro service.
In some embodiments, the configuration information of the micro-Service may include a Service object, an Endpoint object, and a Pod object, where the Service object defines basic configuration information related to the micro-Service, the Endpoint object records an instance list of the micro-Service, the Pod object defines configuration information related to the instance, such as version information, and each update of the micro-Service may be only one object, for example, only one Service object may be updated, two objects may be updated, or three objects may be updated.
In some embodiments, the Service object contains information of: micro-service name, micro-service annotation, virtual IP address and port number of micro-service.
In some embodiments, the Endpoints object contains information of: list of instance IP addresses, port numbers of instances, names of instances, protocols of instances, such as TCP.
In some embodiments, the Pod object contains information of: various labels of the instance, version of the instance, instance name.
Of course, the information contained in the Service object, the end objects and the Pod objects is only an example, and actually, various other configuration information may be included, which is not described in detail herein. In some embodiments, when any micro service changes, the API service may report the latest configuration information of the micro service to kube-proxy.
In some embodiments, the micro-service change includes the following: creation of micro services, micro service version changes, instance changes of micro services, version weight changes of micro services, and deletion of micro services, although in practical embodiments, micro service changes may include more cases, such as name changes of micro services.
In some embodiments, a developer may create a micro-service on the cloud platform through the API service and then add an instance for the micro-service. Wherein, before adding an instance, a developer can label the instance with two kinds of labels, one is a label selector label comprising a label selector determination, and the other is a version label. When a developer creates a micro service on the cloud platform, the tag selector may generate a tag selector tag, the function component on the cloud platform may distinguish different micro services according to the tag selector tag of the micro service, and the version tag may include a version number for distinguishing the function component on the cloud platform from different versions of an instance of the micro service, for example, an initial instance version of the micro service may be v1, i.e., version=v1. The label of the instance may be recorded in the Pod object.
In some embodiments, since the micro-Service has only one version when being created, the micro-Service instance also has only one version, a developer can not need to set weights for the micro-Service in a Service object, configure the Service object, an Endpoint object and a Pod object for the micro-Service after creating the instance, implement adding the instance for the micro-Service and configuring the micro-Service, and further complete the creation of the micro-Service, wherein adding the instance for the micro-Service includes specifying parameters such as an instance IP and a port number in the Endpoint object of the micro-Service. After the creation of the micro service is successful, the API service can generate a message of the creation success and configuration information of the micro service, and the user can know that the micro service is created successfully according to the message of the creation success. The configuration information may include the version, IP, and port number of all instances of the micro-service, although the configuration information may also include other information, such as the name of the micro-service determined by the user when creating the micro-service, for example, the configuration information includes: name=sample, then the name of the micro service is indicated as sample. After the micro-service is successfully created, the API service can report the configuration information of the micro-service to the kube-proxy.
In some embodiments, the configuration information that the API service reports to the kube-proxy at a single time includes an updated object of the micro-service, and if the developer updates multiple objects of the micro-service, the micro-service may report the configuration information to the kube-proxy multiple times. According to the uploading method, after the micro-Service is created, the API Service can upload the Service object, the Endpoint object and the Pod object of the micro-Service to the kube-proxy three times. In some embodiments, after receiving the configuration information of the newly established micro service, kube-proxy may obtain the IP addresses and port numbers of all instances of the micro service according to the configuration information of the micro service, and then generate the configuration instruction of the forwarding rule. Because the configuration information of the micro service is not provided with weight information, the configuration instruction of the forwarding rule may include an unweighted load balancing algorithm, a virtual IP of the micro service and a virtual port number thereof, and an IP of an instance of the micro service and a port number thereof, wherein the virtual IP of the micro service and the virtual port number thereof are access entries of the micro service to the outside, and an access request sent by a user to the micro service at a client can carry the virtual IP of the micro service and the virtual port number thereof, so that the cloud platform can identify the micro service which the user wants to access, and the generation of the virtual IP and the virtual port number thereof can be realized based on the prior art, which is not repeated in the application.
In some embodiments, the unweighted load balancing algorithm may be a Round Robin algorithm that may implement a balanced forwarding of access requests to all instances of the micro service according to certain rules, e.g., forwarding of access requests to the next instance of the last access request corresponding instance. Of course, the unweighted load balancing algorithm may be other algorithms, such as LC (Least Connection) algorithm, which may be implemented to preferentially forward access requests to the instance with the Least number of currently established connections.
In some embodiments, kube-proxy sends a configuration instruction of the forwarding rule to the IPVS after generating the configuration instruction of the forwarding rule, where the IPVS configures the forwarding rule of the access request of the micro service according to the load balancing algorithm in the configuration instruction and the instance IP and port number of the micro service.
In some embodiments, after the IPVS configures the above-mentioned unweighted forwarding rule, if an access request of a user is received, the access request may be forwarded to the corresponding instance according to the forwarding rule.
Referring to fig. 6, for an access request forwarding schematic according to some embodiments, as shown in fig. 6, a user may issue an access request to the IPVS through a client, where the access request includes a virtual IP and a virtual port number of the micro service. The IPVS determines the micro-services to be accessed by the user based on the virtual IP and the virtual port number. For example, the micro service to be accessed by the user is the micro service created in fig. 5, the virtual IP of which is 192.0.2.20 and the virtual port number of which is 80. After determining the micro-service that the user is to access, the IPVS may forward the access request to an instance of the micro-service based on forwarding rules for the micro-service. For example, the microservice includes 5 instances, respectively: instance a, version of which is V1, IP of instance 198.51.100.11, port number 80; instance b, version V1, IP 198.51.100.12, port number 80; instance c, version V1, IP 198.51.100.13, port number 80; instance d, version V1, IP 198.51.100.14, port number 80; example e, version V1, IP 198.51.100.15, port number 80. The load balancing algorithm called by the forwarding rule of the micro service is an unweighted polling algorithm, if the access request is the first request received after the creation of the micro service, the access request can be forwarded to an instance a, if the access request is the nth (n is greater than 1) request, the access request can be forwarded to the next instance of the instance corresponding to the last request, for example, the access request is forwarded to an instance a according to the nth-1 request, the nth request is forwarded to an instance b, and so on. An instance of the micro-service may respond to the access request after receiving the access request, e.g., by returning page data for the micro-service to the client, causing the client to draw an interface for the micro-service based on the page data.
In some embodiments, after creating a micro-service, a developer may edit the micro-service, e.g., add an instance of a new version to the micro-service, thereby creating a new version of the micro-service.
In some embodiments, to implement gray level publishing, a new version instance may be added while retaining a portion of the old version instance, such that at the same time, the new version instance and the old version instance run simultaneously, so that some users may access the new version instance and some users may access the old version instance.
For example, the instance of the new version that the developer may set for the micro-service is an instance of version v2, the instance of version v2 including instance a, instance IP 198.51.100.16, port number 80; example b, with IP 198.51.100.17 and port number 80. The instance of the new version is also provided with both the tag selector tag and the version tag. After the new version of the instance is successfully set, the API service can update the configuration information of the micro service, so that the configuration information of the micro service can be increased by the IP of the V2 version instance and the port number thereof on the basis of the original content, wherein the IP of the V2 version instance and the port number thereof can be set in an Endpoints object, and the tag selector tag and the version tag can be set in a Pod object. The API service may report the updated configuration information to kube-proxy, i.e., the Endpoint objects and the Pod objects are reported to kube-proxy in sequence. In some embodiments, after receiving the updated configuration information, kube-proxy increases the new version instance according to the updated configuration information, does not include the version weight proportion, and does not set the version weight proportion before, and may continue to generate a configuration instruction of the forwarding rule based on the previous load balancing algorithm, where the configuration instruction specifies that the load balancing algorithm is a Round Robin (unweighted polling) -based load balancing algorithm, a virtual IP of the micro Service and its virtual port number port, and an IP of the micro Service instance and its port number, where the IP of the micro Service instance and its port number include the IP of the v1 version instance and the IP of the v2 version instance and its port number, and where, since there is no version weight in the Service object when the micro Service is built, kube-proxy may determine that no version weight proportion is received according to the Service object where no new Service object is received.
In some embodiments, kube-proxy sends a configuration instruction of the forwarding rule to the IPVS after generating the configuration instruction of the forwarding rule, and the IPVS reconfigures the forwarding rule of the access request of the micro service according to the configuration instruction.
In some embodiments, after the IPVS reconfigures the above-mentioned unweighted forwarding rule, if an access request of a user is received, the access request may be forwarded to the corresponding instance by adopting an unweighted polling method according to the forwarding rule. For example, after the forwarding rule is configured, if the received access request is a first request, the access request may be forwarded to instance a of version v 1; if the received access request is the nth (n is greater than 1) request, the access request may be forwarded to the next instance of the instance corresponding to the last request, for example, according to the nth-1 request, the instance e of v1 version is forwarded, and the nth request is forwarded to the instance a of v2 version; if the received access request is the n+1th request, the access request may be forwarded to instance b of version v 2; if the received access request is the n+2th request, the access request may be forwarded to instance a of version v1, and so on.
In some embodiments, to control gray level release, the developer may set the version weight ratio for the micro-service after setting the new version instance for the micro-service, and of course, the developer may set the version weight ratio when setting the new version instance.
For example, after the developer sets up an instance of a new version for the micro-Service, the micro-Service may be edited again, adding the version weight ratio to a preset field in the Service object of the micro-Service, or adding the version weight ratio to the micro-Service annotation of the Service object of the micro-Service. For example, in FIG. 5, two example versions of a micro-service are v1 and v2, respectively, and a developer may set the version weight ratio to: weight=v1:v2=50:1, and the version weight ratio indicates that when an access request is received, the access request needs to be distributed to the old version instance and the new version instance according to the ratio of 50:1.
In some embodiments, the API Service may report the updated configuration information of the micro Service to the kube-proxy after the user sets the version weight of the micro Service, e.g., report the updated Service object to the kube-proxy.
In some embodiments, after receiving the microservice update information, kube-proxy may set a forwarding rule for the microservice according to the version weight proportion in the microservice update information, and generate a configuration instruction of the forwarding rule. At this point, the load balancing algorithm of WRR (Weighted Round Robin, weighted polling) and instance weights of micro-services may be included in the forwarding rules. The method for calculating the instance weight proportion of the micro service is as follows: obtaining the total weight of each version instance of the micro service according to the version weight proportion; obtaining the weight of each instance of the micro service according to the ratio of the total weight of the instance of each version of the micro service to the number of instances of the corresponding version, namely, the calculation formula of the instance weight can be: instance weight = total weight of instances for a version/total number of instances for that version.
For example, the micro-service has two versions v1 and v2, the version weight ratio is 50:1, the v1 version has 5 instances, the v2 version has two instances, then each instance weight of the v1 version=v1 total weight/v1 instance number=50/5=10, each instance weight of the v2 version=v2 total weight/v2 instance number=1/2.
In some embodiments, to meet the limitation of the IPVS rule, the calculated weight value may be appropriately adjusted, for example, since the IPVS rule requires that the weight be an integer, and the foregoing instance weights are divided into 20/2 and 1/2, then the instance weights of v1 are 20, the instance weights of v2 are 1, and the weight ratio of the instance instances of v1 to the instance of v2 is 20:1.
In some embodiments, kube-proxy sends a configuration instruction of the forwarding rule to the IPVS after generating the configuration instruction of the forwarding rule, and the IPVS reconfigures the forwarding rule of the access request of the micro service according to the configuration instruction.
In some embodiments, after the weighted forwarding rules are reconfigured by the IPVS, if an access request of a user is received, the access request may be forwarded to a corresponding instance according to the latest forwarding rule.
Referring to fig. 7, for an access request forwarding diagram according to some embodiments, as shown in fig. 7, a user may issue an access request to an IPVS through a client, where the access request includes a virtual IP and a virtual port number of a micro service. The IPVS determines the micro-services to be accessed by the user based on the virtual IP and the virtual port number. For example, the micro service to be accessed by the user is the micro service in fig. 5, the virtual IP of the micro service is 192.0.2.20, and the virtual port number is 80. After determining the micro-service that the user is to access, the IPVS may forward the access request to an instance of the micro-service based on forwarding rules for the micro-service.
Taking fig. 7 as an example, after performing a version update, the microservice includes two versions, where the weight ratio of the versions is 50:1, and the two versions are respectively: example of v1 version: v1a, IP for this example 198.51.100.11, port number 80; v1b, IP for this example 198.51.100.12, port number 80; v1c, IP for this example 198.51.100.13, port number 80; v1d, IP for this example 198.51.100.14, port number 80; v1e, IP for this example 198.51.100.15, port number 80; examples of version V2: v2a, IP for this example 198.51.100.16, port number 80; v2b, IP for this example is 198.51.100.17 and port number 80.
For the micro-service in fig. 7, when the algorithm called by the forwarding rule is a weighted polling load balancing algorithm, an exemplary access request forwarding manner is as follows:
1 st-7 th, each time forwarded to one instance of v1a-v1e, v2a-v2 b;
8 th-102 th, each time forwarded to one instance of v1a-v1 e;
thus, each instance of v1 is accessed 20 times and each instance of v2 is accessed 1 time.
Then, a new round of operation starts,
103-109, each time forwarded to one instance of v1a-v1e, v2a-v2 b;
110 th-204 th, each time forwarded to one instance of v1a-v1 e;
……
according to the forwarding manner, if an access request belongs to the first 7 requests received by the micro-service after version update, the access request can be forwarded to one instance of v1a to v1e and v2a-v2b according to a polling method; if the access request belongs to the 8 th-102 th request received after the micro-service version is updated, the access request can be forwarded to one instance in v1a-v1 e; if the access request belongs to 103-109 times of requests received after the micro-service version is updated, forwarding the access request to one instance of v1a to v1e and v2a-v2b according to a polling method; if the access request belongs to the 110-204 th request received after the microservice version update, the access request may be forwarded to one instance of v1a-v1e, and so on.
In some embodiments, after a new version of the micro-service is online on the cloud platform for a period of time, if the new version has no significant problem, the version weight may be adjusted to enable more users to use the new version of the micro-service. For example, the developer may scale the version weights of the micro-services to: v1:v2=1:1.
In some embodiments, after the developer adjusts the version weight ratio of the micro service through the API service, the API service may update the configuration information of the micro service according to the adjusted version weight ratio, and report the updated configuration information to the kube-proxy.
In some embodiments, after receiving the configuration information updated by the micro service, the kube-proxy may set a forwarding rule for the micro service again according to the version weight proportion in the configuration information, so as to generate a configuration instruction of the forwarding rule. At this point, the forwarding rules may continue with WRR-based load balancing algorithms and instance weight proportion determination for the micro-services. For example, the micro-service has two versions v1 and v2, the version weight ratio is 1:1, the v1 version has 5 instances, the v2 version has two instances, and then the respective instance weights of the v1 version are: v1 total weight/v 1 number of instances = 1/5, v2 version each instance weight is: v2 total weight/v 2 number of instances = 1/2, weight ratio of instance for each version of micro service is: (1/5): (1/2) =2:5.
In some embodiments, kube-proxy sends a configuration instruction of the forwarding rule to the IPVS after generating the configuration instruction of the forwarding rule, and the IPVS reconfigures the forwarding rule of the access request of the micro service according to the configuration instruction.
In some embodiments, after the weighted forwarding rules are reconfigured by the IPVS, if an access request of a user is received, the access request may be forwarded to a corresponding instance according to the latest forwarding rule. Taking the example weight ratio of micro service as 2:5 as an example, if the IPVS receives 100 access requests, 50 access requests are forwarded to the v1 version example, and the other 50 access requests are forwarded to the v2 version example, so that each v1 version example receives 10 access requests, and each v2 version example receives 25 access requests. It can be seen that by setting the version weight, it is not necessary to add an instance of the new version, and more users can access the new version of the micro service. Of course, in addition to modifying the weights, the number of instances of the new version may also be modified to alleviate access pressure of the new version instances.
In some embodiments, after a new version of the micro-service is online on the cloud platform for a further period of time, if the new version has no significant problem, the version weight may be continuously adjusted so that all users can use the new version of the micro-service. For example, the developer may scale the version weight of the micro-service to v1:v2=0:1.
In some embodiments, after the developer adjusts the version weight ratio of the micro service through the API service, the API service may update the configuration information of the micro service according to the adjusted version weight ratio, and report the updated configuration information to the kube-proxy.
In some embodiments, after receiving the configuration information updated by the micro service, the kube-proxy may set a forwarding rule for the micro service again according to the version weight proportion in the configuration information, so as to generate a configuration instruction of the forwarding rule. At this point, the forwarding rules may continue with WRR-based load balancing algorithms and instance weight proportion determination for the micro-services. For example, the micro-service has two versions v1 and v2, the version weight ratio is 0:1, the v1 version has 5 instances, the v2 version has two instances, then the weight of each instance of the v1 version=v1 total weight/v1 instance number=0, the weight of each instance of the v2 version=v2 total weight/v2 instance number=1/2, and the weight ratio of each instance of the micro-service is: (0/5): (1/2) =0:1.
In some embodiments, kube-proxy sends a configuration instruction of the forwarding rule to the IPVS after generating the configuration instruction of the forwarding rule, and the IPVS reconfigures the forwarding rule of the access request of the micro service according to the configuration instruction.
In some embodiments, after the weighted forwarding rules are reconfigured by the IPVS, if an access request of a user is received, the access request may be forwarded to a corresponding instance according to the latest forwarding rule. Taking the example that the weight ratio of the instance of the micro service is 0:1 as an example, if the IPVS receives the access request, the access request poll is forwarded to the instance of the v2 version and not to the instance of the v1 version. Therefore, by setting the version weight, the old version instance does not need to be deleted immediately, and all users can access the new version of the micro-service, so that the deletion time of the old version instance is reserved, and the pressure of micro-service version adjustment is relieved.
In some embodiments, after setting the weight of the old version instance to 0, the developer may delete the old version instance, make the micro-service instances all new version instances, and cancel the weight setting. For example, when the developer deletes the weights in the Service object, "v1:v2=0:1", the latest Service object no longer contains the version weight proportion, and the API Service reports the micro-Service update information containing the Service object to the kube-proxy according to the Service object update. In some embodiments, after receiving the configuration information updated by the micro Service, the kube-proxy deletes the version weight proportion according to the latest Service object, and sets the forwarding rule for the micro Service again to generate a configuration instruction of the forwarding rule. Because the configuration information of the micro service is not provided with weight information, the configuration instruction of the forwarding rule can comprise a load balancing algorithm of unweighted polling, a virtual IP of the micro service and a virtual port number thereof, and an IP of an instance of the micro service and a port number thereof.
In some embodiments, kube-proxy sends a configuration instruction of the forwarding rule to the IPVS after generating the configuration instruction of the forwarding rule, and the IPVS configures the forwarding rule of the access request of the micro service according to the configuration instruction.
In some embodiments, after the IPVS configures the above-mentioned unweighted forwarding rule, if an access request of a user is received, the access request may be forwarded to the corresponding instance according to the forwarding rule. For example, multiple access requests are forwarded separately to different instances of the v2 version of the microservice in an unweighted round robin fashion.
As can be seen from the above embodiments, in the embodiments of the present application, weights are set for different version instances of the micro service, so that the IPVS can forward the access request of the micro service according to the weights, so that the number of users accessing the new version of the micro service is not limited by the number of instances, flexibility and flow controllability of gray release of the new version of the micro service are improved, and user experience during update of the version of the micro service is facilitated.
Since the foregoing embodiments are all described in other modes by reference to the above, the same parts are provided between different embodiments, and the same and similar parts are provided between the embodiments in the present specification. And will not be described in detail herein.
It should be noted that in this specification, relational terms such as "first" and "second" and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a circuit structure, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such circuit structure, article, or apparatus. Without further limitation, the statement "comprises" or "comprising" a … … "does not exclude the presence of other identical elements in a circuit structure, article or apparatus that comprises the element.
Other embodiments of the application will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure of the application herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.
The above embodiments of the present application do not limit the scope of the present application.
Claims (10)
1. A server, wherein the server is configured to:
monitoring micro-service update information in the cloud platform cluster;
if the micro-service update information comprises a version weight proportion, obtaining the total weight of each version instance of the micro-service according to the version weight proportion, obtaining the weight of each instance of the micro-service according to the ratio of the total weight of each version instance of the micro-service to the number of corresponding version instances, and configuring a weighted forwarding rule for the micro-service according to the weight of each instance, wherein the weighted forwarding rule is used for determining the instance corresponding to the access request of the micro-service;
if the version weight proportion is canceled by the micro service updating information, an unweighted forwarding rule is configured for the micro service corresponding to the micro service updating information according to the micro service updating information, and the unweighted forwarding rule is used for determining an instance corresponding to the access request of the micro service.
2. The server of claim 1, wherein the server is further configured to:
and if the micro service updating information does not comprise the version weight proportion, setting the version weight proportion in the configuration information of the micro service corresponding to the micro service updating information, and configuring a weighted forwarding rule for the micro service according to the micro service updating information and the version weight proportion.
3. The server of claim 1, wherein the unweighted forwarding rules comprise: and calculating an instance corresponding to the access request of the micro service through an unweighted polling algorithm.
4. The server of claim 1, wherein the weighted forwarding rules include: and calculating an instance corresponding to the access request of the micro service through a weighted polling algorithm.
5. The server of claim 1, wherein the micro-service update information includes all configuration information of a micro-service update, such that the server updates forwarding rules of the micro-service according to all configuration information of the micro-service update.
6. The server of claim 1, wherein the micro-service update information includes configuration information of a micro-service change, such that the server updates forwarding rules of the micro-service according to the configuration information of the micro-service change.
7. The server of claim 1, wherein the configuration information of the micro-service changes includes an instance list of the micro-service and/or a version weight of the micro-service.
8. A server, wherein the server is configured to:
Receiving an access request of an access object as a micro service;
responding to the access request, and acquiring a forwarding rule corresponding to the micro service, wherein the method for determining the forwarding rule comprises the following steps: monitoring micro-service update information in the cloud platform cluster; if the micro-service update information comprises a version weight proportion, obtaining the total weight of each version instance of the micro-service according to the version weight proportion, obtaining the weight of each instance of the micro-service according to the ratio of the total weight of each version instance of the micro-service to the number of corresponding version instances, and configuring a weighted forwarding rule for the micro-service according to the weight of each instance, wherein the weighted forwarding rule is used for determining the instance corresponding to the access request of the micro-service; if the version weight proportion is canceled by the micro service updating information, configuring an unweighted forwarding rule for the micro service corresponding to the micro service updating information according to the micro service updating information, wherein the unweighted forwarding rule is used for determining an instance corresponding to an access request of the micro service;
if the forwarding rule is a weighted forwarding rule, forwarding the access request to the instance of the micro service according to a weighted load balancing algorithm;
And if the forwarding rule is an unweighted forwarding rule, forwarding the access request to the micro-service instance according to an unweighted load balancing algorithm.
9. A gradation release method, characterized by comprising:
monitoring micro-service update information in the cloud platform cluster;
if the micro-service update information comprises a version weight proportion, obtaining the total weight of each version instance of the micro-service according to the version weight proportion, obtaining the weight of each instance of the micro-service according to the ratio of the total weight of each version instance of the micro-service to the number of corresponding version instances, and configuring a weighted forwarding rule for the micro-service according to the weight of each instance, wherein the weighted forwarding rule is used for determining the instance corresponding to the access request of the micro-service;
if the version weight proportion is canceled by the micro service updating information, an unweighted forwarding rule is configured for the micro service corresponding to the micro service updating information according to the micro service updating information, and the unweighted forwarding rule is used for determining an instance corresponding to the access request of the micro service.
10. The gradation release method according to claim 9, further comprising:
And if the micro service updating information does not comprise the version weight proportion, setting the version weight proportion in the configuration information of the micro service corresponding to the micro service updating information, and configuring a weighted forwarding rule for the micro service according to the micro service updating information and the version weight proportion.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110314595.8A CN112905210B (en) | 2021-03-24 | 2021-03-24 | Server and gray level publishing method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110314595.8A CN112905210B (en) | 2021-03-24 | 2021-03-24 | Server and gray level publishing method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112905210A CN112905210A (en) | 2021-06-04 |
| CN112905210B true CN112905210B (en) | 2023-09-15 |
Family
ID=76106293
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110314595.8A Active CN112905210B (en) | 2021-03-24 | 2021-03-24 | Server and gray level publishing method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112905210B (en) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113676524A (en) * | 2021-08-09 | 2021-11-19 | 浪潮云信息技术股份公司 | Method for realizing multi-CPU architecture container network proxy |
| CN114035823A (en) * | 2021-11-17 | 2022-02-11 | 青岛聚看云科技有限公司 | Business service updating method and device |
| CN114138325A (en) * | 2021-11-24 | 2022-03-04 | 聚好看科技股份有限公司 | Gray scale publishing method and device |
| CN114172808A (en) * | 2021-12-07 | 2022-03-11 | 中国电信股份有限公司 | Kubernetes cluster upgrading method, system, equipment and storage medium |
| CN114726919B (en) * | 2022-03-22 | 2024-02-13 | 新华三大数据技术有限公司 | Gray scale flow control method, device, computer equipment and storage medium |
| US11637749B1 (en) * | 2022-03-31 | 2023-04-25 | Amazon Technologies, Inc. | Metadata synchronization for remote managed systems |
| CN114866598B (en) * | 2022-04-29 | 2023-09-19 | 安徽宝葫芦信息科技集团股份有限公司 | Module dynamic expansion and authorization system based on micro-service architecture and USB interface |
| CN118175209A (en) * | 2023-11-15 | 2024-06-11 | 博泰车联网(南京)有限公司 | Routing method, micro-service system, device and storage medium |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108683516A (en) * | 2018-03-14 | 2018-10-19 | 聚好看科技股份有限公司 | A kind of upgrade method of application example, device and system |
| CN109814910A (en) * | 2018-12-14 | 2019-05-28 | 深圳壹账通智能科技有限公司 | Automate gray scale dissemination method, device, computer system and storage medium |
| CN110266761A (en) * | 2019-05-17 | 2019-09-20 | 平安科技（深圳）有限公司 | Load balancing application creation method, device, computer equipment and storage medium |
| CN110365502A (en) * | 2018-03-26 | 2019-10-22 | 华为技术有限公司 | A kind of method, apparatus and storage medium of service upgrade management |
| CN110661835A (en) * | 2018-06-29 | 2020-01-07 | 马上消费金融股份有限公司 | Gray level publishing method and processing method thereof, node and system and storage device |
| CN110784530A (en) * | 2019-10-22 | 2020-02-11 | 聚好看科技股份有限公司 | Gray scale publishing method and server |
| CN111176713A (en) * | 2019-12-04 | 2020-05-19 | 江苏艾佳家居用品有限公司 | Gray scale publishing and arranging method based on Kubernetes platform and Istio grid technology |
| WO2020181684A1 (en) * | 2019-03-12 | 2020-09-17 | 平安科技（深圳）有限公司 | Grayscale release management method, system and device, and storage medium |
| CN112000348A (en) * | 2020-07-28 | 2020-11-27 | 金蝶医疗软件科技有限公司 | Control method and device for service gray release and computer equipment |
-
2021
- 2021-03-24 CN CN202110314595.8A patent/CN112905210B/en active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108683516A (en) * | 2018-03-14 | 2018-10-19 | 聚好看科技股份有限公司 | A kind of upgrade method of application example, device and system |
| CN110365502A (en) * | 2018-03-26 | 2019-10-22 | 华为技术有限公司 | A kind of method, apparatus and storage medium of service upgrade management |
| CN110661835A (en) * | 2018-06-29 | 2020-01-07 | 马上消费金融股份有限公司 | Gray level publishing method and processing method thereof, node and system and storage device |
| CN109814910A (en) * | 2018-12-14 | 2019-05-28 | 深圳壹账通智能科技有限公司 | Automate gray scale dissemination method, device, computer system and storage medium |
| WO2020181684A1 (en) * | 2019-03-12 | 2020-09-17 | 平安科技（深圳）有限公司 | Grayscale release management method, system and device, and storage medium |
| CN110266761A (en) * | 2019-05-17 | 2019-09-20 | 平安科技（深圳）有限公司 | Load balancing application creation method, device, computer equipment and storage medium |
| CN110784530A (en) * | 2019-10-22 | 2020-02-11 | 聚好看科技股份有限公司 | Gray scale publishing method and server |
| CN111176713A (en) * | 2019-12-04 | 2020-05-19 | 江苏艾佳家居用品有限公司 | Gray scale publishing and arranging method based on Kubernetes platform and Istio grid technology |
| CN112000348A (en) * | 2020-07-28 | 2020-11-27 | 金蝶医疗软件科技有限公司 | Control method and device for service gray release and computer equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112905210A (en) | 2021-06-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112905210B (en) | Server and gray level publishing method | |
| CN114302219B (en) | Display equipment and variable frame rate display method | |
| CN112612443B (en) | Audio playing method, display device and server | |
| CN112672195A (en) | Remote controller key setting method and display equipment | |
| CN113781957B (en) | Method for preventing screen burn of display device and display device | |
| CN113064645A (en) | Startup interface control method and display device | |
| CN112752156A (en) | Subtitle adjusting method and display device | |
| CN113794914B (en) | Display equipment and method for configuring startup navigation | |
| CN112306604B (en) | Progress display method and display device for file transmission | |
| CN113784198B (en) | Display device, intelligent device and program recording control method | |
| CN112911359B (en) | Resource display method, display equipment and remote controller | |
| CN113556609B (en) | Display device and startup picture display method | |
| CN113132809B (en) | Channel switching method, channel program playing method and display equipment | |
| CN112487322B (en) | Third party application Loading page loading method and display device | |
| CN111787115B (en) | Server, display device and file transmission method | |
| CN113971049B (en) | Background service management method and display device | |
| CN114390190B (en) | Display equipment and method for monitoring application to start camera | |
| CN112637683A (en) | Display equipment system optimization method and display equipment | |
| CN113286185A (en) | Display device and homepage display method | |
| CN111787117A (en) | Data transmission method and display device | |
| CN111782606A (en) | Display device, server, and file management method | |
| CN115412751B (en) | Display equipment and visual menu control method | |
| CN113689856B (en) | Voice control method for video playing progress of browser page and display equipment | |
| CN113703706B (en) | Multi-path screen-throwing display method, display equipment and terminal | |
| CN112527330B (en) | Management method and display device |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |