具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
以下结合附图,详细说明本申请各实施例提供的技术方案。
现有技术中,为了适应不同的业务场景,通常采用插件式的方法来满足不同的场景,在实现不同的功能时,选择插入或者删除相应的插件的方式,比如:Adobe中的Photoshop就是使用的插件式方案来实现不同的功能。但是,现有技术的方案中,插入或者删除的插件本身无法单独成为一个服务的提供方,必须依赖于比如Photoshop这样的主程序,各个插件直接和主程序强耦合,插件无法进行独立部署,场景适用性和灵活性较低。
为了解决现有技术中的缺陷,本方案给出了以下实施例:
图1为本说明书实施例中一种应用部署架构的示意图。如图1所示,可拆合应用部署平台获取待处理业务处理请求,根据待处理业务的业务类型确定出所需组件之后,采用拆合配置平台进行组件的配置部署,配置好之后,由代码服务平台根据配置部署的方式调整代码,将调整之后的代码发送到部署平台,由部署平台根据部署方式将组件在相应的站点进行部署。例如:部署平台在中心站点中独立部署待处理业务所需的引擎(或组件),在本地站点中合并部署待处理业务所需的引擎(或组件),如图1所示,部署平台在中心站中独立部署同步分析引擎、异步分析引擎、模型引擎、核身引擎(身份核实引擎)等,部署平台在中心站中合并部署的分析引擎,核身引擎等。
图2为本说明书实施例提供的一种应用部署方法的流程示意图。从程序角度而言,流程的执行主体可以为搭载于应用服务器的程序或应用客户端。在本方案中,本方案步骤的执行主体可以是图1中表示的可拆合应用部署平台。
如图2所示,该流程可以包括以下步骤:
步骤201:获取待处理业务的业务类型信息以及用于表征所述待处理业务数据总量的表征信息。
业务类型信息可以表示的是待处理业务的各种业务类型,在本方案中的待处理业务可以是支付业务、用户登录业务、用户注册业务、资产管理业务等。
表征信息可以用于表示所述待处理业务数据总量,表征信息可以表示于数据总量、业务场景。其中,场景信息可以表示待处理业务对应的站点类型,比如:中心站点或者本地站点。
根据业务数据总量可以大概计算待处理业务所需的机器数量。在实际应用中,可以采用业务的峰值QPS(Queries Per Second,每秒查询率)来表示业务数据总量,QPS可以指的是一台服务器每秒能够达到的相应的查询次数,需要的机器=峰值时间每秒QPS/单台机器的QPS。或者可以用日活跃用户数量(Daily Active User,简称DAU)来表述业务数据总量。
步骤202:根据所述业务类型信息确定处理所述待处理业务所需的组件。
根据不同的业务类型信息可以选用不同的组件进行部署,如表1所示:
业务类型 |
组件(引擎) |
支付业务 |
同步分析组件、异步分析组件 |
用户登录、用户注册、资产管理 |
异步分析组件 |
身份认证 |
同步分析组件、核身组件 |
表1
从表1中可以看出,让业务类型不同时,可以选用不同的组件进行部署,比如:支付业务可以选用同步分析组件和异步分析组件,用户登录、用户注册或者是资产管理等业务,可以选用异步分析模块进行部署处理,身份认证的相关业务可以选用同步分析模块和核身(身份核实)组件进行部署处理。
步骤203:根据所述表征信息确定各个所述组件的部署方式,所述部署方式包括独立部署和/或合并部署。
表征信息可以指的是用于表征某种特征的信息,表征(representation)可以指的是信息的呈现方式。在本方案中,表征信息可以用于表征业务数据总量,根据表征信息可以确定组件的部署方式,部署方式可以包括独立部署和/或合并部署,其中,独立部署可以表示的是将某个组件作为单独的服务进行使用,可以独立处理业务,而无需依赖主程序。合并部署可以表示的是将组件与其他应用合并使用,可以理解为将某一组件插入到某一应用中,以实现其功能。
步骤204:采用各个所述组件对应的部署方式部署各个所述组件。
当各个组件的部署方式确定之后,需要将各个组件按照确定好的部署方式进行部署,完成应用部署工作。
图2中的方法,通过获取到的待处理业务的业务类型信息以及用于表征所述待处理业务数据总量的表征信息;确定处理所述待处理业务所需的组件以及各个所述组件的部署方式,所述部署方式包括独立部署和/或合并部署;采用各个所述组件对应的部署方式部署各个所述组件。使确定出的组件在不同的表征信息下对不同类型的业务进行灵活配置处理,部署方式既可独立部署也可合并部署,在独立部署时不需要依赖架构中的主模块,场景适应性以及部署灵活性较强。
基于图2的方法,本说明书实施例还提供了该方法的一些具体实施方案,下面进行说明。
步骤202中,所述根据所述业务类型信息确定处理所述待处理业务所需的组件,具体可以包括:
根据所述待处理业务的业务类型信息确定所述待处理业务对应的业务流程;
根据所述业务流程确定出实现所述业务流程对应的组件。
根据待处理业务的业务类型确定处理该业务所需的组件时,可以首先确定待处理业务对应的业务流程,其中,业务流程可以表示的是待处理业务对应的处理步骤,比如:待处理业务为处理A地区的网上支付业务,此时,该网上支付业务可以认为是待处理业务,该网上支付业务对应的业务流程可以为:对获取的业务数据进行预处理→同步该业务对应的线上信息→异步分析该业务对应的离线信息→核对交易信息并进行身份验证→进行支付操作。根据业务流程确定实现所述业务流程对应的组件可能有同步分析组件、异步分析组件、核身组件等。
上述方法步骤中,根据业务类型信息确定对应的业务流程后,进一步确定实现其业务流程所需的组件,能根据待处理业务的类型针对性地初步确定出处理待处理业务所需的组件,提高了部署效率。
所述根据所述表征信息确定各个所述组件的部署方式之前,还可以包括:
根据预设的组件标识判断所述组件是否为可拆合组件,所述组件标识包括可拆合标识和不可拆合标识;
当所述组件为可拆合组件时,执行根据所述表征信息确定各个所述组件的部署方式这一步骤。
在根据待处理业务的业务类型初步确定出处理待处理业务所需的组件之后、确定组件的部署方式之前,需要确定组件是否可拆合。只有当组件可拆合时,才能确定所述组件对应的部署方式。一个应用架构中各个组件都有对应的功能属性,可以表示各个组件所能实现的功能,根据各个组件的功能属性将满足预设条件的组件设置为拆合组件,具体地,将具有相对独立的完整闭合逻辑的组件设置为可拆合组件,并在相应的可拆合组件上打上可拆合标识。比如:设备管理模块,其功能可以包括:设备资料管理、数据采集管理、故障管理、维修管理、数据维护以及设备系统管理等。可以根据设备资料和/或采集到的数据管理系统,并根据故障管理所提供的故障信息对系统进行维修保养等,此时,设备管理模块可以设置为可拆合组件。又比如:引擎中存在数据采集组件、数据清洗组件以及数据合并组件,其中数据采集组件仅用于采集数据,数据清洗组件仅用于对数据进行清洗,数据合并组件仅用于对数据进行合并,此时,数据数据采集组件、数据清洗组件以及数据合并组件为不可拆合组件,在数据采集组件、数据清洗组件以及数据合并组件上打上不可拆合的标识。
在具体确定组件是否为可拆合组件时,可以直接根据预先设置好的组件标识来判断所述组件是否为可拆合组件,当组件为可拆合组件时,执行根据所述表征信息确定各个所述组件的部署方式这一步骤。例如:根据待处理业务的业务类型确定待处理业务所需的组件集合为{组件A(1),组件B(1),组件C(1),组件D(0),组件E(1),组件F(1)},其中,标识(1)表示组件可拆合,标识(0)表示组件不可拆合,由此可以确定,组件A、组件B、组件C、组件E和组件F为可拆合组件,组件D为不可拆合组件。对组件A、组件B、组件C、组件E和组件F执行根据所述表征信息确定各个所述组件的部署方式这一步骤。
上述方法步骤,在确定组件的部署方式之前,先确定组件是否为可拆合组件,只有当组件为可拆合组件时,才会对可拆合组件确定其部署方式,保证了确定部署方式的组件的可拆合功能,使应用部署更加灵活精确。
在实际应用中,所述表征信息可以表示待处理业务的业务场景,也可以表示待处理业务的业务数据总量,还可以同时表示业务场景以及待处理业务的业务数据总量。下面,将针对这三种方式阐述表征信息不同时,确定组件部署方式的方法步骤:
方式一、所述表征信息表示所述待处理业务的业务场景时:
所述根据所述表征信息确定各个所述组件的部署方式,具体可以包括:
对于任意一个所述组件,确定所述业务场景对应的站点;
判断所述站点是否为中心站点,得到第一判断结果;
当所述第一判断结果表示所述站点为中心站点时,确定所述任意一个所述组件的部署方式为独立部署;
当所述第一判断结果表示所述站点为非中心站点时,确定所述任意一个所述组件的部署方式为合并部署。
中心站点可以认为是能集中处理或能服务周边的地区业务的站点。例如:东南亚地区内,新加坡可以集中处理周边地区(比如缅甸、老挝、泰国等)的地区业务,此时,新加坡即可认为是中心站点。也可以将区域核心业务大部分的集中处理站点认为是中心站点,例如:一个区域核心业务60%以上在某个站点进行集中处理,该站点可以被认为是中心站点。
本地站点可以表示仅能处理本地区的业务的站点。比如:印度尼西亚只能处理印度尼西亚本地的业务,此时,印度尼西亚可认为是本地站点。
在中线站点一般都是大流量业务场景,而本地站点的业务量级不高,因此,在确定其组件对应的部署方式时,可以根据业务场景对应的站点的类型来确定组件的部署方式,具体地,对于任意一个所述组件,判断所述业务场景对应的站点是否为中心站点,当所述业务场景对应的站点为中心站点时,将组件的部署方式确定为独立部署,当所述业务场景对应的站点为非中心站点时,将组件的部署方式确定为合并部署。
例如:待处理业务为A,待处理业务的业务场景对应的站点为站点X,当站点X为中心站点时,将组件的部署方式确定为独立部署,当站点A为本地站点时,将组件的部署方式确定为合并部署。
在方式一的方法步骤中,根据业务场景对应的站点的类型来确定组件的部署方式,在中心站点,针对高并发、大流量场景进行拆分独立部署,提升整体的抗大并发能力,提升整体架构稳定性。在本地站点,由于本地站点业务量级不高,相关模块可以进行合并部署,在既满足业务需求和发展的同时,又可以大幅度的精简成本、降低部署的复杂度。
方式二、所述表征信息表示所述待处理业务的数据总量时:
所述根据所述表征信息确定各个所述组件的部署方式,具体可以包括:
对于任意一个所述组件,确定所述待处理业务的数据总量;
当所述待处理业务的数据总量属于第一预设阈值范围时,确定所述任意一个所述组件的部署方式为独立部署;
当所述待处理业务的数据总量属于第二预设阈值范围时,确定所述任意一个所述组件的部署方式为合并部署,所述第一预设阈值范围的最小值大于所述第二预设阈值范围的最小值,所述第一预设阈值范围的最大值大于所述第二预设阈值范围的最大值。
在实际应用中,还可以根据待处理业务的数据总量来确定组件的部署方式,具体地,对于任意一个所述组件,确定所述待处理业务的数据总量,确定数据总量所述的预设阈值范围,不同的预设阈值范围对应不同的部署方式,上述方法步骤中提到的第一阈值范围和第二阈值范围可以完全不重合,也可以部分重合。但第一阈值范围的最小值应该大于所述第二预设阈值范围的最小值,所述第一预设阈值范围的最大值大于所述第二预设阈值范围的最大值。例如:将第一预设阈值范围设置为(A1-A2),第二阈值范围设置为(B1-B2),其中,A1<A2,B1<B2,B1<A1,B2<A2。
当所述待处理业务的数据总量属于第一预设阈值范围时,确定所述任意一个所述组件的部署方式为独立部署;当所述待处理业务的数据总量属于第二预设阈值范围时,确定所述任意一个所述组件的部署方式为合并部署。
除此之外,当业务数据总量既属于第一阈值范围也属于第二阈值范围时,可以根据实际情况设置组件的部署方式。
在飞速发展的国际化场景下,存在一些业务场景,对应的待处理业务的数据总量并未达到将组件完全进行独立部署的条件,此时如果将组件进行独立部署,可能会导致资源的浪费,导致成本增高。但如果采用合并部署的方式,可能存在处理业务的系统负载能力存在不足,导致系统崩溃的问题。方式二中的方法步骤,可拆合应用部署平台可以根据各个国家和地区的不同场景或者对应的待处理业务的业务数据总量,选择相应的组件部署方式,具有动态、灵活、可伸缩的优点。在业务数据总量较小的情况下,采用合并部署的方式,避免了业务数据总量小的情况下采用独立部署时对硬件资源的浪费问题,节约了硬件资源。
方式三、所述表征信息表示所述待处理业务的业务场景以及所述待处理业务的数据总量时:
所述根据所述表征信息确定各个所述组件的部署方式,具体可以包括:
对于任意一个所述组件,确定所述业务场景对应的站点;
判断所述站点是否为中心站点,得到第一判断结果;
当所述第一判断结果表示所述站点为中心站点时,确定所述任意一个所述组件的部署方式为独立部署;
当所述第一判断结果表示所述站点为非中心站点时,确定所述待处理业务的数据总量;
当所述待处理业务的数据总量属于第一预设阈值范围时,确定所述任意一个所述组件的部署方式为独立部署;
当所述待处理业务的数据总量属于第二预设阈值范围时,确定所述任意一个所述组件的部署方式为合并部署,所述第一预设阈值范围的最小值大于所述第二预设阈值范围的最小值,所述第一预设阈值范围的最大值大于所述第二预设阈值范围的最大值。
方式三中的方法步骤,综合考虑待处理业务对应的业务场景以及业务数据总量,选择合适的组件部署方式,具体地,先根据业务场景对应的站点来判断,由于中心站点在理论上都会采用独立部署的方式,因此,如果业务场景对应的站点是中心站点,则选择独立部署的方式,但是如果是本地站点时,需要跟进当地业务的情况进一步判断业务数据总量所属的预设阈值范围来确定组件的部署方式,也就是说,此时,即使是在本地站点,也不一定采用合并部署的方式来部署组件,而是在判定站点为本地站点的基础上,判定业务数据的数据总量属于第一预设阈值范围时,确定部署方式为独立部署,属于第二预设阈值范围时,采用合并部署。
进一步地,当确定部署方式为合并部署时,可以根据所确定的组件的功能以及待处理业务的业务类型以及业务数据总量来综合考虑,选择哪个组件来进行合并。
通过采用方式三中的方法步骤,综合考虑待处理业务对应的业务场景以及业务数据总量,选择合适的组件部署方式,使得部署更加合理,成本控制更优。
在确定好待处理业务所需的组件,并确定所述组件的部署方式之后,需要确定将所述组件部署在哪些硬件资源上对待处理业务进行处理。在确定目标硬件资源时,可以根据实际情况进行确定,例如:可以根据当前发出待处理业务的设备的位置,选择距离较近的硬件设备进行处理,也可以从成本角度进行考虑,选择运行成本较低且处理速度较快的硬件设备进行处理,具体地,可采用以下方式进行实现:
方式一、只根据距离条件来确定目标硬件资源:
所述采用各个所述组件对应的部署方式部署各个所述组件之前,还可以包括:
确定发出待处理业务请求的设备的位置信息;
根据所述位置信息确定满足预设距离条件的第一目标硬件资源;
所述采用各个所述组件对应的部署方式部署各个所述组件,具体可以包括:
采用各个所述组件对应的部署方式将各个所述组件部署在所述第一目标硬件资源上。
目标硬件资源可以指的是处理所述待处理业务所需要的全部硬件设备。
第一目标硬件资源可以包括一台或多台硬件设备。预设距离条件可以表示的是预先设定的距离范围,比如:距离待处理业务发出设备1km内的硬件资源满足条件。
例如:确定待处理业务的发出设备的位置为位置A,预设距离条件为≤1km,此时,满足条件的硬件资源为X,X中包括硬件设备(B,C,D,E)。可以将确定出的组件按照相应的部署方式部署在硬件设备B,硬件设备C,硬件设备D以及硬件设备E上对待处理业务进行处理。
方式二、根据距离条件以及成本条件来确定目标硬件资源:
所述根据所述位置信息确定满足预设距离条件的第一目标硬件资源之后,还可以包括:
从所述第一目标硬件资源中确定满足预设成本条件的第二目标硬件资源;
所述采用各个所述组件对应的部署方式部署各个所述组件,具体可以包括:
采用各个所述组件对应的部署方式将各个所述组件部署在所述第二目标硬件资源上。
预设成本条件可以表示的是预先设定的成本预算。第一目标资源与第二目标资源中可以有重合的硬件设备,所述第一硬件资源中可以存在多台硬件设备,所述第二硬件资源中可以存在至少一台硬件设备,理论上,第二硬件资源中的硬件设备的数量小于等于第一硬件资源中的硬件设备数量。
在根据距离确定出第一目标硬件资源之后,继续根据预设成本条件来进一步确定既满足预设距离条件,又满足预设成本条件的第二目标硬件资源。
延用方式一中的例子,确定待处理业务的发出设备的位置为位置A,预设距离条件为≤1km,预设成本条件为≤1万元(需要说明的是,本方案中用于举例的预设条件:比如距离条件或者成本条件都仅用于便于对方案进行清楚解释,在实际应用过程中,预设条件都是根据业务的具体应用场景来具体设定),此时,满足条件的硬件资源为X,X中包括硬件设备(B,C,D,E),在此基础上,确定若使用设备B,大概需要花费1000元,使用设备C大概需要花费5000元,使用设备D大概花费1万5,使用设备E大概需要花费3000元。此时,根据预设成本条件,可以得到满足预设成本条件的设备为设备B、设备C和设备E,此时得到第二目标硬件资源X’为{设备B,设备C,设备E}。采用确定的部署方式将确定好的组件部署在设备B、设备C和设备E上对待处理业务进行处理。
通过上述的方式一和方式二,单独根据距离条件或者结合距离条件和成本条件来确定将组件部署在对应的硬件资源上,能够充分考虑到数据处理的速度以及成本来进行灵活部署,能更轻松应对复杂场景能力,既能满足高并发、大流量场景进行拆分独立部署需求,又能达到在满足小业务场景下业务需求和发展的同时,大幅度的精简成本、降低部署的复杂度的要求。
在实际的应用部署中,在为硬件资源进行分配时,还可以考虑硬件资源中各个硬件设备的负载能力,根据负载能力来均匀分配待处理业务,具体步骤如下:
所述采用各个所述组件对应的部署方式将各个所述组件部署在目标硬件资源上之后,还可以包括:
采用所述目标硬件资源对所述待处理业务进行处理。
在将待处理业务分发给所述目标硬件资源进行处理时,由于目标硬件资源中每个硬件设备的负载能力以及运行状态可能会出现某些硬件设备接收一两条业务数据后就会达到负载饱和,而某些硬件设备能一次性接收多条业务数据,因此,每个硬件设备能处理的业务数据量可能不同,此时应该将待处理的业务数据在硬件设备资源内均衡分配。具体可以采用以下步骤:
所述采用所述目标硬件资源对所述待处理业务进行处理,具体可以包括:
获取所述目标硬件资源中各硬件设备的负载能力;
根据所述负载能力确定每个所述硬件设备对应的可承载业务数据量;
按照所述可承载业务数据量,将所述待处理业务均匀分发给每个所述硬件设备进行处理。
通过上述的方法步骤,能将待处理业务均匀分配给目标硬件资源中的硬件设备,提高数据处理效率。
基于同样的思路,本说明书实施例还提供了上述方法对应的装置。图3为本说明书实施例提供的对应于图2的一种应用部署装置的结构示意图。
如图3所示,该装置可以包括:
获取模块301,用于获取待处理业务的业务类型信息以及用于表征所述待处理业务数据总量的表征信息;
组件确定模块302,用于根据所述业务类型信息确定处理所述待处理业务所需的组件;
组件部署方式确定模块303,用于根据所述表征信息确定各个所述组件的部署方式,所述部署方式包括独立部署和/或合并部署;
部署模块304,用于采用各个所述组件对应的部署方式部署各个所述组件。
可选的,所述组件确定模块302,具体可以包括:
业务流程确定单元,用于根据所述待处理业务的业务类型信息确定所述待处理业务对应的业务流程;
组件确定单元,用于根据所述业务流程确定出实现所述业务流程对应的组件。
可选的,所述装置,还可以包括:
判断模块,用于根据预设的组件标识判断所述组件是否为可拆合组件,所述组件标识包括可拆合标识和不可拆合标识;
当所述组件为可拆合组件时,执行根据所述表征信息确定各个所述组件的部署方式这一步骤。
可选的,所述表征信息表示所述待处理业务的业务场景,
所述组件部署方式第一确定模块,具体可以包括:
站点确定单元,用于对于任意一个所述组件,确定所述业务场景对应的站点;
判断单元,用于判断所述站点是否为中心站点,得到第一判断结果;
部署方式第一确定单元,用于当所述第一判断结果表示所述站点为中心站点时,确定所述任意一个所述组件的部署方式为独立部署;
当所述第一判断结果表示所述站点为非中心站点时,确定所述任意一个所述组件的部署方式为合并部署。
可选的,所述表征信息表示所述待处理业务的数据总量,
所述组件部署方式第二确定模块,具体可以包括:
业务数据总量确定单元,用于对于任意一个所述组件,确定所述待处理业务的数据总量;
部署方式第二确定单元,用于当所述待处理业务的数据总量属于第一预设阈值范围时,确定所述任意一个所述组件的部署方式为独立部署;
当所述待处理业务的数据总量属于第二预设阈值范围时,确定所述任意一个所述组件的部署方式为合并部署,所述第一预设阈值范围的最小值大于所述第二预设阈值范围的最小值,所述第一预设阈值范围的最大值大于所述第二预设阈值范围的最大值。
可选的,所述表征信息表示所述待处理业务的业务场景以及所述待处理业务的数据总量,
所述组件部署方式第三确定模块,具体可以包括:
站点确定单元,用于对于任意一个所述组件,确定所述业务场景对应的站点;
判断单元,用于判断所述站点是否为中心站点,得到第一判断结果;
部署方式第一确定单元,用于当所述第一判断结果表示所述站点为中心站点时,确定所述任意一个所述组件的部署方式为独立部署;
业务数据总量确定单元,用于当所述第一判断结果表示所述站点为非中心站点时,确定所述待处理业务的数据总量;
部署方式第二确定单元,用于当所述待处理业务的数据总量属于第一预设阈值范围时,确定所述任意一个所述组件的部署方式为独立部署;
当所述待处理业务的数据总量属于第二预设阈值范围时,确定所述任意一个所述组件的部署方式为合并部署,所述第一预设阈值范围的最小值大于所述第二预设阈值范围的最小值,所述第一预设阈值范围的最大值大于所述第二预设阈值范围的最大值。
可选的,所述装置,还可以包括:
位置信息确定模块,用于确定发出待处理业务请求的设备的位置信息;
第一目标硬件资源确定模块,用于根据所述位置信息确定满足预设距离条件的第一目标硬件资源;
所述部署模块,具体可以包括:
第一部署单元,用于采用各个所述组件对应的部署方式将各个所述组件部署在所述第一目标硬件资源上。
可选的,所述装置,还可以包括:
第二目标硬件资源确定模块,用于从所述第一目标硬件资源中确定满足预设成本条件的第二目标硬件资源;
所述部署模块,具体可以包括:
第二部署单元,用于采用各个所述组件对应的部署方式将各个所述组件部署在所述第二目标硬件资源上。
可选的,所述装置,还可以包括:
业务处理模块,用于采用所述目标硬件资源对所述待处理业务进行处理。
基于同样的思路,本说明书实施例还提供了上述方法对应的设备。
图4为本说明书实施例提供的对应于图2的一种应用部署设备的结构示意图。如图4所示,设备400可以包括:
至少一个处理器410;以及,
与所述至少一个处理器通信连接的存储器430;其中,
所述存储器430存储有可被所述至少一个处理器410执行的指令420,所述指令被所述至少一个处理器410执行,以使所述至少一个处理器410能够:
获取待处理业务的业务类型信息以及用于表征所述待处理业务数据总量的表征信息;
根据所述业务类型信息确定处理所述待处理业务所需的组件;
根据所述表征信息确定各个所述组件的部署方式,所述部署方式包括独立部署和/或合并部署;
采用各个所述组件对应的部署方式部署各个所述组件。
在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray,FPGA))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(Hardware Description Language,HDL),而HDL也并非仅有一种,而是有许多种,如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等,目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。