A demand publishing method and device, electronic equipment and storage medium

Abstract

This disclosure provides a method, apparatus, electronic device, and storage medium for demand publishing, relating to the computer field, and particularly to the field of computer development technology. The specific implementation scheme is as follows: Obtain the demand information entered by the demand provider in a specified format through a demand entry interface; write the approved demand information into a demand publishing table; when a publishing instruction is received, convert the demand information in the demand publishing table into a demand configuration file; and publish the demand to services in the log platform based on the demand configuration file. This reduces labor costs and lowers the risk of misoperation.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to the field of computer development technology. Background Technology

[0002] A log platform is a service architecture used to implement functions such as log data collection, transmission, management, querying, and analysis. To support the data construction of the entire mobile ecosystem, the log platform frequently generates logs.

[0003] Requirements include point access and log point changes. After the requester submits a request, the research and development (RD) engineers of the log platform can communicate with the requester to confirm the requirements, write the confirmed requirements into configuration code, and then use the configuration code to deploy the requirements to various services in the log platform. Summary of the Invention

[0004] This disclosure provides a method, apparatus, electronic device, and storage medium for publishing requirements.

[0005] According to a first aspect of this disclosure, a method for publishing requirements is provided, comprising:

[0006] Obtain the requirement information entered by the requirement provider in the requirement entry interface according to the specified format; write the approved requirement information into the requirement release form.

[0007] When a release instruction is received, the requirement information in the requirement release table is converted into a requirement configuration file;

[0008] Based on the aforementioned requirement configuration file, the service requirements in the log middleware are published.

[0009] According to a second aspect of this disclosure, a demand publishing device is provided, comprising: 5 acquisition module, used to acquire demand information entered by a demand provider in a demand entry interface according to a specified format;

[0010] The write module is used to write the approved requirement information into the requirement release table;

[0011] The conversion module is used to convert the requirement information in the requirement release table when a release instruction is received.

[0012] Information is converted into a requirements configuration file;

[0013] The publishing module is used to publish the service requirements in the log middle platform based on the requirement configuration file converted by the conversion module.

[0014] According to a third aspect of this disclosure, an electronic device is provided, comprising:

[0015] At least one processor; and

[0016] A memory communicatively connected to the at least one processor; wherein,

[0017] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method described in any one of the first aspects.

[0018] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform the method described in any one of the first aspects.

[0019] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described in any one of the first aspects.

[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0021] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0022] Figure 1 This is a flowchart of a requirement publishing method provided in an embodiment of this disclosure;

[0023] Figure 2 This is an exemplary schematic diagram of a demand management interface provided in an embodiment of this disclosure;

[0024] Figure 3 This is an exemplary schematic diagram of a demand management process provided in an embodiment of this disclosure;

[0025] Figure 4 This is an exemplary schematic diagram of a hierarchical publishing process provided in an embodiment of this disclosure;

[0026] Figure 5 This is an exemplary schematic diagram of a demand publishing interface provided in an embodiment of this disclosure;

[0027] Figure 6 This is an exemplary schematic diagram of a demand posting details interface provided in an embodiment of this disclosure;

[0028] Figure 7 This is a flowchart of another requirement publishing method provided in this embodiment of the disclosure;

[0029] Figure 8 This is an exemplary schematic diagram illustrating how a demand can be published through a self-service platform, as provided in this embodiment of the disclosure.

[0030] Figure 9 This is a schematic diagram of the structure of a demand publishing device provided in an embodiment of this disclosure;

[0031] Figure 10 A block diagram of an electronic device used to implement the requirements publishing method of the embodiments of this disclosure. Detailed Implementation

[0032] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0033] This disclosure provides a demand publishing method, which is applied to electronic devices, such as terminals and servers. Figure 1 As shown, the method includes: OS101, obtaining the requirement information entered by the requirement provider in the requirement entry interface according to the specified format.

[0034] Among them, the demand provider is the log platform user who puts forward the demand, and the demand entry interface is a demand entry interface with a specified format. The demand provider needs to enter the demand in accordance with the specified format defined in the demand entry interface.

[0035] S102. Write the approved requirement information into the requirement release form.

[0036] 5. After the requirement provider enters the requirement information, the R&D team in the log platform can review the requirement information. Once approved, the server can write the approved requirement information into the requirement release table. The requirement release table is located in a database, for example, a MySQL database.

[0037] S103. When a release instruction is received, the requirement information in the requirement release table is converted into a requirement configuration file.

[0038] 0 Wherein, the requirement configuration file is in a format that the code can recognize, and the embodiments of this disclosure do not limit the code language used.

[0039] S104. Deploy requirements for services in the log middleware based on the requirements configuration file.

[0040] Using the above technical solution, the demand provider enters the demand in the specified format on the demand input interface.

[0041] Requesting information, by specifying a format to constrain the input of requirements, the content of the requirements is standardized, and the requirement provider can directly input the requirement information without the need for frequent communication between the R&D department and the requirement provider in the log platform.

[0042] This facilitates communication between the parties involved, reducing manpower costs during the requirements communication phase. Furthermore, approved requirements can be written into the requirements release table. Upon receiving a release instruction, the requirements information in the release table is converted into a requirements configuration file, eliminating the need for manual editing, reducing the risk of errors, and further lowering manpower costs.

[0043] 0 In some embodiments of this disclosure, the format of the requirement information entered by the requirement provider can be restricted through the requirement input interface. Specifically, S101, obtaining the requirement information entered by the requirement provider in the requirement input interface according to the specified format, can be implemented as follows:

[0044] The system retrieves the application identification (APP ID) and log ID entered by the requirement provider on the requirement entry interface, as well as the target requirement type selected through the menu bar, which includes multiple preset requirement types. In response to the target requirement type selected by the requirement provider, the system displays the requirement details filling template corresponding to the target requirement type on the requirement entry interface. The system generates the target requirement details based on the information entered by the requirement provider in the requirement details filling template.

[0045] Therefore, the APP ID and log ID, target requirement type, and target requirement details filled in by the requirement provider can be used as a requirement information.

[0046] The APP ID is used to represent the product line information to which the requirement belongs. A product line can be an application, meaning the APP ID can also represent the application to which the requirement belongs. Requirements submitted for the same application will have the same APP ID. For example, if requirement a and requirement b both belong to application A, then requirement a and requirement b will have the same APP ID.

[0047] The log ID is used to indicate the scenario in which the log is reported. For example, if the scenario for reporting logs is the number of conference calls initiated daily within application A, the corresponding log ID could be 001.

[0048] The demand type is used to represent the goal of the demand. Demand types can include: original information storage to disk, real-time stream forwarding, and recommendation stream forwarding, etc.

[0049] The requirement details section describes the detailed information about the requirement, and the format of the requirement details section differs for different requirement types. In this embodiment of the disclosure, a set of filling templates can be set for the requirement details of different requirement types, so that requirement providers can fill in the requirement information according to the filling templates.

[0050] For example, for real-time stream forwarding, the requirement details record the target downstream node of the real-time stream; for recommended stream forwarding, the requirement details record information such as the format type of the recommended stream.

[0051] Furthermore, in this embodiment, the request provider only needs to select the target request type in the menu bar, and then fill in the request information in the request details form corresponding to the target request type. The final target request details are generated by the server by combining the request details form and the information filled in by the request provider. For example, for a real-time stream forwarding type request, the request provider needs to fill in information such as the target downstream node in the request details form, and then the server can combine the downstream node information filled in by the request provider with the request details form to form the request details.

[0052] The requirement input interface in this embodiment can be in the form of a webpage in a browser, such as... Figure 2 As shown, Figure 2 This is an exemplary schematic diagram of a demand management interface provided in an embodiment of this disclosure.

[0053] This requirement management interface can be used by requirement providers to enter requirement information, as well as by the log platform's R&D team to review requirement information. The log platform's R&D team can also use this interface for other management purposes. Users with different identities can log in to this requirement management interface using different accounts.

[0054] Figure 2 The document shows input boxes for Log ID and APP ID, as well as a function category selection box. After the user clicks "Please select" in the function category selection box, the pre-set requirement types will be displayed, and the user can then select the requirement type from them.

[0055] When a user clicks the query button, the system will display the request information that matches the log ID, APP ID, and selected request type entered by the user. Figure 2 Each line below represents a requirement. Figure 2 The interface exemplifies the log ID, app ID, modifier, creation time, and status of each requirement. Each requirement also includes action buttons on the right, such as a view button, an edit button, a test passed button, a request to publish button, and a view publication record button. Clicking the view button will display the requirement details for that specific requirement.

[0056] If a user clicks the "Add" button, a template for filling in the requirement details that matches the requirement type selected by the user will be displayed, allowing the requirement provider to enter the requirement information.

[0057] In addition, the RD of the log platform can choose Figure 2 Click the "Publish" button below to publish the selected requirements.

[0058] Figure 2 This is merely an example of a requirements management interface, and the embodiments of this application do not limit the form of the requirements management interface.

[0059] Using the above method, after the request provider enters the APP ID and log ID, they can select the target request type in the menu bar. The server then responds to the selected target request type by displaying a request details template corresponding to that type on the request entry interface. The request provider can then enter the request based on the template. This method allows request providers to enter request information in a relatively standardized format. By pre-setting request details templates for each request type, the format of the entered request information is standardized, and the operation for request providers is simplified. Compared to communication between the log platform's R&D team and the request provider, this method saves communication costs, facilitates the request provider's operation, and reduces the probability of errors in request information entry.

[0060] In some embodiments of this disclosure, before writing the approved requirement information into the requirement release table, the requirement information entered by the requirement provider can be stored in the requirement editing table. When a request to review the requirement information in the requirement editing table is received, the requirement information to be reviewed is displayed on the review interface. Furthermore, the R&D team of the log platform can review the requirement information to be reviewed on the review interface.

[0061] The requirement editing table stores the requirement information entered by the requirement provider. The requirement editing table is located in a database, such as a MySQL database.

[0062] The review interface can be in the form of a webpage in a browser, for example, it can be... Figure 2 The interface shown.

[0063] Request providers can agree with the R&D team of the log platform on a time period for updating request information. Request providers can enter request information at any time, and the R&D team of the log platform can review the request information within the agreed time period. For example, they can review it weekly or proactively check at any time to see if there are any request requests that require review.

[0064] In addition, the review interface allows users to view all requirement information in the requirement editing table, and the RD (Research and Development) team in the log platform can select the requirement information to be reviewed.

[0065] Then, the server writes the approved requirement information into the requirement release table. Specifically, when it receives an approval instruction for the requirement information to be reviewed, it writes the requirement information to be reviewed into the requirement release table.

[0066] For example, Figure 3 This is an exemplary schematic diagram of a requirement management process provided in this disclosure embodiment, including a log platform user (i.e., a requirement provider), the log platform's RD, a requirement management module, and a MySQL database, wherein the MySQL database includes a requirement editing table and a requirement publishing table.

[0067] Request providers can enter request information in a specified format. After receiving the request information from the request provider, the request management module stores the request information in the request editing table.

[0068] When the requirement management module receives a request from the R&D department of the log platform to review the requirement information in the requirement editing table, the requirement management module can read the requirement information to be reviewed from the requirement editing table. Then, the R&D department can view the requirement information to be reviewed and review it. For the requirement information that has been approved, the requirement management module will write the requirement information into the requirement release table.

[0069] Using the above method, the server stores the requirement information entered by the requirement provider in a requirement editing table. When the R&D team in the log platform reviews the requirement information, the server receives the review request for the requirement information in the requirement editing table. The server then displays the requirement information to be reviewed on the review interface so that the R&D team in the log platform can complete the review. For the requirement information that passes the review, it is written into the requirement release table, awaiting release. In this way, the security of the subsequently released requirement information is ensured through the review of the requirement information by the R&D team, and the workload of the log platform R&D team is reduced without the need for manual editing of the requirement information, thus reducing the risk of accidental operation.

[0070] In one embodiment of this disclosure, the server can directly convert all the requirement information in the requirement release table into a requirement configuration file.

[0071] In another implementation of the disclosed embodiments, the requirement information in the requirement release table is converted into a requirement configuration file, which can be specifically implemented as follows:

[0072] Demand information with the same APP ID in the demand release table is grouped into a single demand information set. For each demand information set, multiple demand information sets with the same demand type and demand details are aggregated into a single demand information group. Then, a demand configuration file is generated based on all demand information groups.

[0073] Since the requirement details and requirement types of the same APP ID may be the same, in order to avoid excessive redundancy in the subsequent generated requirement configuration files, the requirement types and requirement details can be aggregated so that multiple requirement information with the same requirement type and requirement details can use a requirement information group.

[0074] The requirement information group includes the APP ID, the log ID of multiple requirement information, the requirement type and requirement details of a single requirement information among the multiple requirement information. The server can automatically generate a requirement configuration file in code form based on the requirement information group.

[0075] For example, if the APP IDs of demand information 1, demand information 2, and demand information 3 are all 100, the demand type is all recommendation stream forwarding, and the demand details are all the same, and the log IDs of demand information 1, demand information 2, and demand information 3 are 001, 002, and 003 respectively, then a demand information group can be generated. This demand information group includes: APP ID: 100; Log IDs: 001, 002, and 003; Demand type: recommendation stream forwarding; and the specific demand details.

[0076] Understandably, the storage space required for request details is substantial; each request detail can occupy up to 100 bytes. If these requests are directly converted into request configuration files, the memory required for these files will reach the MB level. Furthermore, simultaneously distributing these configuration files to multiple service instances in the log platform would place excessive demands on network bandwidth. For instance, distributing request configuration files to 3000 service instances would require 3GBps of network bandwidth.

[0077] In this embodiment, requirement information with the same APP ID is categorized, and requirement information with the same requirement type and details within the same category is further aggregated to obtain requirement detail groups. These requirement detail groups are then used to generate requirement configuration files. This method avoids a large amount of redundant requirement details in the requirement configuration files, significantly reducing their size and network bandwidth requirements. Experiments have shown that this method can reduce the size of requirement configuration files from the MB level to less than 50KB.

[0078] After obtaining the requirement configuration file, in this embodiment of the disclosure, the requirement can be released using a canary release method. The requirement release process specifically includes:

[0079] Step 1: Obtain a list of service instances from the cloud.

[0080] The service instance list includes service instances that need to be published. The server can obtain the service instance list from the cloud. The service instances in the service instance list may change dynamically. Some service instances in the original service instance list may be migrated, and some service instances may be created and added to the service instance list. Therefore, the server can obtain the latest service instance list from the cloud before each time a requirement is published.

[0081] Specifically, this cloud can be Baidu Naming Service (BNS).

[0082] Step 2: Select service instances to be published from the service instance list according to the preset publication ratio.

[0083] The preset deployment ratio can be the preset deployment ratio issued by the RD of the log platform when a deployment command is triggered. Specifically, it can be configured to deploy service instances at a preset deployment ratio every integer minute. For example, 10% of service instances can be deployed every minute.

[0084] Based on the preset deployment ratio, randomly select instances to be deployed from the service instance list. For example, if the service instance list contains 100 service instances and the preset deployment ratio is 10%, then randomly select 10 service instances from the service instance list as instances to be deployed.

[0085] Step 3: Publish the requirements for the service instance to be published according to the requirements configuration file.

[0086] When a request to pull the requirements configuration file is received from a service instance to be published, the requirements configuration file is sent to the service instance to be published so that the service instance to be published can perform hot updates based on the requirements configuration file.

[0087] Each service instance periodically requests and pulls the requirement configuration file. If the server determines that the service instance requesting the requirement configuration file is a pending release instance, it will distribute the requirement configuration file to that service instance. This allows for requirement release via hot updates, eliminating the need for frequent re-deployment of services, thus resolving the issue of frequent deployments and improving the stability of the log platform.

[0088] After a preset time interval, return to step 1 until the requirement to publish to all service instances in the latest obtained service instance list is completed.

[0089] In this context, the RD (Resource Development) function in the log platform can carry the preset duration in the triggered release command. The preset duration can be an integer number of minutes. For example, the preset duration can be 1 minute.

[0090] The process of publishing requirements based on requirement configuration files is as follows: Figure 4 As shown, during the demand release phase, tiered canary releases can be implemented for each service instance. Specifically, in the control module, a scheduled task is pre-set to check for any deployment operations every minute. When a deployment operation is detected, the scheduled task is triggered, and the control module retrieves a list of service instances from the cloud and generates or updates an active service instance list. This cloud can specifically be a Service Provider Interface (BNS), and the control module can query the BNS to obtain the service instance list. If the control module is retrieving the service instance list for the first time, an active service instance list is generated in the control module; otherwise, the active service instance list is updated based on the service instance list retrieved this time.

[0091] The control module retrieves the release progress from the release schedule table of the execution module and calculates the current release progress. For example, if configuration needs to be released to 100 service instances, and the required configuration files have already been released to 10 service instances, the calculated release progress is 10%.

[0092] The control module updates the service instances to be published into the release schedule table, which contains all service instances in the list of active service instances. The control module can update the service instances to be published in the release schedule table to the service instances to be published.

[0093] Then, the execution module obtains the release plan from the release plan table, which allows it to obtain the service instances to be released. Each service instance will request and pull the requirement configuration file in real time. The execution module can determine the version to be released for each service instance based on the release plan.

[0094] If the service instance requesting the requirement configuration file is a service instance to be published, and the current version of the service instance to be published is not the latest version, then the requirement configuration file can be distributed to the service instance to be published. Otherwise, the service instance should be informed to continue running with its current version.

[0095] Update the release status to the release schedule, and repeat the above process when the scheduled task is triggered again, until all service instances have completed the hot update.

[0096] like Figure 5 As shown, Figure 5This is an exemplary schematic diagram of a requirement release interface provided in this embodiment of the disclosure. The release list includes information such as the version number of each requirement configuration file, release type, release description, business function details, responsible person, status, release time, and operation buttons. Taking the first row of the release list as an example, the version number is 0.1.0, the release type is daily business release, the release description is add sid, the business function details are {“tcbox”:[736,1384,1381,1470],“ubc-deilver”:[736,1384,1381,1470]}, the responsible person is A, the status is completed, the release time is start time: 2022-09-06 16:56:38, end time: 2022-09-06 16:57:23, and the operations that can be performed include viewing diff (Difference), viewing the release status, and rolling back this configuration.

[0097] In addition, the R&D team in the log platform can also view the details of requirement releases, such as... Figure 6 As shown, during the requirement release process, the server distributes the requirement configuration file to each service instance one by one. After receiving the requirement configuration file, the R&D personnel in the log platform can also perform operations such as pausing, skipping, continuing, and proceeding to the next step for the requirement release of each service instance in the requirement release details interface. Figure 6 Each circle at the top indicates whether a service instance has completed a requirement release. A circle with a checkmark indicates that the requirement release is complete, for example... Figure 6 Service instance AG has completed the requirement release, while the last service instance H has not.

[0098] The log platform's R&D team can also search for relevant requirement release details by setting start time, end time, current percentage, and service instance name. Meanwhile, in... Figure 6 The second half of the deployment details will display the name of each instance and the status of the corresponding service instance. For example, in the first line of the deployment details, the instance name is bdapp-ubc-deliver-hnb_0001000000, and the status is false, meaning it is not in effect.

[0099] Using the above method, after the server obtains the service instance list from the cloud, it selects service instances to be published from the service instance list according to the preset release ratio. In this way, by selecting service instances to be published according to the preset release ratio and adopting a hierarchical gray release method, only a portion of service instances are hot-updated each time. When the demand information is updated again in a short period of time, it is not necessary to redeploy the demand to all service instances, thus improving the stability of the log platform.

[0100] Based on the above embodiments, this disclosure also provides a flowchart of a demand posting method, such as... Figure 7 As shown, it includes:

[0101] S701, Released.

[0102] S702, Is there a "launch order in the launch process"?

[0103] If yes, execute S712; otherwise, execute S703.

[0104] In the deployment process, a deployment order indicates that other requirement configuration files are being released in the current deployment process.

[0105] S703, pending review.

[0106] Additionally, an activation mode can be configured, which can be used for tiered canary releases of service instances or for simultaneous releases to all service instances globally. For example, if the total number of instances to be released is 100, and the activation mode is "10% 1 minute", this means that for the 100 instances, the configuration file will be released to 10 instances every minute.

[0107] In addition, during the pending review stage, the release can be manually revoked by the RD in the log platform.

[0108] S704, Review.

[0109] S705, Whether the review is approved.

[0110] If yes, execute S706; otherwise, execute S711.

[0111] During the release of a requirement, a second review can be conducted on the requirement that has been approved by the R&D team in the log platform. If the requirement information approved by the R&D team in the log platform still contains errors, such as errors in the format of the requirement information, the release can be revoked.

[0112] S706, currently online.

[0113] For approved requirements, the log platform can automatically generate requirement configuration files based on the requirements information, and then distribute each service instance in a tiered manner according to the generated requirement configuration files.

[0114] During the deployment process, users can manually choose to skip a specific service instance or pause the deployment process.

[0115] S707 has been suspended.

[0116] When the deployment process is paused, it can be manually restarted by the R&D team in the log platform to continue the process.

[0117] S708, go-live progress updates.

[0118] The process of coordinating and updating the launch progress will not be detailed here; please refer to the above. Figure 4 The relevant descriptions in the embodiments.

[0119] S709, online completed.

[0120] S710, successfully released.

[0121] S711 has been withdrawn.

[0122] S712, release failed.

[0123] Using the above method, the activation mode can be set according to actual business needs during the review stage, making the deployment process more flexible. Furthermore, for approved requirements, the server can automatically generate a configuration file in code format. Compared to the log platform's R&D department converting requirements into configuration files, this method reduces the risk of errors. During deployment, manual adjustments such as skipping, continuing, and pausing the deployment process are possible, allowing the log platform's R&D department to adjust the deployment process promptly and improving flexibility in responding to unforeseen circumstances. Using tiered canary releases for hot updates eliminates the need for frequent deployments, improving the stability of the log platform.

[0124] Based on the above embodiments, Figure 8 This is an exemplary schematic diagram illustrating a configuration release process completed through a self-service platform, as provided in this embodiment of the disclosure. Figure 8 This includes log platform users, log platform RD, self-service platform, database, service 1, service 2 and service 3.

[0125] Request providers can enter their requests in a specified format on the self-service platform. The R&D team in the log platform needs to review these requests, specifically the information entered by the request provider. If approved, the request is configured and issued on the self-service platform. The server hosting the self-service platform will automatically generate a request configuration file based on the information entered by the request provider and store it in the database. This allows for tiered deployment of services 1, 2, and 3. For details on the tiered deployment process, please refer to [link / reference]. Figure 4 Examples are not described here. Figure 8 Three services are illustrated as an example, but this disclosure does not impose a specific limit on the number of services.

[0126] The configuration autonomy platform provided in this disclosure supports user-inputted requirement information by requirement providers and has the ability to automatically generate requirement configuration files based on the requirement information entered by the requirement providers. It also supports persistent storage and version switching of requirement configuration files for different versions. During the requirement release process, hierarchical release is supported, and service instances can be released hierarchically through interfaces, Redis middleware, etc. This disclosure does not specifically limit the release method. Regarding permission management, it supports various dimensions of permission management, including log ID, product line, and other dimensions. Requirement input permissions can be delegated to log platform users, i.e., requirement providers, enabling the log platform to meet customized needs more flexibly.

[0127] Based on the same concept Figure 9 This is a schematic diagram of the structure of a demand publishing device provided in an embodiment of the present disclosure, including:

[0128] Module 901 is used to acquire the requirement information entered by the requirement provider in the requirement input interface according to the specified format.

[0129] The writing module 902 is used to write the approved requirement information into the requirement release table;

[0130] The conversion module 903 is used to convert the requirement information in the requirement release table into a requirement configuration file when a release instruction is received.

[0131] The publishing module 904 is used to publish the service requirements in the log middle platform based on the requirement configuration file converted by the conversion module 903.

[0132] Optionally, the acquisition module 901 is specifically used for:

[0133] The system obtains the APP ID and log ID entered by the requirement provider on the requirement entry interface, as well as the target requirement type selected through the menu bar, which includes a variety of preset requirement types.

[0134] In response to the target requirement type selected by the requirement provider, the requirement details filling template corresponding to the target requirement type is displayed on the requirement entry interface;

[0135] Target requirement details are generated based on the information filled in by the requirement provider in the requirement details form template;

[0136] The APP ID and log ID filled in by the requirement provider, the target requirement type, and the target requirement details are considered as a single requirement information.

[0137] Optionally, the device further includes:

[0138] The storage module is used to store the requirement information entered by the requirement provider into the requirement editing table;

[0139] The display module is used to display the requirement information to be reviewed on the review interface when a review request for the requirement information in the requirement editing table is received.

[0140] The writing module 902 is specifically used for:

[0141] When an approval instruction is received for the pending requirement information, the pending requirement information is written into the requirement release table.

[0142] Optionally, the conversion module 903 is specifically used for:

[0143] Collect all demand information with the same APP ID from the demand release table as a single demand information set.

[0144] For each set of demand information, multiple demand information with the same demand type and demand details in the set are aggregated into a demand information group. The demand information group includes the APP ID, the log ID of the multiple demand information, the demand type and demand details of a single demand information among the multiple demand information.

[0145] The requirement configuration file is generated based on all requirement information groups.

[0146] Optionally, the publishing module 904 is specifically used for:

[0147] Obtain a list of service instances from the cloud, including service instances that need to be published.

[0148] Select service instances to be published from the list of service instances according to the preset publication ratio;

[0149] Deploy the requirements for the service instance to be published according to the requirements configuration file.

[0150] After a preset time interval, return to the step of obtaining the service instance list from the cloud, until the requirement to publish the service instance list for all service instances in the latest obtained service instance list is completed.

[0151] Optionally, the publishing module 904 is specifically used for:

[0152] When a request to pull the requirement configuration file is received from the service instance to be published, the requirement configuration file is sent to the service instance to be published so that the service instance to be published can perform hot updates based on the requirement configuration file.

[0153] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0154] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0155] Figure 10 A schematic block diagram of an example electronic device 1000 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0156] like Figure 10 As shown, device 1000 includes a computing unit 1001, which can perform various appropriate actions and processes according to a computer program stored in read-only memory (ROM) 1002 or a computer program loaded from storage unit 1008 into random access memory (RAM) 1003. The RAM 1003 may also store various programs and data required for the operation of device 1000. The computing unit 1001, ROM 1002, and RAM 1003 are interconnected via bus 1004. Input / output (I / O) interface 1005 is also connected to bus 1004.

[0157] Multiple components in device 1000 are connected to I / O interface 1005, including: input unit 1006, such as keyboard, mouse, etc.; output unit 1007, such as various types of monitors, speakers, etc.; storage unit 1008, such as disk, optical disk, etc.; and communication unit 1009, such as network card, modem, wireless transceiver, etc. Communication unit 1009 allows device 1000 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0158] The computing unit 1001 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1001 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1001 performs the various methods and processes described above, such as the demand publishing method. For example, in some embodiments, the demand publishing method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1008. In some embodiments, part or all of the computer program may be loaded and / or installed on device 1000 via ROM 1002 and / or communication unit 1009. When the computer program is loaded into RAM 1003 and executed by the computing unit 1001, one or more steps of the demand publishing method described above may be performed. Alternatively, in other embodiments, the computing unit 1001 may be configured to perform the demand publishing method by any other suitable means (e.g., by means of firmware).

[0159] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0160] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0161] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0162] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0163] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0164] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0165] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0166] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for publishing requirements, comprising: Obtain the requirement information entered by the requirement provider in the requirement entry interface according to the specified format; Write the approved requirements into the requirements release form; When a release instruction is received, the requirement information in the requirement release table is converted into a requirement configuration file; Based on the aforementioned requirement configuration file, publish the requirements for the services in the log platform. The process of publishing requirements to services in the log platform based on the requirement configuration file includes: Obtain a list of service instances from the cloud, including service instances that need to be published. Select service instances to be published from the list of service instances according to the preset publication ratio; Deploy the requirements for the service instance to be published according to the requirements configuration file. After a preset time interval, return to the step of obtaining the service instance list from the cloud, until the demand for all service instances in the latest obtained service instance list is published; The step of publishing the service instance to be published according to the requirement configuration file includes: When a request to pull the requirement configuration file is received from the service instance to be published, the requirement configuration file is sent to the service instance to be published so that the service instance to be published can perform hot updates based on the requirement configuration file.

2. The method according to claim 1, wherein, The requirement information obtained by the requirement provider in the requirement input interface according to the specified format includes: The system obtains the APP ID and log ID entered by the requirement provider on the requirement entry interface, as well as the target requirement type selected through the menu bar, which includes a variety of preset requirement types. In response to the target requirement type selected by the requirement provider, a requirement details filling template corresponding to the target requirement type is displayed on the requirement entry interface; Target requirement details are generated based on the information filled in by the requirement provider in the requirement details form template; The APP ID and log ID filled in by the requirement provider, the target requirement type, and the target requirement details are considered as a single requirement information.

3. The method according to claim 1 or 2, Before writing the approved requirement information into the requirement release form, the method further includes: Store the requirement information entered by the requirement provider in the requirement editing table; When a request to review the requirement information in the requirement editing table is received, the requirement information to be reviewed is displayed on the review interface; The step of writing the approved requirement information into the requirement release table includes: When an approval instruction is received for the pending requirement information, the pending requirement information is written into the requirement release table.

4. The method according to claim 1, wherein, The step of converting the requirement information in the requirement release table into a requirement configuration file includes: Collect all demand information with the same APP ID from the demand release table as a single demand information set. For each set of demand information, multiple demand information with the same demand type and demand details in the set are aggregated into a demand information group. The demand information group includes the APP ID, the log ID of the multiple demand information, the demand type and demand details of a single demand information among the multiple demand information. The requirement configuration file is generated based on all requirement information groups.

5. A demand publishing device, comprising: The acquisition module is used to acquire the requirement information entered by the requirement provider in the requirement entry interface according to the specified format. The write module is used to write the approved requirement information into the requirement release table; The conversion module is used to convert the requirement information in the requirement release table into a requirement configuration file when a release instruction is received. The publishing module is used to publish requirements for services in the log middleware based on the requirement configuration file converted by the conversion module. The publishing module is specifically used for: Obtain a list of service instances from the cloud, including service instances that need to be published. Select service instances to be published from the list of service instances according to the preset publication ratio; Deploy the requirements for the service instance to be published according to the requirements configuration file. After a preset time interval, return to the step of obtaining the service instance list from the cloud, until the demand for all service instances in the latest obtained service instance list is published; The publishing module is specifically used for: When a request to pull the requirement configuration file is received from the service instance to be published, the requirement configuration file is sent to the service instance to be published so that the service instance to be published can perform hot updates based on the requirement configuration file.

6. The apparatus according to claim 5, wherein, The acquisition module is specifically used for: The system obtains the APP ID and log ID entered by the requirement provider on the requirement entry interface, as well as the target requirement type selected through the menu bar, which includes a variety of preset requirement types. In response to the target requirement type selected by the requirement provider, a requirement details filling template corresponding to the target requirement type is displayed on the requirement entry interface; Target requirement details are generated based on the information filled in by the requirement provider in the requirement details form template; The APP ID and log ID filled in by the requirement provider, the target requirement type, and the target requirement details are considered as a single requirement information.

7. The apparatus according to claim 5 or 6, The device further includes: The storage module is used to store the requirement information entered by the requirement provider into the requirement editing table; The display module is used to display the requirement information to be reviewed on the review interface when a review request for the requirement information in the requirement editing table is received. The writing module is specifically used for: When an approval instruction is received for the pending requirement information, the pending requirement information is written into the requirement release table.

8. The apparatus according to claim 5, wherein, The conversion module is specifically used for: Collect all demand information with the same APP ID from the demand release table as a single demand information set. For each set of demand information, multiple demand information with the same demand type and demand details in the set are aggregated into a demand information group. The demand information group includes the APP ID, the log ID of the multiple demand information, the demand type and demand details of a single demand information among the multiple demand information. The requirement configuration file is generated based on all requirement information groups.

9. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-4.

10. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-4.

11. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-4.

Images