一种基于灾备中心的云平台资源配置方法以及系统与流程

本发明关于容灾技术领域，特别是关于灾备中心的资源调度技术，具体的讲是一种基于灾备中心的云平台资源配置方法及系统。

背景技术：

本部分旨在为权利要求书中陈述的本发明的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

随着业务的发展，灾备中心部署了越来越多的业务系统，其中包括了双活、主辅等架构的核心生产系统，还包括热备、温备、冷备架构的多种灾备模式的大量业务系统，用于保障生产系统的安全稳定运行，且大部分业务系统将逐步迁移至云平台中。目前，云平台物理机集群中平均每台物理机上都有较多虚拟机运行，在业务高峰时容易出现某一台物理机负载过高而同集群中其他物理机负载低，也即物理机资源使用率的不均衡，从而影响业务运行效率并造成资源浪费。

目前，物理机监控一般使用Patrol监控，但patrol监控与云平台为相互独立的平台，无通用接口，无法将物理机的负载与云平台的热迁移等高级特性结合起来。

因此，如何研究和开发出一种新的方案以针对不同的灾备模式对云平台资源进行配置是本领域亟待解决的技术难题。

技术实现要素：

为了克服现有技术存在的上述技术问题，本发明提供了一种基于灾备中心的云平台资源配置方法以及系统，通过获取云平台上灾备中心部署的各个业务系统对应的服务器的负载数据，并从生产环境中获取业务运行数据，引入预设的灾容模式等级进行分类，并结合预设的策略配置表进行资源配置，实现了针对不同的灾容模式对应不同的策略对虚拟机、物理机进行迁移，达到节约资源、节约能耗的效果。

为了实现上述目的，本发明提供一种基于灾备中心的云平台资源配置方法，所述方法包括：采集云平台上灾备中心部署的各个业务系统对应的服务器的负载数据；从生产环境中采集业务运行数据；将所述负载数据以及业务运行数据根据预设的容灾模式等级进行分类，得到不同容灾模式下各个业务系统的负载情况数据；根据预设的策略配置表以及负载情况数据对所述云平台进行资源配置。

在本发明的优选实施方式中，采用脚本采集服务器的负载数据，所述服务器包括虚拟机以及物理机。

在本发明的优选实施方式中，所述负载数据包括CPU使用率、内存使用率以及存储容量使用率，所述业务运行数据包括交易量日均值以及交易量日峰值。

在本发明的优选实施方式中，所述容灾模式包括双活容灾模式、主辅容灾模式、温备容灾模式以及冷备容灾模式。

在本发明的优选实施方式中，当所述业务系统为双活容灾模式或主辅容灾模式时，根据策略配置表以及负载情况数据对所述云平台进行资源配置包括：从所述生产环境中采集预测信息；根据预测信息以及所述策略配置表确定所述业务系统的优化策略；根据所述优化策略以及负载情况数据对所述业务系统进行资源配置。

在本发明的优选实施方式中，当所述业务系统为温备容灾模式或冷备容灾模式时，根据策略配置表以及负载情况数据对所述云平台进行资源配置包括根据策略配置表确定所述业务系统的优化策略；根据所述优化策略以及负载情况数据对所述业务系统进行资源配置。

在本发明的优选实施方式中，根据所述优化策略以及负载情况数据对所述业务系统进行资源配置包括从所述优化策略中获取设定信息；

当所述业务系统的资源配置不满足所述设定信息时，根据所述业务系统对应的物理机的名称从预设数据库中读取所述物理机对应的虚拟机；从所述负载情况数据中获取所述虚拟机的CPU使用率除以及内存使用率；根据所述CPU使用率除以及内存使用率确定出所述虚拟机的系数；根据所述虚拟机的系数以及所述优化策略选取待迁移的虚拟机；根据待迁移的虚拟机选取待迁移的物理机；迁移所述待迁移的物理机以及待迁移的虚拟机进行，以使迁移后的所述业务系统满足所述设定信息。

本发明的目的之一是，提供了一种基于灾备中心的云平台资源配置系统，所述的系统包括负载数据采集装置，用于采集云平台上灾备中心部署的各个业务系统对应的服务器的负载数据；运行数据采集装置，用于从生产环境中采集业务运行数据；数据分类装置，用于将所述负载数据以及业务运行数据根据预设的容灾模式等级进行分类，得到不同容灾模式下各个业务系统的负载情况数据；资源配置装置，用于根据预设的策略配置表以及负载情况数据对所述云平台进行资源配置。

在本发明的优选实施方式中，当所述业务系统为温备容灾模式或冷备容灾模式时，所述资源配置装置包括第一优化策略确定模块，用于根据策略配置表确定所述业务系统的优化策略；资源配置模块，用于根据所述优化策略以及负载情况数据对所述业务系统进行资源配置。

在本发明的优选实施方式中，当所述业务系统为双活容灾模式或主辅容灾模式时，所述资源配置装置还包括预测信息采集模块，用于从所述生产环境中采集预测信息；

第二优化策略确定模块，用于根据预测信息以及所述策略配置表确定所述业务系统的优化策。

在本发明的优选实施方式中，所述资源配置模块包括获取单元，用于从所述优化策略中获取设定信息；

读取单元，用于当所述业务系统的资源配置不满足所述设定信息时，根据所述业务系统对应的物理机的名称从预设数据库中读取所述物理机对应的虚拟机；使用率获取单元，用于从所述负载情况数据中获取所述虚拟机的CPU使用率除以及内存使用率；系数确定单元，用于根据所述CPU使用率除以及内存使用率确定出所述虚拟机的系数；第一确定单元，用于根据所述虚拟机的系数以及所述优化策略选取待迁移的虚拟机；第二确定单元，用于根据待迁移的虚拟机选取待迁移的物理机；迁移单元，用于迁移所述待迁移的物理机以及待迁移的虚拟机，以使迁移后的所述业务系统满足所述设定信息。

本发明的有益效果在于，提供了一种基于灾备中心的云平台资源配置方法以及系统，通过获取云平台上灾备中心部署的各个业务系统对应的服务器的负载数据，并从生产环境中获取业务运行数据，引入预设的灾容模式等级进行分类，并结合预设的策略配置表进行资源配置，实现了针对不同的灾容模式对应不同的策略对虚拟机、物理机进行迁移，达到节约资源、节约能耗的效果。

为让本发明的上述和其他目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附图式，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种基于灾备中心的云平台资源配置方法的流程图；

图2为图1中的步骤S104的实施方式一的流程图；

图3为图1中的步骤S104的实施方式二的流程图；

图4为图2中的步骤S303的流程图；

图5为本发明实施例提供的一种基于灾备中心的云平台资源配置系统的结构框图；

图6为本发明实施例提供的一种基于灾备中心的云平台资源配置系统中资源配置装置的实施方式一的结构框图；

图7为本发明实施例提供的一种基于灾备中心的云平台资源配置系统中资源配置装置的实施方式二的结构框图；

图8为本发明实施例提供的一种基于灾备中心的云平台资源配置系统中资源配置模块的结构框图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本领域技术技术人员知道，本发明的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

下面参考本发明的若干代表性实施方式，详细阐释本发明的原理和精神。

目前使用的云平台管理工具中，可监控各虚拟机的分布情况，对物理机资源使用情况监控功能暂时没有，物理机监控使用Patrol商用产品监控，但patrol监控与云资源管理平台为相互独立的平台，无通用接口，无法将物理机的负载与云平台的热迁移等高级特性结合起来。

目前云平台管理工具的虚拟机迁移等功能，针对的场景是物理机故障的高可用迁移，该功能是普适云计算平台最基本的高可用特性，要实现适用于灾备中心业务特点的自动化资源优化，须向云平台引入数据采集、数据分析、过程控制、优化、决策等功能。

本发明针对上述技术问题，提出了一种基于灾备中心的云平台资源配置方法以及系统。

图1为本发明提出的一种基于灾备中心的云平台资源配置方法的具体流程图，请参阅图1，所述的方法包括：

S101：采集云平台上灾备中心部署的各个业务系统对应的服务器的负载数据。

在具体的实施例中，可通过脚本等方式采集服务器的负载数据，所述服务器包括虚拟机以及物理机，所述负载数据包括CPU使用率、内存使用率以及存储容量使用率。

S102：从生产环境中采集业务运行数据。在本发明中，所提及的生产环境是指在典型的金融系统中，用于处理实际金融交易信息的IT系统环境。在具体的实施方式中，所述业务运行数据包括交易量日均值以及交易量日峰值。即步骤S102打通了灾备中心与生产中心的交易监控接口

S103：将所述负载数据以及业务运行数据根据预设的容灾模式等级进行分类，得到不同容灾模式下各个业务系统的负载情况数据。在具体的实施方式中，预设的容灾模式等级中包括双活容灾模式、主辅容灾模式、温备容灾模式以及冷备容灾模式。容灾模式等级可配置，对负载数据以及业务运行数据进行分类，形成以业务系统为维度的负载情况数据，以供后续步骤进行决策。

S104：根据预设的策略配置表以及负载情况数据对所述云平台进行资源配置。

图2为步骤S104的实施方式一的流程图，请参阅图2，在实施方式一中，当所述业务系统为温备容灾模式或冷备容灾模式时，步骤S104包括：

S201：根据策略配置表确定所述业务系统的优化策略；

S202：根据所述优化策略以及负载情况数据对所述业务系统进行资源配置。

在实施方式一中，策略配置表如表1所示，其示出了当所述业务系统为温备容灾模式或冷备容灾模式时，工作日、周末以及节日三种情景下分别对应的优化策略。以温备容灾模式为例，则其工作日对应的优化策略为“历史峰值均值，以前一周峰值作为参考”，即在该种情形下，以前一周的历史峰值的均值作为参考。

表1

图3为步骤S104的实施方式二的流程图，请参阅图3，在实施方式二中，当所述业务系统为双活容灾模式或主辅容灾模式时，步骤S104包括：

S301：从所述生产环境中采集预测信息，此处的预测信息来源于生产环境的预测平台，通常输入为指定的未来某个时间段，输出为预测的该时间段的业务量峰值，在这两种模式下获取预测信息的意义在于既可以保证历史峰值业务量的处理能力，也保证预测平台预测的峰值业务量的处理能力。

S302：根据策略配置表确定所述业务系统的优化策略；

S303：根据所述优化策略以及负载情况数据对所述业务系统进行资源配置。

在实施方式二中，策略配置表如表2所示，其示出了当所述业务系统为双活容灾模式或主辅容灾模式时，工作日、周末以及节日三种情景下分别对应的优化策略。以双活容灾模式为例，则其工作日对应的优化策略为“双中心历史峰值之和，以前一月峰值作为参”，即在该种情形下，以双中心的前一月的历史峰值的和作为参考，此处的双中心指的是北京中心以及上海中心。

表2

图4为步骤S202、S303的流程图，请参阅图4，根据所述优化策略以及负载情况数据对所述业务系统进行资源配置包括：

S401：从所述优化策略中获取设定信息。以双活容灾模式为例，步骤S303确定出其工作日对应的优化策略为“双中心历史峰值之和，以前一月峰值作为参”，即在该种情形下，以双中心的前一月的历史峰值的和作为参考。举例而言，若上海中心前一月的历史峰值为1500tps(即每秒钟1500笔交易)，北京中心前一月的历史峰值为1000tps，则双活容灾模式下工作日对应的优化策略确定出的设定信息为2500tps。

S402：当所述业务系统的资源配置不满足所述设定信息时，根据所述业务系统对应的物理机的名称从预设数据库中读取所述物理机对应的虚拟机，若已满足设定信息，则无需对资源进行调整。此处提及的资源配置是指虚拟机CPU、内存的计算能力。

S403：从所述负载情况数据中获取所述虚拟机的CPU使用率除以及内存使用率；

S404：根据所述CPU使用率除以及内存使用率确定出所述虚拟机的系数，在具体的实施方式中，用虚拟机的CPU使用率除以内存使用率，计算出系数。在本发明中之所以采用此系数是因为CPU使用率高直接影响到物理机的负载，而内存大小则会影响迁移时间。系数值大则表示使用率高或者使用内存低，迁移后对物理机负载影响明显。

S405：根据所述虚拟机的系数以及所述优化策略选取待迁移的虚拟机；

S406：根据待迁移的虚拟机选取待迁移的物理机。

S407：迁移所述待迁移的物理机以及待迁移的虚拟机进行，以使迁移后的所述业务系统的资源配置满足所述设定信息。

在具体的实施方式中，也可以选取好待迁移虚拟机后选择适合迁移的物理机，然后计算迁移后资源配置能否满足设定信息，若不符合条件则再次进行选择。条件满足则执行迁移操作。

如上即是本发明提供的一种基于灾备中心的云平台资源配置方法，获取云平台上灾备中心部署的各个业务系统对应的服务器的负载数据，并从生产环境中获取业务运行数据，引入预设的灾容模式等级进行分类，并结合预设的策略配置表进行资源配置，实现了针对不同的容灾模式自动触发不同的策略对虚拟机进行迁移，如业务低谷时将虚拟机迁移至少数物理机并关闭其他物理机以达到节约资源、节约能耗的效果。

应当注意，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

在介绍了本发明示例性实施方式的方法之后，接下来，参考图5对本发明示例性实施方式的云平台资源配置系统进行介绍。该系统的实施可以参见上述方法的实施，重复之处不再赘述。以下所使用的术语“模块”和“单元”，可以是实现预定功能的软件和/或硬件。尽管以下实施例所描述的模块较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图5为本发明实施例提供的一种基于灾备中心的云平台资源配置系统的结构框图，请参阅图5，所述系统包括：

负载数据采集装置101，用于采集云平台上灾备中心部署的各个业务系统对应的服务器的负载数据。

在具体的实施例中，可通过脚本等方式采集服务器的负载数据，所述服务器包括虚拟机以及物理机，所述负载数据包括CPU使用率、内存使用率以及存储容量使用率。

运行数据采集装置102，用于从生产环境中采集业务运行数据。在具体的实施方式中，所述业务运行数据包括交易量日均值以及交易量日峰值。即运行数据采集装置102打通了灾备中心与生产中心的交易监控接口。

数据分类装置103，用于将所述负载数据以及业务运行数据根据预设的容灾模式等级进行分类，得到不同容灾模式下各个业务系统的负载情况数据。在具体的实施方式中，预设的容灾模式等级中包括双活容灾模式、主辅容灾模式、温备容灾模式以及冷备容灾模式。容灾模式等级可配置，对负载数据以及业务运行数据进行分类，形成以业务系统为维度的负载情况数据，以供后续步骤进行决策。

资源配置装置104，用于根据预设的策略配置表以及负载情况数据对所述云平台进行资源配置。

图6为本发明实施例提供的一种基于灾备中心的云平台资源配置系统中资源配置装置104的实施方式一的结构框图，请参阅图6，在实施方式一中，当所述业务系统为温备容灾模式或冷备容灾模式时，资源配置装置104包括：

第一优化策略确定模块201，用于根据策略配置表确定所述业务系统的优化策略；

资源配置模块202，用于根据所述优化策略以及负载情况数据对所述业务系统进行资源配置。

在实施方式一中，策略配置表如表1所示，其示出了当所述业务系统为温备容灾模式或冷备容灾模式时，工作日、周末以及节日三种情景下分别对应的优化策略。以温备容灾模式为例，则其工作日对应的优化策略为“历史峰值均值，以前一周峰值作为参考”，即在该种情形下，以前一周的历史峰值的均值作为参考。

图7为本发明实施例提供的一种基于灾备中心的云平台资源配置系统中资源配置装置的实施方式二的结构框图，请参阅图7，在实施方式二中，当所述业务系统为双活容灾模式或主辅容灾模式时，所述资源配置装置104还包括：

预测信息采集模块203，用于从所述生产环境中采集预测信息。

在实施方式二中，策略配置表如表2所示，其示出了当所述业务系统为双活容灾模式或主辅容灾模式时，工作日、周末以及节日三种情景下分别对应的优化策略。以双活容灾模式为例，则其工作日对应的优化策略为“双中心历史峰值之和，以前一月峰值作为参”，即在该种情形下，以双中心的前一月的历史峰值的和作为参考，此处的双中心指的是北京中心以及上海中心。

图8为本发明实施例提供的一种基于灾备中心的云平台资源配置系统中资源配置模块202的结构框图，请参阅图8，资源配置模块202包括：

获取单元301，用于从所述优化策略中获取设定信息。以双活容灾模式为例，步骤S303确定出其工作日对应的优化策略为“双中心历史峰值之和，以前一月峰值作为参”，即在该种情形下，以双中心的前一月的历史峰值的和作为参考。举例而言，若上海中心前一月的历史峰值为1500tps，北京中心前一月的历史峰值为1000tps，则双活容灾模式下工作日对应的优化策略确定出的设定信息为2500tps。

读取单元302，用于当所述业务系统的资源配置不满足所述设定信息时，根据所述业务系统对应的物理机的名称从预设数据库中读取所述物理机对应的虚拟机，若已满足设定信息，则无需对资源进行调整。

使用率获取单元303，用于从所述负载情况数据中获取所述虚拟机的CPU使用率除以及内存使用率；

系数确定单元304，用于根据所述CPU使用率除以及内存使用率确定出所述虚拟机的系数，在具体的实施方式中，用虚拟机的CPU使用率除以内存使用率，计算出系数。在本发明中之所以采用此系数是因为CPU使用率高直接影响到物理机的负载，而内存大小则会影响迁移时间。系数值大则表示使用率高或者使用内存低，迁移后对物理机负载影响明显。

第一确定单元305，用于根据所述虚拟机的系数以及所述优化策略选取待迁移的虚拟机；

第二确定单元306，用于根据待迁移的虚拟机选取待迁移的物理机。

迁移单元307，用于迁移所述待迁移的物理机以及待迁移的虚拟机进行，以使迁移后的所述业务系统的资源配置满足所述设定信息。

在具体的实施方式中，也可以选取好待迁移虚拟机后选择适合迁移的物理机，然后计算迁移后资源配置能否满足设定信息，若不符合条件则再次进行选择。条件满足则执行迁移操作。

此外，尽管在上文详细描述中提及了基于灾备中心的云平台资源配置系统的若干单元模块，但是这种划分仅仅并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。同样，上文描述的一个单元的特征和功能也可以进一步划分为由多个单元来具体化。

以下具体实施例以2016年10月1日的某温备系统A的灾备中心云平台资源配置的过程为例，详细说明利用本发明的一种基于灾备中心的云平台资源配置方法及系统是如何实现不同容灾模式下的云平台的负载均衡的。

1.负载数据采集装置显示生产环境A系统，共使用1台虚拟机VM1，VM1的配置为8C16G，CPU使用率为20％，内存使用率为20％；灾备中心A系统共使用1台VM1，配置为2C4G。

2.运行数据采集装置显示生产环境A系统当前的业务量为50tps，历史当日峰值的均值为80tps，2015年10月1日的峰值为100tps。

3.查询策略配置表得知A系统为温备容灾模式，对策略进行初始化。

4.资源配置装置获取1和2的数据，结合策略配置表，进行目标决策，对于该示例，决策目标为将2C4G，当前tps为50tps，自动调整为可满足100tps处理能力的虚拟机配置，并计算出目标虚拟机配置为((8C*20％/50tps)*100tps)/70％＝4.5C，((16G*20％/50tps)*100tps)/70％＝9.14G，(注：70％为灾备环境的资源容差，为固定参数)，因此决策目标为将灾备中心的VM1的配置2C4G调整为5C10G。

5.资源配置装置将决策目标4和相关决策信息1、2(生产环境的服务器负载信息、业务负载信息)发送给容灾系统。

6.容灾系统针对决策目标，确定需进行资源调整。

7.计算物理机上所有虚拟机的cpu使用率与使用内存大小的比例，并按照从大到小排列；并计算所有物理机负载，从小到大排列。

8.挑选合适的目标物理机，对VM1进行迁移和资源调整。

上述描述2016年10月1日的资源动态调整过程，该示例描述的是节假日来临实现了自动扩充资源，按照本系统设计，普通工作日，会自动收缩资源，提高灾备中心的资源使用率。

综上所述，本发明提出的一种基于灾备中心的云平台资源配置方法以及系统，可以针对不同容灾模式下的云计算平台的负载进行负载均衡，方案灵活，也可针对不同的业务系统进行独立的设定，不用担心适用性。且可以省略人工操作步骤，节约工作量，迁移信息等可进行日志存储或保存至数据库，便于查看。本方案站在灾备数据中心的视角，在保障整个灾备中心各业务系统的灾备指标的前提下，同时能有效利用云平台资源池中的计算资源，自动化合理分配资源，减轻了操作人员的工作量。

本申请是站在整个灾备数据中心的视角，围绕灾备中心云IT系统如何更好地满足灾备中心内的各业务系统运行需求(比如如何满足双活系统、温备系统或冷备系统的容灾指标，并且要最大化的优化资源使用率)，其核心是根据对生产业务量的分析结合灾备心中的业务容灾指标，通过决策分析计算，使得云灾备中心的资源能力随时自动调整，使得对于整个云灾备中心始终具备生产系统的实时运行能力或灾备系统的接管能力。

对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片2。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog2。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。