操作系统容器之间通讯的系统和方法与流程

本申请要求于2016年6月20日提交的、发明名称为“操作系统容器之间通讯的系统和方法(systemandmethodformessagingbetweenoperatingsystemcontainers)”的美国专利申请第15/187,443号的优先权，其全部内容以引用的方式并入本文中。

本发明大体上涉及操作系统，在特定实施例中，涉及操作系统容器之间通讯的系统和方法。

背景技术：

通常，虚拟系统在操作系统级别有若干虚拟化的用户空间实例。如今智能手机、平板电脑和云计算系统等很多设备都被虚拟化为包括若干用户空间实例，这实现了更大的粒度且允许在设备上控制软件。尽管典型的操作系统包括一个内核空间和一个用户空间，但虚拟化系统可以包括一个内核空间和若干用户空间实例(有时称为“容器”)。虚拟化系统允许隔离每个容器，但是容器之间可能仍然需要一些通信。

技术实现要素：

根据一实施例，一种方法包括：第一用户空间容器中的第一代理接收来自所述第一用户空间容器中的第一业务的第一消息，其中所述第一消息使用第一消息机制发送至所述第一代理；所述第一代理向第二用户空间容器中的第二代理转发所述第一消息，其中所述第一消息使用不同于所述第一消息机制的第二消息机制发送至所述第二代理；以及所述第二代理将所述第一消息下发至所述第二用户空间容器中的第二业务。

可选地，在前述实施例的任一项中，向所述第二代理转发所述第一消息包括将所述第一消息从所述第一代理直接发送至所述第二代理。

可选地，在前述实施例的任一项中，向所述第二代理转发所述第一消息包括：所述第一代理将所述第一消息发送至路由器，其中所述第一消息使用所述第二消息机制发送至所述路由器；以及所述路由器使用所述第二消息机制向所述第二代理转发所述第一消息。

可选地，在前述实施例的任一项中，将所述第一消息下发至所述第二业务包括：所述第二代理使用所述第一消息机制将所述第一消息发送至所述第二业务。

可选地，在前述实施例的任一项中，将所述第一消息下发至所述第二业务包括：所述第二代理使用与所述第一消息机制不同的第三消息机制将所述第一消息发送至所述第二业务。

可选地，在前述实施例的任一项中，所述第一代理以第一格式接收所述第一消息，并且将所述第一消息以不同于所述第一格式的第二格式发送至所述第二代理。

可选地，在前述实施例的任一项中，将所述第一消息以不同于所述第一格式和所述第二格式的第三格式下发至所述第二业务。

可选地，在前述实施例的任一项中，将所述第一消息以第三格式下发至所述第二业务，其中所述第三格式与所述第一格式相同。

可选地，在前述实施例的任一项中，所述方法还包括：第三用户空间容器中的第三代理接收来自所述第一用户空间容器中的所述第一业务的第二消息；以及所述第三代理将所述第二消息下发至所述第三用户空间容器中的第三业务，其中所述第二消息使用所述第一消息机制或第三消息机制中的一个发送至所述第三业务。

可选地，在前述实施例的任一项中，所述第一代理以第一格式接收所述第一消息，将所述第一消息以不同于所述第一格式的第二格式发送至所述第二代理，以及将所述第二消息以所述第一格式或不同于所述第一格式和所述第二格式的第三格式中的一个下发至所述第三业务。

可选地，在前述实施例的任一项中，所述第一消息是所述第二业务将执行的操作的描述。

可选地，在前述实施例的任一项中，所述第一代理向所述第二代理转发所述第一消息包括：所述第一代理将所述第一消息串行化以生成串行化消息；所述第一代理向所述串行化消息附加标识符；以及所述第一代理使用所述第二消息机制将所述串行化消息发送至所述第二代理。

可选地，在前述实施例的任一项中，所述第二代理将所述第一消息下发至所述第二业务包括：所述第二代理根据所述标识符识别所述第二业务；所述第二代理将所述串行化消息反串行化以生成所述第一消息；以及所述第二代理将所述第一消息发送至所述第二业务。

根据另一实施例，一种操作系统包括第一用户空间容器，其包括第一组多个进程；以及第一消息代理，用于使用第一消息机制接收来自所述第一组多个进程中的一个的第一消息。第二用户空间容器与所述第一用户空间容器分离。所述第二用户空间容器包括：第二消息代理，用于使用不同于所述第一消息机制的第二消息机制接收来自所述第一消息代理的所述第一消息；以及第二组多个进程。所述第二组多个进程中的一个用于接收来自所述第二消息代理的所述第一消息。

可选地，在前述实施例的任一项中，所述操作系统还包括包括设备驱动程序的内核，所述第二组多个进程中的所述一个用于根据从所述第一组多个进程中的所述一个接收的所述第一消息访问所述设备驱动程序。

可选地，在前述实施例的任一项中，所述操作系统还包括消息路由器，用于使用所述第二消息机制接收来自所述第一消息代理的所述第一消息，以及使用所述第二消息机制向所述第二消息代理转发所述第一消息。

可选地，在前述实施例的任一项中，所述第一消息代理用于使用所述第二消息机制将所述第一消息直接下发至所述第二消息代理。

可选地，在前述实施例的任一项中，所述第一消息机制是本地进程间通信机制，所述第二消息机制是全局进程间通信机制。

可选地，在前述实施例的任一项中，所述第二组多个进程中的所述一个用于使用所述第一消息机制接收来自所述第二消息代理的所述第一消息。

可选地，在前述实施例的任一项中，所述第二组多个进程中的所述一个用于使用第三消息机制制接收来自所述第二消息代理的所述第一消息。

可选地，在前述实施例的任一项中，所述第一消息代理以第一消息格式接收所述第一消息，所述第二消息代理以不同于所述第一消息格式的第二消息格式接收所述第一消息。

可选地，在前述实施例的任一项中，所述第二组多个进程中的所述一个以第三消息格式接收所述第一消息，所述第二消息代理将所述第一消息转换成所述第三消息格式。

可选地，在前述实施例的任一项中，所述第二组多个进程中的所述一个以所述第一消息格式接收所述第一消息。

可选地，在前述实施例的任一项中，所述第一消息代理还用于将所述第一消息串行化并进行标识，以生成第二消息，所述第二消息代理还用于将所述第二消息反串行化以生成所述第一消息。

根据另一实施例，一种设备包括处理器和包括程序的计算机可读介质。所述程序包括用于以下操作的指令：第一用户空间容器中的第一代理接收来自所述第一用户空间容器中的第一业务的第一消息，其中所述第一消息使用第一消息机制发送至所述第一代理；所述第一代理向第二用户空间容器中的第二代理转发所述第一消息，其中所述第一消息使用不同于所述第一消息机制的第二消息机制发送至所述第二代理；以及所述第二代理使用所述第一消息机制将所述第一消息下发至所述第二用户空间容器中的第二业务。

本发明实施例的优点在于操作系统容器内的本地通讯可以与容器间通讯解耦。在操作系统中，必须授予容器本地进程全局通讯特权才能进行容器间通讯。将本地通讯和全局通讯解耦可以减少操作系统中执行的特权进程的数量。另外，将本地通讯和全局通讯解耦提供了一种集中消息机制，实现了操作系统中更大程度的访问控制。由此可以提高操作系统和容器的安全性和稳定性。

附图说明

为了更完整地理解本发明及其优点，现在参考下文结合附图进行的描述，其中：

图1是用户设备上具有虚拟化容器的操作系统的框图；

图2是通讯方法的流程图；以及

图3是处理系统的示意图。

具体实施方式

图1是用户设备上具有虚拟化容器的操作系统100的框图。操作系统100使用操作系统级虚拟化，因此操作系统100包括一个内核110和多个用户空间容器120、130和140。可选地，操作系统100包括消息路由器150。操作系统100可以为用户设备上的生态系统，例如android、windows或ios。

内核110包括内核空间组件，例如设备驱动程序112。在一些实施例中，内核110是类unix内核，例如linux。在内核110是linux的实施例中，操作系统100可以是android。设备驱动程序112访问或控制用户设备上的硬件特征，例如输入/输出(input/output，i/o)设备、电话接口、外围设备接口和网络接口等。在设备驱动程序112用于i/o设备的实施例中，设备驱动程序112可以是音频、视频或触摸屏设备驱动程序。在设备驱动程序112用于电话设备的实施例中，设备驱动程序112可以是调制解调器设备驱动程序。设备驱动程序112可以是可加载的内核模块，或者与内核110静态连接。尽管以下参照使用linux内核的android移动操作系统描述了各实施例，但应了解，根据实施例所述的虚拟化系统和方法可以使用多种操作系统和内核实现。

容器120、130和140是内核110上运行的用户空间容器。容器120、130和140共享内核110，但是用户空间分离。因此，容器120、130和140之一中的进程看不到其它容器中的其它进程或资源。在内核110是linux内核的实施例中，容器120、130和140可以运行不同的linux发行版，例如ubuntu、redhat和debian等。在操作系统100是移动操作系统的实施例中，容器120、130和140可以运行使用linux内核的任何移动操作系统，例如ubuntu、tizen和/或android的不同版本。在此类实施例中，可以使用linux容器(linuxcontainers，lxc)来提供容器120、130和140。在内核110是bsd或xnu内核的实施例中，容器120、130和140可以为不同的监牢。容器120、130和140分别包括进程122、132和142以及消息代理124、134和144。尽管图1中示出了三个用户空间容器，但是应了解，操作系统100可以包括任何数量的容器。

进程122、132和142分别在容器120、130和140中执行不同线程或任务，并可以执行不同功能。进程122、132和142可以是用户操作的软件，也可以是操作系统100中的业务。在所示实施例中，容器120中的进程122与设备驱动程序112交互，容器130和140中的进程132和142执行其它应用。例如，在设备驱动程序112是音频驱动程序的实施例中，进程122可以是向设备驱动程序112发送命令或数据的音频业务。在此类实施例中，容器130和140中的进程132和142可能需要访问设备驱动程序112。在一些实施例中，其中一个容器中的进程可能需要将该进程将执行的操作通知给其它容器中的进程。例如，在操作系统100是android操作系统的实施例中，一个进程可能需要向其它容器中的进程发送intent对象。

根据实施例所述的通讯技术允许不同容器120、130和140中的进程122、132和142互相通信。容器间通讯(inter-containermessaging，icm)可以允许进程132和142以受限和受控的方式访问设备驱动程序112。在一些实施例中，使用操作系统100支持的现有消息机制实施icm。为了互相直接通信，可以授予进程122、132和142中的每一个在操作系统100中的通讯特权，且进程122、132和142可以使用容器120、130和140公共的机制进行通信。然而，如上所述，容器120、130和140可以运行不同的linux发行版或用户空间环境。在运行不同的发行版和/或用户空间环境时，容器120、130和140可能无法使用公共消息机制进行通信。另外，增加作为特权进程运行的进程122、132和142的数量可能影响系统安全性和稳定性。减少特权进程的数量可以减少操作系统100的攻击面。

进程122、132和142使用消息代理124、134和144跨容器120、130和140互相通信。容器120、130和140分别包括消息代理124、134和144。消息代理124、134和144中的每一个充当对应的容器120、130和140中的进程122、132和142的集中icm网关。消息代理124、134和144将消息从其对应容器中的源进程转发至具有目标接收方进程的容器。接收方容器中的消息代理将消息转发至接收方进程。在一些实施例中，消息代理124、134和144本身可以为用于跨容器120、130和140代理消息的进程或业务。在一些实施例中，消息代理124、134和144以点对点的方式互相直接通信。在一些实施例中，消息代理124、134和144以广播方式与多个接收方进程通信。

消息代理124、134和144使用各种数据结构和消息机制与进程122、132和142通信。在一些实施例中，进程122、132和142使用消息队列、共享内存和命名管道等进程间通信(inter-processcommunication，ipc)机制与消息代理124、134和144通信。在一些实施例中，进程122、132和142用来与消息代理124、134和144通信的ipc机制只包括用于容器内(有时称为“本地”)通讯的ipc机制。进程122、132和142可以使用特定于对应容器120、130和140的用户空间环境的数据结构或格式与消息代理124、134和144通信。例如，进程132可以使用第一数据结构和第一ipc机制与消息代理134通信，进程142可以使用第二数据结构和第二ipc机制与消息代理144通信。消息代理124、134和144使用用于容器间(有时称为“全局”)通讯的ipc机制进行通信。将进程122、132和142限制为通过容器内ipc和本地通讯格式与消息代理124、134和144通信可使进程122、132和142与系统特定icm解耦。这样可以提高灵活性并减少操作系统100的攻击面。

在进程跨两个以上容器120、130和140进行通信的实施例中，操作系统100可以包括消息路由器150。在容器120、130和140以广播方式进行通信的实施例中，容器120、130和140可以使用消息路由器150交互消息。在此类实施例中，消息代理124、134和144中的每一个使用公共数据结构和消息机制与消息路由器150通信。消息路由器150将消息从源消息代理转发至接收方消息代理。可以使用2016年5月27日提交的同在申请中的美国专利申请第15/167,676号(代理人案号hw85045731us01)中描述的通信机制实现消息路由器150，其以引用的方式并入本文中。在进程跨两个容器通信的实施例中，消息代理可以直接通信，在此类实施例中，不需要消息路由器150。在一些实施例中，容器120、130和140使用其它通信机制通信，例如，无需消息路由器150。尽管消息路由器150描述为在容器120、130和140外部，但是应了解，消息路由器150可以位于任何容器中，例如可以位于容器130或容器140中。

图2是通讯方法200的流程图。通讯方法200可以指示具有多个用户空间的操作系统中发生的操作，例如操作系统100中。在步骤202中，源进程创建针对接收方进程的消息，并将消息发送至源通讯代理(步骤202)。源进程和源通讯代理处于源容器中，接收方进程处于接收方容器中。源进程和源通讯代理可以使用例如本地ipc机制的第一ipc机制以第一通讯格式进行通信。在操作系统是android的实施例中，本地ipc机制例如可以是binder。

如果操作系统准许源通讯代理和源进程跨容器通信(步骤204)，将消息转换为全局消息格式(步骤206)。转换可以包括串行化消息以及向消息中添加标识头。在一些实施例中，消息串行化为文本或二进制格式。标识头标识目的地进程。在一些实施例中，头标识是容器和进程标识符，例如为整数或字符串值。在一些实施例中，可以使用操作系统中的标识注册框架标识目的地进程。如果不准许源通讯代理跨容器通信，通讯方法200结束。

将串行化消息从源通讯代理发送至接收方通讯代理(步骤208)。使用消息中的标识头标识接收方通讯代理。可以使用例如unix域套接字的全局ipc机制将消息发送至接收方通讯代理。

如果接收方容器中的接收方进程可用(步骤210)，则接收方通讯代理将消息转换为用于接收方容器的本地消息格式(步骤212)。在一些实施例中，也可以执行访问控制校验来确定是否准许接收方进程和/或接收方容器接收来自其它容器的通信。转换可以包括从消息中去除标识头和反串行化消息。如果接收方进程不可用，通讯方法200结束。将反串行化消息从接收方通讯代理发送至接收方业务(步骤214)。接收方通讯代理和接收方进程可以使用第一ipc机制以第一通讯格式通信，也可以使用第二ipc机制以第二通讯格式通信。当接收方通讯代理和接收方进程以第二通讯格式通信时，转换可以包括将消息转换为第二通讯格式。可以使用本地ipc机制将消息发送至接收方容器，例如在操作系统是android的实施例中使用binder。

图3是用于执行本文所述方法的实施例的处理系统300的框图，处理系统300可以安装在主机设备中。如图所示，处理系统300包括处理器302、存储器304以及接口306、308和310，可以(或可以不)如图3中所示的布置。处理器302可以是用于执行计算和/或其它与处理相关的任务的任何组件或组件集合，且存储器304可以是用于存储程序和/或供处理器302执行的指令的任何组件或组件集合。在实施例中，存储器304包括非瞬时性计算机可读介质。接口306、308和310可以是允许处理系统300与其它设备/组件和/或用户通信的任何组件或组件集合。例如，接口306、308和310中的一个或多个可以用于将数据、控制或管理信息从处理器302传送至安装在主机设备和/或远端设备上的应用程序。在另一示例中，接口306、308和310中的一个或多个可以用于允许用户或用户设备(例如个人电脑(personalcomputer，pc))与处理系统300互动/通信。处理系统300可以包括图3中未描绘的额外组件，例如，长期存储设备(例如，非易失性存储器等)。

在一些实施例中，处理系统300包括在接入电信网络或另外作为电信网络的部件的网络设备中。在一个示例中，处理系统300处于无线或有线电信网络中的网络侧设备中，例如基站、中继站、调度器、控制器、网关、路由器、应用程序服务器，或电信网络中的任何其它设备。在其它实施例中，处理系统300处于接入无线或有线电信网络的用户侧设备中，例如移动台、用户设备(userequipment，ue)、个人计算机(personalcomputer，pc)、平板计算机、可穿戴通信设备(例如，智能手表等)，或用于接入电信网络的任何其它设备。

应了解，本文所提供的实施例方法的一个或多个步骤可由对应单元或模块执行。步骤可以由转发单元/模块、接收单元/模块、分发单元/模块、串行化单元/模块、附加单元/模块、识别单元/模块、反串行化单元/模块和/或发送单元/模块执行。对应的单元/模块可以是硬件、软件或其组合。例如，一个或多个单元/模块可以是集成电路，例如现场可编程门阵列(fieldprogrammablegatearray，fpga)或专用集成电路(application-specificintegratedcircuit，asic)。

尽管已参考说明性实施例描述了本发明，但此描述并不意图限制本发明。所属领域的技术人员在参考该描述后，将会明白说明性实施例的各种修改和组合，以及本发明其他实施例。因此，所附权利要求书意图涵盖任何此类修改或实施例。