Cloud platform request processing method and device and computer equipment

Abstract

The invention discloses a cloud platform request processing method and device and computer equipment. The method comprises the steps that log data are acquired from multiple levels of a cloud platform, multiple service chains are generated according to the log data, the service chains are used for representing network function links needed for processing request messages, and the multiple levels at least comprise a user access layer, an access control layer, a resource service management and auditing layer and an application service management layer; receiving a request message, and in response to the request message, selecting a target service chain matched with the request message from the plurality of service chains; acquiring a resource allocation strategy of the target service chain; and under the condition that the request message passes verification, for the target service chain, processing the request message according to a resource allocation strategy of the target service chain.

Description

Technical Field

[0001] This application relates to the technical field of cloud platforms, and more particularly, to a cloud platform request processing method, apparatus, and computer device. Background Art

[0002] When the cloud security center scans application vulnerabilities in the cloud platform and policies, it will simulate a hacker intrusion attack through the public network (only sending request messages and not performing any actual attack behaviors) to perform a security scan on your server. If your server has security protection or monitoring deployments, such as a Web Application Firewall (WAF) or a SOC (Security Operations Center), add the IP address of the Web scanner to the whitelist to ensure the normal operation of the scanning service. When the cloud security vulnerability scan is executed in an enterprise information access control system based on cloud computing, in order to enable the operations in the system to be executed with high security and low cost and meet the user's needs on the basis of security, it is necessary to study and analyze users, data, and enterprise characteristics in the cloud computing environment. Users log in to the enterprise information system at the user access layer; perform identity authentication, authorization, and permission management through the access control layer; the resource service management and audit layer mainly provides specific resource services and resource audits; the application management layer realizes the invocation of resources in the resource service management and audit layer and the storage and invocation of data in the database through an interface. After the hierarchical division is implemented, it is also necessary to set security levels for the processes in the underlying layer and the virtual machines in the middle layer according to the multi-level security standard to form a cloud computing multi-level security model. However, in a large-scale system, there is improper use of resources for request message processing, resulting in a decrease in the request message processing efficiency. Summary of the Invention

[0003] Embodiments of this application provide a cloud platform request processing method, apparatus, and computer device to at least solve the technical problem of uneven resource allocation in the request message processing process in related technologies.

[0004] According to one aspect of the embodiments of this application, a cloud platform request processing method is provided, including: obtaining log data from multiple levels of the cloud platform, and generating multiple service chains according to the log data, where the service chains are used to represent network function links required for processing the request message, and the multiple levels at least include: a user access layer, an access control layer, a resource service management and audit layer, and an application service management layer; receiving a request message, and in response to the request message, selecting a target service chain that matches the request message from the multiple service chains; obtaining a resource allocation policy of the target service chain; and in the case where the request message passes verification, for the target service chain, processing the request message according to the resource allocation policy of the target service chain.

[0005] Optionally, obtaining the resource allocation policy for the target service chain includes: obtaining, from the log data, the association relationship between the databases, middleware, and server performance metrics required by the network functions included in the target service chain; constructing a topology graph according to the association relationship, where the edges in the topology graph are used to represent the association relationship between the databases, middleware, and server performance metrics, and the nodes in the topology graph are used to represent the databases, middleware, and server performance metrics; obtaining, from the log data, the data set corresponding to each node in the topology graph, where the data set of each node includes node data in different time dimensions; respectively forming sub-matrices by combining each node in the topology graph with the data set of each node, and combining multiple sub-matrices into a node matrix set; and determining the resource allocation policy for the target service chain according to the node matrix set.

[0006] Optionally, determining the resource allocation policy for the target service chain according to the node matrix set includes: obtaining the computational complexity of each network function in the target service chain, where the computational complexity is used to represent the computational resources required to process unit traffic; obtaining the compression ratio of each network function; and determining the resource allocation policy for each network function in the target service chain based on the computational complexity of each network function and the compression ratio of each network function.

[0007] Optionally, the method further includes: verifying the request message according to a pre-determined verification policy when the resource requested in the request message is in the same domain as the entity sending the request message; obtaining the security attributes between the local domain entity and the target domain entity when the resource requested in the request message is in a different domain from the entity sending the request message; and verifying the request message according to the pre-determined verification policy when the security attributes meet the preset conditions.

[0008] Optionally, the method further includes: obtaining multiple status metrics of the cloud platform host and the weight coefficient of each status metric from the log data; and determining the status score of the cloud platform host as the weighted sum of the multiple status metrics.

[0009] Optionally, the method further includes: obtaining the types of computing power tasks required for the resource allocation policy of the target service chain; determining the computing power resources required for each type of computing power task according to the mapping function corresponding to each type of computing power task; and adjusting the resource allocation policy of the target service chain according to the status score of the cloud platform host and the computing power resources required for each type of computing power task.

[0010] Optionally, the method further includes: obtaining a business process data set, where the business process data set at least includes: a service chain, request message information, and a node matrix set; training a preset large model using the business process data set to obtain an output result of the preset large model; and using the output result of the preset large model as a training data set for a preset small model to train the preset small model.

[0011] According to another aspect of the embodiments of the present application, there is also provided a cloud platform request processing apparatus, including: a generation module, configured to obtain log data from multiple levels of the cloud platform and generate multiple service chains according to the log data, where the service chain is used to represent a network function link required to process the request message, and the multiple levels at least include: a user access layer, an access control layer, a resource service management and auditing layer, and an application service management layer; a receiving module, configured to receive a request message, and in response to the request message, select a target service chain that matches the request message from the multiple service chains; an obtaining module, configured to obtain a resource allocation policy of the target service chain; and a processing module, configured to, when the request message passes verification, process the request message according to the resource allocation policy of the target service chain for the target service chain.

[0012] According to yet another aspect of the embodiments of the present application, there is also provided a computer device, including: a memory and a processor, where the memory is used to store program instructions; and the processor, connected to the memory, is configured to execute the above-mentioned cloud platform request processing method.

[0013] According to still another aspect of the embodiments of the present application, there is also provided a non-volatile storage medium, where the non-volatile storage medium includes a stored computer program, and the device where the non-volatile storage medium is located executes the above-mentioned cloud platform request processing method by running the computer program.

[0014] According to still another aspect of the embodiments of the present application, there is also provided a computer program product, including computer instructions, and when the computer instructions are executed by a processor, the above-mentioned cloud platform request processing method is implemented.

[0015] In an embodiment of the present application, log data is obtained from multiple levels of a cloud platform, and multiple service chains are generated based on the log data, where the service chains are used to represent network function links required for processing request messages, and the multiple levels at least include: a user access layer, an access control layer, a resource service management and auditing layer, and an application service management layer; a request message is received, and in response to the request message, a target service chain matching the request message is selected from the multiple service chains; a resource allocation policy of the target service chain is obtained; when the request message passes verification, for the target service chain, the request message is processed according to the resource allocation policy of the target service chain, thereby achieving the purpose of not only allocating the resources required by the service chain of the request message according to the resource allocation policy of the service chain but also eliminating the request messages that do not pass verification through verification, and thus achieving the technical effect of accurately allocating resource usage, and further solving the technical problem of uneven resource allocation in the process of processing request messages in related technologies. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0017] Figure 1 is a hardware structure block diagram of a computer terminal for implementing a cloud platform request processing method according to an embodiment of the present application;

[0018] Figure 2 is a flowchart of a cloud platform request processing method according to an embodiment of the present application;

[0019] Figure 3 is a schematic diagram of service link resource allocation according to an embodiment of the present application;

[0020] Figure 4 is a flowchart of request message verification according to an embodiment of the present application;

[0021] Figure 5 is another flowchart of request message verification according to an embodiment of the present application;

[0022] Figure 6 is a structural diagram of a cloud platform request processing device according to an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

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

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

[0025] The information collected in the embodiments of this application is information and data authorized by the user or fully authorized by all parties. Moreover, the processing of relevant data, such as collection, storage, use, processing, transmission, provision, disclosure, and application, complies with the relevant laws, regulations, and standards of the relevant regions, takes necessary confidentiality measures, does not violate public order and good customs, and provides corresponding operation entrances for users to choose to authorize or reject the automated decision results; if the user chooses to reject, the expert decision-making process will be entered.

[0026] To solve the problems existing in the related art, the embodiments of this application provide a method for processing cloud platform requests, and this method can run on Figure 1 the computer terminal shown below. The following is an explanation of this computer terminal.

[0027] The method embodiments for processing cloud platform requests provided by the embodiments of this application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Figure 1 The following shows a hardware structure block diagram of a computer terminal for implementing the method for processing cloud platform requests. As Figure 1As shown, the computer terminal 10 may include one or more processors (illustrated as 102a, 102b, ……, 102n in the figure) (the processor may include, but is not limited to, processing devices such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission module 106 for communication functions connected through wired and / or wireless networks. In addition, it may further include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. Those of ordinary skill in the art can understand that Figure 1 the structure shown is only schematic and does not limit the structure of the above-mentioned electronic device. For example, the computer terminal 10 may further include more or fewer components than Figure 1 shown in, or have a different configuration from Figure 1 that shown.

[0028] It should be noted that the above one or more processors and / or other data processing circuits are generally referred to as "data processing circuits" herein. The data processing circuit may be embodied in software, hardware, firmware, or any combination thereof, in whole or in part. In addition, the data processing circuit may be a single independent processing module, or be incorporated in whole or in part into any one of other elements in the computer terminal 10. As involved in the embodiments of the present application, the data processing circuit is a kind of processor control (such as the selection of a variable resistance terminal path connected to an interface).

[0029] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the cloud platform request processing method in the embodiments of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, implements the above-mentioned cloud platform request processing method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memories. In some instances, the memory 104 may further include a memory remotely set relative to the processor, and these remote memories can be connected to the computer terminal 10 through a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0030] The transmission module 106 is used to receive or send data via a network. Specific examples of the above-mentioned network may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission module 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission module 106 can be a Radio Frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0031] The display can be, for example, a touch-screen liquid crystal display (LCD), which enables the user to interact with the user interface of the computer terminal 10.

[0032] It should be noted here that in some alternative embodiments, the above Figure 1 illustrated computer terminal may include hardware elements (including circuits), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware elements and software elements. It should be pointed out that Figure 1 is only an example of a specific specific instance and is intended to show the types of components that may exist in the above computer terminal.

[0033] Under the above operating environment, an embodiment of a cloud platform request processing method is provided in an embodiment of the present application. It should be noted that the steps illustrated in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is illustrated in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0034] Figure 2 is a flowchart of a cloud platform request processing method according to an embodiment of the present application. As Figure 2 shown, the method includes the following steps:

[0035] Step S202, obtaining log data from multiple levels of the cloud platform, and generating multiple service chains according to the log data, where the service chain is used to represent the network function link required to process the request message, and the multiple levels at least include: a user access layer, an access control layer, a resource service management and auditing layer, and an application service management layer;

[0036] In step S202, the user access layer (User Interface Layer, UIL) is used to process the interaction between the user terminal and the cloud platform;

[0037] The Access Control Layer (ACL) is used for authentication, authorization, and privilege management;

[0038] The Resource Service Management and Audit Layer (RSL) is used to provide specific resource services and resource audits;

[0039] The Service Management Layer (SML) is used for invoking resources in the Resource Service Management and Audit Layer and for storing and invoking data in the database.

[0040] Step S204: Receive a request message. In response to the request message, select a target service chain that matches the request message from the multiple service chains;

[0041] Step S206: Obtain the resource allocation policy of the target service chain;

[0042] Step S208: When the request message passes verification, for the target service chain, process the request message according to the resource allocation policy of the target service chain.

[0043] Through the above steps S202 to S208, log data is obtained from multiple levels of the cloud platform, and multiple service chains are generated based on the log data. Among them, the service chain is used to represent the network function link required to process the request message. The multiple levels at least include: the user access layer, the access control layer, the resource service management and audit layer, and the service management layer; receive a request message, in response to the request message, select a target service chain that matches the request message from the multiple service chains; obtain the resource allocation policy of the target service chain; when the request message passes verification, for the target service chain, process the request message according to the resource allocation policy of the target service chain, thereby achieving the purpose of not only allocating the resources required by the service chain of the request message according to the resource allocation policy of the service chain but also eliminating the request messages that do not pass verification through verification, and thus achieving the technical effect of accurately allocating resource usage, and further solving the technical problem of uneven resource allocation in the process of processing request messages in the related art. The following is a detailed description.

[0044] In some embodiments of the present application, the specific steps for obtaining the resource allocation policy of the target service chain are as follows: Obtain the association relationship between the database, middleware, and server performance metrics required by the network functions included in the target service chain from the log data; construct a topology graph according to the association relationship, where the edges in the topology graph are used to represent the association relationship between the database, middleware, and server performance metrics, and the nodes in the topology graph are used to represent the database, middleware, and server performance metrics; obtain the data set corresponding to each node in the topology graph from the log data, where the data set of each node includes node data in different time dimensions; respectively form sub-matrices by combining each node in the topology graph with the data set of each node, and combine multiple sub-matrices into a node matrix set; determine the resource allocation policy of the target service chain according to the node matrix set.

[0045] Specifically, in order to prevent the storage space occupied by the log data from being too large, the log data is analyzed in two layers. Among them, in the first layer, the topology graph is determined by using the log service for the association relationship in the database corresponding to the service chain (database, middleware, server basic monitoring metrics). The topology graph records the relationship between three types of metrics (database, middleware, server performance metrics) among different servers, where the server performance metrics include: CPU usage rate, memory usage rate, disk usage rate, and process usage rate.

[0046] In the second layer, mine the data of each node in the first layer from each log data, which records the monitoring data and operating conditions between the server and the database, middleware, server CPU, memory, disk, and process in different time dimensions.

[0047] Form a sub-matrix by combining the current node with the nodes associated with (database, middleware, server CPU, memory, disk, process) in the first layer, and multiple sub-matrices form a node matrix set. Determine the data chain based on the node matrix set, and annotate the data chain with an identifier. The data chain identifier can quickly locate the call index identifier of each link and associated data.

[0048] In some embodiments of the present application, the specific steps for determining the resource allocation policy of the target service chain according to the node matrix set are: obtain the computational complexity of each network function in the target service chain, where the computational complexity is used to represent the computational resources required to process unit traffic; obtain the compression ratio of each network function; determine the resource allocation policy of each network function in the target service chain based on the computational complexity of each network function and the compression ratio of each network function.

[0049] Specifically, the network functions involved in the execution request message and the link order of the involved network functions can be obtained from the node matrix set, and a service chain is generated based on the link order of the involved network functions.

[0050] The network functions include but are not limited to firewalls, NAT, proxies, deep packet inspection, and WAN optimization functions. These software-based network functions can run on hardware with VNF (Virtual Network Function). However, network functions are usually linked together, and in this case, data packets need to go through a series of network function processing during the forwarding process. If the computing resource allocation between the upstream network function and the downstream network function in the service chain is unreasonable, such as the throughput of the upstream network function being greater than that of the downstream network function, in this case, the bottleneck network function may discard the data packets that have been processed by the upstream network function, resulting in a serious performance decline. The computing resources of the upstream are wasted. Just as hardware switches and routers provide rate-proportional scheduling for data packet flows.

[0051] As Figure 3 shown, the user request will sequentially pass through three network functions: VNF 1 , VNF 2 and VNF 3 ; C 1 , C 2 points and C 3 respectively represent the computational complexity of the network functions. When the request message rate is F, the computing resources required by VNF 1 are FC 1 . For VNF 2 , the optimal computing resource allocation is not simply FC 2 , because the upstream network function does not simply forward data like a router or a switch, but will affect the size of the data flow. The compression ratio of VNF 1 is r 1 , the compression ratio of VNF 2 is r 2 , then the data size flowing into the network function VNF 2 is r 1 F, and the optimal resource allocation strategy indicates that the allocated computing resources are r 1 FC 2 , and so on. The computing resources required by the network function VNF 3 are r 1 r 2 FC 3According to this allocation scheme, the upstream and downstream network functions of the service chain can cooperate with each other without obvious bottlenecks. When the user request changes, it is only necessary to change the size of the computing resources allocated to each network function in the same proportion. For example, in the above example, the perfect ratio of computing resources allocated to each network function is C 1 :r 1 C 2 :r 1 r 2 C 3 .

[0052] The solution for computing resource allocation in the service chain is obtained by calculating the network function computing complexity and traffic compression ratio. However, this method is based on the premise that the performance of each data packet is predictable. In actual situations, the following problems may occur:

[0053] 1. Before the service chain is deployed and operated, the network function management scheduler does not know the a priori capabilities, capacity or processing requirements of each network function.

[0054] 2. The packet cost of the same class of requests is variable (e.g., some packets may need to trigger a DNS lookup, while others may only require a simple header match).

[0055] 3. In different hardware environments, allocating the same computing resources may result in different throughputs.

[0056] Therefore, the network function virtualization manager should be able to adjust the resource allocation strategy in real time when processing each data packet. To solve these problems, the CPU allocation strategy can be adjusted through the preset management framework so that the strategic computing resources can be reasonably allocated according to the packet arrival rate and the required computing resources. Service chain-level congestion control is achieved by using a reasonable resource allocation strategy, and the packet loss caused by the downstream network function can be avoided through the real-time feedback mechanism of the downstream network function to the upstream network function.

[0057] Figure 4 A request message verification flow chart is shown, such as Figure 4 As shown,

[0058] Step 1: The user initiates a request. This is the start of the entire process. The user submits an access request through the interface of the cloud platform. This can be a login request, a data reading request, a service call request, etc. Step 2: The server performs attribute verification. After receiving the request, the server first performs attribute verification in the access control layer (ACL). This includes verifying the user's identity information, permissions, the attributes of the requested resources, and the context information of the request. For example, the server will check whether the user exists in the system, whether the user has permission to access the requested resources, and whether the resources are in an available state. Step 3: The server queries the database. If the attribute verification passes, the server will query the relevant database to obtain the detailed data or service information required by the request. This may be to determine the user's specific permissions, the current state of the resources, or to call a specific service. Step 4: The server returns the database query result. After the database query is completed, the server will return the query result to the next step in the request processing flow. This may include user permission information, the availability of resources, service configuration parameters, etc. Step 5: The server determines whether the request is legal. The server will comprehensively determine whether the user request is legal based on the information in the previous steps. This includes not only whether the permissions match, but may also include a compliance check on the request behavior, such as whether it conforms to the pre-set security policies. Step 6: If the request is legal, the server builds the cloud platform and executes the request. If the request is determined to be legal, the server will build or call the corresponding service resources on the cloud platform to execute the user request. For example, if it is a request to access a certain database, the server will ensure that the database service has been started and is ready to handle subsequent data reading and writing operations. Step 7: The server returns the database operation result. After the request execution is completed, the server will return the operation result to the user. This may be the result of data reading, the status of service call, the success or failure information of the operation, etc.

[0059] It should be noted that the user access layer provides corresponding access interfaces for users. They can access the enterprise information management system published on the cloud computing platform through browsers on terminal devices such as computers, mobile phones, or PDAs. When ordinary users log in to the system, they only need to enter the pre-assigned account and password, while managers have the permission to modify sensitive and key data of the system. To further ensure the security of system data, identity authentication is combined with U-Key to further authenticate the user identity on the basis of hardware, ensuring the legality of the user's behavior of accessing the system. The user access layer mainly includes 3 modules, namely: identity authentication management, user addition, and user basic information management. Through these 3 modules, the system user information is set and managed, and their identity authentication is carried out.

[0060] The access control layer is the core module of the enterprise information system. The access requests of users are mainly judged and determined through this layer. The main modules of this layer are: Policy Enforcement Point (PEP), Policy Information Point (PIP), Policy Decision Point (PDP), Policy Administration Point (PAP), and policy library. After receiving the access request of the user, the PEP module first obtains the relevant attribute information and context information from the PIP module, and based on this information, returns a decision result according to the policy requirements of the PDP module to determine whether to allow the access request of this user. During the operation of the entire system, the policy rules set by this layer are adjusted with the changes of the entire system and the attributes of users and resources. The PAP module timely feedbacks the policy information in the policy library to the PDP module to ensure the real-time nature of access control.

[0061] In the process of verification using the access control layer, when the resource requested in the request message and the entity sending the request message are in the same domain, the request message is verified according to the pre-determined verification policy; when the resource requested in the request message and the entity sending the request message are in different domains, the security attributes between the local domain entity and the target domain entity are obtained; when the security attributes meet the preset conditions, the request message is verified according to the pre-determined verification policy.

[0062] It should be noted that the entity includes but is not limited to: user terminal and application program.

[0063] As Figure 5 shown, first, it is judged in the PEP whether the subject and the resource involved in the request are in the same virtual machine (i.e., the local domain). If this condition is met (flag = 1), after receiving the access request, the PDP module makes a judgment according to the obtained policy and returns a judgment result; otherwise, first, the security between the different virtual machines where the subject and the resource are located (i.e., cross-domain) is judged. If the attributes between the virtual machines meet the requirements, the subject and resource attributes in different virtual machines are aggregated in the PEP and then sent to the PDP, and the PDP makes an attribute judgment and returns the result. During the entire judgment process, once a condition is not met, the access request of the subject will be rejected.

[0064] Specifically, when the subject and the resource are within the same virtual machine (local domain), when the PEP receives an access request, it first checks whether the subject (such as a user, an application) and the resource (such as a file, a database, a service) involved in the request are located in the same virtual machine (VM). This check is based on the rules and policies within the virtual machine, aiming to confirm whether the access request occurs within the local domain, which means the access will not involve cross-virtual machine or network communication. If the request is indeed within the local domain (flag = 1), the PEP passes the request information to the PDP module. The PDP evaluates the request according to a predefined set of policies and rules to determine whether the subject has the permission to access a specific resource. This process may involve checking attributes such as the identity, role, time, location of the subject, as well as the access control list (ACL), security label, etc. of the resource. Once the PDP completes the evaluation, it feeds back a "permit" or "deny" decision to the PEP, and the PEP then notifies the subject that initiated the access request of this result. When the subject and the resource are located between different virtual machines (cross-domain), if the PEP detects that the subject and the resource are in different virtual machines, the process is different. First, the PEP will not make a decision immediately, but conduct a cross-domain security check, which involves evaluating the security attributes and policies between the virtual machines where the subject and the target resource are located to ensure that the cross-virtual machine access is secure and permitted. If the cross-domain check passes (safe = 1), that is, the security attributes and policies between the virtual machines where the subject and the resource are located meet the requirements, the PEP collects the attribute information of the subject and the resource from all the involved virtual machines. This information may include the authentication status, permission level of the subject, as well as the security label, access control policy, etc. of the resource. After integrating these attribute information, the PEP sends them to the PDP for further decision-making. After receiving the integrated information, the PDP makes a decision according to the cross-domain security policy and the attributes of the subject and the resource. Similarly, the PDP returns a "permit" or "deny" decision, and the PEP processes the access request according to this decision.

[0065] In some embodiments of the present application, a plurality of status metrics of the cloud platform host and the weight coefficient of each status metric are obtained from the log data; the weighted sum of the plurality of status metrics is determined as the status score of the cloud platform host.

[0066] Specifically, the log is a true portrayal of the operation of the computer host system. The host jointly examines the host through indicators such as memory, CPU, hard disk, surface file, network connection, etc. within a reasonable range. Beyond the range, it may indicate that the host is abnormal. The host causes a significant increase in CPU load and memory occupancy rate, but generally does not cause the system to crash; while a DoS attack will cause the connection of this host to be interrupted, a sharp increase in memory and CPU usage, and an increase in hard disk space, etc. Here, the weighted average method is used to obtain the host status score, and the calculation method of HostStatus is shown in the following formula:

[0067] HostStatus = ΣWeight i ×Service i

[0068] In the formula, Service i represents the i-th index of the host status, and Weight i represents the weight coefficient of this index. The larger the weight coefficient, the more this index can determine the host status.

[0069] In addition, in the embodiments of the present application, the optimal resource allocation strategy of the service chain is regarded as a computing power task for computing power quantification, so as to solve the resource problems caused by possible hidden login verification anomalies, and obtain the computing power task types required for the resource allocation strategy of the target service chain; determine the computing power resources required for each type of computing power task according to the mapping function corresponding to each type of computing power task type; adjust the resource allocation strategy of the target service chain according to the status score of the cloud platform host and the computing power resources required for each type of computing power task. The calculation of the computing power demand is shown in the following formula:

[0070]

[0071] In the formula, C br is the total computing power demand; f(x) is the mapping function; α i , β j and γ k are mapping proportionality coefficients; q1, q2, and q3 respectively represent different redundant computing powers. n represents the number of logical operation tasks, m represents the number of parallel computing tasks, p represents the number of neural network acceleration tasks, i, j, k respectively represent task numbers, and a i , b j , c k respectively represent the i-th logical operation task, the j-th parallel computing task, and the k-th acceleration task.

[0072] In some embodiments of the present application, a business process data set can also be obtained. The business process data set at least includes: a service chain, request message information, and a node matrix set; use the business process data set to train a preset large model to obtain the output result of the preset large model; use the output result of the preset large model as the training data set of a preset small model to train the preset small model.

[0073] Specifically, step 1: Collect and prepare data: Collect all data related to the user request, including but not limited to the service chain identifier, the specific access requirements of the user, and the resource information associated with the request. Preprocess the data, including data cleaning, formatting, and standardization, to meet the input requirements of the large model.

[0074] Step 2: First Training of the Large Model: Input the preprocessed dataset, especially service chain identifiers, user requirement information, and association information, into a pre-designed large model for training. The goal of the large model is to evaluate the legality of business processes and predict potential anomalies, and initially obtain the processing strategies and risk assessment results of business processes. This step may generate a relatively generalized result set, which may contain the verification of multiple sub-service chains due to the complexity of the business structure, so the results may not be accurate enough.

[0075] Step 3: Analysis and Screening of the Result Set: Analyze the result set generated by the large model to identify potential anomalies or inaccurate parts. Screen out the business processes or service chain identifiers that require further refined analysis, especially those complex businesses that involve the verification of sub-service chains, and prepare for the secondary training of the small model.

[0076] Step 4: Preparation of Dynamic Parameters for the Small Model: Extract service chain identifiers, user requirement information, and association information from the training result set of the large model as the input dynamic parameters for the small model. Ensure that these parameters are targeted and guiding for the subsequent training of the small model, and can help the small model more accurately evaluate the legality of business processes.

[0077] Step 5: Secondary Training of the Small Model: For the business processes that need to be refined and analyzed, use the small model containing the aforementioned screened parameters for secondary training. The training of the small model aims to subdivide and optimize the complex business structure based on the training results of the large model, and improve the accuracy of sub-service chain verification.

[0078] Step 6: Comparison and Optimization of Verification Results: Compare the verification results of the large model and the small model to evaluate the effectiveness of the secondary training of the small model. According to the comparison results, adjust the training parameters of the small model to optimize its ability to handle complex business structures and ensure the accuracy of its verification results.

[0079] Step 7: Legality Verification and Execution Decision: Combine the verification results of the large model and the small model to conduct the final legality verification and determine whether the user request is legal. If the request is legal, the system will continue to execute the subsequent business processes; if it is determined to be illegal, access will be denied to ensure the security of the system and the reasonable use of resources.

[0080] Figure 6 A cloud platform request processing device according to an embodiment of the present application, the device includes:

[0081] A generation module 60, configured to obtain log data from multiple levels of a cloud platform and generate multiple service chains according to the log data, where the service chains are used to represent network function links required for processing the request message, and the multiple levels at least include: a user access layer, an access control layer, a resource service management and auditing layer, and an application service management layer;

[0082] A receiving module 62, configured to receive a request message, and in response to the request message, select a target service chain that matches the request message from the multiple service chains;

[0083] An obtaining module 64, configured to obtain a resource allocation policy of the target service chain;

[0084] A processing module 66, configured to, when the request message passes verification, process the request message according to the resource allocation policy of the target service chain for the target service chain.

[0085] Through the above cloud platform request processing device, log data is obtained from multiple levels of the cloud platform, and multiple service chains are generated according to the log data, where the service chains are used to represent network function links required for processing the request message, and the multiple levels at least include: a user access layer, an access control layer, a resource service management and auditing layer, and an application service management layer; a request message is received, and in response to the request message, a target service chain that matches the request message is selected from the multiple service chains; a resource allocation policy of the target service chain is obtained; when the request message passes verification, for the target service chain, the request message is processed according to the resource allocation policy of the target service chain, so as to achieve the purpose of not only allocating the resources required by the service chain of the request message according to the resource allocation policy of the service chain, but also eliminating the request messages that do not pass verification through verification, thereby realizing the technical effect of accurately allocating resource usage, and further solving the technical problem of uneven resource allocation in the process of processing request messages in the related art.

[0086] The acquisition module 64 includes: an acquisition sub-module, configured to acquire the resource allocation policy of the target service chain, including: acquiring, from the log data, the association relationship between the database, middleware, and server performance metrics required by the network functions included in the target service chain; constructing a topology graph according to the association relationship, where the edges in the topology graph are used to represent the association relationship between the database, middleware, and server performance metrics, and the nodes in the first-layer topology graph are used to represent the database, middleware, and server performance metrics; acquiring, from the log data, the data set corresponding to each node in the topology graph, where the data set of each node includes node data in different time dimensions; respectively forming sub-matrices by combining each node in the topology graph with the data set of each node, and combining multiple sub-matrices into a node matrix set; and determining the resource allocation policy of the target service chain according to the node matrix set.

[0087] The acquisition sub-module includes: a determination unit, configured to determine the resource allocation policy of the target service chain according to the node matrix set, including: acquiring the computational complexity of each network function in the target service chain, where the computational complexity is used to represent the computational resources required to process a unit of traffic; acquiring the compression ratio of each network function; and determining the resource allocation policy of each network function in the target service chain based on the computational complexity of each network function and the compression ratio of each network function.

[0088] The cloud platform request processing device further includes: a verification sub-module, configured to, when the resource requested in the request message is in the same domain as the entity sending the request message, verify the request message according to a pre-determined verification policy; when the resource requested in the request message is in a different domain from the entity sending the request message, acquire the security attributes between the local domain entity and the target domain entity; and when the security attributes meet the preset conditions, verify the request message according to the pre-determined verification policy.

[0089] The cloud platform request processing device further includes: a status sub-module, configured to acquire multiple status metrics of the cloud platform host and the weight coefficient of each status metric from the log data; and determine the status score of the cloud platform host as the weighted sum of the multiple status metrics.

[0090] The status sub-module further includes: a computing power unit, configured to acquire the computing power task types required for the resource allocation policy of the target service chain; determine the computing power resources required for each type of computing power task according to the mapping function corresponding to each type of computing power task type; and adjust the resource allocation policy of the target service chain according to the status score of the cloud platform host and the computing power resources required for each type of computing power task.

[0091] The computing power unit includes: a model subunit, which is used to obtain a business process dataset, and the business process dataset at least includes: a service chain, request message information, and a node matrix set; training a preset large model with the business process dataset to obtain an output result of the preset large model; using the output result of the preset large model as a training dataset for a preset small model to train the preset small model.

[0092] It should be noted that Figure 6 the shown cloud platform request processing device is used to execute Figure 2 the shown cloud platform request processing method. Therefore, the relevant explanations in the above cloud platform request processing method also apply to this cloud platform request processing device, and will not be elaborated here.

[0093] An embodiment of this application also provides a computer device, including: a memory and a processor. Among them, the memory is used to store program instructions; the processor, connected to the memory, is used to execute the above cloud platform request processing method.

[0094] An embodiment of this application also provides a non-volatile storage medium, which includes a stored computer program. Among them, the device where the non-volatile storage medium is located executes the above cloud platform request processing method by running the computer program.

[0095] An embodiment of this application also provides a computer program product, including computer instructions, and when the computer instructions are executed by a processor, the steps of the cloud platform request processing method in this application are implemented.

[0096] The serial numbers of the above embodiments of this application are only for description and do not represent the advantages or disadvantages of the embodiments.

[0097] In the above embodiments of this application, the descriptions of each embodiment have their own focuses. For parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

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

[0099] The unit described as a separation component may or may not be physically separated. The component shown as a unit may or may not be a physical unit, that is, it may be located in one place or may be distributed to multiple units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

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

[0101] If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to enable a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present application. The aforementioned storage medium includes: USB flash drive, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disc and other various media that can store program codes.

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

Claims

1. A cloud platform request processing method, characterized in that: include: Obtain log data from multiple layers of the cloud platform, and generate multiple service chains based on the log data, wherein the service chains are used to represent network function links required to process request messages, and the multiple layers at least include: a user access layer, an access control layer, a resource service management and audit layer, and an application service management layer; receiving a request message, and in response to the request message, selecting a target service chain matching the request message from the multiple service chains; Acquire a resource allocation strategy for the target service chain; In the case that the request message passes the verification, for the target service chain, the request message is processed according to the resource allocation policy of the target service chain.

2. The method according to claim 1, characterized in that Obtaining a resource allocation strategy for the target service chain includes: Acquire, from the log data, associations between databases, middleware, and server performance indicators required for network functions included in the target service chain; Constructing a topology graph according to the association relationship, wherein the edges in the topology graph are used to represent the association relationship between the database, the middleware and the server performance indicator, and the nodes in the topology graph are used to represent the database, the middleware and the server performance indicator; Acquire a data set corresponding to each node in the topology map from the log data, wherein the data set of each node includes node data under different time dimensions; Each node in the topology graph and the data set of each node are respectively formed into sub-matrices, and a plurality of sub-matrices are combined into a node matrix set; A resource allocation strategy for the target service chain is determined according to the node matrix set.

3. The method according to claim 2, characterized in that Determining a resource allocation strategy of the target service chain according to the node matrix set includes: Obtaining a computational complexity of each network function in the target service chain, where the computational complexity is used to represent the computational resources required to process a unit flow; Obtaining a compression ratio of each network function; A resource allocation strategy for each network function in the target service chain is determined based on the computational complexity of each network function and the compression ratio of each network function.

4. The method according to claim 1, characterized in that: The method further comprises: If the resource requested in the request message and the entity sending the request message are in the same domain, verifying the request message according to a predetermined verification policy; When the resource requested in the request message and the entity sending the request message are in different domains, obtaining security attributes between the local domain entity and the target domain entity; In the case where the security attribute meets the preset condition, the request message is verified according to the previously determined verification strategy.

5. The method according to claim 1, characterized in that The method further comprises: Acquire multiple status indicators of the cloud platform host and a weight coefficient of each status indicator from the log data; A weighted sum of the multiple status indicators is determined as the status score of the cloud platform host.

6. The method according to claim 5, characterized in that The method further comprises: Obtaining the computing power task type required by the resource allocation strategy of the target service chain; Determine the computing resources required for each type of computing task based on the mapping function corresponding to each type of computing task; The resource allocation strategy of the target service chain is adjusted according to the status score of the cloud platform host and the computing resources required for each type of computing tasks.

7. The method according to claim 6, characterized in that The method further comprises: Acquire a business process data set, wherein the business process data set at least includes: a service chain, request message information, and a node matrix set; Using the business process data set to train a preset large model to obtain an output result of the preset large model; The output result of the preset large model is used as a training data set of the preset small model to train the preset small model.

8. A cloud platform request processing device, characterized in that: include: A generation module, used to obtain log data from multiple layers of the cloud platform, and generate multiple service chains according to the log data, wherein the service chain is used to represent the network function link required to process the request message, and the multiple layers at least include: a user access layer, an access control layer, a resource service management and audit layer, and an application service management layer; A receiving module, configured to receive a request message, and select, in response to the request message, a target service chain matching the request message from the multiple service chains; An acquisition module, used to acquire the resource allocation strategy of the target service chain; The processing module is used to process the request message according to the resource allocation policy of the target service chain for the target service chain when the request message passes the verification.

9. A computer device, characterized in that: include: A memory and a processor, wherein the memory is used to store program instructions; the processor, connected to the memory, is used to execute the cloud platform request processing method described in any one of claims 1 to 7.

10. A computer program product comprising computer instructions, characterized in that When the computer instructions are executed by the processor, the cloud platform request processing method described in any one of claims 1 to 7 is implemented.

Images