Service parameter updating method and device, storage medium and electronic equipment

Abstract

The invention discloses a service parameter updating method and device, a storage medium and electronic equipment. The method comprises the steps that under the condition that service instances in a parent view meet drilling conditions, a child view is generated, the parent view is used for displaying corresponding service instances with different service types deployed on the same cloud platform, and the child view is used for displaying the service instances meeting the drilling conditions; the drilling condition is related to a service parameter of the service instance in the parent view; target operation is executed on the service instances in the sub-views, target service parameters are updated, the target operation is operation in an intersection operation set corresponding to the sub-views, the intersection operation set is determined by operation sets corresponding to the service instances in the sub-views, and the target service parameters correspond to the service instances in the sub-views. The technical problem that the updating efficiency of the service parameters is too low is solved.

Description

Technical Field

[0001] This application relates to the field of computers, and in particular, to a method and device for updating service parameters, a storage medium, and an electronic device. Background Art

[0002] In the field of cloud computing, with the explosive growth of service types and quantities, the unified management and operation of different types of services have become increasingly complex. In the prior art, for batch operations of hybrid services, it usually relies on pre-defined orchestration processes, groups services according to attributes such as type and status, and then executes serial or parallel operations one by one. This process not only takes time, but also in the face of service type diversity, it is necessary to define independent processes for each combination, resulting in the technical problem of low efficiency in updating service parameters.

[0003] For the above problems, no effective solution has been proposed yet. Summary of the Invention

[0004] Embodiments of this application provide a method and device for updating service parameters, a storage medium, and an electronic device to at least solve the technical problem of too low efficiency in updating service parameters.

[0005] According to one aspect of the embodiments of this application, a method for updating service parameters is provided, including: generating a sub-view when a service instance in a parent view meets the drill-down condition, where the parent view is used to display service instances with different corresponding service types deployed on the same cloud platform, the sub-view is used to display service instances that meet the drill-down condition, and the drill-down condition is related to the service parameters of the service instances in the parent view; performing a target operation on the service instances in the sub-view to update the target service parameters, where the target operation is an operation in an intersection operation set corresponding to the sub-view, the intersection operation set is determined by the operation sets corresponding to the service instances in the sub-view respectively, and the target service parameters correspond to the service instances in the sub-view.

[0006] According to another aspect of the embodiments of the present application, there is also provided an update device for service parameters, including: a generation module, configured to generate a sub-view when a service instance in a parent view meets a drilling condition, where the parent view is used to display service instances of different corresponding service types deployed on the same cloud platform, the sub-view is used to display service instances that meet the drilling condition, and the drilling condition is related to the service parameters of the service instances in the parent view; an update module, configured to perform a target operation on the service instances in the sub-view to update target service parameters, where the target operation is an operation in an intersection operation set corresponding to the sub-view, and the intersection operation set is determined by operation sets corresponding to the service instances in the sub-view respectively, and the target service parameters correspond to the service instances in the sub-view.

[0007] Optionally, the device is further configured to: before generating a sub-view when a service instance in a parent view meets a drilling condition, publish configuration files corresponding to each service in a service set, where the configuration files are used to indicate the service parameters; generate service instances corresponding to each service respectively based on the configuration files, where the service instances inherit at least one of service attributes, service statuses, and operation instructions of the corresponding services, and the service parameters include the service attributes, the service statuses, and the operation instructions; display the service instances corresponding to each service respectively in the parent view.

[0008] Optionally, the device is further configured to perform at least one of the following: the service attributes of the service include service type, product type, and deployment unit; the running status of the service includes a running channel and a running status; the operation instructions of the service include a start instruction, a stop instruction, an isolation instruction, a backup instruction, and an upgrade instruction.

[0009] Optionally, the running status of the service implemented by the device includes a running channel and a running status, including: determining a sampling period according to the service priorities of each service respectively; performing a status acquisition operation on the service instances corresponding to each service respectively according to the sampling period to determine the running status of the service instances corresponding to each service respectively.

[0010] Optionally, the device is configured to publish the configuration files corresponding to each service in a service set in the following manner: publish each service and the configuration files corresponding to each service respectively to generate service identifiers corresponding to each service respectively, where the service identifiers are used to distinguish different services; generate service instances corresponding to each service respectively based on the service identifiers and the configuration files.

[0011] Optionally, the apparatus is further configured to: when the operating states of the first service and the second service are the same, the operation instructions of the first service and the operation instructions of the second service are the same, and the service attributes of the first service and the service attributes of the second service are the same, merge the second service and the first service to obtain a third service, where the service instances corresponding to the third service include the service instances corresponding to the first service and the service instances corresponding to the second service, and the same service attributes include the same names of the service attributes and the same corresponding attribute values.

[0012] Optionally, the apparatus is further configured to: set the drill-down condition according to the target service attribute and the target service state, where the drill-down condition is used to determine, from the service instances in the parent view, the service instances whose service attributes are the target service attribute and whose service states are the target service state; generate a child view when the service instances in the parent view meet the drill-down condition; in response to a target operation instruction, perform the target operation on a first service instance and a second service instance in the child view, and respectively obtain a first service attribute value corresponding to the service attribute of the first service instance, a first state value corresponding to the service state, a second service attribute value corresponding to the service attribute of the second service instance, and a second state value corresponding to the service state, where the service types of the first service instance and the second service instance are different, and the operation instructions of the first service instance and the second service instance both include the target operation instruction; update a first service parameter of the first service instance based on the first service attribute value and the first state value, and update a second service parameter of the second service instance based on the second service attribute value and the second state value.

[0013] According to another aspect of the embodiments of the present application, there is also provided a computer-readable storage medium, in which a computer program is stored, where the computer program is configured to execute the above-mentioned service parameter update method when running.

[0014] According to another aspect of the embodiments of the present application, there is provided a computer program product or a computer program, the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the service parameter update method as described above.

[0015] According to another aspect of the embodiments of the present application, an electronic device is further provided, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to execute the above-mentioned service parameter update method through the computer program.

[0016] In the embodiments of the present application, by setting and applying drill-down conditions in the parent view to generate a sub-view, the effective management and operation of multiple types of service instances on the cloud platform are realized, and the problem of low service parameter update efficiency is solved. Among them, the parent view comprehensively displays all different types of service instances under the same platform, while the sub-view is accurately filtered according to the drill-down conditions defined by the user (related to the service parameters of the service instance), and only contains service instances that meet specific conditions.

[0017] Through the above method, not only a sub-view focused on user needs is quickly generated, but also one-key batch operation is realized, avoiding cumbersome manual configuration and process orchestration, achieving the purpose of efficient management and quick response. This method realizes the consistent and convenient operation of multiple types of service instances on the cloud platform, thereby solving the technical problem of too low service parameter update efficiency and greatly improving the operation and maintenance efficiency and the flexibility of cloud resource management. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application, and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application, and do not constitute an improper limitation of the present application. In the drawings:

[0019] Figure 1 is a schematic diagram of an application environment of an optional service parameter update method according to an embodiment of the present application;

[0020] Figure 2 is a schematic flowchart of an optional service parameter update method according to an embodiment of the present application;

[0021] Figure 3 is a schematic diagram of an optional service parameter update method according to an embodiment of the present application;

[0022] Figure 4 is a schematic diagram of another optional service parameter update method according to an embodiment of the present application;

[0023] Figure 5 is a schematic diagram of another optional service parameter update method according to an embodiment of the present application;

[0024] Figure 6 is a schematic diagram of another optional service parameter update method according to an embodiment of the present application;

[0025] Figure 7 It is a schematic diagram of another optional method for updating service parameters according to an embodiment of the present application;

[0026] Figure 8 It is a schematic diagram of another optional method for updating service parameters according to an embodiment of the present application;

[0027] Figure 9 It is a schematic diagram of another optional method for updating service parameters according to an embodiment of the present application;

[0028] Figure 10 It is a schematic diagram of another optional method for updating service parameters according to an embodiment of the present application;

[0029] Figure 11 It is a schematic diagram of another optional method for updating service parameters according to an embodiment of the present application;

[0030] Figure 12 It is a schematic diagram of another optional method for updating service parameters according to an embodiment of the present application;

[0031] Figure 13 It is a schematic diagram of the structure of an optional service parameter update device according to an embodiment of the present application;

[0032] Figure 14 It is a schematic diagram of the structure of an optional service parameter update product according to an embodiment of the present application;

[0033] Figure 15 It is a schematic diagram of the structure of an optional electronic device according to an embodiment of the present application. Detailed implementation manners

[0034] In order to enable those skilled in the art to better understand the solution of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0035] It should be noted that the terms "first", "second", etc. in the description, claims and above-mentioned drawings of this application are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of this application described here can be implemented in an order other than those illustrated or described here. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0036] First, the professional data that appears in the embodiments of this application is explained as follows:

[0037] SaaS: Software as a Service, software as a service;

[0038] PaaS: Platform as a Service, platform as a service;

[0039] IaaS: Infrastructure as a Service, infrastructure as a service;

[0040] Service: An operation and maintenance object with a set of attributes and operation sets, and its instances can present different states after deployment. Services can have different granularities, and all operation and maintenance objects can be regarded as services, such as physical machines, virtual machines, databases, applications of a certain system, or even a transaction, as long as it has the three characteristics of components.

[0041] The following describes this application in conjunction with embodiments:

[0042] According to one aspect of the embodiments of this application, a method for updating service parameters is provided. Optionally, in this embodiment, the above method for updating service parameters can be applied to, for example, Figure 1 the hardware environment composed of the server 101 and the terminal device 103 as shown. As Figure 1As shown in the figure, the server 101 is connected to the terminal device 103 through a network and can be used to provide services for the terminal device or the application 107 installed on the terminal device. The application can be a video application, an instant messaging application, a browser application, an educational application, a game application, etc. A database 105 can be set up on the server or independently of the server to provide data storage services for the server 101. For example, a game data storage server. The above network can include, but is not limited to: a wired network, a wireless network. Among them, the wired network includes: a local area network, a metropolitan area network, and a wide area network. The wireless network includes: Bluetooth, WIFI, and other networks that implement wireless communication. The terminal device 103 can be a terminal configured with an application and can include, but is not limited to, at least one of the following: a mobile phone (such as an Android mobile phone, an iOS mobile phone, etc.), a laptop computer, a tablet computer, a personal digital assistant, a MID (Mobile Internet Devices), a PAD, a desktop computer, a smart TV, a smart voice interaction device, a smart home appliance, a vehicle-mounted terminal, an aircraft, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a mixed reality (MR) terminal, and other computer devices. The above server can be a single server, a server cluster composed of multiple servers, or a cloud server.

[0043] Combined with Figure 1 As shown in the figure, the above method for updating service parameters can be executed by an electronic device, which can be a terminal device or a server. The above method for updating service parameters can be implemented separately by the terminal device or the server, or jointly implemented by the terminal device and the server.

[0044] The above is only an example, and this embodiment does not make specific limitations.

[0045] Optionally, as an alternative implementation, as Figure 2 shown in the figure, the above method for updating service parameters includes:

[0046] S202, when the service instance in the parent view meets the drill-down condition, generate a sub-view. Among them, the parent view is used to display service instances of different corresponding service types deployed on the same cloud platform, and the sub-view is used to display service instances that meet the drill-down condition. The drill-down condition is related to the service parameters of the service instance in the parent view;

[0047] Optionally, in the embodiments of the present application, in the operation and maintenance management of the cloud platform, the parent view provides a global view of all service instances deployed on the cloud platform, without distinguishing service types, and integrates various services such as SaaS, PaaS, and IaaS in the same view for display. This view aims to provide an overall overview of the service instance status for operation and maintenance personnel, including but not limited to key information such as service type, product type, application ID, deployment unit, running channel, and service running status.

[0048] Furthermore, when operation and maintenance personnel need to perform management operations on service instances of a specific type or status, they can generate a sub-view by defining drill-down conditions. The above drill-down conditions are logical expressions based on service parameters, which can include attributes of the service (such as service type, product type, etc.) and the status of the service (such as running, stopped, unhealthy, etc.). By applying the drill-down conditions, the service instances in the parent view are filtered, and only those service instances whose service parameters meet the drill-down conditions will be included in the sub-view.

[0049] For example, operation and maintenance personnel may be interested in all service instances in the running state, regardless of their service types. Or, they may only want to view and manage service instances belonging to a specific product type (such as Web applications) and deployed in a specific unit (such as RCCOL). In this case, the drill-down conditions can be set to "service running status = running" or "product type = Web application AND deployment unit = RCCOL". Service instances that meet these conditions will be aggregated in the sub-view for more detailed management and operation.

[0050] Furthermore, the following operations in S204 can be performed on the generated sub-view.

[0051] S204, perform target operations on the service instances in the sub-view and update the target service parameters, where the target operation is an operation in the intersection operation set corresponding to the sub-view, and the intersection operation set is determined by the operation sets corresponding to the service instances in the sub-view, and the target service parameters correspond to the service instances in the sub-view.

[0052] Specifically, the service instances in the sub-view may come from different product types (such as applications, databases, middleware, etc.) and different service types (such as SaaS, PaaS, IaaS, etc.), and each service instance has its specific operation set, such as start, stop, restart, backup, monitoring, etc.

[0053] The above-mentioned target operations are one or more operations found from the operation sets of all service instances that can be jointly executed by all service instances, that is, these operations constitute an intersection operation set. For example, if the sub-view contains SaaS applications and IaaS virtual machines, where the operation set of the SaaS application is {start, stop, restart}, and the operation set of the IaaS virtual machine is {start, stop, restart, create snapshot}, then the intersection operation set is {start, stop, restart}. From these intersections, the user can select a target operation, such as "start", and execute it on all service instances in the sub-view.

[0054] Next, after the target operation is executed, the target service parameters can be directly updated. These service parameters may include information such as the running status of the service, resource consumption, and health status. Taking the start operation as an example, after the service instance that was originally in the stopped state executes the start operation, its running status will be updated to running. At the same time, other parameters related to the start operation may also be updated, such as the CPU usage rate, memory occupancy, and network traffic of the service instance.

[0055] That is to say, the sub-view not only provides an easier-to-manage perspective but also allows for more focused batch operations, such as one-key start, one-key stop, or one-key execution of backups, etc. These operations are determined based on the intersection of the operation sets of the service instances in the sub-view. In this way, even in the case of a mixed service type, unified operations can be efficiently executed without the need to separately orchestrate processes for each service type, thereby significantly improving the update efficiency of service parameters and enhancing the operation and maintenance flexibility and response speed of the cloud platform.

[0056] It can be understood that the product types of the service instances in the sub-view can include multiple types, such as applications, databases, etc., and the service types can also be different, for example, SaaS or PaaS or IaaS, etc.

[0057] Moreover, the operations in the operation sets corresponding to different services can be the same or different, and the same operations can also correspond to the same or different operation instructions. For example:

[0058] For the operation of "starting a service": For a SaaS-type service instance, starting the service may mean loading the application into memory and starting to listen for user requests. In the Apache Web server, this may be achieved by executing the apachectl start command; for an IaaS-type service instance, starting the service may represent starting an operating system instance at the hardware abstraction layer. This may be completed by making an API call through the cloud management console and executing an operation instruction similar to startInstance; for example, for a PaaS-type service instance, starting may involve a more complex initialization process, such as preloading data tables or indexes. In the Oracle database, the startup operation may require executing the startup command and may be accompanied by starting the database listener.

[0059] In an exemplary embodiment, in the background visualization operation interface of the cloud platform, a "one-key execution" virtual control can be provided on the interface of the display sub-view for users to interact with. For example, when the user clicks on this control, the services of various different service types in the sub-view can synchronously execute the above-mentioned target operations, including but not limited to starting the service, stopping the service, isolating the service, performing a backup, version upgrade, etc.

[0060] In another exemplary embodiment, in addition to providing the "one-key execution" virtual control of the graphical interface, the cloud platform can also implement the same function in the background operation instruction interface to meet different user preferences and automation requirements.

[0061] Specifically, in the background operation instruction interface, a unified command-line interface (CLI) can be designed to achieve batch operations on all service instances in the sub-view by defining a set of standard command parameters.

[0062] For example, a command similar to cloudctl svc_op -v view_id -op operation_name can be defined, where cloudctl is the CLI command of the cloud management platform, svc_op represents performing an operation on the service instance, the -v parameter specifies the ID of the target sub-view, and the -op parameter specifies the name of the target operation to be executed, such as starting the service, stopping the service, etc. When the user enters this command in the CLI, the cloud management platform will parse the command parameters, identify the intersection operation set of all service instances in the sub-view view_id, and execute the specified target operation operation_name.

[0063] To further improve the operation flexibility, the CLI can support richer parameter options, allowing users to specify additional operation instructions, parameter values, operation sequences, and execution policies when performing operations. For example, users can specify whether to execute operations in parallel, whether to perform a health check before the operation, and the rollback policy in case of operation failure. This design enables the background operation instruction interface to not only provide the convenience of one-click operations but also meet the needs of advanced users with more complex requirements for the operation process.

[0064] In addition, CLI commands can be integrated with automation scripts or programming languages, enabling users to automate the execution of the above operations by writing scripts or code. For example, a Python script can be designed to regularly check the status of all service instances on the cloud platform. When it is found that there are service instances that are not running or running abnormally, it automatically uses CLI commands to generate corresponding sub-views and perform operations such as one-click startup or isolation of services, thus realizing the dynamic monitoring and automatic operation and maintenance of cloud platform resources.

[0065] By providing a background operation instruction interface, the cloud platform not only enhances the operation flexibility of service instances in the sub-view but also supports the operation and maintenance requirements of automation and scripting, improving the efficiency and intelligence level of cloud resource management. Whether through the "one-click execution" control in the graphical interface or through the CLI command line, users can conveniently and quickly perform unified operations on service instances on the cloud platform, effectively solving the problem of low efficiency in updating service parameters and enhancing the operation and maintenance flexibility and response speed of the cloud platform.

[0066] In the embodiment of the present application, by setting and applying drill-down conditions in the parent view to generate sub-views, the effective management and operation of multiple types of service instances on the cloud platform are realized, and the problem of low efficiency in updating service parameters is solved. Among them, the parent view comprehensively displays all different types of service instances under the same platform, while the sub-view is accurately filtered according to the user-defined drill-down conditions (related to the service parameters of the service instances) and only contains service instances that meet specific conditions.

[0067] Through the above method, not only are sub-views focused on user needs quickly generated, but also one-click batch operations are realized, avoiding cumbersome manual configuration and process orchestration, achieving the purpose of efficient management and quick response. This method realizes the consistent and convenient operation of multiple types of service instances on the cloud platform, thereby solving the technical problem of too low update efficiency of service parameters and greatly improving the operation and maintenance efficiency and the flexibility of cloud resource management.

[0068] As an alternative solution, before generating the sub-view when the service instances in the parent view meet the drill-down conditions, the above method further includes: publishing the configuration files corresponding to each service in the service collection, where the configuration files are used to indicate the service parameters; generating the service instances corresponding to each service based on the configuration files, where the service instances inherit at least one of the service attributes, service status, and operation instructions of the corresponding service, and the service parameters include the service attributes, the service status, and the operation instructions; and displaying the service instances corresponding to each service in the parent view.

[0069] Optionally, in the embodiments of the present application, publishing the configuration files corresponding to each service in the service collection means that in the service deployment stage, a configuration file is defined and published for each type of service, and this configuration file details the attribute set, status set, operation set of the service, and the execution instructions corresponding to each operation. It includes but is not limited to the definition of key parameters such as service type, product type, application ID, deployment unit, running channel, service running status, etc., and the corresponding operation instructions such as start, stop, isolation, backup, upgrade, etc.

[0070] It should be noted that the format of the configuration file can be diverse. For example, common data exchange formats such as JSON, XML, or YAML can be used to adapt to different service types and cloud platform requirements. The information in the configuration file is not limited to the service parameters mentioned above, and can also include additional configuration information such as the network settings, storage requirements, and security policies of the service. The present application does not make specific limitations on this, and supports flexible customization of the content of the configuration file according to actual needs.

[0071] Exemplarily, the generation and publishing of the configuration file provide standardized guidance for the creation and management of service instances, ensuring that the service instances can correctly inherit the attributes, status, and operation instructions of the corresponding service. In the service instance creation stage, the cloud platform will automatically generate and deploy service instances based on the configuration file, mapping the attribute set, status set, and operation instructions of the service to specific instances, facilitating subsequent management and operation.

[0072] In an exemplary embodiment, taking the cloud platform to deploy a new SaaS service as an example, first, the service provider needs to define and publish the configuration file of the service, which contains key information such as service type, product type, operation instructions, etc. Subsequently, the cloud platform generates service instances based on the configuration file, inheriting the attributes and service operation instructions defined in the configuration file. Finally, these service instances are centrally displayed in the parent view, and users can generate sub-views through drill-down according to needs and perform unified operations on the service instances in the sub-views.

[0073] Through the embodiments of the present application, by adopting the strategy of defining and publishing configuration files at the initial stage of service deployment, the automation and standardization of the service instance creation process are realized, ensuring that service instances can accurately inherit the attributes, status, and operation instructions of the service. In addition, the centralized display of service instances generated based on the configuration file in the parent view, and the generation of sub-views through drill-down conditions, achieve the rapid screening and one-key operation of mixed service types, aiming to improve the efficiency of service parameter updates and enhance the flexibility and response speed of cloud platform operation and maintenance.

[0074] As an alternative solution, the above method further includes at least one of the following: the service attributes of the above service include service type, product type, and deployment unit; the running status of the above service includes running channel and running status; the operation instructions of the above service include start instruction, stop instruction, isolation instruction, backup instruction, and upgrade instruction.

[0075] As an alternative solution, the running status of the above service includes running channel and running status, including: determining the sampling period according to the service priority of each service; performing a status acquisition operation on the service instances corresponding to each service according to the sampling period to determine the running status of the service instances corresponding to each service.

[0076] Optionally, in the embodiments of the present application, the running status of the service refers to the status information composed of two parts: running channel and running status, including but not limited to the current running path (i.e., running channel) of the service instance and the status such as the health, activity, or stop of the instance. The service priority is preset according to factors such as service type, business importance, and resource requirements, and is used to guide the determination of the sampling period.

[0077] It should be noted that the determination of the sampling period can be dynamically adjusted according to the level of service priority. For example, for services with high priority, the sampling period can be set shorter to obtain their running status more frequently and ensure real-time monitoring of high-priority services. For services with low priority, the sampling period can be set longer to reduce the frequency of status acquisition operations and optimize the resource usage of the cloud platform. The present application does not limit this, and the setting of the sampling period should be based on the characteristics of specific services and the resource management strategy of the cloud platform.

[0078] Exemplarily, in this embodiment, the cloud platform determines the sampling period according to the service priority of each service, that is, the higher the service priority, the shorter the sampling period; the lower the service priority, the longer the sampling period. Then, the cloud platform periodically performs a status acquisition operation according to the set sampling period, and collects the running channel and running status of each service instance in real time for each service instance, so as to timely understand and monitor the running situation of the service instance.

[0079] In an exemplary embodiment, take the cloud platform operation and maintenance of a large-scale financial application system as an example, which includes services of different priorities, such as core transaction processing services (high priority), log audit services (medium priority) and report generation services (low priority). The cloud platform first determines the respective sampling periods according to the service priorities. For example, the sampling period of the core transaction processing service is 1 minute, the sampling period of the log audit service is 5 minutes, and the sampling period of the report generation service is 10 minutes. Subsequently, the cloud platform obtains the status of the service instances according to these sampling periods, monitors the operation of the core transaction processing service in real time, and regularly checks the status of the log audit service and the report generation service to ensure the stable operation and resource efficiency of the entire financial application system.

[0080] Through the embodiments of the present application, a method of dynamically adjusting the sampling period based on service priority is adopted to achieve efficient monitoring and management of the operating status of service instances, thereby achieving the purpose of real-time control of important service status, optimizing resource allocation and improving the overall cloud platform operation and maintenance efficiency.

[0081] As an optional solution, the configuration files corresponding to each service in the above-mentioned service set are published, including: publishing each of the above-mentioned services and the above-mentioned configuration files corresponding to each of the above-mentioned services, generating a service identifier corresponding to each of the above-mentioned services, wherein the above-mentioned service identifier is used to distinguish different services; and generating a service instance corresponding to each of the above-mentioned services based on the above-mentioned service identifier and the above-mentioned configuration files.

[0082] Optionally, in an embodiment of the present application, publishing the configuration files corresponding to each service in the service set refers to publishing the configuration files describing the attributes, status, operation instructions and their associations of each service to the cloud platform before the service is deployed, including but not limited to files in JSON, XML or YAML format. A service identifier is an attribute or identifier used to uniquely identify and distinguish different services in a cloud management platform, such as a service ID or service name.

[0083] It should be noted that the service identifier can be automatically generated based on the information in the configuration file, or it can be manually defined by the service provider, as long as the uniqueness of the service identifier can be ensured. The configuration file can be published with the help of the cloud platform's file management system or through an API interface. This application does not make specific restrictions on this and supports a variety of file publishing methods to meet the needs of different cloud environments and application scenarios.

[0084] Exemplarily, the configuration file of the service contains all necessary information, such as the attributes of the service (service type, product type, etc.), status (running status, running channel, etc.), and operation instructions (start, stop, backup, etc.). When the service provider publishes the configuration file to the cloud platform, the cloud platform generates a corresponding service identifier based on the configuration file and automatically or manually creates a service instance corresponding thereto, ensuring that the service instance can inherit the service attributes, status set, and operation instructions defined in the configuration file.

[0085] In an exemplary embodiment, taking the application scenario of deploying a new database service in a financial cloud environment as an example, the service provider first defines the configuration file of the database service, which includes the service type, product type, operation instructions (such as start, stop, create snapshot, etc.), and their associated parameters. Subsequently, the service provider publishes the configuration file to the financial cloud platform, and the cloud platform generates a unique service identifier according to the configuration file information, such as the database service ID, and creates a series of database service instances based on the service ID and the content of the configuration file. These instances inherit the service attributes, status, and operation instructions defined in the configuration file when created, thereby ensuring the uniqueness and manageability of each database service instance in the cloud platform.

[0086] Through the embodiments of the present application, by adopting the method of publishing the configuration file and generating the service identifier before service deployment, it is realized that the service instance has complete service attribute, status, and operation instruction information at the time of creation, achieving the purpose of standardized creation and unified management of service instances, and at the same time improving the configuration efficiency of cloud platform resources and the operation and maintenance flexibility.

[0087] As an alternative solution, the above method further includes: when the running status of the first service is the same as the running status of the second service, the operation instructions of the first service are the same as the operation instructions of the second service, and the service attributes of the first service are the same as the service attributes of the second service, merging the second service and the first service to obtain a third service, where the service instance corresponding to the third service includes the service instance corresponding to the first service and the service instance corresponding to the second service, and the same service attributes include the same name of the service attributes and the corresponding attribute values are the same.

[0088] Optionally, in the embodiments of the present application, the first service and the second service refer to two independent services managed in the cloud platform, including but not limited to service instances at the SaaS, PaaS, and IaaS layers. The running state includes the running channels and running state information of the service instances. The operation instruction refers to a control instruction associated with the service instance, such as start, stop, isolation, etc. The service attribute refers to a field describing the service characteristics, including service type, product type, application ID, deployment unit, etc. The third service refers to a new service generated by merging the first service and the second service, and its service instance set contains the service instance sets of the first service and the second service.

[0089] It should be noted that the condition for merging services is that the running states, operation instructions, and service attributes of the two services are exactly the same. In practical applications, the comparison of service attributes is not limited to the direct matching of field names and values, but can also be judged through the logical relationship of the attributes.

[0090] For example, two services may have exactly the same set of attributes and operations, but due to being deployed on different hosts, the values of the "deployment unit" field in their service attributes may be different, but this does not affect their merging at a higher level. The present application does not make any limitations in this regard, and the merging conditions can be flexibly adjusted according to specific requirements.

[0091] Exemplarily, when the cloud platform detects that the running states, operation instructions, and service attributes of the first service and the second service are all exactly the same, the cloud platform will automatically merge the second service and the first service to generate the third service. This means that the third service will contain the entire set of service instances of the first service and the service instances of the second service. From the perspective of management and operation, the third service has the same service attributes, status, and operation instructions as the first service and the second service, but has a wider management scope, including all associated service instances.

[0092] In an exemplary embodiment, taking two Oracle database services deployed in a financial industry cloud platform as an example, these two services are respectively deployed on different physical machines, but their service types, product types, running states, operation instructions, and all other service attributes such as application IDs, deployment units, etc. are exactly the same. When the cloud platform manages and monitors service instances, it detects that the running states and operation instructions of these two service instances are consistent, that is, they are running on the same channel and are both in the "running" state, and support the same operations such as "start service", "stop service", and "perform backup". Based on this information, the cloud platform merges these two Oracle database service instances to generate a third service instance for overview, which contains the set of all Oracle database service instances on two physical machines, thus providing a unified service instance operation entry for users on the centralized operation interface, simplifying the operation process, and improving the operation and maintenance efficiency.

[0093] Through the embodiment of the present application, by adopting the service instance merging mechanism, the technical effect of merging service instances under the condition that service attributes, running states, and operation instructions are the same is achieved, and the purpose of simplifying the management of service instances on the cloud platform, optimizing resource utilization, and enhancing the convenience of operation and maintenance operations is achieved. This mechanism is particularly applicable to scenarios where there are multiple service instances with the same configuration in a large system. Through merging, the management complexity of service instances can be significantly reduced, making the operation and maintenance operations of the cloud platform more concise and efficient.

[0094] As an alternative solution, the above method further includes: setting the above drill-down conditions according to the target service attributes and target service states, where the above drill-down conditions are used to determine, from the service instances in the above parent view, the service instances whose service attributes are the above target service attributes and whose service states are the above target service states; generating a sub-view when the service instances in the above parent view meet the above drill-down conditions; in response to a target operation instruction, performing the above target operation on the first service instance and the second service instance in the above sub-view, respectively obtaining the first service attribute value corresponding to the service attribute of the above first service instance, and the first state value corresponding to the service state, and the second service attribute value corresponding to the service attribute of the above second service instance, and the second state value corresponding to the service state, where the service type of the above first service instance is different from the service type of the above second service instance, and the operation instructions of the above first service instance and the operation instructions of the above second service instance both include the above target operation instruction; updating the first service parameters of the above first service instance based on the above first service attribute value and the above first state value, and updating the second service parameters of the above second service instance based on the above second service attribute value and the above second state value.

[0095] Optionally, in the embodiments of the present application, the target service attribute refers to a specific service attribute that a user hopes to filter and display in a sub-view, including but not limited to service type, product type, application ID, deployment unit, etc. The target service status refers to a specific service running status set by the user, such as service running status, running channel status, etc. The drill-down condition is a logical rule formulated based on the target service attribute and the target service status, and is used to filter out service instances that meet specific attributes and service statuses from the parent view to generate a sub-view. The target operation instruction refers to a unified operation that a user hopes to perform on a service instance in the sub-view, such as start, stop, isolate, etc.

[0096] It should be noted that the target service attribute and the target service status can be used alone or in combination to achieve precise filtering of service instances. For example, a user can filter only based on the service type, or set more complex combination conditions, such as the combination of service type + SaaS, product type + Oracle, deployment unit + RCCOL, to generate a more specific sub-view. The present application does not make any limitations in this regard and supports users to flexibly set drill-down conditions according to actual needs.

[0097] Exemplarily, in this embodiment, the cloud platform allows a user to set drill-down conditions to filter out service instances that meet specific service attributes and service statuses from the parent view to generate a new sub-view. After the user specifies the target operation instruction, the cloud platform can perform the target operation on the first service instance and the second service instance (with different service types but supporting the same target operation instruction) in the sub-view. At the same time, the cloud platform will update the respective service parameters according to the service attributes and status values of the first service instance and the second service instance to ensure that the status information of the service instance after the operation is consistent with the actual status.

[0098] In an exemplary embodiment, taking the cloud platform to manage service instances of a financial application system as an example, assume that a user hopes to perform a stop operation on all SaaS services running in the RCCOL deployment unit. The user first sets the drill-down conditions on the interaction interface: service type + SaaS, deployment unit + RCCOL. The cloud platform filters out the service instances that meet the conditions from the parent view according to these conditions to generate a sub-view, which contains all SaaS service instances on the RCCOL deployment unit. Next, the user selects the target operation instruction to stop the service in this sub-view, and the cloud platform will perform the stop operation on all SaaS service instances and obtain the status values (such as service running status) and service attribute values (such as product type, application ID) of each service instance. After the operation is completed, the cloud platform updates the status information of the service instance, such as changing the service running status to "stopped", and synchronizes this information to the cloud management platform to maintain data consistency and accuracy.

[0099] Through the embodiments of the present application, by setting drilling conditions, the technical effect of accurately screening target service instances from the parent view and generating a sub-view is achieved. Further, by responding to the target operation instruction, unified operations are performed on service instances of different service types in the sub-view, and service parameters are updated simultaneously, achieving the purpose of improving the flexibility and efficiency of cloud platform service management and ensuring the real-time accuracy of service status information. This mechanism is particularly applicable to the management of hybrid services in a large-scale cloud environment, which can significantly reduce the complexity of operations and improve the convenience and intelligence level of service management.

[0100] In an exemplary embodiment, existing cloud products basically fail to achieve one-click convenient operations on hybrid services. For example, to start all services of a certain application system with one click (including different applications deployed on different deployment units of the system, such as apache, weblogic server, weblogic admin server, weblogic nodemanager, haproxy, monitoring agents on each host, job scheduling agents, etc.). Usually, existing cloud products implement similar functions through orchestration (grouping all services by type, with each group containing a set of the same services, and then starting all services in each group serially or in parallel through orchestration), which requires pre-defining corresponding processes, wasting a certain amount of manpower. At the same time, one process needs to be orchestrated for each requirement, resulting in a large number of pre-orchestrated processes for different requirements, which are not easy to identify, and it is impossible to quickly find a suitable process when performing emergency operations, reducing the emergency response efficiency.

[0101] Based on this, in order to solve the technical problems that cloud resource management and operation methods usually need to implement hybrid service operations through orchestration, which is time-consuming and lacks convenience, according to the above method, taking banking services as an example, it is assumed that the services mainly include services at the SaaS and PaaS layers of cloud computing.

[0102] Services can be represented by "SR numbers". For example, SR1, SR2... SRn respectively identify n services. Each service corresponds to three different types of sets used to describe the above service parameters:

[0103] SR = {P, S, A}: P (attribute set) (corresponding to the above service attributes), ST (status set) (corresponding to the above service status), and A (operation set).

[0104] Next, use SR1.P, SR1.ST, and SR1.A to identify the property set, state set, and operation set of service SR1. The subscript notation [] is used to identify the elements in the set. For example, SR1.P[1], SR1.P[2], …… SR1.P[n] are used to identify the 1st, 2nd, …… nth properties in the property set of service SR1. Each service is set with an SRId property, and SRId ∈ P. In this embodiment, the value of the SRId property is used to uniquely identify a service.

[0105] It should also be noted that after the service is deployed on cloud computing resources (physical machines, virtual machines), it can run as a software instance. After a service is deployed on cloud computing resources and meets the running conditions, each deployment is called an instance of this service (abbreviated as service instance). After a service is deployed, a set of service instance collections is obtained, which is identified by the corresponding lowercase letter of the service. For example, the service instance set corresponding to service SR1 is sr1, and sr1 = {sr1[1], sr1[2], …… sr1[n]}. Before the service is deployed, the value of each property in its property set is defined. For example:

[0106] Use VAL(F) to identify the value of a certain field. For example, VAL(SR1.P[1]) identifies the value of property SR1.P[1]. The sufficient and necessary condition for two services to be the same service is that their property sets are the same, their state sets are the same, the value of each property is the same, and their operation sets are the same. That is, (SR1 = SR2) is equivalent to (SR1.P = SR2.P AND SR1.ST = SR2.ST AND SR1.A = SR2.A AND (VAL(SR1.P[1]) = VAL(SR2.P[1]) AND VAL(SR1.P[2]) = VAL(SR2.P[2]) AND …… AND VAL(SR1.P[n]) = VAL(SR2.P[n]))).

[0107] Furthermore, the service instance inherits the property set, state set, operation set, and the value of each property of the service. However, the value of each state in the service instance state set is dynamically generated after deployment. Each service needs to provide a STATE() call to return the current state value of its service instance (STATE(sr1) = {sr1.ST[1] = c1, sr1.ST[2] = c2, …… sr1.ST[n] = cn}, where c1, c2, cn are constants).

[0108] Exemplarily, the above drill-down conditions can be understood as: a logical expression composed of the attributes and status of the service (using CD for identification, and CD1, CD2, …… CDn for identifying different filtering conditions), similar to the query conditions in SQL statements, such as service type = SaaS AND product type = application AND deployment unit = RCCOL AND running channel = 1 AND service running status = stop. Among them, service type, product type, and deployment unit are all attributes of the service, SaaS, application, and RCCOL are the values of the attributes respectively, running channel and service running status are the statuses of the service, and 1 and stop are the values of the corresponding attributes of the service instance.

[0109] A mixed set of different types of service instances is called a view, and different views can be identified using VW1, VW2, …… VWn, and the total set composed of all service instances managed by the cloud is identified using VW0, also known as view 0 (the above parent view). The drill-down conditions can be used to filter VW0, and the service instances in VW0 that meet the logical expression defined by the filtering conditions are filtered out to form a new view (the above sub-view). The set of services corresponding to each service instance in a view VW1 is called the service set of the view, identified by VW1.SR. Assuming VW1.SR = {SR1, SR2, …… SRn}, the intersection of the operation sets of these services is called the operation set of the view, identified by VW1.A, and VW1.A = {SR1.A ∩ SR2.A ∩ …… SRn.A, SRn ∈ VW1.SR}.

[0110] Specifically, on the basis of existing cloud management products, extended functions can be added to provide a convenient interface (interactive interface or API interface) to quickly generate filtering conditions, use the filtering conditions to filter VW0, quickly generate the operation view VW1 expected by the user, and use the cloud management product set to perform one-key operations on the service instances in VW1 (the supported operation set is VW1.A, which is the intersection of the operation sets of all services included in the view), and finally realize convenient one-key operations on the mixed service instance set.

[0111] In an exemplary embodiment, each service is self-described by a configuration file (which can be in xml or json format). The configuration file defines the set of attributes, set of states, set of operations of the service, the values of each attribute in the set of attributes, the execution script corresponding to the STATE() call of the service, the execution script corresponding to each operation in the set of operations, etc. The configuration file is published and deployed together with the service. When the service is deployed, the value of the unique identifier SRId of the service is automatically generated. After the service is deployed, the cloud management platform reads the configuration file to parse the service instance, and generates the set of attributes, the value of each attribute, the set of states, and the set of operations of each service instance. At this time, the service instance is officially managed by the cloud. The cloud management platform executes the STATE() call for each managed service instance at a fixed sampling period (such as every minute) to generate the value of each state of the service instance. This information is centrally stored by the cloud management platform.

[0112] Due to different responsibilities of different users and roles, the services they are responsible for maintaining are also different. Therefore, the concept of a predefined view (the above-mentioned parent view) is introduced: A predefined view refers to a subset of VW0 obtained by filtering VW0 in advance using predefined filtering conditions, and it is also a view. After the predefined view is defined in the cloud management platform, an entry can be provided for direct reference. The view can be displayed using a tree structure. The root node corresponds to the filtering conditions of the view (the drill-down condition corresponding to VW0 is {*}), and the leaf nodes are service instances ( Figure 3 is a schematic diagram of an optional method for updating service parameters according to an embodiment of the present application. As Figure 3 shown, where service type, product type, application ID, and deployment unit are attributes of the service, and running channel and service running status are the states of the service instance). The branch nodes of the tree support two options: drill-down and execution operations. When drilling down on a branch node of the tree by a certain attribute or state, the drilled branch node is grouped according to the value of the drilled attribute or state and split into a new set of branch nodes.

[0113] Figure 4 is a schematic diagram of an optional method for updating service parameters according to an embodiment of the present application. Figure 5 is a schematic diagram of an optional method for updating service parameters according to an embodiment of the present application. The above-mentioned parent view is as Figure 4 shown, which is an example of an operation menu corresponding to the branch node of the tree. The first column is the first-level menu, and the second column is the second-level menu. After selecting to drill down by product type, a new tree view (the above-mentioned sub-view) is generated as Figure 5 shown.

[0114] Further, when an operation needs to be performed on a service instance, the user can open a predefined view, drill down through the view to obtain a desired operation view, or directly manually edit the drill-down conditions to generate a desired operation view, and perform an operation on the view corresponding to the tree branch node through the menu on the corresponding tree branch node (the supported operations are the operation set of the view), ultimately achieving convenient and efficient hybrid service operations.

[0115] In an exemplary embodiment, six services are first defined (which can be defined in JSON format):

[0116] Service 1: {P: [SRId, service type, product type, application ID, deployment unit], ST: [running channel, service running status], A: [start service, stop service, isolate service, perform backup, version upgrade], PVal: {SRId: 1, service type: SaaS, product type: application, application ID: RCC, deployment unit: RCCOL], STATE_shell: state.sh, ACT_shell: {start service: start_srv.sh, stop service: stop_srv.sh, isolate service: isol_srv.sh, perform backup: backup_srv.sh, version upgrade: update_srv.sh}};

[0117] Service 2: {P: [SRId, service type, product type, application ID, deployment unit], ST: [running channel, service running status], A: [start service, stop service, isolate service, perform backup, version upgrade], PVal: {SRId: 2, service type: SaaS, product type: application, application ID: RCC, deployment unit: RCCPS], STATE_shell: state.sh, ACT_shell: {start service: start_srv.sh, stop service: stop_srv.sh, isolate service: isol_srv.sh, perform backup: backup_srv.sh, version upgrade: update_srv.sh}};

[0118] Service 3: {P: [SRId, service type, product type, application ID, deployment unit], ST: [running channel, service running status], A: [start service, stop service, isolate service, perform backup, version upgrade], PVal: {SRId: 3, service type: SaaS, product type: application, application ID: ELB, deployment unit: ELBLJ], STATE_shell: state.sh, ACT_shell: {start service: start_srv.sh, stop service: stop_srv.sh, isolate service: isol_srv.sh, perform backup: backup_srv.sh, version upgrade: update_srv.sh}};

[0119] Service 4: {P: [SRId, service type, product type, application ID, deployment unit], ST: [running channel, service running status], A: [start service, stop service, isolate service, perform backup], PVal: {SRId: 4, service type: SaaS, product type: haproxy, application ID: ELB, deployment unit: ELBLJ], STATE_shell: state.sh, ACT_shell: {start service: start_srv.sh, stop service: stop_srv.sh, isolate service: isol_srv.sh, perform backup: backup_srv.sh}};

[0120] Service 5: {P: [SRId, service type, product type, application ID, deployment unit], ST: [service running status], A: [start service, stop service], PVal: {SRId: 5, service type: SaaS, product type: weblogicadmin, application ID: ELB, deployment unit: ELBLJ], STATE_shell: state.sh, ACT_shell: {start service: start_srv.sh, stop service: stop_srv.sh}};

[0121] Service 6: {P: [SRId, service type, product type, application ID, deployment unit], ST: [running channel, service running status], A: [start service, stop service], PVal: {SRId: 6, service type: SaaS, product type: Oracle, application ID: RCC, deployment unit: RCCOL], STATE_shell: state.sh, ACT_shell: {start service: start_srv.sh, stop service: stop_srv.sh}}.

[0122] Figure 6It is a schematic diagram of an optional method for updating service parameters according to an embodiment of the present application. The parent view, that is, the VW0 view, is shown as Figure 6 shown, which is the dimension of the service instance. For example, if the product type of a service is an application and there are two service instances for this application; the same applies to the Oracle product type.

[0123] Figure 7 It is a schematic diagram of an optional method for updating service parameters according to an embodiment of the present application. The operation menu corresponding to the root node is as Figure 7 shown.

[0124] Next, drill down the root node by product type, Figure 8 It is a schematic diagram of an optional method for updating service parameters according to an embodiment of the present application. The displayed sub - view is as Figure 8 shown.

[0125] Figure 9 It is a schematic diagram of an optional method for updating service parameters according to an embodiment of the present application. The operation menu corresponding to the branch node "{Product type = Application}, a total of 6 service instances" is as Figure 9 shown; Figure 10 It is a schematic diagram of an optional method for updating service parameters according to an embodiment of the present application. The operation menu corresponding to the branch node "{Product type = Oracle}, a total of 2 service instances" is as Figure 10 shown.

[0126] Figure 11 It is a schematic diagram of an optional method for updating service parameters according to an embodiment of the present application. Re - open the VW0 view and drill down the root node by service running status, as Figure 11 shown.

[0127] Figure 12 It is a schematic diagram of an optional method for updating service parameters according to an embodiment of the present application. The operation menus corresponding to the branch nodes "{Service running status = start}, a total of 6 service instances", "{Service running status = stop}, a total of 6 service instances", "{Service running status = unhealthy}, a total of 1 service instance" are the same, as Figure 12 shown.

[0128] On the branch node "{Service running status = stop}, a total of 6 service instances", select the menu "Execute operation --> Start service", and all service instances with the current service running status of stop in the VW0 view can be started with one key, that is, all stopped services can be started with one key, simply and conveniently realizing one - key hybrid service operation, which can greatly improve the operation and maintenance and emergency handling efficiency.

[0129] It is understandable that in the specific embodiments of the present application, data related to user information and the like are involved. When the above embodiments of the present application are applied to specific products or technologies, user permission or consent needs to be obtained, and the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of relevant countries and regions.

[0130] It should be noted that for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that the present application is not limited by the described action sequence, because according to the present application, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the present application.

[0131] According to another aspect of the embodiments of the present application, there is also provided a service parameter update device for implementing the above service parameter update method. As Figure 13 shown, the device includes:

[0132] A generation module 1302, configured to generate a sub-view when the service instances in the parent view meet the drill-down condition, where the parent view is used to display service instances of different corresponding service types deployed on the same cloud platform, the sub-view is used to display service instances that meet the drill-down condition, and the drill-down condition is related to the service parameters of the service instances in the parent view;

[0133] An update module 1304, configured to perform a target operation on the service instances in the sub-view and update the target service parameters, where the target operation is an operation in the intersection operation set corresponding to the sub-view, the intersection operation set is determined by the operation sets corresponding to the service instances in the sub-view respectively, and the target service parameters correspond to the service instances in the sub-view.

[0134] As an optional solution, the above device is further configured to: before generating a sub-view when the service instances in the parent view meet the drill-down condition, publish the configuration files corresponding to each service in the service set, where the configuration file is used to indicate the service parameters; generate service instances corresponding to each service based on the configuration file, where the service instance inherits at least one of the service attributes, service status, and operation instructions of the corresponding service, and the service parameters include service attributes, service status, and operation instructions; display the service instances corresponding to each service in the parent view.

[0135] As an optional solution, the above device is further configured to perform at least one of the following: the service attributes of the service include service type, product type, and deployment unit; the running status of the service includes running channel and running status; the operation instructions of the service include start instruction, stop instruction, isolation instruction, backup instruction, and upgrade instruction.

[0136] As an alternative, the operating states of the services implemented by the above device include an operating channel and an operating state, including: determining a sampling period according to the service priority of each service; performing a status acquisition operation on the service instances corresponding to each service according to the sampling period to determine the operating states of the service instances corresponding to each service.

[0137] As an alternative, the above device is used to publish the configuration files corresponding to each service in the service set in the following manner: publishing each service and the configuration file corresponding to each service to generate a service identifier corresponding to each service, where the service identifier is used to distinguish different services; generating service instances corresponding to each service based on the service identifier and the configuration file.

[0138] As an alternative, the above device is further used to: when the operating state of the first service is the same as that of the second service, the operation instruction of the first service is the same as that of the second service, and the service attribute of the first service is the same as that of the second service, merge the second service and the first service to obtain a third service, where the service instances corresponding to the third service include the service instances corresponding to the first service and the service instances corresponding to the second service, and the same service attributes include the same name of the service attributes and the same corresponding attribute values.

[0139] As an alternative, the above device is further used to: set drill-down conditions according to the target service attribute and the target service state, where the drill-down conditions are used to determine, from the service instances in the parent view, the service instances whose service attribute is the target service attribute and whose service state is the target service state; generating a sub-view when the service instances in the parent view meet the drill-down conditions; in response to a target operation instruction, performing the target operation on the first service instance and the second service instance in the sub-view, respectively obtaining the first service attribute value corresponding to the service attribute of the first service instance, the first state value corresponding to the service state, the second service attribute value corresponding to the service attribute of the second service instance, and the second state value corresponding to the service state, where the service types of the first service instance and the second service instance are different, and the operation instructions of the first service instance and the second service instance both include the target operation instruction; updating the first service parameter of the first service instance based on the first service attribute value and the first state value, and updating the second service parameter of the second service instance based on the second service attribute value and the second state value.

[0140] In the embodiments of the present application, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works together with other relevant parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an overall module or unit that includes the function of that module or unit.

[0141] Regarding the device in the above embodiments, the specific manner in which each module performs operations has been described in detail in the embodiments related to the method, and will not be elaborated here.

[0142] According to one aspect of the present application, there is provided a computer program product, which includes a computer program.

[0143] The serial numbers of the embodiments of the present application above are only for description and do not represent the superiority or inferiority of the embodiments.

[0144] Figure 14 A block diagram of a computer system of an electronic device for implementing the embodiments of the present application is schematically shown.

[0145] It should be noted that Figure 14 The computer system 1400 of the electronic device shown is only an example and should not impose any limitations on the functions and usage scope of the embodiments of the present application.

[0146] As Figure 14 shown, the computer system 1400 includes a central processing unit 1401 (Central Processing Unit, CPU), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1402 (Read-Only Memory, ROM) or a program loaded from a storage section 1408 into a random access memory 1403 (Random Access Memory, RAM). In the random access memory 1403, various programs and data required for system operation are also stored. The central processing unit 1401, the read-only memory 1402, and the random access memory 1403 are connected to each other through a bus 1404. An input / output interface 1405 (Input / Output interface, i.e., I / O interface) is also connected to the bus 1404.

[0147] The following components are connected to the input / output interface 1405: an input section 1406 including a keyboard, a mouse, etc.; an output section 1407 including, for example, a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1408 including a hard disk, etc.; and a communication section 1409 including a network interface card such as a local area network card, a modem, etc. The communication section 1409 performs communication processing via a network such as the Internet. The drive 1410 is also connected to the input / output interface 1405 as needed. A removable medium 1411, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1410 as needed so that a computer program read therefrom can be installed into the storage section 1408 as needed.

[0148] Specifically, according to an embodiment of the present application, the processes described in each method flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program codes for executing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from the network through the communication section 1409, and / or installed from the removable medium 1411. When the computer program is executed by the central processing unit 1401, various functions defined in the system of the present application are executed.

[0149] In such an embodiment, the computer program can be downloaded and installed from the network through the communication section 1409, and / or installed from the removable medium 1411. When the computer program is executed by the central processing unit 1401, various functions provided by the embodiments of the present application are executed.

[0150] According to another aspect of the embodiments of the present application, an electronic device for implementing the above-mentioned service parameter update method is further provided. The electronic device may be Figure 1 the terminal device or the server shown. This embodiment takes the electronic device as the terminal device as an example for illustration. As Figure 15 shown, the electronic device includes a memory 1502 and a processor 1504. A computer program is stored in the memory 1502, and the processor 1504 is configured to execute the steps in any of the above method embodiments through the computer program.

[0151] Optionally, in this embodiment, the above-mentioned electronic device may be at least one network device among multiple network devices in a computer network.

[0152] Optionally, in this embodiment, the above-mentioned processor may be configured to execute the methods in the embodiments of the present application through the computer program.

[0153] Optionally, those of ordinary skill in the art can understand that Figure 15 the structure shown is only illustrative Figure 15 and does not limit the structure of the above electronic device. For example, the electronic device may further include more or fewer components (such as a network interface, etc.) than those shown Figure 15 in the figure, or have a different configuration from that Figure 15 shown in the figure.

[0154] Among them, the memory 1502 can be used to store software programs and modules, such as the program instructions / modules corresponding to the service parameter update method and device in the embodiments of the present application. The processor 1504 executes various functional applications and data processing by running the software programs and modules stored in the memory 1502, that is, implements the above service parameter update method. The memory 1502 may include a high-speed random access memory, and may further include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memories. In some instances, the memory 1502 may further include a memory remotely disposed relative to the processor 1504, and these remote memories can be connected to the terminal through a network. Examples of the above network include but are not limited to the Internet, enterprise intranets, local area networks, mobile communication networks, and combinations thereof. Among them, the memory 1502 can specifically but not limitedly be used to store information such as service parameters and configuration files. As an example, as Figure 15 shown in the figure, the above memory 1502 may include but is not limited to the generation module 1302 and the update module 1304 in the above service parameter update device. In addition, it may further include but is not limited to other module units in the above service parameter update device, which will not be elaborated in this example.

[0155] Optionally, the above transmission device 1506 is used to receive or send data via a network. Specific examples of the above network may include wired networks and wireless networks. In one instance, the transmission device 1506 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices and routers through a network cable, thereby enabling communication with the Internet or a local area network. In one instance, the transmission device 1506 is a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0156] In addition, the above electronic device further includes: a display 1508 for displaying the above parent view and child view; and a connection bus 1510 for connecting each module component in the above electronic device.

[0157] In other embodiments, the above-mentioned terminal device or server may be a node in a distributed system. Among them, the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting the multiple nodes in the form of network communication. Among them, the nodes may form a peer-to-peer network, and any form of computing device, such as electronic devices like servers and terminals, can become a node in the blockchain system by joining the peer-to-peer network.

[0158] According to one aspect of the present application, there is provided a computer-readable storage medium. The processor of the electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the service parameter update method provided in various optional implementation manners of the above-mentioned service parameter update.

[0159] Optionally, in this embodiment, the above-mentioned computer-readable storage medium may be set to store the methods for executing the embodiments of the present application.

[0160] Optionally, in this embodiment, those of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the relevant hardware of the terminal device through a program. The program can be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disc, etc.

[0161] The serial numbers of the above embodiments of the present application are only for description and do not represent the superiority or inferiority of the embodiments.

[0162] If the integrated unit in the above embodiments is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in the above-mentioned computer-readable storage medium. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in the storage medium and includes several instructions to enable one or more electronic devices to execute all or part of the steps of the methods described in the various embodiments of the present application.

[0163] In the above embodiments of the present application, the descriptions of the various embodiments have their own emphases. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0164] In several embodiments provided in the present application, it should be understood that the disclosed application program can be implemented in other ways. Among them, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of units or modules can be in an electrical or other form.

[0165] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0166] In addition, each functional unit in various embodiments of the present application can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0167] The above are only the preferred embodiments of the present application. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present application, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present application.

Claims

1. A method for updating service parameters, characterized in that, Including: When a service instance in a parent view meets a drill-down condition, a child view is generated, where the parent view is used to display service instances of different corresponding service types deployed on the same cloud platform, the child view is used to display service instances that meet the drill-down condition, and the drill-down condition is related to service parameters of the service instances in the parent view; Perform a target operation on the service instances in the child view to update target service parameters, where the target operation is an operation in an intersection operation set corresponding to the child view, and the intersection operation set is determined by operation sets corresponding to the service instances in the child view respectively, and the target service parameters correspond to the service instances in the child view.

2. The method according to claim 1, characterized in that, Before generating the child view when the service instance in the parent view meets the drill-down condition, the method further includes: Publish configuration files corresponding to each service in a service set, where the configuration file is used to indicate the service parameters; Generate service instances corresponding to each service based on the configuration file, where the service instance inherits at least one of service attributes, service status, and operation instructions of the corresponding service, and the service parameters include the service attributes, the service status, and the operation instructions; Display service instances corresponding to each service in the parent view.

3. The method according to claim 2, characterized in that, The method further includes at least one of the following: The service attributes of the service include service type, product type, and deployment unit; The running status of the service includes a running channel and a running status; The operation instructions of the service include a start instruction, a stop instruction, an isolation instruction, a backup instruction, and an upgrade instruction.

4. The method according to claim 3, wherein The running status of the service includes a running channel and a running status, including: Determine a sampling period according to the service priorities of each service; Perform a status acquisition operation on the service instances corresponding to each service according to the sampling period to determine the running status of the service instances corresponding to each service.

5. The method according to claim 2, characterized in that, The publishing the configuration files corresponding to each service in the service set includes: Publish each service and the configuration file corresponding to each service to generate a service identifier corresponding to each service, where the service identifier is used to distinguish different services; Generate service instances corresponding to each service based on the service identifier and the configuration file.

6. The method according to claim 2, wherein The method further includes: When the running status of a first service is the same as the running status of a second service, the operation instructions of the first service are the same as the operation instructions of the second service, and the service attributes of the first service are the same as the service attributes of the second service, merge the second service and the first service to obtain a third service, where the service instances corresponding to the third service include the service instances corresponding to the first service and the service instances corresponding to the second service, and the same service attributes include the same name of the service attributes and the same corresponding attribute values.

7. The method according to claim 1, wherein The method further includes: Set the drill-down condition according to the target service attribute and the target service status, where the drill-down condition is used to determine, from the service instances in the parent view, the service instances whose service attribute is the target service attribute and whose service status is the target service status; Generate a child view when the service instances in the parent view meet the drill-down condition; In response to a target operation instruction, perform the target operation on the first service instance and the second service instance in the child view, and respectively obtain the first service attribute value corresponding to the service attribute of the first service instance, the first status value corresponding to the service status, the second service attribute value corresponding to the service attribute of the second service instance, and the second status value corresponding to the service status, where the service types of the first service instance and the second service instance are different, and the operation instructions for the first service instance and the second service instance both include the target operation instruction; Update the first service parameter of the first service instance based on the first service attribute value and the first status value, and update the second service parameter of the second service instance based on the second service attribute value and the second status value.

8. An update device for service parameters, characterized in that, Comprising: A generation module, configured to generate a child view when the service instances in the parent view meet the drill-down condition, where the parent view is used to display service instances with different corresponding service types deployed on the same cloud platform, the child view is used to display the service instances that meet the drill-down condition, and the drill-down condition is related to the service parameters of the service instances in the parent view; An update module, configured to perform a target operation on the service instances in the child view and update the target service parameters, where the target operation is an operation in the intersection operation set corresponding to the child view, the intersection operation set is determined by the operation sets corresponding to the service instances in the child view respectively, and the target service parameters correspond to the service instances in the child view.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, where the computer program, when being run by an electronic device, executes the method described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method described in any one of claims 1 to 7.

11. An electronic device, comprising a memory and a processor, characterized in that, A computer program is stored in the memory, and the processor is configured to execute the method described in any one of claims 1 to 7 through the computer program.

Images