A service publishing method and device, a server and a storage medium

Abstract

Embodiments of the present application relate to a service publishing method and device, a server and a storage medium. The method comprises: when a first service is received, generating a preset number of virtual machines based on the first service; updating a second service running in the preset number of virtual machines according to the first service; adjusting a running parameter of the first service in the preset number of virtual machines; and publishing the first service when the adjusted first service runs successfully in the preset number of virtual machines. Thus, the service can be published without stopping the service and affecting the existing service, reducing the probability of errors after the service is published, and improving the user experience.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of cloud service technology, and in particular to a service publishing method, apparatus, server and storage medium. Background Technology

[0002] With the rise of cloud services, rendering applications are increasingly shifting to the cloud: local model creation, cloud uploading, cloud optimization, cloud-based final scene construction, and content dissemination and service updates based on cloud-provided distribution methods. Therefore, shifting testing to the right plays a crucial role in model processing and service release workflows. This shift includes stable service release, monitoring, and risk control. As project development becomes increasingly agile, shifting testing to the right within the domain, particularly for model transformation and lightweight workflow systems, requires measures to identify and mitigate service issues.

[0003] Deploying existing services can impact existing services, and issues cannot be quickly and accurately monitored on the development side. Therefore, how to ensure stable service deployment, monitoring, and risk control during the shift-right testing process has become a pressing issue. Summary of the Invention

[0004] In view of this, in order to solve the above-mentioned technical problems or some of the technical problems, embodiments of the present invention provide a service publishing method, apparatus, server and storage medium.

[0005] In a first aspect, embodiments of the present invention provide a service publishing method, including:

[0006] Upon receiving the first service, a preset number of virtual machines are generated based on the first service;

[0007] Update the second service running in the preset number of virtual machines according to the first service;

[0008] Adjust the running parameters of the first service in the preset number of virtual machines;

[0009] When the adjusted first service runs successfully on the preset number of virtual machines, the first service is published.

[0010] In one possible implementation, generating a preset number of virtual machines based on the first service includes:

[0011] The first service is divided into a preset number of sub-services;

[0012] Generate a preset number of system images based on the preset number of sub-services;

[0013] The preset number of virtual machines are generated based on the preset number of system images, and there is a one-to-one correspondence between the preset number of sub-services, the preset number of system images, and the preset number of virtual machines.

[0014] In one possible implementation, updating the second service running in the preset number of virtual machines according to the first service includes:

[0015] When the framework of the first service changes, but the function corresponding to the first service remains unchanged, the virtual machine corresponding to the first service is updated according to the first service, and the first service is run according to the second code segment corresponding to the second service.

[0016] When the framework of the first service changes and the corresponding function of the first service changes, the virtual machine corresponding to the first service is updated according to the first service, and the first service is run according to the first code segment corresponding to the first service.

[0017] In one possible implementation, the method further includes:

[0018] When the first service is running, the daemon process in the first service controls the scheduling of the target task in the first service to the first process for processing.

[0019] When the target task fails to process, the daemon process is controlled to schedule the target task to the second process in the first service for processing.

[0020] In one possible implementation, the method further includes:

[0021] The business data in the second service is run within the framework of the first service;

[0022] When the result of the operation of the business data in the framework of the first service is consistent with the result of the operation of the business data in the framework of the second service, a preset number of virtual machines are generated based on the first service.

[0023] In one possible implementation, the method further includes:

[0024] The target frequency of the first service's output logs is determined based on the business level corresponding to the first service.

[0025] During the operation of the first service, logs in a preset format are output according to the target frequency;

[0026] Determine the category information of the log in the preset format;

[0027] The log monitoring system for the first service is generated based on the preset format logs and the category information.

[0028] In one possible implementation, the method further includes:

[0029] Monitor the parameter information of the server and the runtime of each program in the first service;

[0030] An alarm event is triggered when the parameter information meets the first preset condition, or when the runtime meets the second preset condition.

[0031] In a second aspect, embodiments of the present invention provide a service publishing apparatus, comprising:

[0032] The generation module is used to generate a preset number of virtual machines based on the first service when the first service is received.

[0033] A first processing module is configured to update the second service running in the preset number of virtual machines according to the first service;

[0034] The first processing module is used to adjust the running parameters of the first service in the preset number of virtual machines;

[0035] The second processing module is used to publish the first service when the adjusted first service runs successfully on the preset number of virtual machines.

[0036] Thirdly, embodiments of the present invention provide a server, including a processor and a memory, wherein the processor is configured to execute a service publishing program stored in the memory to implement the service publishing method described in any one of the first aspects above.

[0037] Fourthly, embodiments of the present invention provide a storage medium storing one or more programs, which can be executed by one or more processors to implement the service publishing method described in any one of the first aspects.

[0038] The service publishing scheme provided in this invention involves generating a preset number of virtual machines based on a first service upon receipt; updating a second service running in the preset number of virtual machines according to the first service; adjusting the running parameters of the first service in the preset number of virtual machines; and publishing the first service when the adjusted first service runs successfully in the preset number of virtual machines. This achieves seamless service publishing without service interruption or impact on existing services, reducing the probability of errors after service publishing and improving user experience. Attached Figure Description

[0039] Figure 1A flowchart illustrating a service publishing method provided in an embodiment of the present invention;

[0040] Figure 2 A flowchart illustrating another service publishing method provided in an embodiment of the present invention;

[0041] Figure 3 This is a schematic diagram of the structure of a service publishing device provided in an embodiment of the present invention;

[0042] Figure 4 This is a schematic diagram of a server structure provided in an embodiment of the present invention. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0044] To facilitate understanding of the embodiments of the present invention, further explanations and descriptions will be provided below with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of the present invention.

[0045] Figure 1 This is a flowchart illustrating a service publishing method provided in an embodiment of the present invention, such as... Figure 1 As shown, the method specifically includes:

[0046] S11. When the first service is received, a preset number of virtual machines are generated based on the first service.

[0047] The service publishing method provided in this embodiment of the invention is applied to a server or physical machine. Since the deployment of a server and the publishing of services is a relatively complicated task, requiring the installation of many things on the system environment, and problems may occur to the services if not handled carefully, this embodiment completes the updating, running and publishing of services by establishing a virtual machine in the server.

[0048] In this embodiment, the first service is a newly launched service (e.g., the latest version of an application). When the first service is launched, the server obtains the first service and packages the environment and service program corresponding to the first service into a system image. Based on the system image, a preset number of virtual machines (e.g., 3 virtual machines) corresponding to the first service are generated in the server. The virtual machines complete the operation of the service, thereby enabling the service to be tested through a preset number of small-scale virtual machines.

[0049] S12. Update the second service running in the preset number of virtual machines according to the first service.

[0050] In this embodiment, a second service is pre-running in each virtual machine. The second service can be a historical service corresponding to the first service; for example, the second service is a previous version of the first service. Compared with the first service, the second service may have undergone changes in framework and / or program. The second service in the virtual machine is updated by the first service to simulate the service going live process.

[0051] Specifically, since the service itself is an executable program running on a virtual machine, when the program of the second service is updated through the first service, changes are actually made to the virtual machine running the executable program. These changes can include: changing environment variables, integrating the new executable program and saving it as a new system image, etc.

[0052] Furthermore, when a service needs to be hot-updated, the virtual machine must wait until the currently executing task is completed before safely exiting the application, ending the virtual machine's operation, and restarting the virtual machine image with the new program from the first service. This implements a strategy of securely updating the second service through the first service.

[0053] S13. Adjust the running parameters of the first service in the preset number of virtual machines.

[0054] In this embodiment, when the first service is updated to the virtual machine, problems may occur during runtime. These problems can be resolved by adjusting the runtime parameters of the virtual machine and the first service, so that the first service can run normally. The runtime parameters may include, but are not limited to, environment variables, signal sending, service execution behavior, service execution path, code in the service, and control variables.

[0055] Specifically, by adjusting the running parameters of the virtual machine and the first service, the behavior of the virtual machine and the running service can be controlled. This can solve problems that occur during the operation of the first service, so that the behavior of the virtual machine and the first service meets the expected standards set by the developers. This makes it easier to control the behavior of the service in the early stages of business launch, adjust the first service in a timely manner, and minimize the impact of problems that occur during operation, so that the first service can run normally in the virtual machine.

[0056] S14. When the adjusted first service runs successfully on the preset number of virtual machines, the first service is published.

[0057] In this embodiment, when the adjusted first service runs on the virtual machine and meets the expected standards set by the developers, it indicates that the operation is successful and stable. The first service is then fully covered by modifying the switch status in the code of all servers, thereby realizing the release of the first service.

[0058] The service publishing method provided in this invention involves: upon receiving a first service, generating a preset number of virtual machines based on the first service; updating a second service running in the preset number of virtual machines according to the first service; adjusting the running parameters of the first service in the preset number of virtual machines; and publishing the first service when the adjusted first service runs successfully in the preset number of virtual machines. This achieves seamless service publishing without service interruption or impact on existing services, reducing the probability of errors after service publishing and improving user experience.

[0059] Figure 2 This is a flowchart illustrating another service publishing method provided in an embodiment of the present invention, as shown below. Figure 2 As shown, the method specifically includes:

[0060] S21. When the first service is received, the first service is divided into a preset number of sub-services; a preset number of system images are generated based on the preset number of sub-services; and a preset number of virtual machines are generated based on the preset number of system images.

[0061] In this embodiment, since problems are prone to occur during service operation, manual problem-solving can lead to delays, which can cause losses to the project or company. Therefore, it is necessary to implement risk control measures for potential problems in advance.

[0062] Therefore, risk mitigation design should begin from the requirements and design phases (e.g., distributed deployment to share risk, decentralization, dependency reduction, etc.). This embodiment divides the first service into its smallest units during the design phase, specifically into a preset number of sub-services. The preset number represents the maximum number of sub-services the first service can be divided into. Each sub-service handles only one task, and the entire first service is composed of multiple sub-services. This allows for rapid location of the problematic sub-service if an issue is detected during the first service's operation.

[0063] Furthermore, a corresponding system image is generated for each sub-service, and a corresponding virtual machine is generated based on each system image. Each virtual machine pre-runs the sub-services of the second service and their corresponding system images. The second service is a historical version of the first service. A preset number of system images and virtual machines are obtained, with a one-to-one correspondence between the preset number of sub-services, system images, and virtual machines. By running each sub-service and system image of the first service on the corresponding virtual machine, updates to the second service within the virtual machine can be achieved.

[0064] In one possible implementation, before generating the virtual machine, it is determined whether the first service is undergoing a major version update (e.g., the application is being updated from version 1.0 to version 2.0). Before a major version update, in addition to necessary requirements testing and stress testing, a necessary step is traffic replay, which involves rerunning the entire test system using business processes that have been handled online in the past month, such as conversion and face reduction tasks in the model service. The results of the new version are then compared with those obtained online to see if they are consistent.

[0065] Specifically, extract the business data from the second service and run it within the framework of the first service. When the results of running the business data within the framework of the first service are consistent with the results of running the business data within the framework of the second service, it indicates that the first service has no serious problems and can be updated. At this point, a preset number of virtual machines are generated based on the first service.

[0066] S22. When the framework of the first service changes, but the function corresponding to the first service remains unchanged, update the virtual machine corresponding to the first service according to the first service, and run the first service according to the second code segment corresponding to the second service.

[0067] In this embodiment, the first service will be used to represent the sub-services in S21. That is, the first service in this embodiment can represent multiple corresponding sub-services. The server determines whether the framework of the first service has changed compared to the second service, and whether the function implemented by the first service has changed. When the framework has changed but the function has not changed, it means that the system images of the second service and the second service in the virtual machine need to be updated according to the first service and the system image of the first service, and the first service needs to be run according to the code segment corresponding to the second service, that is, the first service needs to be run according to the old process in the second service.

[0068] Specifically, from a functional perspective: a switch (control variable) is set in the code segment. A switch is added to the functional logic entry point of each code segment to control the branch path in the operation of the first service (for example, the branch path can be to follow the old process in the second service or to follow the new process in the first service). In this embodiment, the switch controls the subsequent logic to go to the code segment corresponding to the second service so that the first service is run according to the old process of the second service.

[0069] S23. When the framework of the first service changes and the function corresponding to the first service changes, update the virtual machine corresponding to the first service according to the first service, and run the first service according to the first code segment corresponding to the first service.

[0070] In this embodiment, the server determines whether the framework of the first service has changed compared to the second service, and whether the function implemented by the first service has changed. When the framework and function have changed, it means that the second service and the system image of the second service in the virtual machine need to be updated according to the first service and the system image of the first service, and the old process of the second service needs to be updated to the new process corresponding to the first service. That is, the first service is run according to the code segment corresponding to the first service.

[0071] Specifically, from a functional perspective: A switch controls subsequent logic to navigate to the code segment corresponding to the first service, thus enabling the first service to run according to its new workflow. In actual service deployment, after determining the workflow and code segment executed by the first service, environment variables are configured to modify the service's execution behavior.

[0072] Furthermore, during the update process, from the perspective of hot update and release procedures: relying on Docker technology, the service itself is an executable program running on a virtual machine. When the service program needs to be updated, changes are actually made to the virtual machine running the historical program, such as changing environment variables based on the first service and its system image, integrating the new executable program and saving it as a new system image; when a hot update is needed, the old virtual machine must wait for the previous task to complete, safely exit the application, terminate the virtual machine's operation, and restart the virtual machine image containing the first service program, implementing a secure update strategy. Once an issue is discovered online, the service's execution branch can be adjusted promptly via signals, ensuring good control over the service's execution behavior regardless of the number of services deployed, without needing to modify the deployment sequentially.

[0073] S24. When the first service is running, control the daemon process in the first service to schedule the target task in the first service to the first process for processing; when the target task fails to process, control the daemon process to schedule the target task to the second process in the first service for processing.

[0074] In this embodiment, when the first service finishes updating the virtual machine and is running, a fallback plan is pre-set for important tasks in the first service to reduce the possibility of problems during task execution. When the first service runs, pre-configured daemons and daemon processes are started first. The daemon processes do not actually handle tasks; instead, they dispatch the target task to the corresponding process of the pre-configured fallback program. For example, the daemon process dispatches the target task to the first process for processing and monitors the execution status of the first process. If the first process exits abnormally or fails to process, the task is scheduled to the second process for continued processing, and so on, until the daemon process determines a process that can successfully execute the target task, and then the target task is processed. If all fallback processes fail, feedback is directly sent to the development team via an IM tool. After the development team resolves the issue, the first service continues to run.

[0075] S25. Adjust the running parameters of the corresponding sub-services in the preset number of virtual machines.

[0076] S26. When the adjusted first service runs successfully on the preset number of virtual machines, the first service is published.

[0077] S25-S26 and Figure 1 Similar to S13-S14, this is a brief description and can be referred to. Figure 1 The relevant descriptions will not be repeated here.

[0078] S27. Determine the target frequency of log output for the first service based on the business level corresponding to the first service; during the operation of the first service, output logs in a preset format according to the target frequency; determine the category information of the logs in the preset format; generate a log monitoring system for the first service based on the logs in the preset format and the category information.

[0079] In this embodiment, after the first service is published, log monitoring is required during the operation of the first service. Logs are the most intuitive record of service execution and the most basic source of data for us to analyze online problems and perform data statistics. Therefore, it is essential to take control of the logs.

[0080] First, to ensure the completeness of logs and enable operations personnel to quickly identify problems through them, we need to create a log monitoring system. (For example, if a submitted model processing task is delayed, our operations personnel can quickly pinpoint which service flow is causing the problem through the logs and provide feedback to both users and development.) This requires testing and operations to be deeply involved in the implementation of technical assessments during the requirements formulation phase, proposing log formats to facilitate rapid tracking of potential issues across the entire business line. In other words, the log format should be pre-set based on the business needs of operations and development personnel, the problems to be identified, and the business context.

[0081] Simultaneously, log snapshots are designed for certain processing services. For some services, which are comprehensive processing modules, simply outputting a single log entry is insufficient for tracking and resolving issues. Therefore, we need to output the complete memory state of this service to the logs. In other words, the logs should not only contain the execution steps and encountered problems, but also include a memory snapshot. Memory snapshots can be created by periodically capturing snapshots or triggering critical business logic.

[0082] Simultaneously, logs are tiered. Tiering refers to determining the business level of a primary service, setting the target frequency for log output based on the business level, and outputting logs in a preset format according to the target frequency (for example, newly launched services are tier 1 with a target frequency of once a week, while stable services are tier 2 with a target frequency of once a month). For memory snapshots, to reduce invalid log output, high-frequency output may only be used in newly launched business logic, while low-frequency output may be used in stable business processes, achieving precise monitoring.

[0083] Furthermore, during project development, the category information for each log (such as application type, business type, file line number, error message, etc.) was predefined. This has the advantage of making it very convenient to retrieve the corresponding information when the corresponding log file is available. From this perspective, it greatly facilitates the daily work of operations and maintenance. However, this log information is micro-level, specific data. When seeking macro-level statistical information, simply listing the data becomes insufficient. Therefore, based on this, we store all logs in a database according to a preset format and category information, and encapsulate SQL statements through a user interface. With appropriate input conditions, the current processing status of each server can be retrieved. Thus, a log monitoring system can be obtained through this database. This log monitoring system, through its user interface, can greatly assist operations and maintenance personnel without a technical background, allowing for quick retrieval based on key, problem-prone points.

[0084] In one possible implementation, a scheduled task is established on the log monitoring system to periodically retrieve target messages based on certain conditions. Once a problem is detected in the target message, it is linked with IM tools such as DingTalk or email to promptly push alarm messages to the R&D side, thereby establishing a comprehensive log monitoring system.

[0085] S28. Monitor the parameter information of the server and the runtime of each program in the first service; when the parameter information meets the first preset condition, or when the runtime meets the second preset condition, trigger an alarm event.

[0086] In this embodiment, it is necessary to monitor the performance during the operation of the first service. Although a service will undergo stress testing before going live, performance pressure will still occur after the official launch due to the limitations of the testing scenario. Therefore, we need to establish a visual performance monitoring system.

[0087] Specifically, the first step is to monitor the server hardware and obtain its parameter information. This information may include the server's hard drive and CPU usage, network usage, and, if rendering is required, GPU usage. These hardware parameters can be effectively recorded and visualized using monitoring tools (e.g., Monitor). The initial preset conditions may include, but are not limited to: detecting server hardware failure, CPU usage exceeding a set threshold, and network occupancy exceeding a set threshold. Once a problem is identified, it is reported to the operations and maintenance personnel via instant messaging (IM) to trigger an alert.

[0088] Secondly, it involves time monitoring within the first service's programs, such as monitoring the runtime of each program or function. This is specifically done by inserting monitoring data into the program using a stubbing method, and then posting the data via HTTP at runtime, visualizing it as a flame graph. The second preset condition may include, but is not limited to, runtime exceeding a set threshold, or runtime not falling within a specific time period. When the monitored runtime meets the second preset condition, a problem is identified in the first service, and the issue is reported to the operations and maintenance personnel via an instant messaging tool to trigger an alert.

[0089] In one possible implementation, public opinion monitoring can also be conducted on the first service. The monitoring methods include: the R&D side passively waiting for issues to be submitted by the operations side and actively discovering issues through various channels.

[0090] Specifically, when handling issues submitted by the operations team, a bot is set up in the IM tool to filter the issues submitted by operations. The bot generates answers related to the tags in the issues and sends them to the operations team. These answers help the operations team understand the origin of the issues and, to some extent, help them solve the problems themselves. For issue process tracking, it is linked to a management system similar to PMS and notifies the development team via IM notifications. After the development team solves the problem, they provide feedback in the PMS system.

[0091] When the development team needs to proactively identify issues, a monitoring system is used to monitor various platforms (e.g., Baidu Tieba, forums, etc.). Problems are searched for on these platforms based on sensitive keywords (keywords corresponding to the problematic parts), and this information is directly reported to operations and maintenance (O&M). O&M then manually filters the issues, allowing for rapid problem identification and improved efficiency. This establishes a comprehensive, data-driven proactive defense mechanism. Furthermore, a monitoring mechanism combining hardware and time-based monitoring can be established, triggering alerts via instant messaging tools when hardware anomalies or program problems are detected.

[0092] The service publishing method provided in this invention involves dividing a first service into a preset number of sub-services; generating a preset number of virtual machines based on the preset number of sub-services; updating the virtual machines according to the first service and running the first service according to the second code segment of the second service when the framework of the first service changes but the functionality remains the same; updating the virtual machines according to the first service and running the first service according to the first code segment of the first service when the framework of the first service changes and the functionality changes; controlling a daemon process to schedule target tasks to a first process; when the target task fails to process, the daemon process schedules the target task to a second process for processing; when the first service runs successfully in the virtual machine, the first service is published, and a log monitoring system for the first service is generated to monitor the first service. This method enables seamless publishing of new services without interrupting service or affecting existing services, avoids potential problems before publishing, and allows for rapid detection and location of problems on the development side after publishing, reducing the probability of problems in the service, optimizing the service publishing process, and improving problem detection efficiency.

[0093] Figure 3 This is a schematic diagram of the structure of a service publishing device provided in an embodiment of the present invention, such as... Figure 3 As shown, the device specifically includes:

[0094] Generation module 31 is used to generate a preset number of virtual machines based on the first service when the first service is received;

[0095] The first processing module 32 is used to update the second service running in the preset number of virtual machines according to the first service;

[0096] The first processing module 32 is used to adjust the running parameters of the first service in the preset number of virtual machines;

[0097] The second processing module 33 is used to publish the first service when the adjusted first service runs successfully on the preset number of virtual machines.

[0098] In one possible implementation, the generation module 31 is specifically used to divide the first service into a preset number of sub-services;

[0099] Generate a preset number of system images based on the preset number of sub-services;

[0100] The preset number of virtual machines are generated based on the preset number of system images, and there is a one-to-one correspondence between the preset number of sub-services, the preset number of system images, and the preset number of virtual machines.

[0101] In one possible implementation, the first processing module 32 is specifically used to update the virtual machine corresponding to the first service according to the first service and run the first service according to the second code segment corresponding to the second service when the framework of the first service changes and the function corresponding to the first service does not change.

[0102] When the framework of the first service changes and the corresponding function of the first service changes, the virtual machine corresponding to the first service is updated according to the first service, and the first service is run according to the first code segment corresponding to the first service.

[0103] In one possible implementation, the first processing module 32 is further configured to control the daemon process in the first service to schedule the target task in the first service to the first process for processing when the first service is running.

[0104] When the target task fails to process, the daemon process is controlled to schedule the target task to the second process in the first service for processing.

[0105] In one possible implementation, the generation module 31 is further configured to run the business data in the second service within the framework of the first service;

[0106] When the result of the operation of the business data in the framework of the first service is consistent with the result of the operation of the business data in the framework of the second service, a preset number of virtual machines are generated based on the first service.

[0107] In one possible implementation, the generation module 31 is further configured to determine the target frequency of the output logs of the first service based on the business level corresponding to the first service.

[0108] During the operation of the first service, logs in a preset format are output according to the target frequency;

[0109] Determine the category information of the log in the preset format;

[0110] The log monitoring system for the first service is generated based on the preset format logs and the category information.

[0111] In one possible implementation, the monitoring module 34 is used to monitor the parameter information of the server and the runtime of each program in the first service.

[0112] An alarm event is triggered when the parameter information meets the first preset condition, or when the runtime meets the second preset condition.

[0113] The service publishing device provided in this embodiment can be as follows: Figure 3 The apparatus shown can perform, as Figure 1-2 All steps of the service publishing method are then implemented to achieve... Figure 1-2 For details on the technical effects of the service publishing method shown, please refer to [link / reference]. Figure 1-2 The relevant descriptions are presented concisely and will not be elaborated upon here.

[0114] Figure 4 This is a schematic diagram of the structure of a server provided in an embodiment of the present invention. Figure 4 The server 400 shown includes at least one processor 401, memory 402, at least one network interface 404, and other user interfaces 403. The various components in the server 400 are coupled together via a bus system 405. It is understood that the bus system 405 is used to implement communication between these components. In addition to a data bus, the bus system 405 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 4 The general designated all buses as Bus System 405.

[0115] The user interface 403 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

[0116] It is understood that the memory 402 in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 402 described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0117] In some implementations, memory 402 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 4021 and application program 4022.

[0118] The operating system 4021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 4022 includes various applications, such as a media player and a browser, used to implement various application functions. The program implementing the method of this embodiment can be included in the application program 4022.

[0119] In this embodiment of the invention, by calling the program or instructions stored in the memory 402, specifically the program or instructions stored in the application program 4022, the processor 401 executes the method steps provided in each method embodiment, including, for example:

[0120] Upon receiving the first service, a preset number of virtual machines are generated based on the first service;

[0121] Update the second service running in the preset number of virtual machines according to the first service;

[0122] Adjust the running parameters of the first service in the preset number of virtual machines;

[0123] When the adjusted first service runs successfully on the preset number of virtual machines, the first service is published.

[0124] In one possible implementation, the first service is divided into a preset number of sub-services;

[0125] Generate a preset number of system images based on the preset number of sub-services;

[0126] The preset number of virtual machines are generated based on the preset number of system images, and there is a one-to-one correspondence between the preset number of sub-services, the preset number of system images, and the preset number of virtual machines.

[0127] In one possible implementation, when the framework of the first service changes but the function corresponding to the first service remains unchanged, the virtual machine corresponding to the first service is updated according to the first service, and the first service is run according to the second code segment corresponding to the second service.

[0128] When the framework of the first service changes and the corresponding function of the first service changes, the virtual machine corresponding to the first service is updated according to the first service, and the first service is run according to the first code segment corresponding to the first service.

[0129] In one possible implementation, when the first service is running, the daemon process in the first service controls the scheduling of the target task in the first service to the first process for processing.

[0130] When the target task fails to process, the daemon process is controlled to schedule the target task to the second process in the first service for processing.

[0131] In one possible implementation, the business data in the second service is run within the framework of the first service;

[0132] When the result of the operation of the business data in the framework of the first service is consistent with the result of the operation of the business data in the framework of the second service, a preset number of virtual machines are generated based on the first service.

[0133] In one possible implementation, the target frequency of the first service output logs is determined based on the service level corresponding to the first service.

[0134] During the operation of the first service, logs in a preset format are output according to the target frequency;

[0135] Determine the category information of the log in the preset format;

[0136] The log monitoring system for the first service is generated based on the preset format logs and the category information.

[0137] In one possible implementation, the parameter information of the server and the runtime of each program in the first service are monitored.

[0138] An alarm event is triggered when the parameter information meets the first preset condition, or when the runtime meets the second preset condition.

[0139] The methods disclosed in the above embodiments of the present invention can be applied to processor 401, or implemented by processor 401. Processor 401 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 401 or by instructions in the form of software. The processor 401 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of the present invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 402. Processor 401 reads the information in memory 402 and, in conjunction with its hardware, completes the steps of the above method.

[0140] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0141] For software implementation, the techniques described herein can be implemented by units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0142] The server provided in this embodiment can be as follows: Figure 4 The server shown can perform, for example Figure 1-2 All steps of the service publishing method are then implemented to achieve... Figure 1-2 For details on the technical effects of the service publishing method shown, please refer to [link / reference]. Figure 1-2 The relevant descriptions are presented concisely and will not be elaborated upon here.

[0143] This invention also provides a storage medium (computer-readable storage medium). This storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; the memory may also include combinations of the above types of memory.

[0144] When one or more programs in the storage medium can be executed by one or more processors to implement the service publishing method described above that is executed on the device side.

[0145] The processor is used to execute a service publishing program stored in memory to implement the following steps of a service publishing method executed on the device side:

[0146] Upon receiving the first service, a preset number of virtual machines are generated based on the first service;

[0147] Update the second service running in the preset number of virtual machines according to the first service;

[0148] Adjust the running parameters of the first service in the preset number of virtual machines;

[0149] When the adjusted first service runs successfully on the preset number of virtual machines, the first service is published.

[0150] In one possible implementation, the first service is divided into a preset number of sub-services;

[0151] Generate a preset number of system images based on the preset number of sub-services;

[0152] The preset number of virtual machines are generated based on the preset number of system images, and there is a one-to-one correspondence between the preset number of sub-services, the preset number of system images, and the preset number of virtual machines.

[0153] In one possible implementation, when the framework of the first service changes but the function corresponding to the first service remains unchanged, the virtual machine corresponding to the first service is updated according to the first service, and the first service is run according to the second code segment corresponding to the second service.

[0154] When the framework of the first service changes and the corresponding function of the first service changes, the virtual machine corresponding to the first service is updated according to the first service, and the first service is run according to the first code segment corresponding to the first service.

[0155] In one possible implementation, when the first service is running, the daemon process in the first service controls the scheduling of the target task in the first service to the first process for processing.

[0156] When the target task fails to process, the daemon process is controlled to schedule the target task to the second process in the first service for processing.

[0157] In one possible implementation, the business data in the second service is run within the framework of the first service;

[0158] When the result of the operation of the business data in the framework of the first service is consistent with the result of the operation of the business data in the framework of the second service, a preset number of virtual machines are generated based on the first service.

[0159] In one possible implementation, the target frequency of the first service output logs is determined based on the service level corresponding to the first service.

[0160] During the operation of the first service, logs in a preset format are output according to the target frequency;

[0161] Determine the category information of the log in the preset format;

[0162] The log monitoring system for the first service is generated based on the preset format logs and the category information.

[0163] In one possible implementation, the parameter information of the server and the runtime of each program in the first service are monitored.

[0164] An alarm event is triggered when the parameter information meets the first preset condition, or when the runtime meets the second preset condition.

[0165] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0166] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0167] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A service publishing method, characterized in that, Applied to servers, including: Upon receiving the first service, a preset number of virtual machines are generated based on the first service; Update the second service running in the preset number of virtual machines according to the first service; Adjust the running parameters of the first service in the preset number of virtual machines; When the adjusted first service runs successfully on the preset number of virtual machines, the first service is published; The generation of a preset number of virtual machines based on the first service includes: The first service is divided into a preset number of sub-services; Generate a preset number of system images based on the preset number of sub-services; The preset number of virtual machines are generated based on the preset number of system images, and the preset number of sub-services, the preset number of system images, and the preset number of virtual machines correspond one-to-one. The step of updating the second service running in the preset number of virtual machines according to the first service includes: When the framework of the first service changes, but the function corresponding to the first service remains unchanged, the virtual machine corresponding to the first service is updated according to the first service, and the first service is run according to the second code segment corresponding to the second service. When the framework of the first service changes and the corresponding function of the first service changes, the virtual machine corresponding to the first service is updated according to the first service, and the first service is run according to the first code segment corresponding to the first service.

2. The method according to claim 1, characterized in that, The method further includes: When the first service is running, the daemon process in the first service controls the scheduling of the target task in the first service to the first process for processing. When the target task fails to process, the daemon process is controlled to schedule the target task to the second process in the first service for processing.

3. The method according to claim 1, characterized in that, The method further includes: The business data in the second service is run within the framework of the first service; When the result of the operation of the business data in the framework of the first service is consistent with the result of the operation of the business data in the framework of the second service, a preset number of virtual machines are generated based on the first service.

4. The method according to claim 1, characterized in that, The method further includes: The target frequency of the first service's output logs is determined based on the business level corresponding to the first service. During the operation of the first service, logs in a preset format are output according to the target frequency; Determine the category information of the log in the preset format; The log monitoring system for the first service is generated based on the preset format logs and the category information.

5. The method according to claim 1, characterized in that, The method further includes: Monitor the parameter information of the server and the runtime of each program in the first service; An alarm event is triggered when the parameter information meets the first preset condition, or when the runtime meets the second preset condition.

6. A service publishing device, characterized in that, include: The generation module is used to generate a preset number of virtual machines based on the first service when the first service is received. The first processing module is configured to update the second service running in the preset number of virtual machines according to the first service; The first processing module is used to adjust the running parameters of the first service in the preset number of virtual machines; The second processing module is used to publish the first service when the adjusted first service runs successfully on the preset number of virtual machines; The generation of a preset number of virtual machines based on the first service includes: The first service is divided into a preset number of sub-services; Generate a preset number of system images based on the preset number of sub-services; The preset number of virtual machines are generated based on the preset number of system images, and the preset number of sub-services, the preset number of system images, and the preset number of virtual machines correspond one-to-one. The step of updating the second service running in the preset number of virtual machines according to the first service includes: When the framework of the first service changes, but the function corresponding to the first service remains unchanged, the virtual machine corresponding to the first service is updated according to the first service, and the first service is run according to the second code segment corresponding to the second service. When the framework of the first service changes and the corresponding function of the first service changes, the virtual machine corresponding to the first service is updated according to the first service, and the first service is run according to the first code segment corresponding to the first service.

7. A server, characterized in that, include: A processor and a memory, the processor being configured to execute a service publishing program stored in the memory to implement the service publishing method according to any one of claims 1 to 5.

8. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the service publishing method according to any one of claims 1 to 5.

Images