Application containerization sharing management method and system for cloud mobile phone cluster

Abstract

This invention belongs to the field of cloud computing and containerization technology, and discloses a method and system for application containerization and shared management for cloud phone clusters. The method includes: encapsulating the application into a read-only container image and storing it; intercepting and forwarding user startup requests through the proxy module of the cloud phone lightweight instance; querying the session status by the application routing and session management layer, and triggering the runtime service cluster to start an independent application container process if there is no active session; mounting an independent private data volume to the container process; and establishing a communication channel between the container process and the lightweight instance for interaction. Through the above methods, the decoupling of the application and the cloud phone instance is achieved, along with global sharing of storage resources, on-demand millisecond-level instantiation, and strict data isolation, significantly reducing storage costs and improving management efficiency and user experience.

Description

Technical Field

[0001] This invention relates to the field of cloud computing and containerization technology, and in particular to a method and system for application containerization sharing management for cloud mobile phone clusters. Background Technology

[0002] Cloud phone services create a virtual mobile operating system environment for each user in the cloud, enabling them to run mobile applications remotely. In traditional architectures, user applications need to be pre-installed in the virtual storage of each cloud phone instance. As the user base grows to tens of thousands or even millions, this model exposes significant problems: First, the binary files and resources of the same application are repeatedly stored across thousands of instances, resulting in massive storage redundancy and extremely high storage costs; second, instances containing large amounts of application data become exceptionally bloated, leading to inefficient lifecycle operations such as instance creation, cloning, migration, and snapshots, severely impacting the elastic scaling and fault recovery capabilities of the business; finally, application startup requires loading all files from the instance's virtual disk, which, limited by single-instance I / O performance, introduces inherent latency, making it difficult to achieve a "click-to-use" instant experience.

[0003] Existing related technologies, such as patent document CN114115953A, disclose a method for containerizing and deploying applications within a terminal device, aiming to achieve isolation between the application and the host system. However, its core is still to install the application inside the device, without changing the fundamental attribute of the application being bound to the device, and thus failing to solve the problems of storage redundancy and cumbersome instances. Another example is patent document CN113641395A, which focuses on optimizing the loading of cloud gaming resources. However, the game application itself is still a complete process within the cloud gaming instance, and its resources still need to be distributed locally to the instance, failing to achieve global sharing and on-demand instantaneous instantiation of the application.

[0004] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this invention is to provide a containerized shared management method and system for cloud phone clusters, aiming to solve the technical problems of huge application storage redundancy, cumbersome instance management, and high application startup latency in existing cloud phone technologies.

[0006] To achieve the above objectives, this invention provides a method for containerized shared management of applications for cloud phone clusters. This method is applied to a cloud system, which includes at least a cloud application container repository, a service cluster for application container runtime, an application routing and session management layer, and multiple lightweight cloud phone instances. The method includes: The mobile application and its runtime environment are encapsulated into a read-only application container image and stored in the cloud application container repository. In response to a user's application launch operation on a cloud phone lightweight instance, the application access proxy module running on the cloud phone lightweight instance intercepts the launch operation, generates an instantiation request containing user identifier, instance identifier and application identifier, and sends the instantiation request to the application routing and session management layer. The application routing and session management layer queries whether a corresponding active application container session exists based on the instantiation request. If no session exists, a start command is issued to the service cluster where the application container is running. The application container runtime service cluster obtains the corresponding application container image from the cloud application container repository according to the startup instruction, and starts the application container process, wherein the application container process is an independent and isolated application container process. Create and mount a separate private data volume for the started application container process, wherein the private data volume is used to persistently store the private data of the corresponding user within the application; A communication channel is established between the started application container process and the cloud phone lightweight instance that initiates the instantiation request for transmitting application rendering screens and user input events. The application container process executes application logic, while the cloud phone lightweight instance is responsible for the presentation of the interactive interface and the collection of input.

[0007] In one embodiment, the method further includes: Upon receiving the start command, the application container runtime service cluster will start the container process directly based on the cache if the application container image is cached locally; otherwise, it will pull the image from the cloud application container repository before starting the process.

[0008] In one embodiment, the private data volume is created on a distributed storage service, and its identifier is uniquely associated with the user identifier, instance identifier, and application identifier. Private data volumes corresponding to different users, different instances, or different applications are isolated from each other.

[0009] In one embodiment, the communication channel is a virtual private link established based on a low-latency internal network, used for streaming the rendered video frames and serialized input event data.

[0010] In one embodiment, multiple application container processes launched based on the same application container image share the read-only data blocks of the image in the storage layer, and maintain their own writable layers only in memory.

[0011] In one embodiment, the method further includes: The application routing and session management layer maintains a mapping table for all active sessions. When a session is detected to be terminated or the user actively logs out, it notifies the application container runtime service cluster to destroy the corresponding application container process and retain or clean up the corresponding private data volume according to the policy.

[0012] In one embodiment, the method further includes: When a new application needs to be provided to a large number of cloud phone lightweight instances, a corresponding application container image is published in the cloud application container repository. The first launch request by a user on each instance triggers the independent session management and container instantiation steps, thereby realizing the batch and on-demand deployment of the application.

[0013] Furthermore, to achieve the above objectives, this invention also proposes an application containerization sharing management system for cloud mobile phone clusters. This system is applied to the application containerization sharing management method for cloud mobile phone clusters described above, and includes: A cloud application container repository is used to encapsulate mobile applications and their runtime environments into read-only application container images and store them in the cloud application container repository. The application access proxy module is used to respond to the user's application launch operation on a certain cloud phone lightweight instance. The application access proxy module running on the cloud phone lightweight instance intercepts the launch operation and generates an instantiation request containing user identifier, instance identifier and application identifier, and sends the instantiation request to the application routing and session management layer. The application routing and session management layer is used to query whether there is a corresponding active application container session based on the instantiation request. If there is no session, a start command is issued to the service cluster where the application container is running. The application container runtime service cluster is used to obtain the corresponding application container image from the cloud application container repository according to the startup instruction, and start the application container process, wherein the application container process is an independent and isolated application container process. The storage management module creates and mounts an independent private data volume for the started application container process, wherein the private data volume is used to persistently store the private data of the corresponding user within the application; The communication channel establishment module establishes a communication channel between the started application container process and the cloud phone lightweight instance that initiates the instantiation request for transmitting application rendering screens and user input events. The application container process executes application logic, while the cloud phone lightweight instance is responsible for the presentation of the interactive interface and input collection.

[0014] Furthermore, to achieve the above objectives, the present invention also proposes an application containerization sharing management device for cloud mobile phone clusters. The application containerization sharing management device for cloud mobile phone clusters includes: a memory, a processor, and an application containerization sharing management program for cloud mobile phone clusters stored on the memory and executable on the processor. The application containerization sharing management program for cloud mobile phone clusters is configured to implement the steps of the application containerization sharing management method for cloud mobile phone clusters as described above.

[0015] Furthermore, to achieve the above objectives, the present invention also proposes a storage medium storing an application containerization sharing management program for cloud mobile phone clusters. When the application containerization sharing management program for cloud mobile phone clusters is executed by a processor, it implements the steps of the application containerization sharing management method for cloud mobile phone clusters as described above.

[0016] This invention encapsulates the application as a read-only container image and stores it; intercepts and forwards user startup requests through the proxy module of the cloud phone lightweight instance; the application routing and session management layer queries the session status, and if there is no active session, it triggers the runtime service cluster to start an independent application container process; an independent private data volume is mounted for the container process; and a communication channel is established between the container process and the lightweight instance for interaction. Through these methods, the invention achieves decoupling of the application and the cloud phone instance, global sharing of storage resources, on-demand millisecond-level instantiation, and strict data isolation, significantly reducing storage costs and improving management efficiency and user experience. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the first embodiment of the application containerization and sharing management method for cloud mobile phone clusters according to the present invention. Figure 2 This is a schematic diagram of the overall architecture of the application containerization and sharing management method for cloud mobile phone clusters in this invention; Figure 3 This is a structural block diagram of the first embodiment of the application containerization and sharing management system for cloud mobile phone clusters according to the present invention.

[0018] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0020] This invention provides a method for containerized shared management of applications for cloud phone clusters, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the application containerization and sharing management method for cloud mobile phone clusters according to the present invention.

[0021] In this embodiment, the application containerization sharing management method for cloud mobile phone clusters includes the following steps: Step S10: Encapsulate the mobile application and its runtime environment into a read-only application container image and store it in the cloud application container repository.

[0022] In this embodiment, the execution entity is an application containerization sharing management device for cloud phone clusters. This application containerization sharing management device for cloud phone clusters has functions such as data processing, data communication, and program execution. The application containerization sharing management device for cloud phone clusters can be a computer terminal device or other network device, or other devices with similar functions. This embodiment does not limit the scope of the application containerization sharing management device.

[0023] It's important to note that cloud phone services create a virtual mobile operating system environment for each user in the cloud, enabling them to run mobile applications remotely. In traditional architectures, user applications need to be pre-installed in the virtual storage of each cloud phone instance. As the user base grows to tens of thousands or even millions, this model exposes significant problems: First, the binary files and resources of the same application are repeatedly stored across thousands of instances, resulting in massive storage redundancy and extremely high storage costs. Second, instances containing large amounts of application data become exceptionally bloated, leading to inefficient lifecycle operations such as instance creation, cloning, migration, and snapshots, severely impacting the elastic scaling and fault recovery capabilities of the business. Finally, application startup requires loading all files from the instance's virtual disk, which, limited by single-instance I / O performance, introduces inherent latency, making it difficult to achieve a "click-to-use" instant experience.

[0024] Existing technologies disclose a method for containerizing and deploying applications within terminal devices, aiming to isolate applications from the host system. However, the core of this approach remains installing applications within the device, failing to change the fundamental attribute of application-device binding and thus unable to solve the problems of storage redundancy and cumbersome instances. Similarly, existing technologies focus on optimizing the loading of cloud gaming resources, but the game application itself remains a complete process within the cloud gaming instance, and its resources still need to be distributed locally to the instance, failing to achieve global sharing and on-demand instantiation of the application.

[0025] To address the aforementioned technical challenges, this embodiment encapsulates the application as a read-only container image and stores it. The proxy module of the cloud phone lightweight instance intercepts and forwards user startup requests. The application routing and session management layer queries the session status; if no active session is found, the runtime service cluster is triggered to start an independent application container process. An independent private data volume is mounted on the container process. A communication channel is established between the container process and the lightweight instance for interaction. Through these methods, the application and cloud phone instance are decoupled, storage resources are shared globally, instantiation is performed on demand at millisecond levels, and strict data isolation is achieved. This significantly reduces storage costs and improves management efficiency and user experience. Specifically, this can be implemented as follows.

[0026] In the specific implementation, this embodiment first refers to Figure 2As shown, the system mainly consists of: a cloud application container repository: used to store all standardized and packaged application container images. Each image is read-only, containing an application and its complete runtime environment (file system, libraries, resources), but not any user private data. An application container runtime service cluster: responsible for pulling images from the repository and quickly starting independent, isolated application container processes. This service has container orchestration capabilities and manages the container lifecycle. Lightweight cloud phone instances: stripped of the user application's virtual machine, containing only a streamlined mobile operating system, system services, and a key application access proxy module. This proxy is responsible for intercepting and forwarding the user's application startup requests. An application routing and session management layer: acting as the central hub, maintaining the dynamic mapping relationship between users, cloud phone instances, and application containers, responsible for request routing, session establishment, and communication link management. Distributed storage service: providing each application container session with an independent, persistent private data volume for storing all personalized data of the user within that application. The specific process includes: Step 1: Application deployment and containerization (preparation phase), starting with the developer or administrator submitting the original application installation package (APK) through the management interface. Processing: The platform's automated packaging module parses the APK, extracts its executable files and resources, and packages them together with a pre-built, optimized base operating system runtime environment to generate an application container image conforming to the Open Container Initiative (OCI) standard. This image is read-only. End: The generated image is pushed and stored in the cloud application container repository, available for global access. Step Two: User Request and Application Instantiation (Runtime Phase), Start: The user clicks an application icon on the interface of the cloud phone lightweight instance. Processing: The application access proxy module within the instance captures this event, generates a request containing the user identifier, application identifier, and instance identifier, and sends it to the application routing and session management layer. Processing: The application routing and session management layer checks if an active session for this user-instance-application exists. If not, it sends an instruction to the application container runtime service, requesting it to start a corresponding application container process. Processing: Upon receiving the instruction, the application container runtime service pulls the corresponding application container image from the cloud application container repository (if the local node is not cached) and starts a brand new, isolated container process within milliseconds. Simultaneously, a unique private data volume (identified by user ID + instance ID + application ID) is created and mounted for this session from the distributed storage service. End: The application routing and session management layer establishes a low-latency, high-bandwidth virtual channel between the successfully launched application container process and the requesting cloud phone lightweight instance to transmit the application's rendered screen (video stream) and user input events (touch, key presses). The user perceives the application as launching instantly.Step 3: Runtime Data Isolation and Resource Sharing. The application container process carries all the application's computational logic, and all user data it generates (such as game saves and application configurations) is written to its mounted private data volume, achieving strict data isolation between different users and different instances. The cloud phone lightweight instance only acts as an "interactive terminal," responsible for displaying remotely rendered screens and collecting user input. A lightweight instance can connect to multiple different application containers simultaneously. All container processes launched based on the same application container image share the image's read-only data blocks in the storage layer, with their own independent writable layers only in memory, achieving ultimate storage sharing. Step 4: Batch Deployment and Management. When an administrator needs to enable a new application on a large number of instances, they only need to publish one container image of the application in the cloud application container repository. Each time any user in the target user group clicks on the application for the first time, it will trigger an independent Step 2 process. Through the orchestration capabilities of the application container runtime service, the system can process massive instantiation requests in parallel while ensuring zero storage redundancy.

[0027] In this embodiment, the process is an application preparation step, where the system needs to prepare for the shared operation of mobile applications. Specifically, developers or administrators submit the original application installation package (e.g., an Android APK file) through a management platform. The application packaging management module in the cloud system (which can be a standalone module or integrated into the management platform) receives the installation package. This module automatically parses the installation package, extracting the application's executable code, resource files, configuration files, and other core elements. Subsequently, these extracts are integrated with a pre-configured, lightweight, and stable basic mobile operating system runtime environment, which contains the necessary library files, frameworks, and minimal system services for running this type of application. The entire packaging process generates a container image compliant with the Open Container Initiative (OCI) standard, specifically by receiving the application installation package; parsing the application installation package; and packaging it with a pre-configured basic operating system runtime environment to generate a container image compliant with the OCI standard. This image is designed to be read-only to ensure its content is immutable and has the characteristic of being securely reused an unlimited number of times. Finally, the generated container image is pushed and stored in the "cloud application container repository," becoming the sole application source that all cloud phone users can share.

[0028] Step S20: In response to a user's application launch operation on a certain cloud phone lightweight instance, the application access proxy module running on the cloud phone lightweight instance intercepts the launch operation, generates an instantiation request containing user identifier, instance identifier and application identifier, and sends the instantiation request to the application routing and session management layer.

[0029] User operations occur on a "lightweight cloud phone instance." This instance is a highly streamlined virtual machine or container that runs only the core mobile operating system and necessary system services. Crucially, this lightweight instance itself does not pre-install or contain any binary or resource files for the user's mobile application. The application icons displayed on the instance interface are merely shortcuts or metadata pointing to cloud applications. The application access proxy module is deeply integrated into this instance; it can be integrated into the cloud phone lightweight instance's operating system layer or run as a standalone system background service. The core function of this module is to intercept user actions related to launching application icons and forward requests, without assuming any other application runtime responsibilities. When a user clicks an application icon intending to launch an application, the proxy module immediately captures this click event. It then generates a structured "instantiation request," which contains at least three key identifiers: the current user's identity (User ID), the identifier of the cloud phone lightweight instance the user is on (Instance ID), and the identifier of the target application the user intends to launch (AppID). After generating the request, the proxy module sends it over the network to the unified "application routing and session management layer" in the cloud. Step S30: The application routing and session management layer queries whether there is a corresponding active application container session based on the instantiation request. If there is no session, a start command is issued to the service cluster where the application container is running.

[0030] Step S40: The application container runtime service cluster obtains the corresponding application container image from the cloud application container repository according to the startup instruction, and starts the application container process.

[0031] It's important to note that the "Application Routing and Session Management Layer," acting as the system's control hub, receives requests from lightweight instances. Internally, it maintains a global mapping table of active sessions, recording the real-time relationships between users, instances, applications, and container processes. The management layer first queries this table to check if a running, corresponding "application container process" (i.e., an active session) already exists for the "user-instance-application" combination. If the query result is "not found" (e.g., the user is launching the application for the first time, or the previously launched container has been recycled), the management layer immediately issues a startup command to the "Application Container Runtime Service Cluster."

[0032] The application container runtime service cluster is deployed in the cloud, typically on dedicated compute nodes separate from the physical or virtual nodes running cloud phone lightweight instances. This cluster has powerful container orchestration capabilities (e.g., based on Kubernetes) to manage the entire lifecycle of application container processes, including creation, destruction, monitoring, resource scheduling (such as CPU and memory allocation), and elastic scaling based on load.

[0033] Upon receiving the startup command, the service cluster performs container instantiation. First, based on the application identifier, it attempts to find the corresponding application container image from the local image cache of its node. If the local cache is found, the container process is started directly based on the cached image, significantly reducing startup latency. If no local cache exists, the image is pulled from the cloud application container repository and started, while simultaneously updating the local cache for later use. Subsequently, within milliseconds, the service cluster starts a completely new, independent, and isolated application container process in an isolated runtime environment. All different container processes started based on the same read-only application container image share the image's read-only data blocks at the underlying storage level through technologies such as copy-on-write. Each process only maintains the writable layer data generated during its own runtime in memory, thus achieving ultimate sharing of storage resources.

[0034] Step S50: Create and mount a separate private data volume for the started application container process.

[0035] Simultaneously or immediately after starting the application container process, the system must provide persistent and isolated storage for user data. To this end, the system operates a distributed storage service (such as Ceph, GlusterFS, or cloud-native storage solutions) to create a unique, independent "private data volume" for this specific session. This private data volume is created on the distributed storage service, and its unique identifier (such as a volume ID or path) is strongly associated with the requesting user ID, the cloud phone's lightweight instance ID, and the application ID using a specific algorithm (such as a hash combination). This association ensures that the private data volumes corresponding to different users, different instances, or different applications are strictly isolated from each other in both logical and physical access paths. Subsequently, this newly created private data volume is mounted to the writable path specified in the newly started application container process. From then on, all user private data generated during the operation of this application container process, including but not limited to game saves, chat logs, personal settings, application cache, etc., will be written to this mounted private data volume, achieving data persistence and secure isolation.

[0036] Step S60: Establish a communication channel between the started application container process and the cloud phone lightweight instance that initiated the instantiation request for transmitting application rendering screens and user input events.

[0037] Once the application container process has successfully started and the private data volume has been mounted, the "Application Routing and Session Management Layer" coordinates the establishment of a high-speed, low-latency "communication channel" between the newly started application container process and the cloud phone lightweight instance that initially initiated the request. This channel is a virtual private link established based on the low-latency, high-bandwidth network within the cloud data center (such as a virtual network built using technologies like VXLAN and SR-IOV). After the channel is established, the entire interaction mode is set: the application container process acts as the "computing brain," executing all business logic and computationally intensive tasks such as graphics rendering in the cloud, and encoding the rendered screen into a video stream (such as H.264 / HEVC) in real time, which is then streamed to the lightweight instance through this communication channel. The cloud phone lightweight instance acts as the "interactive terminal," receiving and decoding the video stream, smoothly displaying the application screen on its local interface; simultaneously, it captures and serializes all user input events such as touch, swipe, and key presses on the local interface into specific interaction protocol data packets, which are then sent back to the remote application container process for processing through the same communication channel. For users, the entire process from clicking the icon to the application interface appearing and becoming operable is almost imperceptible, achieving a "click and play" experience.

[0038] Advantages of Session Lifecycle Management and Batch Deployment: Throughout the session, the application routing and session management layer continuously monitor the status of all active sessions. When session termination is detected (e.g., user timeout due to prolonged inactivity), user voluntarily exiting the application, or session connection anomalies, the management layer notifies the application container runtime service cluster to destroy the corresponding application container process to quickly release computing resources. Simultaneously, the management layer instructs the distributed storage service to retain or clean up the corresponding private data volume according to a preset data retention policy (e.g., immediate deletion, retention for 7 days).

[0039] The solution of this invention is particularly suitable for large-scale deployment scenarios. When a system administrator needs to provide a new application to a large cluster of cloud phone lightweight instances, the operation is extremely simple: just publish a container image of the application in the "cloud application container repository". There is no need to perform traditional application distribution, installation, or update operations on any cloud phone lightweight instance. After any user in the cluster sees the new application icon on their lightweight instance desktop, the first click will independently trigger the complete process of "request interception and forwarding" to "channel establishment and interaction". Through the elasticity of the application container runtime service cluster, the system can process massive initial startup requests in parallel, thereby achieving "one-time deployment, global on-demand instant availability" of the application, fundamentally solving the efficiency and consistency problems of batch deployment.

[0040] In this embodiment, the application is encapsulated as a read-only container image and stored; the user's startup request is intercepted and forwarded through the proxy module of the cloud phone lightweight instance; the application routing and session management layer queries the session status, and if there is no active session, the runtime service cluster is triggered to start an independent application container process; an independent private data volume is mounted for the container process; and a communication channel is established between the container process and the lightweight instance for interaction. Through the above methods, the application and the cloud phone instance are decoupled, storage resources are shared globally, instantiation is performed on demand at millisecond levels, and strict data isolation is achieved, significantly reducing storage costs and improving management efficiency and user experience.

[0041] Furthermore, this embodiment of the invention also proposes a storage medium storing an application containerization sharing management program for cloud mobile phone clusters. When the application containerization sharing management program for cloud mobile phone clusters is executed by a processor, it implements the steps of the application containerization sharing management method for cloud mobile phone clusters as described above.

[0042] Reference Figure 3 , Figure 3 This is a structural block diagram of the first embodiment of the application containerization and sharing management system for cloud mobile phone clusters according to the present invention.

[0043] like Figure 3 As shown in the embodiments of the present invention, the application containerization and sharing management system for cloud mobile phone clusters includes: The cloud application container repository 10 is used to encapsulate the mobile application and its runtime environment into a read-only application container image and store it in the cloud application container repository. Application access proxy module 20 is used to respond to the user's application startup operation on a certain cloud phone lightweight instance. The application access proxy module running on the cloud phone lightweight instance intercepts the startup operation and generates an instantiation request containing user identifier, instance identifier and application identifier, and sends the instantiation request to the application routing and session management layer. The application routing and session management layer 30 is used to query whether there is a corresponding active application container session based on the instantiation request. If there is no session, a start command is issued to the service cluster where the application container is running. Application container runtime service cluster 40 is used to obtain the corresponding application container image from the cloud application container repository according to the startup instruction and start the application container process, wherein the application container process is an independent and isolated application container process. Storage management module 50 creates and mounts an independent private data volume for the started application container process, wherein the private data volume is used to persistently store the private data of the corresponding user in the application; The communication channel establishment module 60 establishes a communication channel between the started application container process and the cloud phone lightweight instance that initiates the instantiation request for transmitting application rendering screens and user input events. The application container process executes application logic, and the cloud phone lightweight instance is responsible for the presentation of the interactive interface and input collection.

[0044] In this embodiment, the application is encapsulated as a read-only container image and stored; the user's startup request is intercepted and forwarded through the proxy module of the cloud phone lightweight instance; the application routing and session management layer queries the session status, and if there is no active session, the runtime service cluster is triggered to start an independent application container process; an independent private data volume is mounted for the container process; and a communication channel is established between the container process and the lightweight instance for interaction. Through the above methods, the application and the cloud phone instance are decoupled, storage resources are shared globally, instantiation is performed on demand at millisecond levels, and strict data isolation is achieved, significantly reducing storage costs and improving management efficiency and user experience.

[0045] This application embodiment also provides an application containerization sharing management device for cloud phone clusters, including a processor, a communication interface, a memory, and a communication bus. The processor, communication interface, and memory communicate with each other through the communication bus. The memory is used to store the application containerization sharing management program for cloud phone clusters. When the processor executes the program stored in the memory, it implements the above-mentioned application containerization sharing management method for cloud phone clusters.

[0046] The communication bus mentioned above for the containerized shared management device for cloud phone clusters can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc.

[0047] The communication interface is used for communication between the aforementioned application containerization shared management device for cloud phone clusters and other devices.

[0048] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0049] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0050] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0051] 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.

[0052] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0053] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

[0054] It should be understood that the above are merely illustrative examples and do not constitute any limitation on the technical solutions of the present invention. In specific applications, those skilled in the art can make settings as needed, and the present invention does not impose any restrictions on this.

[0055] It should be noted that the workflow described above is merely illustrative and does not limit the scope of protection of this invention. In practical applications, those skilled in the art can select some or all of the workflow to achieve the purpose of this embodiment according to actual needs, and no restrictions are imposed here.

[0056] In addition, for technical details not described in detail in this embodiment, please refer to the application containerization sharing management method for cloud mobile phone clusters provided in any embodiment of the present invention, which will not be repeated here.

[0057] Furthermore, it should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system 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 system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0058] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0059] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0060] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

[0061] It is understood that the system provided in the embodiments of the present invention corresponds to the method provided in the embodiments of the present invention, and the explanation, examples and beneficial effects of the relevant content can be referred to the corresponding parts of the above methods.

Claims

1. A method for containerized shared management of applications for cloud mobile phone clusters, characterized in that, The application containerization and shared management method for cloud phone clusters is applied to a cloud system, which includes at least a cloud application container repository, a service cluster for application container runtime, an application routing and session management layer, and multiple lightweight cloud phone instances. The method includes: The mobile application and its runtime environment are encapsulated into a read-only application container image and stored in the cloud application container repository. In response to a user's application launch operation on a cloud phone lightweight instance, the application access proxy module running on the cloud phone lightweight instance intercepts the launch operation, generates an instantiation request containing user identifier, instance identifier and application identifier, and sends the instantiation request to the application routing and session management layer. The application routing and session management layer queries whether a corresponding active application container session exists based on the instantiation request. If no session exists, a start command is issued to the service cluster where the application container is running. The application container runtime service cluster obtains the corresponding application container image from the cloud application container repository according to the startup instruction, and starts the application container process, wherein the application container process is an independent and isolated application container process. Create and mount a separate private data volume for the started application container process, wherein the private data volume is used to persistently store the private data of the corresponding user within the application; A communication channel is established between the started application container process and the cloud phone lightweight instance that initiates the instantiation request for transmitting application rendering screens and user input events. The application container process executes application logic, while the cloud phone lightweight instance is responsible for the presentation of the interactive interface and the collection of input.

2. The application containerization and sharing management method for cloud mobile phone clusters as described in claim 1, characterized in that, The method further includes: Upon receiving the start command, the application container runtime service cluster will start the container process directly based on the cache if the application container image is cached locally; otherwise, it will pull the image from the cloud application container repository before starting the process.

3. The application containerization and sharing management method for cloud mobile phone clusters as described in claim 1, characterized in that, The private data volume is created on a distributed storage service, and its identifier is uniquely associated with the user identifier, instance identifier, and application identifier. Private data volumes corresponding to different users, different instances, or different applications are isolated from each other.

4. The application containerization and sharing management method for cloud mobile phone clusters as described in claim 1, characterized in that, The communication channel is a virtual private link established based on a low-latency internal network, used for streaming the rendered video encoding footage and serialized input event data.

5. The application containerization and sharing management method for cloud mobile phone clusters as described in claim 1, characterized in that, Multiple application container processes launched based on the same application container image share the read-only data blocks of the image in the storage layer, and maintain their own writable layers only in memory.

6. The application containerization and sharing management method for cloud mobile phone clusters as described in claim 1, characterized in that, The method further includes: The application routing and session management layer maintains a mapping table for all active sessions. When a session is detected to be terminated or the user actively logs out, it notifies the application container runtime service cluster to destroy the corresponding application container process and retain or clean up the corresponding private data volume according to the policy.

7. The application containerization and sharing management method for cloud mobile phone clusters as described in claim 1, characterized in that, The method further includes: When a new application needs to be provided to a large number of cloud phone lightweight instances, a corresponding application container image is published in the cloud application container repository. The first launch request by a user on each instance triggers the independent session management and container instantiation steps, thereby realizing the batch and on-demand deployment of the application.

8. A containerized shared management system for cloud mobile phone clusters, characterized in that, The application containerization sharing management system for cloud mobile phone clusters is applied to the application containerization sharing management method for cloud mobile phone clusters as described in any one of claims 1 to 7, and the system includes: A cloud application container repository is used to encapsulate mobile applications and their runtime environments into read-only application container images and store them in the cloud application container repository. The application access proxy module is used to respond to the user's application launch operation on a certain cloud phone lightweight instance. The application access proxy module running on the cloud phone lightweight instance intercepts the launch operation and generates an instantiation request containing user identifier, instance identifier and application identifier, and sends the instantiation request to the application routing and session management layer. The application routing and session management layer is used to query whether there is a corresponding active application container session based on the instantiation request. If there is no session, a start command is issued to the service cluster where the application container is running. The application container runtime service cluster is used to obtain the corresponding application container image from the cloud application container repository according to the startup instruction, and start the application container process, wherein the application container process is an independent and isolated application container process. The storage management module creates and mounts an independent private data volume for the started application container process, wherein the private data volume is used to persistently store the private data of the corresponding user within the application; The communication channel establishment module establishes a communication channel between the started application container process and the cloud phone lightweight instance that initiates the instantiation request for transmitting application rendering screens and user input events. The application container process executes application logic, while the cloud phone lightweight instance is responsible for the presentation of the interactive interface and input collection.

9. A containerized shared management device for cloud mobile phone clusters, characterized in that, The application containerization sharing management device for cloud mobile phone clusters includes: a memory, a processor, and an application containerization sharing management program for cloud mobile phone clusters stored on the memory and capable of running on the processor. The application containerization sharing management program for cloud mobile phone clusters is configured to implement the steps of the application containerization sharing management method for cloud mobile phone clusters as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores an application containerization sharing management program for cloud mobile phone clusters. When the application containerization sharing management program for cloud mobile phone clusters is executed by the processor, it implements the steps of the application containerization sharing management method for cloud mobile phone clusters as described in any one of claims 1 to 7.

Images