WO2019184727A1 - 一种服务升级管理的方法、装置及存储介质 - Google Patents

一种服务升级管理的方法、装置及存储介质 Download PDF

Info

Publication number
WO2019184727A1
WO2019184727A1 PCT/CN2019/078286 CN2019078286W WO2019184727A1 WO 2019184727 A1 WO2019184727 A1 WO 2019184727A1 CN 2019078286 W CN2019078286 W CN 2019078286W WO 2019184727 A1 WO2019184727 A1 WO 2019184727A1
Authority
WO
WIPO (PCT)
Prior art keywords
grayscale
service
version
offloading
state
Prior art date
Application number
PCT/CN2019/078286
Other languages
English (en)
French (fr)
Inventor
尤光瑞
陆学锋
陈飞斐
Original Assignee
华为技术有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP19774314.9A priority Critical patent/EP3758293A4/en
Publication of WO2019184727A1 publication Critical patent/WO2019184727A1/zh
Priority to US17/032,536 priority patent/US20210011834A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/368—Test management for test version control, e.g. updating test cases to a new software version
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities

Definitions

  • the present invention relates to the field of grayscale publishing technologies, and in particular, to a service upgrade management method, a grayscale release control platform, a grayscale offloading device, and a storage medium.
  • Grayscale publishing is a kind of publishing method that can smoothly transition between black and white.
  • AB test is a grayscale publishing method, which allows some users to continue to use A, and some users start to use B. If the user has no objection to B, then gradually expand the scope and move all users to B.
  • the grayscale release can ensure the stability of the overall system, and the problem can be found and adjusted at the initial gray level to ensure its influence.
  • the production environment and the test environment are used in the live network.
  • the front-end traffic distribution device performs the traffic distribution control. After the new version of the system is online, the traffic distribution policy is offloaded to the test environment for trial operation. If the operation is normal, the upgrade is successful. Otherwise, the business message is diverted to the original production environment.
  • the present application provides a method, an apparatus, and a storage medium for service upgrade management, which can solve the problem of requiring an additional deployment system environment and excessive resource occupation in the prior art.
  • the first aspect of the present application provides a service upgrade management method, which is applied to a grayscale release control platform, and the method includes:
  • the grayscale publishing policy, the grayscale offloading rule, and the grayscale offloading state are used by the grayscale offloading device to control the flow of the service message.
  • the grayscale distribution control platform delivers the grayscale publishing policy, the grayscale offloading rule, and the grayscale offloading state to the grayscale offloading device, so that the grayscale offloading device can accurately control the service message.
  • the flow direction can ensure the stability of the telecom software application system. It does not need to deploy another test environment or the backup environment is specially used for stability testing before release. It can realize the grayscale upgrade capability of VNF and ensure smooth switching of service traffic. And non-destructive upgrades, and through trial and error to reduce the risk of upgrades, improve the reliability of the software, and not significantly increase the additional virtual machine resources.
  • the gray-scale offloading state includes: an initial state, an ending state, a whitelisted offloading state, and a proportionally splitting state
  • the grayscale publishing policy may include a whitelisting policy, such as a whitelisted list, a whitelisted list. Strongly related to the service.
  • the whitelist in the whitelist can be the user ID, device ID, device network address, and so on.
  • the gray-scale shunting state may correspond to a behavior logic of the gray-scale shunting device, that is, a shunting manner corresponding to controlling the flow of the service message.
  • the method before the grayscale distribution policy, the grayscale offloading rule, and the grayscale offloading state are sent to the plurality of grayscale offloading devices, the method further includes:
  • the device determines an identifier of the service message sending object, and the version of the second version of the service instance is higher than the service instance of the first version.
  • the method further includes:
  • the split ratio is adjusted, where the split ratio refers to the ratio of the number of service instances of the first version of the offload service message and the number of service instances of the second version of the offload service message.
  • the adjusting the split ratio includes:
  • the method further includes:
  • the service message includes a specific field
  • the method before the sending the service message, the method further includes:
  • the second aspect of the present application provides a method for service upgrade management, which is applied to a grayscale offloading device, and the method includes:
  • the gray-scale shunt state includes an initial state, an end state, a whitelist shunt state, and a proportional shunt state.
  • controlling the flow of service message traffic according to the determined split mode, the grayscale issue policy, the grayscale offload rule, and the grayscale offload state includes one of the following implementation manners:
  • gray-scale offloading state is an initial state
  • traffic of the service message is offloaded according to a polling manner in the service instance of the first version
  • the gray-scale offloading state is an end state
  • the traffic of the service message is offloaded according to a polling manner
  • the gray-scale offloading state is a whitelisted offloading state
  • the service message conforming to the grayscale publishing policy is offloaded to the second version of the service instance, and the grayscale is not met.
  • the service message of the degree release policy is offloaded according to the polling manner in the service instance of the first version;
  • the gray-scale offloading state is a proportionally splitting state
  • the service message that conforms to the grayscale publishing policy is offloaded to the second version of the service instance, and the grayscale is not met.
  • the service message of the degree release policy is offloaded according to the polling manner in the service instance of the first version or the service instance of the second version.
  • the grayscale publishing policy includes a whitelisting policy, and according to the grayscale publishing policy, the service message that meets the grayscale publishing policy is offloaded to the second version of the service instance, including:
  • the method further includes:
  • the split ratio refers to a ratio of the number of service instances of the first version of the offloaded service message and the number of service instances of the second version of the offloaded service message;
  • the grayscale shunt device is integrated in a service instance in the manner of a software development kit SDK.
  • the third aspect of the present application provides a grayscale distribution control platform having a function of implementing a method corresponding to the service upgrade management provided by the above first aspect.
  • the functions may be implemented by hardware or by corresponding software implemented by hardware.
  • the hardware or software includes one or more modules corresponding to the functions described above, which may be software and/or hardware.
  • the grayscale publishing control platform includes:
  • a transceiver module configured to deliver the grayscale publishing policy, the grayscale offloading rule, and the grayscale offloading state to a grayscale offloading device;
  • the grayscale publishing policy, the grayscale offloading rule, and the grayscale offloading state are used by the grayscale offloading device to control the flow of the service message.
  • the gray-scale shunt state includes an initial state, an end state, a whitelist shunt state, and a proportional shunt state.
  • the processing module before the sending and receiving module sends the grayscale publishing policy, the grayscale offloading rule, and the grayscale offloading state to the plurality of grayscale offloading devices, the processing module is further configured to:
  • the device determines an identifier of the service message sending object, and the version of the second version of the service instance is higher than the service instance of the first version.
  • the processing module is further configured to:
  • the split ratio is adjusted, where the split ratio refers to the ratio of the number of service instances of the first version of the offload service message and the number of service instances of the second version of the offload service message.
  • the processing module is configured to:
  • a fourth aspect of the present application provides a grayscale offloading device having a function of implementing a method corresponding to the service upgrade management provided by the second aspect.
  • the functions may be implemented by hardware or by corresponding software implemented by hardware.
  • the hardware or software includes one or more modules corresponding to the functions described above, which may be software and/or hardware.
  • the grayscale offloading device includes:
  • a transceiver module configured to receive a grayscale publishing policy, a grayscale shunting rule, and a grayscale shunting state from a grayscale publishing control platform;
  • a processing module configured to control a flow of the service message according to the grayscale publishing policy, the grayscale offloading rule, and the grayscale offloading state.
  • the gray-scale shunt state includes an initial state, an end state, a whitelist shunt state, and a proportional shunt state.
  • the processing module is configured to perform at least one of the following operations:
  • gray-scale offloading state is an initial state
  • traffic of the service message is offloaded according to a polling manner in the service instance of the first version
  • the gray-scale offloading state is an end state
  • the traffic of the service message is offloaded according to a polling manner
  • the gray-scale offloading state is a whitelisted offloading state
  • the service message conforming to the grayscale publishing policy is offloaded to the second version of the service instance, and the grayscale is not met.
  • the service message of the degree release policy is offloaded according to the polling manner in the service instance of the first version;
  • the gray-scale offloading state is a proportionally splitting state
  • the service message that conforms to the grayscale publishing policy is offloaded to the second version of the service instance, and the grayscale is not met.
  • the service message of the degree release policy is offloaded according to the polling manner in the service instance of the first version or the service instance of the second version.
  • the grayscale publishing policy includes a whitelisting policy
  • the processing module is specifically configured to:
  • the transceiver module is further configured to:
  • the split ratio refers to a ratio of the number of service instances of the first version of the offloaded service message and the number of service instances of the second version of the offloaded service message;
  • Yet another aspect of the present application provides a computer apparatus comprising at least one connected processor, a memory and a transceiver, wherein the memory is for storing program code, and the processor is configured to call program code in the memory
  • the memory is for storing program code
  • the processor is configured to call program code in the memory
  • Yet another aspect of the present application provides a computer storage medium comprising instructions which, when run on a computer, cause the computer to perform the operations described in the first aspect above, or perform the operations described in the second aspect above.
  • Yet another aspect of the present application provides a computer program product comprising instructions which, when run on a computer, cause the computer to perform the operations described in the first aspect above, or perform the operations described in the second aspect above.
  • FIG. 1 is a schematic structural diagram of a telecommunications software application system according to an embodiment of the present application
  • FIG. 2 is a schematic flowchart of a method for service upgrade management in an embodiment of the present application
  • FIG. 3 is a schematic flowchart of a service message according to a gray-scale offloading state according to an embodiment of the present application
  • FIG. 4 is a schematic flowchart of a method for service upgrade management in an embodiment of the present application.
  • FIG. 5 is a schematic structural diagram of a grayscale release control platform according to an embodiment of the present application.
  • FIG. 6 is a schematic structural diagram of a gray-scale power splitting device according to an embodiment of the present application.
  • FIG. 7 is a schematic structural diagram of an apparatus for performing a method for service upgrade management in an embodiment of the present application.
  • modules may be combined or integrated into another system, or some features may be ignored or not executed, and in addition, displayed or discussed between each other
  • the coupling or direct coupling or communication connection may be through some interfaces, and the indirect coupling or communication connection between the modules may be electrical or the like, which is not limited in the present application.
  • the modules or sub-modules described as separate components may or may not be physically separated, may not be physical modules, or may be distributed to multiple circuit modules, and some or all of them may be selected according to actual needs. Modules are used to achieve the objectives of the present application.
  • the present application provides a service upgrade management method, apparatus, and storage medium for use in a grayscale distribution in a telecom software application system, for example, an upgrade operation, a patch operation, a configuration operation, and the like of a telecom software application system. The details are described below.
  • a telecom software application system includes a virtualised network function (VNF), a virtualised network function manager (VNFM), a VNFM-A, and a network function virtualization (Network).
  • VNF virtualised network function
  • VNFM virtualised network function manager
  • VNFM-A virtualised network function manager
  • Network Network function virtualization
  • Function Virtualisation NFV
  • PaaS Platform-as-a-Service
  • VIM Virtual Infrastructure Manager
  • the function of each functional part in the system shown in Fig. 1 will be described below.
  • the VNF is used to deploy business service instances and grayscale publications, such as deploying service instance 1 and service instance 2.
  • PaaS refers to the provision of software development platforms as a service to users.
  • a service architecture refers to an architecture method in which a large complex software application is disassembled into one or more service instances. Each service instance in the system can be self-administered independently, and each service instance is loosely coupled. Each service instance focuses only on completing one task and doing it well.
  • a grayscale release control platform, a grayscale offloading device, and a VNFM-A are deployed in the PaaS.
  • the grayscale publishing control platform is used for process control and policy management, that is, the new version of the service instance is online, and the grayscale publishing policy is stored and managed, and the grayscale publishing policy is synchronously delivered to the grayscale shunting device according to the grayscale publishing process.
  • the grayscale release control platform interacts with the PaaS, deploys a new version of the service instance for the grayscale published service, and invokes the service registry interface to add tag information to the service instance, and the tag information is used for the grayscale offload LB to determine the service message sending object.
  • logo The grayscale release control platform synchronizes the grayscale strategy to the grayscale shunting device.
  • the gray-scale shunting device is configured to perform shunt management on the service request message, for example, the gray-scale shunting device may be based on the grayscale publishing policy, the gray-scale shunting rule metadata, and the gray-scale shunting state received from the grayscale publishing control platform.
  • the gray-scale shunting device may be based on the grayscale publishing policy, the gray-scale shunting rule metadata, and the gray-scale shunting state received from the grayscale publishing control platform.
  • the traffic of some service messages is offloaded to the high version instance.
  • VNFM-A is connected to VNFM. It is responsible for managing the grayscale publishing process and needs virtual machine resource management. It is mainly responsible for completing the application and release of virtual machine resources in the grayscale publishing process.
  • the gray-scale offloading device may be deployed independently or in a service instance integrated by a software development kit (SDK), that is, a small grayscale is integrated inside each service instance.
  • SDK software development kit
  • the shunting device when there are many types of services in a telecom software application system, increases the management load of the grayscale release control platform.
  • the grayscale offloading device can parse the service due to the distributed SDK code and service co-process deployment within the service instance.
  • the RPC type interface contract file can support both the RPC interface type message shunting and the Restful interface type message shunting. For the gray-scale shunting device independent deployment mode, only the Restful interface type gray-scale shunting is supported. In the scenario where the gray-scale traffic distribution device is deployed in an independent process, gray-scale offloading to third-party software systems is also supported.
  • the present application mainly provides the following technical solutions:
  • the "gray release control platform”, “grayscale shunt device” and “VNFM_A” public services are added, and the grayscale release control platform controls the high and low versions of the upgraded service service.
  • the VNFM_A performs the application of the corresponding type of virtual machine resource according to the type of the upgraded service at the beginning of the upgrade, and is responsible for releasing the virtual machine resource at the end of the grayscale release.
  • the grayscale release control platform automatically calculates the number of new and old versions of the service instances according to the whitelist and the split ratio, and expands and shrinks the new and old versions of the service instances by calling the PaaS interface, and the grayscale shunting device
  • the traffic control of the traffic message is controlled according to the number of service instances and the proportion of the traffic.
  • the following describes a method for providing service upgrade management, where the method includes:
  • the grayscale publishing control platform creates a grayscale publishing policy and a grayscale offloading rule.
  • the grayscale publishing policy may include a whitelisting policy, such as a whitelisting list, where the whitelisting list is strongly related to the service, and the whitelist in the whitelisted list may be a user identifier, a device identifier, a device network address, and the like. .
  • the grayscale release control platform controls the grayscale shunt state.
  • the gray-scale shunt state includes an end state, an initial state, a whitelist shunt state, and a proportional shunt state.
  • the gray-scale shunting state may correspond to a behavior logic of the gray-scale shunting device, that is, a shunting manner corresponding to controlling the flow of the service message.
  • the meaning of the gray-scale shunt state, the corresponding relationship between the gray-scale shunt state and the behavior logic of the gray-scale shunt device can be referred to the following Table 1:
  • Table 1 discloses the behavior logic of the corresponding gray-scale shunting device in each gray-scale shunting state.
  • the behavior logic of the gray-scale shunting device refers to the shunting mode in which the gray-scale shunting device controls the flow of the service message.
  • the grayscale offloading device may distribute the service message poll in the whitelist list to the new version service instance, and offload the service message polling in the whitelist list. To the old version of the service instance.
  • the gray-scale shunting device can quickly and accurately find the shunting method corresponding to the flow of the control service message, thereby efficiently and accurately satisfying the gray-scale publishing strategy and not satisfying the gray-scale publishing strategy.
  • the business message is offloaded to the corresponding service instance, thereby gradually migrating the business message smoothly to the new version of the service instance.
  • the grayscale distribution control platform sends the grayscale publishing policy, the grayscale offloading rule, and the grayscale offloading state to the grayscale offloading device.
  • the grayscale publishing policy, the grayscale offloading rule, and the grayscale offloading state are used by the grayscale offloading device to control the flow of the service message.
  • the grayscale publishing control platform defines the matching relationship between a specific field and the whitelist in the service message by using a configuration file, and specifically defines the The required code is as follows:
  • the grayscale shunting device receives the grayscale publishing policy, the grayscale shunting rule, and the grayscale shunting state from the grayscale publishing control platform.
  • the grayscale offloading device controls the flow of the service message according to the grayscale publishing policy, the grayscale offloading rule, and the grayscale offloading state.
  • the grayscale publishing control platform sends the grayscale publishing policy, the grayscale shunting rule, and the grayscale shunting state to the grayscale shunting device, so that the grayscale shunting
  • the device can accurately control the flow of service messages, and can ensure the stability of the telecom software application system. It does not need to deploy another test environment or the backup environment is specially used for stability testing before release, and can realize the grayscale upgrade capability of VNF. To ensure smooth switching and non-destructive upgrade of business traffic, and to reduce the risk of upgrade and improve the reliability of the software through trial and error, and not significantly increase the additional virtual machine resources.
  • the flow-dividing mode may be determined based on determining the current gray-scale splitting state, and then the flow of the service message traffic is controlled according to the determined splitting manner, specifically At least one of the following implementations can be included:
  • the gray-scale offloading state is an initial state
  • the traffic of the service message is offloaded according to the polling manner in the service instance of the first version.
  • the gray-scale offload state is an end state
  • the traffic of the service message is split according to a polling manner.
  • the gray-scale offloading state is a whitelisted offloading state
  • the service message conforming to the grayscale publishing policy is offloaded to the second version of the service instance, and the grayscale is not met.
  • the service message of the degree release policy is offloaded according to the polling manner in the service instance of the first version. For example, the service message matching the whitelist policy is offloaded to the service instance of the second version with the second tag information, and the service message that does not match the whitelist policy is polled in the service instance of the first version. The way to split.
  • the gray-scale offloading state is a proportionally splitting state
  • the service message that conforms to the grayscale publishing policy is offloaded to the second version of the service instance, and the grayscale is not met.
  • the service message of the degree release policy is offloaded according to the polling manner in the service instance of the first version or the service instance of the second version.
  • the service message matching the whitelist policy is offloaded to the service instance of the second version with the second tag information, and the service message that does not match the whitelist policy is polled in the service instance of the first version.
  • the method performs offloading, or the service message that does not match the whitelist policy is offloaded in a polling manner in the service instance of the second version.
  • the gray-scale shunting device can quickly and accurately find the shunting method corresponding to the flow of the control service message, thereby efficiently and accurately
  • the service message that satisfies the gray-scale publishing policy and does not satisfy the gray-scale publishing policy is offloaded to the corresponding service instance, thereby gradually migrating the service message to the service instance of the second version.
  • the grayscale offloading device according to the grayscale publishing policy, offloading the service message that meets the grayscale publishing policy to the second version of the service instance, including:
  • the grayscale offloading device acquires a specific field in the service message, and matches the specific field with the whitelist policy. For example, if the device identifier included in a specific field in the service message can be found in the whitelist policy, it may be determined that the service message satisfies the condition of offloading to the second version of the service instance.
  • the grayscale offloading device may obtain a matching relationship between the specific field and the whitelist from the grayscale distribution control platform, and when the matching relationship between the specific field and the whitelist matches the specific field, the grayscale offloading device determines The service message satisfies the condition of offloading to the service instance of the second version, thereby offloading the service message to the service instance of the second version.
  • the grayscale offloading device determines that the service message does not satisfy the condition of offloading to the service instance of the second version, and offloads the service message. Go to the first version of the service instance. It can be seen that, based on the matching relationship, the service message that needs to be offloaded to the service instance of the second version can be effectively identified.
  • the grayscale publishing control platform sends the grayscale publishing policy, the grayscale offloading rule, and the grayscale offloading state to a plurality of grayscale offloading devices.
  • the method further includes:
  • the grayscale issuance control platform deploys the service instance of the second version of the service service for performing the grayscale distribution, and adds the first label information to the service instance of the first version, and adds the second label information to the service instance of the second version. among them.
  • the first label information and the second label information are used by the grayscale offloading device to determine an identifier of a service message sending object, where a version of the second version of the service instance is higher than the service instance of the first version. .
  • adding tag information to the first version of the service instance eg, a lower version of the service instance: Low_version
  • adding tag information to the second version of the service instance eg, a higher version of the service instance: High_version.
  • the method further includes:
  • the grayscale publishing control platform adjusts a split ratio, where the split ratio refers to a ratio of the number of service instances of the first version of the offloaded service message and the number of service instances of the second version of the offloaded service message. For example, the last split ratio was 20%, and this time, the split ratio was 50%, which was gradually increased.
  • the grayscale release control platform may adjust the split ratio in the following manner:
  • the grayscale issuance control platform reduces the service instance of the first version to release the virtual machine resources occupied by the first version of the service instance; and performs the service instance of the second version.
  • the capacity expansion of the second version of the service instance occupies the released virtual machine resources.
  • the grayscale issuance control platform calculates the split ratio according to the number of service instances of the first version after the volume reduction, the number of service instances of the second version after the expansion, and the maximum split ratio of the current grayscale publishing task. Transmitting the split ratio to the grayscale shunt device.
  • the offloading ratio refers to the ratio of the number of service instances of the first version of the offloaded service message to the number of service instances of the second version of the offloaded service message.
  • the split ratio can be processed according to the following logic:
  • ⁇ the maximum split ratio of the current batch task
  • V1 the number of service instances of the lower version of the server
  • V2 the number of service instances of the high version of the server.
  • the grayscale offloading device receives the offloading ratio from the grayscale publishing control platform, and offloads the service message to the second version of the service instance according to the splitting ratio, from the grayscale publishing control platform.
  • Receiving the updated split ratio controlling the flow of the service message according to the updated split ratio until all service messages are offloaded to the second version of the service instance.
  • the service traffic flow on the service instance that is offloaded to the second version may be gradually improved by dynamically and repeatedly adjusting the split ratio, for example, 4 may be set.
  • the sub-flow ratio gradually completes the upgrade operation: 10%-->20%-->50%-->100%.
  • the service version of the second version of the service instance can take on more services by increasing the traffic distribution rate on the service instance that is offloaded to the second version through dynamic and multiple batch adjustment of the split ratio.
  • the adjustment of the split ratio in the present application may be completed multiple times, so that each time the split ratio of the service message is adjusted, Additional redundant virtual machine resources will be applied for, and service traffic can be gradually and smoothly migrated from the second version of the service instance to the first version of the service instance, which can avoid the unstable quality of the second version of the service instance. In this case, the risk of a complete system failure may result.
  • the multi-batch gradual migration of service message traffic can reduce the requirements for redundant virtual machine resources, especially in the scenario where the cost of virtual machine resources in the telecommunication equipment system is relatively high.
  • the business code in the telecom software application system is separated from the base platform code, the business code does not need to pay attention to the grayscale release details, and the grayscale release can be supported without modifying the open source code and the third party service code.
  • the grayscale release control platform After receiving the instruction to end the grayscale release sent by the user, the grayscale release control platform performs some environment cleaning actions, including the release of redundant virtual machine resources and the deletion of redundant low-level service packages.
  • the embodiment of the present application includes:
  • Step 1 The user creates a grayscale publishing task through the grayscale upgrade interface.
  • the grayscale publishing task includes: a service type of grayscale publishing, a target version of the service, and a whitelist list and a grayscale publishing batch. After the user fills in the relevant task information, click the submit operation, the grayscale publishing service receives the request, and persists the task information. Then start the grayscale publishing task.
  • Step 2 Before the grayscale publishing task starts, you need to apply to the VNFM for virtual machine resources, which are used to deploy new version instances of the grayscale service. Applying for virtual machine resources requires VNFM_A and VNFM to apply for a virtual machine.
  • Step 3 The grayscale publishing control platform interacts with the PaaS to deploy a new version of the service instance for the grayscale published service;
  • Step 4 The grayscale publishing control platform invokes the service registration center interface to add label information to the new and old version of the service instance respectively.
  • the label information on the server (old version) is: old_version, on the server (new version).
  • the tag information is: new_version, and the tag information is used by the gray-scale offloading device to determine the identifier of the service message sending object.
  • Step 5 The grayscale release control platform synchronizes the grayscale strategy to the grayscale shunting device.
  • Step 6 The grayscale distribution control platform sends a command to the grayscale offloading LB to notify the grayscale offloading LB to start grayscale publishing;
  • Step 7 The gray-scale shunting is performed according to the gray-scale shunting rule, for example, parsing the corresponding parameter from a specific field of the service message according to the currently received service message, and comparing with the whitelist list, if the parameter in the service message If it matches the whitelist, it needs to be distributed to the new version of the service instance, otherwise it needs to be offloaded to the old version of the service instance.
  • the gray-scale shunting for example, parsing the corresponding parameter from a specific field of the service message according to the currently received service message, and comparing with the whitelist list, if the parameter in the service message If it matches the whitelist, it needs to be distributed to the new version of the service instance, otherwise it needs to be offloaded to the old version of the service instance.
  • Step 8 The user can enable the high-level service instance to take on more services by increasing the traffic on the service instance that is offloaded to the new version, for example, sending a notification to adjust the split ratio to the grayscale release control platform.
  • Step 9 When the grayscale release control platform receives the notification of increasing the grayscale split ratio, the PaaS interface is first invoked to complete the shrinkage of the old version service, and the service instance that is shrunk automatically releases the virtual machine resource.
  • Step 10 The PaaS interface is invoked to expand the service instance of the new version.
  • the newly expanded service instance occupies the virtual machine resources released in step 9. It should be noted that the capacity reduction and capacity expansion operations can be completed multiple times, so that no excessive redundant virtual machine resources are applied for each time, and service traffic can be smoothly migrated between high and low version service instances. .
  • Step 11 The grayscale distribution control platform sends the split ratio to the grayscale offloading device.
  • Step 12 The grayscale offloading device offloads more traffic to the new version of the service instance according to the split ratio.
  • the user needs to repeatedly adjust the gray scale ratio until the entire service traffic is offloaded to the new version of the service instance, thereby smoothly completing the service migration.
  • Step 13 After the service traffic is all switched to the high version service instance, and after a period of stable operation, the user may send an instruction to execute the grayscale release to the grayscale release control platform. After receiving the command, the grayscale release control platform performs some environment cleanup actions, including releasing redundant virtual machine resources and deleting redundant old service packs.
  • the gray-scale traffic distribution device gradually migrates the service traffic from the old version of the service instance to the new version of the service instance according to the whitelist and the split-scale ratio, so as to avoid the unstable software quality of the new version of the service. It may cause the risk of failure of the whole telecom software application system.
  • the multi-batch step-by-step traffic migration reduces the requirements for redundant virtual machine resources, especially for scenarios where the virtual machine resource cost is relatively high in the telecom software application system.
  • the above describes a method for service upgrade management in the present application.
  • the following describes the grayscale release control platform and the grayscale offloading device for performing the above method for service upgrade management.
  • the grayscale issuance control platform of the embodiment of the present application can implement the grayscale distribution control platform in the embodiment corresponding to any of the above-mentioned FIG. 2 to FIG.
  • the steps of the method of service upgrade management performed by the control platform are released.
  • the functions implemented by the grayscale release control platform may be implemented by hardware, or may be implemented by hardware corresponding software.
  • the hardware or software includes one or more modules corresponding to the functions described above, which may be software and/or hardware.
  • the grayscale issuance control platform may include a transceiver module and a processing module, and the function implementation of the processing module may refer to each of the grayscale issue control platforms executed in the embodiment corresponding to any one of FIG. 2 to FIG. Such operations are not described here.
  • the function implementation of the transceiver module may refer to various operations performed by the grayscale issue control platform in the embodiment corresponding to any one of FIG. 2 to FIG. 4, and the processing module may be configured to control the transceiver operation of the transceiver module.
  • the processing module can be used to create a grayscale publishing policy and a grayscale shunting rule to control the grayscale shunting state.
  • the transceiver module may be configured to send the grayscale publishing policy, the grayscale offloading rule, and the grayscale offloading state to a grayscale offloading device;
  • the grayscale publishing policy, the grayscale offloading rule, and the grayscale offloading state are used by the grayscale offloading device to control the flow of the service message.
  • the transceiver module in the grayscale distribution control platform delivers the grayscale publishing policy, the grayscale offloading rule, and the grayscale offloading state to the grayscale offloading device, so that the grayscale shunting device can be accurate
  • the flow of control service messages can ensure the stability of the telecom software application system. There is no need to deploy another test environment or the backup environment is dedicated to the stability test before release. It can realize the grayscale upgrade capability of VNF and ensure the service. Smooth switching and non-destructive upgrade of traffic, and reduce the risk of upgrade and improve the reliability of the software through trial and error, and do not significantly increase the additional virtual machine resources.
  • the gray-scale shunt state includes an initial state, an end state, a whitelist shunt state, and a proportional shunt state.
  • the processing module before the sending and receiving module sends the grayscale publishing policy, the grayscale offloading rule, and the grayscale offloading state to the plurality of grayscale offloading devices, the processing module is further configured to:
  • the device determines an identifier of the service message sending object, and the version of the second version of the service instance is higher than the service instance of the first version.
  • the processing module is further configured to:
  • the split ratio is adjusted, where the split ratio refers to the ratio of the number of service instances of the first version of the offload service message and the number of service instances of the second version of the offload service message.
  • the processing module is configured to:
  • FIG. 6 is a schematic structural diagram of a gray-scale shunting device, and the gray-scale shunting device in the embodiment of the present application can implement a gray-scale shunting device corresponding to the embodiment corresponding to any of the foregoing FIG. 2 to FIG.
  • the functions implemented by the gray-scale shunt device can be implemented by hardware or by executing corresponding software through hardware.
  • the hardware or software includes one or more modules corresponding to the functions described above, which may be software and/or hardware.
  • the gray-scale shunting device may include a transceiver module and a processing module, and the function implementation of the processing module may refer to various operations performed by the gray-scale shunt device in the embodiment corresponding to any of FIG.
  • transceiver module For the function implementation of the transceiver module, refer to various operations performed by the gray-scale offloading device in the embodiment corresponding to any one of FIG. 2 to FIG. 4, and the processing module can be used to control the transceiver operation of the transceiver module.
  • the transceiver module is configured to receive a grayscale publishing policy, a grayscale offloading rule, and a grayscale offloading state from a grayscale publishing control platform;
  • a processing module configured to control a flow of the service message according to the grayscale publishing policy, the grayscale offloading rule, and the grayscale offloading state.
  • the gray-scale shunt state includes an initial state, an end state, a whitelist shunt state, and a proportional shunt state.
  • the processing module in the grayscale shunting device can Accurate control of the flow of business messages can ensure the stability of the telecom software application system system. There is no need to deploy another test environment or the backup environment is dedicated to the stability test before release, which can realize the grayscale upgrade capability of VNF. Smooth switching and non-destructive upgrade of service traffic, and reduce the risk of upgrade and improve the reliability of the software through trial and error, and do not significantly increase the additional virtual machine resources.
  • the processing module is configured to perform at least one of the following operations:
  • gray-scale offloading state is an initial state
  • traffic of the service message is offloaded according to a polling manner in the service instance of the first version
  • the gray-scale offloading state is an end state
  • the traffic of the service message is offloaded according to a polling manner
  • the gray-scale offloading state is a whitelisted offloading state
  • the service message conforming to the grayscale publishing policy is offloaded to the second version of the service instance, and the grayscale is not met.
  • the service message of the degree release policy is offloaded according to the polling manner in the service instance of the first version;
  • the gray-scale offloading state is a proportionally splitting state
  • the service message that conforms to the grayscale publishing policy is offloaded to the second version of the service instance, and the grayscale is not met.
  • the service message of the degree release policy is offloaded according to the polling manner in the service instance of the first version or the service instance of the second version.
  • the grayscale publishing policy includes a whitelisting policy
  • the processing module is specifically configured to:
  • the transceiver module is further configured to:
  • the split ratio refers to a ratio of the number of service instances of the first version of the offloaded service message and the number of service instances of the second version of the offloaded service message;
  • FIG. 7 is another schematic structural diagram of a grayscale distribution control platform or a grayscale offloading device according to an embodiment of the present disclosure, which may include at least one processor, at least one network interface or other communication interface, a memory, at least one communication bus, At least one transceiver is used to implement connection communication between these devices.
  • the above processor is configured to execute an executable module, such as a computer program, stored in the above memory.
  • the above memory may include a high speed random access memory (English name: Random Access Memory, English abbreviation: RAM), and may also include a non-volatile memory, such as at least one disk memory.
  • the communication connection between the system gateway and at least one other network element is implemented by at least one network interface (which may be wired or wireless), and an Internet, a wide area network, a local network, a metropolitan area network, etc. may be used.
  • the memory is stored in the memory, and the program instruction may be executed by the processor, and the processor specifically executes the service in the embodiment of the present application by calling a program instruction stored in the memory.
  • the program code that needs to be called when managing the method.
  • the physical devices corresponding to all the transceiver modules may be transceivers, and the physical devices corresponding to all processing modules may be processed.
  • Device Each of the devices shown in FIGS. 5 and 6 may have a structure as shown in FIG. 7.
  • the processor and the transceiver in FIG. 7 implement the aforementioned corresponding device.
  • the device module provides the same or similar functions as the processing module and the transceiver module, and the memory storage processor in FIG. 7 needs to call the program code when executing the method of the service upgrade management described above.
  • the transceiver may also be replaced by a receiver and a transmitter, and may be the same or different physical entities. When they are the same physical entity, they can be collectively referred to as a transceiver.
  • the transceiver can be a radio frequency (English name: Radio Frequency, English abbreviation: RF) circuit.
  • the memory may be integrated in the processor or may be provided separately from the processor.
  • the processor in FIG. 7 may call the program code that is required to be executed when the processor specifically executes the method of service upgrade management in the embodiment of the present application by calling a program instruction stored in the memory.
  • the memory storage processor in FIG. 7 executes the above-described program code to be called when the method of performing the service upgrade management by the grayscale distribution control platform is executed.
  • the processor in FIG. 7 can call the program code in the memory to perform the following operations:
  • the memory storage processor in FIG. 7 executes the above-described program code to be called when the method of performing service upgrade management by the gradation shunting apparatus is executed.
  • the processor in FIG. 7 can call the program code in the memory to perform the following operations:
  • the disclosed system, apparatus, and method may be implemented in other manners.
  • the device embodiments described above are merely illustrative.
  • the division of the modules is only a logical function division.
  • there may be another division manner for example, multiple modules or components may be combined or Can be integrated into another system, or some features can be ignored or not executed.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or module, and may be electrical, mechanical or otherwise.
  • the modules described as separate components may or may not be physically separated.
  • the components displayed as modules may or may not be physical modules, that is, may be located in one place, or may be distributed to multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the embodiment.
  • each functional module in each embodiment of the present application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.
  • the above integrated modules can be implemented in the form of hardware or in the form of software functional modules.
  • the integrated modules, if implemented in the form of software functional modules and sold or used as separate products, may be stored in a computer readable storage medium.
  • the computer program product includes one or more computer instructions.
  • the computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable device.
  • the computer instructions can be stored in a computer readable storage medium or transferred from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions can be from a website site, computer, server or data center Transfer to another website site, computer, server, or data center by wire (eg, coaxial cable, fiber optic, digital subscriber line (DSL), or wireless (eg, infrared, wireless, microwave, etc.).
  • wire eg, coaxial cable, fiber optic, digital subscriber line (DSL), or wireless (eg, infrared, wireless, microwave, etc.).
  • the computer readable storage medium can be any available media that can be stored by a computer or a data storage device such as a server, data center, or the like that includes one or more available media.
  • the usable medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (such as a solid state disk (SSD)).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

一种服务升级管理的方法、装置及存储介质，所述方法包括：创建灰度发布策略和灰度分流规则；控制灰度分流状态；向灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态；其中，所述灰度发布策略、所述灰度分流规则和所述灰度分流状态用于所述灰度分流设备控制业务消息的流向。通过采用该方案，不需要另外部署一套测试环境或者备份环境专门用于发布前的稳定性测试，就能够实现业务流量的平滑切换及无损升级。

Description

一种服务升级管理的方法、装置及存储介质
本申请要求于2018年3月26日提交中国国家知识产权局、申请号为201810253849.8、发明名称为“一种服务升级管理的方法、装置及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及灰度发布技术领域，尤其涉及一种服务升级管理的方法、灰度发布控制平台、灰度分流设备及存储介质。
背景技术
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
对现网设备采用生产环境及测试环境，通过前端分流设备进行分流控制，当新版本系统上线后，控制分流设备分流策略将业务消息分流到测试环境上进行试运行，如果运行正常，则升级成功，否则将业务消息分流到原先的生产环境上。
发明内容
本申请提供了一种服务升级管理的方法、装置及存储介质，能够解决现有技术中需要额外部署系统环境，资源占用过多的问题。
本申请第一方面提供一种服务升级管理的方法，应用于灰度发布控制平台，所述方法包括：
创建灰度发布策略和灰度分流规则；
控制灰度分流状态；
向灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态；
其中，所述灰度发布策略、所述灰度分流规则和所述灰度分流状态用于所述灰度分流设备控制业务消息的流向。
本申请实施例中，灰度发布控制平台向灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态，使得灰度分流设备能够准确的控制业务消息的流向，可以保证电信软件应用系统系统的稳定性，不需要另外部署一套测试环境或者备份环境专门用于发布前的稳定性测试，能够实现VNF的灰度升级能力，保证业务流量的平滑切换及无损升级，并通过试错的方式降低升级风险、提升软件的可靠性，并且不显著增加额外虚机资源。
一些实施方式中，所述灰度分流状态包括：初始状态、结束状态、白名单分流状态和按比例分流状态，所述灰度发布策略可包括白名单策略，例如为白名单列表，白名单列表与业务强相关，白名单列表中的白名单可以是用户标识、设备标识、设备网络地址等。通过对灰度分流状态进行分类，使得灰度分流设备能够迅速、准确地找的对应控制业务消息流向的分流方式，进而高效、准确地将满足灰度发布策略、不满足灰度发布策略的业务消息分流至对 应的服务实例中，从而逐步地将业务消息平滑的迁移至新版本的服务实例上。
一些实施方式中，所述灰度分流状态可对应灰度分流设备的行为逻辑，即对应控制业务消息流向的分流方式。
一些实施方式中，所述向多个灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态之前，所述方法还包括：
对待进行灰度发布的业务服务部署第二版本的服务实例；
分别对第一版本的服务实例添加第一标签信息，对第二版本的服务实例添加第二标签信息；其中，所述第一标签信息和所述第二标签信息均用于所述灰度分流设备判断业务消息发送对象的标识，所述第二版本的服务实例的版本高于所述第一版本的服务实例。
一些实施方式中，所述方法还包括：
调整分流比例，所述分流比例是指分流业务消息的第一版本的服务实例数量和分流业务消息的第二版本的服务实例数量的比例。
一些实施方式中，所述调整分流比例，包括：
对所述第一版本的服务实例进行缩容，以释放缩容的所述第一版本的服务实例占用的虚拟机资源；以及对所述第二版本的服务实例进行扩容，扩容的第二版本的服务实例占用所述释放的虚拟机资源；
根据缩容后的所述第一版本的服务实例数量、扩容后的所述第二版本的服务实例数量、以及当前灰度发布任务的最大分流比例，计算分流比例；
所述方法还包括：
向所述灰度分流设备发送所述分流比例。
一些实施方式中，所述业务消息包括特定字段，发送业务消息之前，所述方法还包括：
建立白名单与所述业务消息中的特定字段的匹配关系；
向所述灰度分流设备发送所述匹配关系。
本申请第二方面提供一种服务升级管理的方法，应用于灰度分流设备，所述方法包括：
从灰度发布控制平台接收灰度发布策略、灰度分流规则和灰度分流状态；
根据所述灰度分流状态确定分流模式；
根据确定的分流模式、所述灰度发布策略、所述灰度分流规则和所述灰度分流状态，控制业务消息的流向。
一些实施方式中，所述灰度分流状态包括：初始状态、结束状态、白名单分流状态和按比例分流状态。
一些实施方式中，所述根据确定的分流模式、所述灰度发布策略、所述灰度分流规则和所述灰度分流状态，控制业务消息流量的流向，包括以下实现方式之一：
当所述灰度分流状态为初始状态时，在第一版本的服务实例中按照轮询方式对业务消息的流量分流；
或者，当所述灰度分流状态为结束状态时，对业务消息的流量按照轮询方式分流；
或者，当所述灰度分流状态为白名单分流状态时，根据所述灰度发布策略，将符合所述灰度发布策略的业务消息分流到第二版本的服务实例，将不符合所述灰度发布策略的业务消息在第一版本的服务实例中按照轮询方式进行分流；
或者，当所述灰度分流状态为按比例分流状态时，根据所述灰度发布策略，将符合所述灰度发布策略的业务消息分流到第二版本的服务实例，将不符合所述灰度发布策略的业务消 息在第一版本的服务实例或第二版本的服务实例中按照轮询方式进行分流。
一些实施方式中，所述灰度发布策略包括白名单策略，所述根据所述灰度发布策略，将符合所述灰度发布策略的业务消息分流到第二版本的服务实例，包括：
获取所述业务消息中的特定字段；
将所述特定字段与所述白名单策略进行匹配；
当根据特定字段与白名单的匹配关系匹配到所述特定字段时，则确定所述业务消息满足分流到第二版本的服务实例的条件，将所述业务消息分流到第二版本的服务实例上；
当根据所述特定字段与白名单的匹配关系未匹配到所述特定字段时，则确定所述业务消息不满足分流到第二版本的服务实例的条件，将所述业务消息分流到第一版本的服务实例上。
一些实施方式中，所述方法还包括：
从所述灰度发布控制平台接收分流比例，所述分流比例是指分流业务消息的第一版本的服务实例数量和分流业务消息的第二版本的服务实例数量的比例；
按照所述分流比例，将所述业务消息分流到所述第二版本的服务实例上；
从所述灰度发布控制平台接收更新的分流比例，按照更新的分流比例控制业务消息的流向，直至将所有业务消息分流到所述第二版本的服务实例上。
一些实施方式中，所述灰度分流设备以软件开发工具包SDK的方式集成在服务实例中。
本申请第三方面提供一种灰度发布控制平台，具有实现对应于上述第一方面提供的服务升级管理的方法的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，所述模块可以是软件和/或硬件。一种实施方式中，所述灰度发布控制平台包括：
处理模块，用于创建灰度发布策略和灰度分流规则；
控制灰度分流状态；
收发模块，用于向灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态；
其中，所述灰度发布策略、所述灰度分流规则和所述灰度分流状态用于所述灰度分流设备控制业务消息的流向。
一些实施方式中，所述灰度分流状态包括：初始状态、结束状态、白名单分流状态和按比例分流状态。
一些实施方式中，所述收发模块向多个灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态之前，所述处理模块还用于：
对待进行灰度发布的业务服务部署第二版本的服务实例；
分别对第一版本的服务实例添加第一标签信息，对第二版本的服务实例添加第二标签信息；其中，所述第一标签信息和所述第二标签信息均用于所述灰度分流设备判断业务消息发送对象的标识，所述第二版本的服务实例的版本高于所述第一版本的服务实例。
一些实施方式中，所述处理模块还用于：
调整分流比例，所述分流比例是指分流业务消息的第一版本的服务实例数量和分流业务消息的第二版本的服务实例数量的比例。
一些实施方式中，所述处理模块用于：
对所述第一版本的服务实例进行缩容，以释放缩容的所述第一版本的服务实例占用的虚 拟机资源；以及对所述第二版本的服务实例进行扩容，扩容的第二版本的服务实例占用所述释放的虚拟机资源；
根据缩容后的所述第一版本的服务实例数量、扩容后的所述第二版本的服务实例数量、以及当前灰度发布任务的最
大分流比例，计算分流比例；
通过所述收发模块向所述灰度分流设备发送所述分流比例。
本申请第四方面提供一种灰度分流设备，具有实现对应于上述第二方面提供的服务升级管理的方法的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，所述模块可以是软件和/或硬件。
一种实施方式中，所述灰度分流设备包括：
收发模块，用于从灰度发布控制平台接收灰度发布策略、灰度分流规则和灰度分流状态；
处理模块，用于根据所述灰度发布策略、所述灰度分流规则和所述灰度分流状态，控制业务消息的流向。
一些实施方式中，所述灰度分流状态包括：初始状态、结束状态、白名单分流状态和按比例分流状态。
一些实施方式中，所述处理模块至少用于执行以下操作之一：
当所述灰度分流状态为初始状态时，在第一版本的服务实例中按照轮询方式对业务消息的流量分流；
或者，当所述灰度分流状态为结束状态时，对业务消息的流量按照轮询方式分流；
或者，当所述灰度分流状态为白名单分流状态时，根据所述灰度发布策略，将符合所述灰度发布策略的业务消息分流到第二版本的服务实例，将不符合所述灰度发布策略的业务消息在第一版本的服务实例中按照轮询方式进行分流；
或者，当所述灰度分流状态为按比例分流状态时，根据所述灰度发布策略，将符合所述灰度发布策略的业务消息分流到第二版本的服务实例，将不符合所述灰度发布策略的业务消息在第一版本的服务实例或第二版本的服务实例中按照轮询方式进行分流。
一些实施方式中，所述灰度发布策略包括白名单策略，所述处理模块具体用于：
通过所述收发模块获取所述业务消息中的特定字段；
将所述特定字段与所述白名单策略进行匹配；
当根据特定字段与白名单的匹配关系匹配到所述特定字段时，则确定所述业务消息满足分流到第二版本的服务实例的条件，将所述业务消息分流到第二版本的服务实例上；
当根据所述特定字段与白名单的匹配关系未匹配到所述特定字段时，则确定所述业务消息不满足分流到第二版本的服务实例的条件，将所述业务消息分流到第一版本的服务实例上。
一些实施方式中，所述收发模块还用于：
从所述灰度发布控制平台接收分流比例，所述分流比例是指分流业务消息的第一版本的服务实例数量和分流业务消息的第二版本的服务实例数量的比例；
按照所述分流比例，将所述业务消息分流到所述第二版本的服务实例上；
从所述灰度发布控制平台接收更新的分流比例，按照更新的分流比例控制业务消息的流向，直至将所有业务消息分流到所述第二版本的服务实例上。
本申请又一方面提供了一种计算机装置，其包括至少一个连接的处理器、存储器和收发器，其中，所述存储器用于存储程序代码，所述处理器用于调用所述存储器中的程序代码来 执行上述各方面所述的方法。
本申请又一方面提供了一种计算机存储介质，其包括指令，当其在计算机上运行时，使得计算机执行上述第一方面中所述的操作，或者执行上述第二方面中所述的操作。
本申请又一方面提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面中所述的操作，或者执行上述第二方面中所述的操作。
附图说明
图1为本申请实施例中电信软件应用系统的一种架构示意图；
图2为本申请实施例中服务升级管理的方法的一种流程示意图；
图3为本申请实施例中按照灰度分流状态分流业务消息的一种流程示意图；
图4为本申请实施例中服务升级管理的方法的一种流程示意图；
图5为本申请实施例中灰度发布控制平台的一种结构示意图；
图6为本申请实施例中灰度分流设备的一种结构示意图；
图7为本申请实施例中执行服务升级管理的方法的装置的一种结构示意图。
具体实施方式
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或模块的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或模块，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块，本申请中所出现的模块的划分，仅仅是一种逻辑上的划分，实际应用中实现时可以有另外的划分方式，例如多个模块可以结合成或集成在另一个系统中，或一些特征可以忽略，或不执行，另外，所显示的或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，模块之间的间接耦合或通信连接可以是电性或其他类似的形式，本申请中均不作限定。并且，作为分离部件说明的模块或子模块可以是也可以不是物理上的分离，可以是也可以不是物理模块，或者可以分布到多个电路模块中，可以根据实际的需要选择其中的部分或全部模块来实现本申请方案的目的。
本申请供了一种服务升级管理的方法、装置及存储介质，用于电信软件应用系统中的灰度发布，例如用于电信软件应用系统的升级操作、补丁操作、配置操作等场景。以下进行详细说明。
如图1所示的一种电信软件应用系统，其包括虚拟网络功能(Virtualised Network Function，VNF)、虚拟网络功能管理者(Virtualised Network Function Manager，VNFM)、VNFM-A、网络功能虚拟化(Network Function Virtualisation，NFV)、平台即服务(Platform-as-a-Service，PaaS)、虚拟基础设施管理者(Virtualised Infrastructure Manager，VIM)和业务/运营支持系统。下面介绍图1所示的系统中各功能部分的功能。
VNF用于部署业务服务实例和灰度发布，例如部署服务实例1和服务实例2。
PaaS是指将软件研发的平台作为一种服务提供给用户使用。服务化架构是指将一个大型复杂软件应用拆解成一个或多个服务实例组成的架构方法，系统中的各个服务实例可独立自 治，各个服务实例之间是松耦合的。每个服务实例仅关注于完成一件任务并很好地完成该任务。本申请实施例中，在PaaS中部署灰度发布控制平台、灰度分流设备和VNFM-A。
其中，灰度发布控制平台用于流程控制和策略管理，即负责新版本服务实例上线，并存储管理灰度发布策略，根据灰度发布过程将灰度发布策略同步下发到灰度分流设备。灰度发布控制平台与PaaS交互，对灰度发布的服务部署新版本的服务实例，以及调用服务注册中心接口对服务实例添加标签信息，该标签信息用于灰度分流LB判断业务消息发送对象的标识。灰度发布控制平台同步灰度策略给灰度分流设备。
灰度分流设备用于对业务请求消息进行分流管理等，例如灰度分流设备可根据从灰度发布控制平台接收到的灰度发布策略、灰度分流规则元数据及灰度分流状态等信息，来控制业务消息的流向。比如，根据白名单策略，将部分业务消息的流量分流到高版本实例上。
VNFM-A与VNFM对接，负责管理灰度发布过程需要虚机资源管理，主要负责完成在灰度发布过程进行虚机资源的申请和释放。
本申请实施例中，灰度分流设备可以是独立部署，也可以是以软件开发工具包(Software Development Kit，SDK)的方式集成的服务实例内部，即每个服务实例内部集成一个小的灰度分流设备，当一个电信软件应用系统系统中的服务类型众多时，会加大灰度发布控制平台的管理负载，由于服务实例内分流的SDK代码和服务共进程部署，灰度分流设备可以解析服务之间的RPC类型接口契约文件，因此，既可以支持RPC接口类型的消息分流，也可以支持Restful接口类型的消息分流；对于灰度分流设备独立部署模式下，仅仅支持Restful接口类型的灰度分流，灰度分流设备独立进程部署的场景下，也支持对第三方软件系统进行灰度分流。
为解决上述技术问题，本申请主要提供以下技术方案：
在基于PaaS的电信软件应用系统架构中，增加“灰度发布控制平台”、“灰度分流设备”及“VNFM_A”公共服务，由灰度发布控制平台控制被升级的业务服务的高、低版本的服务实例生命周期管理，并控制灰度分流设备的分流状态及策略的变迁，以及控制VNFM_A服务与VNFM交互完成灰度升级期间的虚机资源的申请及释放；灰度分流设备根据灰度策略及分流状态完成业务消息的分流任务，VNFM_A在升级开始初期根据被升级业务的类型执行申请对应类型的虚机资源及在结束灰度发布负责虚机资源的释放。
通过灰度发布控制平台根据白名单及分流比例，自动计算新、旧版本的服务实例数量，并通过调用PaaS接口对新、旧版本的服务实例的进行扩容、缩容操作，并且灰度分流设备根据服务实例数量及分流比例进行业务消息的分流控制。
参照图2，以下介绍本申请提供一种服务升级管理的方法，所述方法包括：
201、灰度发布控制平台创建灰度发布策略和灰度分流规则。
一些实施方式中，所述灰度发布策略可包括白名单策略，例如为白名单列表，白名单列表与业务强相关，白名单列表中的白名单可以是用户标识、设备标识、设备网络地址等。
202、灰度发布控制平台控制灰度分流状态。
一些实施方式中，所述灰度分流状态包括：结束状态、初始状态、白名单分流状态和按比例分流状态。所述灰度分流状态可对应灰度分流设备的行为逻辑，即对应控制业务消息流向的分流方式。灰度分流状态的含义、灰度分流状态与灰度分流设备的行为逻辑的对应关系可参考下表1：
Figure PCTCN2019078286-appb-000001
表1
表1中揭示了每种灰度分流状态下对应的灰度分流设备的行为逻辑，灰度分流设备的行为逻辑是指：灰度分流设备控制业务消息的流向的分流方式。例如，当灰度分流状态为白名单分流状态时，灰度分流设备可将在白名单列表中的业务消息轮询分发给新版本服务实例，将未在白名单列表中的业务消息轮询分流至旧版本服务实例。可见，通过对灰度分流状态进行分类，使得灰度分流设备能够迅速、准确地找的对应控制业务消息流向的分流方式，进而高效、准确地将满足灰度发布策略、不满足灰度发布策略的业务消息分流至对应的服务实例中，从而逐步地将业务消息平滑的迁移至新版本的服务实例上。
203、灰度发布控制平台向灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态。
其中，所述灰度发布策略、所述灰度分流规则和所述灰度分流状态用于所述灰度分流设备控制业务消息的流向。
为了实现灰度分流设备的处理逻辑与具体的白名单类型及业务消息，灰度发布控制平台通过配置文件的方式来定义：业务消息中的某个特定字段与白名单的匹配关系，具体定义所需的代码如下：
Figure PCTCN2019078286-appb-000002
204、灰度分流设备从灰度发布控制平台接收灰度发布策略、灰度分流规则和灰度分流状 态。
205、灰度分流设备根据所述灰度发布策略、所述灰度分流规则和所述灰度分流状态，控制业务消息的流向。
与现有机制相比，本申请实施例中，灰度发布控制平台向灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态，使得灰度分流设备能够准确的控制业务消息的流向，可以保证电信软件应用系统系统的稳定性，不需要另外部署一套测试环境或者备份环境专门用于发布前的稳定性测试，能够实现VNF的灰度升级能力，保证业务流量的平滑切换及无损升级，并通过试错的方式降低升级风险、提升软件的可靠性，并且不显著增加额外虚机资源。
一些实施方式中，例如图3所示，灰度分流设备控制业务消息流量的流向时，可基于确定当前的灰度分流状态确定分流方式，然后根据确定的分流方式控制业务消息流量的流向，具体至少可包括以下实现方式之一：
例如，当所述灰度分流状态为初始状态时，在第一版本的服务实例中按照轮询方式对业务消息的流量分流。
或者，当所述灰度分流状态为结束状态时，对业务消息的流量按照轮询方式分流。
或者，当所述灰度分流状态为白名单分流状态时，根据所述灰度发布策略，将符合所述灰度发布策略的业务消息分流到第二版本的服务实例，将不符合所述灰度发布策略的业务消息在第一版本的服务实例中按照轮询方式进行分流。例如，将与白名单策略匹配的业务消息分流到带有第二标签信息的第二版本的服务实例，将与所述白名单策略不匹配的业务消息在第一版本的服务实例中按照轮询方式进行分流。
或者，当所述灰度分流状态为按比例分流状态时，根据所述灰度发布策略，将符合所述灰度发布策略的业务消息分流到第二版本的服务实例，将不符合所述灰度发布策略的业务消息在第一版本的服务实例或第二版本的服务实例中按照轮询方式进行分流。例如，将与白名单策略匹配的业务消息分流到带有第二标签信息的第二版本的服务实例，将与所述白名单策略不匹配的业务消息在第一版本的服务实例中按照轮询方式进行分流，或者将与所述白名单策略不匹配的业务消息在第二版本的服务实例中按照轮询方式进行分流。
可见，通过对灰度分流状态进行分类，并预配置灰度分流设备对应的行为逻辑，使得灰度分流设备能够迅速、准确地找的对应控制业务消息流向的分流方式，进而高效、准确地将满足灰度发布策略、不满足灰度发布策略的业务消息分流至对应的服务实例中，从而逐步地将业务消息平滑的迁移至第二版本的服务实例上。
可选的，在本申请的一些实施例中，所述灰度分流设备根据所述灰度发布策略，将符合所述灰度发布策略的业务消息分流到第二版本的服务实例，包括：
灰度分流设备获取所述业务消息中的特定字段，将所述特定字段与所述白名单策略进行匹配。例如该业务消息中的特定字段中包括的设备标识能够在该白名单策略中找到，那么可确定所述业务消息满足分流到第二版本的服务实例的条件。
一些实施方式中，灰度分流设备可从灰度发布控制平台获取特定字段与白名单的匹配关系，当根据特定字段与白名单的匹配关系匹配到所述特定字段时，则灰度分流设备确定所述业务消息满足分流到第二版本的服务实例的条件，从而将所述业务消息分流到第二版本的服务实例上。
当根据所述特定字段与白名单的匹配关系未匹配到所述特定字段时，则灰度分流设备确 定所述业务消息不满足分流到第二版本的服务实例的条件，将所述业务消息分流到第一版本的服务实例上。可见，基于匹配关系，能够有效的识别出需要分流到第二版本的服务实例的业务消息。
可选的，在本申请的一些发明实施例中，所述灰度发布控制平台向多个灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态之前，所述方法还包括：
所述灰度发布控制平台对待进行灰度发布的业务服务部署第二版本的服务实例，分别对第一版本的服务实例添加第一标签信息，对第二版本的服务实例添加第二标签信息。其中。所述第一标签信息和所述第二标签信息均用于所述灰度分流设备判断业务消息发送对象的标识，所述第二版本的服务实例的版本高于所述第一版本的服务实例。
例如，对第一版本的服务实例(例如低版本的服务实例)添加标签信息：Low_version；对第二版本的服务实例(例如高版本的服务实例)添加标签信息：High_version。
可选的，在本申请的一些发明实施例中，所述方法还包括：
所述灰度发布控制平台调整分流比例，所述分流比例是指分流业务消息的第一版本的服务实例数量和分流业务消息的第二版本的服务实例数量的比例。例如，上一次分流比例为20％，本次可下发分流比例50％，逐步增加。
一些实施方式中，所述灰度发布控制平台可以采用以下方式调整分流比例：
所述灰度发布控制平台对所述第一版本的服务实例进行缩容，以释放缩容的所述第一版本的服务实例占用的虚拟机资源；以及对所述第二版本的服务实例进行扩容，扩容的第二版本的服务实例占用所述释放的虚拟机资源。
所述灰度发布控制平台根据缩容后的所述第一版本的服务实例数量、扩容后的所述第二版本的服务实例数量、以及当前灰度发布任务的最大分流比例，计算分流比例，向所述灰度分流设备发送所述分流比例。所述分流比例是指分流业务消息的第一版本的服务实例数量和分流业务消息的第二版本的服务实例数量的比例。一些实施方式中，分流比例可以按照下面逻辑进行处理：
分流比例α计算公式为：α＝V2/(V1+V2)>β？β：负载均衡
其中，β：当前批次任务的最大分流比例；V1：服务端低版本服务实例数；V2：服务端高版本服务实例数。
相应的，灰度分流设备从所述灰度发布控制平台接收分流比例，按照所述分流比例，将所述业务消息分流到所述第二版本的服务实例上，从所述灰度发布控制平台接收更新的分流比例，按照更新的分流比例控制业务消息的流向，直至将所有业务消息分流到所述第二版本的服务实例上。本申请实施例中，为实现业务流量的平滑迁移，还可以通过动态的、多次的调整分流比例的方式，逐步的提高分流到第二版本的服务实例上的业务消息流量，例如可设置4个次分流比例逐步的完成升级操作：10％-->20％-->50％-->100％。
可见，通过动态的、多次分批的调整分流比例的方式，能够通过提高分流到第二版本的服务实例上的业务消息流量，使得第二版本的服务实例承担更多的业务。另外，本申请中对分流比例的调整(例如对第一版本的服务实例缩容和对第二版本的服务实例扩容)可以分多次完成，这样每次调整业务消息的分流比例时，也不会额外申请过多的冗余虚机资源，业务流量也可以逐步的、平滑的从第二版本的服务实例迁移至第一版本的服务实例，能够避免在第二版本的服务实例的质量不稳定情况下可能造成整系统故障的风险。同时，通过多批次逐步对业务消息流量迁移，可以降低对冗余虚机资源的要求，尤其适应于电信设备系统内虚机 资源成本占比较高的场景。此外，电信软件应用系统中的业务代码与基础平台代码分离，业务代码无需关注灰度发布细节，无需修改开源代码及第三方服务代码也能支持灰度发布。
当业务流量全部从第一版本的服务实例切换到第二版本的服务实例后，并且经过一段时间的稳定运行，用户可以执行结束灰度发布。灰度发布控制平台接收到用户发送的结束灰度发布的指令后，则会进行一些环境清理动作，环境清理动作包括释放掉多余的虚机资源及删除多余的低版本的服务包等。
为便于理解，下面以一具体的应用场景为例介绍本申请的服务升级管理的方法，如图4所示，本申请实施例包括：
步骤1：用户通过灰度升级界面创建灰度发布任务，灰度发布任务包括：灰度发布的服务类型，服务的目标版本，以及白名单列表及灰度发布批次等信息。用户填写相关任务信息后，点击提交操作，灰度发布服务接收请求，并对任务信息进行持久化保存。接着开始执行灰度发布任务。
步骤2：在灰度发布任务开始之前，需要先向VNFM申请虚拟机资源，该虚拟机资源用于部署灰度服务的新版本实例。申请虚拟机资源需要VNFM_A和VNFM交互申请虚机。
步骤3：灰度发布控制平台与PaaS交互，对灰度发布的服务部署新版本的服务实例；
步骤4：灰度发布控制平台调用服务注册中心接口给新、旧版本的服务实例分别添加标签信息，例如服务端(旧版本)上所打标签信息为：old_version，在服务端(新版本)上所打标签信息为：new_version，该标签信息用于灰度分流设备判断业务消息发送对象的标识。
步骤5：灰度发布控制平台同步灰度策略给灰度分流设备。
步骤6：灰度发布控制平台给灰度分流LB下发命令，通知灰度分流LB开始灰度发布；
步骤7：灰度分流设按照灰度分流规则进行服务调用，例如根据当前接收到的业务消息，从业务消息的特定字段中解析对应参数，并与白名单列表进行比较，若业务消息中的参数与白名单列表匹配，则需要分发到新版本的服务实例，否则需要分流到旧版本的服务实例。
步骤8：用户可以通过提高分流到新版本的服务实例上的流量来让高版本服务实例承担更多的业务，例如向灰度发布控制平台下发调整分流比例的通知。
步骤9：当灰度发布控制平台接收到提高灰度分流比例的通知后，先调用PaaS接口完成对旧版本服务的缩容，这时被缩容的服务实例会自动释放虚机资源。
步骤10：紧接着调用PaaS接口进行新版本的服务实例的扩容，新扩容的服务实例则占用步骤9中释放的虚机资源。需要说明的是，缩容和扩容操作可以分多次完成，这样每次也不会额外申请过多的冗余虚机资源，业务流量也可以平滑的在高、低版本的服务实例之间迁移。
步骤11、灰度发布控制平台向灰度分流设备发送分流比例。
步骤12：灰度分流设备根据分流比例，将更多的业务流量分流至新版本的服务实例。在整个电信软件应用系统的完整的升级过程，需要用户重复多次调整灰度比例，直至将全部业务流量分流至新版本的服务实例上，从而平滑的完成服务迁移。
步骤13：当业务流量全部切换到高版本服务实例来后，且经过一段时间的稳定运行后，用户可以向灰度发布控制平台发送执行结束灰度发布的指令。灰度发布控制平台接收到指令后，进行一些环境清理动作，包括释放掉多余的虚机资源及删除多余的旧版本的服务包等。
可见，通过灰度分流设备根据白名单及分流比例等灰度发布策略，将业务流量逐步从旧版本的服务实例迁移到新版本的服务实例上，避免在新版本服务的软件质量不稳定情况下， 可能造成整电信软件应用系统故障的风险；同时，通过多批次逐步流量迁移，降低对冗余虚机资源的要求，尤其适用于电信软件应用系统内虚机资源成本占比较高的场景。
上述图1-图4中任一所对应的实施例中出现的任一技术特征，也同样适用于本申请中的图5-图7所对应的实施例，后续类似之处不再赘述。
以上对本申请中一种服务升级管理的方法进行说明，以下分别介绍执行上述服务升级管理的方法的灰度发布控制平台、灰度分流设备。
如图5所示的一种灰度发布控制平台的结构示意图，本申请实施例中的灰度发布控制平台能够实现对应于上述图2-图4中任一所对应的实施例中由灰度发布控制平台所执行的服务升级管理的方法的步骤。所述灰度发布控制平台实现的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，所述模块可以是软件和/或硬件。所述灰度发布控制平台可包括收发模块和处理模块，所述处理模块的功能实现可参考图2-图4中任一所所对应的实施例中由所述灰度发布控制平台执行的各种操作，此处不作赘述。所述收发模块的功能实现可参考图2-图4中任一所所对应的实施例中由灰度发布控制平台执行的各种操作，处理模块可用于控制所述收发模块的收发操作。
一些实施方式中，所述处理模块可用于创建灰度发布策略和灰度分流规则，控制灰度分流状态。
所述收发模块可用于向灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态；
其中，所述灰度发布策略、所述灰度分流规则和所述灰度分流状态用于所述灰度分流设备控制业务消息的流向。
本申请实施例中，灰度发布控制平台中的收发模块向灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态，使得灰度分流设备能够准确的控制业务消息的流向，可以保证电信软件应用系统系统的稳定性，不需要另外部署一套测试环境或者备份环境专门用于发布前的稳定性测试，能够实现VNF的灰度升级能力，保证业务流量的平滑切换及无损升级，并通过试错的方式降低升级风险、提升软件的可靠性，并且不显著增加额外虚机资源。
一些实施方式中，所述灰度分流状态包括：初始状态、结束状态、白名单分流状态和按比例分流状态。
一些实施方式中，所述收发模块向多个灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态之前，所述处理模块还用于：
对待进行灰度发布的业务服务部署第二版本的服务实例；
分别对第一版本的服务实例添加第一标签信息，对第二版本的服务实例添加第二标签信息；其中，所述第一标签信息和所述第二标签信息均用于所述灰度分流设备判断业务消息发送对象的标识，所述第二版本的服务实例的版本高于所述第一版本的服务实例。
一些实施方式中，所述处理模块还用于：
调整分流比例，所述分流比例是指分流业务消息的第一版本的服务实例数量和分流业务消息的第二版本的服务实例数量的比例。
一些实施方式中，所述处理模块用于：
对所述第一版本的服务实例进行缩容，以释放缩容的所述第一版本的服务实例占用的虚拟机资源；以及对所述第二版本的服务实例进行扩容，扩容的第二版本的服务实例占用所述 释放的虚拟机资源；
根据缩容后的所述第一版本的服务实例数量、扩容后的所述第二版本的服务实例数量、以及当前灰度发布任务的最
大分流比例，计算分流比例；
通过所述收发模块向所述灰度分流设备发送所述分流比例。
如图6所示的一种灰度分流设备的结构示意图，本申请实施例中的灰度分流设备能够实现对应于上述图2-图4中任一所对应的实施例中由灰度分流设备所执行的服务升级管理的方法的步骤。灰度分流设备实现的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，所述模块可以是软件和/或硬件。所述灰度分流设备可包括收发模块和处理模块，所述处理模块的功能实现可参考图2-图4中任一所所对应的实施例中由灰度分流设备执行的各种操作，此处不作赘述。所述收发模块的功能实现可参考图2-图4中任一所所对应的实施例中由灰度分流设备执行的各种操作，处理模块可用于控制所述收发模块的收发操作。
一些实施方式中，所述收发模块可用于从灰度发布控制平台接收灰度发布策略、灰度分流规则和灰度分流状态；
处理模块，用于根据所述灰度发布策略、所述灰度分流规则和所述灰度分流状态，控制业务消息的流向。
一些实施方式中，所述灰度分流状态包括：初始状态、结束状态、白名单分流状态和按比例分流状态。
本申请实施例中，灰度分流设备中的收发模块从灰度发布控制平台获取灰度发布策略、所述灰度分流规则和所述灰度分流状态后，灰度分流设备中的处理模块能够准确的控制业务消息的流向，可以保证电信软件应用系统系统的稳定性，不需要另外部署一套测试环境或者备份环境专门用于发布前的稳定性测试，能够实现VNF的灰度升级能力，保证业务流量的平滑切换及无损升级，并通过试错的方式降低升级风险、提升软件的可靠性，并且不显著增加额外虚机资源。
一些实施方式中，所述处理模块至少用于执行以下操作之一：
当所述灰度分流状态为初始状态时，在第一版本的服务实例中按照轮询方式对业务消息的流量分流；
或者，当所述灰度分流状态为结束状态时，对业务消息的流量按照轮询方式分流；
或者，当所述灰度分流状态为白名单分流状态时，根据所述灰度发布策略，将符合所述灰度发布策略的业务消息分流到第二版本的服务实例，将不符合所述灰度发布策略的业务消息在第一版本的服务实例中按照轮询方式进行分流；
或者，当所述灰度分流状态为按比例分流状态时，根据所述灰度发布策略，将符合所述灰度发布策略的业务消息分流到第二版本的服务实例，将不符合所述灰度发布策略的业务消息在第一版本的服务实例或第二版本的服务实例中按照轮询方式进行分流。
一些实施方式中，所述灰度发布策略包括白名单策略，所述处理模块具体用于：
通过所述收发模块获取所述业务消息中的特定字段；
将所述特定字段与所述白名单策略进行匹配；
当根据特定字段与白名单的匹配关系匹配到所述特定字段时，则确定所述业务消息满足 分流到第二版本的服务实例的条件，将所述业务消息分流到第二版本的服务实例上；
当根据所述特定字段与白名单的匹配关系未匹配到所述特定字段时，则确定所述业务消息不满足分流到第二版本的服务实例的条件，将所述业务消息分流到第一版本的服务实例上。
一些实施方式中，所述收发模块还用于：
从所述灰度发布控制平台接收分流比例，所述分流比例是指分流业务消息的第一版本的服务实例数量和分流业务消息的第二版本的服务实例数量的比例；
按照所述分流比例，将所述业务消息分流到所述第二版本的服务实例上；
从所述灰度发布控制平台接收更新的分流比例，按照更新的分流比例控制业务消息的流向，直至将所有业务消息分流到所述第二版本的服务实例上。
图7为本申请实施例提供的灰度发布控制平台或灰度分流设备的另一结构示意图，其中，可包括至少一个处理器、至少一个网络接口或者其它通信接口、存储器、至少一个通信总线、至少一个收发器用于实现这些装置之间的连接通信。上述处理器用于执行上述存储器中存储的可执行模块，例如计算机程序。上述存储器可能包含高速随机存取存储器(英文全称：Random Access Memory，英文简称：RAM)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个网络接口(可以是有线或者无线)实现该系统网关与至少一个其它网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。
如图7所示，在一些实施方式中，上述存储器中存储了程序指令，上述程序指令可以被上述处理器执行，通过调用存储器存储的程序指令，上述处理器具体执行本申请实施例中的业务管理的方法时需要调用的程序代码。
需要说明的是，在本申请各实施例(包括图5和图6所示的各实施例)中所有的收发模块对应的实体设备可以为收发器，所有的处理模块对应的实体设备可以为处理器。图5和图6所示的各装置均可以具有如图7所示的结构，当其中一种装置具有如图7所示的结构时，图7中的处理器和收发器实现前述对应该装置的装置实施例提供的处理模块和收发模块相同或相似的功能，图7中的存储器存储处理器执行上述服务升级管理的方法时需要调用的程序代码。其中，该收发器也可以用接收器和发送器代替，可以为相同或者不同的物理实体。为相同的物理实体时，可以统称为收发器，例如该收发器可以为射频(英文全称：Radio Frequency，英文简称：RF)电路。所述存储器可以集成在所述处理器中，也可以与所述处理器分开设置。
上述本申请各实施例揭示的方法可以应用于图7所示的处理器中，或者由图7所示的处理器实现。例如，在一些实施方式中，图7中的处理器可通过调用存储器存储的程序指令，上述处理器具体执行本申请实施例中的服务升级管理的方法时需要调用的程序代码。
例如，当灰度发布控制平台具有如图7所示的结构时，图7中的存储器存储处理器执行上述由灰度发布控制平台执行服务升级管理的方法时需要调用的程序代码。具体来说，图7中的处理器能够调用存储器中的程序代码执行以下操作：
创建灰度发布策略和灰度分流规则；
控制灰度分流状态；
通过所述收发器向灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态；其中，所述灰度发布策略、所述灰度分流规则和所述灰度分流状态用于所述灰度分流设备控制业务消息的流向。
例如，当灰度分流设备具有如图7所示的结构时，图7中的存储器存储处理器执行上述由灰度分流设备执行服务升级管理的方法时需要调用的程序代码。具体来说，图7中的处理器能够调用存储器中的程序代码执行以下操作：
通过所述收发器从灰度发布控制平台接收灰度发布策略、灰度分流规则和灰度分流状态；
根据所述灰度发布策略、所述灰度分流规则和所述灰度分流状态，控制业务消息的流向。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。
所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
以上对本申请所提供的技术方案进行了详细介绍，本申请中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (23)

  1. 一种服务升级管理的方法，应用于灰度发布控制平台，其特征在于，所述方法包括：
    创建灰度发布策略和灰度分流规则；
    控制灰度分流状态；
    向灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态；
    其中，所述灰度发布策略、所述灰度分流规则和所述灰度分流状态用于所述灰度分流设备控制业务消息的流向。
  2. 根据权利要求1所述的方法，其特征在于，所述灰度分流状态包括：初始状态、结束状态、白名单分流状态和按比例分流状态。
  3. 根据权利要求1或2所述的方法，其特征在于，所述向多个灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态之前，所述方法还包括：
    对待进行灰度发布的业务服务部署第二版本的服务实例；
    分别对第一版本的服务实例添加第一标签信息，对第二版本的服务实例添加第二标签信息；其中，所述第一标签信息和所述第二标签信息均用于所述灰度分流设备判断业务消息发送对象的标识，所述第二版本的服务实例的版本高于所述第一版本的服务实例。
  4. 根据权利要求3所述的方法，其特征在于，所述方法还包括：
    调整分流比例，所述分流比例是指分流业务消息的第一版本的服务实例数量和分流业务消息的第二版本的服务实例数量的比例。
  5. 根据权利要求4所述的方法，其特征在于，所述调整分流比例，包括：
    对所述第一版本的服务实例进行缩容，以释放缩容的所述第一版本的服务实例占用的虚拟机资源；以及对所述第二版本的服务实例进行扩容，扩容的第二版本的服务实例占用所述释放的虚拟机资源；
    根据缩容后的所述第一版本的服务实例数量、扩容后的所述第二版本的服务实例数量、以及当前灰度发布任务的最大分流比例，计算分流比例；
    所述方法还包括：
    向所述灰度分流设备发送所述分流比例。
  6. 根据权利要求1-5中任一项所述的方法，其特征在于，所述业务消息包括特定字段，发送业务消息之前，所述方法还包括：
    建立白名单与所述业务消息中的特定字段的匹配关系；
    向所述灰度分流设备发送所述匹配关系。
  7. 一种服务升级管理的方法，应用于灰度分流设备，其特征在于，所述方法包括：
    从灰度发布控制平台接收灰度发布策略、灰度分流规则和灰度分流状态；
    根据所述灰度发布策略、所述灰度分流规则和所述灰度分流状态，控制业务消息的流向。
  8. 根据权利要求7所述的方法，其特征在于，所述灰度分流状态包括：初始状态、结束状态、白名单分流状态和按比例分流状态。
  9. 根据权利要求8所述的方法，其特征在于，所述根据所述灰度发布策略、所述灰度分流规则和所述灰度分流状态，控制业务消息流量的流向，至少包括以下实现方式之一：
    当所述灰度分流状态为初始状态时，在第一版本的服务实例中按照轮询方式对业务消息 的流量分流；
    或者，当所述灰度分流状态为结束状态时，对业务消息的流量按照轮询方式分流；
    或者，当所述灰度分流状态为白名单分流状态时，根据所述灰度发布策略，将符合所述灰度发布策略的业务消息分流到第二版本的服务实例，将不符合所述灰度发布策略的业务消息在第一版本的服务实例中按照轮询方式进行分流；
    或者，当所述灰度分流状态为按比例分流状态时，根据所述灰度发布策略，将符合所述灰度发布策略的业务消息分流到第二版本的服务实例，将不符合所述灰度发布策略的业务消息在第一版本的服务实例或第二版本的服务实例中按照轮询方式进行分流。
  10. 根据权利要求9所述的方法，其特征在于，所述灰度发布策略包括白名单策略，所述根据所述灰度发布策略，将符合所述灰度发布策略的业务消息分流到第二版本的服务实例，包括：
    获取所述业务消息中的特定字段；
    将所述特定字段与所述白名单策略进行匹配；
    当根据特定字段与白名单的匹配关系匹配到所述特定字段时，则确定所述业务消息满足分流到第二版本的服务实例的条件，将所述业务消息分流到第二版本的服务实例上；
    当根据所述特定字段与白名单的匹配关系未匹配到所述特定字段时，则确定所述业务消息不满足分流到第二版本的服务实例的条件，将所述业务消息分流到第一版本的服务实例上。
  11. 根据权利要求7所述的方法，其特征在于，所述方法还包括：
    从所述灰度发布控制平台接收分流比例，所述分流比例是指分流业务消息的第一版本的服务实例数量和分流业务消息的第二版本的服务实例数量的比例；
    按照所述分流比例，将所述业务消息分流到所述第二版本的服务实例上；
    从所述灰度发布控制平台接收更新的分流比例，按照更新的分流比例控制业务消息的流向，直至将所有业务消息分流到所述第二版本的服务实例上。
  12. 一种灰度发布控制平台，其特征在于，所述灰度发布控制平台包括：
    处理模块，用于创建灰度发布策略和灰度分流规则；
    控制灰度分流状态；
    收发模块，用于向灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态；
    其中，所述灰度发布策略、所述灰度分流规则和所述灰度分流状态用于所述灰度分流设备控制业务消息的流向。
  13. 根据权利要求12所述的灰度发布控制平台，其特征在于，所述灰度分流状态包括：初始状态、结束状态、白名单分流状态和按比例分流状态。
  14. 根据权利要求12或13所述的灰度发布控制平台，其特征在于，所述收发模块向多个灰度分流设备下发所述灰度发布策略、所述灰度分流规则和所述灰度分流状态之前，所述处理模块还用于：
    对待进行灰度发布的业务服务部署第二版本的服务实例；
    分别对第一版本的服务实例添加第一标签信息，对第二版本的服务实例添加第二标签信息；其中，所述第一标签信息和所述第二标签信息均用于所述灰度分流设备判断业务消息发送对象的标识，所述第二版本的服务实例的版本高于所述第一版本的服务实例。
  15. 根据权利要求14所述的灰度发布控制平台，其特征在于，所述处理模块还用于：
    调整分流比例，所述分流比例是指分流业务消息的第一版本的服务实例数量和分流业务消息的第二版本的服务实例数量的比例。
  16. 根据权利要求15所述的灰度发布控制平台，其特征在于，所述处理模块用于：
    对所述第一版本的服务实例进行缩容，以释放缩容的所述第一版本的服务实例占用的虚拟机资源；以及对所述第二版本的服务实例进行扩容，扩容的第二版本的服务实例占用所述释放的虚拟机资源；
    根据缩容后的所述第一版本的服务实例数量、扩容后的所述第二版本的服务实例数量、以及当前灰度发布任务的最
    大分流比例，计算分流比例；
    通过所述收发模块向所述灰度分流设备发送所述分流比例。
  17. 一种灰度分流设备，其特征在于，所述灰度分流设备包括：
    收发模块，用于从灰度发布控制平台接收灰度发布策略、灰度分流规则和灰度分流状态；
    处理模块，用于根据所述灰度发布策略、所述灰度分流规则和所述灰度分流状态，控制业务消息的流向。
  18. 根据权利要求17所述的灰度分流设备，其特征在于，所述处理模块至少用于执行以下操作之一：
    当所述灰度分流状态为初始状态时，在第一版本的服务实例中按照轮询方式对业务消息的流量分流；
    或者，当所述灰度分流状态为结束状态时，对业务消息的流量按照轮询方式分流；
    或者，当所述灰度分流状态为白名单分流状态时，根据所述灰度发布策略，将符合所述灰度发布策略的业务消息分流到第二版本的服务实例，将不符合所述灰度发布策略的业务消息在第一版本的服务实例中按照轮询方式进行分流；
    或者，当所述灰度分流状态为按比例分流状态时，根据所述灰度发布策略，将符合所述灰度发布策略的业务消息分流到第二版本的服务实例，将不符合所述灰度发布策略的业务消息在第一版本的服务实例或第二版本的服务实例中按照轮询方式进行分流。
  19. 根据权利要求18所述的灰度分流设备，其特征在于，所述灰度发布策略包括白名单策略，所述处理模块具体用于：
    通过所述收发模块获取所述业务消息中的特定字段；
    将所述特定字段与所述白名单策略进行匹配；
    当根据特定字段与白名单的匹配关系匹配到所述特定字段时，则确定所述业务消息满足分流到第二版本的服务实例的条件，将所述业务消息分流到第二版本的服务实例上；
    当根据所述特定字段与白名单的匹配关系未匹配到所述特定字段时，则确定所述业务消息不满足分流到第二版本的服务实例的条件，将所述业务消息分流到第一版本的服务实例上。
  20. 根据权利要求17所述的灰度分流设备，其特征在于，所述收发模块还用于：
    从所述灰度发布控制平台接收分流比例，所述分流比例是指分流业务消息的第一版本的服务实例数量和分流业务消息的第二版本的服务实例数量的比例；
    按照所述分流比例，将所述业务消息分流到所述第二版本的服务实例上；
    从所述灰度发布控制平台接收更新的分流比例，按照更新的分流比例控制业务消息的流向，直至将所有业务消息分流到所述第二版本的服务实例上。
  21. 一种灰度发布控制平台，其特征在于，所述灰度发布控制平台包括：
    至少一个处理器、存储器和收发器；
    其中，所述存储器用于存储程序代码，所述处理器用于调用所述存储器中存储的程序代码来执行如权利要求1-6任一项所述的方法。
  22. 一种灰度分流设备，其特征在于，所述灰度分流设备包括：
    至少一个处理器、存储器和收发器；
    其中，所述存储器用于存储程序代码，所述处理器用于调用所述存储器中存储的程序代码来执行如权利要求7-11任一项所述的方法。
  23. 一种计算机存储介质，其特征在于，其包括指令，当其在计算机上运行时，使得计算机执行如权利要求1-6任一所述的方法，或者执行如权利要求7-11任一项所述的方法。
PCT/CN2019/078286 2018-03-26 2019-03-15 一种服务升级管理的方法、装置及存储介质 WO2019184727A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP19774314.9A EP3758293A4 (en) 2018-03-26 2019-03-15 PROCEDURE, DEVICE, AND STORAGE MEDIUM FOR SERVICE UPGRADE
US17/032,536 US20210011834A1 (en) 2018-03-26 2020-09-25 Service Upgrade Management Method, Apparatus, And Storage Medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810253849.8A CN110365502B (zh) 2018-03-26 2018-03-26 一种服务升级管理的方法、装置及存储介质
CN201810253849.8 2018-03-26

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/032,536 Continuation US20210011834A1 (en) 2018-03-26 2020-09-25 Service Upgrade Management Method, Apparatus, And Storage Medium

Publications (1)

Publication Number Publication Date
WO2019184727A1 true WO2019184727A1 (zh) 2019-10-03

Family

ID=68060857

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/078286 WO2019184727A1 (zh) 2018-03-26 2019-03-15 一种服务升级管理的方法、装置及存储介质

Country Status (4)

Country Link
US (1) US20210011834A1 (zh)
EP (1) EP3758293A4 (zh)
CN (1) CN110365502B (zh)
WO (1) WO2019184727A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111399875A (zh) * 2020-03-06 2020-07-10 咪咕文化科技有限公司 灰度升级控制方法、装置、电子设备及存储介质
CN111431818A (zh) * 2020-02-28 2020-07-17 口碑(上海)信息技术有限公司 跨域请求的流量分配方法、装置、存储介质及计算机设备
CN111752597A (zh) * 2020-06-29 2020-10-09 深圳前海微众银行股份有限公司 业务的灰度发布方法、装置、设备及计算机可读存储介质
CN114579162A (zh) * 2022-05-07 2022-06-03 杭州又拍云科技有限公司 一种基于事件驱动和水平触发的灰度发布方法

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110781013B (zh) * 2019-10-25 2022-11-18 湖南水羊科技有限公司 一种灰度发布方法、装置、设备及介质
CN111767073A (zh) * 2019-12-04 2020-10-13 北京沃东天骏信息技术有限公司 发布灰度的方法、装置、设备和计算机可读介质
CN111488159A (zh) * 2019-12-20 2020-08-04 杭州当虹科技股份有限公司 一种能够动态配置的灰度发布方法
CN113127023B (zh) * 2019-12-31 2024-04-09 华为技术有限公司 业务升级的方法、装置和系统
CN111338824B (zh) * 2020-02-27 2023-08-15 中国联合网络通信集团有限公司 灰度发布方法、装置、电子设备及存储介质
CN111290867A (zh) * 2020-02-27 2020-06-16 北京三快在线科技有限公司 流量调度方法、业务服务器、存储介质及流量调度系统
CN111585805B (zh) * 2020-04-30 2023-04-18 中国平安财产保险股份有限公司 平滑发布升级方法、装置、计算机系统及可读存储介质
CN111638885A (zh) * 2020-05-29 2020-09-08 北京金山云网络技术有限公司 一种插件的发布方法、装置、电子设备及存储介质
CN113805909B (zh) * 2020-06-17 2024-04-16 菜鸟智能物流控股有限公司 设备升级方法、装置、电子设备和存储介质
CN112187662B (zh) * 2020-09-16 2023-03-28 银盛支付服务股份有限公司 一种基于Apollo的流量分发方法
CN112130892A (zh) * 2020-09-23 2020-12-25 平安科技（深圳）有限公司 产品灰度发布方法、装置、设备及存储介质
CN112269591A (zh) * 2020-11-11 2021-01-26 北京凌云雀科技有限公司 版本发布方法、装置、设备及存储介质
CN112565406B (zh) * 2020-12-01 2023-11-03 中国人寿保险股份有限公司 一种灰度发布方法、灰度发布系统及电子设备
CN112905210B (zh) * 2021-03-24 2023-09-15 青岛聚看云科技有限公司 服务器及灰度发布方法
CN112835604B (zh) * 2021-03-26 2024-03-29 中国工商银行股份有限公司 系统灰度版本发布管理方法、系统、设备和介质
CN113422732A (zh) * 2021-06-22 2021-09-21 康键信息技术（深圳）有限公司 基于全站灰度的版本更新方法、装置、设备及存储介质
CN113452622A (zh) * 2021-06-29 2021-09-28 上海通联金融服务有限公司 一种基于客户端的灰度分流方法
CN114726919B (zh) * 2022-03-22 2024-02-13 新华三大数据技术有限公司 灰度流量控制的方法、装置、计算机设备及存储介质
CN114884915B (zh) * 2022-04-19 2024-03-26 阿里巴巴（中国）有限公司 基于灰度发布的消息处理方法、装置以及设备
CN115022174B (zh) * 2022-06-20 2024-03-26 北京奇艺世纪科技有限公司 一种请求处理方法、装置、可读存储介质及电子设备
CN115408285B (zh) * 2022-08-31 2023-06-20 北京发现角科技有限公司 一种灰度测试方法、装置、电子设备及存储介质
CN115168162B (zh) * 2022-09-08 2022-12-06 江苏博云科技股份有限公司 容器环境基于ingress控制器多灰度发布方法、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103095743A (zh) * 2011-10-28 2013-05-08 阿里巴巴集团控股有限公司 一种灰度发布的处理方法及系统
CN103176790A (zh) * 2011-12-26 2013-06-26 阿里巴巴集团控股有限公司 应用发布方法和系统
CN105791341A (zh) * 2014-12-22 2016-07-20 华为软件技术有限公司 一种应用发布的处理方法、装置及系统
CN105955761A (zh) * 2016-06-30 2016-09-21 乐视控股（北京）有限公司 基于docker的灰度发布装置及方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10560372B1 (en) * 2017-08-28 2020-02-11 Amazon Technologies, Inc. Request routing based on server software versions

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103095743A (zh) * 2011-10-28 2013-05-08 阿里巴巴集团控股有限公司 一种灰度发布的处理方法及系统
CN103176790A (zh) * 2011-12-26 2013-06-26 阿里巴巴集团控股有限公司 应用发布方法和系统
CN105791341A (zh) * 2014-12-22 2016-07-20 华为软件技术有限公司 一种应用发布的处理方法、装置及系统
CN105955761A (zh) * 2016-06-30 2016-09-21 乐视控股（北京）有限公司 基于docker的灰度发布装置及方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3758293A4

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111431818A (zh) * 2020-02-28 2020-07-17 口碑(上海)信息技术有限公司 跨域请求的流量分配方法、装置、存储介质及计算机设备
CN111431818B (zh) * 2020-02-28 2023-06-09 口碑(上海)信息技术有限公司 跨域请求的流量分配方法、装置、存储介质及计算机设备
CN111399875A (zh) * 2020-03-06 2020-07-10 咪咕文化科技有限公司 灰度升级控制方法、装置、电子设备及存储介质
CN111399875B (zh) * 2020-03-06 2023-09-05 咪咕文化科技有限公司 灰度升级控制方法、装置、电子设备及存储介质
CN111752597A (zh) * 2020-06-29 2020-10-09 深圳前海微众银行股份有限公司 业务的灰度发布方法、装置、设备及计算机可读存储介质
CN111752597B (zh) * 2020-06-29 2024-02-27 深圳前海微众银行股份有限公司 业务的灰度发布方法、装置、设备及计算机可读存储介质
CN114579162A (zh) * 2022-05-07 2022-06-03 杭州又拍云科技有限公司 一种基于事件驱动和水平触发的灰度发布方法

Also Published As

Publication number Publication date
CN110365502B (zh) 2021-04-09
EP3758293A4 (en) 2021-08-25
EP3758293A1 (en) 2020-12-30
CN110365502A (zh) 2019-10-22
US20210011834A1 (en) 2021-01-14

Similar Documents

Publication Publication Date Title
WO2019184727A1 (zh) 一种服务升级管理的方法、装置及存储介质
US11146453B2 (en) Method and apparatus for creating network slice, and communications system
US10523529B2 (en) Method and apparatus for deploying network service
US10742502B2 (en) Software modification initiation method, and metadata release method and apparatus
JP6834033B2 (ja) ネットワークスライス管理方法、ユニット、及びシステム
US10924966B2 (en) Management method, management unit, and system
CN110720091B (zh) 用于与托管的应用/虚拟网络功能(vnf)协调基础设施升级的方法
CN107959582B (zh) 一种切片实例的管理方法及装置
WO2020186911A1 (zh) 一种容器化虚拟网络功能vnf的资源管理方法及装置
KR102288521B1 (ko) 블록체인 기반의 데이터 저장 장치 및 방법
WO2016121834A1 (ja) ネットワーク機能仮想化管理方法とシステムと装置とプログラム
WO2017066931A1 (zh) 网络功能虚拟化架构中证书的管理方法及装置
EP3584998A1 (en) Method for virtual machine capacity expansion and reduction and virtual management device
WO2019100266A1 (zh) 移动边缘主机服务通知方法和装置
US20210289435A1 (en) Virtualization management method and apparatus
CN106856438B (zh) 一种网络业务实例化的方法、装置及nfv系统
WO2015127850A1 (zh) 一种数据升级的方法和中心服务器
WO2020093976A1 (zh) 一种资源变更的方法及装置、设备、存储介质
WO2016183832A1 (zh) 一种网络业务实例化的方法及设备
CN113300866B (zh) 节点能力管控方法、设备、系统及存储介质
WO2021027689A1 (zh) 一种基于网络功能虚拟化的版本升级的方法及设备
CN116724543A (zh) 容器集群的管理方法和装置
CN114070889B (zh) 配置方法、流量转发方法、设备、存储介质及程序产品
WO2017206092A1 (zh) 一种生命周期管理方法及管理单元
CN107147712B (zh) 更新网络应用程序的方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19774314

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019774314

Country of ref document: EP

Effective date: 20200923