A cloud computer service operation method and device and electronic equipment

Abstract

Embodiments of the present application disclose a cloud computer service operation method and device and electronic equipment, and relate to the technical field of computer application, and are invented to reduce cross-network redundancy during service processing and improve service processing efficiency. The method comprises the following steps: receiving a service request sent by a client; wherein the service request comprises service operation object information; determining a first target application service corresponding to the service operation object information according to the service operation object information in the service request; the first target application service acquires a token corresponding to the client from a storage module of the cluster; and the first target application service determines whether to perform a service operation corresponding to the service request according to user permission information in the token. The present application is suitable for service processing.

Description

Technical Field

[0001] This application relates to the field of computer application technology, and in particular to a cloud computer service operation method, apparatus, electronic device and readable storage medium. Background Technology

[0002] Cloud PC solutions based on clusters (such as Kubernetes environments) are widely used in multi-user scenarios due to their advantages such as high resource utilization, flexible deployment, and strong scalability. The current mainstream architecture adopts the "single Pod integrated full-featured" model, which encapsulates the underlying operating system functions such as kernel, drivers, desktop, and front-end applications into a single Pod, simplifying deployment and operation and maintenance processes.

[0003] In multi-user scenarios, clients need to connect to cloud computers through identity authentication, and calls between services (desktop services, driver services, etc.) within a cloud computer Pod require permission control based on user identity. Tokens, as core identity credentials, are crucial. However, in existing technologies, when processing business on cloud computers, inter-service calls suffer from cross-network redundancy, resulting in low business processing efficiency. Summary of the Invention

[0004] In view of this, embodiments of this application provide a cloud computer service operation method, apparatus, electronic device, and readable storage medium, which can reduce cross-network redundancy during service processing and improve service processing efficiency.

[0005] In a first aspect, embodiments of this application provide a cloud computer service operation method, wherein the cloud computer runs in a container of a cluster; the method includes: receiving a service request sent by a client; wherein the service request includes service operation object information; determining a first target application service corresponding to the service operation object information based on the service operation object information in the service request; the first target application service obtaining a token corresponding to the client from the storage module of the cluster; and the first target application service determining whether to execute a service operation corresponding to the service request based on user permission information in the token.

[0006] According to a specific implementation of an embodiment of this application, before receiving a service request sent by a client, the method further includes: establishing a long-connection communication link with the client; wherein, receiving the service request sent by the client includes: receiving the service request sent by the client based on the long-connection communication link; the first target application service obtaining a token corresponding to the client from the storage module of the cluster includes: the first target application service determining a token identifier corresponding to the client based on the long-connection communication link; the first target application service obtaining a token corresponding to the token identifier from the storage module of the cluster according to the token identifier.

[0007] According to a specific implementation of an embodiment of this application, establishing a long-term communication link with the client includes: receiving a first connection request sent by the client; the first connection request includes a token; verifying the status of the token; and if the verification passes, establishing a long-term communication link with the client.

[0008] According to a specific implementation of an embodiment of this application, the step of verifying the status of the token includes: using a local public key to verify the token; if the token verification passes, querying the status of the token in the storage module; and verifying the status of the token.

[0009] According to a specific implementation of an embodiment of this application, determining the first target application service corresponding to the business operation object information in the business request includes: determining the first target application service and the second target application service corresponding to the business operation object information in the business request; the method further includes: when the first target application service performs a business operation corresponding to the business request, invoking the second target application service; the second target application service obtains a token corresponding to the client from the storage module of the cluster; the second target application service determines whether to perform the business operation corresponding to the business request based on the user permission information in the token.

[0010] According to a specific implementation of an embodiment of this application, before receiving a first connection request sent by a client, the method further includes: a token creation service in the cluster receiving a second connection request sent by a client; the second connection request including client information; obtaining user permissions from the storage module based on the client information; allocating a target cloud computer to the client; generating a token corresponding to the client and a token identifier corresponding to the token based on the connection information of the target cloud computer, the client information, and the user permissions; storing the token and the token identifier in the storage module, and sending the token to the client.

[0011] According to a specific implementation of an embodiment of this application, the client information includes client device information; the token creation service in the cluster receives a second connection request sent by the client, including: the gateway receiving the second connection request sent by the client and performing a validity check on the client device information in the second connection request; if the check passes, the gateway sends the second connection request to the token creation service; the token creation service receives the second connection request forwarded by the gateway.

[0012] According to a specific implementation of an embodiment of this application, the client information further includes user information; wherein, the step of obtaining user permissions from the storage module based on the client information includes: verifying the user information in the second connection request; if the verification passes, obtaining permission information corresponding to the client from the storage module.

[0013] According to a specific implementation of an embodiment of this application, the method further includes: a monitoring service in the cluster monitoring the connection status between the client and the cloud computer; if the connection between the client and the cloud computer is lost, the token management service in the cluster destroys the token corresponding to the client in the storage module.

[0014] According to a specific implementation of an embodiment of this application, the method further includes: monitoring whether the client's token has expired based on the expiration time in the token; if the client's token has expired, the token management service in the cluster cleans up the client's token.

[0015] Secondly, embodiments of this application provide a cloud computer service operation device, wherein the cloud computer runs in a container of a cluster; the device includes: a first receiving module, configured to receive a service request sent by a client; wherein the service request includes service operation object information; a first determining module, configured to determine a first target application service corresponding to the service operation object information based on the service operation object information in the service request; a first obtaining module, configured to obtain a token corresponding to the client from the storage module of the cluster through the first target application service; and a second determining module, configured to determine whether to execute the service operation corresponding to the service request based on the user permission information in the token through the first target application service.

[0016] According to a specific implementation of an embodiment of this application, the apparatus further includes: an establishment module, configured to establish a long-connection communication link with the client before the receiving module receives a service request sent by the client; wherein, the first receiving module is specifically configured to: receive a service request sent by the client based on the long-connection communication link; the first acquisition module is specifically configured to determine a token identifier corresponding to the client through the first target application service based on the long-connection communication link; the first target application service acquires a token corresponding to the token identifier from the storage module of the cluster according to the token identifier.

[0017] According to a specific implementation of an embodiment of this application, the establishment module is specifically used to receive a first connection request sent by a client; the first connection request includes a token; the status of the token is verified; if the verification passes, a long-term connection communication link is established with the client.

[0018] According to a specific implementation of an embodiment of this application, the establishment module is specifically used to verify the token using a local public key; if the token verification is successful, the status of the token in the storage module is queried; and the status of the token is verified.

[0019] According to a specific implementation of an embodiment of this application, the first determining module is specifically used to determine a first target application service and a second target application service corresponding to the business operation object information in the business request; the device further includes: a calling module, used to call the second target application service when the first target application service performs a business operation corresponding to the business request; a second obtaining module, used to obtain a token corresponding to the client from the storage module of the cluster through the second target application service; and a third determining module, used to determine whether to execute the business operation corresponding to the business request based on the user permission information in the token through the second target application service.

[0020] According to a specific implementation of an embodiment of this application, the apparatus further includes: a second receiving module, configured to receive a second connection request sent by the client through a token creation service in the cluster before the establishment module receives the first connection request sent by the client; the second connection request includes client information; a third obtaining module, configured to obtain user permissions from the storage module based on the client information; an allocation module, configured to allocate a target cloud computer to the client; a generation module, configured to generate a token corresponding to the client and a token identifier corresponding to the token based on the connection information of the target cloud computer, the client information, and the user permissions; and a sending module, configured to store the token and the token identifier in the storage module and send the token to the client.

[0021] According to a specific implementation of an embodiment of this application, the client information includes client device information; the second receiving module is specifically configured to: receive a second connection request sent by the client through a gateway and perform a validity check on the client device information in the second connection request; if the check passes, send the second connection request to the token creation service; the token creation service receives the second connection request forwarded by the gateway.

[0022] According to a specific implementation of an embodiment of this application, the client information further includes user information; wherein, the third acquisition module is specifically used to: verify the user information in the second connection request; if the verification passes, obtain the permission information corresponding to the client from the storage module.

[0023] According to a specific implementation of an embodiment of this application, the device further includes: a monitoring module, used to monitor the connection status between the client and the cloud computer through a monitoring service in the cluster; and a destruction module, used to destroy the token corresponding to the client in the storage module if the connection between the client and the cloud computer is lost, by a token management service in the cluster.

[0024] According to a specific implementation of an embodiment of this application, the apparatus further includes: a monitoring module, configured to monitor whether the client's token has expired based on the expiration time in the token; and a cleanup module, configured to clean up the client's token if the client's token has expired, configured to clean up the client's token by a token management service in the cluster.

[0025] Thirdly, embodiments of this application provide an electronic device, the electronic device comprising: a processor and a memory, wherein the memory is used to store executable program code; the processor runs a program corresponding to the executable program code by reading the executable program code stored in the memory, for executing the cloud computer service operation method described in any of the foregoing implementations.

[0026] Fourthly, embodiments of this application provide a computer-readable storage medium storing one or more programs, which can be executed by one or more processors to implement the cloud computer service operation method described in any of the foregoing implementations.

[0027] The cloud computer service operation method, apparatus, electronic device, and readable storage medium of this embodiment receive a service request sent by a client. Based on the service operation object information in the service request, a first target application service corresponding to the service operation object information is determined. Thus, the first target application service can obtain a token corresponding to the client from the storage module of the cluster. Based on this, the first target application service determines whether to execute the service operation corresponding to the service request according to the user permission information in the token. Since the first target application service obtains the token corresponding to the client from the storage module of the cluster, other services in the cloud computer do not need to send tokens to the first target application service, that is, there is no need for tokens to be passed between services of the cloud computer. This reduces cross-network redundancy during service processing and improves service processing efficiency. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 A flowchart illustrating a cloud computer service operation method provided in an embodiment of this application; Figure 2 This is an overall architecture diagram of the client and cluster provided in one embodiment of this application; Figure 3 A schematic diagram illustrating the token usage process provided in one embodiment of this application; Figure 4 A schematic diagram illustrating the token creation process provided in one embodiment of this application; Figure 5 This is a schematic diagram of the structure of a cloud computer service operation device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] The embodiments of this application will now be described in detail with reference to the accompanying drawings. It should be understood that the described embodiments are merely some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0031] To enable those skilled in the art to better understand the technical concept, implementation scheme and beneficial effects of the embodiments of this application, detailed descriptions are provided below through specific embodiments.

[0032] Figure 1 This is a flowchart illustrating a cloud computer service operation method provided in an embodiment of this application, as shown below. Figure 1 As shown in this embodiment, the cloud computer service operation method, in which the cloud computer runs in a container within a cluster, includes: S101, Receive the service request sent by the client.

[0033] like Figure 2 In the illustrated embodiment, the cluster can be Kubernetes (K8s for short), which is an open-source container orchestration platform used to automate the deployment, scaling, and management of containerized applications.

[0034] A cluster includes containers, within which cloud computers run. For example, cloud computers run within Kubernetes container Pods. A Pod is the smallest unit of deployment in Kubernetes, containing one or more tightly coupled containers that share network namespaces and storage resources. In some examples, a cloud computer runs within a Pod; in this case, the Pod and the cloud computer running on it can be referred to as a cloud computer Pod. A cluster can include multiple Pods, such as... Figure 2 In the illustrated embodiment, the cluster includes cloud computer Pod1, cloud computer Pod2, and cloud computer Pod3.

[0035] The cluster in this embodiment supports horizontal scaling of cloud PC Pods and dynamic addition of multi-tenants, adapting to the growth of enterprise user scale; it has a variety of alternative solutions, and the technology selection can be flexibly adjusted according to business scenarios (such as security requirements, bandwidth conditions, cluster size), with strong compatibility.

[0036] The underlying functions of the operating system, such as the kernel, drivers, desktop, and front-end applications, are encapsulated in a single Pod, namely the cloud PC Pod. In this embodiment, the cloud PC Pod adopts the "single Pod integrating full functions" mode, which simplifies the deployment and maintenance process.

[0037] The computing, storage, and applications of a cloud computer all run on cloud servers, while the local device in front of the user (which can be a regular computer, tablet, mobile phone, or even a TV) is only responsible for displaying the screen and sending operation commands.

[0038] Users can operate the cloud computer through clients such as Tarui.

[0039] Users can operate the client to perform related tasks and send operation requests, including information about the target object, to the cloud computer. In this embodiment, the operation request includes information about the target object.

[0040] For example, if a user wants to save a file on their desktop on the client side, the business operation object information includes the file's location, file name, file content, and so on.

[0041] S102. Based on the business operation object information in the business request, determine the first target application service corresponding to the business operation object information.

[0042] In cloud computing, business operations on business operation object information require corresponding application services to complete. After receiving the business operation object information, the information is parsed to determine the application service corresponding to the information, i.e., the target application service.

[0043] In the specific scenario described above, the first target application service can be a desktop service.

[0044] S103. The first target application service obtains the token corresponding to the client from the cluster's storage module.

[0045] The cluster's storage module is specifically the Kubernetes storage layer, namely Redis Cluster, which implements persistent storage.

[0046] The cluster's storage module pre-stores the tokens corresponding to the clients. The first target application service can retrieve the tokens corresponding to the clients that sent the business requests from the storage module.

[0047] The first target application service calls the storage module's interface to obtain a token from the storage module. The communication between the first target application service and the storage module is an internal network call, thus avoiding cross-network redundancy.

[0048] S104. The first target application service determines whether to execute the business operation corresponding to the business request based on the user permission information in the token.

[0049] The token contains user permission information. Before executing a business operation, the first target application service needs to determine whether to execute the business operation corresponding to the business request based on the user permission information.

[0050] Permission information (levels) can include administrators (admin), users (user), and visitors (visitor). Each has different permissions. For example, administrators have the highest permissions and are responsible for system settings, account management, resource allocation, etc. Users have normal usage permissions and can log in, operate applications, and process their own files, but cannot modify system settings or manage other accounts. Visitors have limited temporary access permissions and can usually only view specific content or use basic functions. Their access time and scope are strictly limited.

[0051] In this embodiment, a business request sent by a client is received. Based on the business operation object information in the business request, a first target application service corresponding to the business operation object information is determined. Thus, the first target application service can obtain a token corresponding to the client from the cluster's storage module. Based on this, the first target application service determines whether to execute the business operation corresponding to the business request according to the user permission information in the token. Since the first target application service obtains the token corresponding to the client from the cluster's storage module, there is no need for other services in the cloud computer to send the token to the first target application service. That is, there is no need for services in the cloud computer to pass tokens to each other. This reduces cross-network redundancy during business processing and improves business processing efficiency.

[0052] To reduce operation latency and improve user experience, in some embodiments, the method of this embodiment further includes the following before receiving the service request sent by the client: S105. Establish a long-term communication link with the client.

[0053] In one specific example, the front-end application service in the cloud computer establishes a persistent communication link with the client. Persistent communication links are characterized by continuous online connectivity and low-latency communication. In this embodiment, establishing a persistent communication link between the client and the cloud computer reduces the latency of interaction between them.

[0054] The step S101, receiving the service request sent by the client, includes: S101a: Based on a long-connection communication link, receive service requests sent by the client.

[0055] Long-lived communication links enable timely and rapid reception of service requests from clients.

[0056] Long-connection communication links also have the characteristic of state preservation. Thus, after establishing a long-connection communication link, when a cloud computer receives or sends information through this link, it can identify the corresponding client; similarly, when a client receives or sends information through this link, it can identify the corresponding cloud computer. In one embodiment, step S103, where the first target application service retrieves the token corresponding to the client from the cluster's storage module, includes: S103a, The first target application service determines the token identifier corresponding to the client based on the long connection communication link.

[0057] S103b: The first target application service retrieves the token corresponding to the token identifier from the storage module of the cluster.

[0058] In some examples, the establishment of a long-lived connection communication link with the client in step S105 includes: S105a, Receive the first connection request sent by the client.

[0059] The first connection request includes a token.

[0060] like Figure 3 In the embodiment shown, the front-end application service of the cloud computer Pod receives the first connection request.

[0061] S105b: Verify the status of the token.

[0062] The status of a token includes whether it is valid, specifically whether it has expired or been revoked, etc.

[0063] In a specific example, the token's status is retrieved from the storage module, and the token's status is verified.

[0064] S105c: If the verification passes, a long-lived communication link is established with the client.

[0065] If the token is in a valid state, the verification has passed.

[0066] If the verification passes, a long-lived communication link is established with the client to facilitate subsequent interactions.

[0067] If the verification fails, there is no need to establish a long-lived communication link with the client.

[0068] In such Figure 3 In the illustrated embodiment, the front-end application service of the cloud computer Pod executes steps S105b and S105c.

[0069] To enhance connection security, in some cases, S105b verifies the token's state, including: A1. Use the local public key to verify the token.

[0070] like Figure 3 In the illustrated embodiment, the front-end application service calls the SDK module in the cloud computer to verify the token using the local public key and parse the token. It is understood that the token received in this embodiment is signed.

[0071] In one specific example, RS256 is used to perform asymmetric cryptographic signing on the token. This ensures the token is tamper-proof and cannot be forged, guaranteeing data integrity and improving security. The key is stored in the Secret of the Kubernetes cluster to prevent plaintext leakage, further enhancing the security level.

[0072] A2. If the token verification passes, query the status of the token in the storage module.

[0073] like Figure 3 In the example shown, the front-end application service queries Redis to confirm the status of the Token.

[0074] A3. Verify the status of the token.

[0075] It can determine whether the token is in a valid state.

[0076] Specifically, in step S105c, if the verification passes, a long-lived communication link is established with the client, including: B1. If the token is valid, a long-lived communication link is established with the client.

[0077] When establishing a long-lived communication link with the client, a desktop session is returned to the client, and the ID of the desktop session is set to be the same as the Token ID.

[0078] In embodiments where the business operation object information involves multiple target application services, step S102, which determines the first target application service corresponding to the business operation object information based on the business operation object information in the business request, includes: S102a. Based on the business operation object information in the business request, determine the first target application service and the second target application service corresponding to the business operation object information.

[0079] The second target application service is adjacent to the first target application service and is in the process of executing business operations. After the first target application service executes the corresponding business operation, the second target application service then executes the corresponding operation.

[0080] If the first target application service corresponding to the business operation object information is a desktop service and the second target application service is a file service, the file service will perform its corresponding business operation after the desktop service performs its own business operation.

[0081] Correspondingly, the method in this embodiment further includes: S106. If the first target application service performs the business operation corresponding to the business request, the second target application service is invoked.

[0082] In some cases, when calling a second target application service, the business operation object information is sent to the second target application service.

[0083] S107. The second target application service obtains the token corresponding to the client from the cluster's storage module.

[0084] S108. The second target application service determines whether to execute the business operation corresponding to the business request based on the user permission information in the token.

[0085] In this embodiment, before the first target application service and the second target application service execute business operations, they both obtain the token corresponding to the client from the cluster's storage module. This allows them to determine whether to execute the corresponding business operation based on the user's permission information, thus avoiding the cross-network redundancy problem caused by passing tokens between application services.

[0086] A dedicated token creation service can be set up in the cluster to create a token when a client sends a connection request. In some examples, before S105a receives the first connection request sent by the client, the method includes: S109. The token creation service in the cluster receives the second connection request sent by the client.

[0087] The second connection request includes client information.

[0088] like Figure 2In the illustrated embodiment, the token creation service does not belong to the Kubernetes cluster. like Figure 4 In the embodiment shown, the second connection request includes not only client information but also user credentials, which may be a username, user ID, and / or tenant ID.

[0089] Deploying a separate, highly available token creation service in a K8s environment can adapt to the cloud PC's "single Pod full-function integration" architecture.

[0090] S110. Obtain user permissions from the storage module based on the client information.

[0091] The storage module stores pre-set client information and corresponding user permissions.

[0092] S111: Assign a target cloud computer to the client.

[0093] The token creation service allocates a cloud computer to the client that sends the connection request based on the running status of each cloud computer in the cluster, so that the client can use it.

[0094] S112. Based on the connection information, client information, and user permissions of the target cloud computer, generate a token corresponding to the client and a token identifier corresponding to the token.

[0095] The connection information for the target cloud computer includes the cloud computer's IP address, service port, and connection protocol.

[0096] The token includes connection information, client information, and user permissions, meaning that the token in this embodiment contains multiple data dimensions. This eliminates the need to query related data when making calls between services, reducing system I / O overhead and latency, and improving system operating efficiency.

[0097] In this embodiment, the token includes client information, thus meeting the client's authentication requirements when connecting to the cloud computer.

[0098] The generated token can be in JWT format, which is used for direct verification between services.

[0099] In one specific embodiment, the multi-dimensional data of the token is encapsulated in JWT (JSON Web Token) format and signed using asymmetric encryption (RS256 algorithm) to ensure that the data is immutable and forgery-proof. The data structure design of the token is as follows (a new token will be generated if any data item changes): JSON { "jti": "Unique token identifier (UUID)", "sub": "UserID", "tenant_id": "tenant ID", "username": "username", "permissions": "User permission level (e.g., admin / user / visitor)", "connection_info": { "pod_ip": "IP address of the cloud PC's Pod", "port": "Cloud PC Service Port", "protocol": "Connection protocol (e.g., RDP / SSH)", "session_id": "session ID (UUID)", "timeout": 3600 / / Connection timeout (seconds) }, "client_info": { "client_name": "Tarui", "client_version": "v2.3.0", "device_model": "iPhone 15 Pro", "device_uuid": "Unique device identifier (IMEI / UUID)", "os_type": "iOS 17.0", "client_ip": "Client's public IP address" }, "iat": 1740000000, / / Token creation time (timestamp) "exp": 1740036000, / / Token expiration time (timestamp, default 24 hours) "nbf": 1740000000 / / Token effective time (timestamp) } Specifically, the token includes core fields such as user ID, tenant ID, Pod IP, port, session ID, client device identifier, and expiration time, achieving integrated encapsulation of multi-dimensional information.

[0100] S113. Store the token and token identifier in the storage module and send the token to the client.

[0101] The token is sent to the client. After receiving the token, the client sends the first connection request to the target cloud computer based on the connection information in the token.

[0102] like Figure 4 In the illustrated embodiment, the metadata of the Token is stored in Redis. The metadata includes the connection information of the target cloud computer, client information, and user permissions.

[0103] In some cases, Redis stores not only token metadata but also session state with clients and blacklists.

[0104] Multi-dimensional data is encapsulated in JWT (JSON Web Token) format and stored in a Redis cluster. Due to the use of "JWT stateless transmission and Redis cluster persistent storage" mode, high availability and data consistency can be guaranteed.

[0105] In scenarios where multiple users share the same cloud pod, because the token contains the IP information of the cloud pod (the connection information of the target cloud pod), each user's activity after logging in occurs on the same original cloud pod. Furthermore, because the token-based management scheme supports multiple users, the issue of user isolation is naturally resolved; data requiring isolation needs to be accessed via a token, such as... Figure 2 As shown by the arrows above, each person needs to obtain the data they require through a token.

[0106] For example, if an enterprise deploys 10 cloud computers (10 pods in a Kubernetes cluster) and 500 employees use them simultaneously, this solution can support multiple employees to use the cloud computers normally at the same time, and the employees are isolated from each other and do not affect each other, ensuring the fundamental need for multi-user login of cloud computers.

[0107] To improve security while reducing the operational burden on the token creation service, in some cases, client information includes client device information.

[0108] In step S109, the token creation service in the cluster receives the second connection request sent by the client, including: S109a. The gateway receives the second connection request sent by the client and verifies the validity of the client device information in the second connection request.

[0109] The storage module contains valid client device information. Upon receiving a second connection request, the gateway queries the storage module to check whether the client device information in the second connection request is valid.

[0110] S109b If the verification passes, the second connection request is sent to the token creation service.

[0111] If the verification fails, an invalid terminal message will be returned, and the process will be terminated.

[0112] S109c, The token creation service receives the second connection request forwarded by the gateway.

[0113] In this embodiment, before the token creation service receives the second connection request, the gateway verifies the legitimacy of the client device information in the second connection request. If the verification is successful, the gateway forwards the second connection request to the token creation service, which then verifies the client device. This not only improves security but also reduces the operational burden on the token creation service.

[0114] like Figure 4 In the illustrated embodiment, after the token creation service receives the second connection request forwarded by the gateway, it calls the user center database to verify the user credentials and tenant quota. If the verification passes, a token is generated, signed with a private key, and the token's cloud data is stored in the Redis cluster. After storage in the Redis cluster, a storage success confirmation message is returned. If the verification fails, an authentication failure message is returned, and the process is terminated.

[0115] Furthermore, in some embodiments, the client information also includes user information.

[0116] Specifically, S110 retrieves user permissions from the storage module based on client information, including: S110a, Verify the user information in the second connection request.

[0117] The storage module contains pre-set user information. The token creation service verifies the user information in the second connection request based on the user information in the storage module.

[0118] S110b If the verification passes, retrieve the permission information corresponding to the client from the storage module.

[0119] To facilitate the management of token lifecycle and improve the security of cloud computer use, in some examples, the method further includes: S114. The monitoring service in the cluster monitors the connection status between the client and the cloud computer.

[0120] S115. If the connection between the client and the cloud computer is lost, the token management service in the cluster will destroy the token corresponding to the client in the storage module.

[0121] In this embodiment, the token can be destroyed promptly after the connection is broken, thus preventing unauthorized reuse and improving security.

[0122] To facilitate the management of token lifecycle and improve the security of cloud computer use, in some examples, the method further includes: S116. Based on the expiration time in the token, the monitoring service in the cluster monitors whether the client's token has expired.

[0123] The token includes its creation time, expiration time, or effective time. These times are generated when the token is created by the token creation service.

[0124] S117. If the client's token has expired, the token management service in the cluster will clean up the client's token.

[0125] In some cases, when it is necessary to revoke a token, Kubernetes provides a corresponding service to proactively revoke the token in the storage module, ensuring system security.

[0126] In one embodiment, by monitoring connection status, setting expiration time in the token, and actively calling the interface, the entire lifecycle of the token can be managed automatically. The token is destroyed immediately when the connection is broken, and expired tokens are automatically cleaned up.

[0127] In the embodiments provided in this application, when a client requests a connection, the cluster triggers functions such as token creation, secure storage after creation, dynamic refresh, connection disconnection, automatic expiration and destruction, and proactive revocation to ensure system security. The token creation service, token monitoring service, and token management service are adapted to the cloud PC's "single Pod full-function integration" architecture, realizing full lifecycle management of the token from creation to destruction.

[0128] Figure 5 This is a schematic diagram of the structure of a cloud computer service operation device provided in an embodiment of this application, as shown below. Figure 5 As shown, this embodiment of the cloud computer service operation device has a cloud computer running in a container within a cluster. The device includes: a first receiving module 11, used to receive a service request sent by a client; wherein the service request includes service operation object information; a first determining module 12, used to determine a first target application service corresponding to the service operation object information based on the service operation object information in the service request; a first obtaining module 13, used to obtain a token corresponding to the client from the storage module of the cluster through the first target application service; and a second determining module 14, used to determine whether to execute the service operation corresponding to the service request based on the user permission information in the token through the first target application service.

[0129] The apparatus of this embodiment can be used to perform Figure 1 The technical solutions of the method embodiments shown are similar in principle and in effect, and will not be described again here.

[0130] The apparatus in this embodiment receives a service request sent by a client. Based on the service operation object information in the service request, it determines a first target application service corresponding to the service operation object information. Thus, the first target application service can obtain a token corresponding to the client from the storage module of the cluster. Based on this, the first target application service determines whether to execute the service operation corresponding to the service request according to the user permission information in the token. Since the first target application service obtains the token corresponding to the client from the storage module of the cluster, there is no need for other services in the cloud computer to send the token to the first target application service. That is, there is no need for services in the cloud computer to pass tokens to each other. This reduces cross-network redundancy during service processing and improves service processing efficiency.

[0131] As an optional implementation, the apparatus further includes: an establishment module, configured to establish a long-connection communication link with the client before the receiving module receives a service request sent by the client; wherein, the first receiving module is specifically configured to: receive a service request sent by the client based on the long-connection communication link; the first acquisition module is specifically configured to determine a token identifier corresponding to the client through the first target application service based on the long-connection communication link; the first target application service acquires a token corresponding to the token identifier from the storage module of the cluster according to the token identifier.

[0132] As an optional implementation, the establishment module is specifically used to receive a first connection request sent by the client; the first connection request includes a token; verify the status of the token; if the verification passes, establish a long-term connection communication link with the client.

[0133] As an optional implementation, the establishment module is specifically used to verify the token using a local public key; if the token verification is successful, the status of the token in the storage module is queried; and the status of the token is verified.

[0134] As an optional implementation, the first determining module is specifically used to determine a first target application service and a second target application service corresponding to the business operation object information in the business request; the device further includes: a calling module, used to call the second target application service when the first target application service performs a business operation corresponding to the business request; a second obtaining module, used to obtain a token corresponding to the client from the storage module of the cluster through the second target application service; and a third determining module, used to determine whether to execute the business operation corresponding to the business request based on the user permission information in the token through the second target application service.

[0135] As an optional implementation, the apparatus further includes: a second receiving module, configured to receive a second connection request sent by the client through a token creation service in the cluster before the establishment module receives the first connection request sent by the client; the second connection request includes client information; a third obtaining module, configured to obtain user permissions from the storage module based on the client information; an allocation module, configured to allocate a target cloud computer to the client; a generation module, configured to generate a token corresponding to the client and a token identifier corresponding to the token based on the connection information of the target cloud computer, the client information, and the user permissions; and a sending module, configured to store the token and the token identifier in the storage module and send the token to the client.

[0136] As an optional implementation, the client information includes client device information; the second receiving module is specifically used for: receiving a second connection request sent by the client through the gateway and verifying the validity of the client device information in the second connection request; if the verification passes, sending the second connection request to the token creation service; the token creation service receiving the second connection request forwarded by the gateway.

[0137] As an optional implementation, the client information further includes user information; wherein, the third acquisition module is specifically used to: verify the user information in the second connection request; if the verification passes, obtain the permission information corresponding to the client from the storage module.

[0138] As an optional implementation, the device further includes: a monitoring module, used to monitor the connection status between the client and the cloud computer through a monitoring service in the cluster; and a destruction module, used to destroy the token corresponding to the client in the storage module if the connection between the client and the cloud computer is lost, by a token management service in the cluster.

[0139] As an optional implementation, the apparatus further includes: a monitoring module, configured to monitor whether the client's token has expired according to the expiration time in the token; and a cleanup module, configured to clean up the client's token if the client's token has expired, configured to clean up the client's token by the token management service in the cluster.

[0140] The apparatus described in the above embodiments can be used to execute the technical solutions of the above method embodiments. The implementation principle and technical effects are similar, and will not be repeated here.

[0141] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, as shown below. Figure 6As shown, it may include a processor 61 and a memory 62, wherein the memory 62 is used to store executable program code; the processor 61 runs the program corresponding to the executable program code by reading the executable program code stored in the memory 62, and is used to execute any of the cloud computer business operation methods provided in the foregoing embodiments, so as to achieve the corresponding beneficial technical effects, which has been described in detail above and will not be repeated here.

[0142] The aforementioned electronic devices exist in various forms, including but not limited to: (1) Personal computer devices: These devices have computing and processing functions and generally also have mobile Internet access capabilities.

[0143] (2) Server: A device that provides computing services. The components of a server include a processor, hard disk, storage module, system bus, etc. Servers are similar to general computer architectures, but because they need to provide highly reliable services, they have higher requirements in terms of processing power, stability, reliability, security, scalability, and manageability.

[0144] (3) Other electronic devices with data interaction functions.

[0145] Accordingly, embodiments of this application also provide a computer-readable storage medium storing one or more programs, which can be executed by one or more processors to implement any of the cloud computer service operation methods provided in the foregoing embodiments, thus achieving the corresponding technical effects. This has been described in detail above and will not be repeated here.

[0146] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0147] The various embodiments in this specification are described in a related manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0148] In particular, the device embodiment is basically similar to the method embodiment, so the description is relatively simple. For relevant details, please refer to the description of the method embodiment.

[0149] For ease of description, the above apparatus is described by dividing it into various functional units / modules. Of course, in implementing this application, the functions of each unit / module can be implemented in one or more software and / or hardware.

[0150] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0151] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for operating cloud computing services, characterized in that, The cloud computer runs in a container within the cluster; the method includes: Receive a service request sent by the client; wherein the service request includes service operation object information; Based on the business operation object information in the business request, determine the first target application service corresponding to the business operation object information; The first target application service obtains the token corresponding to the client from the storage module of the cluster; The first target application service determines whether to execute the business operation corresponding to the business request based on the user permission information in the token.

2. The method according to claim 1, characterized in that, Before receiving the service request sent by the client, the method further includes: Establish a long-lived communication link with the client; The receiving of service requests sent by the client includes: Based on the long-connection communication link, receive service requests sent by the client; The first target application service obtains the token corresponding to the client from the storage module of the cluster, including: The first target application service determines the token identifier corresponding to the client based on the long-connection communication link; The first target application service retrieves the token corresponding to the token identifier from the storage module of the cluster based on the token identifier.

3. The method according to claim 2, characterized in that, The establishment of a long-lived communication link with the client includes: Receive a first connection request sent by the client; the first connection request includes a token; The status of the token is verified; If the verification passes, a long-lived communication link is established with the client.

4. The method according to claim 3, characterized in that, The verification of the token's status includes: The token is verified using the local public key; If the token verification is successful, then query the status of the token in the storage module; The status of the token is verified.

5. The method according to claim 1, characterized in that, The step of determining the first target application service corresponding to the business operation object information based on the business operation object information in the business request includes: Based on the business operation object information in the business request, determine the first target application service and the second target application service corresponding to the business operation object information; The method further includes: When the first target application service performs a business operation corresponding to the business request, the second target application service is invoked. The second target application service obtains the token corresponding to the client from the storage module of the cluster; The second target application service determines whether to execute the business operation corresponding to the business request based on the user permission information in the token.

6. The method according to claim 3, characterized in that, Before receiving the first connection request sent by the client, the method further includes: The token creation service in the cluster receives a second connection request sent by the client; the second connection request includes client information. Based on the client information, obtain user permissions from the storage module; Assign a target cloud computer to the client; Based on the connection information of the target cloud computer, the client information, and the user permissions, a token corresponding to the client and a token identifier corresponding to the token are generated; The token and the token identifier are stored in the storage module, and the token is sent to the client.

7. The method according to claim 6, characterized in that, The client information includes client device information; The token creation service in the cluster receives a second connection request sent by the client, including: The gateway receives the second connection request sent by the client and verifies the validity of the client device information in the second connection request; If the verification passes, the second connection request is sent to the token creation service; The token creation service receives the second connection request forwarded by the gateway.

8. The method according to claim 7, characterized in that, The client information also includes user information; The step of obtaining user permissions from the storage module based on the client information includes: Verify the user information in the second connection request; If the verification passes, the permission information corresponding to the client is retrieved from the storage module.

9. The method according to claim 2, characterized in that, The method further includes: The monitoring service in the cluster monitors the connection status between the client and the cloud computer; If the connection between the client and the cloud computer is lost, the token management service in the cluster will destroy the token corresponding to the client in the storage module.

10. The method according to claim 1, characterized in that, The method further includes: Based on the expiration time in the token, the monitoring service in the cluster monitors whether the client's token has expired; If the client's token has expired, the token management service in the cluster will clean up the client's token.

Images