一种业务服务实现方法、系统、计算设备及存储介质

技术领域

本发明涉及互联网技术领域，尤其涉及一种业务服务实现方法、业务服务实现系统、计算设备及存储介质。

背景技术

随着互联网公司业务的快速发展，用户量增多，随之而来的就是访问量的激增。面对大流量、高并发的场景，仅通过业务服务层程序来控制流量已经不能满足需求，而且，会造成业务系统的架构庞大且复杂，维护成本高，且容易出问题。

现有技术中，为了承接高并发流量，可以采用网关服务结合业务系统的方法，网关服务负责支撑流量转发、过滤、查询结果缓存等基础功能，业务全部交由核心业务系统。这种方案存在以下缺陷：一旦有大量满足需求的流量进入核心业务系统，会造成业务系统压力骤增，如果处理不当可能会造成系统宕机，服务中断；为了应对大流量业务系统，通常会引入一些控制方法，增加了系统复杂度；业务系统的实现方式受限，开发语言性能问题难以有效地解决；每次业务需求变更需要重新发布整个系统。

为此，需要一种业务服务实现方法及系统，以实现对各业务服务进行统一配置和管理，解决上述技术方案中存在的问题。

发明内容

为此，本发明提供一种业务服务实现方法及业务服务实现系统，以解决或至少缓解上面存在的问题。

根据本发明的一个方面，提供一种业务服务实现方法，在管理平台执行，包括：根据业务线的业务名称和描述信息，生成业务线类型；根据业务线类型，为业务线配置生成对应的业务配置信息并存储，所述业务配置信息包括业务请求路径和验证预设值；根据所述业务配置信息，构建业务脚本，并生成对应的版本号；将所述业务脚本推送至测试服务端进行验证，所述测试服务端适于在验证成功后，将所述业务脚本推送至线上服务端进行上线，以便根据上线的业务脚本提供业务服务。

可选地，在根据本发明的业务服务实现方法中，将所述业务脚本推送至测试服务端进行验证，包括：向所述测试服务端发送对所述业务脚本的验证请求，并接收所述测试服务端返回的验证结果；将所述验证结果与所述业务配置信息中的验证预设值进行比对，如果比对结果一致，则确定验证结果为验证成功；如果比对结果不一致，则确定验证结果为验证失败。

可选地，在根据本发明的业务服务实现方法中，所述测试服务端适于：根据所述业务脚本生成待验证摘要值，并将所述待验证摘要值与所述测试服务端中存储的预期摘要值进行比对，如果比对结果一致，则验证成功；如果比对结果不一致，则验证失败。

可选地，在根据本发明的业务服务实现方法中，所述测试服务端还适于对所述业务脚本的版本号进行验证。

可选地，在根据本发明的业务服务实现方法中，还包括：根据选择的目标版本号，生成定时任务；根据所述定时任务，定时将所述目标版本号对应的业务脚本推送至测试服务端进行验证，以自动对所述目标版本号对应的业务脚本进行上线。

可选地，在根据本发明的业务服务实现方法中，还包括：根据所述定时任务，定时向线上服务器请求对所述目标版本号对应的业务脚本进行下线处理。

可选地，在根据本发明的业务服务实现方法中，在定时将所述目标版本号对应的业务脚本推送至测试服务端进行验证之后，还包括：如果验证失败，则触发报警。

可选地，在根据本发明的业务服务实现方法中，所述摘要值为MD5值。

根据本发明的一个方面，提供一种业务服务实现系统，包括：管理平台，适于执行如上所述的方法；服务系统，与所述管理平台通信连接，所述服务系统包括测试服务端和线上服务端，所述测试服务端适于对业务脚本进行验证，并适于在验证成功后将所述业务脚本推送至线上服务端进行上线，以便根据上线的业务脚本提供业务服务。

根据本发明的一个方面，提供一种计算设备，包括：至少一个处理器；存储器，存储有程序指令，其中，程序指令被配置为适于由上述至少一个处理器执行，所述程序指令包括用于执行如上所述的业务服务实现方法的指令。

根据本发明的一个方面，提供一种存储有程序指令的可读存储介质，当该程序指令被计算设备读取并执行时，使得该计算设备执行如上所述的业务服务实现方法。

根据本发明的技术方案，提供了一种业务服务实现方法及系统，其中，可以根据业务线的业务名称和描述信息，生成业务线类型，根据业务线类型来为业务线配置生成对应的业务配置信息(包括业务请求路径、验证预设值)并存储。并且，可以根据业务配置信息构建业务脚本，生成对应的版本号。进而，可以将业务脚本推送至服务系统的测试服务端进行验证，测试服务端在验证成功后，可以将业务脚本推送至线上服务端进行上线，这样，服务系统可以根据上线的业务脚本对外提供业务服务。可见，根据本发明的技术方案，能实现一站式统一配置并编写业务脚本，在对业务脚本进行上线后可以对外提供业务服务，以便将业务服务从核心业务系统中分离出来，保证核心业务系统的稳定性。并且，在进行上线之前还对业务脚本进行自动验证，这样有效保证了业务服务逻辑的正确性，避免因配置错误而导致业务服务无法正常运行。进一步地，各业务服务逻辑可以统一在管理平台进行可视化配置，这样无需直接修改和操作服务系统，从而简化了对业务服务的配置和发布操作。

进一步地，本发明根据目标版本号对相应版本的业务脚本生成定时任务，能实现在无人值守情况下自动对相应版本的业务脚本进行上下线以及报警处理。这样，有利于同时控制多个业务线，统一管理和维护多种业务服务，且无需开发人员干预即可满足服务性能要求，降低了开发人员工作量。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

为了实现上述以及相关目的，本文结合下面的描述和附图来描述某些说明性方面，这些方面指示了可以实践本文所公开的原理的各种方式，并且所有方面及其等效方面旨在落入所要求保护的主题的范围内。通过结合附图阅读下面的详细描述，本公开的上述以及其它目的、特征和优势将变得更加明显。遍及本公开，相同的附图标记通常指代相同的部件或元素。

图1示出了根据本发明一个实施例的业务服务实现系统100的示意图；

图2示出了根据本发明一个实施例的计算设备200的示意图；

图3示出了根据本发明一个实施例的业务服务实现方法300的流程示意图。

具体实施方式

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

根据本发明的业务服务实现方案，能实现对多种业务服务进行统一配置和管理，以便将业务服务逻辑从业务系统中分离出来，确保核心业务系统的稳定性。

图1示出了根据本发明一个实施例的业务服务实现系统100的示意图。

如图1所示，业务服务实现系统100包括管理平台110及服务系统120，管理平台110与服务系统120通信连接，例如可以通过有线或无线的方式网络连接。服务系统120包括相互通信连接的测试服务端121和线上服务端122。

其中，管理平台110可以是开发人员/管理员使用的终端设备，具体可以是桌面电脑、笔记本电脑等个人计算机，也可以是手机、平板电脑、多媒体设备、智能可穿戴设备等移动终端，但不限于此，还可以是驻留在终端设备中的应用程序。

服务系统120可用于管理和维护提供业务服务，其可以实现为现有技术中的任何一种能够管理和维护业务服务的计算设备，本发明对服务系统120的具体种类不作限制。例如，服务端服务系统120可以实现为桌面电脑、笔记本电脑、处理器芯片、手机、平板电脑等，但不限于此。服务系统120也可以是驻留在计算设备中的服务程序。

在一个实施例中，服务系统120中的测试服务端121、线上服务端122可以基于Nginx实现，但本发明不受限于此。

在本发明的实施例中，管理平台110可以根据业务线的业务名称和描述信息来生成业务线类型，根据业务线类型(开发人员选择的业务线类型)来为业务线配置生成对应的业务配置信息，并存储该业务配置信息。这里，业务配置信息可以包括业务请求路径、验证预设值。另外，在其他实施例中，业务配置信息还可以包括数据源接口、限流阈值等。

接下来，管理平台110可以根据业务配置信息来构建与业务线相对应的业务脚本，并生成对应的版本号。之后，管理平台110可以将业务脚本推送至测试服务端121进行验证。具体地，管理平台110可以根据选择的业务配置信息，来将对应生成的业务脚本推送至服务系统120的测试服务端121进行验证。

在本发明的实施例中，测试服务端121可以对业务脚本进行验证。并且，测试服务端121在对业务脚本验证成功后，可以将业务脚本推送至线上服务端122进行上线。这样，服务系统120可以根据上线的业务脚本对外(例如向多个客户端)提供业务服务。可以理解，业务服务即是与业务线相对应的业务服务。

根据本发明的一个实施例，测试服务端121在对业务脚本进行验证时，具体可以根据业务脚本生成待验证摘要值，并将待验证摘要值与测试服务端121中存储的预期摘要值(也即，正确摘要值)进行比对。如果待验证摘要值与测试预期摘要值的比对结果一致，则测试服务端121对业务脚本验证成功。如果待验证摘要值与测试预期摘要值的比对结果不一致，则测试服务端121对业务脚本验证失败。之后，测试服务端121可以将验证结果(验证成功或失败)返回至管理平台110。

在一种实现方式中，上述摘要值(待验证摘要值/预期摘要值)具体可以为MD5值。

另外，在一个实施例中，测试服务端121在对业务脚本进行验证时，还可以对业务脚本的版本号进行验证。

测试服务端121在对业务脚本验证成功的情况下，可以继续将业务脚本推送至线上服务端122，以便线上服务端122对验证通过的业务脚本进行上线。这样，服务系统120可以根据上线的业务脚本对外(例如向多个客户端)提供业务服务。

例如，在一个实施例中，各客户端可以基于业务请求路径来向服务系统120请求对应的业务服务。服务系统120在接收到客户端的业务服务请求后，可以基于请求中的业务请求路径路由到对应的业务服务，以向客户端提供业务服务。需要说明的是，根据上述建立的业务请求路径与业务脚本的关联关系，服务系统120可根据业务请求路径路由到对应的业务服务。

根据本发明的一个实施例，管理平台110可以将业务脚本推送至测试服务端121，并向测试服务端121发送对业务脚本的验证请求，随后，可以接收测试服务端121返回的验证结果。进而，管理平台110可以将测试服务端121返回的验证结果与业务配置信息中的验证预设值(预期结果)进行比对，如果验证结果与验证预设值的比对结果一致，则确定测试服务端121返回的验证结果为验证成功；如果验证结果与验证预设值的比对结果不一致，则确定测试服务端121返回的验证结果为验证失败。

在一些实施例中，通过管理平台110可以针对多个业务线生成对应的多个业务脚本，并可以对多个业务脚本进行验证及上线。这样，服务系统120可以根据已上线的多个业务脚本对外提供多种业务服务(对应多个业务线)。

根据本发明的一个实施例，在将业务脚本推送至线上服务端122进行上线后，可以将已上线的业务脚本加入定时校验任务，这样，基于定时校验任务可以定时自动地对已上线的业务脚本进行验证(可以验证业务脚本的摘要值和/或版本号)。

根据本发明的一个实施例，对于需要自动上下线的业务脚本，管理平台110可以根据选择的目标版本号(或者对应的业务配置信息)来为对应的业务脚本生成定时任务。接下来，管理平台110可以根据该定时任务，来定时将目标版本号对应的业务脚本推送至测试服务端121进行验证，并在验证成功后，自动对目标版本号对应的业务脚本进行上线(即，将目标版本号对应的业务脚本推送至线上服务端122进行上线)。这样，能实现在无人值守情况下自动对业务脚本进行上线。

另外，管理平台110在定时将目标版本号对应的业务脚本推送至测试服务端121进行验证之后，如果测试服务端121对该业务脚本验证失败，则管理平台110可以触发报警。

在一个实施例中，管理平台110还可以根据上述定时任务，来定时对目标版本号对应的业务脚本进行下线。具体地，管理平台110可以根据定时任务，定时向服务系统120的线上服务器请求对目标版本号对应的业务脚本进行下线处理，以便定时对对目标版本号对应的业务脚本进行下线。这样，能实现在无人值守情况下自动对业务脚本进行下线。

在本发明的实施例中，管理平台110被配置为执行本发明的业务服务实现方法300。本发明的业务服务实现方法300将在下文中详述。

在一个实施例中，本发明中的管理平台110、服务系统120(测试服务端121、线上服务端122)分别可以实现为一种计算设备。当管理平台110实现为一种计算设备时，使得本发明的业务服务实现方法300可以在计算设备中执行。

图2示出了根据本发明一个实施例的计算设备200的结构图。如图2所示，在基本的配置202中，计算设备200典型地包括系统存储器206和一个或者多个处理器204。存储器总线208可以用于在处理器204和系统存储器206之间的通信。

取决于期望的配置，处理器204可以是任何类型的处理，包括但不限于：微处理器(μP)、微控制器(μC)、数字信息处理器(DSP)或者它们的任何组合。处理器204可以包括诸如一级高速缓存210和二级高速缓存212之类的一个或者多个级别的高速缓存、处理器核心214和寄存器216。示例的处理器核心214可以包括运算逻辑单元(ALU)、浮点数单元(FPU)、数字信号处理核心(DSP核心)或者它们的任何组合。示例的存储器控制器218可以与处理器204一起使用，或者在一些实现中，存储器控制器218可以是处理器204的一个内部部分。

取决于期望的配置，系统存储器206可以是任意类型的存储器，包括但不限于：易失性存储器(诸如RAM)、非易失性存储器(诸如ROM、闪存等)或者它们的任何组合。系统存储器106可以包括操作系统220、一个或者多个应用222以及程序数据224。应用222实际上是多条程序指令，其用于指示处理器204执行相应的操作。在一些实施方式中，应用222可以布置为在操作系统上使得处理器204利用程序数据224进行操作。

计算设备200还可以包括有助于从各种接口设备(例如，输出设备242、外设接口244和通信设备246)到基本配置202经由总线/接口控制器230的通信的接口总线240。示例的输出设备242包括图形处理单元248和音频处理单元250。它们可以被配置为有助于经由一个或者多个A/V端口252与诸如显示器或者扬声器之类的各种外部设备进行通信。示例外设接口244可以包括串行接口控制器254和并行接口控制器256，它们可以被配置为有助于经由一个或者多个I/O端口258和诸如输入设备(例如，键盘、鼠标、笔、语音输入设备、触摸输入设备)或者其他外设(例如打印机、扫描仪等)之类的外部设备进行通信。示例的通信设备246可以包括网络控制器260，其可以被布置为便于经由一个或者多个通信端口264与一个或者多个其他计算设备262通过网络通信链路的通信。

网络通信链路可以是通信介质的一个示例。通信介质通常可以体现为在诸如载波或者其他传输机制之类的调制数据信号中的计算机可读指令、数据结构、程序模块，并且可以包括任何信息递送介质。“调制数据信号”可以这样的信号，它的数据集中的一个或者多个或者它的改变可以在信号中编码信息的方式进行。作为非限制性的示例，通信介质可以包括诸如有线网络或者专线网络之类的有线介质，以及诸如声音、射频(RF)、微波、红外(IR)或者其它无线介质在内的各种无线介质。这里使用的术语计算机可读介质可以包括存储介质和通信介质二者。

在根据本发明的计算设备200中，计算设备200的应用222中包括执行业务服务实现方法300的多条程序指令，这些程序指令可以指示处理器204执行本发明的业务服务实现方法300，以便计算设备200通过执行本发明的业务服务实现方法300，来实现对多种业务服务进行统一配置和管理。

图3示出了根据本发明一个实施例的业务服务实现方法300的流程示意图。方法300适于在管理平台110(例如前述计算设备200)中执行。

如图3所示，方法300始于步骤310。

首先，在步骤310中，管理平台110根据业务线的业务名称和描述信息来生成业务线类型。

需要说明的是，在执行步骤310之前，可以创建一个或多个业务线，对于每个业务线，通过向管理平台110输入各业务线的业务名称和描述信息，随后，管理平台110可以根据各业务线的业务名称和描述信息来生成对应的业务线类型。这里，每个业务线可以对应一种应用场景。

之后，开发人员可以在管理平台110选择业务线类型，并为该业务线类型的业务线配置业务配置信息。

随后，在步骤320中，管理平台110可以根据业务线类型(开发人员选择的业务线类型)，来为业务线配置生成对应的业务配置信息，并存储该业务配置信息。这里，业务配置信息可以包括业务请求路径、验证预设值。另外，在其他实施例中，业务配置信息还可以包括数据源接口、限流阈值等。

接着，在步骤330中，根据业务配置信息(包含业务线对应的数据源接口、业务请求路径、验证预设值、限流阈值)，来构建与业务线相对应的业务脚本，并生成对应的版本号。这里，版本号与业务配置信息、业务脚本相对应。也就是说，这里构建的是与版本号相对应的版本的业务脚本。

需要指出的是，业务配置信息中包含业务请求路径，这样，可以建立业务请求路径与业务脚本的关联关系。

应当理解，业务脚本中包含业务服务逻辑数据，以便基于业务脚本来提供业务服务。

在一个实施例中，管理平台110包括可视化的配置页面，开发人员可以在可视化的配置页面进行可视化配置，为业务线配置对应的业务配置信息，以及，格局业务配置信息编写业务脚本。这样，可以简化对业务服务的配置和发布操作。

最后，在步骤340中，将上述业务脚本推送至测试服务端121进行验证。具体地，通过在管理平台110选择上述业务配置信息，管理平台110可以根据选择的业务配置信息，来将对应生成的业务脚本推送至服务系统120的测试服务端121进行验证。

具体地，测试服务端121可以对业务脚本进行验证。并且，测试服务端121在对业务脚本验证成功后，可以将业务脚本推送至线上服务端122进行上线，这样，可以根据上线的业务脚本对外(例如向多个客户端)提供业务服务。可以理解，业务服务即是与业务线相对应的业务服务。

这里，需要说明的是，根据与当前版本号相对应的当前版本的业务脚本，在上线后可以替换先前版本的业务脚本，以实现对业务服务逻辑进行更新。

根据本发明的业务服务实现方法300，可以针对多个业务线生成对应的多个业务脚本，并可以对多个业务脚本进行验证及上线。服务系统120可以根据已上线的多个业务脚本可以对外提供多种业务服务(对应多个业务线)。

另外，在本发明的实施例中，根据上述建立的业务请求路径与业务脚本的关联关系，服务系统120可根据业务请求路径路由到对应的业务服务。

根据本发明的一个实施例，步骤340中将业务脚本推送至测试服务端121进行验证，具体可以包括如下步骤：管理平台110将业务脚本推送至测试服务端121，并向测试服务端121发送对业务脚本的验证请求，随后，可以接收测试服务端121返回的验证结果。

进而，管理平台110可以将测试服务端121返回的验证结果与业务配置信息中的验证预设值(预期结果)进行比对，如果验证结果与验证预设值的比对结果一致，则确定测试服务端121返回的验证结果为验证成功；如果验证结果与验证预设值的比对结果不一致，则确定测试服务端121返回的验证结果为验证失败。

根据本发明的一个实施例，测试服务端121在对业务脚本进行验证时，具体可以根据业务脚本生成待验证摘要值，并将待验证摘要值与测试服务端121中存储的预期摘要值(也即，正确摘要值)进行比对。如果待验证摘要值与测试预期摘要值的比对结果一致，则测试服务端121对业务脚本验证成功。如果待验证摘要值与测试预期摘要值的比对结果不一致，则测试服务端121对业务脚本验证失败。之后，测试服务端121可以将验证结果(验证成功或失败)返回至管理平台110。

在一种实现方式中，上述摘要值(待验证摘要值/预期摘要值)具体可以为MD5值。

另外，在一个实施例中，测试服务端121在对业务脚本进行验证时，还可以对业务脚本的版本号进行验证。

测试服务端121在对业务脚本验证成功的情况下，可以继续将业务脚本推送至线上服务端122，以便线上服务端122对验证通过的业务脚本进行上线。这样，服务系统120可以根据上线的业务脚本对外(例如向多个客户端)提供业务服务。

例如，在一个实施例中，各客户端可以基于业务请求路径来向服务系统120请求对应的业务服务。服务系统120在接收到客户端的业务服务请求后，可以基于请求中的业务请求路径路由到对应的业务服务，以向客户端提供业务服务。

根据本发明的一个实施例，在步骤340中，在将业务脚本推送至线上服务端122进行上线后，还可以将已上线的业务脚本加入定时校验任务，这样，基于定时校验任务可以定时自动地对已上线的业务脚本进行验证(可以验证业务脚本的摘要值和/或版本号)。

根据本发明的一个实施例，对于需要自动上下线的业务脚本，通过在管理平台110选择该业务脚本对应的目标版本号(或者对应的业务配置信息)，管理平台110可以根据选择的目标版本号(或者对应的业务配置信息)来为对应的业务脚本生成定时任务。接下来，管理平台110可以根据该定时任务，来定时将目标版本号对应的业务脚本推送至测试服务端121进行验证，并在验证成功后，自动对目标版本号对应的业务脚本进行上线(即，将目标版本号对应的业务脚本推送至线上服务端122进行上线)。这样，能实现在无人值守情况下自动对业务脚本进行上线。

另外，在管理平台110定时将目标版本号对应的业务脚本推送至测试服务端121进行验证之后，如果测试服务端121对该业务脚本验证失败，则管理平台110可以触发报警。

需要说明的是，这里可以采用上述实施例中的方法来(定时)将目标版本号对应的业务脚本推送至测试服务端121进行验证。即：管理平台110可以定时将业务脚本推送至测试服务端121，并向测试服务端121发送对业务脚本的验证请求，随后，可以接收测试服务端121返回的验证结果。进而，管理平台110可以将测试服务端121返回的验证结果与业务配置信息中的验证预设值(预期结果)进行比对，如果验证结果与验证预设值的比对结果一致，则确定测试服务端121返回的验证结果为验证成功；如果验证结果与验证预设值的比对结果不一致，则确定测试服务端121返回的验证结果为验证失败。

在一个实施例中，还可以根据上述定时任务，来定时对目标版本号对应的业务脚本进行下线。具体地，管理平台110可以根据定时任务，定时向服务系统120的线上服务器请求对目标版本号对应的业务脚本进行下线处理，以便定时对对目标版本号对应的业务脚本进行下线。这样，能实现在无人值守情况下自动对业务脚本进行下线。

需要说明的是，在一些实施例中，在生成定时任务时可以为目标版本号对应的业务脚本设置上线时间、下线时间、告警接收人。这样，可以根据上线时间/下线时间来定时对业务脚本进行上线/下线，在对业务脚本验证失败而触发报警时，可以向告警接收人所在客户端发送报警信息。

可见，根据本发明的技术方案，通过生成定时任务能实现在无人值守情况下自动对相应版本的业务脚本进行上下线以及报警处理。

根据本发明的业务服务实现方法及系统，可以根据业务线的业务名称和描述信息，生成业务线类型，根据业务线类型来为业务线配置生成对应的业务配置信息(包括业务请求路径、验证预设值)并存储。并且，可以根据业务配置信息构建业务脚本，生成对应的版本号。进而，可以将业务脚本推送至服务系统的测试服务端进行验证，测试服务端在验证成功后，可以将业务脚本推送至线上服务端进行上线，这样，服务系统可以根据上线的业务脚本对外提供业务服务。可见，根据本发明的技术方案，能实现一站式配置并编写业务脚本，在对业务脚本进行上线后可以对外提供业务服务，以便将业务服务从核心业务系统中分离出来，保证核心业务系统的稳定性。并且，在进行上线之前还对业务脚本进行自动验证，这样有效保证了业务服务逻辑的正确性，避免因配置错误而导致业务服务无法正常运行。进一步地，各业务服务逻辑可以统一在管理平台进行可视化配置，这样无需直接修改和操作服务系统，从而简化了对业务服务的配置和发布操作。

此外，本发明根据目标版本号对相应版本的业务脚本生成定时任务，能实现在无人值守情况下自动对相应版本的业务脚本进行上下线以及报警处理。这样，有利于同时控制多个业务线，统一管理和维护多种业务服务，且无需开发人员干预即可满足服务性能要求，降低了开发人员工作量。

这里描述的各种技术可结合硬件或软件，或者它们的组合一起实现。从而，本发明的方法和设备，或者本发明的方法和设备的某些方面或部分可采取嵌入有形媒介，例如可移动硬盘、U盘、软盘、CD-ROM或者其它任意机器可读的存储介质中的程序代码(即指令)的形式，其中当程序被载入诸如计算机之类的机器，并被所述机器执行时，所述机器变成实践本发明的设备。

在程序代码在可编程计算机上执行的情况下，移动终端一般包括处理器、处理器可读的存储介质(包括易失性和非易失性存储器和/或存储元件)，至少一个输入装置，和至少一个输出装置。其中，存储器被配置用于存储程序代码；处理器被配置用于根据该存储器中存储的所述程序代码中的指令，执行本发明的业务服务实现方法。

以示例而非限制的方式，可读介质包括可读存储介质和通信介质。可读存储介质存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息。通信介质一般以诸如载波或其它传输机制等已调制数据信号来体现计算机可读指令、数据结构、程序模块或其它数据，并且包括任何信息传递介质。以上的任一种的组合也包括在可读介质的范围之内。

在此处所提供的说明书中，算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与本发明的示例一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下被实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。

本领域那些技术人员应当理解在本文所公开的示例中的设备的模块或单元或组件可以布置在如该实施例中所描述的设备中，或者可替换地可以定位在与该示例中的设备不同的一个或多个设备中。前述示例中的模块可以组合为一个模块或者此外可以分成多个子模块。

除非另行规定，使用序数词“第一”、“第二”、“第三”等等来描述普通对象仅仅表示涉及类似对象的不同实例，并且并不意图暗示这样被描述的对象必须具有时间上、空间上、排序方面或者以任意其它方式的给定顺序。