Patent Description:
Container technology is a lightweight operating system-level virtualization that allows to run an application service and its dependencies in a process with resources isolated. Components necessary for running of the application service are packaged into an image and can be reused. Compared with VMs, each VM instance needs to run a complete copy of an operating system, and a large quantity of application programs are included in the copy. Therefore, it takes a period of time to start the operating system and initialize the application programs. The container is a lightweight operating system, and its size is much smaller than that of the complete copy of the operating system (generally within <NUM> MB), and can be started within several seconds. The container has advantages of fast deployment, high efficiency, and higher security, and an application range is becoming wider.

Communication between different processes in a same container may be implemented by using a driver in a kernel of an operating system on a server. During a process of concurrent running of a plurality of containers in a conventional technology, an earlier registered container may first apply for a memory storage space as shared memory by using the driver in the kernel, store request content of each request message by using the shared memory, and record an operation object of each request message by using a global service linked list. Then, a later registered container may re-apply for a new storage space as new shared memory by using the driver in the kernel. In this case, all containers need to switch to a shared memory that is latest applied for to store requested content of each request. Based on the implementation process of the foregoing technical solution, when different containers share a same memory space, data inconsistency may occur, affecting normal running of an application service in the container.

Therefore, how to ensure consistency of data processing processes of a plurality of containers when a plurality of containers run concurrently to avoid affecting normal running of applications in the containers becomes an urgent problem in the industry.

<CIT> describes a method for accessing services across domains.

This application provides a data processing method, to ensure consistency of data processing processes of a plurality of containers during concurrent running of a plurality of containers, and to avoid affecting normal running of an application service in the container.

Additional embodiments are defined by the dependent claims.

<FIG> is a schematic architectural diagram of a container system according to an embodiment of this application. As shown in the figure, an architecture of the container system may include a hardware layer and a software layer. The hardware layer and the software layer are separately described in detail below.

The hardware layer is not specifically limited in this embodiment of this application, and may be, for example, an X86 server, an advanced reduced instruction set machine (advanced reduced instruction set computing machine, ARM) server, or may be a heterogeneous server.

The hardware layer may include but is not limited to a processor <NUM>, a memory <NUM>, a hard disk <NUM>, and a network adapter <NUM>. The processor <NUM>, the memory <NUM>, the hard disk <NUM>, and the network adapter <NUM> may be connected by using an internal connection path (for example, a bus).

The software layer includes an operating system <NUM>. The operating system <NUM> is not specifically limited in this embodiment of this application, and may be, for example, a Linux operating system or a Windows operating system. A driver <NUM> and a container <NUM> run on the operating system <NUM>.

The container <NUM> is a lightweight operating system-level virtualization that allows us to run an application service and its dependencies in a process with resources isolated. The system architecture shown in <FIG> includes a plurality of containers <NUM>, each container <NUM> may run one operating system, and operating systems running in different containers <NUM> may be the same or may be different. In the following description of this embodiment of this application, that an Android (Android) operating system runs in the container <NUM> is used as an example for description. For ease of description, a container running the Android operating system may also be referred to as an Android container (Android in a box, Anbox).

The driver <NUM> may implement communication between components in the software layer and the hardware layer. It should be noted that the driver <NUM> is further related to a type of the operating system <NUM>. The driver <NUM> varies with the operating system <NUM>.

The driver <NUM> further includes a namespace <NUM>, and the namespace <NUM> is managed by the driver <NUM>. The namespace <NUM> is a technology developed to resolve a naming problem in a same scope. A namespace allows a variable, a function name, and a class name to be applied in a local space, while another space can use a same name. This is similar to the following: Different folders can have a same file name, but a same folder cannot have repeated file names. The namespace is similar to this virtual folder. The namespace <NUM> may be represented by using a structure. In this embodiment of this application, the structure may include but is not limited to a pointer and a head of a linked list.

With reference to <FIG>, the following describes in detail the technical solutions of the embodiments of this application by using an example in which the operating system <NUM> is a Linux operating system, the driver <NUM> is an Android driver, the container <NUM> is an Android container, and the namespace <NUM> is an Android namespace. The Android driver may be a binder driver, and the Android namespace may be a binder namespace.

It should be understood that the Android container is a container technology-based virtualization solution. The Android container may use the Android namespace, start and run an Android system in the Linux operating system, and provide an Android application (application, APP).

<FIG> is a schematic architectural diagram of another container system according to an embodiment of this application. As shown in the figure, an architecture of the container system may include a hardware layer <NUM> and a Linux operating system <NUM>.

The Linux operating system <NUM> includes a kernel <NUM>. The kernel <NUM> is an important part of the Linux operating system <NUM>, and may be configured to manage some underlying functions. The functions may include but are not limited to scheduling memory and processes. The kernel <NUM> may further include a driver, for example, an Android driver <NUM>.

The Linux operating system <NUM> may run one or more Android containers, for example, an Android container <NUM>, an Android container <NUM>, and an Android container <NUM>. One Android container includes at least one Android application service, and each Android application service may run a plurality of processes.

For processes, all memory addresses used are virtual memory addresses, and the virtual memory address can be divided into a plurality of virtual pages. Each process maintains a separate page table. The page table is an array structure that stores a status of each virtual page and is used to record whether each virtual page is mapped. In the Linux operating system <NUM>, each process is allocated a memory address, and the Linux operating system <NUM> maps such a virtual memory address to a physical memory address. Each process has its respective virtual memory address and cannot operate virtual memory of another process. Each process can operate only its respective virtual memory, and only the Linux operating system <NUM> has a permission to operate a physical memory address. However, in most cases, data communication between different processes in a same container is inevitable. Therefore, the Linux operating system <NUM> needs to provide an inter-process communication mechanism.

Based on memory operation permissions of processes, an operation scope of processes can be divided into a user mode and a kernel mode. The user mode may indicate that a process runs in a specific operation mode, has no permission to access physical memory or a device, can only access memory with a limited permission, and cannot access a peripheral device. The kernel mode may indicate that a process can access a protected memory space, and also have all permissions to access an underlying hardware device, for example, the hard disk <NUM> and the network adapter <NUM>.

Referring to <FIG>, the Android container <NUM>, the Android container <NUM>, and the Android container <NUM> may belong to the user mode. The kernel <NUM> and the Android driver <NUM> may belong to the kernel mode. In the Android system, the Android container may access the memory by using the Android driver <NUM> that runs in the kernel mode, so that communication between different processes in the Android container can be implemented, and data is transferred from one process to another process.

It should be understood that the memory in this embodiment of this application may correspond to the memory <NUM> in <FIG>.

A service manager (service manager, SM) is deployed in each container. The service manager may manage an application service in the container, and is responsible for communicating with the Android driver <NUM>, so as to implement communication between processes in the container. For example, a service manager <NUM> in the container <NUM>, a service manager <NUM> in the container <NUM>, and a service manager <NUM> in the container <NUM>. A service manager runs in a container or a service manager may be considered as a process in a container where the service manager resides. Correspondingly, for different service managers, a process identifier (process identification, PID) may be allocated for the service manager in the kernel <NUM>.

In the kernel <NUM>, different processes are associated with different inter-process communication (inter-process communication, IPC) namespaces, that is, different processes are isolated by using different inter-process communication namespaces, to implement independence of each process. In this embodiment of this application, a namespace filtering module <NUM> is further added to the Android driver <NUM>. The namespace filtering module <NUM> is configured to associate each service manager with an inter-process communication namespace in the kernel <NUM>, and apply for associated Android namespaces in the memory for different containers. For example, the namespace filtering module <NUM> applies for an associated Android namespace <NUM> in the Android driver <NUM> for the container <NUM>, applies for an associated Android namespace <NUM> in the Android driver <NUM> for the container <NUM>, and applies for an associated Android namespace <NUM> in the Android driver <NUM> for the container <NUM>.

Before each container runs, a registration procedure needs to be completed. For ease of description, the following uses the container <NUM> as an example to further describe a procedure in which the service manager <NUM> in the container <NUM> registers with the Android driver <NUM> and runs.

Before the container <NUM> runs, the service manager <NUM> in the container <NUM> needs to register with the Android driver <NUM>. Specifically, the service manager <NUM> may invoke an interface to register with the Android driver <NUM>. For example, the service manager <NUM> may invoke an interface function (for example, an open interface function) of the Android driver <NUM> by using a preset function (for example, a binder open function) to perform registration.

When the service manager <NUM> in the container <NUM> initiates registration to the Android driver <NUM> by using the preset function, the namespace filtering module <NUM> in the Android driver <NUM> may apply for a memory space associated in the memory with the container <NUM>, where the memory space may be referred to as the Android namespace <NUM>. In addition, a structure of the Android namespace <NUM> may be generated on the Android namespace <NUM>. The structure may include but is not limited to: an address pointer of private memory applied for by the namespace filtering module <NUM> for the container <NUM>, a head of a private service linked list applied for by the namespace filtering module <NUM> for the container <NUM>, and a process lock.

It should be understood that a size of a memory space occupied by the Android namespace <NUM> is the same as a size of a memory space required by the structure of the Android namespace <NUM>. Because information such as a pointer of a private linked list, the head of the private service linked list, and the process lock is stored in the structure of the Android namespace <NUM>, a memory size occupied by the information is fixed. Therefore, the Android driver <NUM> may apply for, for the container <NUM> based on a memory size occupied by the structure of the Android namespace <NUM>, the Android namespace <NUM> associated in the memory.

After applying for the Android namespace <NUM> associated in the memory for the container <NUM>, the namespace filtering module <NUM> may apply for private memory <NUM> in the memory for the container <NUM>, and create a private service linked list <NUM> for the container <NUM>. The private memory <NUM> and the private service linked list <NUM> are private only to the container <NUM>. The namespace filtering module <NUM> may store an address pointer of the private memory <NUM> into the structure of the Android namespace <NUM> generated above, and store a head of the private service linked list into the structure of the Android namespace <NUM>.

The service manager <NUM> runs in the container <NUM> in a process of registering with the Android driver <NUM> by the service manager <NUM> in the container <NUM>, the service manager <NUM> may also be understood as a process in the container <NUM> in which the service manager <NUM> is located, and the kernel <NUM> allocates a PID for the service manager <NUM>. Therefore, the namespace filtering module <NUM> may determine, based on the PID of the service manager <NUM>, an inter-process communication namespace associated in the memory with the service manager <NUM>. The namespace filtering module <NUM> may store a pointer of the structure of the Android namespace <NUM> associated in the memory with the container <NUM> into a structure of the inter-process communication namespace associated in the memory with the service manager <NUM>. The structure of the inter-process communication namespace may include the pointer of the structure of the Android namespace <NUM>.

It should be understood that addresses of the private memory <NUM> may be consecutive or may be inconsecutive. This is not specifically limited in this embodiment of this application. When the addresses of the private memory <NUM> are inconsecutive, they may be stored in the structure of the Android namespace <NUM> based on a start address of the physical memory and a memory size.

The following uses the private memory <NUM> and the private service linked list <NUM> of the container <NUM> as an example for detailed description.

Private service linked list <NUM>: When the container <NUM> registers with the Android driver <NUM>, the namespace filtering module <NUM> may create a private service linked list <NUM> of the container <NUM> in the memory (for example, the memory <NUM> shown in <FIG>). A head of the private service linked list <NUM> is stored in the structure of the Android namespace <NUM> associated in the memory with the container <NUM>. The head of the private service linked list <NUM> has a pointer that points to the next node address in the linked list.

Private memory <NUM>: When the container <NUM> registers with the Android driver <NUM>, the namespace filtering module <NUM> may apply in the memory (for example, the memory <NUM> shown in <FIG>) for a <NUM>-KB storage space that is private to the container <NUM>. During a storage process, the storage space may be dynamically expanded based on a size of stored content in a unit of <NUM> MB.

It should be noted that an application service running in the container <NUM> may include a plurality of processes, and different processes in the application service may communicate with each other. That a first process of the application service running in the container <NUM> sends a request message for inter-process communication to a second process of the application service is used as an example. The request message may include control information and content information.

The namespace filtering module <NUM> may record the control information in the request message sent by the container <NUM> into the private service linked list <NUM>. For example, information recorded in the private service linked list <NUM> may include but is not limited to: an identifier ID of the first process, an identifier ID of the second process, information indicating that the first process is a requesting party sending a request message, and information indicating that the second process is a requested party needing to be notified by the server to perform request message processing.

The namespace filtering module <NUM> may store the content information in the request message sent by the container <NUM> into the private memory <NUM>. The content information in the request message includes specific content and data of the service request sent by the first process as a requesting party to the second process. For example, content stored in the private memory <NUM> may be that the first process requests to use a service of the second process. For another example, content stored in the private memory <NUM> may be that the first process requests to obtain data of the second process in the memory.

In this embodiment of this application, the private memory <NUM> may be shared by the kernel-mode Android driver <NUM> and the user-mode service manager <NUM>, and data is copied. Specifically, when the Android driver <NUM> applies for the private memory <NUM> in the memory for the container <NUM>, a kernel-mode virtual address and a user-mode virtual address may be mapped to a same physical page, so that the user-mode address and the kernel-mode address share one physical page. When the container <NUM> uses the private memory <NUM>, the physical address needs to be obtained from an interface of the Android driver <NUM> by using the service manager <NUM>.

In a running process of the container <NUM>, the application service running in the container <NUM> may include a plurality of processes, and the plurality of processes may communicate with each other. For ease of description, that the first process of the application service running in the container <NUM> sends an inter-process communication request message to the second process is used as an example for description.

It should be noted that an architecture used in a process of mutual communication between processes in a same container is a client/server (client/server, C/S) architecture, that is, a client and a server are deployed in each container. For example, a client <NUM> and a server <NUM> are deployed in the container <NUM>.

The server is configured to manage and schedule each process of the application service to process a request message. The client is configured to receive a request message of each process of the application service. For example, the client may receive a request message for obtaining or using a service by any process. Essentially, the server and the client can be modules implemented by software programs. For example, a first process of an application service in a same container requests communication with a second process. A client receives a request message of the first process to communicate with a second process, and sends the request message to a service manager in which the container is located, the service manager sends the request message to an Android driver, and then the Android driver stores the request message into an Android container associated with the container. The server may obtain the request message in an Android namespace, and notify the second process that there is a request needing to be processed, so as to implement communication between the first process and the second process. The second process, as a client, may use such a notification service provided by the server, to process the request message sent by the first process.

Optionally, in an architecture in which processes in a same container communicate with each other, each process may also serve as a client, and when needing to communicate with another process, the process directly sends a request message to a service manager. The service manager sends the request message to an Android driver, and then the Android driver stores the request message into an Android container associated with the container. The server may obtain the request message in an Android namespace, and notify the second process that there is a request that needs to be processed, so as to implement communication between the first process and the second process. The second process, as a client, may use such a notification service provided by the server, to process the request message sent by the first process.

For example, the first process of the application service in the container <NUM> may send the request message to the service manager <NUM> in the container <NUM>. After receiving the request message sent by the first process, the service manager <NUM> in the container <NUM> may send the request message to the namespace filtering module <NUM> in the Android driver <NUM>. The namespace filtering module <NUM> may determine, based on the PID of the service manager <NUM> in the container <NUM>, the inter-process communication namespace associated in the memory with the service manager <NUM>, and obtain, from the structure of the inter-process communication namespace, the pointer of the structure of the Android namespace <NUM> associated in the memory with the container <NUM>. The namespace filtering module <NUM> obtains the address pointer of the private memory <NUM> and the head of the private service linked list <NUM> from the structure of the Android namespace <NUM>, so that the control information in the request message sent by the first process in the container <NUM> may be recorded into the private service linked list <NUM>, and the content information in the request message may be recorded into the private memory <NUM>. For detailed descriptions of the control information and the content information in the request message, refer to descriptions in the foregoing container registration process.

After the namespace filtering module <NUM> in the Android driver <NUM> records the control information in the request message sent by the container <NUM> into the private service linked list <NUM>, and stores the content information into the private memory <NUM>, the server <NUM> in the container <NUM> may query, by using the service manager <NUM>, the Android driver <NUM> for whether there is a request message needing to be processed by the server. Processing the request message by the server may be understood as modifying, by the server, a format of the content information stored by the container <NUM> in the private memory <NUM>, so that the second process, needing to process the request message, in the container <NUM> receives the request message and performs a corresponding action based on the content information in the request message. Optionally, the second process may be in a dormant state, and when the container <NUM> determines that there is a request message needing to be processed by the second process, the container <NUM> wakes up the process to process the request message.

Specifically, the server in the container <NUM> may periodically query, by using the service manager <NUM>, the Android driver <NUM> for whether there is a request message needing to be processed by the server. The namespace filtering module <NUM> in the Android driver <NUM> may determine, based on the PID of the service manager <NUM>, the inter-process communication namespace associated in the memory with the service manager <NUM>, and obtain, from the structure of the inter-process communication namespace, the address pointer of the Android namespace <NUM> associated with the container <NUM>. The namespace filtering module <NUM> then obtains the address pointer of the private memory <NUM> and the head of the private service linked list <NUM> from the structure of the Android namespace <NUM>. Then, the namespace filtering module <NUM> queries, based on a pointer that points to a next node address and that is in the head of the private service linked list <NUM>, whether the private service linked list <NUM> records that the server in the container <NUM> needs to notify the second process needing to process the request message. If the private service linked list <NUM> records related control information, the control information, recorded in the private service linked list <NUM>, of the request message is returned to the server in the container <NUM>. The server in the container <NUM> may copy stored request content from the private memory <NUM> based on an address of the private memory <NUM>, and after modifying a data format of the request content, re-store the request content of the modified data format into the private memory <NUM>.

In the technical solution provided in this application, each container is allocated its respective private memory and private service linked list, so as to avoid data inconsistency caused by sharing same memory by a plurality of containers in a conventional technology and impact on service processing.

The following further describes a data processing method provided in an embodiment of this application with reference to <FIG> and <FIG> by using any container as an example. For ease of description, any container is simply referred to as a first container below, the first container includes a first service manager, an Android namespace associated with the first container is a first Android namespace, and the first Android namespace further includes first private memory and a first private service linked list. The example in <FIG> and <FIG> is merely intended to help a person skilled in the art understand the embodiment of this application, but is not intended to limit the embodiment of this application to a specific value or a specific scenario shown in the example. Apparently, a person skilled in the art may make various equivalent modifications or changes based on the example given in <FIG> and <FIG>.

<FIG> and <FIG> are schematic flowcharts of a data processing method according to an embodiment of this application. As shown in the figure, the data processing method includes a container registration process, a running process, and a resource release process. The registration process includes step <NUM>, the running process includes steps <NUM> to <NUM>, and the resource release process includes steps <NUM> to <NUM>. The following separately describes the foregoing three processes in detail.

Step <NUM>: A first service manager in a first container registers with an Android driver.

Before running, the first container needs to complete a registration procedure, and the first service manager in the first container may initiate registration to the Android driver by using a preset function. A namespace filtering module in the Android driver applies in memory for first private memory of the first container and creates a first private service linked list of the first container. The first private memory is used only to store content information in a request message sent by a first process of an application service in the first container, and the first private service linked list is used only to record control information in the request message sent by the first process of the application service in the first container. For a detailed registration process, refer to descriptions in <FIG>.

Step <NUM>: A client in the first container sends a request message to the first service manager.

After registering with the Android driver, the first service manager may process a request message of a process of the application service running in the container. For ease of description, the first process of the application service in the first container is used as an example for description. The first process may serve as a client to send a request message to the first service manager. The request message includes control information and content information. The control information includes but is not limited to an identifier ID of the first process and an identifier ID of the second process. The first process is a requesting party that sends a request message, and the second process is a requested party needing to be notified by the server to perform request message processing. The content information in the request message includes specific content and data of the service request sent by the first process as a requesting party to the second process. For example, the content information may be that the first process requests to use a service of the second process. For another example, the content information may be that the first process requests to obtain data of the second process in the memory.

Step <NUM>: The first service manager sends the request message to the Android driver.

Step <NUM>: The Android driver records the control information in the request message into the first private service linked list.

After receiving the request message sent by the first service manager, the Android driver <NUM> may obtain, based on a PID of the first service manager, an inter-process communication namespace associated in the memory with the first service manager, and obtain, from a structure of the inter-process communication namespace, a pointer of a structure of a first Android namespace applied for by the first container in the registration procedure. The namespace filtering module may obtain a head of the first private service linked list and an address pointer of the first private memory from the structure of the first Android namespace, so that the control information in the request message sent by the first process in the first container may be recorded into the first private service linked list.

Step <NUM>: The Android driver stores the content information in the request message into the first private memory.

After receiving the request message sent by the first service manager, the Android driver may obtain an address of the first private memory of the first container according to the method in step <NUM>, and may store the content information in the request message sent by the first process into the first private memory.

It should be noted that there is no sequence relationship between step S325 and step S330, and step <NUM> may be performed before step S330 is performed. Alternatively, step S330 may be performed first, and then step <NUM> is performed. Alternatively, step <NUM> and step <NUM> are performed simultaneously. This is not limited in this application.

Step <NUM>: A server in the first container queries, by using the first service manager, whether there is a to-be-processed request message.

The server in the first container may periodically query, by using the first service manager, whether there is a to-be-processed request message. For example, the first process in the first container needs to send a request message to the second process, and when the server in the first container determines that there is a request message needing to be processed by the second process, the server may notify the second process to process the request message.

Step <NUM>: The first service manager queries, by using the Android driver, whether there is a to-be-processed request message.

Step <NUM>: The Android driver queries the control information recorded in the first private service linked list.

The namespace filtering module in the Android driver may obtain the head of the first private service linked list of the first container in the first Android namespace based on the PID of the first service manager with reference to the method in step <NUM>. The namespace filtering module may query, based on a pointer that points to a next address in the linked list and that is in the head of the first private service linked list, whether the first private service linked list records that the server in the first container needs to notify the second process needing to process the request message. If the first private service linked list records related control information, the control information, recorded in the first private service linked list, of the request message is returned to the server of the first container.

Step <NUM>: The first service manager obtains the content information in the request message from the first private memory.

The first service manager may obtain the content information in the request message based on the address of the first private memory, and send the content information stored in the first private memory to the server of the first container.

Step <NUM>: The first service manager sends the content in the request message to the server of the first container for processing.

The server in the first container may obtain the control information recorded in the first private linked list. When it is determined that the second process in the first container needs to process the request message sent by the first process, the server may process the content information in the request message sent by the first process, so that the second process, needing to process the request message, in the first container <NUM> receives the request message, and performs a corresponding action based on the content information in the request message.

Processing the request message by the server in the first container may be understood as modifying, by the server, a format of the content information stored by the first process in the first container in the private memory <NUM>. For example, when the first process in the first container serves as a client to request a service from the server, a preset interface function (for example, a transact interface function) is actually invoked, and a data format of the content information in the request message sent by the first process complies with a structure format of the interface. When notifying the second process that there is a request message needing to be processed, the server also needs to invoke a preset interface function (for example, a notify interface function), and a data format of the content information of the sent request message should comply with a structure format of the interface. Therefore, the server needs to modify a format of the content information stored by the first process in the private memory <NUM>, so that the second process, needing to process the request message, in the first container can receive the request message, and perform a corresponding action based on the content information in the request message.

Step <NUM>: The server of the first container may send content information of the modified data format to the first service manager.

Step <NUM>: The first service manager sends the content information of the modified data format to the Android driver.

Step <NUM>: The Android driver stores the content information of the modified data format into the first private memory.

The Android driver may delete the information content stored by the first process in the first private memory, and may reassign a storage space in the first private memory, and store the content information of the modified data format into the first private memory.

Step <NUM>: The first service manager notifies the second process in the first container.

After the first process in the first container sends the request message to the first service manager, the second process, needing to be notified by the server, in the first container may be in a waiting state, waiting for the server in the container <NUM> to notify the second process to process the request message.

It should be noted that when the second process is processing another request message, the second process is in a working state, and the server needs to wait for the second process to complete processing of the another request message. In this case, a plurality of request messages may be stored in a queue, and the request messages may be processed one by one. The queue may be a first in first out (first input first output, FIFO) queue.

Step <NUM>: The waiting second process in the first container obtains content in the request message from the first private memory.

The second process, needing to be notified by the server, in the first container may obtain the content of the request message from the first private memory. Specifically, with reference to the method in step <NUM>, the second process obtains an address pointer of the first private memory in the first Android namespace of the first container, and obtains the content information of the request message stored in the first private memory to which the pointer points.

When the first container needs to be deleted, a resource of the first container is released, and in this case, a resource of the Android namespace associated with the first container is also released. Next, a process of releasing the first Android namespace is further described with reference to steps <NUM> to <NUM>.

Step <NUM>: The Android driver receives a request for releasing a resource of the first container.

Specifically, the request for releasing a resource of the first container may be generated by an operating system according to an instruction from an operation and maintenance person, or may be sent by a container manager (not shown in <FIG>) to the Android driver.

Step S385: The Android driver releases the first private service linked list.

The Android driver may determine, based on the PID of the first service manager <NUM>, the first Android namespace associated in the memory with the first container, obtain the head of the first private service linked list stored in the structure of the first Android namespace, and further release a storage space occupied by the first private service linked list. Releasing the first private service linked list includes deleting content and a data structure of the first private service linked list, and then releasing the storage space corresponding to the first private service linked list.

Step <NUM>: The Android driver releases a storage space corresponding to the first private memory address.

The Android driver may determine the first Android namespace of the first container based on the PID of the first service manager, obtain the address pointer of the first private memory stored in the structure of the first Android namespace, and release the storage space occupied by the first private memory to which the pointer points. Releasing the first private memory includes deleting data in the first private memory.

Step <NUM>: The Android driver releases a storage space corresponding to an address of the structure of the first Android namespace.

The Android driver may delete the pointer stored in the structure of the first Android namespace, and may release a storage space occupied by the structure of the first Android namespace.

It should be noted that there is no sequence relationship between step S385 and step S390, and step <NUM> may be performed before step S390 is performed. Alternatively, step S390 may be performed first, and then step <NUM> is performed. Alternatively, step <NUM> and step <NUM> are performed simultaneously. This is not limited in this application.

This embodiment of this application may further improve performance of concurrent running of a plurality of containers and ensure consistency of data processing processes of a plurality of containers. The following describes, by using the container <NUM>, the container <NUM>, and the container <NUM> in <FIG> as an example, a process of concurrent running of a plurality of container instances in this embodiment of this application.

In a container startup phase, a service manager of each container registers with an Android driver <NUM>, and the Android driver <NUM> may apply in memory for an Android namespace associated with each container, and private memory and a private service linked list of each container. For example, the Android driver applies for an Android namespace <NUM> for the container <NUM>, where the Android namespace <NUM> includes a private service linked list <NUM> and a private service linked list <NUM>. The Android driver applies for an Android namespace <NUM> for the container <NUM>, where the Android namespace <NUM> includes a private service linked list <NUM> and a private service linked list <NUM>. The Android container applies for an Android namespace <NUM> for the container <NUM>, where the Android namespace <NUM> includes a private service linked list <NUM> and a private service linked list <NUM>. Each private memory is isolated from another and is used to store content information of only one container. Each private service linked list is used to store control information of only one container.

When a plurality of containers run concurrently, a namespace filtering module <NUM> may determine, based on PIDs of service managers in different containers, different inter-process communication namespaces associated with the service managers, further obtain, from structures of the inter-process communication namespaces, Android namespaces associated with the different containers, and then obtain, from the structures of the Android namespaces associated with the different containers, addresses of private memory and private service linked list addresses of the different containers.

In this embodiment of this application, private memory and a private service linked list that are used only to store data of a single container may be applied for, so as to resolve a data inconsistency problem in a conventional technology caused by using shared memory and a shared global service linked list by a plurality of containers during concurrent running of a plurality of containers. In addition, during registration, each container applies for an associated Android namespace and its exclusive private memory and private service linked list. The private memory and private service linked list used by each container are independent, thereby avoiding a problem in a conventional technology that each registration of a new container requires re-application of new shared memory, which causes a complex procedure and time wasting because an earlier registered container needs to be switched to the new shared memory. In addition, each container separately uses its respective private memory and private service linked list, which can further avoid a time sequence problem caused when a plurality of containers use shared memory and a shared global data linked list, thereby further reducing service processing duration of a system, and improving working efficiency of concurrent processing of a plurality of containers.

The foregoing describes in detail the data processing methods provided in the embodiments of this application with reference to <FIG> and <FIG>. The following describes in detail apparatus embodiments of this application with reference to <FIG>. It should be understood that the description of the method embodiments corresponds to the description of the apparatus embodiments. Therefore, for a part that is not described in detail, refer to the foregoing method embodiments.

<FIG> is a schematic structural diagram of a data processing apparatus <NUM> according to an embodiment of this application. The data processing apparatus <NUM> includes a receiving module <NUM>, a sending module <NUM>, a determining module <NUM>, and a processing module <NUM>.

The receiving module <NUM> is configured to receive a request message of a first process by the first service manager, where the first process is a process of any application service in the first container, the request message includes control information, content information, and a process identifier PID of the first service manager, the PID is used to uniquely identify the first service manager, the control information is used to record identifiers of the first process and the second process, the second process is a process that is of an application service and that is to process the request message, and the content information is used to indicate content and data of the service request.

The sending module <NUM> is configured to send the request message to the Android driver by the first service manager.

The determining module <NUM> is configured to determine, by the Android driver based on the process identifier PID of the first service manager in the request message, a first inter-process communication IPC namespace associated with the first service manager, and determine, based on a pointer of a structure of the first IPC namespace, a first Android namespace associated with the first container, where the first Android namespace is used to record first private memory and a first private service linked list of the first container.

The processing module <NUM> is configured to: store, by the Android driver, the control information into the first private service linked list, and store the content information into the first private memory.

It should be understood that the data processing apparatus <NUM> in this embodiment of this application may be implemented by using an application-specific integrated circuit (application-specific integrated circuit, ASIC) or a programmable logic device (programmable logic device, PLD). The PLD may be a complex programmable logical device (complex programmable logical device, CPLD), a field-programmable gate array (field-programmable gate array, FPGA), a generic array logic (generic array logic, GAL), or any combination thereof. Alternatively, when the data processing method shown in <FIG> and <FIG> may be implemented by using software, the data processing apparatus <NUM> and the modules of the data processing apparatus <NUM> may be software modules.

Optionally, in some embodiments, the data processing apparatus <NUM> further includes an application module <NUM>.

The receiving module <NUM> is further configured to receive, by the Android driver, a first registration request sent by the first service manager, where the first registration request includes the PID of the first service manager.

The application module <NUM> is configured to apply, by the Android driver, for the first Android namespace for the first container.

The application module <NUM> is further configured to apply, by the Android driver, for the first private memory for the first container, and create the first private service linked list.

Optionally, in some embodiments, the data processing apparatus <NUM> further includes a storage module <NUM>.

The storage module <NUM> is configured to store, by the Android driver, an address pointer of the first private memory and a head of the first private service linked list into a structure of the first Android namespace.

The storage module <NUM> is further configured to store, by the Android driver, an address pointer of the first Android namespace into the structure of the first IPC namespace based on the PID of the first service manager.

Optionally, in some embodiments, the determining module <NUM> is specifically configured to: obtain, by the Android driver, a pointer of the structure of the first Android namespace from the structure of the first IPC namespace; and determine, by the Android driver, the first Android namespace based on the pointer of the structure of the first Android namespace.

Optionally, in some embodiments, the receiving module <NUM> is further configured to receive, by the Android driver, a second registration request sent by the second service manager, where the second registration request includes a PID of the second service manager.

The application module <NUM> is further configured to apply, by the Android driver, for a second Android namespace for the second container, where an address pointer of the second Android namespace is stored in a structure of a second IPC namespace associated with the second service manager.

The application module <NUM> is further configured to apply, by the Android driver, for second private memory for the second container, and create a second private service linked list, wherein the second private memory and a head of the second private service linked list are stored in the structure of the second Android namespace, the second private memory is used only to store content information in a request message sent by a process of an application service in the second container, and the second private service linked list is used only to store control information in the request message sent by the process of the application service in the second container.

Optionally, in some embodiments, the data processing apparatus <NUM> further includes a release module <NUM>.

The receiving module <NUM> is further configured to receive a deletion request of the first container.

The release module <NUM> is configured to: when the first container needs to be deleted, release, by the Android driver, a storage space occupied by the first private service linked list and the first private memory.

The data processing apparatus <NUM> according to this embodiment of this application may correspondingly perform the method described in the embodiments of this application, and the foregoing and other operations and/or functions of the units in the data processing apparatus <NUM> are respectively used to implement corresponding procedures of the method in <FIG> and <FIG>. For brevity, details are not described herein again.

<FIG> is a schematic structural diagram of a server <NUM> according to an embodiment of this application. The server <NUM> includes a processor <NUM>, a memory <NUM>, a communications interface <NUM>, and a bus <NUM>.

It should be understood that the processor <NUM> in the server <NUM> shown in <FIG> may correspond to the processing module <NUM> and the determining module <NUM> in the data processing apparatus <NUM> in <FIG>. The communications interface <NUM> in the server <NUM> may correspond to the first receiving module <NUM> and the sending module <NUM> in the data processing apparatus <NUM>.

The processor <NUM> may be connected to the memory <NUM>. The memory <NUM> may be configured to store program code and data. Therefore, the memory <NUM> may be a storage unit inside the processor <NUM>, or may be an external storage unit independent of the processor <NUM>, or may be a component including a storage unit inside the processor <NUM> and an external storage unit independent of the processor <NUM>.

Optionally, the server <NUM> may further include a bus <NUM>. The memory <NUM> and the communications interface <NUM> may be connected to the processor <NUM> by using the bus <NUM>. The bus <NUM> may be a peripheral component interconnect (Peripheral Component Interconnect, PCI) bus, an extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus, or the like. The bus <NUM> may be an address bus, a data bus, a control bus, and the like. For ease of representation, only one line is used for representation in <FIG>, but it does not mean that there is only one bus or only one type of bus.

It should be understood that, in this embodiment of this application, the processor <NUM> may use a central processing unit (central processing unit, CPU). The processor may be another general purpose processor, a digital signal processor (digital signal processor, DSP), an application-specific integrated circuit (application specific integrated circuit, ASIC), or a field programmable gate array (field programmable gate Array, FPGA) or another programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, or the like. The general purpose processor may be a microprocessor, or the processor may be any conventional processor, or the like. Alternatively, the processor <NUM> uses one or more integrated circuits, and is configured to execute a related program, to implement the technical solutions provided in the embodiments of this application.

The memory <NUM> may include a read-only memory and a random access memory, and provide an instruction and data for the processor <NUM>. A part of the processor <NUM> may further include a nonvolatile random access memory. For example, the processor <NUM> may further store information about a storage device type.

When the server <NUM> runs, the processor <NUM> executes a computer executable instruction in the memory <NUM>, to perform the operation steps of the foregoing method by using a hardware resource in the server <NUM>.

It should be understood that the server <NUM> according to this embodiment of this application may correspond to the data processing apparatus <NUM> in the embodiments of this application, and may correspond to a corresponding entity that performs the method shown in <FIG> in the embodiments of this application. In addition, the foregoing and other operations and/or functions of the modules in the server <NUM> are respectively used to implement corresponding procedures of the method in <FIG> and <FIG>. For brevity, details are not described herein again.

All or some of the foregoing embodiments may be implemented by using software, hardware, firmware, or any other combination. When software is used to implement the foregoing embodiments, all or some of the foregoing embodiments may be implemented in a form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, all or some of the procedures or functions according to the embodiments of this application are generated. The computer may be a general-purpose computer, a dedicated computer, a computer network, or another programmable apparatus. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions may be transmitted from a website, computer, server, or data center via wired (for example, through a coaxial cable, an optical fiber, or a digital subscriber line (DSL)) or wireless (for example, infrared, wireless, or microwave) transmission to another website, computer, server, or data center. The computer-readable storage medium may be any usable medium accessible by a computer, or a data storage device such as a server or a data center that includes one or more usable medium sets. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, or a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium. The semiconductor medium may be a solid state drive (solid state drive, SSD).

A person of ordinary skill in the art may be aware that units and algorithm steps in the examples described with reference to the embodiments disclosed in this specification may be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether these functions are performed in a hardware or software manner depends on specific applications and design constraints of the technical solution. A person skilled in the art may use different methods to implement the described functions for each specific application.

In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented by using some interfaces, and the indirect couplings or communication connections between the apparatuses or units may be implemented in electrical, mechanical, or other forms.

Claim 1:
A data processing method, wherein the method is performed by a server, the server comprises a first container and an Android operating system driver, a first service manager is deployed in the first container, the first service manager is configured to manage a plurality of application services of the first container, each application service comprises at least two processes, and the method comprises:
receiving (S315), by the first service manager, a request message of a first process, wherein the first process is a process of any application service of the first container, the request message comprises control information, content information, and a process identifier PID of the first service manager, the PID is used to uniquely identify the first service manager, the control information is used to record identifiers of the first process and a second process, the second process is an application process of the first container that is to process the request message, and the content information is used to indicate content and data of the request message;
sending (S320), by the first service manager, the request message to the Android driver;
determining, by the Android driver based on the process identifier PID of the first service manager in the request message, a first inter-process communication IPC namespace associated with the first service manager, and determining, by the Android driver based on a pointer of a structure of the first IPC namespace, a first Android namespace associated with the first container, wherein the first Android namespace is used to record a first private memory and a first private service linked list of the first container; and
storing (S325), by the Android driver, the control information into the first private service linked list, and storing (<NUM>) the content information into the first private memory; wherein the first private memory is used only to store the content information in the request message sent by the first process of the application service of the first container, wherein the first private service linked list is used only to record the control information in the request message sent by the first process of the application service of the first container.