Configuration item changing method and device, equipment and cluster

By changing the configuration item to run on the computing device, verifying and updating the configuration items of the target service, the operational exceptions that occur after the single-body application/microservice call the configuration items in the production environment are solved, and the stability and reliability of the system are improved.

CN119902816APending Publication Date: 2025-04-29HUAWEI CLOUD COMPUTING TECHNOLOGIES CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202410121652.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2023-10-25
Filing Date
2024-01-29
Publication Date
2025-04-29

AI Technical Summary

Technical Problem

In a production environment, abnormal situations such as running errors and crashes often occur after a single application/microservice call configuration item, which affects the user experience.

Method used

Provides a configuration item change method, by which the computing device receives a change request when running the target version of the target service, verify whether the target version supports the use of the target configuration item, and change its value to a specified value if supported.

Benefits of technology

It effectively avoids the risks caused by the current version not supporting the use of target configuration items, and improves the operation stability and reliability of single-unit applications/microservices.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119902816A_ABST
    Figure CN119902816A_ABST
Patent Text Reader

Abstract

The invention discloses a configuration item changing method and device, equipment and a cluster, and relates to the technical field of computers. In the method, a target version of the micro-service runs on the computing device, and the target version is configured with a target configuration item. And after receiving a change request of the target configuration item, the computing device determines whether the target version supports use of the target configuration item, and if the target version supports use of the target configuration item, the computing device changes the value of the target configuration item to a second value. The change request is executed only when the current version (namely the target version) operated by the computing equipment supports the use of the target configuration item, so that risks (such as operation abnormality and the like) caused by the fact that the current version does not support the use of the target configuration item are avoided, the operation abnormality of the target service calling configuration item can be avoided, and the user experience is improved. And thus, the operation stability and reliability of the target service can be improved.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on October 25, 2023, with application number 202311393629.2 and application name “Service configuration method, apparatus, computing device cluster and storage medium”, all contents of which are incorporated by reference in this application. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to a configuration item change method, apparatus, device and cluster. Background Art

[0003] Currently, monolithic applications / microservices usually have many configuration items to indicate the different business logics of the monolithic applications / microservices. However, in the production environment, after the monolithic applications / microservices call the configuration items, abnormal situations such as operation errors and crashes often occur, which prevents users from using the monolithic applications / microservices normally, seriously affecting the user experience.

[0004] Therefore, how to avoid operational anomalies after monolithic applications / microservices call configuration items has become a technical problem that needs to be solved urgently. Summary of the invention

[0005] The present application provides a configuration item change method, apparatus, device and cluster, which helps to avoid exceptions after a single application / microservice calls a configuration item, thereby helping to improve the operating stability and reliability of the single application / microservice.

[0006] In order to achieve the above objectives, this application adopts the following technical solutions:

[0007] In a first aspect, a configuration item change method is provided, which is applied to a computing device, wherein the computing device is used to run a target version of a target service, the target version is configured with a target configuration item, and the value of the target configuration item is a first value; the target configuration item is used to configure a software function of the target service, or the target configuration item is used to turn on or off the software function of the target service; the target service includes a single application or a microservice; the method includes: when the computing device runs the target version of the target service, receiving a change request, the change request is used to request a change of the target configuration item; the computing device verifies whether the target version supports the use of the target configuration item and obtains a verification result; when the verification result indicates that the target version supports the use of the target configuration item, the computing device changes the value of the target configuration item to a second value.

[0008] In this solution, a target version of a target service is running on a computing device, and the target version is configured with a target configuration item, and the value of the target configuration item is a first value. On this basis, when the computing device runs the target version of the target service, if a target configuration item change request is received, it verifies whether the target version supports the use of the target configuration item to obtain a verification result. When the verification result indicates that the target version supports the use of the target configuration item, the computing device changes the value of the target configuration item to a second value. Since the change request is executed only when the current version (i.e., the target version) running on the computing device supports the use of the target configuration item, the risk (such as operation abnormality, etc.) caused by the current version not supporting the use of the target configuration item is avoided, thereby helping to avoid operation abnormalities when the target service calls the configuration item, and further helping to improve the operation stability and reliability of the target service.

[0009] In addition, since the target service can be a monolithic application or a microservice, this solution can be used to manage configuration items of monolithic applications as well as configuration items for managing microservices, which increases the scope of application of configuration item change methods. In addition, after performing version upgrades and rollbacks on the target service, when the operation and maintenance personnel request to change the configuration items, the solution verifies the changed target configuration items, which helps to effectively control the risks caused by the changes in the target configuration items, and thus helps to improve the operational stability of the target service after version upgrades and rollbacks.

[0010] In a possible implementation, the target version includes a first business logic indicated by a first value and a second business logic indicated by a second value; after the computing device changes the value of the target configuration item to the second value, the method further includes: the computing device runs a first test case to obtain a test result of the first test case; the first test case is used to indicate the running of the second business logic, and the test result of the first test case is used to indicate whether the second business logic has passed the test or failed the test; when the test result of the first test case indicates that the second business logic has failed the test, the computing device changes the value of the target configuration item to the first value. In this way, it is helpful to eliminate the risks caused by changing the target configuration item in a timely manner, thereby helping to avoid affecting the user's use of the target service, and further helping to improve the user's experience.

[0011] In another possible implementation, the method further includes: when the test result of the first test case indicates that the second business logic fails the test, the computing device deletes the first value in the value range of the target configuration item. This helps to avoid the subsequent change of the value of the target configuration item to the first value, thereby helping to improve the operation stability and reliability of the target service.

[0012] In a possible implementation, the computing device verifies whether the target version supports the use of the target configuration item, and obtains the verification result, including: the computing device determines the version range corresponding to the target configuration item; the version range is used to indicate the service version that supports the use of the target configuration item; when the version range includes the target version, the computing device determines that the verification result indicates that the target version supports the use of the target configuration item; or when the version range does not include the target version, the computing device determines that the verification result indicates that the target version does not support the use of the target configuration item. In this way, it is not only helpful to ensure the accuracy of the content indicated by the verification result, but also helpful to improve the speed of determining the verification result.

[0013] In another possible implementation, the method further includes: when the version range does not include the target version, the computing device runs a first version of the target service; and the first version is selected from the version range.

[0014] In this implementation, by running the first version included in the version range, that is, running the version that supports the use of the target configuration item, not only can the target configuration item be called, but it also helps to improve the operating stability and reliability of the target service after calling the target configuration item.

[0015] In another possible implementation, when the version range includes the target version, the computing device determines that the verification result indicates that the target version supports the use of the target configuration item, including: when the version range includes the target version, the computing device determines the version status of the target version; the version status is used to indicate that the verified version range includes the target version or the unverified version range includes the target version; when the version status indicates that the verified version range includes the target version, the computing device determines that the verification result indicates that the target version supports the use of the target configuration item. This helps to improve the accuracy and reliability of the verification result.

[0016] In another possible implementation, the method further includes: when the version status indicates that the unverified version range includes the target version, the computing device determines that the verification result indicates that the target version does not support the use of the target configuration item. This helps to improve the accuracy and reliability of the verification result.

[0017] In another possible implementation, the method also includes: when the version status of the target version indicates that the unverified version range includes the target version, the computing device runs a second version of the target service, and / or deletes the target version in the version range; the second version is selected from the version range, and the version status of the second version indicates that the verified version range includes the second version.

[0018] In this implementation, by running the second version included in the version range, and the version status indication of the second version is verified, not only can the target configuration item be called, but it also helps to improve the operating stability and reliability of the target service after calling the target configuration item.

[0019] In another possible implementation, the version range includes a version set or a third version; the version set includes at least one service version, and each service version in the at least one service version supports the use of the target configuration item; the third version is used to indicate the minimum service version that supports the use of the target configuration item. In this way, it not only helps to improve the diversity of the version range, but also allows different types of range versions to be selected for configuration items with different risk levels, thereby helping to improve the matching degree between the version range and the risk level of the configuration item.

[0020] In another possible implementation, when the management mode of the target configuration item is a strict mode, the version range includes a version set; when the management mode of the target configuration item is a non-strict mode, the version range includes the third version.

[0021] In this implementation, by corresponding different management modes to different types of version ranges, different types of version ranges are determined according to the management mode, which helps to match the determined version range with the risk level of the target configuration item.

[0022] In another possible implementation, the computing device determines the version range corresponding to the target configuration item, including: the computing device determines the environment type of the target service; the environment type includes a production environment or a non-production environment; if the environment type of the target service is a production environment, the computing device determines the version range corresponding to the target configuration item.

[0023] In this implementation, the environment type is determined before the verification result is determined, which helps avoid verifying the target configuration items in the change request in a non-production environment, thereby helping to ensure the necessity and effectiveness of the verification operation and avoid performing invalid operations that affect the normal configuration item change process.

[0024] In another possible implementation, the method further includes: when the verification result indicates that the target version does not support the use of the target configuration item, the computing device returns first prompt information based on the change request; the first prompt information is used to indicate that the target version does not support the use of the target configuration item.

[0025] In this implementation, by returning the first prompt information, the operation and maintenance personnel can understand the reason why the configuration target configuration item is not supported, which helps the operation and maintenance personnel to adjust the change strategy in time, and further helps the operation and maintenance personnel to better manage the target service.

[0026] In another possible implementation, when the verification result indicates that the target version supports the use of the target configuration item, the computing device changes the value of the target configuration item to a second value, including: when the verification result indicates that the target version supports the use of the target configuration item, the computing device determines the value range of the target configuration item; when the value range of the target configuration item includes the second value, the computing device changes the value of the target configuration item to the second value.

[0027] In this implementation, the target configuration item is changed only when the value range of the target configuration item includes the first value, which helps to avoid the target configuration item affecting the operating stability of the target service due to an inappropriate value.

[0028] In another possible implementation, the method further includes: when the value range of the target configuration item does not include the second value, the computing device returns second prompt information based on the change request; the second prompt information is used to indicate that the value range of the target configuration item does not include the first value.

[0029] In this implementation, when the value range of the target configuration item does not include the first value, the second prompt information is returned, which helps the operation and maintenance personnel to promptly understand the reason why the target configuration item cannot be changed.

[0030] In another possible implementation, the computing device verifies whether the target version supports the use of the target configuration item, and obtains the verification result, including: the computing device determines the target identification range corresponding to the target version, the target identification range is used to indicate the configuration items supported by the target version; when the target identification range includes the identification of the target configuration item, the computing device determines that the verification result indicates that the target version supports the use of the target configuration item; or when the target identification range does not include the identification of the target configuration, the computing device determines that the verification result indicates that the target version does not support the use of the target configuration item. In this implementation, the verification result is determined by whether the target identification range corresponding to the target version includes the identification of the target configuration item, which not only improves the diversity of the methods for determining the verification result, but also improves the efficiency of determining the verification result. In another possible implementation, before receiving the change request, the method further includes: the computing device runs a second test case to obtain the test result of the second test case; the second test case is used to indicate the target business logic of the target version, the target business logic includes the business logic indicated by the target configuration item, and the test result of the second test case is used to indicate whether the target configuration item passes the test; when the test result of the second test case indicates that the target configuration item passes the test, the computing device updates the version range corresponding to the target configuration item, and the updated version range includes the target version.

[0031] In this implementation, by running the second test case, the business logic indicated by the target configuration item (i.e., the target business logic in the target version) is run, thereby testing whether the target version supports the use of the target configuration item. On this basis, if the test result of the second test case indicates that the target configuration item passes the test, the computing device updates the version range corresponding to the target configuration item so that the updated version range includes the target version, so that the version range corresponding to the target configuration item can be used to indicate whether the target version supports the use of the target configuration item, thereby verifying the target configuration item in the change request according to the version range corresponding to the target configuration item, so as to ensure the validity and stability of the target configuration item in the target version, and avoid the change of the target configuration item that has not been verified to take effect.

[0032] In another possible implementation, the version range includes a version set or a third version; the version range corresponding to the target configuration item updated by the computing device includes: based on the target configuration item's management mode being a strict mode, the computing device updates the version set corresponding to the target configuration item; the updated version set includes the target version; based on the target configuration item's management mode being a non-strict mode and the target configuration item's corresponding third version not including the target version, the computing device updates the target configuration item's corresponding third version, and the updated third version includes the target version. This helps to improve the accuracy of the update.

[0033] In another possible implementation, the method further includes: when the test result of the second test case indicates that the target configuration item has passed the test, the computing device sets the version status of the target version to indicate that the verified version range includes the target version.

[0034] In this implementation, by setting the target configuration item to pass the test, the version status is modified to indicate verified, which helps to ensure the accuracy of the version status indication content, and further helps to ensure the accuracy of subsequent verification results.

[0035] In another possible implementation, the computing device runs the third test case to obtain the test result of the third test case; the third test case is used to test the target version, and the test result of the third test case is used to indicate whether the target version has passed the test or not; when the test result of the third test case indicates that the target version has passed the test, and the test result of the second test case indicates that the target configuration item has passed the test, the computing device determines that the test result of the target version is passed. This helps to avoid the target version passing the test when the target version does not support the use of the target configuration item, thereby avoiding the target version that does not support the use of the target configuration item from being provided to the user, affecting the user's experience.

[0036] In a second aspect, a configuration item change device is provided, the device comprising: a functional unit for executing any one of the methods provided in the first aspect, the actions performed by each functional unit are implemented by hardware or by hardware executing corresponding software. For example, the configuration item change device may include: a receiving module, a verification module and a change module; the receiving module is used to receive a change request when the computing device runs the target version of the target service, the change request is used to request to change the target configuration item; the verification module is used to verify whether the target version supports the use of the target configuration item and obtain a verification result; the change module is used to change the value of the target configuration item to a second value when the verification result indicates that the target version supports the use of the target configuration item.

[0037] According to a third aspect, a processor is provided, which can be used to execute any one of the methods provided in the first aspect.

[0038] In a fourth aspect, a chip is provided, comprising: a processor and a power supply circuit; the power supply circuit can be used to supply power to the chip; and the processor can be used to execute any one of the methods provided in the first aspect above.

[0039] In a fifth aspect, a computing device is provided, comprising a processor, a memory, and a computer program / instructions stored in the memory; the processor executes the computer program to enable the computing device to perform the steps of any one of the methods provided in the first aspect above.

[0040] In a sixth aspect, a computing device cluster is provided, comprising: at least one computing device, each computing device in the at least one computing device comprises a processor and a memory; each computing device comprises a processor, a memory and a computer program / instructions stored on the memory; the processor executes the computer program / instructions so that the computing device cluster implements the steps of any one of the methods provided in the first aspect above.

[0041] In a seventh aspect, a computer program product comprising instructions is provided, including a computer program / instructions, which, when executed by a processor, implements the steps of any one of the methods provided in the first aspect above.

[0042] In an eighth aspect, a computer-readable storage medium is provided, on which a computer program / instruction is stored. When the computer program / instruction is executed by a processor, the steps of any one of the methods provided in the first aspect are implemented.

[0043] Among them, the technical effects brought about by any implementation method in the second to eighth aspects can refer to the technical effects brought about by different implementation methods in the above-mentioned first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1A system architecture diagram of a production environment provided in an embodiment of the present application;

[0045] Figure 2 A system architecture diagram of a test environment provided in an embodiment of the present application;

[0046] Figure 3 A system architecture diagram of a pre-release environment provided for an embodiment of the present application;

[0047] Figure 4 A flowchart of a configuration item change method provided in an embodiment of the present application;

[0048] Figure 5 A flowchart of a configuration item testing method provided in an embodiment of the present application;

[0049] Figure 6 A schematic diagram of the life cycle of a configuration item provided in an embodiment of the present application;

[0050] Figure 7 A test process diagram of a configuration item provided in an embodiment of the present application;

[0051] Figure 8 A configuration item change process diagram provided in an embodiment of the present application;

[0052] Fig. 9 A schematic diagram of a configuration item changing device provided in an embodiment of the present application;

[0053] Fig.10 A schematic diagram of a computing device provided in an embodiment of the present application;

[0054] Fig.11 A schematic diagram of a computing device cluster provided in an embodiment of the present application;

[0055] Fig.12 A connection diagram of a computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0056] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0057] In the description of this application, unless otherwise specified, " / " indicates that the objects associated with each other are in an "or" relationship, for example, A / B can represent A or B; "and / or" in this application is merely a description of the association relationship between associated objects, indicating that three relationships may exist, for example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural.

[0058] Furthermore, in the description of this application, unless otherwise specified, "plurality" means two or more than two. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0059] In addition, in order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first", "second" and the like are used to distinguish the same items or similar items with substantially the same functions and effects. Those skilled in the art will understand that the words "first", "second" and the like do not limit the quantity and execution order, and the words "first", "second" and the like do not necessarily limit the differences. At the same time, in the embodiments of the present application, the words "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or design solutions. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.

[0060] The following is a brief introduction to the relevant terms involved in the embodiments of the present application.

[0061] Monolithic Application Architecture: It can also be called Monolithic Architecture, Monolithic Application Architecture, etc. It is a software architecture pattern used to develop, deploy and manage a complete application as a single, executable unit. In the Monolithic Application Architecture, all functional modules and components of the application are packaged together and share the same database and code base. Among them, the application developed based on the Monolithic Application Architecture can be called a Monolithic Application or Monolithic Service.

[0062] Microservices Architecture: is a software architecture pattern used to split a monolithic application into multiple sub-services. Each sub-service covers an independent service scope. A single sub-service can run in a single process. Different sub-services can communicate with each other, such as through the Hypertext Transfer Protocol (HTTP). In addition, each sub-service can be independently developed, deployed, and managed. Among them, the sub-services of an application developed based on the microservice architecture can be called microservices.

[0063] Configuration Item: Also called configuration, it can be used to indicate the business logic in a single application / microservice. Different values ​​of configuration items can be used to indicate different business logic in the source code of a single application / microservice. For example, a single application / microservice can read configuration items during startup and operation to determine the business logic to be executed.

[0064] It should be noted that in the embodiments of the present application, the configuration items can be used to configure the software functions of the single application / microservice, turn on or off the software functions of the single application / microservice, etc.

[0065] Configuration center: A system used to centrally manage configuration items. Since configuration items are stored in the code base together with the source code of the single application / microservice, it is not only easy to cause configuration item leakage, but also the single application / microservice needs to be restarted when the configuration item is changed for the changed configuration item to take effect. Based on this, in order to ensure the security of configuration items and dynamically change configuration items, the relevant technology proposes to dynamically manage configuration items through a configuration center.

[0066] Grayscale testing: It can also be called grayscale verification. It refers to a testing method in which a specific group of people are selected for trial before the official release of a single application or microservice, and the number of trial users is gradually expanded to timely discover and correct problems, from "gray" to "black".

[0067] Blue-green deployment: refers to having two identical and independent production environments, one of which is the "blue environment" and the other is the "green environment". The green environment is the production environment currently in use by users. When a new version of a single application / microservice needs to be deployed, the new version can be deployed to the blue environment first, and tests can be run in the blue environment to check whether the new version works properly. If the test passes, user traffic is directed from the green environment to the blue environment, and the blue environment becomes the production environment. If the test fails, the user is directed back to the green environment, and debugging is performed in the blue environment to determine the cause of the problem.

[0068] Development environment (dev): refers to the environment in which developers develop and debug software, such as the environment in which monolithic applications / microservices are developed and debugged. In the development environment, developers can quickly write, debug, and test the code of monolithic applications / microservices. After the developers have completed the code writing, debugging, and testing of the monolithic applications / microservices, they hand over the software package of the monolithic applications / microservices to the testers, who then test the monolithic applications / microservices that have been developed.

[0069] Test environment (test): refers to the environment in which testers test single applications / microservices. In the test environment, testers can conduct comprehensive functional tests, performance tests, compatibility tests, etc. on single applications / microservices to ensure that the single applications / microservices can run stably after they are launched. The test environment usually uses independent computing devices to test single applications / microservices, that is, different computing devices from those in the development environment are used to ensure the independence and accuracy of the test results.

[0070] Pre-release environment (pre): Also known as the pre-release environment, it refers to the environment used by testers for final verification and accurate launch. In the pre-release environment, the single application / microservice can be finally verified and tuned. The pre-release environment is usually similar to the production environment and uses real production data. In the pre-release environment, some pre-launch functional tests, performance tests, and compatibility tests can be performed to ensure the stability and reliability of the single application / microservice after it is launched.

[0071] It should be noted that the pre-release environment and the test environment usually use different computing devices to test the monolithic application / microservice to ensure the independence and accuracy of the test results.

[0072] Production environment (pro): It can also be called the live network environment. It is the environment that provides services to users and is also the environment that users access and use. In the production environment, a stable version of a monolithic application or microservice that has been tested and verified is deployed.

[0073] The following is an exemplary introduction to the application scenarios of the embodiments of the present application.

[0074] The configuration item changing method provided in the embodiment of the present application is applicable to scenarios such as changing the configuration items of microservices and the configuration items of monolithic applications.

[0075] From development to launch, microservices usually need to go through development environment, test environment, pre-release environment, production environment, etc. In the development environment, developers usually configure many configuration items for microservices to indicate the different business logics of microservices. However, in the production environment, after microservices call configuration items, abnormal situations such as operation errors and crashes often occur, resulting in users being unable to use microservices normally, which seriously affects the user experience.

[0076] For example, when a user requests a list service from the microservice of an application, the microservice fails to provide the list service to the user after calling the configuration item corresponding to the list service. The reason is that when the microservice calls the corresponding configuration item, the returned message body content is empty, which causes the microservice to be unable to execute the business logic indicated by the configuration item (i.e., the list service). This situation seriously affects the user experience.

[0077] Therefore, how to avoid operational abnormalities after microservices call configuration items has become a technical problem that needs to be solved urgently.

[0078] In view of this, the embodiment of the present application provides a configuration item change method, which is applied to a computing device, and a target version of a target microservice can be run on the computing device, and the target version is configured with a target configuration item. On this basis, in the process of the computing device running the target version, if a target configuration item change request is received, the verification result of the target configuration item is determined to determine whether the target version of the target microservice supports the use of the target configuration item. After that, the computing device can process the change request according to the verification result of the target configuration item. Since it is determined how to process the target configuration item change request based on whether the current version (i.e., the target version) running the computing device supports the use of the target configuration item, therefore, on the one hand, it helps to avoid changing the target configuration item when the current version does not support the use of the target configuration item, thereby helping to avoid the risk caused by the target version not supporting the use of the target configuration item, and then helping to improve the operation stability and reliability of the target service. On the other hand, it not only helps to avoid changing the unverified configuration item to take effect, but also helps to ensure the validity of the changed configuration item in the currently running target version.

[0079] The following is an exemplary introduction to the system architecture of the embodiments of the present application.

[0080] Figure 1 A system architecture diagram of a production environment is provided for an embodiment of the present application.

[0081] In the embodiment of the present application, the production environment can provide services to cloud tenants in the form of cloud services, that is, the equipment in the production environment can be rented to cloud tenants for use. Cloud tenants can deploy microservices of the application in the rented production environment, thereby implementing the configuration item change method provided in the embodiment of the present application to verify the configuration items in the change request.

[0082] like Figure 1As shown, the system architecture includes a first terminal device, a first electronic device, a first application programming interface gateway (APIG), a microservice platform and a first configuration center. The first terminal device and the first electronic device can communicate with the microservice platform through the first API gateway, and the microservice platform can communicate with the first configuration center.

[0083] The microservice platform can be used to run multiple microservices, such as microservice 1, ... microservice K. The first configuration center can be used to manage multiple configuration items of multiple microservices, such as configuration item 1, ... configuration item N. Users using the application can access different microservices of the microservice platform through the first terminal device to obtain services provided by different microservices. Operation and maintenance personnel can access the microservice platform through the first electronic device to request configuration of multiple configuration items of multiple microservices.

[0084] It should be noted that the multiple microservices running on the microservice platform have been tested in test environments, pre-test environments, and other environments, and the test results are that the microservices have passed the test.

[0085] In the embodiment of the present application, the configuration items of each microservice in the multiple microservices can be managed by the configuration center, or can be directly set in the code of the microservice and managed by the computing device running the microservice, and the embodiment of the present application does not limit this. Below, the configuration items are managed by the configuration center as an example to illustrate the embodiment of the present application.

[0086] In the embodiment of the present application, after the tested microservice is deployed on the microservice platform, the microservice platform can automatically register the configuration items in the microservice to the first configuration center, so that the configuration items are managed by the configuration center.

[0087] Optionally, the first terminal device may include a mobile phone, a tablet computer, a handheld computer, a personal computer (PC), a cellular phone, a personal digital assistant (PDA), a wearable device (such as a smart watch, a smart bracelet, etc.), a smart home device (such as a television, etc.), a car machine (such as a car computer, etc.), a smart screen, a game console, a headset, an AI speaker, an augmented reality (AR) / virtual reality (VR) device, an ultra-mobile personal computer (UMPC), a laptop computer, a netbook, a desktop computer or an all-in-one computer, etc.

[0088] It should be noted that the embodiment of the present application does not limit the device form of the first terminal device, and the above is only an exemplary description.

[0089] Optionally, the first electronic device may be a tablet computer, a handheld computer, a PC, a UMPC, a notebook computer, a netbook, a desktop computer or an all-in-one computer, etc.

[0090] It should be noted that the embodiments of the present application do not limit the device form of the first electronic device, and the above description is only an exemplary description.

[0091] In the embodiment of the present application, the microservice platform may include at least one first computing device, wherein different first computing devices in the at least one first computing device may communicate with each other.

[0092] It should be noted that in the embodiments of the present application, at least one may be one, or may be multiple, wherein multiple may be two or more, which will not be elaborated later.

[0093] In one example, different first computing devices in the microservice platform can be used to run the same microservice. In another example, a portion of the first computing devices in the microservice platform can be used to run the same microservice, and another portion of the first computing devices can be used to run different microservices. In yet another example, different first computing devices in the microservice platform can be used to run different microservices.

[0094] It should be noted that the embodiment of the present application does not limit whether different first computing devices in the microservice platform run the same microservice. Below, the embodiment of the present application is exemplarily described by taking this further example as an example.

[0095] In the embodiment of the present application, each first computing device in the microservice platform can be used to run at least one microservice.

[0096] In one example, each first computing device in the microservice platform can run a microservice through a virtual machine. In another example, a portion of the first computing devices in the microservice platform can run a microservice through a container, and another portion of the first computing devices can run a microservice through a virtual machine. In yet another example, each first computing device in the microservice platform can run a microservice through a container.

[0097] It should be noted that the embodiment of the present application does not limit how each first computing device in the microservice platform runs the microservice, and the above is only an exemplary description. Below, taking this further example as an example, the embodiment of the present application is exemplarily described.

[0098] Optionally, the first computing device in the microservice platform may be a network device or an electronic device, etc.

[0099] The network device may include a server, etc. The server may be a physical or logical server, or may be two or more physical or logical servers that share different responsibilities and cooperate with each other to realize various functions of the server.

[0100] Exemplarily, the server may be a blade server, a high-density server, a rack server, a tower server, or the like.

[0101] It should be noted that the embodiment of the present application does not limit the device form of the first computing device in the microservice platform, and the above is only an exemplary description.

[0102] In the embodiment of the present application, the configuration center may include at least one first server, wherein different first servers in the at least one first server may communicate with each other.

[0103] In one example, different first servers of the configuration center can be used to manage different configuration items. In another example, some of the first servers of the configuration center can be used to manage the same configuration items, and other first servers can be used to manage different configuration items. In yet another example, each first server of the configuration center can be used to manage the same configuration item, based on which, the configuration center can also be called a distributed configuration center.

[0104] It should be noted that the embodiment of the present application does not limit whether different first servers in the configuration center manage the same configuration item. Hereinafter, the embodiment of the present application is exemplarily described by taking this further example.

[0105] In terms of software, the present application embodiment also provides a first software, which can be used to implement the following Figure 4 The solution of the embodiment shown. Each first computing device in the microservice platform can implement by running the first software Figure 4 A scheme of the illustrated embodiment.

[0106] Exemplarily, the first software may be a software development kit (SDK).

[0107] The present application embodiment also provides a second software, which can be used to implement the following Figure 5 The solution of the embodiment shown. Each first computing device in the microservice platform can implement by running the first software Figure 5 A scheme of the illustrated embodiment.

[0108] Exemplarily, the second software may be a software development kit (SDK).

[0109] In the embodiment of the present application, the first software and the second software may be integrated into one software package (eg, a software package of the target software), or the first software and the second software may be carried by two different software packages respectively.

[0110] Figure 2 A system architecture diagram of a test environment is provided for an embodiment of the present application.

[0111] In the embodiment of the present application, the test environment can provide services to cloud tenants in the form of cloud services, that is, the equipment in the test environment can be rented to cloud tenants for use. Cloud tenants can deploy the newly developed microservices in the rented test environment, so that when testing the new version of the microservice, they can also test whether the new version of the microservice supports the use of the configuration items.

[0112] like Figure 2 As shown, the system architecture includes a second electronic device, a second API gateway, a test platform and a second configuration center. The second electronic device communicates with the test platform through the second API gateway, and the test platform can communicate with the second configuration center.

[0113] The test platform can be used to run multiple microservices' of the application, such as microservice 1', ..., microservice K'. The second configuration center can be used to manage multiple configuration items' of the multiple microservices', such as configuration item 1', ..., configuration item N'. The tester can access the test platform through the second electronic device to instruct the test platform to test the multiple microservices'.

[0114] In the embodiment of the present application, the test platform includes at least one second computing device. Each second computing device in the test platform can be used to implement the following Figure 5 For example, each second computing device in the test platform can implement Figure 5 A scheme of the illustrated embodiment.

[0115] Exemplarily, different second computing devices may be used to run different microservices', thereby implementing testing of different microservices'. In addition, different second computing devices may not communicate with each other, thereby implementing independent testing of different microservices'.

[0116] It should be noted that for other relevant descriptions about the second computing device, such as: device form, how to run microservices, the number of running microservices, etc., you can refer to the relevant descriptions of the first computing device, which will not be repeated here.

[0117] In the embodiment of the present application, the second configuration center may include at least one second server.

[0118] It should be noted that for the relevant description of the second server, please refer to the description of the first service, which will not be repeated here.

[0119] Figure 3 A system architecture diagram of a pre-release environment is provided for an embodiment of the present application.

[0120] In the embodiment of the present application, the pre-release test environment can provide services to cloud tenants in the form of cloud services, that is, the equipment in the pre-release test environment can be rented to cloud tenants for use. Cloud tenants can deploy the newly developed microservices in the rented test environment. In this way, when testing the new version of the microservice, they can also test whether the new version of the microservice supports the use of configuration items. For example, testing according to the grayscale verification strategy.

[0121] like Figure 3 As shown, the system architecture may include a third terminal device, a third electronic device, a third API gateway, a pre-release test platform, and a third configuration center. The third terminal device and the third electronic device communicate with the pre-release test platform through the third API gateway, and the pre-release test platform can communicate with the third configuration center.

[0122] Among them, the pre-release test platform can be used to run multiple microservices of the application, such as: microservice 1,..., microservice K. The third configuration center can be used to manage multiple configuration items of multiple microservices, such as: configuration item 1,..., configuration item N. The pre-release tester can access the pre-release test platform through the third electronic device to instruct the pre-release test platform to test multiple microservices.

[0123] Among them, a specific user can access different microservices of the pre-release test platform through a third terminal device to obtain services provided by different microservices. This helps to increase the similarity between the preset test environment and the production environment, thereby helping to improve the accuracy and reliability of the test results.

[0124] In the embodiment of the present application, the pre-launch test platform includes at least one third computing device. Each third computing device in the pre-launch test platform can be used to implement the following Figure 5 For example, each third computing device in the pre-release test platform can implement Figure 5 A scheme of the illustrated embodiment.

[0125] Exemplarily, different third computing devices can communicate with each other, thereby implementing pre-testing of different microservices when multiple microservices are running synchronously.

[0126] It should be noted that for other relevant descriptions about the third computing device, such as: device form, how to run microservices, the number of running microservices, etc., you can refer to the relevant descriptions of the first computing device, which will not be repeated here.

[0127] In the embodiment of the present application, the third configuration center may include at least one third server.

[0128] It should be noted that for the relevant description of the third server, please refer to the description of the first service, which will not be repeated here.

[0129] In addition, the reason why the first computing device, the second computing device, and the third computing device are named in the embodiments of the present application is to distinguish computing devices of different platforms (such as: microservice platform, test platform, pre-release test platform), which will be described separately later.

[0130] It should be noted that the different names of servers (such as: first server, second server, third server) and configuration centers (such as: first configuration center, second configuration center, third configuration center) are the same as the naming principles of computing devices and will not be repeated here.

[0131] It should be noted that the system architecture and application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the evolution of the system architecture and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0132] For ease of understanding, the configuration item changing method provided in the embodiment of the present application is exemplarily introduced below in combination with the above system architecture and accompanying drawings.

[0133] Figure 4 4 is a flowchart of a configuration item change method according to an exemplary embodiment. Exemplarily, the method may include the following steps 401 to 403.

[0134] It should be noted that the "step" in the embodiments of the present application can be abbreviated as "S" and will not be repeated later.

[0135] In the embodiment of the present application, the computing device can be used to run the target version of the target service, and the value of the target configuration item is the first value.

[0136] Optionally, the target configuration item is used to configure the software function of the target service, and / or the target configuration item is used to enable or disable the software function of the target service. It should be noted that the embodiments of the present application do not limit the functions implemented by the target configuration, and the above is only an exemplary description.

[0137] Optionally, the target service includes a target monolithic application or a target microservice.

[0138] In the following, the target service is taken as a target microservice as an example to exemplarily introduce the embodiments of the present application.

[0139] It should be noted that the embodiment of the present application does not limit the type of service provided by the target service, for example, it may provide social services, information services, network resource services, tool services, etc.

[0140] in, Figure 4 The configuration item change method shown can be changed by Figure 1 The configuration item changing method can be executed by any first computing device in the microservice platform.

[0141] In the following, a single first computing device in a microservice platform is taken as an example to exemplify the embodiments of the present application.

[0142] For the sake of ease of description, the first computing device, the first terminal device, the first electronic device, and the first configuration center will be referred to as a computing device, a terminal device, an electronic device, and a configuration center below and will not be repeated later.

[0143] Step 401: When a computing device runs a target version of a target microservice, a change request sent by an electronic device is received.

[0144] The change request is used to request to change the value of the target configuration item to a second value.

[0145] In an embodiment of the present application, a computing device may be used to run at least one microservice of an application, wherein the at least one microservice includes a target microservice, wherein the target microservice includes at least one configuration item, and the at least one configuration item includes a target configuration item.

[0146] The target microservice may be any one of the at least one microservice, and the target configuration item may be any one of the at least one configuration item.

[0147] In the embodiment of the present application, the target configuration item may include a configuration switch, configuration information, etc.

[0148] It should be noted that the embodiment of the present application does not limit the type of configuration items, and the above is only an exemplary description. In addition, the configuration switch in the embodiment of the present application can also be called a function switch, a feature switch, etc.

[0149] For example, the configuration information may include volume information, which indicates the volume percentage of a certain version / function, that is, the percentage of users who can use the newly launched version / function. For example, if the number of users of the application is 100 and the volume information is 10%, then 10 (100*10%) users can use the newly launched version / function.

[0150] Exemplarily, the configuration switch may include a function release switch, an experiment switch, an operation and maintenance switch, a permission switch, a freeze switch, and the like. Among them, the function release switch may be used to indicate whether the new function / new version is allowed to be released, such as when the value is 0, it represents the closed state, that is, release is not allowed, and when the value is 1, it represents the open state, that is, release is allowed. The experiment switch may be used to indicate the diversion percentage, such as when the value is 10%, it indicates diversion of 10%. The operation and maintenance switch is used to indicate whether to run a blue environment or a green environment, such as when the value is 0, the blue environment is run, and when the value is 1, the green environment is run. The permission switch is used to indicate operation permissions, such as when the value is 0, everyone is allowed to operate, when the value is 1, only management operations are allowed, and the freeze switch may be used to indicate freezing of resources in an account, such as when the value is 100, 100 units of resources are frozen.

[0151] It should be noted that the "switch (such as a configuration switch, etc.)" in the embodiment of the present application can be used to indicate different states of a function of the target microservice, where one state can correspond to a business logic. Therefore, the "switch" in the embodiment of the present application not only has two states, on and off, but also has different sub-states in the on state. For example, when the value of the experimental switch is 0%, it is used to represent the off state (i.e., closing the drainage); when the value of the experimental switch is greater than 0%, it is used to represent the on state (i.e., opening the drainage); when the value of the experimental switch is 1%, 10%, 15%, etc., it belongs to different sub-states in the on state.

[0152] On this basis, when the operation and maintenance personnel want to change the target configuration item, they can use the electronic device to send a change request to the computing device running the target microservice to request to change the value of the target configuration item. For example, if the current value of the target configuration item (such as a freeze switch) is 0 (i.e., the first value), and the operation and maintenance personnel want to change the value of the freeze switch to 100 (i.e., the second value), the operation and maintenance personnel can send a change request for the freeze switch to the computing device running the target microservice through the electronic device.

[0153] In one example, a "change" can be a change between an on state and an off state. For example, the current state of the function release switch is on, and a change is requested to be off. Or, the current value of the freeze switch is 0, and a change is requested to be 50. In another example, a "change" can also be a change between different sub-states. For example, the current value of the freeze switch is 1, and a change is requested to be 100.

[0154] In the embodiment of the present application, the change request indicates the target configuration item. Based on this, after receiving the change request, the computing device can determine based on the change request that the operation and maintenance personnel requests to change the target configuration item, rather than other configuration items.

[0155] In one example, the change request may include an identifier of the target configuration item. The computing device may determine, based on the identifier of the target configuration item, that the configuration requested by the operation and maintenance personnel is the target configuration item.

[0156] Exemplarily, the change request may include an identifier of a freeze switch, so that after receiving the change request, the computing device can determine, based on the identifier of the freeze switch, that the operation and maintenance personnel wants to change the freeze switch.

[0157] It should be noted that the embodiments of the present application do not limit how to indicate the target configuration item, and the above is only an exemplary description.

[0158] In the embodiment of the present application, the change request indicates the target microservice. Based on this, after receiving the change request, the computing device can determine based on the change request that the operation and maintenance personnel requests to change the configuration item of the target microservice in at least one microservice, rather than the configuration items of other microservices.

[0159] In one example, the change request may include an identifier of the target microservice. The computing device may determine, based on the identifier of the target microservice, that the configuration requested by the operation and maintenance personnel is a configuration item of the target microservice.

[0160] In another example, the computing device stores a correspondence between the target configuration item and the target microservice. Based on this, after receiving the change request, the computing device determines that the configuration item requested to be changed by the operation and maintenance personnel is the configuration item of the target microservice, that is, the configuration item of the target microservice that has a correspondence relationship with the target configuration item based on the correspondence and the change request indicating the target configuration item.

[0161] It should be noted that the embodiments of the present application do not limit how to indicate the target microservice, and the above is only an exemplary description.

[0162] In the embodiment of the present application, the change request indicates the value to be changed (e.g., the second value). Based on this, after the computing device receives the change request, it can determine, based on the change request, that the operation and maintenance personnel requests to change the value of the target configuration item to the second value, rather than other values. This helps to improve the accuracy of the results.

[0163] Optionally, the configuration item change method further includes: the computing device determines whether the environment type of the target microservice is a production environment.

[0164] If the determination result is yes, execute step 402. If the determination result is no, change the target configuration item or end.

[0165] The environment type may include a production environment or a non-production environment. For example, a non-production environment may include a development environment, a test environment, a pre-production environment, and the like.

[0166] In the embodiment of the present application, after receiving the change request, the computing device determines whether the environment type of the target microservice is a production environment. If it is a production environment, the verification result of the target configuration is determined to determine how to handle the target configuration item change request. If it is a non-production environment, the target configuration item is changed based on the change request (e.g., the value of the target configuration item is changed to a second value) or ends.

[0167] Exemplarily, the computing device stores an environment type identifier, which can be used to indicate the type of environment in which the target microservice is running. After receiving the change request, the computing device can determine whether the current environment is a production environment by reading the environment type identifier.

[0168] It should be noted that the embodiment of the present application does not limit the method of determining the environment type, and the above is only an exemplary description. In addition, the embodiment of the present application does not limit the order of determining whether it is a production environment and executing step 402, and the above is only an exemplary description.

[0169] In this embodiment, before determining the verification result of the target configuration item, the environment type in which the target microservice is currently running is determined to avoid verifying the target configuration item in the change request in a non-production environment, thereby helping to ensure the necessity and effectiveness of the verification operation and avoiding executing invalid operations that affect the normal change process.

[0170] Step 402: The computing device verifies whether the target version supports the use of the target configuration item and obtains a verification result.

[0171] The verification result is used to indicate whether the target version of the target microservice supports the use of the target configuration item or does not support the use of the target configuration item.

[0172] It can be understood that, since the verification result is used to determine whether the target version of the target microservice supports the use of the target configuration item, step S402 can also be considered as determining whether the target version of the target microservice supports the use of the target configuration item.

[0173] Exemplarily, after receiving a change request, the computing device can run the first software (such as SDK) to verify whether the target version supports the use of the target configuration item to determine the verification result of the target configuration item, and perform different operations based on the different contents indicated by the verification result, thereby achieving a comprehensive check on the risks of the changed configuration item.

[0174] There are multiple implementation methods for step 402 . Below, method 1 and method 2 are used for exemplary description.

[0175] Method 1: Determine the verification result of the target configuration item based on the version range and target version corresponding to the target configuration item.

[0176] The version range corresponding to the target configuration item is used to indicate the microservice version that supports the use of the target configuration item.

[0177] In the embodiment of the present application, after receiving the change request, the computing device determines the version range and target version corresponding to the target configuration item based on the change request, and determines the verification result of the target configuration based on the corresponding version range and target version of the target configuration. Since the version range can indicate the microservice version that supports the use of the target configuration item, it is possible to accurately determine whether the target version supports the use of the target configuration item based on the version range and the target version. The determination process is not only simple and convenient, but also the accuracy of the determined verification result is high.

[0178] In the following, an implementation method of method 1 is exemplified through S1-S2.

[0179] S1: The computing device determines the version range corresponding to the target configuration item.

[0180] The following is an exemplary description of determining the version range corresponding to the target configuration item through two implementation methods.

[0181] The first implementation method: the configuration content of the target configuration item includes a version range. Based on this, the computing device can determine the version range corresponding to the target configuration item according to the configuration content of the target configuration item.

[0182] In the embodiment of the present application, the configuration content of the target configuration item may include a version range, etc. On this basis, the computing device may determine the version range corresponding to the target configuration item by reading the "version range" in the configuration content.

[0183] Exemplarily, the configuration content of the target configuration item may also include a configuration item identifier (such as a keyword (Key) in a key-value pair) and a current value of the configuration item (such as a value (Value) in a key-value pair). Different configuration items have different configuration item identifiers. This helps to distinguish different configuration items through configuration content, thereby accurately locating the target configuration item.

[0184] Exemplarily, the configuration content of the target configuration item may also include an environment type, which is used to indicate the storage location of the environment type identifier. In this way, after the computing device obtains the configuration content of the target configuration item, it can accurately read the environment type identifier based on the read environment type field, thereby determining whether the current operating environment of the target microservice is a production environment. If it is a production environment, continue to read the version range to determine the verification result.

[0185] In an embodiment of the present application, if the configuration content of the target configuration item is stored in the configuration center, the computing device may send a first acquisition request to the configuration center to request to acquire the configuration content of the target configuration item. After receiving the first acquisition request, the configuration center returns the configuration content of the target configuration item to the computing device in response to the first acquisition request.

[0186] Exemplarily, the first acquisition request may include an identifier of the target configuration item. After receiving the first acquisition request, the configuration center returns the configuration content of the target configuration item to the computing device based on the identifier of the target configuration item.

[0187] Exemplarily, the configuration content of the target configuration item can be recorded in the target configuration file. The format of the target configuration file can be Text, Json, XML, YAML, Properties, etc. On this basis, the first acquisition request can be specifically used to request to obtain the configuration file of the target configuration item (i.e., the target configuration file), and the configuration center can return the configuration file of the target configuration item to the computing device in response to the first acquisition request.

[0188] It should be noted that the embodiments of the present application do not limit the recording form of the configuration content and the format of the configuration file, and the above is only an exemplary description.

[0189] In addition, the embodiments of the present application do not impose any restrictions on the storage location of the configuration content of the target configuration item. For example, the configuration content of the target configuration item may also be stored on a computing device. In this way, the computing device can obtain the configuration content of the target configuration item from local storage, which helps to improve the convenience and efficiency of obtaining the configuration content.

[0190] In this implementation, by recording the version range corresponding to the target configuration item in the configuration content of the configuration item, the version range can be directly read from the configuration content, which helps to improve the accuracy of the determined version range and avoids determining the version range corresponding to the non-target configuration item as the version range of the target configuration item, thereby helping to improve the accuracy of the verification result.

[0191] In the embodiment of the present application, the version range corresponding to the target configuration item may include a version set or a third version.

[0192] In this embodiment, by setting two different types of version ranges, it helps to increase the diversity of version ranges, and further helps to increase the flexibility of changing configuration items.

[0193] Optionally, the version set (also referred to as a version whitelist) includes at least one service version. Each service version in the at least one service version supports the use of the target configuration item. Based on this, if the target version belongs to any service version in the at least one service version, in other words, at least one service version includes the target version, then the target version supports the use of the target configuration item, otherwise, the target configuration item is not supported.

[0194] Exemplarily, the version set corresponding to the freeze switch may include version 2.0, version 3.0, and version 5.0.

[0195] In this embodiment, the version range is set to indicate the version set, thereby improving the version conditions for supporting the use of the target configuration item, that is, only the versions belonging to the version set support the use of the target configuration item. This helps to control the number of versions that support the use of the target configuration item, and further helps to improve the operating stability and reliability of the target microservice.

[0196] Optionally, the third version is used to indicate the minimum microservice version that supports the use of the target configuration item, which can also be called the starting effective version. That is, if the target version is higher than or equal to the third version, the target version supports the use of the target configuration item, otherwise, it does not support the use of the target configuration item.

[0197] Exemplarily, the third version corresponding to the freeze switch may be version 2.0.

[0198] In this embodiment, the minimum microservice version is indicated by setting the version range, thereby lowering the version condition for supporting the use of the target configuration item, that is, as long as it is higher than or equal to the minimum service version, it will be sufficient. This helps to increase the number of versions that support the use of the target configuration item, thereby helping to increase the range of applicable microservice versions of the target configuration item, and further helping more versions of microservices to support changes to the target configuration item.

[0199] In an embodiment of the present application, the target configuration item is also configured with a management mode, and the management mode can be used to indicate the risk level of the target configuration item. The management mode may include a strict mode or a non-strict mode (also referred to as a loose mode). Among them, the strict mode is used to indicate that the risk level of the target configuration item is high, and the non-strict mode is used to indicate that the risk level of the target configuration item is low, that is, the risk level indicated by the strict mode is higher than the risk level indicated by the non-strict mode. In addition, the risk level can also be used to indicate the risk level of abnormal operation when the computing device runs the business logic indicated by the target configuration item after the target configuration item is changed.

[0200] For example, if the risk level of the target configuration item is high, the management mode of the target configuration item can be set to a strict mode, for example, it can be set by the developer of the target microservice. Otherwise, the management mode of the target configuration item can be set to a non-strict mode.

[0201] When the management mode of the target configuration is the strict mode, the version range of the target configuration item includes the version set. When the management mode of the target configuration item is the non-strict mode, the version range of the target configuration item includes the third version.

[0202] In this embodiment, when the management mode is strict mode, the version range is the version set, and only the versions in the set can pass the verification. When the management mode is non-strict mode, the version range is the third version, and as long as it is higher than the third version, it can pass the verification. Therefore, the verification mode corresponding to the version set is relatively strict, and the verification mode corresponding to the third version is relatively loose. This helps to ensure that the management mode of the target configuration item matches the verification mode, thereby helping to improve the reliability of the verification results of the target configuration item.

[0203] In the following, S1 is exemplarily introduced through steps S1a to S1c in combination with the management mode of the target configuration and two types of version ranges.

[0204] S1a: The computing device determines whether the management mode of the target configuration item is a strict mode.

[0205] If the determination result is yes, then S1b is executed, and if the determination result is no, then S1c is executed.

[0206] It should be noted that for the method of determining the management mode, you can refer to the above method of determining the version range, such as: you can record whether the management mode of the target configuration item is a strict mode in the configuration content of the target configuration item, which will not be repeated here.

[0207] S1b: The computing device determines that the version set is a version range.

[0208] Exemplarily, if the management mode is the strict mode, the computing device reads the first field in the configuration content, the first field records at least one version in the version set, and determines the version set indicated by the first field as the version range.

[0209] S1c: The computing device determines that the third version is the version range.

[0210] Exemplarily, if the management mode is a non-strict mode, the computing device reads the second field in the configuration content, the second field records the third version, and determines the third version indicated by the second field as the lowest version in the version range.

[0211] In this embodiment, by setting the management mode and corresponding different management modes to different types of version ranges, it is possible to determine different types of version ranges according to the management mode, and then match the determined version range with the risk level of the target configuration item. This not only helps to improve the flexibility of changing the target configuration item, but also helps to improve the security of changing the target configuration item, and thus helps to improve the stability and reliability of the microservice operation.

[0212] Second implementation: The target file corresponding to the target configuration item includes the version range corresponding to the target configuration item. Based on this, the computing device can determine the version range corresponding to the target configuration item according to the content in the target file.

[0213] In the embodiment of the present application, the target configuration item is configured with a target file, that is, there is a corresponding relationship between the target file and the target configuration item, such as: the target file and the target configuration item may have the same identifier, and the same identifier may be the identifier of the target configuration item. On this basis, the computing device can determine the version range corresponding to the target configuration item by reading the content in the target file.

[0214] In this implementation, the target file may be stored in a configuration center, or may be stored on a computing device, which is not limited in this embodiment of the present application.

[0215] It should be noted that for other related instructions of the second implementation method, reference can be made to the instructions of the first implementation method mentioned above, which will not be repeated here.

[0216] In this embodiment, since the target file corresponding to the target configuration item is used to record the version range, the target file only includes relevant information about the version range, so the target configuration item and the target file can be managed separately, which helps to improve the flexibility of the management method. In addition, the target file can be stored separately in the computing device, so that when the version range needs to be determined, the locally stored target file can be directly read, which not only helps to improve the efficiency of determining the version range, but also helps to avoid the inability to determine the version range when a network failure occurs.

[0217] S2: The computing device determines the verification result of the target configuration item based on the relationship between the version range and the target version.

[0218] In the embodiment of the present application, if the version range corresponding to the target configuration item includes the target version, indicating that the target version supports the use of the target configuration item, then the computing device determines that the verification result indicates that the target version supports the use of the target configuration item, such as determining that the verification result is a successful verification. If the version range corresponding to the target configuration item does not include the target version, indicating that the target version does not support the use of the target configuration item, then the computing device determines that the target version does not support the use of the target configuration item, such as determining that the verification result is a failed verification. This helps to ensure the accuracy of the content indicated by the verification result.

[0219] In one example, the version range includes a version set, which includes version 2.0, version 3.0, and version 5.0. Based on this, if the target version is version 3.0, the version range includes the target version, and the verification result is verification success. If the target version is version 4.0, the version range does not include the target version, and the verification result is verification failure.

[0220] In another example, the version range includes the third version, which is version 2.0. Based on this, when the target version is version 3.0, since version 3.0 is higher than version 2.0, the version range includes the target version, and the verification result is verification success. When the target version is version 4.0, similarly, the verification result is also verification success. If the target version is version 1.0, since version 1.0 is lower than version 2.0, the version range does not include the target version, and the verification result is verification failure.

[0221] In one example, if the verification result is "yes", the verification result indicates that the target version supports the use of the target configuration item, and if the verification result is "no", the verification result indicates that the target version does not support the use of the target configuration item.

[0222] In another example, if the verification result is a "first identifier", the verification result indicates that the target version supports the use of the target configuration item, and if the verification result is a "second identifier", the verification result indicates that the target version does not support the use of the target configuration item. Exemplarily, the first identifier and the second identifier may be numbers, letters, etc. The content of the first identifier is different from the content of the second identifier.

[0223] It should be noted that the embodiment of the present application does not limit how the verification result indicates whether the target configuration item is supported for use, and the above is only an exemplary description.

[0224] In the above implementation, the verification result of the target configuration item is determined by the relationship between the version range corresponding to the target configuration item and the target version. This not only helps to ensure the accuracy of the verification result, but also helps to improve the efficiency of determining the verification result because the verification result is determined based on only two parameters.

[0225] In the embodiment of the present application, the configuration item changing method may include the following S3.

[0226] S3: When the version range does not include the target version, the computing device runs the first version of the target microservice.

[0227] Among them, the first version is selected from the version range.

[0228] In an embodiment of the present application, when the computing device determines that the version range corresponding to the target configuration item does not include the target version, a version rollback operation can be performed to switch from the target version of the target microservice to the first version of the target microservice.

[0229] Exemplarily, the computing device stores source codes of different versions of the target microservice, such as source codes for each of the multiple versions included in the version range. The computing device can run the first version of the target microservice by running the source code of the first version.

[0230] The following is an exemplary introduction to how to determine the first version. Exemplarily, the version range may be a version set, and the target version may be version 4.0.

[0231] In one example, the computing device may determine the highest version among multiple versions as the first version, such as version 5.0 in the version set, which helps to ensure the performance of the target microservice.

[0232] In another example, the computing device may determine the lowest version among multiple versions as the first version, such as version 2.0 in the version set, which helps to ensure the stability of the target microservice.

[0233] In another example, the first version may be any version in the version set, such as version 2.0, version 3.0 or version 5.0 in the version set, which helps to increase the selection range of the first version.

[0234] It should be noted that the embodiments of the present application do not limit how to determine the first version, and the above is only an exemplary description.

[0235] In this embodiment, when the version range corresponding to the target configuration item does not include the target version, that is, when the target version does not support the use of the target configuration item, the version of the target microservice is rolled back to the first version included in the version range, so that the computing device can run the version that supports the use of the target configuration item. In this way, not only can the computing device run the target business logic indicated by the target configuration item, but also the stability and reliability of running the target business logic can be guaranteed.

[0236] In the following, another implementation of method 1 is exemplarily described through S4-S6.

[0237] S4: The computing device determines a version range corresponding to the target configuration item.

[0238] It should be noted that for the relevant description of S4, please refer to the above S1, which will not be repeated here.

[0239] S5: When the version range includes the target version, the computing device determines the version status of the target version.

[0240] The version status is used to indicate that a verified version range includes a target version (hereinafter referred to as verified) or an unverified version range includes a target version (hereinafter referred to as unverified).

[0241] In the embodiment of the present application, when the version range corresponding to the target configuration item includes the target version, the computing device further determines the version status of the target version, thereby achieving accuracy in determining that the version range includes the target version. This helps to improve the accuracy of the verification result.

[0242] The following is an exemplary description of how to determine the version status of the target version.

[0243] In one example, a version file of the target version is stored in the computing device, and the version file includes the microservice version status (ie, the version status of the target version). The computing device can determine the version status of the target version by reading the version file of the target version.

[0244] Exemplarily, the version file may also include a microservice version number (i.e., a target version), a microservice identifier (i.e., an identifier of a target microservice), a microservice name (i.e., a name of a target microservice), etc. This helps to distinguish different version files of different microservices, thereby helping to improve the accuracy of the determined version status.

[0245] In another example, the configuration center stores the version file of the target version. The computing device may send a second acquisition request to the configuration center to request to acquire the version file of the target version.

[0246] Example 1: After determining that the version range corresponding to the target configuration item includes the target version, the computing device may send a second acquisition request to the configuration center to request the version file of the target version. This helps to increase the necessity of obtaining the version file, thereby helping to avoid wasting network resources.

[0247] Example 2: When sending a first acquisition request to the configuration center, the computing device can simultaneously request to obtain the version file of each version in the version range, that is, the second acquisition request and the first acquisition request are the same acquisition request. This helps to reduce the number of times the acquisition request is sent, thereby helping to improve the acquisition efficiency.

[0248] S6: The computing device determines a verification result of the target configuration item based on the version status of the target version.

[0249] In the embodiment of the present application, if the version status of the target version indicates verified, it means that the accuracy of the version range including the target version is high, based on which the computing device can determine that the verification result indicates that the target version supports the use of the target configuration item. If the version status of the target version indicates unverified, it means that the accuracy of the version range including the target version is low, based on which the computing device can determine that the verification result indicates that the target version does not support the use of the target configuration item. This helps to ensure the accuracy of the content indicated by the verification result.

[0250] In the above implementation, the verification result of the target configuration item is determined in combination with the version range corresponding to the target configuration item and the version status of the target version. Since the verification conditions are added, it not only helps to improve the precision of the verification result, but also helps to improve the accuracy of the verification result, thereby helping to reduce the risk of changing the target configuration item, and further helping to improve the stability and reliability of the target microservice operation.

[0251] In the embodiment of the present application, the configuration item changing method may include the following S7:

[0252] S7: When the version status of the target version indicates that the unverified version range includes the target version, the computing device runs the second version of the target microservice.

[0253] The second version is selected from a version range corresponding to the target configuration item, and the version status of the second version indicates that the verified version range includes the second version.

[0254] In an embodiment of the present application, when the computing device determines that the version status indication of the target version is not verified, it means that the reliability of the version range including the target version is low. Based on this, the computing device can perform a rollback operation to switch from running the target version of the target microservice to running the second version of the target microservice.

[0255] Exemplarily, the version range is a version set, the target version is version 4.0, the version status of version 2.0 indicates verified, the version status of version 3.0 indicates unverified, and the version status of version 5.0 indicates verified, then the second version may be version 2.0 or version 5.0.

[0256] It should be noted that for the relevant instructions about the second version, please refer to the relevant instructions about the first version, which will not be repeated here.

[0257] In this embodiment, by setting the version status of the target version to indicate that it is not verified, that is, when the accuracy of the version range including the target version is uncertain, the target version is rolled back to the second version included in the version range, so that the computing device can not only run a version that supports the use of the target configuration item, but also run a verified version. In this way, not only can the computing device run the business logic indicated by the target configuration item, but it also helps to reduce the risk when running the business logic, thereby helping to improve the stability and reliability of the target microservice when running the business logic.

[0258] Optionally, in a case where the version status of the target version indicates that the version range is not verified to include the target version, the computing device may further delete the target version in the version range.

[0259] In one example, if the version range corresponding to the target configuration item is managed by the configuration center, such as: the version range is set in the configuration content of the target configuration item, the computing device can send a deletion instruction to the configuration center to instruct to delete the target version in the version range. In another example, if the version range corresponding to the target configuration item is stored in the computing settings, the computing device can directly delete the target version in the version range.

[0260] In this embodiment, by setting the version status of the target version to indicate unverified, the target version in the version range is deleted. This not only helps to improve the accuracy of the version range, but also helps to avoid the target version passing verification when the operation and maintenance personnel request to change the target configuration item again, thereby helping to avoid changing the target configuration item in the target version, and further helping to ensure the operating stability and reliability of the target microservice.

[0261] Method 2: Determine the verification result of the target configuration item based on the target identification range corresponding to the target version.

[0262] The target identifier range is used to indicate the configuration items that the target version supports.

[0263] Exemplarily, each identifier included in the target identifier range may be an identifier of each configuration item supported for use by the target version.

[0264] In this implementation, since the identification range can indicate the configuration items supported by the target version, based on this, whether the identification range includes the target configuration item can accurately determine whether the target version supports the use of the target configuration item, and the determination method is not only simple and convenient, but also highly accurate. In addition, the diversity of the determination method is also improved.

[0265] The following is an illustrative description of method 2 through S8-S9.

[0266] S8: The computing device determines a target identification range corresponding to the target version.

[0267] In an embodiment of the present application, the correspondence between multiple versions of the target microservice and multiple identification ranges, wherein the target version has a correspondence with the target identification range. The correspondence can be stored in the computing device. Based on this, after the computing device receives the change request, it can read the target identification range corresponding to the target version from the local storage.

[0268] Exemplarily, the target identification range may include an identification set, and the identification set may include 111, 222, and 333.

[0269] It should be noted that for other related instructions about the identification range, please refer to the version range description, which will not be repeated here.

[0270] S9: The computing device determines a verification result of the target configuration item based on the target identification range and the identification of the target configuration item.

[0271] In the embodiment of the present application, if the target identification range corresponding to the target version includes the identification of the target configuration item, indicating that the target version supports the use of the target configuration item, then the computing device determines that the verification result indicates that the target version supports the use of the target configuration item, such as: determining that the verification result is a successful verification. If the target identification range corresponding to the target version does not include the identification of the target configuration item, indicating that the target version does not support the use of the target configuration item, then the computing device determines that the verification result indicates that the target version does not support the use of the target configuration item, such as: determining that the verification result is a failed verification. In this way, it helps to ensure the accuracy of the content indicated by the verification result.

[0272] Exemplarily, the target identification range includes 111, 222, and 333. If the identification of the target configuration item is 222, the target identification range includes the identification of the target configuration item, and the verification result is verification success. If the identification of the target configuration item is 444, the target identification range does not include the identification of the target configuration item, and the verification result is verification failure.

[0273] It should be noted that for other related instructions of method 2, please refer to the instructions of method 1 above, which will not be repeated here.

[0274] In this embodiment, the verification result of the target configuration item is determined by whether the target identification range includes the identification of the target configuration item. Not only is the determination method simple, but the accuracy of determining whether the target identification range includes the identification of the target configuration item is also high, thus helping to improve the accuracy of the verification result.

[0275] Step 403: The computing device processes the change request based on the verification result of the target configuration item.

[0276] Step 403 may include multiple implementation methods, and the following is exemplified by methods A and B.

[0277] Method A: Process the change request based on whether the target version supports the use of the target configuration item.

[0278] In this method, whether the target version supports the use of the target configuration item determines how to handle the configuration item request. This not only helps avoid changing the target configuration item when the target version does not support the use of the target configuration item, but also helps improve the processing efficiency of the change request, thereby helping to improve the user experience of operation and maintenance personnel.

[0279] The following will exemplify the method A through S10 - S11 .

[0280] S10: When the verification result indicates that the target version supports the use of the target configuration item, the computing device changes the value of the target configuration item to a second value.

[0281] Based on S10, processing the change request may include "changing the value of the target configuration item to a second value".

[0282] In the embodiment of the present application, if the target version supports the use of the target configuration item, it means that the probability of an exception occurring when the computing device runs the business logic indicated by the changed target configuration item is low. Therefore, when the verification result indicates that the target version supports the use of the target configuration item, the computing device changes the target configuration item, such as changing the value of the target configuration item to the second value, which can reduce the risk of changing the target configuration item, thereby helping to improve the operational stability of the target microservice.

[0283] In one example, the target configuration item is managed by a configuration center, and the computing device can send a change instruction to the configuration center to indicate the change of the target configuration item, such as changing the value of the configuration item to a first value. Exemplarily, the change request is used to request to change the value of the freeze switch to 100, and the change instruction is used to indicate to change the value of the freeze switch to 100.

[0284] In another example, the target configuration item is stored on the computing device, and the computing device can directly change the value of the target configuration item to the second value, that is, there is no need to send a change instruction to the configuration center. For example, the computing device can change the value of the freeze switch stored locally to 100.

[0285] S11: When the verification result indicates that the target version does not support the use of the target configuration item, the computing device sends a first prompt message to the electronic device, wherein the first prompt message is used to indicate that the target version does not support the use of the target configuration item.

[0286] Based on S11, processing the change request may include "sending a prompt message".

[0287] Exemplarily, if the version range is a version set and the target version is version 4.0, the first prompt information may be that the target microservice of version 4.0 does not support the use of a freeze switch, or does not support the use of a freeze switch with a value of 100. In the embodiment of the present application, if the target version does not support the use of a target configuration item, it means that the computing device runs the business logic indicated by the changed target configuration item, and the probability of an exception is high. Therefore, the computing device does not change the target configuration item, that is, does not execute the content requested by the change request, which helps to reduce the risk brought by the target configuration item, thereby helping to improve the operation stability and reliability of the target microservice.

[0288] In addition, the computing device sends a first prompt message to the electronic device. After the electronic device receives the first prompt message, it can present the first prompt message to the operation and maintenance personnel, so that the operation and maintenance personnel can understand the reason why the target configuration item is not supported to be changed, thereby helping the operation and maintenance personnel to adjust the change strategy in time, and further helping the operation and maintenance personnel to better manage the target microservices.

[0289] Method B: Process the change request based on whether the target version supports the use of the target configuration item and the value range of the target configuration item.

[0290] In this method, how to handle the change request is determined by whether the target version supports the use of the target configuration item and the value range of the target configuration item. This not only helps to avoid changing the target configuration item when the target version does not support the use of the target configuration item, but also helps to avoid changing the target configuration item to an inappropriate value when the target version supports the use of the target configuration item, such as changing it to a value outside the value range. This helps to reduce the risk of changing the target configuration item, and further helps to improve the operating stability and reliability of the target microservice after changing the target configuration item.

[0291] The following is an illustrative description of method B through S12-S14.

[0292] S12: When the target version supports the use of the target configuration item, the computing device determines a value range of the target configuration item.

[0293] The value range of the target configuration item is used to indicate the values ​​that the target configuration item supports changing.

[0294] Example 1: The value range of the freeze switch may include 100, 500, and 1000. Example 2: The value range of the freeze switch may include 50, 200, and 500.

[0295] In the embodiment of the present application, when the target version supports the use of the target configuration item, the computing device can determine the value range of the target configuration item to determine the value that the target configuration item supports changing.

[0296] In one example, the value range may include every value that the target configuration item supports changing. This helps to improve the accuracy of determining whether the value range includes the first value, thereby helping to improve the accuracy of the determined change request processing method.

[0297] In another example, the value range may include the minimum value that the target configuration item supports changing. In yet another example, the value range may include the maximum value that the target configuration item supports changing. This helps to reduce the condition that the value range includes the second value, thereby helping to increase the probability that the target configuration item is changed to the second value, and further helps to increase the probability of running the target microservice in the mode expected by the operation and maintenance personnel.

[0298] It should be noted that the method for determining the value range can refer to the method of "determining the version range corresponding to the target configuration item" in step 402. In addition, the type of the value range can also refer to the type of the version range, which will not be repeated here.

[0299] S13: The computing device processes the change request based on the value range and the second value of the target configuration item.

[0300] In an embodiment of the present application, after the computing device determines the value range of the target configuration item, it can determine how to process the change request based on whether the value range includes the second value in the change request.

[0301] Optionally, when the value of the target configuration item includes a second value, the computing device changes the target configuration item to the second value.

[0302] Exemplarily, the second value is 100, based on the freeze switch of Example 1 in S12 above, the value range of the freeze switch includes 100, and the determination result is yes. Based on the freeze switch of Example 2 in S12 above, the value range of the freeze switch does not include 100, and the determination result is no.

[0303] Since the value range of the target configuration item includes the first value, it means that the target configuration item supports being changed to the second value. In this case, the risk of changing the value of the target configuration item to the second value is low, that is, when the computing device executes the second business logic indicated by the second value, the probability of an exception in the target microservice is low. Therefore, the computing device can execute the change request.

[0304] In an embodiment of the present application, if the target configuration item is managed by a configuration center, the computing device may send a change instruction to the configuration center to instruct the configuration center to change the value of the target configuration item to a second value. Exemplarily, the change instruction may include an identifier of the target configuration item to indicate the specific configuration item to be changed. In addition, the change instruction may also include a second value to indicate the specific value to be changed of the target configuration item.

[0305] In this embodiment, by setting a value range for the target configuration item and sending a change instruction to the configuration center only when the value range includes the first value requested to be changed by the operation and maintenance personnel, it helps to ensure the reliability of the changed target configuration item, and further helps to ensure the operating stability and reliability when the target microservice calls the changed target configuration item.

[0306] Optionally, when the value range of the target configuration item does not include the second value, the computing device sends a second prompt message to the electronic device.

[0307] The second prompt information is used to indicate that the value range of the target configuration item does not include the first value.

[0308] Exemplarily, the second prompt information may be that the freeze switch does not support being changed to 100, or that the value range of the freeze switch does not include 100.

[0309] In an embodiment of the present application, after the computing device sends the second prompt information to the electronic device based on the change request, the electronic device receives the second prompt information and displays the second prompt information to present the second prompt information to the operation and maintenance personnel.

[0310] It should be noted that for the relevant description of the second prompt information, reference can be made to the description of the first prompt information in S11 above, which will not be repeated here.

[0311] In this embodiment, since the value range of the target configuration item does not include the first value, it means that the target configuration item does not support changing to the second value. In this case, the risk of changing the value of the target configuration item to the second value is high, that is, when the computing device executes the second business logic indicated by the second value, the probability of the target microservice being abnormal is high. Therefore, the computing device may not execute the change request, which helps to avoid the target microservice being abnormal due to the target configuration item. In addition, by sending the second prompt information to the electronic device, the operation and maintenance personnel understand the specific reasons for failing to execute the change request, which helps the operation and maintenance personnel adjust the change strategy of the target configuration item, and then helps the operation and maintenance personnel better manage the operation strategy of the target microservice.

[0312] It should be noted that the embodiment of the present application does not limit the order of "determining whether the target version supports the use of the target configuration item" and "determining whether the value range of the target configuration item includes the first value", and the above is only an exemplary description. For example, it is also possible to first determine whether the value range of the target configuration item includes the first value. If the value range includes the first value, it is determined whether the target version supports the use of the target configuration item. If the value range does not include the first value, the second prompt information is returned to the electronic device.

[0313] S14: When the verification result indicates that the target version does not support the use of the target configuration item, the computing device sends a first prompt message to the electronic device. For the relevant description of S14, reference can be made to the above S11, which will not be repeated here.

[0314] In the embodiment of the present application, the target microservice may include a first business logic indicated by a first value and a second business logic indicated by a second value.

[0315] Exemplarily, when the computing device receives the change request, the first business logic indicated by the first value is executed. After the value of the target configuration item is changed to the second value based on the change request, that is, after the value of the target configuration item is changed from the first value to the second value, the computing device calls the target configuration item and executes the second business logic indicated by the second value.

[0316] Optionally, the configuration item changing method may include the following S15-S16.

[0317] S15: The computing device runs the first test case to obtain a test result of the first test case.

[0318] The first test case is used to instruct the running of the second business logic, and the test result of the first test case is used to indicate whether the second business logic passes the test or fails the test.

[0319] In an embodiment of the present application, if the target version supports the use of the target configuration item, after the computing device changes the value of the target configuration item to the second value, it can run the first test case (also called the acceptance case) to implement the second business logic indicated by the second value, thereby verifying whether the second business logic can run normally.

[0320] For example, the code of the first test case may indicate calling the target configuration item and running the business logic indicated by the current value of the target configuration item. This helps to avoid affecting the user experience when there is an error in the second business logic.

[0321] In the embodiment of the present application, if no exception occurs during the execution of the second business logic, the test result of the first test case indicates that the test has passed. Otherwise, the test result of the first test case indicates that the test has not passed.

[0322] Exemplarily, the abnormality may include log error, operation result error, etc. Wherein, the operation result error refers to the execution result error when executing the second business logic indicated by the second value of the target configuration item. Exemplarily, when the value of the freeze switch is set to 100, when requesting to freeze the account, 500 units of resources in the account are frozen, which indicates that the operation result is wrong.

[0323] Exemplarily, the first test case may set a target condition, such as: the target condition may include that the log does not report an error, the running result is correct, etc. Based on this, if the running result of the first test case meets the target condition, the computing device may automatically determine that the test result of the first test case indicates that the test has passed, otherwise, it may be determined that the test result of the first test case indicates that the test has not passed.

[0324] It should be noted that the first test case can also be used to indicate that a freezing request is automatically generated during the running of the first business logic to request freezing of an account, which helps to improve the automation level of the first test case and the efficiency of executing the first test case.

[0325] It should be noted that the embodiment of the present application does not limit the method of determining whether the test result of the first test case indicates a pass in the test, and it can be determined based on actual conditions. The above is only an exemplary description.

[0326] It should be noted that the reason for the exception may be an error in the source code of the first business logic, or it may be other reasons, which is not limited in this embodiment of the present application.

[0327] Exemplarily, the computing device stores an operation log of the target microservice, wherein the operation log is used to record the occurrence of an exception and the cause of the exception, such as the cause may be the operation of the first business logic, etc. Based on this, the computing device can read the operation log of the target microservice to determine whether an exception related to the target configuration item occurs.

[0328] It should be noted that the embodiments of the present application do not limit the cause of the exception, how to determine whether an exception occurs, and how to determine whether the exception is related to the target configuration item. The above is only an exemplary description.

[0329] S16: When the test result of the first test case indicates that the test has not passed, the computing device changes the target configuration item to the first value.

[0330] In the embodiment of the present application, if the test result of the first test case indicates that the test is passed, the operation of changing the value of the target configuration item to the second value takes effect. If the test result of the first test case indicates that the test is not passed, the computing device changes the target configuration item back to the first value.

[0331] It should be noted that the method of “changing the configuration target item to the first value again” can refer to the above-mentioned method of “changing the target configuration item to the second value”, which will not be repeated here.

[0332] In an embodiment of the present application, after the value of the target configuration item is changed to the first value, during the process of the computing device running the target microservice, the target configuration item is called, and based on the value of the target configuration item being the first value, the first business logic indicated by the first value is run, thereby avoiding the risks brought about by changing the target configuration item.

[0333] Optionally, the configuration item changing method may further include the following S17.

[0334] S17: When the test result of the first test case indicates that the test has not passed, the computing device deletes the second value in the value range of the target configuration item.

[0335] In an embodiment of the present application, when the test result of the first test case indicates that the test has not passed, it means that there is a high risk of changing the target configuration item to the second value. Therefore, the computing device can delete the second value in the value range of the target configuration item. This helps to avoid the target configuration item being changed to the second value again.

[0336] Exemplarily, if the value range of the target configuration item is managed by the configuration center, such as: the value range is stored in the target configuration item change content, the computing device can send a deletion instruction to the configuration center to instruct to delete the second value in the value range of the target configuration item.

[0337] It should be noted that for other related instructions about S17, please refer to the above instructions for "Deleting the target version in the version range", which will not be repeated here.

[0338] In this embodiment, by setting the test result of the first test case to indicate that the test has not passed, the second value in the value range of the target configuration item is deleted. This helps to avoid the subsequent target configuration item being changed to the second value again, thereby helping to avoid abnormalities in the target microservice, and further helping to ensure the operating stability and reliability of the target microservice.

[0339] It should be noted that the present embodiment does not limit the execution order of S16 and S17, and the above is only an exemplary description. For example, S17 may be executed first, and then S16.

[0340] Optionally, if the value range of the target configuration item does not include the first value or the test result of the first test case indicates that the test fails, the configuration item changing method may include the following S18.

[0341] S18: The computing device sends the value range of the target configuration item to the electronic device.

[0342] In an embodiment of the present application, if the value range of the target configuration item does not include the first value, it means that the value requested to be changed by the operation and maintenance personnel cannot be used, and the test result of the first test case indicates that the test failed, which means that the target configuration item is not suitable for being changed to the first value. Based on this, the computing device can send the value range of the target configuration item to the electronic device, so that the electronic device presents the value range to the operation and maintenance personnel. In this way, it is helpful for the operation and maintenance personnel to select other values ​​to be configured for the target configuration item, thereby helping to improve the efficiency of changing the configuration item and reducing the workload of the operation and maintenance personnel in selecting appropriate values.

[0343] The above embodiment introduces a solution for verifying configuration items in a change request. The present application embodiment also provides another solution, which can be used to determine the "version range corresponding to the target configuration item", "target identifier range corresponding to the target version", etc. used when verifying configuration items.

[0344] The following, combined Figure 5 , the other solution is exemplified. It should be noted that only the differences between the two solutions are described in detail below, and the similarities are not repeated.

[0345] Figure 5 1 is a flowchart of a configuration item testing method according to an exemplary embodiment. Exemplarily, the method may include the following steps 501 to 503.

[0346] The configuration item testing method provided in the embodiment of the present application can be used to test whether the target version of the target microservice supports the use of the target configuration item. If the test result is that the target version supports the use of the target configuration item, it can be determined that the version range corresponding to the target configuration item includes the target version, or it can be determined that the target identifier range corresponding to the target version includes the identifier of the target configuration item.

[0347] On this basis, when the operation and maintenance personnel request to change the target configuration item, they can determine whether the target version supports the use of the target configuration item based on the version range corresponding to the target configuration item, or the target identification range corresponding to the target version, thereby implementing a comprehensive check on the request to change the target configuration item, ensuring the validity and stability of the target configuration item in the target version, and avoiding the implementation of unverified changes to the target configuration item.

[0348] In the embodiment of the present application, Figure 5 The configuration item test method shown can be Figure 1 The microservice platform shown, Figure 2 The test platform shown or Figure 3 The pre-release test platform shown is executed.

[0349] Below, with Figure 1 Taking the microservice platform shown in the figure as an example, the configuration item testing method is illustrated.

[0350] Exemplarily, the computing device of the microservice platform can fully verify at least one configuration item of the target microservice in the environment provided by the target version through the configuration item testing method, thereby determining whether the target version supports the use of at least one configuration item for testing.

[0351] In an embodiment of the present application, a computing device may be used to run at least one microservice of an application, and the at least one microservice includes a target microservice. The target microservice includes at least one configuration item, and the at least one configuration item includes a target configuration item. The target microservice may be any one of the at least one microservice. The target configuration item may be any one of the at least one configuration item.

[0352] The following uses the target version and target configuration items as an example to Figure 5 The illustrated embodiments are intended to be illustrative only.

[0353] Need to explain, Figure 5 For other related descriptions of the illustrated embodiment, such as the computing device for executing the configuration item test method on the microservice platform, the description of the target microservice, etc., please refer to Figure 4 The description of the illustrated embodiment will not be repeated here.

[0354] Step 501: The computing device obtains a second test case.

[0355] Among them, the second test case is used to indicate the target business logic of running the target microservice, and the target business logic includes the business logic indicated by at least one value of the target configuration item.

[0356] In one example, the second test case can be written by a tester. In another example, the second test case can be automatically written by a computer. It should be noted that the embodiment of the present application does not limit how to generate the second test case, and the above is only an exemplary description. Below, the embodiment of the present application is introduced by taking the tester writing the second test case as an example.

[0357] The following is an exemplary introduction to the type of the second test case.

[0358] Example 1: When the developer develops the target version of the target microservice, he adds a target configuration item to the target version. Based on this, after obtaining the target version, the tester writes a second test case based on the newly added target configuration item. Thus, the second test case can be used to test whether the target version supports the use of the newly added target configuration item.

[0359] The target business logic includes the business logic of at least some value indications of the target configuration item. That is, the second test case can be used to test the business logic of each value indication of the target configuration item, or can also be used to test the business logic of some value indications of the target configuration item.

[0360] Example 2: The historical version of the target microservice is configured with a target configuration item. When the developer develops the target version, he adds a new value to the value range of the target configuration item. Based on this, the tester can write a second test case based on the newly added value in the value range. Thus, the second test case can be used to test whether the target version supports the use of the newly added value in the target configuration item. If the target version supports the use of the newly added value in the target configuration item, it is determined that the target version supports the use of the target configuration item.

[0361] It should be noted that for other related instructions of Example 2, please refer to the above Example 1, which will not be repeated here.

[0362] Example 3: The historical version of the target microservice is configured with a target configuration item. When the developer develops the target version, the value in the value range of the target configuration item is not changed. Based on this, the tester can write a second test case based on at least part of the value of the target configuration item. Thus, the second test case can be used to test whether the target version supports the use of the target configuration item in the historical version.

[0363] It should be noted that for other related instructions of Example 3, please refer to the above Example 1, which will not be repeated here.

[0364] In an embodiment of the present application, the second test case may be a test case in Example 1, Example 2 or Example 3 above, or may be a test case combining Example 1 and Example 3 above, or may be a test case combining Example 2 and Example 3, etc.

[0365] It should be noted that the embodiment of the present application does not limit the type of the second test case, and the above is only an exemplary description.

[0366] Below, taking Example 1 as an example, the content of the second test case is exemplarily introduced.

[0367] The target version of the target microservice may include the first business logic, the second business logic, and the third business logic, and the value range of the target configuration item may include the first value and the third value, wherein the first value indicates the first business logic, and the third value indicates the third business logic.

[0368] Exemplarily, the second test case may include a first executable code, wherein the first executable code indicates at least one of running a first business logic indicated by a first value and running a third business logic indicated by a third value.

[0369] Exemplarily, the second test case may include a second executable code, wherein the second executable code indicates at least one of configuring the value of the target configuration item to be the first value and configuring the value of the target configuration item to be the third value.

[0370] In the embodiment of the present application, after the tester has written the second test case, the second test case can be stored in the cloud or in a storage medium. On this basis, the computing device can obtain the second test case from the cloud or in the storage medium.

[0371] It should be noted that the embodiment of the present application does not limit the method for obtaining the second test case, and the above is only an exemplary description.

[0372] Step 502: The computing device runs the second test case to obtain a test result of the second test case.

[0373] The test result of the second test case is used to indicate whether the target configuration item passes the test or fails the test.

[0374] It can be understood that since the second test case is used to test whether the configuration item can be called / run normally by the microservice, the second test case can also be called a test case for the configuration item.

[0375] In the embodiment of the present application, if no exception occurs during the process of the computing device executing the business logic corresponding to different values ​​of the target configuration item, the test result of the second test case is passed. Conversely, if an exception occurs during the process of executing the business logic corresponding to different values ​​of the target configuration item, the test result of the second test case is failed.

[0376] It should be noted that for relevant descriptions on the occurrence of exceptions, reference may be made to the descriptions on the occurrence of exceptions in test cases in the relevant technologies, and the embodiments of the present application do not impose any restrictions on this.

[0377] In the following, the target business logic includes the first business logic and the third business logic as an example to exemplarily introduce the embodiments of the present application.

[0378] In the embodiment of the present application, after the computing device obtains the second test case, it implements the first business logic indicated by the first value and the third business logic indicated by the third value by running the second test case.

[0379] Exemplarily, the computing device may automatically call the target configuration item by running the first executable code, and run the business logic indicated by the current value of the target configuration item, such as the first business logic, the third business logic, etc.

[0380] In one example, the computing device automatically modifies the value of the target configuration item by running the second executable code, such as modifying the value of the target configuration item to the first value, the third value, etc. This helps to improve the automation level of the second test case, and further helps to improve the execution efficiency and convenience of the test process.

[0381] In another example, when the computing device runs the second test case, if the computing device has finished running the first business logic, the tester can manually modify the value of the target configuration item to the third value. This helps to increase the diversity of the execution methods of the second test case, and further helps to increase the flexibility of the test execution process.

[0382] It should be noted that the embodiment of the present application does not limit the execution order of different business logics in the target business logic, and the above is only an exemplary description.

[0383] In an embodiment of the present application, the computing device can run the target business logic of the target microservice, that is, the business logic indicated by the target configuration item, by running the second test case, thereby realizing automatic detection of the logical branches corresponding to the target configuration item, and whether the target version supports the use of the target configuration item for detection, that is, whether the target version and the target configuration item are matched.

[0384] Step 503: When the test result of the second test case indicates that the target configuration item passes the test, the computing device updates the version range corresponding to the target configuration item, and the updated version range includes the target version.

[0385] In the embodiment of the present application, the computing device may determine that the version range corresponding to the target configuration item includes the target version based on the test result of the second test case indicating that the target configuration item test has passed.

[0386] Example 1: If the test result of the second test case indicates that the target configuration item passes the test, the version range corresponding to the target configuration item includes the target version. Otherwise, the test ends. Example 2: If the test result of the second test case indicates that the target configuration item passes the test, the target identifier range corresponding to the target version includes the identifier of the target configuration item. Otherwise, the test ends.

[0387] Hereinafter, Example 1 is taken as an example to exemplify the embodiments of the present application.

[0388] In the embodiment of the present application, when the version range corresponding to the target configuration item includes the target version, the computing device may include updating the version range corresponding to the target configuration item so that the updated version range includes the target version.

[0389] The following is an exemplary introduction to the method of updating the version range.

[0390] In an example, if the management mode of the target configuration item is a non-strict mode, and the third version corresponding to the target configuration item does not include the target version, updating the version range may include: updating the target version to the third version.

[0391] In another example, if the management mode of the target configuration item is a non-strict mode and the third version corresponding to the target configuration item includes the target version, the version range may not be updated.

[0392] In another example, if the management mode of the target configuration item is a strict mode, updating the version range may include: adding the target version to the version set. Below, this example is taken as an example to exemplify the embodiment of the present application.

[0393] Exemplarily, if the target configuration item is managed by a configuration center, the computing device may send an update instruction to the configuration center, the update instruction being used to instruct to increase the target version in the version range corresponding to the target configuration item. After receiving the update instruction, the configuration center responds to the update instruction and increases the target version to the version range corresponding to the target configuration item. Alternatively, if the target configuration item is stored on the computing device, the computing device may directly update the version range corresponding to the target configuration item to increase the target version to the version range.

[0394] In the above embodiment, by running the second test case, the business logic indicated by at least one value of the target configuration item is implemented, that is, the target business logic in the target version is implemented, and then the test of whether the target version supports the use of the target configuration item is implemented. On this basis, according to the test result of the second test case indicating that the target configuration item has passed the test, the version range corresponding to the target configuration item is updated, so that the version range corresponding to the target configuration item can be used to indicate whether the target version supports the use of the target configuration item, and then the target configuration item in the change request can be verified according to the version range corresponding to the target configuration item, so as to ensure the validity and stability of the target configuration item in the target version, and avoid the change of the unverified target configuration item from taking effect.

[0395] Optionally, the configuration item testing method may include the following S19.

[0396] S19: When the test result of the second test case indicates that the target configuration item has passed the test, the computing device sets the version status of the target version to indicate that the verified version range includes the target version.

[0397] In one example, before executing the second test case, the configuration center or computing device has stored a version file of the target version, and the version status in the version file indicates unverified. On this basis, if the test result of the second test case indicates that the target configuration item has passed the test, the computing device can update the version status to indicate verified. For example, the value of whether to verify is updated to correct (true).

[0398] In another example, when the test result of the second test case indicates that the target configuration item test has passed, the computing device automatically generates a version file of the target version and sets the version status in the version file to indicate verified.

[0399] It should be noted that the method of setting the "version status to indicate verified" can refer to the method of updating the "version range to include the target version", which will not be repeated here.

[0400] In this embodiment, when the test result of the second test case indicates that the target configuration item has passed the test, the version status is set to indicate verified. This helps to ensure the accuracy of the content indicated by the version status, and further helps to ensure the accuracy of subsequent verification results.

[0401] In the embodiment of the present application, the configuration item testing method may further include the following S20-S21:

[0402] S20: The computing device runs the third test case to obtain a test result of the third test case, wherein the third test case is used to test the target version, and the test result of the third test case is used to indicate whether the target version passes the test or fails the test.

[0403] The test target version can be considered as whether the test target version can run normally, that is, whether there will be any operation exceptions during the test of running the target version. The test target version does not include at least one configuration item supported by the test target version, that is, it does not include whether there will be any operation exceptions after calling at least one configuration item during the test of running the target version. In other words, the test content of the third test case is different from the test content of the second test case.

[0404] It can be understood that since the third test case is a test case for testing a microservice, the third test case can also be referred to as a test case for a microservice.

[0405] It should be noted that regarding how to use the third test case to test the target version, reference may be made to the method of testing microservices in the relevant technology, and the embodiments of the present application do not limit this.

[0406] In one example, the computing device can obtain the third test case from a local storage medium or in the cloud. In another example, a target pipeline is configured on the computing device, and the target pipeline is used to test the target version of the target microservice. Among them, the target pipeline may include a third test case, etc., and the third test case is used to test the target version. Based on this, the computing device can obtain the third test case through the target pipeline. Below, taking this other example as an example, an exemplary description of the embodiment of the present application is given.

[0407] It is understandable that the target pipeline is also used to test the configuration items supported by the target version. Based on this, the target pipeline can also include a second test case, and the second test case can be used to test the configuration items supported by the target version.

[0408] It should be noted that for other related instructions of S20, reference can be made to the instructions in step 501, which will not be repeated here.

[0409] S21: When the test result of the third test case indicates that the target version passes the test and the test result of the second test case indicates that the target configuration item passes the test, the computing device determines that the test result of the target version is passed.

[0410] In an embodiment of the present application, when the test result of the third test case indicates that the target version has passed the test, and the test result of the second test case indicates that the target configuration item has passed the test, it means that the target version can operate normally and the target version supports the use of the target configuration item. In this case, the probability of anomalies occurring when the target version provides services to users is low. Therefore, it can be determined that the test result of the target version has passed the test, so that the target version can be launched in the production environment, and then the target version can provide services to users.

[0411] Exemplarily, when the test result of the third test case indicates that the target version has passed the test, and the test result of the second test case indicates that the target configuration item has passed the test, the computing device may determine that the test status of the target pipeline is a test success, to indicate that the test result of the target version is a test pass. If the test result indicates that the target business logic test has not passed, the test status of the target pipeline is determined to be a test failure.

[0412] Exemplarily, if the test result of the third test case indicates that the target version fails the test, and the test result of the second test case indicates that the target configuration item passes the test, or, the test result of the third test case indicates that the target version passes the test, and the test result of the second test case indicates that the target configuration item fails the test, or, the test result of the third test case indicates that the target version fails the test, and the test result of the second test case indicates that the target configuration item fails the test, it can be determined that the test result of the target version is test failure, that is, the test status of the target pipeline is test failure.

[0413] For example, if the test status of the target pipeline is a test failure, the developer may modify the target version again, such as modifying the target version again based on the failure reason. Afterwards, the modified target version may be tested using the second test case and the third test case.

[0414] In the embodiment of the present application, when the test result of the third test case indicates that the target version has passed the test, and the test result of the second test case indicates that the target configuration item has passed the test, it can be determined that the target version has passed the test as a whole, and the target version can be provided to users for use, such as being deployed in a production environment. In this way, the target version can be put online for use by users only when it can be guaranteed that the target version supports the use of the target configuration item, thereby helping to ensure the stability and reliability of the target version after it is put online.

[0415] Figure 6 A schematic diagram of the life cycle of a configuration item provided in an embodiment of the present application.

[0416] The following, combined Figure 6 , an exemplary introduction to the life cycle of microservice configuration items.

[0417] Exemplarily, the life cycle of a microservice configuration item includes at least three stages. The first stage is the development stage (i.e. Figure 6 The second stage is the testing stage (i.e. Figure 6 The third stage is the verification stage ( Figure 6 STEP 3 verification state shown).

[0418] Among them, the development phase can be carried out in the development environment. When the developer develops a new version of the microservice (such as the target version), he can add configuration items (such as the target configuration items) to the target version, and develop different business logics in the code of the target version based on different values ​​of the target configuration items, that is, different values ​​of the target configuration items indicate different business logics in the target version. In addition, the developer can determine whether the management mode of the target configuration item is a strict mode based on the risk level of the target configuration item. For example, when the risk level is high, each subsequent version needs to be strongly tested (that is, each version must execute the test case of the configuration item (that is, the second test case)), so the management mode can be set to a strict mode.

[0419] It should be noted that developers can also expand the value range of the configuration items of the historical version (hereinafter referred to as historical configuration items), such as adding new values ​​to the value range of the historical configuration items. The following is an exemplary description taking the newly added configuration items as an example.

[0420] Exemplarily, the microservice configuration items (development state) generated by developers may include configuration item identifiers, configuration item value ranges, whether it is a strict mode, current values ​​of configuration items, environment types, etc.

[0421] It should be noted that different configuration items have different configuration item identifiers. The embodiment of the present application does not limit the form of the configuration item identifier, for example, it can be letters, numbers and other characters.

[0422] After the developer completes the development, the new version of the microservice (including the target configuration items) is packaged into a container and sent to the tester, so that the tester can test the new version of the microservice (including the target configuration items).

[0423] The testing phase can be carried out in the test environment, pre-release environment, production environment, etc. After the tester obtains the new version of the microservice, he can automatically / manually incrementally design the tasks to be executed (i.e., TODO tasks) in the test case (i.e., the second test case) of the target configuration item according to the value range of the target configuration item.

[0424] It should be noted that, when the value range of the historical configuration item is expanded, the tester can design the tasks to be executed in the second test case according to the difference between the value range of the historical configuration item and the previous version.

[0425] In addition, testers can also generate a test pipeline for the target version (i.e. Figure 6The test pipeline may include a test case for the target configuration item. Afterwards, the tester may automatically / manually complete the test of the pipeline through a test platform (also referred to as a test case platform). Exemplarily, the test pipeline may include a pipeline identifier, a pipeline name, a microservice release pipeline task status, and the like.

[0426] It should be noted that different assembly lines have different assembly line identifiers. The embodiment of the present application does not limit the form of the assembly line identifier, for example, it can be letters, numbers and other characters.

[0427] During the testing phase, the computing device can test the target version by executing the third test case in the target pipeline, and test whether the target version supports the target configuration item by executing the second test case in the target pipeline. Exemplarily, the computing device can determine the newly added configuration items of the target version (i.e., the target configuration items) by comparing the configuration items of the target version with the configuration items of the historical version of the target microservice. For the newly added configuration items, the access control determines whether the test case of the newly added configuration item passes. If passed, the target microservice publishes the task status of the target pipeline as success, indicating that the target pipeline passes the test. After the test case of the target configuration item (i.e., the configuration branch case) passes the test, the version range corresponding to the target configuration item is updated to add the newly verified version (i.e., the target version) to the version range. Among them, the version range can be a matching microservice version range (i.e., a version set) or a starting effective microservice version (i.e., the third version).

[0428] After the target pipeline passes the test, the target version (including the target configuration items) can be deployed to the production environment. For example, it can be deployed to the microservice platform of the production environment so that users can use the services provided by the target version.

[0429] The verification phase can be performed in a production environment. In a production environment, the target configuration item (i.e., the microservice configuration item (running state)) can include all the contents included in the microservice configuration item (development state) and the version range updated in the testing phase.

[0430] On this basis, when the computing device of the microservice platform is running the target version, if a change request for the target configuration item sent by the operation and maintenance personnel is received, the computing device can perform circuit breaking processing on the configuration items that are not within the version range by running the SDK (such as the SDK of the first software), that is, not executing the content requested by the change request. In addition, by running the SDK, the computing device can also connect to the alarm system, such as sending the first prompt information to notify the operation and maintenance personnel to perform manual processing in time, thereby ensuring that the changes of each configuration item in the production environment are verified, and configuration is performed only after verification.

[0431] In addition, if the version range includes the target version and the version status of the target version indicates unverified, the computing device can perform a version rollback operation and delete the target version in the version range to ensure the accuracy and redundancy of the version range.

[0432] Figure 7 A test process diagram of a configuration item provided in an embodiment of the present application.

[0433] The following, combined Figure 7 , an exemplary introduction to the testing process of microservice configuration items is given.

[0434] For example, when a developer develops a new version of a microservice (such as a target version), they plan and develop configuration items, including environment type, value range, current value, whether it is a strict mode, etc. For example, developers can develop new versions of microservices and configuration items through an integrated development environment (IDE) and an integrated SDK.

[0435] After development is completed, the developer packages the target version (including configuration items) into a container and sends it to the tester. After the tester deploys the container of the target version to the test platform, the target version can be tested through the test platform.

[0436] When testing is needed, the test platform can determine whether the current environment variable (i.e., environment type) indicates the test environment. If so, the test operation continues to be executed. If not, the environment switch is modified so that the environment variable indicates the test environment, and the test cases matching the target version (including test cases for configuration items, such as the second test case mentioned above) are put online so that the test platform can obtain the test cases for the target version.

[0437] When the environment variable indicates the test environment, the test platform performs functional testing of the configuration item, such as: the functional test can be grayscale verification according to the grayscale verification strategy. The functional test of the configuration item can refer to whether the business logic indicated by the configuration item can run normally, that is, whether there will be any abnormal operation when running the business logic indicated by the configuration item.

[0438] If the test result of the configuration branch (i.e., configuration item) is a passed test, the test platform instructs the configuration center of the test environment to automatically update the version range of the corresponding configuration item (such as the supporting microservice version range, the third version, etc.) to add the newly verified version (such as the target version). For example, the test platform can send a setting instruction to the configuration center of the test environment to instruct the configuration center of the test environment to make settings. If the test result of the configuration branch is a failed test, the test platform can execute a switch rollback to instruct the developer to modify the target version.

[0439] When the pipeline gate test of the target version passes (i.e. the test case of the configuration item passes the test), the target version can be deployed to the production environment (i.e. the live network), and the updated version range can be deployed to the configuration center of the production environment. For example, deployment can be performed through the DevOps platform.

[0440] Figure 8 A configuration item change process diagram provided in an embodiment of the present application.

[0441] The following, combined Figure 8 , an exemplary introduction to the microservice configuration item change process.

[0442] Exemplarily, the production environment may include a blue environment and a green environment. When the operation and maintenance personnel need to change the configuration items, they can first verify in the blue environment (such as SDK inspection, acceptance case inspection, etc.). If the verification in the blue environment passes, then verify in the green environment. If the verification in the green environment passes, the configuration item change takes effect. This helps to improve the accuracy of the verification results, as well as the operational stability and reliability of the microservice after the configuration items are changed.

[0443] Based on this, the operation and maintenance personnel send a change request to the computing device running the target version in the blue environment. The change request is used to request a change in the target configuration item so that the blue environment triggers an SDK check, such as: SDK check can perform grayscale verification according to the grayscale verification policy to verify whether the microservice version (i.e., the target version) running in the blue environment supports the use of the target configuration item. If the management mode of the target configuration item is strict mode, the version set corresponding to the target configuration item is checked; if the management mode of the target configuration item is loose mode, the starting effective microservice version corresponding to the target configuration item is checked.

[0444] If the SDK check of the blue environment passes, the target configuration item in the configuration center of the blue environment is changed. After that, the acceptance case can be run to determine whether the acceptance case passes. If the acceptance case passes, the green environment is instructed to trigger the SDK check. If the SDK check fails and / or the acceptance case fails, the alarm system is connected to facilitate timely manual processing. In addition, if the first condition is met, such as: the version range includes the target version and the acceptance case fails, a version rollback can be performed, and the rollback version (i.e., the target version) in the version range is deleted.

[0445] After the green environment triggers the SDK check, production verification can be performed according to the production verification strategy. If the SDK check passes, the target configuration items in the configuration center of the green environment are changed. After that, the acceptance case can be run to determine whether the acceptance case passes. If the acceptance case passes, the configuration item changes in the green environment take effect. If the SDK check fails and / or the acceptance case fails, the process ends, that is, the target configuration items are not changed.

[0446] Based on the above, for public cloud scenarios, the production environment, test environment, and pre-release environment provided in the embodiments of the present application can not only be used as a Software as a Service (SaaS) cloud service by running a configuration item change method to provide cloud tenants with a reliable microservice configuration item change method, but can also be used as a service-oriented configuration center to provide cloud tenants with a more capable configuration center, and can also be used in conjunction with the pipeline capabilities of the Development Operations (DevOps) platform to ensure that the configuration items and microservice versions in the change request are supported for use, and that the configuration items in the change request are verified before the change request is executed.

[0447] For private cloud or hybrid cloud scenarios, the configuration item change method, testing method, etc. provided in the embodiments of the present application can be implemented by deploying the software packages provided in the embodiments of the present application, such as the first software, the second software, and other software packages.

[0448] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the method. In order to achieve the above functions, the configuration item change device includes a hardware structure and / or software module corresponding to the execution of each function. It should be easily appreciated by those skilled in the art that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present application.

[0449] The embodiment of the present application can exemplarily divide the functional modules of the configuration item change device according to the above method. For example, the configuration item change device can include various functional modules corresponding to the various functional divisions, or two or more functions can be integrated into one processing module. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical functional division. There may be other division methods in actual implementation.

[0450] For example, Fig. 9 A possible structural diagram of the configuration item changing device (denoted as configuration item changing device 900) involved in the above-mentioned embodiment is shown. The action performed by the configuration item changing device 900 is implemented by a computing device or by executing corresponding software through a computing device. Among them, the computing device is used to run a target version of a target service, the target version is configured with a target configuration item, and the value of the target configuration item is a first value; the target configuration item is used to configure the software function of the target service, or the target configuration item is used to turn on or off the software function of the target service; the target service includes a single application or a microservice. The configuration item changing device 900 may include a receiving module 901, a verification module 902 and a changing module 903. The receiving module 901 is used to receive a change request when the computing device runs the target version of the target service, and the change request is used to request to change the target configuration item. For example, Figure 4 Step 401 shown. Verification module 902 is used to verify whether the target version supports the use of the target configuration item and obtain a verification result. For example, Figure 4 Step 402 shown. Changing module 903 is used for, when the verification result indicates that the target version supports the use of the target configuration item, the computing device changes the value of the target configuration item to a second value. For example, Figure 4 Step 403 is shown.

[0451] Optionally, the configuration item changing device 900 may further include a testing module 904. The target version includes a first business logic indicated by a first value and a second business logic indicated by a second value; the testing module 904 is used to run a first test case after changing the value of the target configuration item to the second value to obtain a test result of the first test case; the first test case is used to indicate the running of the second business logic, and the test result of the first test case is used to indicate whether the second business logic passes the test or fails the test; the changing module 903 is also used to: when the test result of the first test case indicates that the second business logic fails the test, change the value of the target configuration item to the first value.

[0452] Optionally, the verification module 902 is further configured to: when the test result of the first test case indicates that the second business logic fails the test, delete the first value in the value range of the target configuration item.

[0453] Optionally, verification module 902 is specifically used to: determine the version range corresponding to the target configuration item; the version range is used to indicate the service version that supports the use of the target configuration item; when the version range includes the target version, determine that the verification result indicates that the target version supports the use of the target configuration item; or when the version range does not include the target version, determine that the verification result indicates that the target version does not support the use of the target configuration item.

[0454] Optionally, the configuration item changing device 900 includes an operating module 905. The operating module 905 is further configured to: when the version range does not include the target version, operate the first version of the target service; the first version is selected from the version range.

[0455] Optionally, the verification module 902 is also used to: determine the version status of the target version when the version range includes the target version; the version status is used to indicate that the verified version range includes the target version or the unverified version range includes the target version; and when the version status indicates that the verified version range includes the target version, determine that the verification result indicates that the target version supports the use of the target configuration item.

[0456] Optionally, the verification module 902 is further configured to: when the version status indicates that the unverified version range includes the target version, the computing device determines that the verification result indicates that the target version does not support the use of the target configuration item.

[0457] Optionally, when the version status of the target version indicates that the unverified version range includes the target version, the running module 905 is also used to: run the second version of the target service, and / or delete the target version in the version range; the second version is selected from the version range, and the version status of the second version indicates that the verified version range includes the second version.

[0458] Optionally, the version range includes a version set or a third version; the version set includes at least one service version, and each service version of the at least one service version supports the use of the target configuration item; the third version is used to indicate the minimum service version that supports the use of the target configuration item.

[0459] Optionally, when the management mode of the target configuration item is a strict mode, the version range includes a version set; when the management mode of the target configuration item is a non-strict mode, the version range includes a third version.

[0460] Optionally, the verification module 902 is further used to: determine the environment type of the target service; the environment type includes a production environment or a non-production environment; if the environment type of the target service is a production environment, determine the version range corresponding to the target configuration item.

[0461] Optionally, the verification module 902 is further used to: when the verification result indicates that the target version does not support the use of the target configuration item, return first prompt information based on the change request; the first prompt information is used to indicate that the target version does not support the use of the target configuration item.

[0462] Optionally, the changing module 903 is further used to: determine the value range of the target configuration item when the verification result indicates that the target version supports the use of the target configuration item; and change the value of the target configuration item to the second value when the value range of the target configuration item includes the second value.

[0463] Optionally, the verification module 902 is further used to: return second prompt information based on the change request when the value range of the target configuration item does not include the second value; the second prompt information is used to indicate that the value range of the target configuration item does not include the first value.

[0464] Optionally, verification module 902 is specifically used to: determine a target identification range corresponding to a target version, the target identification range being used to indicate configuration items supported by the target version; when the target identification range includes the identification of a target configuration item, determine that the verification result indicates that the target version supports the use of the target configuration item; or when the target identification range does not include the identification of the target configuration, determine that the verification result indicates that the target version does not support the use of the target configuration item.

[0465] Optionally, before receiving the change request, the test module 904 is also used to: run a second test case to obtain a test result of the second test case; the second test case is used to indicate the target business logic of running the target version, the target business logic includes the business logic indicated by the target configuration item, and the test result of the second test case is used to indicate whether the target configuration item passes the test or fails the test; when the test result of the second test case indicates that the target configuration item passes the test, the version range corresponding to the target configuration item is updated, and the updated version range includes the target version.

[0466] Optionally, the version range includes a version set or a third version; the test module 904 is specifically used to: based on the management mode of the target configuration item being a strict mode, the computing device updates the version set corresponding to the target configuration item; the updated version set includes the target version; based on the management mode of the target configuration item being a non-strict mode and the third version corresponding to the target configuration item not including the target version, the third version corresponding to the target configuration item is updated, and the updated third version includes the target version.

[0467] Optionally, the testing module 904 is further configured to: when the test result of the second test case indicates that the target configuration item has passed the test, set the version status of the target version to indicate that the verified version range includes the target version.

[0468] Optionally, the running module 905 is also used to: run a third test case to obtain a test result of the third test case; the third test case is used to test the target version, and the test result of the third test case is used to indicate whether the target version passes the test or fails the test; when the test result of the third test case indicates that the target version passes the test, and the test result of the second test case indicates that the target configuration item passes the test, the test result of the target version is determined to be a passed test.

[0469] For the detailed description of the above optional methods, please refer to the above method embodiments, which will not be repeated here. In addition, the explanation and description of the beneficial effects of any configuration item change device 900 provided above can refer to the above corresponding method embodiments, which will not be repeated here.

[0470] In the embodiment of the present application, the receiving module 901, the verification module 902, the change module 903, the test module 904 and the operation module 905 can be implemented by software, or can be implemented by hardware. Exemplarily, the implementation of the verification module 902 is introduced below by taking the verification module 902 as an example. Similarly, the implementation of the receiving module 901, the change module 903, the test module 904 and the operation module 905 can refer to the implementation of the verification module 902.

[0471] As an example of a software functional unit, the verification module 902 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the verification module 902 may include code running on multiple hosts / virtual machines / containers.

[0472] It should be noted that the multiple hosts / virtual machines / containers used to run the code can be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code can be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple data centers with similar geographical locations. Generally, a region can include multiple AZs.

[0473] Similarly, multiple hosts / virtual machines / containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

[0474] As an example of a hardware functional unit, the verification module 902 may include at least one computing device, such as a server, etc. Alternatively, the verification module 902 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

[0475] The multiple computing devices included in the verification module 902 can be distributed in the same region or in different regions. The multiple computing devices included in the verification module 902 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the verification module 902 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0476] It should be noted that, in other embodiments, the receiving module 901 can be used to execute any step in the configuration item change method, the verification module 902 can be used to execute any step in the configuration item change method, the change module 903 can be used to execute any step in the configuration item change method, the test module 904 can be used to execute any step in the configuration item change method, and the operation module 905 can be used to execute any step in the configuration item change method. The steps that the receiving module 901, the verification module 902, the change module 903, the test module 904, and the operation module 905 are responsible for implementing can be specified as needed, and the receiving module 901, the verification module 902, the change module 903, the test module 904, and the operation module 905 respectively implement different steps in the configuration item change method to realize all functions of the configuration item change device.

[0477] The present application also provides a computing device 100. Fig.10 As shown, the computing device 100 includes: a bus 102, a processor 104, a memory 106, and a communication interface 108. The processor 104, the memory 106, and the communication interface 108 communicate with each other through the bus 102. The computing device 100 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the computing device 100.

[0478] The bus 102 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.10 The bus 102 is represented by only one line, but it does not mean that there is only one bus or one type of bus. The bus 102 may include a path for transmitting information between various components of the computing device 100 (eg, the memory 106, the processor 104, and the communication interface 108).

[0479] The processor 104 may include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0480] The memory 106 may include a volatile memory, such as a random access memory (RAM). The processor 104 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0481] The memory 106 stores executable program codes, and the processor 104 executes the executable program codes to respectively implement the functions of the aforementioned receiving module 901, the verification module 902, the change module 903, the test module 904, and the running module 905, thereby implementing the configuration item change method. That is, the memory 106 stores instructions for executing the configuration item change method.

[0482] The communication interface 108 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 100 and other devices or a communication network.

[0483] The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0484] like Fig.11 As shown, the computing device cluster includes at least one computing device 100. The memory 106 in one or more computing devices 100 in the computing device cluster may store the same instructions for executing the configuration item change method.

[0485] In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster may also store partial instructions for executing the configuration item change method. In other words, the combination of one or more computing devices 100 may jointly execute the instructions for executing the configuration item change method.

[0486] It should be noted that the memory 106 in different computing devices 100 in the computing device cluster can store different instructions, which are respectively used to execute part of the functions of the configuration item change device. That is, the instructions stored in the memory 106 in different computing devices 100 can implement the functions of one or more modules among the receiving module 901, the verification module 902, the change module 903, the test module 904 and the running module 905.

[0487] In some possible implementations, one or more computing devices in the computing device cluster may be connected via a network, which may be a wide area network or a local area network, etc. Fig.12 A possible implementation is shown. Fig.12 As shown, two computing devices 100A and 100B are connected via a network. Specifically, they are connected to the network via a communication interface in each computing device. In this type of possible implementation, the memory 106 in the computing device 100A stores instructions for executing the functions of the receiving module 901, the verification module 902, the change module 903, and the operation module 905. At the same time, the memory 106 in the computing device 100B stores instructions for executing the functions of the test module 904.

[0488] Fig.12 The connection method between the computing device clusters shown may be based on the consideration that the configuration item change method provided in the present application requires a large amount of computing resources, and therefore it is considered that the functions implemented by the test module 904 are handed over to the computing device 100B for execution.

[0489] It should be understood that Fig.12The functions of the computing device 100A shown in FIG. 1 may also be completed by multiple computing devices 100. Similarly, the functions of the computing device 100B may also be completed by multiple computing devices 100.

[0490] The present application embodiment also provides another computing device cluster. The connection relationship between the computing devices in the computing device cluster can be similar to that of Fig.11 and Fig.12 The connection mode of the computing device cluster is shown. The difference is that the memory 106 in one or more computing devices 100 in the computing device cluster may store the same instructions for executing the configuration item change method.

[0491] In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster may also store partial instructions for executing the configuration item change method. In other words, the combination of one or more computing devices 100 may jointly execute the instructions for executing the configuration item change method.

[0492] The embodiment of the present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes a configuration item change method.

[0493] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by the computing device or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute the configuration item change method.

[0494] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A configuration item change method, characterized in that: Applied to a computing device, the computing device is used to run a target version of a target service, the target version is configured with a target configuration item, the value of the target configuration item is a first value; the target configuration item is used to configure a software function of the target service, or the target configuration item is used to turn on or off the software function of the target service; The target service includes a target monolithic application or a target microservice; The method comprises: The computing device receives a change request when running a target version of a target service, the change request being used to request that a value of the target configuration item be changed to a second value; The computing device verifies whether the target version supports the use of the target configuration item, and obtains a verification result; When the verification result indicates that the target version supports the use of the target configuration item, the computing device changes the value of the target configuration item to the second value.

2. The method according to claim 1, characterized in that: The target version includes a first business logic indicated by the first value and a second business logic indicated by the second value; After the computing device changes the value of the target configuration item to the second value, the method further includes: The computing device runs a first test case to obtain a test result of the first test case; the first test case is used to instruct the running of the second business logic, and the test result of the first test case is used to indicate whether the second business logic passes the test or fails the test; When the test result of the first test case indicates that the second business logic fails the test, the computing device changes the value of the target configuration item to the first value.

3. The method according to claim 1 or 2, characterized in that: The computing device verifies whether the target version supports the use of the target configuration item, and obtains a verification result, including: The computing device determines a version range corresponding to the target configuration item; the version range is used to indicate a service version that supports the use of the target configuration item; In a case where the version range includes the target version, the computing device determines that the verification result indicates that the target version supports the use of the target configuration item; or In a case where the version range does not include the target version, the computing device determines that the verification result indicates that the target version does not support use of the target configuration item.

4. The method according to claim 3, characterized in that Before receiving the change request, the method further includes: The computing device runs a second test case to obtain a test result of the second test case; the second test case is used to indicate the target business logic of the target version to be run, the target business logic includes the business logic indicated by the target configuration item, and the test result of the second test case is used to indicate whether the target configuration item has passed the test or failed the test; When the test result of the second test case indicates that the target configuration item passes the test, the computing device updates the version range corresponding to the target configuration item, and the updated version range includes the target version.

5. The method according to claim 4, characterized in that The method further comprises: The computing device runs a third test case to obtain a test result of the third test case; the third test case is used to test the target version, and the test result of the third test case is used to indicate whether the target version passes the test or fails the test; When the test result of the third test case indicates that the target version passes the test and the test result of the second test case indicates that the target configuration item passes the test, the computing device determines that the test result of the target version is passed.

6. The method according to claim 1, characterized in that The computing device verifies whether the target version supports the use of the target configuration item, and obtains a verification result, including: The computing device determines a target identification range corresponding to the target version, where the target identification range is used to indicate configuration items supported by the target version; In a case where the target identification range includes the identification of the target configuration item, the computing device determines that the verification result indicates that the target version supports the use of the target configuration item; or In a case where the target identification range does not include the identification of the target configuration, the computing device determines that the verification result indicates that the target version does not support the use of the target configuration item.

7. A configuration item changing device, characterized in that: Applied to a computing device, the computing device is used to run a target version of a target service, the target version is configured with a target configuration item, the value of the target configuration item is a first value; the target configuration item is used to configure a software function of the target service, or the target configuration item is used to turn on or off the software function of the target service; The target service includes a target monolithic application or a target microservice; The configuration item changing device comprises: A receiving module, configured to receive a change request when the computing device runs a target version of a target service, wherein the change request is used to request that a value of the target configuration item be changed to a second value; A verification module, used to verify whether the target version supports the use of the target configuration item, and obtain a verification result; A changing module is used to change the value of the target configuration item to the second value when the verification result indicates that the target version supports the use of the target configuration item.

8. The device according to claim 7, characterized in that The target version of the target service includes a first business logic indicated by the first value and a second business logic indicated by the second value; the configuration item changing device also includes a test module; The test module is used to run the first test case after changing the value of the target configuration item to the second value to obtain a test result of the first test case; The first test case is used to instruct the execution of the second business logic, and the test result of the first test case is used to indicate whether the second business logic passes the test or fails the test; The changing module is also used to change the value of the target configuration item to the first value when the test result of the first test case indicates that the second business logic fails the test.

9. The device according to claim 7 or 8, characterized in that The verification module is specifically used for: Determine a version range corresponding to the target configuration item; the version range is used to indicate a service version that supports the use of the target configuration item; In a case where the version range includes the target version, determining that the verification result indicates that the target version supports use of the target configuration item; or In a case where the version range does not include the target version, it is determined that the verification result indicates that the target version does not support the use of the target configuration item.

10. The device according to claim 9, characterized in that The configuration item changing device further includes a testing module; the testing module is further used for: Running a second test case to obtain a test result of the second test case; the second test case is used to indicate running the target business logic of the target version, the target business logic includes the business logic indicated by the target configuration item, and the test result of the second test case is used to indicate whether the target configuration item passes the test or fails the test; When the test result of the second test case indicates that the target configuration item passes the test, the version range corresponding to the target configuration item is updated, and the updated version range includes the target version.

11. The device according to claim 10, characterized in that The test module is also used to: Running a third test case to obtain a test result of the third test case; the third test case is used to test the target version, and the test result of the third test case is used to indicate whether the target version passes the test or fails the test; When the test result of the third test case indicates that the target version passes the test and the test result of the second test case indicates that the target configuration item passes the test, it is determined that the test result of the target version passes the test.

12. The device according to claim 7, characterized in that The verification module is specifically used for: Determine a target identification range corresponding to the target version, where the target identification range is used to indicate configuration items supported by the target version; In a case where the target identification range includes the identification of the target configuration item, determining that the verification result indicates that the target version supports the use of the target configuration item; or In a case where the target identification range does not include the identification of the target configuration, it is determined that the verification result indicates that the target version does not support the use of the target configuration item.

13. A computing device, characterized in that: The computing device includes a processor and a memory; The computing device comprises a processor, a memory and a computer program / instruction stored in the memory; the processor executes the computer program so that the computing device implements the steps of the method according to any one of claims 1 to 6.

14. A computing device cluster, characterized in that: include: at least one computing device, each computing device of the at least one computing device comprising a processor and a memory; Each computing device includes a processor, a memory, and a computer program / instruction stored in the memory; the processor executes the computer program / instruction to enable the computing device cluster to implement the steps of the method as described in any one of claims 1-6.

15. A computer program product, characterized in that The method comprises a computer program / instruction, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 6.

16. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program / instruction, and when the computer program / instruction is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.