CN105357239B

CN105357239B - 提供服务的方法和装置、获取服务的方法及装置

Info

Publication number: CN105357239B
Application number: CN201410411906.2A
Authority: CN
Inventors: 金小艇; 王伟
Original assignee: Hangzhou H3C Technologies Co Ltd
Current assignee: Hangzhou H3C Technologies Co Ltd
Priority date: 2014-08-20
Filing date: 2014-08-20
Publication date: 2020-05-12
Anticipated expiration: 2034-08-20
Also published as: WO2016026436A1; CN105357239A; US10491706B2; US20170272538A1

Abstract

本申请提供一种提供服务的方法，应用于服务器上，包括：接收终端的服务请求报文；如果所述服务请求报文中未携带排队信息，为终端分配排队信息，记录排队信息与报文源地址的对应关系，将排队信息发送给所述终端；如果所述服务请求报文中携带有排队信息，验证排队信息与报文源地址的对应关系；若所述终端通过验证，根据排队信息确定所述终端的服务优先级。通过本申请的技术方案，减轻了服务器的负担，提高了服务器的处理速度。

Description

提供服务的方法和装置、获取服务的方法及装置

技术领域

本申请涉及网络通信技术领域，尤其涉及一种提供服务的方法和装置，和一种获取服务的方法和装置。

背景技术

云计算的出现对信息产业的发展产生了革命性的影响。云计算利用互联网的高速传输能力，将数据的处理过程从个人计算机或私有的服务器转移到大型的云计算中心，并将计算能力、存储能力以服务的方式为用户提供，用户能够像使用电力、自来水等公用设施一样购买和使用计算能力。

企业或个人客户通常会按照常规的需求来购买云服务。但事实上，在某一些特定时点，可能发生并发访问资源连接过多的状况，这种时候非常容易出现不能访问资源和不能提供服务的情况。比如，学校刚开学时候的自助选课系统，常常发生瘫痪；每年春运期间12306提供的订票服务，经常打不开或者订不上。面对这种情况，需要提供更好的应对方式。

发明内容

有鉴于此，本公开提供一种提供服务的方法，应用于服务器上，包括：

接收终端的服务请求报文；

如果所述服务请求报文中未携带排队信息，为终端分配排队信息，记录排队信息与报文源地址的对应关系，将排队信息发送给所述终端；

如果所述服务请求报文中携带有排队信息，验证排队信息与报文源地址的对应关系；若所述终端通过验证，根据排队信息确定所述终端的服务优先级。

本公开提供的一种获取服务的方法，应用在终端上，包括：

如果本地保存有服务器发送的排队信息，生成携带排队信息的服务请求报文；

向所述服务器发送所述携带排队信息的服务请求报文，以使所述服务器根据所述排队信息进行验证并确定服务优先级。

本公开还提供了一种提供服务的装置，应用于服务器上，包括：

请求报文接收单元，用于接收终端的服务请求报文；

排队信息生成单元，用于在所述服务请求报文中未携带排队信息时，为终端分配排队信息，记录排队信息与报文源地址的对应关系，将排队信息发送给所述终端；

排队信息处理单元，用于在所述服务请求报文中携带有排队信息时，验证排队信息与报文源地址的对应关系；若所述终端通过验证，根据排队信息确定所述终端的服务优先级。

本公开提供的一种获取服务的装置，应用在终端上，包括：

请求报文生成单元，用于在本地保存有服务器发送的排队信息时，生成携带排队信息的服务请求报文；

请求报文发送单元，用于向所述服务器发送所述携带排队信息的服务请求报文，以使所述服务器根据所述排队信息进行验证并确定服务优先级。

由以上技术方案可见，本公开的实施例通过为等待服务的终端反馈排队序号，并根据排队序号确定该终端后续服务请求的服务优先级，避免了因终端得不到服务而不断请求给服务器增加的任务，减轻了服务器的负担，提高了服务器的处理速度。

附图说明

图1是一个例子中云服务的组网结构示意图；

图2是一个例子中服务器或终端所在物理设备的硬件架构示意图；

图3是一个例子中服务器上提供服务的方法的流程图；

图4是一个例子中终端获取服务的方法的流程图；

图5是一个例子中终端与服务器的处理和交互流程示意图；

图6是一个例子中一种提供服务的装置的逻辑结构图；

图7是一个例子中一种获取服务的装置的逻辑结构图。

具体实施方式

云服务能够像水电一样的方便使用，使得各行各业的互联网化成本极大的降低。租用云服务的企业或个人日渐增多，通过云服务把线下的业务搬迁到线上进行，这些企业或个人不必配备花费庞大的基础设备，就可享受专业的服务；还可根据业务发展的规模、需求，调配所需的服务组合；当有新技术出现时，也不必为升级硬件的费用和技术而烦恼。

一种云服务的可能方式是，租用云服务的企业或个人在云服务提供商的云端网络中搭建一个服务器，这个服务器可以是租用的一台物理服务器或由两台以上物理服务器组成的集群，也可以是运行在云端网络的一台到多台物理服务器上的虚拟服务器。最终用户在终端(包括手机、个人电脑、平板电脑等用户端设备)上通过网络向云端的服务器请求服务，云端的服务器对终端的请求进行响应，为终端提供服务。

例如，在图1所示的网络中，企业在云端搭建了一个虚拟的IIS(InternetInformation Services，互联网信息服务)服务器120，一个用户在电脑终端111上用浏览器、另一个用户在手机终端112上用App(应用程序)，通过网络以web(网页)方式访问IIS服务器120提供的服务，如提交浏览请求或者提交订单，IIS服务器120依据终端的请求提供对应的服务，如返回终端访问的网页或者处理终端的订单。

云端服务器的处理能力通常根据企业或个人支付的租金来决定。现有技术中，如果发生有过多的终端同时访问服务器，导致并发访问资源连接过多的情况，通常的处理方式是拒绝服务。例如，企业购买了同时支持10000个用户在线的云端服务资源，当并发访问的终端数量达到10000时，云端服务器会直接拒绝为后续请求访问的终端提供服务。被拒绝服务的终端通常会不断的再次申请服务，拒绝这些超量访问会消耗云端服务器的处理资源，直接影响对前10000个终端的处理效率。这样在并发连接过多时，容易陷入恶性循环，请求访问的终端数量越多，处理速度越慢。

在本公开的一个例子中，运行在云端服务器上的服务控制逻辑与运行在终端的服务控制逻辑能够在并发访问资源连接较多时，提高服务器的处理效率。请参考图2，服务器所在的物理设备20可以包括处理器211、内存212、非易失性存储器213以及网络接口214，这些硬件通过内部总线215相互连接。在这个例子中，处理器211将服务器的服务控制逻辑从非易失性存储器213中读取到内存212中运行，其运行流程如图3所示。

在这个例子中，终端所在的物理设备同样可以具有如图2所示硬件结构，由处理器211将终端的服务控制逻辑从非易失性存储器213中读取到内存212中运行，其运行流程如图4所示。

请参考图3和图4，在终端上，步骤410，如果本地保存有服务器发送的排队信息，生成携带排队信息的服务请求报文。

终端在向服务器请求服务前，生成服务请求报文。终端先在本地查找，是否保存有从该服务器接收的排队信息，如果有，则将保存的排队信息按照预定格式封装到发送给该服务器的服务请求报文中；如果没有，则生成常规的，不带有排队信息的服务器请求报文。无论是否带有排队信息，服务请求报文中都带有终端的地址，如IP地址，以便在网络中正常传输。

在一个例子中，终端本地保存的排队信息包括服务器发送的排队序号，生成的服务请求报文中带有排队序号；在另一个例子中，终端本地保存的排队信息包括服务器发送的排队序号和对应于排队序号的排队密码，则在生成的服务请求报文中携带排队序号和对应的排队密码。

根据服务器和终端之间采用的具体协议和服务类型，服务请求报文可以具有各种不同的格式和内容，本例中对此不作限定。

在终端上，步骤420，向服务器发送携带排队信息的服务请求报文，以使服务器根据其中的排队信息进行验证并确定服务优先级

在服务器上，步骤310，接收终端的服务请求报文。

在服务器上，步骤320，如果来自终端的服务请求报文中未携带排队信息，为终端分配排队信息，记录排队信息与报文源地址的对应关系，将排队信息发送给该终端。

如果终端发送的服务请求报文中没有排队信息，则服务器认为这是该终端首次发起的服务请求，为该终端分配排队信息，把分配的排序信息发送给该终端。为了在终端之后发起的服务请求中正确识别该终端，在服务器上记录排队信息和服务请求报文源地址(如IP地址)的对应关系。

在一个例子中，服务器为终端分配的排队信息包括排队序号。一般而言，在服务器上为相同的源地址只分配一个排队序号，以便为各个终端提供公平的排队环境。也可以为同一个源地址分配超过一个排队序号。

服务器可以按照发起请求的顺序为所有的终端从小到大依次分配排队序号；也可以按照终端的用户级别、请求服务的类型等来划分不同的队列，在对应的队列里为终端分配排队序号。

在一个例子中，服务器可以在系统使用率超过设定阈值后启动排队机制，在排队机制启动后，才为终端分配排队序号并发送给终端，记录排队序号与请求报文源地址的对应关系，同时在提供服务时根据排队序号确定终端的服务次序。如果服务器的未超过设定阈值，则不进行排队序号的分配，直接为终端提供服务。可以根据具体应用场景选择不同的参数来作为系统使用率的衡量指标，并设置相适应的阈值；例如，采用SPEC web(一种测算web服务器处理能力的标准)系列中的极限请求数量作为系统处理能力的最大值来计算系统使用率，或采用TPC(Transaction Processing Performance Council，事务处理性能委员会)-C中的单位时间处理的事务量作为系统处理能力的最大值来计算系统使用率，或者采用所购买的服务用户数量作为系统处理能力的最大值来计算系统使用率，等等。

在另一个例子中，为了进一步增加安全性，可以为排队序号配置对应的排队密码，服务器为终端分配的排队信息包括排队序号和对应的排队密码。具体而言，如果终端发送的服务请求报文中不带有排队信息，则为终端分配排队序号，生成排队密码，该排队密码对应于排队序号和服务请求报文的源地址。在这个例子中，服务器记录排队序号、排队密码和服务请求报文的源地址的对应关系，并且将排队序号和对应的排队密码发送给终端，这样终端在下次发起服务请求时，会在服务请求报文中携带排队序号和排队密码。服务器可以采用各种方式生成排队密码，例如，在服务器上预置若干个排队密码轮流使用；再如，在服务器上根据预定的加密算法，以排队序号和/或服务请求报文的源地址为参数来生成排队密码。

服务器可以根据自身的处理速度和终端排队序号预估能够处理终端的服务请求的时间，在将排队序号发送给终端时，将可能需要等待的时间也一并发送给终端。

对终端的服务请求报文，服务器可以按照现有的模式进行处理，将其放入等待处理的任务队列中。

在终端上，如果收到服务器发送的排队信息，将其保存在本地。

当终端发送的服务请求报文中不带有排队信息时，服务器可能返回排队信息给终端。如果终端收到服务器发送的排队信息，则将排队信息保存在本地，这样在下一次生成服务请求报文时将会携带该排队信息。

排队信息可以包括排队序号，也可以包括排队序号和排队密码。

终端可以将排队序号显示给用户。如果服务器返回的报文中还带有服务器预估的等待时间，可以与排队序号一起显示给用户；终端还可以自动按照预估的等待时间来再次发起服务请求。

在服务器上，步骤330，如果来自终端的服务请求报文中携带有排队信息，验证排队信息与报文源地址的对应关系；若终端通过验证，根据排队信息确定该终端的服务优先级。

对带有排队信息的服务请求报文，服务器提取报文中的排队信息和报文的源地址，对比记录的排队信息和源地址的对应关系，来对发送该服务请求报文的终端进行验证。如果报文的排队信息和源地址与记录相符，终端通过验证，则根据排队信息来确定为该终端提供服务的优先级。

如果终端未能通过验证，服务器可以拒绝服务，也可以将其作为首次发起服务请求的终端来对待，重新为其分配排队信息，记录排队信息与该服务请求报文源地址的对应关系，并将排队信息发送给该终端。

在一个例子中，终端发送的服务请求报文中携带有排队序号。按照服务器分配排队序号的方式，服务器上可能有一个到多个任务队列来存放等待处理的服务请求。服务器按照排队序号将终端的服务请求放入所匹配的任务队列的对应位置，以便按照分配排队序号时的优先次序为终端提供服务。对有多个任务队列的情形，如何在多个任务队列之间进行调度可以按照任意的方式进行，本例中不做限定。

在另一个例子中，终端发送的服务请求报文中携带有排队序号、和与排队序号对应的排队密码。此时，服务器要对服务请求报文中的源地址、排队序号、排队密码三者，与记录的源地址、排队序号和排队密码的对应关系进行比对，如果三者均相符，终端才通过验证。

可以利用生存时间来为排队信息增加时效性。例如，可以在服务器上为记录的排队信息设置生存时间，当生存时间到时，删除记录中排队信息和服务请求报文源地址的对应关系。这样，当携带超过生存时间的排队信息的服务请求报文到达服务器时，将无法通过验证，此时服务器可以为其重新分配排队信息。再如，可以终端上为保存的排队信息设置生存时间，或者由服务器在发送排队信息时指定其生存时间；当生存时间到时，终端删除本地保存的排队信息。这样，在超过排队信息的生存时间后，终端将发送不带有排队信息的服务请求报文，而重新从服务器获得排队信息。在服务器上和终端上都为排队信息设置生存时间，也可以达到同样的效果，不再赘述。在排队信息具有生存时间的情形下，服务器在向终端发送排队信息时，可以告知用户在生存时间到期前重新发起服务请求，以避免重新排队。

在服务器下发排队信息后，终端可以得知服务器上的任务处理情况，避免了不停的发起服务请求，减少了服务器需要处理的任务，提高了服务器的响应速度。

在本公开的另一个例子中，图1所示的网络中，终端111和112以web方式访问IIS服务器120提供的服务。服务器120上预置有用来加密排队序号的保密密钥：Key1。终端111与服务器120之间的交互流程如图5所示。

1)服务器120对自身的系统使用率进行监控，如果系统使用率未达到90％，则直接响应终端的服务请求，为终端提供对应的服务。

2)服务器120监测到系统使用率达到90％，启动排队机制。

3)终端111通过浏览器访问服务器120提供的服务，向服务器120发送服务请求报文。这是终端111首次访问服务器120，因此终端111本地并未保存排队信息，其发送的服务请求报文中不带有排队信息。

4)服务器120收到终端111的服务请求报文，将终端111的服务请求放入本地的任务队列等待处理。服务器120提取报文中的IP地址，为该终端分配唯一的带有生存时间的排队序号。服务器120根据服务请求报文到达服务器的先后顺序从小到大分配排队序号，每个IP地址只分配一个排队序号。

例如，服务器120为终端111分配的排队序号为30，为随后到达的终端112分配的排队序号为31。

5)服务器120以排队序号30和Key1为参数，运行加密算法得到对应于排队序号的唯一的排队密码Code-111。

6)服务器120保存终端111的IP地址IP-111、排队序号30和排队密码Code-111的对应关系。

7)服务器120将带有生存时间的排队序号30、排队密码Code-111、预估的等待时间返回给终端111。

8)终端111将服务器120发送的排队序号30和排队密码Code-111保存在本地，如保存在cookie中。终端111向用户显示排队序号30、预估等待时间，提示用户其请求的服务正在等待处理中。

9)终端111在经过预估等待时间之后再次请求服务，由于本地保存了排队信息，生成服务请求报文时，在报文中封装排队序号30和排队密码Code-111。

10)终端111将带有排队序号30和排队密码Code-111的服务请求报文发送给服务器120。

11)服务器120从收到的服务请求报文中提取源IP地址、排队序号30和排队密码Code-111，在保存的对应关系中查找匹配的记录以对终端111进行验证。服务器120找到了相同的记录，终端111通过验证。

12)服务器120将终端111的服务请求放入任务队列中与排队序号30对应的位置，以实现排队的顺序处理目的。

13)终端111上排队序号30的生存时间到，终端111删除本地保存的排队序号30和排队密码Code-111的对应关系。

14)服务器120上排队序号30的生存时间到，服务器120删除本地保存的IP地址IP-111、排队序号30和排队密码Code-111的对应关系。

15)服务器120监测到系统使用率降到90％以下，在任务队列清空后退出排队机制。退出排队机制后，服务器120不再为请求服务的终端分配排队信息。

在这个例子中，服务器给终端的IP地址分配一个唯一的排队序号以及对应的排队密码，并且将预估等待时间告知用户，这样终端不会经常刷新服务请求，减轻了服务器负担，保证了对已经连接到服务器的终端的响应速度；另外，用户得到服务在排队中的反馈信息，可以对服务时间有一个心理预期，从而提升了用户体验。

与上述流程实现对应，本公开还提供了一种应用在服务器上的提供服务的装置和一种应用在终端上的获取服务的装置，这两种装置可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，可以通过图2中的处理器211将服务控制逻辑读取到内存212中运行而形成。

图6所示为本公开一个例子中的一种提供服务的装置，应用于服务器上，包括请求报文接收单元610、排队信息生成单元620和排队信息处理单元630，其中：

请求报文接收单元610用于接收终端的服务请求报文；

排队信息生成单元620用于在所述服务请求报文中未携带排队信息时，为终端分配排队信息，记录排队信息与报文源地址的对应关系，将排队信息发送给所述终端；

排队信息处理单元630用于在所述服务请求报文中携带有排队信息时，验证排队信息与报文源地址的对应关系；若所述终端通过验证，根据排队信息确定所述终端的服务优先级。

一个例子中，所述排队信息生成620单元包括：排队机制运行模块，用于在服务器的系统使用率超过设定阈值，并且所述服务请求报文中未携带排队信息时，为终端分配排队信息。

所述装置还可以包括验证失败处理单元，用于在所述终端未通过验证时，为所述终端重新分配排队信息，记录排队信息与报文源地址的对应关系，将排队信息发送至所述终端。

一个例子中，所述排队信息具有生存时间；这个例子中所述装置还包括：生存时间处理单元，用于当排队信息生存时间到时，删除所记录的排队信息与报文源地址的对应关系。

所述排队信息包括：排队序号；或者，所述排队信息包括：排队序号和排队密码。

图7所示为本公开一个例子中的一种获取服务的装置，应用在终端上，包括请求报文生成单元710和请求报文发送单元720，其中：

请求报文生成单元710用于在本地保存有服务器发送的排队信息时，生成携带排队信息的服务请求报文；

请求报文发送单元720用于向所述服务器发送所述携带排队信息的服务请求报文，以使所述服务器根据所述排队信息进行验证并确定服务优先级。

一个例子中，所述排队信息具有生存时间；这个例子中所述装置还包括：生存时间处理单元，用于当排队信息生存时间到时，删除所保存的排队序号。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims

1.一种提供服务的方法，应用于服务器上，其特征在于，所述方法包括：

接收终端的服务请求报文；

2.根据权利要求1所述的方法，其特征在于，所述为终端分配排队序号，包括：如果服务器的系统使用率超过设定阈值，并且所述服务请求报文中未携带排队信息，为终端分配排队信息。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：若所述终端未通过验证，为所述终端重新分配排队信息，记录排队信息与报文源地址的对应关系，将排队信息发送至所述终端。

4.根据权利要求1所述的方法，其特征在于，所述排队信息具有生存时间；

所述方法还包括：当排队信息生存时间到时，删除所记录的排队信息与报文源地址的对应关系。

5.根据权利要求1至4任一所述的方法，其特征在于，所述排队信息包括：排队序号；或者，所述排队信息包括：排队序号和排队密码。

6.一种获取服务的方法，应用在终端上，其特征在于，所述方法包括：

向所述服务器发送所述携带排队信息的服务请求报文，以使所述服务器根据所述排队信息进行验证并确定服务优先级；

其中，如果本地未保存有服务器发送的排队信息，生成不带有排队信息的服务请求报文；向所述服务器发送所述不带有排队信息的服务请求报文，以使所述服务器确定服务请求报文中未携带排队信息时，为终端分配排队信息，记录排队信息与报文源地址的对应关系，将排队信息发送给所述终端。

7.根据权利要求6所述的方法，其特征在于：所述排队信息具有生存时间；

所述方法还包括：当排队信息生存时间到时，删除所保存的排队序号。

8.根据权利要求6或7所述的方法，其特征在于，所述排队信息包括：排队序号；或者，所述排队信息包括：排队序号和排队密码。

9.一种提供服务的装置，应用于服务器上，其特征在于，所述装置包括：

请求报文接收单元，用于接收终端的服务请求报文；

10.根据权利要求9所述的装置，其特征在于，所述排队信息生成单元包括：排队机制运行模块，用于在服务器的系统使用率超过设定阈值，并且所述服务请求报文中未携带排队信息时，为终端分配排队信息。

11.根据权利要求9所述的装置，其特征在于，所述装置还包括验证失败处理单元，用于在所述终端未通过验证时，为所述终端重新分配排队信息，记录排队信息与报文源地址的对应关系，将排队信息发送至所述终端。

12.根据权利要求9所述的装置，其特征在于，所述排队信息具有生存时间；

所述装置还包括：生存时间处理单元，用于当排队信息生存时间到时，删除所记录的排队信息与报文源地址的对应关系。

13.根据权利要求9至12任一所述的装置，其特征在于，所述排队信息包括：排队序号；或者，所述排队信息包括：排队序号和排队密码。

14.一种获取服务的装置，应用在终端上，其特征在于，所述装置包括：

请求报文发送单元，用于向所述服务器发送所述携带排队信息的服务请求报文，以使所述服务器根据所述排队信息进行验证并确定服务优先级；

15.根据权利要求14所述的装置，其特征在于：所述排队信息具有生存时间；

所述装置还包括：生存时间处理单元，用于当排队信息生存时间到时，删除所保存的排队序号。

16.根据权利要求14或15所述的装置，其特征在于，所述排队信息包括：排队序号；或者，所述排队信息包括：排队序号和排队密码。