提供容器服务的设备和方法以及该设备的热升级方法

技术领域

本公开涉及一种互联网领域的容器服务，特别涉及提供容器服务的设备和方法以及该设备的热升级方法。

背景技术

容器技术是一种将软件打包成标准化单元的技术，以用于开发、交付和部署。它确保了应用运行环境一致性，能够更快速地启动。容器技术具有隔离性、可扩展性、迁移方便、可持续交付和部署等特点。基于以上特性，容器技术被广泛地应用在云服务领域。

基于容器技术例如可以实现一种轻量化的GPU(Graphics Processing Unit，图像处理单元)虚拟化解决方案。图1示意性地示出了可用于该方案中的一种GPU容器架构。

该GPU容器架构中，基于内核态的设备驱动器(或称为“设备驱动”或“设备驱动模块”)来实现内核态模块与容器之间的通信以及内核态模块与物理设备之间的通信。

如图1所示，用户态模块创建并维护多个容器实例，例如容器1、容器2、……、容器N。可以基于GPU容器运行库来分别初始化这些容器实例。

内核态模块的GPU容器驱动包括任务调度器、资源分配器和GPU设备驱动器。

任务调度器用于调度来自各容器实例的任务。

资源分配器，用于分配物理设备的资源。

GPU设备驱动器除了与硬件层的物理设备(如GPU)进行通信，还实现多个设备节点，例如设备节点1、设备节点2、……设备节点N，将这些设备节点分别链接到相应容器实例内部。

由此，可以实现一个物理设备被多个容器实例共享，同时还能保证实现容器实例之间的资源隔离和任务隔离。

这种GPU容器方案不需要修改用户态的容器运行库。相对于设备的分片虚拟化方案，该方案又更易于实现，同时又有理论上的性能优势。相对于硬件的SR-IOV(Single RootI/O Virtualization，单根I/O虚拟化)方案，该方案又灵活可配。

在这种GPU容器方案中，为了进行软件修复，新增功能等目的，往往需要进行软件升级。

在传统的升级方案中，需要停止所有的容器服务，然后升级底层容器软件，接下来再重启容器服务。然而，这种升级方案会对容器内的服务有所影响。

例如，对于图1所示的架构，标准的热升级方案是将整个GPU容器驱动作为一个整体进行升级。但是，由于GPU容器驱动需要提供多个设备节点给相应容器实例使用，不可避免地，在升级过程中，会影响到容器实例内的服务。

因此，仍然需要一种新的容器服务解决方案，其有可能实现客户无感知的容器服务热升级，在热升级过程中也不会影响容器实例内的服务。

发明内容

本公开要解决的一个技术问题是提供一种提供容器服务的设备和方法以及该设备的热升级方法，其能够实现客户无感知的容器服务热升级。

根据本公开的第一个方面，提供了一种提供容器服务的设备，包括用户态模块和内核态模块，内核态模块包括：接口驱动模块，用于创建并维护设备节点，并使设备节点连接到用户态模块中的相应容器实例；以及逻辑驱动模块，用于驱动物理设备，并执行逻辑控制功能，其中，逻辑驱动模块通过接口驱动模块维护的设备节点与用户态模块中的相应容器实例进行通信。

可选地，逻辑驱动模块被配置为包括需要进行热升级的功能模块且能够热升级。

可选地，接口驱动模块被配置为包括不需要进行热升级的功能模块。

可选地，响应于热升级指令，接口驱动模块执行对逻辑驱动模块的升级处理。

可选地，在执行对逻辑驱动模块的升级处理之前，接口驱动模块调用旧逻辑驱动模块的状态保存函数，以保存逻辑驱动模块中的状态；并且在执行对逻辑驱动模块的升级处理之后，接口驱动模块调用新逻辑驱动模块的状态恢复函数，将所保存的状态传递给新逻辑驱动模块。

可选地，在调用状态保存函数之前，接口驱动模块还指令旧逻辑驱动模块暂停执行核心逻辑功能。

可选地，响应于回退指令或热升级出错，接口驱动模块恢复旧逻辑驱动模块。

可选地，接口驱动模块从用户态模块中的热升级管理程序接收热升级指令。

可选地，逻辑驱动模块包括：任务调度器，用于调度来自各容器实例的任务；以及/或者资源分配器，用于分配物理设备的资源；以及/或者设备驱动器，用于驱动物理设备。

可选地，用户态模块维护容器实例，内核态模块使容器实例共享物理设备。

可选地，该设备提供GPU容器服务，上述物理设备是GPU。

可选地，该设备还包括上述物理设备。

根据本公开的第二个方面，提供了一种提供容器服务的设备，包括用户态模块和内核态模块，内核态模块包括：第一驱动模块，用于创建并维护设备节点，并使设备节点连接到用户态模块中的相应容器实例；以及第二驱动模块，通过第一驱动模块维护的设备节点与用户态模块中的相应容器实例进行通信。

可选地，第一驱动模块包括内核态模块中不需要进行热升级的功能模块，第二驱动模块包括内核态模块中需要进行热升级的功能模块。

可选地，内核态模块包括多个第二驱动模块，响应于针对上述多个第二驱动模块中的一个或多个第二驱动模块的热升级指令，第一驱动模块执行对上述一个或多个第二驱动模块的升级处理。

根据本公开的第三个方面，提供了一种容器服务提供方法，包括：在用户态维护容器实例；在内核态提供接口驱动模块，用于创建并维护设备节点，并使设备节点连接到用户态模块中的相应容器实例；以及在内核态提供逻辑驱动模块，用于驱动物理设备，并执行逻辑控制功能，其中，逻辑驱动模块通过接口驱动模块维护的设备节点与用户态模块中的相应容器实例进行通信。

可选地，逻辑驱动模块被配置为包括需要进行热升级的功能模块且能够热升级。

可选地，接口驱动模块被配置为包括不需要进行热升级的功能模块。

可选地，该方法还可以包括：响应于热升级指令，接口驱动模块执行对逻辑驱动模块的升级处理。

可选地，该方法还可以包括：在执行对逻辑驱动模块的升级处理之前，接口驱动模块调用旧逻辑驱动模块的状态保存函数，以保存逻辑驱动模块中的状态；以及在执行对逻辑驱动模块的升级处理之后，接口驱动模块调用新逻辑驱动模块的状态恢复函数，将所保存的状态传递给新逻辑驱动模块。

可选地，该方法还可以包括：在调用状态保存函数之前，接口驱动模块还指令旧逻辑驱动模块暂停执行核心逻辑功能。

可选地，该方法还可以包括：响应于回退指令或热升级出错，接口驱动模块恢复旧逻辑驱动模块。

可选地，该方法还可以包括：接口驱动模块从用户态模块中的热升级管理程序接收热升级指令。

可选地，逻辑驱动模块维护下述至少一项：任务调度器，用于调度来自各容器实例的任务；以及/或者资源分配器，用于分配物理设备的资源；以及/或者设备驱动器，用于驱动物理设备。

根据本公开的第四个方面，提供了一种对根据本公开第一个方面所述的设备进行热升级的方法，包括：响应于热升级指令，接口驱动模块执行对逻辑驱动模块的升级处理。

可选地，该方法还可以包括：在执行对逻辑驱动模块的升级处理之前，接口驱动模块调用旧逻辑驱动模块的状态保存函数，以保存逻辑驱动模块中的状态；以及在执行对逻辑驱动模块的升级处理之后，接口驱动模块调用新逻辑驱动模块的状态恢复函数，将所保存的状态传递给新逻辑驱动模块。

可选地，该方法还可以包括：在调用状态保存函数之前，接口驱动模块还指令旧逻辑驱动模块暂停执行核心逻辑功能。

可选地，该方法还可以包括：响应于回退指令或热升级出错，接口驱动模块恢复旧逻辑驱动模块。

可选地，该方法还可以包括：接口驱动模块从用户态模块中的热升级管理程序接收热升级指令。

根据本公开的第五个方面，提供了一种容器服务提供方法，包括：在用户态维护容器实例；在内核态提供第一驱动模块，用于创建并维护设备节点，并使设备节点连接到用户态模块中的相应容器实例；以及在内核态提供第二驱动模块，通过第一驱动模块维护的设备节点与用户态模块中的相应容器实例进行通信。

可选地，第一驱动模块包括内核态中不需要进行热升级的功能模块，第二驱动模块包括内核态中需要进行热升级的功能模块。

可选地，在内核态提供多个第二驱动模块，该方法还可以包括：响应于针对所述多个第二驱动模块中的一个或多个第二驱动模块的热升级指令，第一驱动模块执行对所述一个或多个第二驱动模块的升级处理。

根据本公开的第六个方面，提供了一种计算设备，包括：处理器；以及存储器，其上存储有可执行代码，当可执行代码被处理器执行时，使处理器执行如上述第三至第五个方面所述的方法。

根据本公开的第七个方面，提供了一种非暂时性机器可读存储介质，其上存储有可执行代码，当可执行代码被电子设备的处理器执行时，使处理器执行如上述第三至第五个方面所述的方法。

由此，通过将接口驱动与内核驱动去耦合，相比于传统的整体热升级方案，本方案能够方便地实现客户无感知的容器服务热升级，实现难度大为降低，并且避免了热升级可能带来的风险。

在进一步的实施例中，即使热升级出错，接口驱动模块还可以及时将逻辑驱动模块回退到旧版本。升级出错再回退的整个过程也可以做到对客户完全无感知。

附图说明

通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施方式中，相同的参考标号通常代表相同部件。

图1示意性地示出了现有技术的一种容器架构。

图2示意性地示出了根据本公开的容器架构。

图3是根据本公开的容器服务热升级方法的示意性流程图。

图4示出了根据本发明一实施例可用于实现上述提供容器服务的方法的计算设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

在根据本公开的容器服务提供方案中，将原有的GPU容器的内核驱动拆分为稳定的一般不需要进行热升级的接口驱动模块和可以进行热升级的核心逻辑模块。当进行热升级的时候，接口驱动模块不需要进行升级，只需要对核心逻辑模块进行升级。

这里，热升级是指在不影响服务的情况下进行升级。内核(Kernel)是指操作系统的内核，经常用来指Linux操作系统的内核。

利用这种创新的架构，能够在不影响对客户的容器服务的同时进行热升级。而且，与传统的整体热升级方案相比，实现难度简单。

图2示意性地示出了根据本公开的容器架构，可以作为根据本公开的提供容器服务的设备的示例。

如图2所示，该容器架构(设备)可以包括用户态模块和内核态模块。

该容器架构(设备)还可以包括物理设备。内核态模块驱动物理设备，并使用户态模块维护的一个或多个容器实例共享该物理设备。

该物理设备例如可以包括GPU。相应地，该容器架构(设备)例如可以是提供GPU容器服务的容器架构(设备)。

用户态模块在用户态维护多个容器实例，例如容器1、容器2、……、容器N。可以基于容器运行库(例如GPU容器运行库)来分别初始化这些容器实例。内核态模块使容器实例共享物理设备，可以包括接口驱动模块100和逻辑驱动模块200。

接口驱动模块100用于创建并维护设备节点，例如设备节点1、设备节点2、……、设备节点N，并使这些设备节点分别连接到用户态模块中的相应容器实例，例如容器1、容器2、……、容器N。

一般而言，容器实例可能不能够直接看到设备节点。这样，可以通过额外的命令使设备节点绑定或者连接到容器实例，使得容器实例内部能够看到所创建并维护的设备节点，从而通过设备节点与内核态模块通信，并进而共享利用为其分配的物理设备。

逻辑驱动模块200用于执行逻辑控制功能，特别是核心的逻辑功能(这种情况下，也可以称为“核心驱动模块”)，例如任务调度和资源分配等。

本公开的方案中，引入了接口驱动模块100来维护逻辑驱动模块200与用户态模块中的容器实例之间的接口，即设备节点，换言之，在接口驱动模块100中实现了需要与用户态模块通信的功能。因此，逻辑驱动模块200执行的逻辑控制功能可以包括内核态中那些不需要与用户态模块中的容器实例直接通信的，从而在热升级的时候不会影响到用户态容器的服务的逻辑控制功能，例如任务调度、资源分配、设备驱动等。逻辑驱动模块200还可以用于驱动物理设备，例如GPU。

例如，逻辑驱动模块200可以包括任务调度器210、资源分配器220、设备驱动器230。

任务调度器210，用于调度来自各容器实例的任务。

资源分配器220，用于分配物理设备的资源。

设备驱动器230，用于驱动物理设备，例如GPU。在根据本公开的方案中，设备驱动器230不再创建和维护与用户态的容器实例进行通信的设备节点，从而与容器实例解耦。

逻辑驱动模块200通过接口驱动模块100维护的各设备节点与分别用户态模块中的相应容器实例进行通信。

逻辑驱动模块200被配置为包括需要进行热升级的功能模块且能够热升级。换言之，可以在逻辑驱动模块200中实现各种能够被热升级的逻辑功能等。

另一方面，因为设备节点的接口通常不会变动，所以可以不对接口驱动模块100进行热升级。

换言之，可以在接口驱动模块100中实现一般不需要热升级的功能，特别是与用户态的容器实例进行通信的设备节点的维护功能。即，接口驱动模块被配置为包括不需要进行热升级的功能模块。此模块一旦完成，可以保持稳定而不需要进行热升级。

接口驱动模块100可以从用户态模块中的热升级管理程序接收热升级指令。

响应于热升级指令，接口驱动模块100可以执行对逻辑驱动模块200的升级处理。例如，可以删除(卸载)旧的逻辑驱动模块，加载安装新的逻辑驱动模块。或者，也可以对旧的逻辑驱动模块进行改造，例如删除部分旧内容(例如新功能实现等)和/或添加部分新内容(例如新功能实现等)。

由此，能够方便地实现逻辑驱动模块200的热升级。

同时，由于不对用于维护与用户态的容器实例进行通信的设备节点的接口驱动模块100进行热升级，能够实现在热升级过程中对用户无感。

另外，在执行对逻辑驱动模块200的升级处理之前，接口驱动模块100可以调用旧逻辑驱动模块的状态保存函数，以保存逻辑驱动模块200中的状态，例如设备节点状态。

相应地，在执行对逻辑驱动模块200的升级处理之后，接口驱动模块100调用新逻辑驱动模块的状态恢复函数，将所保存的状态，例如设备节点状态，传递给新逻辑驱动模块。

在例如图1所示的容器架构中，由GPU容器驱动来保存多个设备节点的状态，容易在软件中产生竞争状态，造成设备驱动器不稳定甚至是内核崩溃。

而在本公开的方案中，由接口驱动模块100来调用旧逻辑驱动模块的状态保存函数来保存状态，调用新逻辑驱动模块的状态恢复函数来恢复状态。

由此，能够实现状态信息的顺利恢复，使得即使在热升级前后，也能够提供顺畅的容器服务。

另外，为了避免运行出错，在进行热升级之前，或者更进一步，在调用状态保存函数之前，接口驱动模块100还可以指令旧逻辑驱动模块2暂停执行核心逻辑功能。

这样，在保存状态之后，状态不会再因旧逻辑驱动模块的操作而发生变化，可以进一步避免热升级完成后状态出错的问题。

另外，响应于用户或系统发出的回退指令，或者响应于热升级出错，接口驱动模块100还可以恢复旧逻辑驱动模块2。

这样，即使热升级出错，或者期望回到先前的版本，也可以方便地恢复旧逻辑驱动模块，以便继续提供容器服务。

下面参考图3进一步描述根据本公开的容器服务提供方案中进行热升级的过程。

图3是根据本公开的容器服务热升级方法的示意性流程图。

在步骤S1，在需要热升级的时候，用户态模块中的热升级管理程序触发热升级流程，通知接口驱动模块100。接口驱动模块100从热升级管理程序接收热升级指令。

在步骤S2，接口驱动模块100指令旧逻辑驱动模块200暂停执行核心逻辑功能，如任务调度器、资源分配器等，防止热升级过程中产生错误。

在步骤S3，接口驱动模块100调用逻辑驱动模块200的状态保存函数，以保存逻辑驱动模块200中的状态，例如设备节点状态等。

在步骤S4，接口驱动模块100执行对逻辑驱动模块200的升级处理。

例如，可以是卸载旧的逻辑驱动模块，并加载新的逻辑驱动模块。或者，也可以对旧的逻辑驱动模块进行改造，例如删除部分旧内容(例如新功能实现等)和/或添加部分新内容(例如新功能实现等)。

在步骤S5，接口驱动模块100调用新逻辑驱动模块的状态恢复函数，将步骤S3中所保存的状态，例如设备节点状态，传递给新逻辑驱动模块(即，恢复状态)。

在步骤S6，接口驱动模块100可以继续运行新逻辑驱动模块。

至此，整个热升级流程完成。

如上文所述，在根据本公开的提供容器服务的方案中，将原有的单一内核态模块分割成两个子模块。

一个子模块为用户态的容器实例提供接口，并且保持稳定，从而避免了热升级过程中维护用户态接口的复杂状态。

另外一个子模块执行容器服务的核心逻辑，保证了容器服务的核心功能，如资源分配器、任务调度器等。这些功能可以被热升级，并且在热升级的时候不会影响到用户态容器的服务。

更一般地，内核态模块可以包括第一驱动模块和第二驱动模块。

第一驱动模块可以包括内核态模块中不需要进行热升级的功能模块。例如，第一驱动模块可以是，但不限于，图2所示的接口驱动模块100，用于创建并维护设备节点，并使设备节点连接到用户态模块中的相应容器实例。这样，第一驱动模块为用户态的容器实例提供接口，即，在第一驱动模块中实现了需要与用户态模块通信的功能。应当理解，第一驱动模块还可以包括其它不需要或不经常需要进行热升级的功能模块。例如，在图2所示的逻辑驱动模块200中的某个模块，例如任务调度器210、资源调度器220、设备驱动器230中的某一个不需要或不经常需要进行热升级的情况下，也可以将其配置到第一驱动模块中。

第二驱动模块可以包括内核态模块中需要进行热升级的功能模块，或者，在一些实施例中也可以只包括经常需要进行热升级的功能模块。例如，第二驱动模块可以是，但不限于，图2所示的逻辑驱动模块200，通过第一驱动模块维护的设备节点与用户态模块中的相应容器实例进行通信。应当理解，第二驱动模块还可以包括其它需要或经常需要进行热升级的功能模块。或者，如上所述，在一些情况下，图2所示的逻辑驱动模块200中的某个模块也可以不属于第二驱动模块而配置到第一驱动模块中。

在一些实施例中，第二驱动模块执行的逻辑功能可以包括内核态中那些不需要与用户态模块中的容器实例直接通信的，从而在热升级的时候不会影响到用户态容器的服务的逻辑控制功能，例如任务调度、资源分配、设备驱动等。

另外，在内核态模块中可以提供一个第二驱动模块，也可以提供多个第二驱动模块。

在提供多个第二驱动模块的情况下，多个第二驱动模块可以执行相同类型的功能，也可以执行不同类型的功能。

例如，可以有一个或多个第二驱动模块包括任务调度器，用于执行任务调动功能。又例如，可以有一个或多个第二驱动模块包括资源分配器，用于执行资源分配功能。又例如，可以有一个或多个第二驱动模块包括设备驱动器，用于驱动物理设备，例如GPU。

这样，一次可以对一个或多个第二驱动模块进行热升级。换言之，响应于针对多个第二驱动模块中的一个或多个第二驱动模块的热升级指令，第一驱动模块可以执行对该一个或多个第二驱动模块的升级处理。而对于其它未收到热升级指令的第二驱动模块，可以不进行热升级处理。

第一驱动模块接收到用户态的热升级管理程序发来的热升级指令后，可以对相应的第二驱动模块进行热升级。

热升级的过程可以与上文中参考图3描述的流程大致相同，只是将其中的接口驱动模块替换为第一驱动模块，而将逻辑驱动模块替换为第二驱动模块。

具体说来，第一驱动模块指令需要热升级的旧第二驱动模块暂停执行其逻辑功能。第一驱动模块调用旧第二驱动模块的状态保存函数来保存函数。第一驱动模块执行第二驱动模块的热升级。第一驱动模块调用新第二驱动模块的状态恢复函数来恢复状态。然后继续运行第二驱动模块，热升级完成。

在一些实施例中，本公开的方案可以实施为异构计算方案，即由使用不同类型指令集和体系架构的计算单元组成的系统计算方案。常见的计算单元类别包括CPU(中央处理单元)、GPU(图像处理单元)、NPU(神经网络处理单元)等。

例如，可以在CPU中执行容器服务软件，包括用户态、内核态。容器服务底层的物理设备则可以为GPU。

图4示出了根据本发明一实施例可用于实现上述提供容器服务的方法的计算设备的结构示意图。

参见图4，计算设备400包括存储器410和处理器420。

处理器420可以是一个多核的处理器，也可以包含多个处理器。在一些实施例中，处理器420可以包含一个通用的主处理器以及一个或多个特殊的协处理器，例如图形处理器(GPU)、数字信号处理器(DSP)等等。在一些实施例中，处理器420可以使用定制的电路实现，例如特定用途集成电路(ASIC，Application Specific Integrated Circuit)或者现场可编程逻辑门阵列(FPGA，Field Programmable Gate Arrays)。

存储器410可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)，和永久存储装置。其中，ROM可以存储处理器420或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器410可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器410可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器410上存储有可执行代码，当可执行代码被处理器420处理时，可以使处理器420执行上文述及的提供容器服务的方法。

上文中已经参考附图详细描述了根据本发明的提供容器服务的设备和方法。

此外，根据本发明的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。

或者，本发明还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器执行时，使所述处理器执行根据本发明的上述方法的各个步骤。

本领域技术人员还将明白的是，结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。