一种订单服务请求的处理系统

技术领域

本申请属于通信技术领域，尤其涉及一种订单服务请求的处理系统。

背景技术

随着计算机科学技术的快速发展，为满足用户日益增长的需求，计算机服务系统的性能也在不断优化。服务器是计算机服务系统中用于管理资源并为用户提供计算服务的设备，可响应接收到的服务请求，并对其进行处理，具有较高的数据处理能力和保障服务能力。

目前，在金融行业中，用户下单后，需要等待服务器对订单完成处理后，才可以得到下单结果。如果服务器对订单处理时间较长，用户需要等待较长时间才可以获得下单结果，整个下单过程浪费用户较长时间。

发明内容

本申请实施例提供了一种订单服务请求的处理系统，可以解决目前订单处理时间长，浪费用户时间的问题。

第一方面，本申请实施例提供了一种订单服务请求的处理系统，包括：请求处理模块和多个第一服务器；

所述第一服务器，用于接收到第一订单服务请求，在所述第一订单服务请求满足所述处理条件时，返回请求成功信息，并向所述请求处理模块发送所述第一订单服务请求，所述第一服务器还用于在所述第一订单服务请求不满足所述处理条件时，返回请求失败信息；

所述请求处理模块，用于接收所述第一服务器发送的所述第一订单服务请求，并对所述第一订单服务请求进行处理，生成所述第一订单服务请求的订单信息。

在第一方面的一种可能的实现方式中，所述向请求处理模块发送所述第一订单服务请求，包括：

获取当前时间t

判断所述当前时间t

若所述第二订单服务请求的数量小于预设值，则向所述请求处理模块发送所述第一订单服务请求。

在第一方面的一种可能的实现方式中，在所述判断所述当前时间t

若所述第二订单服务请求的数量等于所述预设值，则以预设时间间隔T重新确定当前时间t

本申请实施例与现有技术相比存在的有益效果是：本申请中第一服务器接收到第一订单服务请求后，先判断第一订单服务请求是否满足处理条件，在满足处理条件时，返回请求成功信息，并向请求处理模块发送第一订单服务请求；在第一订单服务请求不满足处理条件时，返回请求失败信息；请求处理模块用于接收第一订单服务请求，并对第一订单服务请求进行处理生成订单信息；本申请利用第一服务器对订单进行筛选，并在第一订单服务请求满足处理条件时，直接返回请求成功信息，以告知用户第一订单服务请求处理成功，并利用请求处理模块继续对第一订单服务请求进行处理，免去了用户等待订单处理的时间，户在下单后即可收到返回的订单结果，节约了用户的时间。

附图说明

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

图1是本申请一实施例提供的订单服务请求的处理系统的示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当……时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

图1示出了本申请提供的订单服务请求的处理系统的示意图，参照图1，对该系统的详述如下：

订单服务请求的处理系统包括：请求处理模块110和多个第一服务器511。

所述第一服务器511，用于接收第一订单服务请求，在所述第一订单服务请求满足所述处理条件时，返回请求成功信息，并向所述请求处理模块110发送所述第一订单服务请求，所述第一服务器511还用于在所述第一订单服务请求不满足所述处理条件时，返回请求失败信息，其中，所述处理条件用于判断是否需要对所述第一订单服务请求进行处理，所述请求成功信息用于在完成对所述第一订单服务请求处理之前向用户展示请求成功的结果，所述请求失败信息用于向所述用户展示请求失败的结果；

所述请求处理模块110，用于接收所述第一服务器511发送的所述第一订单服务请求，并对所述第一订单服务请求进行处理，生成所述第一订单服务请求的订单信息。

在本实施例中，第一服务器511可以为多个，每个第一服务器511处理一类订单，例如，服务器A可以用于处理下单订单，服务器B可以用于处理支付订单。

第一服务器511还用于对第一订单服务请求进行筛选，将满足处理条件的第一订单服务请求发送至请求处理模块110。与此同时，第一服务器511还会返回请求成功信息。用户端在接收到第一服务器511返回的请求成功信息后，会展示给用户，用户查收到之后，则会知道该订单已经被成功处理，不用再继续等待，也就是不用等到请求处理模块110将第一订单服务请求处理完成后才收到订单处理成功的消息，会在请求处理模块110将第一订单服务请求处理完成之前得到对订单的处理结果。请求成功信息可以为下单成功或OK等文字信息，还可以是动画或图片信息。

在本实施例中，请求处理模块110与各个第一服务器511相连，请求处理模块110用于对第一服务器511发送的第一订单服务请求进行处理，完成第一订单服务请求，并生成订单信息。订单信息可以包括订单号、订单完成时间等。

作为举例，如果第一订单服务请求为支付请求，则订单信息可以包括支付时间，支付编号、支付金额等。

在本实施例中，第一服务器511将不满足处理条件的第一订单服务请求进行拦截，并直接向用户端返回请求失败信息，以此告知用户该请求不符合要求，不会对该请求进行处理。第一订单服务请求可以不发送至请求处理模块110，减少了订单处理时间。请求失败信息可以为下单失败或NO等文字信息，还可以是动画或图片信息。

在本实施例中，处理条件为预先根据需要设置的、第一订单服务请求应该满足的要求，例如，下单服务请求时应该满足下单顺序、信息填写完整等；支付服务请求时应满足支付银行卡的余额充足等。

作为举例，如果第一订单服务请求为下单服务请求，第一服务器511中设置了秒杀条件为对前10个下单的请求进行响应。第一服务器511接收用户端发送的下单服务请求，对前10个下单服务请求返回下单成功的信息，并将前10个下单服务请求发送至请求处理模块110。对第11个及之后的下单服务请求返回下单失败的信息，不会对第11个及之后的下单服务请求进行处理。

具体的，第一服务器511向请求处理模块110发送第一订单服务请求包括：

S101，获取当前时间t

在本实施例中，在向请求处理模块110发送第一订单服务请求之前，先获取请求处理模块110中已经存在的订单服务请求的数量，将已经存在的订单服务请求作为第二订单服务请求。

S102，判断所述当前时间t

在本实施例中，判断当前第二订单服务请求的数量是否超过预设值，如果超过预设值则说明请求处理模块110中的订单服务请求已经达到上限，则暂时可以不向请求处理模块110发送第一订单服务请求；如果第二订单服务请求的数量没有超过预设值，则可以向请求处理模块110发送第一订单服务请求。

在本实施例中，预设值可以根据需要或请求处理模块110的性能进行设置。

S103，若所述第二订单服务请求的数量小于预设值，则向所述请求处理模块110发送所述第一订单服务请求。

S104，若所述第二订单服务请求的数量等于所述预设值，则以预设时间间隔T重新确定当前时间t

在本实施例中，如果当前时间第二订单服务请求的数量等于预设值，可以在预设时间间隔之后再次获取第二订单服务请求的数量，再次判断第二订单服务请求的数量与预设值之间的关系，直到可以将第一订单服务请求发送至请求处理模块110为止。

本申请实施例中，第一服务器511接收到第一订单服务请求后，先判断第一订单服务请求是否满足处理条件，在满足处理条件时，返回请求成功信息，并向请求处理模块110发送第一订单服务请求；在第一订单服务请求不满足处理条件时，返回请求失败信息；请求处理模块110用于接收第一订单服务请求，并对第一订单服务请求进行处理生成订单信息；本申请利用第一服务器511对订单进行筛选，并在第一订单服务请求满足处理条件时，直接返回请求成功信息，以告知用户第一订单服务请求处理成功，并利用请求处理模块110继续对第一订单服务请求进行处理，免去了用户等待订单处理的时间，可以使用户在下单后即可收到返回的订单结果，节约了用户的下单时间。

如图1所示，在一种可能的实现方式中，所述请求处理模块110包括：多个异步数据处理服务器111和多个第二服务器112；

所述异步数据处理服务器111，用于接收并存储所述第一服务器511发送的所述第一订单服务请求，并在所述第一订单服务请求的数量大于预设数量时，并向所述多个第二服务器112分发所述第一订单服务请求；

所述第二服务器112，用于对所述第一订单服务请求进行处理，并生成对应的订单信息。

在本实施例中，预设数量可以根据需要设置。

在本实施例中，异步数据处理服务器111可以通过消息队列(RabbitMQ)进行异步处理服务，在高访问量时，用户不用一直等待请求被处理成功后才返回处理结果，可以在请求发出后立即得到反馈，通过RabbitMQ存储高访问时没有处理的请求，并由后边的服务器处理RabbitMQ中的请求，实现流量削峰、异步处理、应用解耦的功能。

在本实施例中，异步数据处理服务器111可以包括多个，将第一服务器511进行分组，每组第一服务器511连接一个异步数据处理服务器111。

异步数据处理服务器111在接收到第一订单服务请求后，可以将第一订单服务请求依照队列的形式进行存储，在第二服务器112需要对第一订单服务请求进行处理时，第二服务器112可以从异步数据处理服务器111中获取第一订单服务请求。

在本实施例中，每个第二服务器112可以处理一种或多种类型的请求，异步数据处理服务器111可以根据第一订单服务请求的请求类型将第一订单服务请求发送至不同的第二服务器112。

需要说明的是，第二服务器生成的订单信息可以返回至用户端，也可以在用户端查询该订单信息时返回至用户端。

本申请实施例中，通过异步数据处理服务器111可以在高访问量时将第一订单服务请求存储起来，不用同时对大量的请求进行处理，减轻了服务器的工作量，使系统运行更顺畅。

如图1所示，在一种可能的实现方式中，所述系统还包括：

第一请求分发模块210，用于接收用户端发送的访问请求，并将所述访问请求发送至第二请求分发模块310；

第二请求分发模块310，用于接收并响应所述访问请求，所述第二请求分发模块310还用于接收所述用户端发送的所述第一订单服务请求，并基于所述第一订单服务请求的请求类型，向对应的第一服务器511发送所述第一订单服务请求，其中，每个所述第一服务器511对应处理至少一类订单服务请求。

在本实施例中，客户端可以是手机客户端、电脑客户端或平板客户端等。访问请求可以是打开某个网页或某个APP。

在本实施例中，第二请求分发模块310主要对访问请求进行分发，并接收第一订单服务请求。

如图1所示，在一种可能的实现方式中，所述第一请求分发模块210包括：鉴权授权服务器212和第一反向代理服务器211；

所述鉴权授权服务器212，用于对所述用户端进行鉴权和/或授权；

所述第一反向代理服务器211，用于在接收到多个所述用户端发送的访问请求时，调用所述鉴权授权服务器212对所述用户端进行鉴权和/或授权处理，得到目标用户端，并基于预设的第一分发策略，将所述目标用户端的访问请求分发至所述第二请求分发模块310。

在本实施例中，鉴权授权服务器212可以通过令牌验证(IdentityServer4)服务对客户端进行统一认证授权，保证数据传输的安全可靠。

第一反向代理服务器211(Nginx)在接收到访问请求时，可以对用户端进行鉴权和/或授权处理，确定可以进行访问的客户端，然后将访问请求分发至第二请求分发模块310。

如图1所示，在一种可能的实现方式中，所述第二请求分发模块310包括：第二反向代理服务器312和多个应用服务器311

所述应用服务器311，用于接收并响应所述第一反向代理服务器211发送的访问请求，并在接收到所述目标用户端发送的第一订单服务请求后，向所述第二反向代理服务器312发送所述第一订单服务请求，其中，所述第一分发策略包括向每个应用服务器311分发所述访问请求的个数的比例；

所述第二反向代理服务器312，用于确定所述第一订单服务请求的请求类型，并基于所述请求类型和第二分发策略，将所述第一订单服务请求分发至对应的第一服务器511，其中，所述第二分发策略包括每个第一服务器511对应处理的订单服务请求的类型、同类型的第一服务器511的分发数量的比值。

在本实施例中，多个应用服务器311可以搭载不同的信息，也可以搭载相同的信息。

作为举例，应用服务器A上可以搭载应用A的信息，应用服务器B上也可以搭载应用A的信息，应用服务器上还可以搭载应用B的信息。

在本实施例中，第一反向代理服务器211(Nginx)在接收到访问请求时，可以根据第一分发策略和访问请求中的待访问信息，将访问请求分发至应用服务器311中。

第一分发策略可以包括各个应用服务器311可以处理的请求的数量的比值，以及每个应用服务器311中搭载的信息。

作为举例，如果同时有3个方位请求，分别为打开应用A、应用B和应用C，应用服务器A和应用服务器B中的信息完全相同，且应用服务器A和应用服务器B可以处理的请求的数量的比较为1：2。则可以将应用A分发至应用服务器A，将应用B和应用C分发至应用服务器B。

应用服务器311在接收到访问请求后，会对访问请求做出响应，将与访问请求对应的内容返回至客户端，例如，访问请求是打开购物网站B，应用服务器在接收到打开购物网站B的访问请求后，将购物网站B的页面返回至用户端。应用服务器向用户返回信息时，可以通过第一反向代理服务器返回至用户端。

应用服务器311还可以接受用户端的第一订单服务请求，例如，用户A通过第一用户端上的W购物网站购买T物品，并对T物品进行下单，则应用服务器311则会接收到第一用户端发送的对T物品的下单服务请求。

应用服务器311在接收到第一订单服务请求后，将第一订单服务请求发送至第二反向代理服务器312。第二反向代理服务器312(Nginx)对第一订单服务请求进行分析，确定第一订单服务请求的请求类型，然后将第一订单服务请求分发至对应的第一服务器511。应用服务器311在对第一订单服务请求进行分发时，可以根据第一服务器511处理的请求的类型和第一服务器511的处理能力进行分发。

作为举例，如果第一订单服务请求包括：第一下单服务请求、第二下单服务请求、第三下单服务器请求和支付服务请求。第一服务器C用于处理下单服务器请求，第一服务器D用于处理下单服务器请求，第一服务器E用于处理支付服务器请求，且第一服务器C和第一服务器D可以处理的请求的数量的比值为2:1。第二反向代理服务器可以将第一下单服务请求和第二下单服务请求分发至第一服务器C，将第三下单服务请求分发至第一服务器D，将支付服务请求分发至第一服务器E。

本申请实施例中，通过第一反向代理服务器211将多个访问请求分发至不同的应用服务器311，可以减少应用服务器311的压力，提高工作效率。

如图1所示，在一种可能的实现方式中，所述系统还包括：

信息存储模块410，用于接收并存储所述请求处理模块110发送的所述订单信息。

具体的，信息存储模块410包括：缓存数据库411和数据库；

所述缓存数据库411，用于接收并存储所述请求处理模块110发送的所述订单信息。

数据库，用于接收并存储请求处理模块110发送的订单信息。

具体的，缓存数据库411和数据库均用于接收并存储第二服务器112发送的订单信息。

在本实施例中，设置缓存数据库411，将订单信息缓存起来，用户在查看订单信息时，可以直接从缓存数据库411中调用数据，使数据调用速度更快。缓存数据库411可以通过远程字典服务(Redis-Remote Dictionary Server)实现数据缓存。

在本实施例中，数据库可以包括主数据库和多个分数据库。数据库可以为分库分表的形式，使读写分离，提高数据库的服务能力。

如图1所示，在一种可能的实现方式中，所述系统还包括：配置管理服务器611；

所述配置管理服务器611，用于存储所述第一服务器511的配置信息；

相应的，所述第一服务器511还用于：

从所述配置管理服务器611获取对应的所述配置信息。

在本实施例中，配置管理服务器611中设置第一服务器511的配置信息，对第一服务器511的配置进行统一管理。相同功能的第一服务器511在配置管理服务器611中设置一套即可。在对第一服务器511中的配置进行更改时，可以直接在配置管理服务器611中进行修改，然后第一服务器511从配置管理服务器611中读取对应的配置信息。

配置管理服务器611可以通过服务注册和发现(Consul)工具对第一服务器511的配置信息进行统一管理。

可选的，配置管理服务器611中还可以设置不同的配置模块，各个配置模块均相同，每个配置模块中均包括所有第一服务器511的配置信息。

配置管理服务器611可以与第二反向代理服务器312相连，通过第二反向代理服务器312将第一服务器511的读取请求分发至不同的配置模块，以减少大量第一服务器511需要读取配置信息时，需要排队等候的现象。

作为举例，配置管理服务器中包括第一配置模块和第二配置模块，第一配置模块和第二配置模块完全相同。有三个第一服务器A、B、C需要读取配置信息，第二反向代理服务器可以将A和B分发至第一配置模块读取配置信息，将C分发至第二配置模块读取配置信息。

在本实施例中，配置管理模块中还可以包括第二服务器112的配置信息。第二服务器112还用于从配置管理模块读取对应的配置信息。

需要说明的是，配置管理服务器和第二反向代理服务器可以使用不同的服务器，也可以使用同一个服务器。

本申请实施例中，通过配置管理服务器611同一管理第一服务器511的配置信息，提高了对第一服务器511的配置管理效率，相比于现有技术对每个第一服务器511的配置进行修改，可以减少出错率。

如图1所示，在一种可能的实现方式中，所述系统还包括进程管理服务器711；

所述进程管理服务器711，用于对所述第一服务器511和所述第二服务器112进行应用进程的监控，并在所述第一服务器511和/或所述第二服务器112的应用进程异常时，重启出现异常的所述第一服务器511和/或第二服务器112。

在本实施例中，进程管理服务器711用于对第一服务器511和第二服务器112的应用进程进行管理。进程管理服务器711可以通过进程管理工具(Supervisord)来实现第一服务器511和第二服务器112中各个应用服务的进程管理，在某个进程发生异常时，通过Supervisord工具将该进程对应的服务器进行重启。可以保证服务器正常顺利的运行，避免人为误操作的发生。

可选的，一个第一服务器可以对应一个进程管理服务器，一个第二服务器可以对应一个进程管理服务器。

需要说明的是，进程管理服务器可以设置在第一服务器外部，也可以设置在第一服务器内部。同样的，进程管理服务器可以设置在第二服务器外部，也可以设置在第二服务器内部。进程管理服务器可以包括第一管理服务器和第二管理服务器，第一管理服务器用于对第一服务器的应用进程进行管理。第二管理服务器用于对第二服务器的应用进程进行管理。

如图1所示，在一种可能的实现方式中，所述系统还包括日志管理服务器811；

所述日志管理服务器811，用于获取并存储所述第一服务器511和所述第二服务器112中的日志。

在本实施例中，日志管理服务器811可以对第一服务器511和第二服务器112中的日志进行统一收集管理，可以通过日志管理服务器811中的日志查看第一服务器511和第二服务器112的运行参数，可以通过日志分析第一服务器511和第二服务器112是否运行正常。

日志管理服务器811可以采用开源日志收集工具(ExceptionLess)对日志进行收集和管理。

可选的，一个第一服务器可以对应一个日志管理服务器，一个第二服务器可以对应一个日志管理服务器。

需要说明的是，日志管理服务器可以设置在第一服务器外部，也可以设置在第一服务器内部。同样的，日志管理服务器可以设置在第二服务器外部，也可以设置在第二服务器内部。日志管理服务器可以包括第三管理服务器和第四管理服务器，第三管理服务器用于对第一服务器中的日志进行管理。第四管理服务器用于对第二服务器中的日志进行管理。

需要说明的是，以上系统可以无限扩展，满足不同场景的需求，满足高访问量、高安全性以及高可用性的要求。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。