A service end gray release control method and system

Abstract

The embodiment of the present application provides a kind of server gray release control method and system, the method includes service end receiving service configuration parameter release request, through configuration management platform, when determining that the distributed business system identified corresponding distributed business system is in non-production release state, it is determined whether each first business subsystem in distributed business system meets service configuration parameter issue condition, if yes, create service configuration parameter issue task, and according to service configuration parameter issue task, the service configuration parameter to be released is sent to each first business subsystem, after determining that each first business subsystem gray release succeeds, parameter file backup instruction is issued to any first business subsystem.Such, can be without relying on database, it can be realized to the gray release of service configuration parameter to be released, and can ensure that distributed system is consistent in the process of configuration service configuration parameter in gray, so that parameter maintenance cost can be reduced.

Description

Technical Field

[0001] This invention relates to the field of financial technology (Fintech), and in particular to a server-side canary release control method and system. Background Technology

[0002] With the development of computer technology, more and more technologies are being applied in the financial sector, and the traditional financial industry is gradually transforming into fintech. However, due to the security and real-time requirements of the financial industry, higher demands are being placed on technology. In the financial sector, as the business needs of financial services continue to increase, the related business parameters also need to be constantly updated. This necessitates the canary release of these updated business parameters so that various business terminals in the distributed cluster can promptly obtain and use these updated parameters. Therefore, how to effectively and promptly release business parameters in a canary release manner has become an urgent problem to be solved.

[0003] Existing canary deployment methods primarily involve the server maintaining all business parameters in the database. Upon receiving a user's request to update business parameters, the server retrieves the corresponding updated parameters from the database and sends them to the business applications. This allows the applications to implement the updated parameters in a canary deployment, facilitating timely operation of the applications. However, this approach suffers from several drawbacks. First, it relies heavily on the database for full maintenance of business parameters, resulting in high maintenance costs. Second, if the server crashes, the applications cannot update their parameters promptly.

[0004] In summary, there is an urgent need for a server-side canary release control method to reduce parameter maintenance costs. Summary of the Invention

[0005] This invention provides a server-side canary release control method and system to reduce parameter maintenance costs.

[0006] In a first aspect, embodiments of the present invention provide a server-side canary release control method, including:

[0007] The server receives a business configuration parameter publishing request; the business configuration parameter publishing request includes the business configuration parameters to be published and the distributed business system identifier.

[0008] The server, through the configuration management platform, determines whether each first business subsystem in the distributed business system meets the conditions for issuing business configuration parameters when it determines that the distributed business system corresponding to the distributed business system identifier is in a non-production release state.

[0009] If yes, the server creates a service configuration parameter issuing task, and when it is determined that the number of the to-be-issued service configuration parameters is greater than a preset threshold, performs sharding processing on the to-be-issued service configuration parameters to determine m pieces of sharded data; sequentially sends the m pieces of sharded data to the first service subsystems, and records the issuing state of the to-be-issued service configuration parameters of the first service subsystems in the service configuration parameter issuing task; each piece of sharded data includes at least one parameter; the issuing state of the to-be-issued service configuration parameters is reported by the first service subsystems.

[0010] After the server determines that the first service subsystems are successfully gray released based on the parameter gray execution state and the parameter synchronous execution state of the first service subsystems in the service configuration parameter issuing task, the server issues a parameter file backup instruction to any first service subsystem; the parameter file backup instruction is used to instruct the first service subsystem to upload the locally stored gray released service configuration parameter file to a file storage system.

[0011] In the above technical solution, through the configuration management platform, when it is determined that the distributed service system identified corresponding distributed service system is in an uncommissioned state, it is determined whether each first service subsystem in the distributed service system meets the service configuration parameter issuing condition, so that it can be determined in time whether the to-be-issued service configuration parameters can be issued, so as to avoid affecting the normal work of the distributed service system due to unreasonable issuing operation. Then, when it is determined that each first service subsystem meets the service configuration parameter issuing condition, a service configuration parameter issuing task is created, and when it is determined that the number of the to-be-issued service configuration parameters is greater than a preset threshold, the to-be-issued service configuration parameters are sharded, and m pieces of sharded data are sent to each first service subsystem, so that each first service subsystem can timely gray release the to-be-issued service configuration parameters. Then, after it is determined that each first service subsystem is successfully gray released, a parameter file backup instruction is issued to any first service subsystem, so that the first service subsystem uploads the locally stored gray released service configuration parameter file to a file storage system, so that the gray released service configuration parameter file can be accurately obtained from the file storage system in time when the distributed system abnormally. In this way, the scheme can realize gray release of the to-be-issued service configuration parameters without relying on the database to maintain the service configuration parameters in full, and can ensure the consistency of the distributed system in the gray process to configure the service configuration parameters in a database-free environment, thereby reducing the parameter maintenance cost and realizing high availability of the gray released service configuration parameter file. In addition, the server can flexibly control the gray release process of the to-be-issued service configuration parameters, and the flexibility of the service configuration parameters can be realized.

[0012] Optionally, after the parameter file backup instruction is issued to any first service subsystem, the method further comprises:

[0013] If a new first service subsystem is added, a first service subsystem closest to the new first service subsystem is determined from the first service subsystems;

[0014] The new first service subsystem acquires the gray-release service configuration parameter file from the closest first service subsystem and generates a first hash value of the gray-release service configuration parameter file;

[0015] The new first service subsystem acquires a second hash value of the gray-release service configuration parameter file from the file storage system;

[0016] The new first service subsystem determines whether the first hash value and the second hash value are consistent;

[0017] If yes, the new first service subsystem confirms that the gray-release service configuration parameter file is available.

[0018] In the above technical solution, since each service subsystem in the distributed service system stores the gray-release service configuration parameter file, when a new service subsystem needs to be added to the distributed service system, the current full-service configuration parameter file can be acquired from the closest service subsystem in time, without acquiring from the database maintained by the server, and without relying on the persistent layer database to maintain the full-service configuration parameter, so that the purpose of extending the new service subsystem in the database-free environment can be achieved.

[0019] Optionally, after the parameter file backup instruction is issued to any first service subsystem, the method further comprises:

[0020] If it is determined that the distributed service system has a failure, a new distributed service system is started;

[0021] For each second service subsystem in the new distributed service system, the second service subsystem acquires the gray-release service configuration parameter file and a third hash value of the gray-release service configuration parameter file from the file storage system and reports the third hash value to the server; and the server is configured to determine whether the third hash values reported by the second service subsystems are consistent;

[0022] The second service subsystem confirms that the gray-release service configuration parameter file is available based on the third hash value consistency indication sent by the server.

[0023] In the technical solution, if it is determined that the distributed business system is abnormal (for example, it is hung due to a fault), a new distributed business system needs to be started for disaster recovery. In this way, each business subsystem in the new distributed business system can obtain the current full set of business configuration parameter files from the file storage system, and use the business configuration parameter files after it is determined that the third hash values reported by the business subsystems are consistent, so that each business subsystem in the new distributed business system can timely and conveniently obtain the current full set of business configuration parameter files.

[0024] Optionally, the method further comprises:

[0025] If the server determines that the third hash values reported by the second business subsystems are inconsistent, the server sends a configuration inconsistency indication to the second business subsystems; the configuration inconsistency indication is used to instruct each second business subsystem to obtain the gray release business configuration parameter files from the file storage system based on the distributed business system identifier, generate fourth hash values of the gray release business configuration parameter files, and report the fourth hash values to the server for verification until it is confirmed that the hash values reported by the second business subsystems are consistent.

[0026] In the technical solution, if it is determined that the distributed business system is abnormal, a new distributed business system needs to be started for disaster recovery. In this way, each business subsystem in the new distributed business system can obtain the current full set of business configuration parameter files from the file storage system, and obtain the gray release business configuration parameter files again and generate fourth hash values of the gray release business configuration parameter files when it is determined that the third hash values reported by the business subsystems are inconsistent, until the server confirms that the hash values reported by the second business subsystems are consistent, so as to ensure that the current full set of business configuration parameter files obtained by the second business subsystems are accurate.

[0027] Optionally, the method further comprises:

[0028] The server interrupts the business configuration parameter release request through the configuration management platform when it is determined that the distributed business system corresponding to the distributed business system identifier is in a production release state.

[0029] In the technical solution, in order to prevent repeated gray release of business configuration parameters from affecting the operation of the distributed business system, and to avoid repeated gray release of business configuration parameters from causing the distributed business system to be abnormal, if it is determined through the configuration management platform that the distributed business system in the business configuration parameter request is in a production release state, the business configuration parameter release request is immediately interrupted, so that the server can timely and effectively control the business configuration parameter release request.

[0030] Optionally, the determining whether each first service subsystem in the distributed service system satisfies the service configuration parameter issuing condition comprises:

[0031] For each first service subsystem, the server queries the central processing unit (CPU) usage, memory usage and thread pool state of the first service subsystem through the configuration management platform.

[0032] The server determines whether the CPU usage of the first service subsystem satisfies a first preset condition, whether the memory usage of the first service subsystem satisfies a second preset condition, and whether the thread pool state of the first service subsystem satisfies a third preset condition.

[0033] In the above technical solution, in order to know whether the distributed service system currently has the condition of gray publishing service configuration parameters in time, the running state of each service subsystem in the distributed service system is queried through the configuration management platform, such as the CPU usage, memory usage and thread pool state of each service subsystem, and the CPU usage, memory usage and thread pool state of each service subsystem are compared with the corresponding preset conditions (i.e. preset alarm threshold) respectively, so as to determine whether the server can currently perform service configuration parameter issuing in time and effectively, so as to realize the dynamic control of the server for service configuration parameter issuing.

[0034] Optionally, the sending the m pieces of shard data to each first service subsystem comprises:

[0035] The server sends a data shard issuing instruction to each first service subsystem, and after determining that each first service subsystem receives the data shard issuing instruction, the server sends each piece of shard data in the m pieces of shard data to each first service subsystem in turn.

[0036] After determining that each first service subsystem receives the m pieces of shard data, the server sends a shard data merging instruction to each first service subsystem; the shard data merging instruction is used to instruct each first service subsystem to merge the m pieces of shard data according to the actual arrangement order of the shard data.

[0037] In the technical solution, if the quantity of the to-be-published service configuration parameters is greater than the preset threshold, in order to avoid the impact of a large quantity of service configuration parameters on the normal operation of the distributed service system, and to avoid the excessive network resources consumed by the one-time large quantity of service configuration parameters transmission affecting other normal network transmission of the server, the service configuration parameters are subjected to fragmentation processing, so that the server transmits only a part of the to-be-published parameters to the distributed service system each time, thereby reducing the network resources consumed by the service configuration parameter transmission, reducing the impact on the normal operation of the distributed service system, and reducing the impact on other normal network transmission of the server. In addition, if one or more service subsystems fail to publish the service configuration parameters, the server re-executes the service configuration parameter publishing process for the failed service subsystems until the publishing state of all service subsystems in the distributed service system is successful, thereby achieving the timely and effective management and control of the service configuration parameter publishing of the service subsystems.

[0038] Optionally, after recording the publishing state of the to-be-published service configuration parameters of the first service subsystems in the service configuration parameter publishing task, the method further comprises:

[0039] After determining that the to-be-published service configuration parameters are successfully published based on the publishing state of the to-be-published service configuration parameters of the first service subsystems, the server determines n first service subsystems for gray publishing of the to-be-published service configuration parameters from the first service subsystems.

[0040] The server publishes a parameter gray publishing instruction to the n first service subsystems, and records a parameter gray publishing execution state of the n first service subsystems in the service configuration parameter publishing task; the parameter gray publishing instruction is used to instruct the n first service subsystems to perform gray publishing on the to-be-published service configuration parameters.

[0041] In the technical solution, in order to ensure that the service provided by the distributed service system is not affected in the process of gray publishing the service configuration parameters, the scheme selects one or more service subsystems to publish the service configuration parameters in the gray manner after determining that the service configuration parameters to be published are successfully issued, and the other service subsystems normally operate to provide the service. In this way, the scheme implements the gray publishing of the service configuration parameters for each service subsystem in the distributed service system in multiple times, thereby ensuring that the service can be normally provided in the process of gray publishing the service configuration parameters. In addition, if the server learns that one or more service subsystems fail in the gray publishing of the service configuration parameters, the server re-executes the process of the gray publishing of the service configuration parameters for the service subsystems that fail in the gray publishing, until the gray execution states of the service configuration parameters of all the service subsystems in the distributed service system are successful, so that the server can effectively manage and control the gray publishing of the service configuration parameters of the service subsystems in time.

[0042] Optionally, after recording the parameter gray execution states of the n first service subsystems in the service configuration parameter issuing task, the method further includes:

[0043] After determining that the gray publishing of the service configuration parameters of the first service subsystems is successful based on the parameter gray execution states of the first service subsystems, the server issues a parameter synchronization instruction to the first service subsystems, and records the parameter synchronization execution states of the first service subsystems in the service configuration parameter issuing task. The parameter synchronization instruction is used to instruct the first service subsystems to synchronize the service configuration parameters stored in a first parameter file to a second parameter file to obtain a service configuration parameter file after the gray publishing. The first parameter file is a parameter file read by the first service subsystem in the gray publishing process. The second parameter file is a parameter file read by the first service subsystem in the application process.

[0044] In the technical solution, after the server determines that each first business subsystem succeeds in the gray release of the to-be-released business configuration parameters, the server sends a parameter synchronization instruction to each first business subsystem, so that each first business subsystem can synchronize the first parameter file to the second parameter file in time to obtain the business configuration parameter file after the gray release, and each first business subsystem can read the business configuration parameter file after the gray release in time in the application process. In addition, during the synchronization of the business configuration parameters, if the server learns that one or more business subsystems fail in the synchronization of the business configuration parameters, the server re-executes the process of the synchronization of the business configuration parameters for the business subsystems that fail in the synchronization, until the synchronization of the business configuration parameters of all the business subsystems in the distributed business system is successful. In this way, the server can effectively manage and control the synchronization of the business configuration parameters of the business subsystems in time.

[0045] Optionally, after the parameter gray release instruction is sent to the n first business subsystems, the method further includes:

[0046] The server receives the gray release execution result, the hash value of the first parameter file, the hash value of the second parameter file, and the hash value of the gray control file reported by the n first business subsystems.

[0047] For each first business subsystem of the n first business subsystems, the server determines whether the hash value of the first parameter file of the first business subsystem is consistent with the hash value of the first parameter file of the first business subsystem that has succeeded in the gray release, whether the hash value of the second parameter file of the first business subsystem is consistent with the hash value of the second parameter file of the first business subsystem that has succeeded in the gray release, and whether the hash value of the gray control file of the first business subsystem is consistent with the hash value of the gray control file of the first business subsystem that has succeeded in the gray release.

[0048] If the server determines that at least one of the hash values of the files of the first business subsystem is inconsistent with the hash value of the corresponding file of the first business subsystem that has succeeded in the gray release, the server records the hash value verification failure in the gray release execution state of the first business subsystem.

[0049] In the technical solution, before the synchronization of the to-be-released business configuration parameters, in order to ensure that each first business subsystem succeeds in the gray release, the hash values of the files of each first business subsystem in each gray release are verified, so that whether each first business subsystem succeeds in the gray release can be obtained in time, thereby providing support for accurately executing the synchronization of the to-be-released business configuration parameters subsequently.

[0050] In a second aspect, the embodiment of the present application further provides a server gray release control system, which comprises:

[0051] receive a service configuration parameter publishing request; the service configuration parameter publishing request includes service configuration parameters to be published and a distributed service system identifier;

[0052] The processing unit is configured to, through the configuration management platform, determine whether each first service subsystem in the distributed service system meets a service configuration parameter delivery condition when it is determined that the distributed service system corresponding to the distributed service system identifier is in a non-production publishing state; if so, create a service configuration parameter delivery task, and when it is determined that the number of the service configuration parameters to be published is greater than a preset threshold, perform sharding processing on the service configuration parameters to be published to determine m pieces of sharding data; send the m pieces of sharding data to each first service subsystem, and record the delivery state of the service configuration parameters to be published of each first service subsystem in the service configuration parameter delivery task; each piece of sharding data includes at least one parameter; the delivery state of the service configuration parameters to be published is reported by the first service subsystem; after it is determined that each first service subsystem successfully performs gray publishing based on the parameter gray execution state and the parameter synchronous execution state of each first service subsystem in the service configuration parameter delivery task, issue a parameter file backup instruction to any first service subsystem; the parameter file backup instruction is used to instruct the first service subsystem to upload a locally stored service configuration parameter file after gray publishing to a file storage system. BRIEF DESCRIPTION OF DRAWINGS

[0053] In order to more clearly illustrate the technical solutions in the embodiments of the present application, a brief introduction will be given below to the drawings needed to be used in the embodiment descriptions. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without any creative effort on the basis of these drawings.

[0054] Figure 1 A possible system architecture schematic diagram is provided for the embodiments of the present application.

[0055] Figure 2 A flowchart of a service end gray publishing control method is provided for the embodiments of the present application.

[0056] Figure 3 A structure schematic diagram of a service end gray publishing control system is provided for the embodiments of the present application.

[0057] Figure 4 A structure schematic diagram of a computing device is provided for the embodiments of the present application. DETAILED DESCRIPTION

[0058] In order to make the objects, technical solutions and advantages of the present application clearer, the following will further describe the present application in detail with reference to the drawings. Obviously, the described embodiments are only some but not all of the embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts should fall into the protection scope of the present application.

[0059] The following first explains some terms involved in the embodiments of the present application, so as to facilitate the understanding of those skilled in the art.

[0060] (1) sdk: Software Development, software development kit, generally a collection of development tools for software engineers to develop application software for specific software packages, software frameworks, hardware platforms, operating systems, etc.

[0061] (2) bmp-server-sdk: nested in the server side (such as the web server side), used to manage the entire business configuration parameter life cycle and delivery, such as managing the process from business configuration parameter delivery to business configuration parameter gray scale to business configuration parameter synchronization.

[0062] (3) Gray scale: the business subsystem does not read the second parameter file, but reads the first parameter file. Because the first parameter file is written with the business configuration parameters to be released at this time, and the second parameter file is temporarily not written.

[0063] (4) Rollback: that is, before the complete delivery process is completed, the business parameter configuration interface can be manually canceled this time gray release, and each business subsystem is rolled back to the configuration file before the configuration delivery. Rollback is the final state, and the task is completed.

[0064] (5) Gray control file: in the gray process, save which business subsystem needs to read the first parameter file.

[0065] (6) Data rollback: synchronize the first parameter file to the second parameter file.

[0066] As described above, some terms involved in the embodiments of the present application are introduced, and the technical features involved in the embodiments of the present application are introduced.

[0067] In order to facilitate the understanding of the embodiments of the present application, first, the system structure shown in Figure 1 The system architecture can include a server 100 and at least one distributed business system (such as a distributed business system 201, a distributed business system 202, etc.). Figure 1

[0068] ​The service end 100 has information processing and information forwarding functions, and can be a single server or a server cluster. For example, the service end 100 can be a single physical server or a server cluster formed by multiple physical servers. Each distributed business system can include at least one business subsystem. For example, the distributed business system 201 can include a business subsystem A, a business subsystem B, and a business subsystem C, and the distributed business system 202 can include a business subsystem D, a business subsystem E, and a business subsystem F. In addition, the service end 100 and each distributed business system can be connected by a wired or wireless communication connection, and the embodiments of the present application do not limit the same.

[0069] For example, the distributed business system 201 is described. When the user needs to perform a gray release of a business parameter of the distributed business system 201, the service end 100 can provide a parameter configuration interface to the user, so that the user performs editing operations such as modification, addition, or deletion of the parameter in the parameter configuration interface, and generates a business configuration parameter release request based on the edited business parameter. The business configuration parameter release request includes the to-be-released business configuration parameter and the distributed business system identifier. The parameters provided by the parameter configuration interface of the service end 100 are obtained from the corresponding distributed business system of the distributed business system identifier. After the service end 100 generates the business configuration parameter release request, the service end 100 distributes the to-be-released business configuration parameter to the distributed business system corresponding to the distributed business system identifier, so that the distributed business system performs a gray release of the to-be-released business configuration parameter. In addition, the service end 100 controls the gray release process of each business subsystem in the distributed business system during the process of the distributed business system performing the gray release of the business configuration parameter. In addition, the service end 100 creates a business configuration parameter distribution task, which is responsible for recording the gray release state of each business subsystem in the distributed business system. For example, if the business subsystem A fails during the process of distributing the business configuration parameter, the service end 100 controls the business subsystem A to re-execute the process of distributing the business configuration parameter until the distribution state of the business configuration parameter of the business subsystem A is successful. Alternatively, if the business subsystem A fails during the process of performing the gray release of the business configuration parameter, the service end 100 controls the business subsystem A to re-execute the process of performing the gray release of the business configuration parameter until the gray release state of the business configuration parameter of the business subsystem A is successful. Then, the service end 100 distributes a parameter file backup instruction to any business subsystem, so that the business subsystem uploads the locally stored business configuration parameter file after the gray release to the file storage system for backup.

[0070] It should be noted that the aboveFigure 1 The structure shown is only an example, and embodiments of the application are not limited thereto.

[0071] Based on the above description, Figure 2 An exemplary flow of a service end gray release control method provided by embodiments of the application is shown, which can be executed by a service end gray release control system.

[0072] As Figure 2 The flow specifically includes:

[0073] Step 201, the service end receives a service configuration parameter release request.

[0074] In embodiments of the application, the service configuration parameter release request can include a to-be-released service configuration parameter and a distributed service system identifier. The to-be-released service configuration parameter is obtained by updating a service configuration parameter acquired from a distributed service system corresponding to the distributed service system identifier.

[0075] Before receiving the service configuration parameter release request, the service end will embed a java sdk, namely bmp-server-sdk. When a user needs to adjust the service configuration parameter of a certain distributed service system, for example, as the business increases or a certain business is updated, the business parameter also needs to be adjusted accordingly. At this time, the user will adjust the service configuration parameter in the distributed service system corresponding to the business. First, the existing service configuration parameter of the distributed service system, such as the kv parameter (i.e., the key-value parameter), will be queried on the business parameter configuration interface provided by the service end. The existing service configuration parameter is queried from the distributed service system by the service end and displayed on the business parameter configuration interface, so as to adjust the existing service configuration parameter by the user. The user can adjust one or more business parameters in the existing service configuration parameter, and of course, can also adjust all business parameters in the existing service configuration parameter. For example, the user can modify the business parameter, delete the business parameter, or increase the business parameter, etc. After the user adjusts the existing service configuration parameter (such as the kv parameter), the submit for approval button can be clicked, and at this time, the service configuration parameter release request is generated.

[0076] Exemplarily, a business of a distributed business system 1 changes, at which time, it is required to modify the business configuration parameters of the distributed business system 1, for example, it is required to modify 5 business parameters of the distributed business system 1. A user can query the existing business configuration parameters of the distributed business system 1 on a business parameter configuration interface provided by a server (for example, a web server) and modify the 5 business parameters in the existing business configuration parameters. After the 5 business parameters are modified, a submit for approval button is clicked to generate a business configuration parameter publishing request. The business configuration parameter publishing request includes an identifier of the distributed business system 1 and to-be-published business configuration parameters. The to-be-published business configuration parameters include the modified 5 business parameters and other business parameters that are not modified.

[0077] In step 202, the server determines whether each first business subsystem in the distributed business system satisfies a business configuration parameter delivery condition through the configuration management platform when it is determined that the distributed business system corresponding to the distributed business system identifier is in the non-production publishing state.

[0078] In the embodiment of the present application, after receiving the service configuration parameter publishing request submitted by the user, the server determines whether the distributed service system corresponding to the distributed service system identifier is in the production publishing state through the configuration management platform. If the distributed service system is in the production publishing state, the service configuration parameter publishing request is immediately interrupted. In this way, the influence of repeated gray publishing of service configuration parameters on the operation of the distributed service system can be prevented, and the abnormality of the distributed service system caused by repeated gray publishing of service configuration parameters can be avoided, thereby realizing timely and effective control of the server on the service configuration parameter publishing request. If the distributed service system is not in the production publishing state, it is determined whether each first service subsystem in the distributed service system meets the service configuration parameter issuing condition, that is, for each first service subsystem, the server queries the central processing unit (CPU) usage rate, memory usage rate, and thread pool state of the first service subsystem through the configuration management platform, and determines whether the CPU usage rate of the first service subsystem meets the first preset condition, whether the memory usage rate of the first service subsystem meets the second preset condition, and whether the thread pool state of the first service subsystem meets the third preset condition. In this way, the running state of each service subsystem in the distributed service system can be queried through the configuration management platform, such as the CPU usage rate, memory usage rate, and thread pool state of each service subsystem, and the CPU usage rate, memory usage rate, and thread pool state of each service subsystem are compared with the corresponding preset conditions (i.e., preset alarm thresholds) respectively, so as to timely and effectively determine whether the server can currently issue service configuration parameters, and to timely know whether the distributed service system currently has the condition of gray publishing service configuration parameters, thereby realizing dynamic control of the server on the service configuration parameter issuing.

[0079] Specifically, after receiving the service configuration parameter publishing request submitted by the user, the server queries, through the bmp-server-sdk, a CMDB (Configuration Management Database) interface, whether the distributed system corresponding to the distributed system identifier is in a production publishing state from the CMDB. If the distributed system is in the production publishing state, the service configuration parameter publishing request is interrupted, that is, the submission for review is stopped. If the distributed system is not in the production publishing state, the bmp-server-sdk queries, through the CMDB interface, whether the port of each business subsystem in the distributed business system is in a live state (that is, whether each business subsystem is in a normal working state) from the CMDB. For each business subsystem, if the port of the business subsystem is in the live state, the service configuration parameter can be issued to the business subsystem, otherwise, even if the service configuration parameter is issued to the business subsystem, the business subsystem cannot publish the service configuration parameter in a gray manner, so when it is determined that the port of the business subsystem is not in the live state, the service configuration parameter publishing request is interrupted, that is, the submission for review is stopped.

[0080] After it is determined that the ports of the business subsystems in the distributed business system are in the live state, the bmp-server-sdk queries, through the CMDB interface, whether each business subsystem in the distributed business system satisfies the service configuration parameter issuing condition from the CMDB, that is, the CPU usage, the memory usage (such as the jvm memory usage), and the thread pool state of each business subsystem in the distributed business system are queried from the CMDB, the CPU usage is compared with the corresponding CPU threshold, the memory usage is compared with the corresponding memory threshold, and the thread pool state is compared with the corresponding thread preset threshold. The thread pool state includes the current active thread count active_count, the task number in the task waiting queue, the core thread count core_pool_size, and the thread idle waiting time keep_alive_time. For each business subsystem, if the CPU usage of the business subsystem is less than or equal to the corresponding CPU threshold, the memory usage is less than or equal to the corresponding memory threshold, the current active thread count is less than or equal to the core thread count, the task number in the task waiting queue is less than or equal to the core thread count, and the thread idle waiting time is greater than or equal to 60 seconds, it is determined that the business subsystem satisfies the service configuration parameter issuing condition. If the CPU usage of the business subsystem is greater than the corresponding CPU threshold, or the memory usage is greater than the corresponding memory threshold, the current active thread count is greater than the core thread count, or the task number in the task waiting queue is greater than the core thread count, or the thread idle waiting time is less than 60 seconds, the service configuration parameter publishing request is interrupted, that is, the submission for review is stopped.

[0081] After determining that each business subsystem in the distributed business system meets the business configuration parameter issuing condition, the business configuration parameter publishing request is submitted to the approval chain. The approval chain intercepts the business configuration parameter publishing request and verifies the business configuration parameter request. After verification, the business configuration parameter request is submitted to the person in charge for manual review. After determining that the manual review is passed, the server creates a business configuration parameter issuing task through the bmp-server-sdk. When the server generates the business configuration parameter publishing request, it also generates a regular expression for each business parameter in the business configuration parameter request to generate a regular expression for each business parameter in the business configuration parameter request. Then, when the approval chain verifies the business configuration parameter request, it verifies the regular expression of each business parameter in the business configuration parameter request to determine whether each business parameter meets the business parameter format requirement.

[0082] For example, continue to describe the distributed business system 1. Assume that the distributed business system has three business subsystems, i.e., business subsystem A, business subsystem B, and business subsystem C. After the server receives the business configuration parameter publishing request of the user for the distributed business system 1, it calls the CMDB interface through the bmp-server-sdk to query whether the distributed system 1 is in the production publishing state from the CMDB. If the distributed system 1 is in the production publishing state, the business configuration parameter publishing request is interrupted, i.e., the audit is stopped. If the distributed system 1 is not in the production publishing state, the server calls the CMDB interface through the bmp-server-sdk to query whether the port of each business subsystem in the distributed business system 1 is in the alive state from the CMDB, i.e., to determine whether the ports of the business subsystem A, the business subsystem B, and the business subsystem C are in the alive state. If it is determined that the port of a business subsystem (such as the business subsystem A) is not in the alive state, the business configuration parameter publishing request is interrupted. If it is determined that the ports of the business subsystem A, the business subsystem B, and the business subsystem C are in the alive state, the server calls the CMDB interface through the bmp-server-sdk to query the CPU usage, the memory usage, and the thread pool state of each business subsystem in the distributed system 1 from the CMDB, i.e., to query the CPU usage, the memory usage, and the thread pool state of the business subsystem A, the business subsystem B, and the business subsystem C. Then, for each business subsystem, the CPU usage of the business subsystem is compared with the corresponding CPU threshold, the memory usage is compared with the corresponding memory threshold, and the thread pool state is compared with the corresponding thread preset threshold.

[0083] For example, taking business subsystem A as an example, it is assumed that the CPU usage of business subsystem A is less than or equal to the corresponding CPU threshold value, the memory usage is less than or equal to the corresponding memory threshold value, the current number of active threads is less than or equal to the core thread number, the number of tasks in the task waiting queue is less than or equal to the core thread number, and the thread idle waiting time is greater than or equal to 60 seconds. It is determined that business subsystem A meets the business configuration parameter issuing condition. It is assumed that the CPU usage of business subsystem A is greater than the corresponding CPU threshold value, the memory usage is less than or equal to the corresponding memory threshold value, the current number of active threads is less than or equal to the core thread number, the number of tasks in the task waiting queue is less than or equal to the core thread number, and the thread idle waiting time is greater than or equal to 60 seconds. Or the CPU usage of business subsystem A is less than or equal to the corresponding CPU threshold value, the memory usage is greater than the corresponding memory threshold value, the current number of active threads is less than or equal to the core thread number, the number of tasks in the task waiting queue is less than or equal to the core thread number, and the thread idle waiting time is greater than or equal to 60 seconds. Or the CPU usage of business subsystem A is greater than the corresponding CPU threshold value, the memory usage is less than or equal to the corresponding memory threshold value, the current number of active threads is greater than the core thread number, the number of tasks in the task waiting queue is less than or equal to the core thread number, and the thread idle waiting time is greater than or equal to 60 seconds. Or the CPU usage of business subsystem A is greater than the corresponding CPU threshold value, the memory usage is less than or equal to the corresponding memory threshold value, the current number of active threads is less than or equal to the core thread number, the number of tasks in the task waiting queue is greater than the core thread number, and the thread idle waiting time is greater than or equal to 60 seconds. Or the CPU usage of business subsystem A is greater than the corresponding CPU threshold value, the memory usage is less than or equal to the corresponding memory threshold value, the current number of active threads is less than or equal to the core thread number, the number of tasks in the task waiting queue is less than or equal to the core thread number, and the thread idle waiting time is less than 60 seconds. It is determined that business subsystem A does not meet the business configuration parameter issuing condition, and the business configuration parameter publishing request will be immediately interrupted.

[0084] In step 203, if it is determined that each first business subsystem in the distributed business system meets the business configuration parameter issuing condition, the server creates a business configuration parameter issuing task, and performs sharding processing on the to-be-published business configuration parameters to determine m pieces of shard data when it is determined that the number of to-be-published business configuration parameters is greater than a preset threshold value. The m pieces of shard data are sent to each first business subsystem, and the delivery state of the to-be-published business configuration parameters of each first business subsystem is recorded in the business configuration parameter issuing task.

[0085] In the embodiment of the present application, the server will create a service configuration parameter issuing task after determining that each first service subsystem in the distributed service system satisfies the service configuration parameter issuing condition, the service configuration parameter issuing task is used to record the parameter gray execution state, the parameter synchronization execution state and the issuing state of the to-be-issued service configuration parameter of each first service subsystem. Of course, when creating the service configuration parameter issuing task, the CMDB interface is called through the bmp-server-sdk to query whether there is a task of ongoing configuration issuing in the distributed service system from the CMDB, if there is, the service configuration parameter issuing task cannot be created, and at the same time, the lock of the CMDB concurrent table is used to control that the service configuration parameter issuing task for the distributed service system cannot be created, because two or more service configuration parameter issuing tasks cannot be created at the same time.

[0086] Specifically, when creating a service configuration parameter delivery task, a task group record (i.e., a taskGroup record) and multiple task detail records (i.e., taskDetail records) are inserted through the bmp-server-sdk, wherein each service subsystem corresponds to a task detail record. The task group record is used to record the overall state of the distributed service system. That is, the overall gray-scale execution state, the overall synchronization execution state, and the overall delivery state of the business configuration parameters to be published of the distributed service system; the task detail record is used to record the gray-scale execution state, the synchronization execution state, and the delivery state of the business configuration parameters to be published of the corresponding service subsystem. For example, continue to take the distributed service system 1 as an example for description, assuming that the distributed service system has two service subsystems, i.e., service subsystem A and service subsystem B. For example, taking the gray-scale process of the service subsystem as an example for description, assuming that the service subsystem A successfully performs the gray-scale execution for the business configuration parameters, and the service subsystem B successfully performs the gray-scale execution for the business configuration parameters, the task detail record corresponding to the service subsystem A will record that the gray-scale execution state of the service subsystem A is successful, and the task detail record corresponding to the service subsystem B will record that the gray-scale execution state of the service subsystem B is successful, at this time, the task group record corresponding to the distributed service system 1 will record that the overall gray-scale execution state of the distributed service system 1 is successful. Assuming that the service subsystem A successfully performs the gray-scale execution for the business configuration parameters, and the service subsystem B fails to perform the gray-scale execution for the business configuration parameters, the task detail record corresponding to the service subsystem A will record that the gray-scale execution state of the service subsystem A is successful, and the task detail record corresponding to the service subsystem B will record that the gray-scale execution state of the service subsystem B is failed, at this time, the task group record corresponding to the distributed service system 1 will record that the overall gray-scale execution state of the distributed service system 1 is failed. In addition, if the task group record corresponding to the distributed service system 1 records that the overall gray-scale execution state of the distributed service system 1 is failed, the server can set a task of re-executing the gray-scale of the business configuration parameters at regular intervals until the overall gray-scale execution state of the task group record is successful. In this way, the server can effectively manage and control the gray-scale publishing of the business configuration parameters of the service subsystem in a timely manner. The synchronization execution state, the delivery state of the business configuration parameters to be published of the distributed service system 1 can also be recorded in the same way as the gray-scale execution state, which will not be described here.

[0087] After the business configuration parameter delivery task is created, the to-be-published business configuration parameters can be sent to each first business subsystem according to the business configuration parameter delivery task. Specifically, after the business configuration parameter task is created, the user can click the configuration delivery button on the business parameter configuration interface to deliver the to-be-published business configuration parameters. If the number of the to-be-published business configuration parameters is greater than the preset threshold, the to-be-published business configuration parameters need to be processed by fragmentation to determine m pieces of fragmented data. Then the m pieces of fragmented data are sent to each first business subsystem in turn, and the delivery status of the to-be-published business configuration parameters of each first business subsystem is recorded in the business configuration parameter delivery task. Each piece of fragmented data includes at least one parameter; and the delivery status of the to-be-published business configuration parameters is reported by the first business subsystem. In this way, in order to avoid the impact of a large number of business configuration parameters on the normal operation of the distributed business system, and in order to avoid excessive network resources consumed by the one-time large batch transmission of business configuration parameters affecting other normal network transmissions of the server, the scheme processes the to-be-published business configuration parameters by fragmentation, so that the server only transmits a part of the to-be-published parameters to the distributed business system each time. In this way, the network resources consumed by the transmission of business configuration parameters can be reduced, thereby reducing the impact on other normal network transmissions of the server during the transmission of business configuration parameters.

[0088] Further, when the service end sends the shard data to each first business subsystem, the service end first sends a data shard issuing instruction to each first business subsystem, and after determining that each first business subsystem has received the data shard issuing instruction, the service end sends each shard data in the m shard data to each first business subsystem in turn. Then, after determining that each first business subsystem has received the m shard data, the service end sends a shard data merging instruction to each first business subsystem. The shard data merging instruction is used to instruct each first business subsystem to merge the m shard data according to the actual arrangement order of the shard data. For example, if the number of the business configuration parameters to be published is too large, greater than a preset threshold, the bmp-server-sdk is used to perform shard processing on the business configuration parameters to be published, and a plurality of shard data is obtained. That is, first, the bmp-server-sdk is used to broadcast a request for starting shard issuing of the business configuration parameters to be published to each business subsystem in the distributed business system. After each business subsystem receives the request for shard issuing of the business configuration parameters to be published, the business subsystem records a task in a local receiving file, and then reports the receiving status to the bmp-server-sdk. Then, the bmp-server-sdk is used to broadcast and send each shard data to each business subsystem in the distributed business system. Each business subsystem records the detailed business parameters of each shard in a receiving file after receiving each shard data, and then reports the receiving status to the bmp-server-sdk. Finally, after each shard data is broadcasted and sent, a merging shard request is broadcasted. After each business subsystem receives the merging shard request, the business subsystem merges each shard data according to the actual arrangement order of the shard data, writes the merged business configuration parameters into a first parameter file, and reports the receiving status to the bmp-server-sdk. After the business configuration parameters to be published are issued, the task group record of the service end records the overall issuing status of the business configuration parameters to be published, and the multiple task detail records record the issuing status of the business configuration parameters to be published corresponding to each business subsystem. Each business subsystem has two parameter files, i.e., a first parameter file and a second parameter file. The first parameter file is a parameter file read by each business subsystem during a gray process. The second parameter file is a parameter file read by each business subsystem during an application process.

[0089] Further, after the service end sends the to-be-published service configuration parameters to each first service subsystem, if it is determined that the to-be-published service configuration parameters are successfully issued based on the issuing state of the to-be-published service configuration parameters of each first service subsystem, n first service subsystems for gray-scale to-be-published service configuration parameters are determined from each first service subsystem. Then, a parameter gray-scale instruction is issued to the n first service subsystems, and the parameter gray-scale execution state of the n first service subsystems is recorded in the service configuration parameter issuing task. The parameter gray-scale instruction is used to instruct the n first service subsystems to perform gray-scale processing on the respective to-be-published service configuration parameters. In this way, in order to ensure that the service provided by the distributed service system is not affected in the process of gray-scale publishing of the service configuration parameters, the scheme selects one or more service subsystems to perform gray-scale publishing of the service configuration parameters each time after it is determined that the to-be-published service configuration parameters are successfully issued, and the other service subsystems normally operate to provide service. In this way, the scheme implements gray-scale publishing of the service configuration parameters by each service subsystem in the distributed service system in multiple times, thereby ensuring that the service can be normally provided in the process of gray-scale publishing of the service configuration parameters.

[0090] In the scheme, after the parameter gray-scale instruction is issued to the n first service subsystems, the service end receives the gray-scale execution results, the hash values of the first parameter files, the hash values of the second parameter files, and the hash values of the gray-scale control files reported by the n first service subsystems, and saves the gray-scale execution results, the hash values of the first parameter files, the hash values of the second parameter files, and the hash values of the gray-scale control files reported by the n first service subsystems. Then, for each first service subsystem in the n first service subsystems, the service end determines whether the hash value of the first parameter file of the first service subsystem is consistent with the hash value of the first parameter file of the first service subsystem that has successfully performed gray-scale, whether the hash value of the second parameter file of the first service subsystem is consistent with the hash value of the second parameter file of the first service subsystem that has successfully performed gray-scale, and whether the hash value of the gray-scale control file of the first service subsystem is consistent with the hash value of the gray-scale control file of the first service subsystem that has successfully performed gray-scale. If it is determined that at least one of the hash values of the files of the first service subsystem is inconsistent with the hash value of the corresponding file of the first service subsystem that has successfully performed gray-scale, the hash value verification failure is recorded in the gray-scale execution state of the first service subsystem.

[0091] Exemplarily, continue to describe taking the distributed business system 1 as an example, assuming that the distributed business system has three business subsystems, i.e., the business subsystem A, the business subsystem B and the business subsystem C. After determining that the business configuration parameters to be published of the business subsystem A, the business subsystem B and the business subsystem C are successfully issued, the user can select one or more business subsystems for gray release in the business parameter configuration interface in batches, and then the server generates a gray request, the gray request including the business configuration parameters to be published and the gray list of the business subsystems for gray release this time, and calls the bmp-server-sdk to issue the gray request to one or more business subsystems for gray release this time through a broadcast interface. After receiving the business configuration parameters to be published and the gray list of the business subsystems for gray release this time, each business subsystem compares its own business subsystem identifier with the business subsystem identifiers in the gray list of the business subsystems for gray release this time, and if its own business subsystem identifier exists in the gray list of the business subsystems for gray release this time, the business configuration parameters to be published will be processed for gray release. After the gray release is completed, each business subsystem will generate the hash value of the first parameter file, the hash value of the second parameter file and the hash value of the gray control file through a message digest algorithm or a secure hash algorithm, and report the gray execution result, the hash value of the first parameter file, the hash value of the second parameter file and the hash value of the gray control file to the bmp-server-sdk, and the bmp-server-sdk saves the gray execution result, the hash value of the first parameter file, the hash value of the second parameter file and the hash value of the gray control file. Since the gray release operation of the distributed business system 1 is multiple times, the bmp-server-sdk needs to dynamically save the gray execution result, the hash value of the first parameter file, the hash value of the second parameter file and the hash value of the gray control file reported by each business subsystem for gray release each time, i.e., recording the gray execution result, the hash value of the first parameter file, the hash value of the second parameter file and the hash value of the gray control file through the task details record of each business subsystem. If the hash value of a file is inconsistent with the hash value of the file of the business subsystem that has reported the gray success, the hash value verification failure is recorded in the gray execution state recorded in the task group record. At this time, the server can set to re-execute the business configuration parameter gray release task of the business subsystem with the hash value error at a time until the overall gray execution state recorded in the task group record is successful. Then, the user selects each business subsystem in the distributed business system for gray release in batches, and the bmp-server-sdk determines that each business subsystem is successfully grayed through the result data reported each time, and then the next parameter synchronization operation is performed.

[0092] For example, the user selects service subsystem A and service subsystem B to be released in gray scale one time, the server generates a gray scale request, the gray scale request includes the service configuration parameters to be released and the gray scale list of the service subsystems to be released this time (such as service subsystem A and service subsystem B), and calls bmp-server-sdk to release the gray scale request to the service subsystems A and B selected to be released in gray scale through a broadcast interface. Taking service subsystem A as an example, and service subsystem A has attribute file 1 and attribute file 2, attribute file 1 is used to indicate the file to be read by service subsystem A in the application process (i.e. non-gray scale process), and attribute file 2 is used to indicate the file to be read by service subsystem A in the gray scale process. After receiving the service configuration parameters to be released and the gray scale list of the service subsystems to be released this time, service subsystem A compares its own service subsystem identifier with the identifiers of the service subsystems in the gray scale list. If its own service subsystem identifier exists in the gray scale list, the service configuration parameters to be released will be processed in gray scale. After the gray scale is completed, service subsystem A will generate the hash values of the first parameter file, the hash values of the second parameter file and the hash values of the gray scale control file through a message digest algorithm or a secure hash algorithm, and report the gray scale execution result, the hash values of attribute file 1, the hash values of attribute file 2 and the hash values of the gray scale control file to bmp-server-sdk. bmp-server-sdk records the gray scale execution result, the hash values of attribute file 1, the hash values of attribute file 2 and the hash values of the gray scale control file through a task detail record. Assuming that the hash value of attribute file 1 is inconsistent with the hash value of attribute file 1 of the service subsystem B reported to be successful in gray scale, the gray scale execution state recorded by the task group record is updated to hash value verification failure. At this time, the server can set to re-execute the service configuration parameter gray scale task of the service subsystem A with hash value error at any time until the overall gray scale execution state of the task group record is successful. Then, the user releases each service subsystem in the distributed business system in gray scale through multiple times, and bmp-server-sdk determines that each service subsystem is successfully gray scaled through the result data reported each time, and then performs the next parameter synchronization operation.

[0093] It should be noted that during the gray scale process, the user can select to roll back the distributed business system at any time, and then bmp-server-sdk ensures that each service subsystem in the distributed business system is rolled back to the state before the configuration is released.

[0094] Further, after determining that each first business subsystem is successful in the parameter grayscale execution state based on the parameter grayscale of each first business subsystem, a parameter synchronization instruction is issued to each first business subsystem, and the parameter synchronization execution state of each first business subsystem is recorded in the business configuration parameter issuing task. The parameter synchronization instruction is used to instruct each first business subsystem to synchronize the business configuration parameters to be issued in the first parameter file to the second parameter file to obtain the business configuration parameter file after grayscale publishing, so that each first business subsystem can read the business configuration parameter file after grayscale publishing in time in the application process.

[0095] Exemplarily, after determining that each first business subsystem is successful in the grayscale, the user clicks the data rollback button on the business parameter configuration interface, and the bmp-server-sdk issues a data rollback instruction to each business subsystem in the distributed business system through the broadcast interface. After executing the data rollback instruction, each business subsystem reports the execution result of data rollback to the bmp-server-sdk, and the bmp-server-sdk updates the data rollback execution state of the entire distributed business system through the task group record, and updates the data rollback execution state of each business subsystem through the respective task detail record of each business subsystem. For example, continue to describe the distributed business system 1, assuming that the distributed business system has two business subsystems, namely business subsystem A and business subsystem B. The user clicks the data rollback button on the business parameter configuration interface, and the bmp-server-sdk issues a data rollback instruction to the business subsystem A and the business subsystem B through the broadcast interface. The business subsystem A and the business subsystem B respectively report the execution result of data rollback to the bmp-server-sdk. Assuming that the data rollback execution result of the business subsystem A is successful, and the data rollback execution result of the business subsystem B is successful, the task detail record corresponding to the business subsystem A updates the data rollback execution state of the business subsystem A to successful, the task detail record corresponding to the business subsystem B updates the data rollback execution state of the business subsystem B to successful, and the data rollback execution state of the entire distributed business system 1 is successful. Assuming that the data rollback execution result of the business subsystem A is failed, and the data rollback execution result of the business subsystem B is successful, the task detail record corresponding to the business subsystem A updates the data rollback execution state of the business subsystem A to failed, the task detail record corresponding to the business subsystem B updates the data rollback execution state of the business subsystem B to successful, and the data rollback execution state of the entire distributed business system 1 is failed. At this time, the server can set a business configuration parameter rollback task of the business subsystem A which fails in data rollback execution to be executed again at regular intervals until the overall data rollback execution state recorded in the task group record is successful.

[0096] In step 204, the service end determines that the parameter file backup instruction is issued to any first business subsystem after the success of the gray release of each first business subsystem based on the parameter gray release execution state and the parameter synchronization execution state of each first business subsystem in the task issuing based on the business configuration parameter.

[0097] In the embodiment of the present application, the service end determines that the parameter file backup instruction is issued to any first business subsystem after the success of the gray release of each first business subsystem based on the parameter gray release execution state and the parameter synchronization execution state of each first business subsystem in the task issuing based on the business configuration parameter, so as to make the first business subsystem upload the locally stored business configuration parameter file after the gray release to the file storage system. Specifically, the bmp-server-sdk determines that the gray release of each first business subsystem is successful through the task group record and the task detail record, and then notifies any one of the distributed business systems through an interface, that is, the data backup instruction is issued to the business subsystem, so as to make the business subsystem upload the locally stored business configuration parameter file after the gray release to the file storage system for backup and storage.

[0098] After the business configuration parameter file after the gray release is uploaded to the file storage system for backup and storage, the current full amount of business configuration parameters can be easily obtained when the new business subsystem (i.e. the new server) is expanded or backed up, without the need to obtain from the database maintained by the service end, and without the need to rely on the persistent layer database to maintain the full amount of business configuration parameters, so as to achieve the purpose of expanding the new business subsystem in the database-free environment.

[0099] If the distributed business system needs to add a new first business subsystem, the first business subsystem closest to the new first business subsystem can be determined from the first business subsystems. The new first business subsystem obtains the gray-scale published business configuration parameter file from the first business subsystem closest to the new first business subsystem, generates a first hash value of the gray-scale published business configuration parameter file through a message digest algorithm or a secure hash algorithm, and obtains a second hash value of the gray-scale published business configuration parameter file based on the distributed business system identifier from the file storage system. Then, it is determined whether the first hash value and the second hash value are consistent. If yes, the new first business subsystem confirms that the gray-scale published business configuration parameter file is available. If not, the new first business subsystem can obtain the gray-scale published business configuration parameter file from the file storage system based on the distributed business system identifier. The file storage system can store the gray-scale published business configuration parameter file, the hash value of the gray-scale published business configuration parameter file, and the distributed business system identifier. Alternatively, the file storage system can store the gray-scale published business configuration parameter file and the distributed business system identifier, and each first business subsystem can obtain the gray-scale published business configuration parameter file from the file storage system and calculate a second hash value of the obtained gray-scale published business configuration parameter file through a message digest algorithm or a secure hash algorithm. In this way, since each business subsystem in the distributed business system stores the gray-scale published business configuration parameter file, when the distributed business system needs to add a new business subsystem, the current full-amount business configuration parameter file can be obtained from the closest business subsystem in time, without the need to obtain it from the database maintained by the server, and without the need to rely on the persistent layer database to maintain the full-amount business configuration parameter.

[0100] For example, the distributed business system 1 is described. It is assumed that the distributed business system has two business subsystems, i.e., the business subsystem A and the business subsystem B. At this time, a new business subsystem C needs to be added. The new business subsystem C can obtain the current full-amount business configuration parameter file from the closest business subsystem (such as the business subsystem A), generate a first hash value of the current full-amount business configuration parameter file through a message digest algorithm or a secure hash algorithm, and obtain the current full-amount business configuration parameter file from the file storage system based on the identifier of the distributed business system 1, and generate a second hash value of the current full-amount business configuration parameter file obtained from the file storage system through a message digest algorithm or a secure hash algorithm. Then, it is determined whether the first hash value and the second hash value are consistent. If yes, the new business subsystem C confirms that the current full-amount business configuration parameter file is available. If not, the new business subsystem C can obtain the current full-amount business configuration parameter file from the file storage system based on the identifier of the distributed business system 1.

[0101] If it is determined that the distributed business system fails, a new distributed business system can be started. For each second business subsystem in the new distributed business system, the second business subsystem acquires a gray release business configuration parameter file and a third hash value of the gray release business configuration parameter file from a file storage system based on a distributed business system identifier, and reports the third hash value to a server, where the server is configured to determine whether the third hash values reported by the second business subsystems are consistent. Then, based on a third hash value consistency indication sent by the server, it is confirmed that the gray release business configuration parameter file is available. The file storage system can store the gray release business configuration parameter file, a hash value of the gray release business configuration parameter file, and the distributed business system identifier. Alternatively, the file storage system can store the gray release business configuration parameter file and the distributed business system identifier, and each second business subsystem can acquire the gray release business configuration parameter file from the file storage system based on the distributed business system identifier, and calculate a third hash value of the acquired gray release business configuration parameter file by using a message digest algorithm or a secure hash algorithm. If the third hash values are inconsistent, each second business subsystem needs to acquire the gray release business configuration parameter file from the file storage system based on the distributed business system identifier again, and then calculate a fourth hash value of the acquired gray release business configuration parameter file by using a message digest algorithm or a secure hash algorithm. Then, the recalculated fourth hash value is reported to the bmp-server-sdk for verification until it is confirmed that the hash values reported by the second business subsystems are consistent.

[0102] Exemplarily, continue to describe with the distributed business system 1 as an example, assuming that the region where the distributed business system 1 is located encounters a disaster and hangs up, and another region of the distributed business system 2 needs to be started for disaster recovery, the server sends a broadcast request to the distributed business system 2 in the new region through the bmp-server-sdk, then each business subsystem in the distributed business system 2 pulls the current full amount of business configuration parameter file based on the distributed business system identifier from the file storage system, and calculates the hash value of the current full amount of business configuration parameter file through a message digest algorithm or a secure hash algorithm, and reports the hash value of the current full amount of business configuration parameter file to the bmp-server-sdk, and the bmp-server-sdk collects the hash values reported by each business subsystem in the distributed business system 2 for verification. If the hash values reported by each business subsystem are consistent, it is confirmed that the current full amount of business configuration parameter file is available. If the hash values reported by each business subsystem are inconsistent, each business subsystem needs to reacquire the current full amount of business configuration parameter file from the file storage system based on the distributed business system identifier, then calculate the third hash value of the acquired current full amount of business configuration parameter file through a message digest algorithm or a secure hash algorithm, and then report the recalculated hash value to the bmp-server-sdk for verification, until the verification confirms that the hash values reported by each business subsystem are consistent.

[0103] The above embodiments show that, by the configuration management platform, when it is determined that the distributed business system corresponding to the distributed business system identifier is in the non-production release state, it is determined whether each first business subsystem in the distributed business system meets the business configuration parameter distribution condition, so that it can be determined in a timely and effective manner whether the distribution of the to-be-distributed business configuration parameter can be performed at present, thereby avoiding the influence of the normal work of the distributed business system due to unreasonable distribution operation. Then, when it is determined that each first business subsystem meets the business configuration parameter distribution condition, a business configuration parameter distribution task is created, and when it is determined that the number of to-be-distributed business configuration parameters is greater than a preset threshold, the to-be-distributed business configuration parameters are subjected to sharding processing, m pieces of sharding data subjected to the sharding processing are sent to each first business subsystem, so that each first business subsystem can perform gray release of the to-be-distributed business configuration parameter in a timely manner. Then, after it is determined that the gray release of each first business subsystem is successful, a parameter file backup instruction is distributed to any first business subsystem, so that the first business subsystem uploads the locally stored business configuration parameter file subjected to the gray release to the file storage system, so that the business configuration parameter file subjected to the gray release can be acquired from the file storage system in a timely and accurate manner when the distributed system abnormally. In this way, the scheme can realize the gray release of the to-be-distributed business configuration parameter without relying on the database to perform full-maintenance of the business configuration parameter, and can ensure the consistency of the configuration of the business configuration parameter in the gray release process of the distributed system in a database-free environment, thereby reducing the parameter maintenance cost and realizing the high availability of the business configuration parameter file subjected to the gray release. In addition, the distribution of the to-be-distributed business configuration parameter by the server can flexibly control the gray release process, thereby realizing the flexible configuration of the business configuration parameter.

[0104] Based on the same technical concept, Figure 3 An exemplary service server gray release control system provided by the embodiment of the application is shown, which can execute the flow of the service server gray release control method.

[0105] As Figure 3 shown, the system comprises:

[0106] The receiving unit 301 is configured to receive a business configuration parameter release request; the business configuration parameter release request comprises to-be-distributed business configuration parameters and a distributed business system identifier; the to-be-distributed business configuration parameters are obtained by updating the business configuration parameters acquired from the distributed business system corresponding to the distributed business system identifier;

[0107] Processing unit 302 is configured to, through a configuration management platform, determine whether each first business subsystem in the distributed business system meets the conditions for distributing business configuration parameters when the distributed business system corresponding to the distributed business system identifier is in a pre-release state; if so, create a business configuration parameter distribution task, and when the number of business configuration parameters to be released is greater than a preset threshold, perform sharding processing on the business configuration parameters to be released to determine m shards; send the m shards to each first business subsystem, and record the conditions for each first business subsystem in the business configuration parameter distribution task. The distribution status of the business configuration parameters to be released by a business subsystem; each data shard includes at least one parameter; the distribution status of the business configuration parameters to be released is reported by the first business subsystem; after determining that the gray-scale release of each first business subsystem is successful based on the parameter gray-scale execution status and parameter synchronous execution status of each first business subsystem in the business configuration parameter distribution task, a parameter file backup instruction is issued to any first business subsystem; the parameter file backup instruction is used to instruct the first business subsystem to upload the business configuration parameter file after gray-scale release stored locally to the file storage system.

[0108] Based on the same technical concept, embodiments of the present invention also provide a computing device, such as... Figure 4 As shown, it includes at least one processor 401 and a memory 402 connected to at least one processor. In this embodiment of the invention, the specific connection medium between the processor 401 and the memory 402 is not limited. Figure 4 Taking the connection between processor 401 and memory 402 via a bus as an example, the bus can be divided into address bus, data bus, control bus, etc.

[0109] In this embodiment of the invention, the memory 402 stores instructions that can be executed by at least one processor 401. By executing the instructions stored in the memory 402, at least one processor 401 can perform the steps included in the aforementioned server-side canary release control method.

[0110] The processor 401 is the control center of the computing device, can connect various parts of the computing device by using various interfaces and lines, and realize data processing by running or executing instructions stored in the memory 402 and calling data stored in the memory 402. Optionally, the processor 401 can include one or more processing units, and the processor 401 can integrate an application processor and a modem processor, wherein the application processor mainly processes an operating system, a user interface, an application program and the like, and the modem processor mainly processes an issued instruction. It can be understood that the above-mentioned modem processor can also not be integrated into the processor 401. In some embodiments, the processor 401 and the memory 402 can be implemented on the same chip, and in some embodiments, they can also be respectively implemented on independent chips.

[0111] The processor 401 can be a general-purpose processor, for example, a central processing unit (CPU), a digital signal processor, an application specific integrated circuit (ASIC), a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, and can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of the application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in combination with the embodiment of the server gray release control method can be directly embodied as hardware processor execution completion or executed by hardware and software module combination in the processor.

[0112] The memory 402, as a non-volatile computer readable storage medium, can be used to store non-volatile software programs, non-volatile computer executable programs and modules. The memory 402 can include at least one type of storage medium, for example, can include flash memory, hard disk, multimedia card, card type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. The memory 402 is any other medium capable of carrying or storing desired program codes in the form of instructions or data structures and capable of being accessed by a computer, but is not limited thereto. The memory 402 in the embodiment of the present application can also be a circuit or any other device capable of realizing a storage function, used for storing program instructions and / or data.

[0113] Based on the same technical concept, the embodiment of the present application further provides a computer readable storage medium, which stores a computer program executable by a computing device, and when the program runs on the computing device, causes the computing device to execute the steps of the above-mentioned server-side gray release control method.

[0114] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0115] The present application is described with reference to flowcharts and / or block diagrams of the method, device (system) and computer program product according to the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can be realized by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing devices to produce a machine, so that the instructions executed by the computer or other programmable data processing devices produce a device for realizing the functions specified in the flowcharts and / or block diagrams. Figure 1one or more processes and / or blocks Figure 1 an apparatus for performing the functions specified in the flowchart

[0116] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the flowchart Figure 1 one or more processes and / or blocks Figure 1 an apparatus for performing the functions specified in the flowchart

[0117] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the flowchart Figure 1 one or more processes and / or blocks Figure 1 an apparatus for performing the functions specified in the flowchart

[0118] Although preferred embodiments of the application have been described herein, changes and modifications can be suggested to one skilled in the art, and it is intended that the scope of the application be limited only by the appended claims and equivalents thereof.

[0119] Obviously, numerous modifications and variations of the present application are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims and their equivalents, the application can be practiced otherwise than as specifically described.

Claims

1. A server-side canary release control method, characterized in that, include: The server receives a business configuration parameter publishing request; the business configuration parameter publishing request includes the business configuration parameters to be published and the distributed business system identifier. The server, through the configuration management platform, determines whether each first business subsystem in the distributed business system meets the conditions for issuing business configuration parameters when it determines that the distributed business system corresponding to the distributed business system identifier is in a non-production release state. If so, the server creates a business configuration parameter distribution task, and when it is determined that the number of business configuration parameters to be published is greater than a preset threshold, it performs sharding processing on the business configuration parameters to be published to determine m shard data; sends the m shard data to each first business subsystem, and records the distribution status of the business configuration parameters to be published in each first business subsystem in the business configuration parameter distribution task; Each data shard includes at least one parameter; the distribution status of the service configuration parameters to be published is reported by the first service subsystem. After determining that the canary release of each first business subsystem is successful based on the parameter canary execution status and parameter synchronous execution status of each first business subsystem in the task issued based on the business configuration parameters, the server issues a parameter file backup instruction to any first business subsystem. The parameter file backup instruction is used to instruct the first business subsystem to upload the business configuration parameter file after the gray-scale release stored locally to the file storage system.

2. The method as described in claim 1, characterized in that, After issuing a parameter file backup command to any first business subsystem, the following is also included: If a new first business subsystem is added, then the first business subsystem that is closest to the new first business subsystem is determined from among the existing first business subsystems. The new first business subsystem obtains the business configuration parameter file after the canary release from the nearest first business subsystem, and generates the first hash value of the business configuration parameter file after the canary release; The new first business subsystem obtains the second hash value of the business configuration parameter file after the grayscale release from the file storage system; The new first business subsystem determines whether the first hash value and the second hash value are consistent; If so, the new first business subsystem confirms that the business configuration parameter file after the gray-scale release is available.

3. The method as described in claim 1, characterized in that, After issuing a parameter file backup command to any first business subsystem, the following is also included: If it is determined that the distributed business system has failed, a new distributed business system will be started. For each second business subsystem in the new distributed business system, the second business subsystem obtains the business configuration parameter file after the canary release and the third hash value of the business configuration parameter file after the canary release from the file storage system, and reports the third hash value to the server; the server is used to determine whether the third hash values ​​reported by each second business subsystem are consistent. The second business subsystem confirms the availability of the business configuration parameter file after the canary release based on the consistency indication of the third hash value sent by the server.

4. The method as described in claim 3, characterized in that, The method further includes: If the server determines that the third hash values ​​reported by each of the second business subsystems are inconsistent, it sends a configuration inconsistency indication to each of the second business subsystems. The configuration inconsistency indication is used to instruct each second business subsystem to re-obtain the business configuration parameter file after the gray release from the file storage system based on the distributed business system identifier, generate a fourth hash value of the business configuration parameter file after the gray release, and report the fourth hash value to the server for verification until it is confirmed that the hash values ​​reported by each of the second business subsystems are consistent.

5. The method as described in claim 1, characterized in that, Determining whether each first business subsystem in the distributed business system meets the conditions for issuing business configuration parameters includes: For each first business subsystem, the server queries the CPU utilization, memory utilization, and thread pool status of the first business subsystem through the configuration management platform. The server determines whether the CPU utilization rate of the first business subsystem meets a first preset condition, whether the memory utilization rate of the first business subsystem meets a second preset condition, and whether the thread pool status of the first business subsystem meets a third preset condition.

6. The method as described in claim 1, characterized in that, Sending the m data shards to each first service subsystem includes: The server sends a data sharding delivery instruction to each of the first business subsystems, and after confirming that each of the first business subsystems has received the data sharding delivery instruction, it sequentially sends each of the m sharded data to each of the first business subsystems. After determining that each of the first business subsystems has received the m data fragments, the server sends a data fragment merging instruction to each of the first business subsystems. The data fragment merging instruction is used to instruct each first business subsystem to merge the m data fragments according to the actual order in which the data fragments are arranged.

7. The method according to any one of claims 1 to 6, characterized in that, After recording the distribution status of the service configuration parameters to be published for each of the first service subsystems in the service configuration parameter distribution task, the task further includes: After the server determines that the service configuration parameters to be published have been successfully published based on the publication status of the service configuration parameters to be published in each of the first business subsystems, it determines n first business subsystems from each of the first business subsystems for gray-scale deployment of the service configuration parameters to be published. The server sends parameter grayscale instructions to the n first business subsystems and records the parameter grayscale execution status of the n first business subsystems in the business configuration parameter sending task; the parameter grayscale instructions are used to instruct the n first business subsystems to perform grayscale processing on their respective business configuration parameters to be released.

8. The method as described in claim 7, characterized in that, After recording the parameter grayscale execution status of the n first business subsystems in the business configuration parameter distribution task, the following is also included: After determining that the gray-scale deployment of each first business subsystem is successful based on the parameter gray-scale execution status of each first business subsystem, the server sends a parameter synchronization instruction to each first business subsystem and records the parameter synchronization execution status of each first business subsystem in the business configuration parameter distribution task. The parameter synchronization instruction is used to instruct each first business subsystem to synchronize the business configuration parameters to be released stored in the first parameter file to the second parameter file to obtain the business configuration parameter file after gray-scale release. The first parameter file is the parameter file read by the first business subsystem during the gray-scale process. The second parameter file is the parameter file read by the first business subsystem during the application process.

9. The method as described in claim 7, characterized in that, After issuing parameter grayscale instructions to the n first business subsystems, the process also includes: The server receives the grayscale execution results, the hash value of the first parameter file, the hash value of the second parameter file, and the hash value of the grayscale control file reported by the n first business subsystems. For each of the n first business subsystems, the server determines whether the hash value of the first parameter file of the first business subsystem is consistent with the hash value of the first parameter file of the first business subsystem that has been successfully gray-scaled, whether the hash value of the second parameter file of the first business subsystem is consistent with the hash value of the second parameter file of the first business subsystem that has been successfully gray-scaled, and whether the hash value of the gray-scale control file of the first business subsystem is consistent with the hash value of the gray-scale control file of the first business subsystem that has been successfully gray-scaled. If the server determines that at least one of the hash values ​​of the files in the first business subsystem is inconsistent with the hash value of the corresponding file in the first business subsystem that has been successfully gray-scaled, then the server records a hash value verification failure in the gray-scale execution status of the first business subsystem.

10. A server-side canary release control system for implementing the method as described in any one of claims 1 to 9, wherein the server-side canary release control system comprises a server, each first business subsystem, and each second business subsystem.

Images