Cloud platform service calling method, system and device, medium and program product

Abstract

The invention provides a cloud platform service calling method and system, and belongs to the technical field of cloud computing, and the method comprises the steps: adding a corresponding label on the basis of an original request, and generating a to-be-executed request; according to the label, determining all target control services which need to be called in the cloud platform by the to-be-executed request; according to the security levels corresponding to all the target control services, determining an execution strategy of the to-be-executed request when all the target control services are called; according to the execution strategy, sending the to-be-executed request to the heterogeneous execution body of each target control service for processing, and obtaining an execution result returned by each heterogeneous execution body; and determining a service calling result according to all the execution results, and returning the service calling result to the request initiator. According to the method, accurate identification and full-process management of the user request are realized through a full-process tracking mechanism in combination with the hierarchical execution strategy of the security level and the dynamic management of the multi-heterogeneous execution body, so that efficient and safe service calling requirements are met.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing technology, and in particular to a cloud platform service calling method, system, device, medium and program product. Background Art

[0002] With the development of cloud computing technology, cloud platforms, as the core infrastructure for centralized computing and storage, bear the processing needs of a large number of user requests. In the prior art, user requests are usually processed through centralized scheduling and static path allocation, and service calls are completed according to fixed logic. However, with the complexity and diversification of user needs, existing solutions have gradually exposed some limitations. Due to the large number of service modules and complex functions in the cloud platform, requests often lack effective identification methods in the process of multi-module collaboration, which may lead to confusion, repeated processing or loss of requests. In addition, for service modules with different security levels, the prior art cannot flexibly adjust resource allocation and service paths according to actual needs, resulting in potential security risks in high-security demand scenarios, and may cause resource waste and performance degradation in ordinary scenarios.

[0003] Therefore, how to accurately identify and manage the entire process of user requests in the cloud platform to meet the needs of efficient and secure service calls has become a technical problem that needs to be solved urgently. Summary of the invention

[0004] The present invention provides a cloud platform service calling method, system, device, medium and program product to solve the defects in the prior art and realize accurate identification and full-process management of user requests in the cloud platform to meet the needs of efficient and secure service calling.

[0005] The present invention provides a cloud platform service calling method, comprising the following steps: Receive an original request from a request initiator, and add a corresponding tag to the original request to generate a request to be executed; the tag is used to uniquely identify the original request; According to the tag, determine all target control services that need to be called in the cloud platform for the request to be executed; each target control service corresponds to a service type, and each service type corresponds to a security level; Determining, according to the security levels corresponding to all the target control services, an execution strategy for the request to be executed when calling all the target control services; According to the execution strategy, the request to be executed is sent to each heterogeneous execution body of the target control service for processing, and the execution result returned by each heterogeneous execution body is obtained; A service call result is determined based on all the execution results, and the service call result is returned to the request initiator.

[0006] According to a cloud platform service calling method provided by the present invention, determining the execution strategy of the request to be executed when calling all the target control services according to the security levels corresponding to all the target control services specifically includes: When the security level of the target control service is the first security level, distributing the to-be-executed requests to all first heterogeneous execution bodies of each of the target control services in parallel; When the security level of the target control service is the second security level, sending the request to be executed only to any one of all the second heterogeneous execution bodies of each of the target control services; The first security level is higher than the second security level.

[0007] According to a cloud platform service calling method provided by the present invention, according to the execution strategy, the request to be executed is sent to each heterogeneous execution body of the target control service for processing, and the execution result returned by each heterogeneous execution body is obtained, which specifically includes: For each target control service of the first security level, distributing the request to be executed to all the first heterogeneous execution bodies in parallel, and obtaining the first execution results returned by all the first heterogeneous execution bodies; When all the first execution results are consistent, the request to be executed is sent to any second heterogeneous execution body of the target control service of each second security level, and the second execution result returned by each second heterogeneous execution is obtained.

[0008] According to a cloud platform service calling method provided by the present invention, the method further includes: When any one of the first execution results is inconsistent with the other first execution results, first abnormal information is reported to the feedback control unit in the cloud platform to replace, clean or rotate the abnormal first heterogeneous execution body; When the second execution result is an execution failure, a new second execution body is randomly re-scheduled from each second security level target control service to continue execution until the number of re-executions reaches a preset value, and second abnormal information is reported to the feedback control unit in the cloud platform each time the execution fails to replace, clean or rotate the abnormal second heterogeneous execution body.

[0009] According to a cloud platform service calling method provided by the present invention, the method of adding a corresponding tag on the basis of the original request to generate a request to be executed specifically includes: Parsing the original request and extracting the first subtag; Determine all target functions that the original request needs to call in the cloud platform, and generate a second sub-tag according to a preset tag corresponding to each target function; generating a random third subtag each time the original request is communicated externally; The first subtag, the second subtag and the third subtag are combined to form a combined tag, and the combined tag is added to the request header or metadata field of the original request to generate the request to be executed.

[0010] According to a cloud platform service calling method provided by the present invention, the method further includes: Determining the security risk factor of each target control service according to the attack risk probability of various service types; All the target control services are graded according to the security risk coefficient to obtain the security levels corresponding to all the target control services.

[0011] The present invention also provides a cloud platform service calling system, comprising the following modules: A first processing module is used to receive an original request from a request initiator, and to attach a corresponding tag to the original request to generate a request to be executed; the tag is used to uniquely identify the original request; A second processing module is used to determine all target control services that need to be called in the cloud platform by the request to be executed according to the tag; each of the target control services corresponds to a service type, and each of the service types corresponds to a security level; The second processing module is further used to determine the execution strategy of the request to be executed when calling all the target control services according to the security levels corresponding to all the target control services; The second processing module is further used to send the request to be executed to each heterogeneous execution body of the target control service for processing according to the execution strategy, and obtain the execution result returned by each heterogeneous execution body; The third processing module is used to determine the service call result according to all the execution results, and return the service call result to the request initiator.

[0012] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the cloud platform service calling method as described above is implemented.

[0013] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any of the cloud platform service calling methods described above.

[0014] The present invention also provides a computer program product, including a computer program, which, when executed by a processor, implements any of the cloud platform service calling methods described above.

[0015] In summary, one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: By receiving the original request from the request initiator and attaching the corresponding tag to the original request, a pending request is generated, thereby realizing the unique identification and full-process tracking of the user request. By determining all the target control services that the pending request needs to call in the cloud platform according to the tag, the target service of the request is accurately identified. The target control service is clearly divided into different service types, and each service type corresponds to a security level. This hierarchical management strategy combines the importance and risk level of the service to ensure that the services of the first security level can be protected first, while the services of the second security level achieve efficient resource utilization. By determining the execution strategy of the pending request when calling all target control services according to the security levels corresponding to all target control services, the security and resource utilization efficiency of the cloud platform are dynamically balanced. By sending the pending request to each heterogeneous executor of the target control service for processing according to the execution strategy, and obtaining the execution results returned by each heterogeneous executor, efficient processing and dynamic adaptability of the request are achieved. By determining the service call result based on all execution results and returning the service call result to the request initiator, the closed-loop management of the service call is completed, and then the accurate identification and full-process management of user requests are realized in the cloud platform to meet the needs of efficient and secure service calls. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0017] Figure 1 This is one of the flow charts of the cloud platform service calling method provided by the present invention.

[0018] Figure 2 This is the second flow chart of the cloud platform service calling method provided by the present invention.

[0019] Figure 3 This is the third flow chart of the cloud platform service calling method provided by the present invention.

[0020] Figure 4This is the fourth flow chart of the cloud platform service calling method provided by the present invention.

[0021] Figure 5 This is the fifth flow chart of the cloud platform service calling method provided by the present invention.

[0022] Figure 6 This is the sixth flow chart of the cloud platform service calling method provided by the present invention.

[0023] Figure 7 It is a structural diagram of the cloud platform service calling system provided by the present invention.

[0024] Figure 8 It is a structural schematic diagram of the electronic device provided by the present invention. DETAILED DESCRIPTION

[0025] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with the drawings of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0026] It should be noted that, in the description of the present invention, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "include one..." do not exclude the existence of other identical elements in the process, method, article or device including the elements. The orientation or positional relationship indicated by the terms "upper", "lower", etc. is based on the orientation or positional relationship shown in the accompanying drawings, and is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the system or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present invention. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to the specific circumstances.

[0027] The terms "first", "second", etc. in the present invention are used to distinguish similar objects, and are not used to 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 the present invention can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first", "second", etc. are generally of the same type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" means at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0028] As a key technology to promote the digital transformation of traditional industries, cloud computing has become the core driving force for the development of the real economy. However, cloud computing platforms face complex and severe network security challenges. Traditional defense technologies mainly rely on boundary protection and prior knowledge of attacks, and cannot fully address the generalized functional safety issues of cloud platforms. This plug-in defense method is difficult to meet the growing security needs of cloud platforms, and has failed to resolve the contradiction between system performance and security. New solutions are urgently needed to enhance the inherent security capabilities of cloud platforms.

[0029] As an innovative security paradigm, intrinsic security theory and mimicry defense technology integrate dynamic, heterogeneous and redundant characteristics into system design by simulating biological mimicry phenomena, thereby improving the defense capabilities of cloud platforms. Although some technical solutions have attempted to apply mimicry defense technology to transform cloud platforms, these solutions have obvious engineering bottlenecks in practice. For example, some solutions have high deployment costs due to the independent deployment of multiple cloud management modules, and at the same time, they have insufficient processing capabilities for feedback control and cloud platform complexity, ignoring key issues such as unified authentication and data consistency; other solutions have complex multi-level arbitration strategies in message distribution and arbitration, which seriously affect system performance and lack engineering feasibility; and some solutions cannot effectively solve the problems of consistency assurance and efficient communication when heterogeneous executors operate on databases. As a highly complex system, the cloud platform includes virtual resource management such as computing, storage, and network, and also involves complex communication phenomena between different components, modules, and services. This complexity further increases the difficulty of intrinsic security transformation.

[0030] The present application provides a cloud platform service calling method, which improves and optimizes the shortcomings of the existing solutions in many aspects. Overall, the solution takes the cloud platform control service as the core, divides it into two types: the first security level and the second security level, and adopts differentiated endogenous security empowerment strategies for different levels. For the first security level external interface service (such as the API service in OpenStack), the endogenous security integrated empowerment is adopted, and the reliability and anti-attack ability of the results are ensured by distributing user requests to multiple heterogeneous executors for parallel processing, and the consistency arbitration mechanism is combined to ensure the reliability of the results and the ability to resist attacks, which significantly improves the level of security protection. For control services with lower security requirements (such as scheduling services or execution services), the endogenous security gene empowerment strategy is adopted, and a single heterogeneous executor is randomly scheduled for processing, and the resource utilization efficiency is optimized by combining a dynamic rotation mechanism, thereby reducing the complexity and resource consumption of the transformation. The mimetic transformation of the first security level service is achieved through multi-dimensional heterogeneity, including the combination of different hardware architectures, container runtimes and operating systems, which enhances the dynamic adaptability of the service and the robustness of the system. At the same time, the processing strategy of the second security level service simplifies the execution process by lightweight design, and achieves efficient management through the container orchestration system. This differentiated design not only ensures strong protection for important interface services during implementation, but also avoids excessive impact on the overall performance of the system, successfully achieving a dynamic balance between security and performance.

[0031] The following embodiments will be combined Figure 1-Figure 8 The cloud platform service calling method, system, electronic device and storage medium provided by the present invention are described, and the specific implementation method of the solution is explained in detail.

[0032] Figure 1 This is one of the flow charts of the cloud platform service calling method provided by the present invention, such as Figure 1 As shown, including but not limited to the following steps: Step 101: Receive the original request from the request initiator, and add a corresponding tag to the original request to generate a request to be executed; the tag is used to uniquely identify the original request.

[0033] When implementing step 101, in order to ensure that each user request can be accurately identified and tracked throughout the complex service call and execution process of the cloud platform, it is necessary to generate a request to be executed by attaching a unique tag after receiving the original request from the request initiator. The core purpose of this design is to solve the problem of request confusion, repeated processing or call conflict caused by multi-module collaboration in traditional cloud platforms, and at the same time lay the foundation for subsequent service calls and result aggregation.

[0034] In one possible implementation, refer to Figure 2 , Figure 2This is the second flow chart of the cloud platform service calling method provided by the present invention, such as Figure 2 As shown, step 101 specifically includes steps 201-204: Step 201: Parse the original request and extract the first subtag.

[0035] Step 202: Determine all target functions that the original request needs to call in the cloud platform, and generate a second sub-tag according to a preset tag corresponding to each target function.

[0036] Step 203: Generate a random third subtag each time the original request performs external communication.

[0037] Step 204: Combine the first subtag, the second subtag, and the third subtag to form a combined tag, and add the combined tag to the request header or metadata field of the original request to generate a request to be executed.

[0038] Specifically, when the cloud platform receives the original request from the request initiator, it first performs a parsing operation to extract the first subtag. The first subtag is usually bound to a unique identifier of the request, such as the source, timestamp, or other specific features of the request, and is used to globally identify the entire request to ensure that the request always remains unique in the cloud platform. This design can avoid identification conflicts caused by concurrent processing of multi-user or multi-threaded requests.

[0039] On the basis of extracting the first sub-tag, it is necessary to further analyze the operation content involved in the original request to determine all the target functions that need to be called by the request in the cloud platform. For each target function, the system generates a corresponding preset tag based on the pre-set functional characteristics or risk assessment indicators, and aggregates these tags to form a second sub-tag. The role of the second sub-tag is to clarify the module or service path that the request needs to pass through, to ensure that in subsequent service calls, the system can quickly locate the relevant functional modules and provide a basis for security level classification.

[0040] In addition, since the original request may communicate with external services or databases multiple times during execution, in order to avoid identification confusion or processing conflicts caused by repeatedly sending the same request data, the system dynamically generates a random third subtag for each communication. The third subtag is generated in combination with the current execution status of the request, which can provide a unique identifier for each independent communication operation, ensuring that each communication data can be accurately identified and tracked even in a complex asynchronous processing environment.

[0041] Finally, the first subtag, the second subtag, and the third subtag are combined to form a complete combined tag, and the combined tag is added to the request header or metadata field of the original request to generate a request to be executed. The introduction of combined tags not only makes each request globally unique, but also provides fine-grained identification capabilities in its processing path and communication process, thereby achieving full process traceability of the request.

[0042] Step 102: According to the tags, determine all target control services that need to be called in the cloud platform for the request to be executed; each target control service corresponds to a service type, and each service type corresponds to a security level.

[0043] When implementing step 102, in order to ensure that user requests can be accurately assigned to all target control services that need to be called in the cloud platform, and to perform reasonable scheduling according to the characteristics and security requirements of different services, the system associates target services through tags and determines the security level of each service. The core purpose of this design is to solve the problems of unclear service call paths, inflexible security management and resource allocation in traditional cloud platforms, so as to achieve efficient and secure processing of requests.

[0044] In one possible implementation, refer to Figure 3 , Figure 3 This is the third flow chart of the cloud platform service calling method provided by the present invention, such as Figure 3 As shown, the security level corresponding to each target control service can be obtained by following the steps below: Step 301: Determine the security risk factor of each target control service according to the attack risk probability of various service types.

[0045] When implementing step 301, in order to scientifically classify the security levels of the target control services in the cloud platform, it is necessary to calculate the security risk coefficient of each service based on the attack risk probability. The design purpose of this process is to solve the problem that the security level classification in the traditional cloud platform lacks quantitative basis and cannot dynamically adapt to the changes in service risks, thereby providing reliable support for subsequent service scheduling and security protection.

[0046] During the specific implementation, the system first collects data and conducts risk analysis on the characteristics of the target control service. The attack risk probability of each target control service is the result of a comprehensive evaluation of multiple dimensions, including the number and complexity of the service's open interfaces, the frequency of historical security incidents, the number of potential vulnerabilities, and the frequency of external communications. For services exposed to the external environment, such as services that directly provide API interfaces (such as nova-api service, cinder-api service, neutron-server service, glance-api service, etc. in openstack), the probability of being attacked is usually high; while for services that only interact and execute with internal modules, the risk probability is relatively low.

[0047] After clarifying the risk dimensions of each service, the system calculates the risk contribution values ​​of different dimensions by setting weight factors to generate the security risk coefficient of each target control service. For example, the number of externally exposed interfaces may be the main source of risk, with a higher weight factor; while the frequency of historical security events may be a secondary indicator with a lower weight factor. In this way, the system can quantify the security risk coefficient of each target control service, making it comparable and reference-worthy among different services.

[0048] The calculation result of the security risk coefficient not only reflects the current security situation of the service, but also dynamically responds to environmental changes. For example, when a service adds a high-risk external interface, or a new vulnerability is discovered in the underlying module it depends on, the system can update its risk assessment in real time and recalculate the security risk coefficient. In this way, the cloud platform can maintain a dynamic perception of the security status of the service and provide an accurate basis for subsequent security level classification.

[0049] Step 302: Classify all target control services according to the security risk coefficient to obtain the security levels corresponding to all target control services.

[0050] In specific implementation, the system first uses the security risk coefficient calculated in step 301, combined with the preset risk threshold or interval, to divide the target control service into multiple security levels. This division process is based on the risk coefficient, and reflects the security requirements of different services by setting a number of classification intervals. Usually, target control services corresponding to high risk coefficients are classified as the first security level. These services may directly provide interfaces to the outside world or process core sensitive data; while target control services with low risk coefficients are classified as the second security level. These services usually undertake background support or auxiliary functions and have less impact on the overall system.

[0051] During the partitioning process, the system can adopt static or dynamic adjustment strategies. For example, static partitioning is based on a fixed risk interval set in advance, and all target control services are directly mapped to the corresponding security level according to their risk coefficients. Dynamic partitioning combines real-time operation data with environmental changes. For example, if the communication frequency of a service increases or new vulnerabilities appear in its dependent modules, the system can adjust its security level in real time, so that the partitioning results always accurately reflect the current risks.

[0052] After completing the classification, the system binds the security level information of each target control service with its functional characteristics and tags to form a unified service configuration table. This configuration table not only facilitates subsequent service scheduling and policy execution, but also enables dynamic management and rapid query of service levels within the cloud platform.

[0053] Step 103: Determine the execution strategy of the request to be executed when calling all target control services according to the security levels corresponding to all target control services.

[0054] When implementing step 103, in order to efficiently and securely call all target control services in the cloud platform, it is necessary to determine the execution strategy of the pending request according to its security level. The core purpose of this design is to achieve a dynamic balance between resource allocation and security protection, that is, while meeting the first security level requirements, optimize the processing efficiency of the second security level service, thereby improving the performance and reliability of the entire cloud platform.

[0055] In one possible implementation, refer to Figure 4 , Figure 4 This is a fourth flow chart of the cloud platform service calling method provided by the present invention, such as Figure 4 As shown, step 103 specifically includes steps 401-402: Step 401: When the security level of the target control service is the first security level, the requests to be executed are distributed to all first heterogeneous execution bodies of each target control service in parallel.

[0056] When implementing step 401, in order to ensure the security and reliability of the target control service of the first security level (i.e., high security level) during execution, it is necessary to adopt a multi-copy parallel distribution strategy to distribute the request to be executed to all first heterogeneous execution bodies of the service for processing at the same time. The purpose of this design is to enhance the system's fault tolerance and anti-attack capabilities, and ensure the consistency and credibility of the request processing results in complex threat scenarios.

[0057] In specific implementation, the system first selects the service modules of the first security level according to the security level information of the target control service, and starts the distribution process according to the execution strategies corresponding to these modules. Before the request to be executed is distributed, a combined tag (including the first subtag, the second subtag and the third subtag) is attached to ensure the unique identification and traceability of each request. Then, the system sends the request to be executed carrying the tag in parallel to all the first heterogeneous executors of the target control service of the first security level.

[0058] The construction of the first heterogeneous executive is achieved by introducing a variety of heterogeneous technologies, including but not limited to different hardware architectures (such as X86, ARM, RISC-V, etc.), different operating systems (such as Linux, Windows, etc.) and different container runtimes (such as Docker, Kata Container, etc.). The diversity of heterogeneous executives makes them more robust in the face of potential malicious attacks or random failures, and can effectively prevent attacks against specific architectures or environments.

[0059] Step 402: When the security level of the target control service is the second security level, only send a request for execution to any one of all second heterogeneous execution bodies of each target control service; wherein the first security level is higher than the second security level.

[0060] When implementing step 402, in order to optimize resource utilization and processing efficiency, a single-copy random scheduling execution strategy is adopted for the target control service of the second security level (i.e., low security level), that is, the request to be executed is only distributed to any one of all the second heterogeneous execution bodies of the service for processing. The core purpose of this design is to reduce system resource consumption and improve the overall processing performance of requests while ensuring service availability.

[0061] In specific implementation, the system first selects the service modules of the second security level according to the security level information of the target control service. These modules usually correspond to functions with lower security requirements and less exposure risks in the cloud platform, such as general data query or non-critical resource management. For these services, the request to be executed is attached with a combined tag consisting of the first subtag, the second subtag and the third subtag to ensure the unique identification and traceability of the request during the distribution and execution process.

[0062] When executing request distribution, the system selects a target instance from all second heterogeneous executors through random scheduling or polling strategies. Although the heterogeneous design of the second heterogeneous executor is not as diverse as the first heterogeneous executor, it still contains a combination of different hardware architectures, operating systems, or container runtimes, and can provide basic fault tolerance. The random scheduling method avoids the uneven load of executors that may be caused by fixed allocation, and at the same time increases the dynamic nature of request allocation, making it difficult for attackers to predict the execution path, thereby improving the security of the system.

[0063] Step 104: according to the execution strategy, the request to be executed is sent to each heterogeneous execution body of the target control service for processing, and the execution result returned by each heterogeneous execution body is obtained.

[0064] When implementing step 104, in order to efficiently execute the pending requests in the cloud platform and obtain reliable execution results, it is necessary to distribute the pending requests to various heterogeneous execution bodies according to the security level of the target control service and the corresponding execution strategy, and obtain the execution results returned by each execution body. The core purpose of this design is to achieve the accuracy and security of request execution, while optimizing resource utilization and ensuring the stability and reliability of service calls.

[0065] In one possible implementation, refer to Figure 5 , Figure 5 This is a fifth flow chart of the cloud platform service calling method provided by the present invention, such as Figure 5 As shown, step 104 specifically includes steps 501-502: Step 501: for each target control service of the first security level, distribute the request to be executed to all first heterogeneous execution bodies in parallel, and obtain the first execution results returned by all first heterogeneous execution bodies.

[0066] When implementing step 501, in order to ensure the reliability and anti-attack capability of the first security level target control service during the request processing, it is necessary to distribute the request to be executed in parallel to all the first heterogeneous execution bodies of the service, and collect and process the return results of each execution body. The core purpose of this design is to enhance the fault tolerance of the system by using the mechanism of multi-copy parallel execution, and to ensure the credibility of the final result through consistency judgment.

[0067] In specific implementation, the system first determines the set of first heterogeneous executors that need to be distributed to the requests to be executed according to the security policy of the first security level target control service. The first heterogeneous executors are designed and constructed through the diversity of hardware architecture, operating system and operating environment. When distributing the requests to be executed, the system passes the combined tag (including the first subtag, the second subtag and the third subtag) attached to the request to all first heterogeneous executors to ensure that each executor can uniquely identify the request and correctly parse the execution path. After receiving the request, each first heterogeneous executor independently completes its processing task and returns the execution result to the system.

[0068] Step 502: When all first execution results are consistent, the request to be executed is sent to any second heterogeneous execution body of each target control service of the second security level, and the second execution result returned by each second heterogeneous execution is obtained.

[0069] When implementing step 502, in order to optimize resource utilization efficiency and ensure that the request of the second security level target control service can be accurately processed, when the first execution results of all the first security level target control services are consistent, the system distributes the request to be executed to any second heterogeneous execution body of each second security level target control service for processing and obtains the execution result. The core purpose of this design is to reduce system resource consumption by simplifying the processing strategy of the low security module while ensuring the integrity and accuracy of the high security module.

[0070] In specific implementation, the selection of the second heterogeneous executor adopts random scheduling, polling strategy or preset rules to ensure load balancing of the executor, while increasing the dynamics of request processing and avoiding the path prediction or attack risks that may be caused by fixed allocation. When distributing requests to be executed, the system attaches a combined tag (including the first subtag, the second subtag and the third subtag) to ensure the unique identification and tracking capabilities of the request and avoid data confusion or conflict in cross-module communication. After receiving the request, the selected second heterogeneous executor independently completes the processing task and returns the second execution result.

[0071] In one possible implementation, refer to Figure 6 , Figure 6 This is the sixth flow chart of the cloud platform service calling method provided by the present invention, such as Figure 6 As shown, the method further includes steps 601-602: Step 601: When any one of the first execution results is inconsistent with the other first execution results, first abnormal information is reported to the feedback control unit in the cloud platform to replace, clean or rotate the abnormal first heterogeneous execution body.

[0072] When implementing step 601, in order to ensure that the execution process of the first security level target control service always has high reliability and credibility, when the first execution result returned by the first heterogeneous executor is inconsistent, the system needs to promptly report the first abnormal information to the feedback control unit to replace, clean or rotate the abnormal first heterogeneous executor. The core purpose of this design is to quickly discover and isolate possible faults or potential attack risks through a dynamic exception handling mechanism to ensure the security and stability of the system.

[0073] In specific implementation, the system first makes a consistency decision on all first execution results of the first security level target control service. When there is any inconsistency in the results, the system determines it as a potential anomaly, which may be caused by an attack on a first heterogeneous executor, a hardware failure, or a system error. To prevent the erroneous results from affecting subsequent processing, the system immediately generates the first exception information, which includes the identification of the abnormal executor, the deviation information of the returned results, and the relevant tags (such as the first sub-tag and the second sub-tag), and sends the exception information to the feedback control unit of the cloud platform.

[0074] After receiving the first abnormal information, the feedback control unit will process the abnormal first heterogeneous executor according to the system preset strategy. Specifically, the system will further analyze the executor to confirm the source of the abnormality. If it is confirmed that the executor is faulty or attacked, the system will start the cleaning process to restore its normal operation capability by resetting the execution environment or reloading the security policy; if the executor problem cannot be repaired, the system will start the replacement or rotation mechanism to replace the abnormal executor with a new instance to ensure the integrity and reliability of the heterogeneous resource pool.

[0075] While handling the exception, the system will also record the first exception information in the log and update the relevant operation status monitoring data so that the administrator can conduct further analysis and optimization. This real-time exception handling and monitoring mechanism enables the system to quickly respond to abnormal events, prevent the spread of erroneous results, and continuously optimize the operation status of heterogeneous resource pools.

[0076] Step 602: When the second execution result is an execution failure, a new second execution body is randomly re-scheduled from each second security level target control service to continue execution until the number of re-executions reaches a preset value, and second abnormal information is reported to the feedback control unit in the cloud platform each time the execution fails, so as to replace, clean or rotate the abnormal second heterogeneous execution body.

[0077] When implementing step 602, in order to ensure the continuity and reliability of the second security level target control service during the request execution process, when a single copy fails to execute, the system needs to randomly re-schedule a new second heterogeneous execution body to continue execution, and report the second abnormal information to the feedback control unit every time the execution fails, so as to replace, clean or rotate the abnormal second heterogeneous execution body. The core purpose of this design is to improve the stability of the system through abnormal feedback and dynamic repair mechanism while ensuring service availability.

[0078] In specific implementation, the system first makes a consistency decision on the execution result of the first security level target control service. When the first execution results returned by all first heterogeneous executors are consistent, the decision result is deemed valid, and the system enters the execution phase of the second security level target control service. At this time, the system selects a target executor from the corresponding second heterogeneous executor set for request distribution according to the execution strategy of the second security level service. In the execution phase of the second security level target control service, the system receives the second execution result returned by the second heterogeneous executor. When the returned result shows that the execution failed (such as timeout, error code or does not meet the expected format), the system immediately determines that the current executor cannot complete the request processing normally. At this time, the system reselects a new target executor from the second heterogeneous executor set corresponding to the service through a random scheduling mechanism, and redistributes the request to be executed to the newly selected executor. Each time it is redistributed, the system updates the random tag (third subtag) in the combined tag to ensure the uniqueness and traceability of the new request in the communication.

[0079] For the number of re-executions, the system sets a preset value as an upper limit to prevent resource waste or processing delays due to continuous failure of the executor. When a redistribution still fails, the system will record the exception information, including the failed executor identification, fault description and related combination tags, and generate a second exception information and send it to the feedback control unit. After receiving the second exception information, the feedback control unit starts the cleaning, replacement or rotation process of the abnormal executor. For example, the module can diagnose the abnormal executor and clean up its operating environment, or mark it as unavailable and call in a backup instance to replace the abnormal resources.

[0080] After reaching the preset upper limit of re-execution times, if the request processing is still not successfully completed, the system will trigger a high-level exception management process and report the current processing status to the management platform for further analysis and processing by the operation and maintenance personnel.

[0081] Step 105: Determine the service call result based on all execution results, and return the service call result to the request initiator.

[0082] In specific implementation, after completing all execution steps of the target control service, the system collects the execution results from the first security level and second security level target control services. For the first security level target control service, the system has confirmed the reliability of the results through multi-copy parallel execution and consistency arbitration mechanism; for the second security level target control service, the system ensures the availability of the results through single-copy random scheduling and retry mechanism. At this time, the system associates these execution results according to the combined tags of the request (first subtag, second subtag and third subtag) to ensure that each execution result accurately matches the corresponding request to be executed.

[0083] In the result aggregation phase, the system will further format all execution results and return a unified data structure to adapt to the interface requirements of the request initiator. If the execution results of some services are not returned within the specified time or return an exception, the system will generate corresponding error information and attach it to the result so that the request initiator can understand the cause and scope of the call failure. Such error information will also be recorded in the log for operation and maintenance personnel to analyze and optimize.

[0084] Before the results are returned, the system will also perform integrity checks on the summary results to ensure that the execution paths and call results of all requests can be tracked and verified. If inconsistencies or omissions are found, the system will choose to trigger secondary scheduling or high-level exception reporting processes based on the exception type. The implementation of integrity checks relies on the combined tag generated in step 101 and the execution record of step 104, thus forming a transparent and traceable processing link.

[0085] Finally, the system returns the summary of the service call results to the user through the interface of the request initiator, including the result of successful execution, the reason for failure, and related tag information. The return process is transmitted through a secure channel to prevent data leakage or tampering during transmission.

[0086] By implementing step 105, the system can condense the complex multi-module execution process into a clear and reliable service call result, thereby improving the user's trust and satisfaction. The formatting and integrity verification of the execution result ensures the accuracy of the result, while the addition and logging of error information provide key support for subsequent system optimization and problem diagnosis. This closed-loop design enables the cloud platform to respond to complex service call requests in an efficient, secure and transparent manner, fully demonstrating its operating efficiency and service capabilities.

[0087] Furthermore, this application comprehensively optimizes and improves the architecture of the cloud platform, and improves the performance of the cloud platform in terms of efficiency, security, and resource utilization efficiency through the collaborative design and distributed deployment of multiple functional modules.

[0088] The cloud management interface is the entry point for users to interact with the cloud platform, providing resource management and display functions. Users can manage computing, storage, network and other resources throughout their life cycle through the cloud management interface. When a user initiates a request, the user-side proxy arbitration unit receives the request and adds a globally unique request tag to the request header to form a request to be executed. These tags, through the combination of the first sub-tag, the second sub-tag and the third sub-tag, not only ensure the uniqueness and traceability of the request, but also provide a clear identification for subsequent distribution and execution.

[0089] The user-side proxy adjudication unit forwards the tagged request to heterogeneous resource pool 1. For the target control service of the first security level, heterogeneous resource pool 1 empowers its executor with endogenous security integration. Through heterogeneous and microservice design, these executors are composed of different hardware architectures, container runtimes, and operating systems, which significantly improves the system's anti-attack capabilities and robustness. Multiple heterogeneous executors receive requests at the same time and process them independently. When they need to interact with the database or other services, a combined label is generated and the operation content is sent to the business-side proxy adjudication unit. The business-side proxy adjudication unit adjudicates these operations to ensure the consistency and correctness of database operations and message communications.

[0090] For database operations of the first security level service, the data proxy adjudication module determines whether the request is consistent based on the tag. After the adjudication is passed, the unified operation is sent to the database execution unit, and the execution result is returned to all relevant execution bodies. For inter-service communication, the message communication proxy adjudication module adjudicates the validity of the message based on the tag content, and randomly distributes the message to a control service in the heterogeneous resource pool 2 for continued execution or directly sends it to the business execution unit.

[0091] Heterogeneous resource pool 2 processes the target control service of the second security level. Its heterogeneous design is more lightweight and adopts a random scheduling strategy to dynamically distribute requests to the executor. During the request execution process, if a single copy fails to execute, the system will automatically reallocate the request to a new executor for processing to ensure the continuity and stability of the service. After the execution is completed, the result is returned through the business-side proxy decision unit and summarized to the user-side proxy decision unit.

[0092] The final virtual resource operation is completed by the business execution unit, including the creation, management and deletion of resources such as virtual machines, cloud disks and cloud networks. Regardless of whether the request comes from heterogeneous resource pool 1 or heterogeneous resource pool 2, the business execution unit will complete the actual operation according to the instruction and return the result to the user-side proxy decision unit. At the same time, the feedback control unit dynamically manages the executors in heterogeneous resource pool 1 and heterogeneous resource pool 2, responds to abnormal situations in a timely manner, and maintains the stability of the resource pool through cleaning, replacement or rotation mechanisms.

[0093] The improved architecture of this application achieves full-process optimization of the cloud platform through inherent security empowerment and multi-module collaboration, enhances the security, stability and resource utilization efficiency of the system, and provides efficient solutions in complex service call scenarios.

[0094] Reference Figure 7 , Figure 7 It is a structural diagram of the cloud platform service calling system provided by the present invention, and the system includes: The first processing module is used to receive the original request from the request initiator, and to attach a corresponding tag to the original request to generate a request to be executed; the tag is used to uniquely identify the original request; The second processing module is used to determine all target control services that need to be called in the cloud platform for the request to be executed according to the tag; each target control service corresponds to a service type, and each service type corresponds to a security level; The second processing module is further used to determine the execution strategy of the request to be executed when calling all target control services according to the security levels corresponding to all target control services; The second processing module is further used to send the request to be executed to each heterogeneous execution body of the target control service for processing according to the execution strategy, and obtain the execution result returned by each heterogeneous execution body; The third processing module is used to determine the service call result according to all the execution results, and return the service call result to the request initiator.

[0095] In a possible implementation manner, the second processing module is further configured to: When the security level of the target control service is the first security level, distributing the to-be-executed requests to all first heterogeneous executors of each target control service in parallel; When the security level of the target control service is the second security level, the request to be executed is sent only to any one of all the second heterogeneous execution bodies of each target control service, wherein the first security level is higher than the second security level.

[0096] In a possible implementation manner, the second processing module is further configured to: For each target control service of the first security level, the to-be-executed request is distributed to all first heterogeneous execution bodies in parallel, and the first execution results returned by all first heterogeneous execution bodies are obtained; When all the first execution results are consistent, the request to be executed is sent to any second heterogeneous execution body of the target control service of each second security level, and the second execution result returned by each second heterogeneous execution is obtained.

[0097] In a possible implementation manner, the second processing module is further configured to: When any one of the first execution results is inconsistent with the other first execution results, first abnormal information is reported to the feedback control unit in the cloud platform to replace, clean or rotate the abnormal first heterogeneous execution body; When the second execution result is an execution failure, a new second execution body is randomly re-scheduled from each second security level target control service to continue execution until the number of re-executions reaches a preset value, and the second abnormal information is reported to the feedback control unit in the cloud platform each time the execution fails, so as to replace, clean or rotate the abnormal second heterogeneous execution body.

[0098] In a possible implementation manner, the first processing module is further configured to: Parse the original request and extract the first subtag; Determine all target functions that the original request needs to call in the cloud platform, and generate a second sub-label according to the preset label corresponding to each target function; Generate a random third subtag each time the original request makes external communication; The first subtag, the second subtag, and the third subtag are combined to form a combined tag, and the combined tag is added to the request header or metadata field of the original request to generate a request to be executed.

[0099] In a possible implementation, the system further includes a security level classification module, which is used to: Determine the security risk factor of each target control service based on the attack risk probability of various service types; All target control services are graded according to the security risk coefficient to obtain the corresponding security levels of all target control services.

[0100] It should be noted that the cloud platform service calling system provided by the present invention can execute the cloud platform service calling method of any of the above-mentioned embodiments during specific operation, which will not be elaborated in this embodiment.

[0101] Figure 8 is a schematic diagram of the structure of the electronic device provided by the present invention, such as Figure 8 As shown, the electronic device may include: a processor 810 (processor), a communication interface 820 (CommunicationsInterface), a memory 830 (memory) and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other through the communication bus 840. The processor 810 may call the logic instructions in the memory 830 to execute the cloud platform service calling method, which includes: In addition, the logic instructions in the above-mentioned memory 830 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0102] On the other hand, the present invention further provides a computer program product, the computer program product includes a computer program stored on a non-transitory computer-readable storage medium, the computer program includes program instructions, when the program instructions are executed by a computer, the computer can execute the cloud platform service calling method provided in the above embodiments, the method comprising: In another aspect, the present invention further provides a non-transitory computer-readable storage medium having a computer program stored thereon, which is implemented when the computer program is executed by a processor to execute the cloud platform service calling method provided in the above embodiments, the method comprising: The system embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, i.e., they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Those of ordinary skill in the art may understand and implement it without creative effort.

[0103] Through the description of the above implementation modes, those skilled in the art can clearly understand that each implementation mode can be implemented by means of software plus a necessary general hardware platform, or of course by hardware. Based on such an understanding, the above technical solution can essentially or in other words be embodied in the form of a software product that contributes to the prior art. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods of each embodiment or some parts of the embodiment.

[0104] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cloud platform service calling method, characterized in that: include: Receive the original request from the request initiator, and add a corresponding tag based on the original request to generate a request to be executed; The tag is used to uniquely identify the original request; According to the tag, determine all target control services that need to be called in the cloud platform for the request to be executed; each target control service corresponds to a service type, and each service type corresponds to a security level; Determining, according to the security levels corresponding to all the target control services, an execution strategy for the request to be executed when calling all the target control services; According to the execution strategy, the request to be executed is sent to each heterogeneous execution body of the target control service for processing, and the execution result returned by each heterogeneous execution body is obtained; A service call result is determined based on all the execution results, and the service call result is returned to the request initiator.

2. The cloud platform service calling method according to claim 1, characterized in that: Determining, according to the security levels corresponding to all the target control services, the execution strategy of the request to be executed when calling all the target control services specifically includes: When the security level of the target control service is the first security level, distributing the to-be-executed requests to all first heterogeneous execution bodies of each of the target control services in parallel; When the security level of the target control service is the second security level, sending the request to be executed only to any one of all the second heterogeneous execution bodies of each of the target control services; The first security level is higher than the second security level.

3. The cloud platform service calling method according to claim 2, characterized in that: The step of sending the request to be executed to each heterogeneous executor of the target control service for processing according to the execution strategy, and obtaining the execution result returned by each heterogeneous executor, specifically includes: For each target control service of the first security level, distributing the request to be executed to all the first heterogeneous execution bodies in parallel, and obtaining the first execution results returned by all the first heterogeneous execution bodies; When all the first execution results are consistent, the request to be executed is sent to any second heterogeneous execution body of the target control service of each second security level, and the second execution result returned by each second heterogeneous execution is obtained.

4. The cloud platform service calling method according to claim 3, characterized in that: The method further comprises: When any one of the first execution results is inconsistent with the other first execution results, first abnormal information is reported to the feedback control unit in the cloud platform to replace, clean or rotate the abnormal first heterogeneous execution body; When the second execution result is an execution failure, a new second execution body is randomly re-scheduled from each second security level target control service to continue execution until the number of re-executions reaches a preset value, and second abnormal information is reported to the feedback control unit in the cloud platform each time the execution fails to replace, clean or rotate the abnormal second heterogeneous execution body.

5. The cloud platform service calling method according to claim 1, characterized in that: The step of adding a corresponding tag on the basis of the original request to generate a request to be executed specifically includes: Parsing the original request and extracting the first subtag; Determine all target functions that the original request needs to call in the cloud platform, and generate a second sub-tag according to a preset tag corresponding to each target function; generating a random third subtag each time the original request is communicated externally; The first subtag, the second subtag and the third subtag are combined to form a combined tag, and the combined tag is added to the request header or metadata field of the original request to generate the request to be executed.

6. The cloud platform service calling method according to claim 1, characterized in that: The method further comprises: Determining the security risk factor of each target control service according to the attack risk probability of various service types; All the target control services are graded according to the security risk coefficient to obtain the security levels corresponding to all the target control services.

7. A cloud platform service calling system, characterized in that: include: A first processing module is used to receive an original request from a request initiator, and to attach a corresponding tag to the original request to generate a request to be executed; The tag is used to uniquely identify the original request; A second processing module is used to determine all target control services that need to be called in the cloud platform by the request to be executed according to the tag; each of the target control services corresponds to a service type, and each of the service types corresponds to a security level; The second processing module is further used to determine the execution strategy of the request to be executed when calling all the target control services according to the security levels corresponding to all the target control services; The second processing module is further used to send the request to be executed to each heterogeneous execution body of the target control service for processing according to the execution strategy, and obtain the execution result returned by each heterogeneous execution body; The third processing module is used to determine the service call result according to all the execution results, and return the service call result to the request initiator.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the computer program, the cloud platform service calling method as described in any one of claims 1-6 is implemented.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, the cloud platform service calling method as described in any one of claims 1 to 6 is implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by the processor, the cloud platform service calling method as described in any one of claims 1 to 6 is implemented.

Images