发明内容
本申请提供一种数据的处理方法、设备以及存储介质,能够依据不同的用户请求确定对应的执行顺序,并依据执行顺序执行用户请求所请求的内容,提高了多个服务器的兼容性和便利性。
第一方面,本申请实施例提供一种数据的处理方法,应用于第一服务器,第一服务器为服务器集群中的任一服务器,方法包括:
接收网关按照第一配置信息发送的任务数据,任务数据包括用户请求,第一配置信息为基于用户请求确定的,用于指示完成用户请求所需的多个服务器和服务器间的执行顺序,多个服务器包括第一服务器;
基于任务数据,执行用户请求中与第一服务器对应的任务,得到任务的处理结果。
第二方面,本申请实施例提供一种数据的处理方法,应用于网关,网关与服务器集群中的任意一个或多个服务器连接,其特征在于,包括:
获取与用户请求对应的上下文,上下文包括第一配置信息,第一配置信息为基于用户请求确定的,用于指示完成用户请求所需的多个服务器和服务器间的执行顺序,多个服务器包括至少一个第一服务器;
基于第一配置信息,确定至少一个第一服务器;
基于用户请求和上下文,得到任务数据,并将任务数据发送至至少一个第一服务器。
第三方面,本申请实施例提供一种数据的处理方法,应用于云服务器,方法包括:
接收网关发送的用户请求;
确定用户请求的业务类型;
基于业务类型,生成与用户请求对应的上下文。
第四方面,本申请实施例提供一种服务器,包括:
接收模块,用于接收网关按照第一配置信息发送的任务数据,任务数据包括用户请求,第一配置信息为基于用户请求确定的,用于指示完成用户请求所需的多个服务器和服务器间的执行顺序,多个服务器包括第一服务器;
处理模块,用于基于任务数据,执行用户请求中与第一服务器对应的任务,得到任务的处理结果。
第五方面,本申请实施例提供一种网关,包括:
获取模块,用于获取与用户请求对应的上下文,上下文包括第一配置信息,第一配置信息为基于用户请求确定的,用于指示完成用户请求所需的多个服务器和服务器间的执行顺序,多个服务器包括至少一个第一服务器;
处理模块,用于基于第一配置信息,确定至少一个第一服务器;
处理模块还用于基于用户请求和上下文,得到任务数据,并将任务数据发送至至少一个第一服务器。
第六方面,本申请实施例提供一种云服务器,包括:
接收模块,用于接收网关发送的用户请求;
处理模块,用于确定用户请求的业务类型;
处理模块还用于基于业务类型,生成与用户请求对应的上下文。
第七方面,本申请实施例提供一种服务器,包括:存储器和处理器;
存储器存储计算机执行指令;
处理器执行存储器存储的计算机执行指令,使得处理器执行第一方面或其各实施方式中的方法。
第八方面,本申请实施例提供一种网关,包括:存储器和处理器;
存储器存储计算机执行指令;
处理器执行存储器存储的计算机执行指令,使得处理器执行第二方面或其各实施方式中的方法。
第九方面,本申请实施例提供一种网关,包括:存储器和处理器;
存储器存储计算机执行指令;
处理器执行存储器存储的计算机执行指令,使得处理器执行第二方面或其各实施方式中的方法。
第十方面,本申请实施例提供一种云服务器,包括:存储器和处理器;
存储器存储计算机执行指令;
处理器执行存储器存储的计算机执行指令,使得处理器执行第三方面或其各实施方式中的方法。
第十一方面,本申请实施例提供一种存储介质,包括:可读存储介质和计算机程序,计算机程序用于实现第一方面、第二方面、第三方面或其各实现方式中的方法。
本申请实施例,通过第一服务器接收网关按照第一配置信息发送的任务数据,再基于任务数据执行用户请求中与第一服务器对应的任务,得到处理结果,其中,第一配置信息时基于用户请求确定的,能够指示完成用户请求所需的多个服务器和服务器间的执行顺序,实现了针对用户请求对服务器集群中的服务器进行灵活编排,增加了服务器集群的兼容性。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
目前,常通过服务器集群中的多个服务器协同工作,为用户提供服务。多个服务器之间通过有线或者无线的方式连接,根据实际的应用场景,各服务器既可以是串行关系也可以是并行关系,结合图1所示,服务器集群中包括服务器A至N,服务器A和服务器B、C为串行关系,服务器B和服务器C为并行关系。以金融服务为例,用户A向服务器A发起一次贷款请求,服务器A执行该用户请求中与服务器A对应的任务,例如对用户的权益进行认证,进而,根据预先设置的执行顺序,服务器A将用户请求和权益认证的处理结果发送至服务器B和服务器C,服务器B和服务器C分别执行各自的任务,例如服务器B确定该用户的用户信用,服务器C确定该用户所能享受的折扣,进一步地,服务器C将处理结果和用户请求发送至下游的服务器D,服务器D确定该用户的还款利息,服务器B将处理结果和用户请求发送至下游服务器直至到达最下游的服务器N,最终服务器N确定向该用户发放贷款的额度。
在上述场景中,各服务器间的执行顺序维护在各自的系统内部,一旦业务流程发生变更,需要重新维护执行顺序,兼容性较差,无法广泛应用;并且,各服务器的处理结果没有统一存储,存在数据遗失的可能,增大了服务器集群正常运行的风险;另一方面,服务器内部多个模块多为串行关系,业务耦合严重。
针对上述问题,本申请实施例提供一种数据的处理方法,针对不同的用户请求,使用对应的上下文对服务器集群中每个服务器的执行顺序进行知识,解决了执行顺序无法兼容多种业务流程的问题;通过云服务器将各服务器的处理结果存储在上下文中,实现了处理结果的统一存储,避免执行数据丢失;并针对不同的用户请求使用对应的上下文对每个服务器内部模块的执行顺序进行指示,解决了服务器的内部模块耦合严重的问题,提高了处理效率。
图2为本申请实施例提供的一种数据的处理系统200的结构示意图。如图2所示,数据的处理系统200包括:终端设备201,网关202、204,服务器205、206和云服务器207。
网关202连接于终端设备201和服务器203之间,网关204连接在服务器203与服务器205、206之间,应理解,数据的处理系统200可以包括更多或者更少的服务器和网关。
应理解,图中服务器203为服务器205和服务器206的上游服务器,服务器205和服务器206为并行服务器,示例性的,数据的处理系统200还包括服务器205和服务器206的下游服务器。
每个网关或服务器均与云服务器207连接。
应理解,上述各设备的连接方式均可以是有线或者无线的连接方式,且各设备均设置有标准化接口,通过标准化协议进行信息传输。
其中,终端设备201用于接收用户的操作以生成用户请求,并向服务器集群发送该用户请求。可选的,终端设备可以是手机(Mobile Phone)、平板电脑(Pad)、电脑、虚拟现实(Virtual Reality,VR)终端设备、增强现实(Augmented Reality,AR)终端设备、工业控制(industrial control)中的终端设备、无人驾驶(self driving)中的终端设备、远程医疗(remote medical)中的终端设备、智慧城市(smart city)中的终端设备或智慧家庭(smarthome)中的终端设备等中的任意一种。本申请实施例中的终端设备201还可以是可穿戴设备,可穿戴设备也可以称为穿戴式智能设备,是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称,如眼镜、手套、手表、服饰及鞋等。可穿戴设备即直接穿在身上,或是整合到用户的衣服或配件的一种便携式设备,终端设备201均可以是固定的或者移动的。
网关202接收终端设备201发送的用户请求,将用户请求发送至云服务器207,云服务器207对用户请求进行识别,得到用户请求对应的上下文,该上下文用于指示服务器集群中的至少一个服务器按照预设的执行规则执行对应的任务,完成该用户请求。
可选的,云服务器207中部署有云服务平台和云存储。
网关202和网关204均可用于从云服务器207获取上下文,以获取至少一个第一服务器的标识,根据至少一个第一服务器的标识向对应的目标服务器发送任务数据,该任务数据包括用户请求,在一些实施例中任务数据还包括至少一个第二服务器的标识,即第一服务器执行用户请求之前执行该用户请求的上游服务器。结合图2所示,服务器203相对于网关202为第一服务器,服务器203相对于网关204为第二服务器,服务器205和服务器206相对于网关204为第一服务器。
服务器203、205和206,在接收到网关发送的任务数据后,执行用户请求中与各自对应的任务,并将处理结果发送至云服务器207,存储在上下文中。在一些实施例中,各服务器在接收到网关发送的任务数据后,从云服务器207获取上下文,基于上下文中存储的上游服务器的处理结果,执行本服务器的任务;在另一些实施例中,服务器205或服务器206在接收到网关发送的任务数据后,从云服务器207获取上下文,并基于上下文确定是否该本服务器执行用户请求,在确定该本服务器执行用户请求的情况下,再执行用户请求中与本服务器对应的任务。
图3为本申请实施例提供的一种数据的处理方法300的流程示意图。
为了能够实现服务器间的灵活编排,使多个服务器针对不同的用户请求,协同完成各自的任务,本申请实施例提出如图3所示的实现方案,具体步骤如下:
S301:接收网关按照第一配置信息发送的任务数据。
一般来说,用户可通过终端设备向网关发送用户请求,网关接收到用户请求后基于用户请求得到任务数据,示例性的,用户请求可直接作为任务数据,或者用户请求和其他相关信息一同作为任务数据,并基于第一配置信息确定至少一个第一服务器,再将任务数据发送至至少一个第一服务器,该第一服务器为服务器集群中的一个服务器。应理解,第一配置信息为基于用户请求确定的,换句话说第一配置信息与用户请求之间存在对应关系,第一配置信息用于指示完成用户请求所需的多个服务器,以及多个服务器在执行用户请求对应的任务时的执行顺序。
对于服务器间的网关,接收上游服务器(也称作第二服务器)发送的任务数据中的用户请求,确定了至少一个第一服务器后,即向至少一个第一服务器发送包含用户请求的任务数据。
相应的,本申请实施例中,服务器集群中的任一服务器,接收到网关发送的任务数据,该服务器即为网关确定的至少一个第一服务器中的一个。
S302:基于任务数据,执行用户请求中与第一服务器对应的任务,得到任务的处理结果。
应理解,任务数据中至少包括用户请求,那么第一服务器接收到网关发送的任务数据后,根据任务数据中的用户请求,即执行用户请求中与本第一服务器对应的任务,得到该任务的处理结果。
本申请实施例中,第一服务器接收网关按照第一配置信息发送的任务数据,再基于任务数据执行用户请求中与第一服务器对应的任务,得到处理结果,其中,第一配置信息时基于用户请求确定的,能够指示完成用户请求所需的多个服务器和服务器间的执行顺序,实现了针对用户请求对服务器集群中的服务器进行灵活编排,增加了服务器集群的兼容性。
图4为本申请实施例提供的一种数据的处理方法400的流程交互示意图。如图4所示,该方法包括:
S401:网关从云服务器获取与用户请求对应的上下文。
网关在接收到用户请求之后,从云服务器获取与该用户请求对应的上下文,该上下文包括与该用户请求对应的第一配置信息。
S402:网关基于第一配置信息,确定至少一个第一服务器。
第一配置信息中设置有执行用户请求所需的多个服务器,以及多个服务器各自需要执行的用户请求的任务,和执行各自任务的顺序。
网关根据第一配置信息,确定将要执行用户请求的至少一个第一服务器。示例性的,第一配置信息中按顺序设置了多个服务器的标识,网关可根据第二服务器(即已执行过用户请求的服务器)的标识,确定将要执行用户请求的至少一个第一服务器的标识;或者,上下文中还包括执行数据,该执行数据为至少一个第二服务器上传的处理结果,网关可根据上下文中的执行数据确定出已执行用户请求的第二服务器,再根据第一配置信息,确定将要执行用户请求的至少一个第一服务器。
S403:网关基于用户请求和上下文,得到任务数据。
在本步骤中,网关将用户请求和上下文的标识作为任务数据,或者将用户请求和上下文作为任务数据。
在一些实施例中,网关将用户请求、上下文的标识和第二服务器的标识作为任务数据。
S404:网关向至少一个第一服务器发送任务数据。
一般来说,网关向每个第一服务器发送的任务数据相同。多个第一服务器接收到任务数据后,并行处理各自对应的任务。
S405:每个第一服务器基于任务数据,执行用户请求中与服务器对应的任务,得到任务的处理结果。
本实施例中,网关从云服务器中获取与用户请求对应的上下文,并基于上下文中的第一配置信息确定至少一个第一服务器,再将任务数据发送至至少一个第一服务器,使第一服务器基于任务数据执行用户请求中与本第一服务器对应的任务,相比于现有技术中仅能根据预设的上游服务器和下游服务器之间的关系,向固定的下游服务器发送任务数据,本实施例可基于用户请求编排对应的执行顺序,通过网关的控制,使对应的服务器按照执行顺序执行用户请求中对应的任务。
图5为本申请实施例提供的一种数据的处理方法500的流程交互示意图。本申请实施例在网关从云服务器获取与用户请求对应的上下文之前,提供如下可能的实现方式:
首先,网关需要获取用户请求,网关获取用户请求包括以下两种可能的场景:
场景一:连接于终端设备和第一服务器之间的网关,该网关接收终端设备发送的用户请求,并将该用户请求发送至云服务器,使云服务器基于用户请求确定业务类型,再根据业务类型生成与用户请求对应的上下文,进而网关从云服务器获取该用户请求对应的上下文。在一些实施例中,终端设备还基于用户请求生成对应的上下文,并将上下文发送给网关,那么网关不需再向云服务器发送用户请求,也不需要从云服务器获取上下文。
场景二:连接于第二服务器和第一服务器之间的网关,应理解,网关所连接的第二服务器和第一服务器的数量均可以为多个,当第二服务器执行了用户请求中与该第二服务器对应的任务后,即向网关发送用户请求,在一些实施例中,还向网关发送上下文,网关在获取用户请求后即获取该用户请求对应的上下文。
结合图5所示,在场景一中,网关从云服务器获取与用户请求对应的上下文之前,还包括:
S501-1:获取终端设备发送的用户请求。
S502:网关将用户请求发送至云服务器。
S503:云服务器确定用户请求的业务类型。
S504:云服务器基于业务类型,生成与用户请求对应的上下文。
例如,用户请求为请求偿还本期利息或者请求偿还剩余借款,则确定该用户请求的业务类型为还款类型,那么云服务器基于该业务类型,生成与该用户请求对应的上下文,应理解,上下文为一种结构体,该结构体可定义如下:
需要说明的是,每个用户请求对应一个上下文,每个业务类型对应一个第一配置信息,每个业务类型对应一个第二配置信息;会话ID为上下文的唯一标识,执行数据为服务器集群中的服务器执行各自任务已完成用户请求时上传的处理结果。
在场景二中,网关从云服务器获取与用户请求对应的上下文之前,还包括:
S501-2:获取第二服务器发送的用户请求。
应理解,在第二服务器发送用户请求之前,已生成了与用户请求对应的上下文。
第二服务器基于其接收到的用户请求以及获取的上下文,执行了用户请求中与自身对应的任务后,示例性的,将处理结果上传至云服务器存储在上下文的执行数据中,并向网关发送用户请求。
S505:网关获取与用户请求对应的上下文。
示例性的,第二服务器可直接将上下文发送至网关,或者第二服务器将上下文的标识(例如会话ID)发送至网关,网关根据上下文的标识从云服务器读取该上下文,或者网关根据用户请求从云服务器中匹配得到对应的上下文,本申请对此不做限制。
应理解,不通过云服务器集中管理上下文,使数据处理的流程更加灵活,通过云服务器集中管理上下文,能够减少服务器之间所传递数据的数据量,提高处理效率。
S506:网关基于第一配置信息,确定至少一个第一服务器。
S507:网关基于用户请求和上下文,得到任务数据。
S508:网关向至少一个第一服务器发送任务数据。
步骤S506至S508与图4所示实施例中的步骤S402至S404类似,此处不再赘述。
S509:至少一个第一服务器获取与用户请求对应的上下文。
针对至少一个第一服务器中的每个第一服务器,在接收到任务数据后,获取用户请求对应的上下文。
示例性的,获取用户请求对应的上下文包括以下两种可能的实现方式:
一、任务数据还包括与用户请求对应的上下文的标识,则第一服务器基于上下文的标识,从云服务器中读取该上下文。
二、任务数据还包括与用户请求对应的上下文,则第一服务器接收网关发送的任务数据时,即获取到该上下文。
应理解,在本实施例中,上下文还包括第二配置信息,第二配置信息用于指示完成服务器对应的任务所需的至少一个模块和至少一个模块间的执行顺序。
结合图6所示,假设第一服务器中有四个模块,模块a、模块b、模块c和模块d,第二配置信息可以指示该第一服务器在执行该用户请求时只执行模块a和模块c,或者指示该第一服务器在执行该用户请求时先执行模块a和模块b再执行模块c和模块d。
S510:每个第一服务器基于第二配置信息,控制至少一个模块按照执行顺序,执行用户请求中与第一服务器对应的任务,得到任务的处理结果。
在本步骤中,每个第一服务器根据第二配置信息的指示,控制对应的模块按照执行顺序,执行用户请求中与第一服务器对应的任务,得到任务的处理结果。
示例性的,每个服务器中的多个模块之间存在预设的并行或者串行的数据处理方式,一般来说第二配置信息所指示的模块间的执行顺序应满足多个模块之间预设的并行或者串行的数据处理方式。
例如,第一服务器中预设的模块a与模块b可并行,模块d和模块c可并行,模块a和模块d串行,模块b和模块c串行,则第二配置信息可指示先执行模块a、b,后执行模块c、d,而不可指示先执行模块a、c,再执行模块b、d。并行的模块之间没有相互的执行依赖,能够并发处理,提高了处理效率。
在一种具体的实现方式中,本申请实施例中的上下文还包括执行数据,执行数据为至少一个第二服务器执行用户请求所产生的处理结果,第二服务器为任一在第一服务器之前执行用户请求的服务器,则第一服务器基于第二配置信息,控制至少一个模块按照所述执行顺序,根据执行数据,执行用户请求中与第一服务器对应的任务,得到任务的处理结果。
一般来说,第二服务器执行用户请求所产生的处理结果,将作为第一服务器执行用户请求的输入变量。
在上述任一实施例的基础上,为了确保用户请求的流转方向符合第一配置信息的设定,本实施例中,第一服务器在执行用户请求中与第一服务器对应的任务之前,需要对用户请求的执行顺序是否满足第一配置信息中设置的多个服务器的执行顺序进行确认。示例性的,网关向第一服务器发送的任务数据中还包括第二服务器的标识,第一服务器基于第二服务器的标识和第一服务器的标识,确定用户请求的执行顺序是否满足第一配置信息中设置的多个服务器的执行顺序,若用户请求的执行顺序满足第一配置信息中设置的多个服务器的执行顺序,则执行用户请求中与所述第一服务器对应的任务,得到所述任务的处理结果,若用户请求的执行顺序不满足第一配置信息中设置的多个服务器的执行顺序,则结束本第一服务器的数据处理过程,或者结束本次服务器集群针对该用户请求的数据处理过程,避免数据处理过程存在异常导致处理结果出错。
在上述任一实施例的基础上,当第一服务器执行完成后,将任务的处理结果发送至云服务器,存储在上下文的执行数据中。
示例性的,在针对用户请求进行数据处理的每个服务器均执行完成后,由最下游的服务器向最上游的服务器依次返回处理结果,最终由最上游的处理器,例如图2中所示的服务器103,向终端设备返回针对用户请求的处理结果。
综上所述,本申请实施例运用上下文实现了跨服务器的信息存储,个服务器根据上下文中的信息,进行服务器之间的灵活流转以及内部流程的实时动态编排,提高了数据的处理系统的可扩展性和可维护性,服务器内部模块可设置为多线程多模块的并发处理,且无外部依赖,降低了对用户请求的相应时间,提高了数据处理的效率。
图7为本申请实施例提供的一种服务器700的结构示意图,如图7所示,该服务器700包括:
接收模块710,用于接收网关按照第一配置信息发送的任务数据,任务数据包括用户请求,第一配置信息为基于用户请求确定的,用于指示完成用户请求所需的多个服务器和服务器间的执行顺序,多个服务器包括第一服务器;
处理模块720,用于基于任务数据,执行用户请求中与第一服务器对应的任务,得到任务的处理结果。
本实施例提供的一种服务器700包括接收模块710和处理模块720,通过接收网关按照第一配置信息发送的任务数据,再基于任务数据执行用户请求中与第一服务器对应的任务,得到处理结果,其中,第一配置信息时基于用户请求确定的,能够指示完成用户请求所需的多个服务器和服务器间的执行顺序,实现了针对用户请求对服务器集群中的服务器进行灵活编排,增加了服务器集群的兼容性。
在一种可能的设计中,处理模块720具体用于:
获取用户请求对应的上下文,上下文包括第二配置信息,第二配置信息为基于用户请求确定的,用于指示完成服务器对应的任务所需的至少一个模块和至少一个模块间的执行顺序;
基于第二配置信息,控制至少一个模块按照执行顺序,执行用户请求中与第一服务器对应的任务,得到任务的处理结果。
在一种可能的设计中,处理模块720具体用于:
基于上下文的标识,从云服务器中读取上下文。
在一种可能的设计中,处理模块720具体用于:
基于第二配置信息,控制至少一个模块按照执行顺序,执行用户请求中与服务器对应的任务,得到任务的处理结果。
在一种可能的设计中,处理模块720具体用于:
基于第二配置信息,控制至少一个模块按照执行顺序,根据执行数据,执行用户请求中与第一服务器对应的任务,得到任务的处理结果。
在一种可能的设计中,处理模块720具体用于:
基于第二服务器的标识和第一服务器的标识,确定用户请求的执行顺序是否满足第一配置信息中设置的多个服务器的执行顺序;
若用户请求的执行顺序满足第一配置信息中设置的多个服务器的执行顺序,则执行用户请求中与第一服务器对应的任务,得到任务的处理结果;
若用户请求的执行顺序不满足第一配置信息中设置的多个服务器的执行顺序,则结束数据处理过程。
图8为本申请实施例提供的另一种服务器700的结构示意图,如图8所示,该服务器700还包括:
发送模块730,用于将任务的处理结果发送至云服务器,存储在上下文的执行数据中。
本实施例提供的一种服务器可用于实现上述任一实施例中第一服务器侧的方法,其实现效果与方法实施例类似,此处不再赘述。
图9为本申请实施例提供的一种网关900的结构示意图,如图9所示,该网关900包括:
获取模块910,用于获取与用户请求对应的上下文,上下文包括第一配置信息,第一配置信息为基于用户请求确定的,用于指示完成用户请求所需的多个服务器和服务器间的执行顺序,多个服务器包括至少一个第一服务器;
处理模块920,用于基于第一配置信息,确定至少一个第一服务器;
处理模块920还用于基于用户请求和上下文,得到任务数据,并将任务数据发送至至少一个第一服务器。
在一种可能的设计中,获取模块910还用于:
获取用户请求;
将用户请求发送至云服务器;
从云服务器中获取上下文。
在一种可能的设计中,获取模块910具体用于:
接收第二服务器发送的用户请求;
则基于用户请求,得到任务数据,包括:
将用户请求、第二服务器的标识和上下文的标识作为任务数据;或者将用户请求、第二服务器的标识和上下文的标识作为任务数据。
本实施例提供的一种服务器可用于实现上述任一实施例中网关侧的方法,其实现效果与方法实施例类似,此处不再赘述。
图10为本申请实施例提供的一种云服务器1000的结构示意图,如图10所示,该云服务器1000包括:
接收模块1010,用于接收网关发送的用户请求;
处理模块1020,用于确定用户请求的业务类型;
处理模块1020还用于基于业务类型,生成与用户请求对应的上下文。
本实施例提供的一种服务器可用于实现上述任一实施例中云服务器侧的方法,其实现效果与方法实施例类似,此处不再赘述。
图11为本申请一实施例提供的电子设备1100的硬件结构示意图。如图11所示,通常,电子设备1100包括有:处理器1110和存储器1120。
处理器1110可以包括一个或多个处理核心,比如4核心处理器、8核心处理器等。处理器1110可以采用DSP(Digital Signal Processing,数字信号处理)、FPGA(Field-Programmable Gate Array,现场可编程门阵列)、PLA(Programmable Logic Array,可编程逻辑阵列)中的至少一种硬件形式来实现。处理器1110也可以包括主处理器和协处理器,主处理器是用于对在唤醒状态下的数据进行处理的处理器,也称CPU(Central ProcessingUnit,中央处理器);协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中,处理器1110可以在集成有GPU(Graphics Processing Unit,图像处理器),GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中,处理器1001还可以包括AI(Artificial Intelligence,人工智能)处理器,该AI处理器用于处理有关机器学习的计算操作。
存储器1120可以包括一个或多个计算机可读存储介质,该计算机可读存储介质可以是非暂态的。存储器1120还可包括高速随机存取存储器,以及非易失性存储器,比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中,存储器1120中的非暂态的计算机可读存储介质用于存储至少一个指令,该至少一个指令用于被处理器1110所执行以实现本申请中方法实施例提供的方法。
可选地,如图11所示,电子设备1100还可以包括收发器1130,处理器1110可以控制该收发器1130与其他设备进行通信,具体地,可以向其他设备发送信息或数据,或接收其他设备发送的信息或数据。
其中,收发器1130可以包括发射机和接收机。收发器1130还可以进一步包括天线,天线的数量可以为一个或多个。
可选地,该电子设备1100可以为上述实施例中的服务器、网关和云服务器中的任意一种,可以实现本申请实施例的各个方法中的相应流程,为了简洁,在此不再赘述。
本领域技术人员可以理解,图11中示出的结构并不构成对电子设备1100的限定,可以包括比图示更多或更少的组件,或者组合某些组件,或者采用不同的组件布置。
本申请实施例还提供了一种非临时性计算机可读存储介质,当所述存储介质中的指令由网关的处理器执行时,使得电子设备能够执行上述实施例提供的方法。
本实施例中的计算机可读存储介质可以是计算机能够存取的任何可用介质,或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备,可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如SSD)等。
本领域普通技术人员可以理解:实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时,执行包括上述各方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
本申请实施例还提供了一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述实施例提供的方法。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上所述仅为本申请的较佳实施例,并不用以限制本申请,凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。