A service-centric enterprise hybrid cloud resource management method and system

Abstract

This invention provides a service-centric enterprise hybrid cloud resource management method and system, relating to the field of cloud computing resource management technology. The method includes: acquiring basic service information and resource application information; verifying the basic service information to obtain microservice identifiers, and constructing a microservice catalog based on the microservice identifiers and basic service information; generating a microservice-resource bidirectional mapping graph based on resource application information, microservice identifiers, and the microservice catalog; automatically converging user permissions at the microservice dimension to obtain permission convergence results; grouping and aggregating resource billing details according to microservice tags based on the microservice-resource bidirectional mapping graph to obtain resource billing statistics results at the microservice dimension; and combining the microservice-resource bidirectional mapping graph, permission convergence results, and resource billing statistics results to uniformly manage resource instances, thereby obtaining a service-centric enterprise hybrid cloud resource management result.

Description

Technical Field

[0001] This invention relates to the field of cloud computing resource management technology, and in particular to a service-centric enterprise hybrid cloud resource management method and system. Background Technology

[0002] With the widespread adoption of hybrid cloud and microservice architectures in enterprises, the types of resources within enterprises are gradually increasing, and the relationships between resources are becoming increasingly complex. To ensure the stable operation of microservices, it is necessary to manage resources such as physical machines, virtual machines, containers, domain names, databases, and configuration files in a unified manner, and to achieve the relationship management between resources and microservices, thereby improving resource management efficiency and business management capabilities.

[0003] Resource management typically relies on traditional CMDBs (Configuration Management Databases) or cloud vendors' own management consoles. Its management dimensions are usually centered on asset ledgers or cluster nodes, which uniformly record and manage physical machines, virtual machines, containers, and network resources.

[0004] However, the above-mentioned resource-centric static management approach has the following drawbacks: during the resource application process, only the information of the resource being used by the department can be recorded, and it is impossible to trace which microservice application the resource specifically serves, making it difficult to quickly locate the scope of impact when a fault occurs; at the same time, due to the lack of a reverse mapping relationship between resources and microservices, operations and maintenance personnel need to manually check the affected microservices during resource changes or resource reclamation, which poses a high risk. Summary of the Invention

[0005] To address the current technical issues where the resource application process can only record information about which department has used the resource, but cannot trace which microservice application the resource specifically serves, making it difficult to quickly locate the scope of impact when a failure occurs; and because there is no reverse mapping relationship between resources and microservices, operations and maintenance personnel need to manually check the affected microservices during resource changes or resource reclamation, which poses a high-risk technical problem.

[0006] The technical solution provided by this invention is as follows: A first aspect of this invention provides a service-centric enterprise hybrid cloud resource management method, comprising: S1: Obtain basic service information and resource application information; S2: Verify the service basic information to obtain the microservice identifier, and construct the microservice catalog based on the microservice identifier and service basic information; S3: Generate a bidirectional mapping graph of microservices and resources based on resource request information, microservice identifiers, and microservice catalogs; S4: Based on the microservice-resource bidirectional mapping graph, the permissions of users at the microservice level are automatically converged to obtain the permission convergence result; S5: Obtain resource billing details; S6: Based on the microservice-resource bidirectional mapping graph, the resource billing details are grouped and aggregated according to the microservice tags to obtain the resource billing statistics results at the microservice level; S7: By combining the microservice-resource bidirectional mapping graph, permission convergence results, and resource billing statistics, resource instances are managed in a unified manner to obtain service-centric enterprise hybrid cloud resource management results.

[0007] A second aspect of this invention provides a service-centric enterprise hybrid cloud resource management system, comprising: a processor and a memory; A third aspect of the present invention provides a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the service-centric enterprise hybrid cloud resource management method as described in the first aspect.

[0008] The beneficial effects of the technical solution provided by this invention include: The system searches for the corresponding microservice identifier in the microservice directory based on the target service name, establishing an association with the specific microservice during the application phase. This clarifies resource ownership from the source, avoiding the problem of not being able to determine the service object after resource creation. Simultaneously, a microservice tag corresponding to the microservice identifier is injected when the resource instance is created. A bidirectional mapping graph between microservices and resources is constructed based on the resource instance and the microservice tag. When a resource instance fails, the microservices associated with that resource instance can be queried in reverse through the bidirectional mapping graph, quickly determining the scope of the failure. Users can query the associated resources from a microservice or vice versa, enabling bidirectional tracing between microservices and resources. Before resource changes or reclamation, the affected microservices can be automatically identified, reducing manual troubleshooting workload and the risk of error. Attached Figure Description

[0009] Figure 1 A flowchart illustrating a service-centric enterprise hybrid cloud resource management method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a service-centric enterprise hybrid cloud resource management system provided in an embodiment of the present invention. Detailed Implementation

[0010] Reference manual attached Figure 1 The diagram illustrates a flowchart of a service-centric enterprise hybrid cloud resource management method provided by an embodiment of the present invention.

[0011] This invention provides a service-centric enterprise hybrid cloud resource management method, which may include the following steps: S1: Obtain basic service information and resource application information.

[0012] In one possible implementation, the service basic information includes: the microservice name and the business to which the microservice belongs.

[0013] Resource request information includes the resource type, information about the resource itself, and the name of the target microservice.

[0014] S2: Verify the service basic information to obtain the microservice identifier, and construct the microservice catalog based on the microservice identifier and service basic information.

[0015] Among them, the microservice identifier refers to the identification information used to uniquely identify a microservice node. The microservice directory is a data collection used to store the correspondence between microservice names, their respective business functions, and microservice identifiers.

[0016] Specifically, it receives input from the administrator, defines a logical microservice node (e.g., microservice name: Order-Query-Service), generates a globally unique microservice identifier, and sets the business to which the microservice belongs.

[0017] In this embodiment of the invention, by verifying the basic information of services and generating a unique microservice identifier, different microservices can be accurately distinguished. At the same time, a microservice catalog is constructed based on the microservice identifier and the basic information of services, thereby realizing unified management of microservices and providing basic support for subsequent resource application, resource binding and resource tracking.

[0018] S3: Generate a bidirectional mapping graph of microservices and resources based on resource request information, microservice identifiers, and microservice catalogs.

[0019] Among them, the microservice-resource bidirectional mapping graph refers to the set of mapping relationships used to represent the correspondence between microservices and resource instances.

[0020] In one possible implementation, S3 specifically includes sub-steps S301 to S304: S301: Find the microservice identifier corresponding to the target service name in the microservice directory and generate a resource request work order containing the target service name and the microservice identifier.

[0021] Among them, the resource application work order refers to the electronic process document generated when a user applies for resources. The resource application work order contains the name of the target service.

[0022] Specifically, the system establishes a unified entry point for resource request tickets. It identifies the cloud resources that the business depends on, such as virtual machines, database accounts, and domain names, and creates corresponding resource request forms for different resources. In addition to information about the resource itself, the ticket form includes a mandatory field for the "target microservice name." The system refuses to process resource creation requests that are not associated with a valid microservice name.

[0023] It should be noted that by searching for the microservice identifier corresponding to the target service name in the microservice directory, the specific microservice to which the resource belongs can be clearly identified during the resource application ticket generation stage. This avoids the problem of unclear resource ownership caused by only recording the department or applicant, and provides an accurate basis for subsequent resource creation, tag injection, and bidirectional mapping graph construction.

[0024] S302: Determine whether the target service name and microservice identifier meet the preset validity conditions. If yes, mark the resource request ticket as a pending approval ticket and proceed to step S303. Otherwise, return to step S301.

[0025] It should be noted that those skilled in the art can set preset effective conditions according to actual needs, and this invention does not limit such conditions.

[0026] It should be noted that by determining whether the target service name and microservice identifier meet the preset validity conditions, the validity of the resource application work order can be verified before resource approval, preventing resource applications without associated valid microservices from entering the subsequent process, thereby improving the accuracy and completeness of resource application data and reducing misbinding and omissions.

[0027] S303: Approve the work order to be approved, and create a resource instance based on the approved work order and the microservice identifier, and inject the microservice tag corresponding to the microservice identifier when the resource instance is created.

[0028] Resource instances refer to the infrastructure resources or software configuration resources that support the operation of microservices, including physical machines, virtual machines, container groups, domain names, IP addresses, database instances, message queue topics, monitoring and alerting rules, and configuration files. Microservice tags are the tag information written into a resource instance during its creation process to identify the microservice to which that instance belongs.

[0029] In one possible implementation, the specific process of injecting the microservice tag corresponding to the microservice identifier when the resource instance is created is as follows: inject the microservice tag corresponding to the microservice identifier when the resource instance is created through the API of the underlying platform or by executing an IaC script.

[0030] It should be noted that by creating resource instances after approval and injecting microservice tags corresponding to microservice identifiers during resource instance creation, the resource instances are bound to microservices at the time of generation. This ensures the correlation between resources and business services from the source, providing a foundation for subsequent resource tracking, permission convergence, and cost aggregation.

[0031] S304: Construct a bidirectional mapping graph between microservices and resources based on resource instances and microservice tags.

[0032] Specifically, after successful resource creation, a bidirectional mapping graph between microservices and resources is constructed and stored in a unified configuration management center (typically a CMDB). The specific mapping table structure is as follows: In the bidirectional mapping relationship between microservices and resources, the microservice with the identifier Order-Query-Service is associated with multiple types of resource instances. The resource types associated with this microservice include Kubernetes Pods, domain name records, and configuration files. Specifically, resource instance Pod-12345 is located in a self-built IDC's K8s environment, with a specific configuration of 2 CPU cores and 4GB of memory. Resource instance api.order.com is located in a public cloud DNS environment, with a specific configuration of the IP address 10.0.0.1. Resource instance config / order.yml is located in the configuration center, with a specific configuration of the database connection string mysql.order. Through the above mapping relationship, the resource instances and their configuration information associated with the same microservice in different resource environments can be determined. Based on this mapping table, a visual microservice resource topology graph is generated.

[0033] It should be noted that by constructing a two-way mapping graph between microservices and resources through resource instances and microservice tags, the created resource instances can be accurately associated with the corresponding microservice nodes. This eliminates the need for manual recording or post-event recording of resource relationships, thereby improving the accuracy of resource ownership identification and providing a reliable basis for subsequent permission authorization, cost statistics, and determination of the scope of resource impact.

[0034] In one possible implementation, the process after S3 and before S4 includes: Store the microservice-resource bidirectional mapping graph in the configuration management database.

[0035] In this embodiment of the invention, by establishing the correspondence between microservices and resources through resource application information, microservice identifiers and microservice catalogs, the originally scattered resource instances can be incorporated into the same service dimension for management. This allows the system to both query the associated resources from the microservice and locate the microservice to which the resource belongs, thereby improving the accuracy of resource tracking, fault impact analysis and subsequent management operations.

[0036] S4: Based on the microservice-resource bidirectional mapping graph, user permissions at the microservice level are automatically converged to obtain the permission convergence result.

[0037] In one possible implementation, S4 specifically includes S401 to S404: S401: Obtain user permission request information.

[0038] It should be noted that by obtaining the user's permission request information, users can make permission requests based on microservices, rather than requesting permissions for each resource such as hosts, Kubernetes Pods, or monitoring panels one by one. This simplifies the permission request process and reduces the complexity of user operations.

[0039] S402: Approve permission request information and, based on the microservice-resource bidirectional mapping graph, parse the resource instances associated with the microservice in the approved permission request information.

[0040] Specifically, after a work order is approved, the system automatically calls the underlying platform's API or executes an IaC script to inject the corresponding microservice tag when the resource instance is created.

[0041] For example, environment variables are forcibly injected when creating a Kubernetes Pod. When creating a public cloud host, the tagging interface is automatically called to tagged the microservice (ServiceID).

[0042] It should be noted that by approving permission request information and resolving resource instances associated with microservices based on the microservice-resource bidirectional mapping graph, the scope of resources that users need to access can be accurately determined before authorization, avoiding omissions caused by administrators manually searching for resources and improving the accuracy of permission allocation.

[0043] S403: Determine the permissions associated with the microservice based on the resource instance.

[0044] Specifically, the permissions include: host login permission, K8s Pod exec permission, and monitoring panel viewing permission.

[0045] Specifically, host login permission refers to the user's permission to log in to the physical machine or virtual machine associated with the microservice and perform access operations. K8s Pod exec permission refers to the container group command execution permission, which is the user's permission to execute commands on the Kubernetes container group. Monitoring panel viewing permission refers to the user's permission to view the resource monitoring panel associated with the microservice and its monitoring data.

[0046] It should be noted that the corresponding permissions are determined based on the parsed resource instances, enabling the system to convert different types of resources associated with microservices into specific executable permission items, such as host login permissions, K8s Pod exec permissions, and monitoring panel viewing permissions, thereby achieving automatic matching of permission content.

[0047] S404: Grant all permissions to the user and obtain the permission convergence result.

[0048] It should be noted that granting all permissions related to microservices to users in a unified manner can centralize permissions that were originally scattered across multiple platforms and resources to be processed at the microservice level. This reduces the workload of administrators in configuring permissions on each platform and lowers the risk of missing or incorrect permissions.

[0049] In this embodiment of the invention, the scope of resources associated with the microservice requested by the user is determined by the microservice-resource bidirectional mapping graph, and the corresponding resource permissions are uniformly granted to the user. This can centralize the permissions that were originally scattered in the host, container and monitoring system to the microservice dimension for processing, reduce the workload of manually configuring permissions one by one, and improve the efficiency of authorization and the accuracy of permission management.

[0050] S5: Get resource billing details.

[0051] Among them, resource billing details refer to resource cost data obtained through the public cloud cost interface.

[0052] In one possible implementation, S5 specifically involves obtaining resource billing details through the public cloud fee interface.

[0053] In this embodiment of the invention, obtaining resource billing details through the public cloud fee interface can provide a real source of cost data for subsequent cost collection, enabling the system to calculate the costs generated by each resource instance based on actual billing information, and then further group and aggregate according to microservice tags to obtain resource cost statistics results at the microservice level.

[0054] S6: Based on the microservice-resource bidirectional mapping graph, the resource billing details are grouped and aggregated according to the microservice tags to obtain the resource billing statistics results at the microservice level.

[0055] In this embodiment of the invention, the correspondence between resource billing details and microservices is determined by a microservice-resource bidirectional mapping graph, and grouping and aggregating operations are performed according to microservice tags. This enables the costs scattered across different resource instances to be uniformly collected at the specific microservice dimension, facilitating the statistical analysis of the actual resource consumption of each microservice and improving the accuracy of cost accounting.

[0056] S7: By combining the microservice-resource bidirectional mapping graph, permission convergence results, and resource billing statistics, resource instances are managed in a unified manner to obtain service-centric enterprise hybrid cloud resource management results.

[0057] Furthermore, for scenarios where multiple microservice containers are deployed on the same physical host (i.e., resource-sharing scenarios), the system provides a cost-sharing strategy configuration interface. The default strategy is to distribute the physical machine cost equally based on the number of services. The system also supports administrators to customize the allocation based on a CPU utilization-weighted ratio. Finally, a microservice cost report is output, clearly showing the overall cost of each microservice in a hybrid cloud environment.

[0058] In this embodiment of the invention, by combining the microservice-resource bidirectional mapping graph, permission convergence results, and resource billing statistics, resource ownership, permission management, and cost statistics are unified under the microservice dimension for processing. This prevents resource instances from being managed separately in a decentralized state, thereby achieving unified management of enterprise hybrid cloud resources centered on services and improving the completeness and visibility of resource management.

[0059] Reference manual attached Figure 2 The diagram illustrates a service-centric enterprise hybrid cloud resource management system according to an embodiment of the present invention.

[0060] This invention provides a service-centric enterprise hybrid cloud resource management system 20, comprising: a processor 201 and a memory 202; The memory 202 stores programs or instructions that can run on the processor 201. When the program or instructions are executed by the processor 201, they implement the steps of the above-described service-centric enterprise hybrid cloud resource management method and achieve the same technical effect. To avoid repetition, the present invention will not elaborate further.

[0061] This invention provides a readable storage medium that stores a program or instructions on the readable storage medium. When the program or instructions are executed by a processor, they implement the steps of the above-described service-centric enterprise hybrid cloud resource management method and achieve the same technical effect. To avoid repetition, this invention will not elaborate further.

[0062] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. The scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A service-centric enterprise hybrid cloud resource management method, characterized in that, include: S1: Obtain basic service information and resource application information; S2: Verify the service basic information to obtain the microservice identifier, and construct the microservice directory based on the microservice identifier and the service basic information; S3: Generate a bidirectional mapping graph of microservices and resources based on the resource request information, the microservice identifier, and the microservice directory; S4: Based on the microservice-resource bidirectional mapping graph, the permissions of users at the microservice level are automatically converged to obtain the permission convergence result; S5: Obtain resource billing details; S6: Based on the microservice-resource bidirectional mapping graph, the resource billing details are grouped and aggregated according to the microservice tags to obtain the resource billing statistics results at the microservice level; S7: Combining the microservice-resource bidirectional mapping graph, the permission convergence result, and the resource billing statistics result, resource instances are managed in a unified manner to obtain service-centric enterprise hybrid cloud resource management results.

2. The service-centric enterprise hybrid cloud resource management method according to claim 1, characterized in that, The basic service information includes: the microservice name and the business to which the microservice belongs; The resource application information includes the resource type, information about the resource itself, and the name of the target microservice.

3. The service-centric enterprise hybrid cloud resource management method according to claim 1, characterized in that, S3 specifically includes: S301: Find the microservice identifier corresponding to the target service name in the microservice directory, and generate a resource request work order containing the target service name and the microservice identifier; S302: Determine whether the target service name and the microservice identifier meet the preset valid conditions; if yes, mark the resource application work order as a work order pending approval and proceed to step S303; otherwise, return to step S301. S303: Approve the pending work order, and create a resource instance based on the approved work order and the microservice identifier, and inject the microservice tag corresponding to the microservice identifier when the resource instance is created; S304: Construct the microservice-resource bidirectional mapping graph based on the resource instance and the microservice tag.

4. The service-centric enterprise hybrid cloud resource management method according to claim 1, characterized in that, The specific process of injecting the microservice tag corresponding to the microservice identifier when the resource instance is created is as follows: inject the microservice tag corresponding to the microservice identifier when the resource instance is created through the API of the underlying platform or by executing an IaC script.

5. The service-centric enterprise hybrid cloud resource management method according to claim 1, characterized in that, The process includes the following steps after S3 and before S4: The microservice-resource bidirectional mapping graph is stored in the configuration management database.

6. The service-centric enterprise hybrid cloud resource management method according to claim 1, characterized in that, S4 specifically includes: S401: Obtain the user's permission request information; S402: Approve the permission request information, and parse the resource instances associated with the microservice in the approved permission request information according to the microservice-resource bidirectional mapping graph; S403: Based on the resource instance, determine the permissions associated with the microservice; S404: Grant the user all the permissions described above to obtain the permission convergence result.

7. The service-centric enterprise hybrid cloud resource management method according to claim 1, characterized in that, The permissions include: host login permission, K8s Pod exec permission, and monitoring panel viewing permission.

8. The service-centric enterprise hybrid cloud resource management method according to claim 1, characterized in that, Specifically, S5 involves obtaining the resource billing details through the public cloud fee interface.

9. A service-centric enterprise hybrid cloud resource management system, characterized in that, include: Processor and memory; The memory stores programs or instructions that can run on the processor, which, when executed by the processor, implement the steps of the service-centric enterprise hybrid cloud resource management method as described in any one of claims 1 to 8.

10. A readable storage medium, characterized in that, The program or instructions are stored on the readable storage medium, and when executed by a processor, the program or instructions implement the steps of the service-centric enterprise hybrid cloud resource management method as described in any one of claims 1 to 8.

Images