CN115756539A - 一种去中心化反向服务调用方法、系统及设备 - Google Patents

Abstract

本申请涉及一种去中心化反向服务调用方法、系统及设备，包括以下步骤：广播请求信息至所有门店端，门店端用于通过信息通道筛选出对应的请求信息并对请求信息进行处理返回反馈信息；在预设的第一时间内接收所有门店端的反馈信息；提取所有在预设时间内接收反馈信息中的ID信息，并基于ID信息处理规则得出订单处理结果；将订单处理结果发送至客户端。本申请通过广播的方式向门店端发送订单以及控制指令，使得门店端能够及时对订单进行响应并根据请求信息进行版本更新，使得订单处理的效率更高；通过在一段时间内重复播放请求信息，确保门店端或其他服务端能够准确接收到请求信息，使得服务端数据的下发，较为可靠。

Description

一种去中心化反向服务调用方法、系统及设备

技术领域

本申请涉及订单配送技术领域，尤其是涉及一种去中心化反向服务调用方法、系统及设备。

背景技术

在零售连锁业务系统，经常需要通过云端来发起对于本地服务的调用，比如将本地打印机暴露成云端打印机；检查本地设备运行状态；检查应用系统版本并发送升级信息；批量获取远程门店的硬件信息；

而门店设备可能是一个PC、Pad，也可以是一个电脑盒子或其他智能设备，门店设备和服务端的连接也不是完全稳定的，同时大部分是在内网，从而将一个局域网的服务通过一个公共的公网暴露出来，我们称之为“隧道（tunnel)”技术。

但是在订单配送行业，尤其是外卖行业这种对时间要求比较高的行业，一般的方式都是通过服务端将订单或更新信息发送到门店端，等待门店端响应，受门店端的操作人员影响，门店端对订单响应时间不一，比如人员忙碌时忘记点击接订单，便会导致服务端无法推送其他订单到该门店端，导致客户的订单处理被耽误，使得客户的服务体验较差。

发明内容

为了使得客户的订单处理不易被耽误，本申请提供一种去中心化反向服务调用方法、系统及设备。

第一方面本申请提供的一种去中心化反向服务调用方法，采用如下的技术方案：

一种去中心化反向服务调用方法，包括以下步骤：

广播请求信息至所有门店端，门店端用于通过信息通道筛选出对应的请求信息并对请求信息进行处理返回反馈信息；

在预设的第一时间内接收所有门店端的反馈信息；

提取所有在预设时间内接收反馈信息中的ID信息，并基于ID信息处理规则得出订单处理结果；

将订单处理结果发送至客户端。

通过采用上述技术方案，通过广播请求信息的方式到门店端，并设置接收时间，使得对应的门店端能够快速收到广播的请求信息，无需进行排队等候，提高了通讯效率，同时设置反馈信息的接收时间，在部分门店因为其他事情耽误接单时，服务端的进程也不会因此停滞，服务端也能够推送其他订单到门店端,能够快速向客户给出订单处理结果。

优选的，其中，订单处理结果为订单成功处理结果或订单失败结果，所述ID信息处理规则包括：

识别请求信息的类型，其中，请求信息的类型包括订单型；

根据订单型的请求信息，判断是否接收到反馈信息；

若是，则得出订单成功处理结果；

若否，则得出订单失败结果。

通过采用上述技术方案，订单型的请求信息一般会对应单一的门店端，所以在服务端收到反馈信息后，说明门店端已经处理了该请求信息，则得出订单成功处理结果，反正没有收到反馈信息后，则说明门店端没有在规定时间内处理请求信息，为了避免客户等待太长时间，所以给出订单失败结果。

优选的，在广播请求信息至所有门店端前，还包括以下步骤：

接收其他服务端广播的请求信息。

通过采用上述技术方案，不同服务器之间也可以进行请求信息的传递，使用多个服务器分担订单处理需要的算力，使得处理更加高效。

优选的，在广播请求信息至所有门店端前，还包括以下步骤：

根据客户订单请求或控制指令生成请求信息。

通过采用上述技术方案，服务端能够对客户订单请求以及控制指令生成请求信息，以使门店端不仅仅能够对订单进行处理，也能够执行服务端下达的例如更新、验证之类的各种控制指令。

优选的，其中，请求信息的类型还包括指令型，所述ID信息处理规则还包括：

根据指令型的请求信息，识别指令型的请求信息中的目标指令信息；

将目标指令信息与预置的指令表对应，得出门店端ID集合；

将门店端ID集合中的门店端ID逐一与预设时间内接收的所有反馈信息中的ID信息比对，得到门店端响应结果，其中门店端响应结果包括全部响应结果或部分响应结果；

在得出部分响应结果后，记忆该请求信息并在第一时间内间隔预设间隔时间重复广播该请求信息。

通过采用上述技术方案，在执行强制更新等控制指令时，服务端会检测各个门店端的响应情况，若门店端没有全部进行响应即服务端没有接收到全部需要更新的门店端的反馈信息，那么服务端会在第一时间内重复广播该请求信息，以减少外部网络环境因素导致门店端没有接收到请求信息的偶然现象对本申请的影响，确保请求信息能够被门店端接收。

优选的，在广播请求信息至所有门店端后，还包括以下步骤：

同时广播请求信息到监控服务端，其中，监控服务端接收请求信息后提取请求信息中的目标指令信息后，检测与目标指令信息对应的门店端的状态信息是否正常，得出检测结果，根据请求信息与检测结果发送延时操作信息到服务端；

接收监控服务端发送的处理信息；

根据延时操作信息，将第一时间延长至预置的第二时间。

通过采用上述技术方案，在检测到门店端的状态信息不正常时，比如发现网络波动或者系统卡顿时，导致门店端无法第一时间接收请求信息或发出反馈信息，则通过监控服务端了解门店端的状态信息不正常后，可以延长请求信息的发送时间以及反馈信息的接收时间，以减少网络波动或者系统卡顿对本申请的去中心化反向服务调用方法的不良影响。

优选的，在广播请求信息至所有门店端后，还包括以下步骤：

接收监控服务端发出的结束操作信息，使得接收所有门店端的反馈信息的步骤结束。

通过采用上述技术方案，能够缩短不必要的处理流程，使得本申请的中心化反向服务调用方法更为高效。

优选的，在将门店端ID集合中的门店端ID逐一与预设时间内接收的所有反馈信息中的ID信息比对，得到门店端响应结果前，还包括以下步骤：

获取监控服务端发送的门店端下线信息；

根据门店端下线信息，获取下线门店端ID并从门店端ID集合中将与下线门店端ID对应的门店端ID屏蔽。

通过采用上述技术方案，能够排除离线的门店端对本申请的中心化反向服务调用方法的干扰，使得本申请的中心化反向服务调用方法更为高效。

第二方面本申请提供的一种去中心化反向服务调用系统，采用如下的技术方案：

一种去中心化反向服务调用系统，包括：

广播通讯模块，用于广播请求信息至所有门店端，门店端用于通过信息通道筛选出对应的请求信息并对请求信息进行处理返回反馈信息；

反馈接收模块，用于在预设的第一时间内接收所有门店端的反馈信息；

订单处理模块，用于提取所有在预设时间内接收反馈信息中的ID信息，并基于ID信息处理规则得出订单处理结果；以及，

信息发送模块，用于将订单处理结果发送至客户端。

第三方面本申请还提供一种电子设备，采用如下的技术方案：

一种电子设备，包括：处理器和存储器；其中，所述存储器存储有计算机程序，所述计算机程序适于由所述处理器加载并执行一种去中心化反向服务调用方法的步骤。

综上所述，本申请包括以下至少一种有益技术效果：

1.本申请通过广播的方式向门店端发送订单以及控制指令，使得门店端能够及时对订单进行响应并根据请求信息进行版本更新，使得订单处理的效率更高；

2.通过在一段时间内重复播放请求信息，确保门店端或其他服务端能够准确接收到请求信息，使得服务端数据的下发，较为可靠；

3.通过对门店端的状态信息进行监测对请求信息的广播时间进行调整，能够减少网络波动以及系统卡顿对本申请的影响。

附图说明

图1是本申请实施例的一种去中心化反向服务调用方法的流程示意图。

图2是本申请实施例的服务器之间网关通讯的整体架构示意图。

图3是本申请实施例的服务器与门店端之间通讯步骤的架构示意图。

图4是本申请实施例的一种去中心化反向服务调用系统的架构示意图。

附图标记说明：1、广播通讯模块；2、反馈接收模块；3、订单处理模块；4、信息发送模块。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。

在本申请实施例的描述中，“示性的”、“例如”或者“举例来说”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示性的”、“例如”或者“举例来说”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示性的”、“例如”或者“举例来说”等词旨在以具体方式呈现相关概念。

本申请运用于线上门店交易行业。线上购物是当今社会普遍的消费行为，一般运用于线上购物的零售连锁业务系统中门店设备和服务端的连接大部分是在内网，从而将一个局域网的服务通过一个公共的公网暴露出来，我们称之为“隧道（tunnel)”技术。此种通讯方式响应较慢，对于人员操作在及时性方面要求较高，比如需要相应的门店端及时处理确认订单以及更新等任务，否则这些未处理的任务占据的内存过多，会影响整个系统运行的顺畅度，导致系统不稳定且依赖人员操作也容易影响客户订单处理的及时性。

所以为了提高系统运行的顺畅度以及使得客户订单能够被及时处理,本申请实施例公开一种去中心化反向服务调用方法。

参照图1和图2，一种去中心化反向服务调用方法，包括以下步骤：

S0：根据客户订单请求或控制指令生成请求信息；

具体的：客户利用智能机通过互联网访问服务端上的APP发起订单请求以进行下单，在其他实施例中，具体的下单的方式也可以通过gRPC或者HTTP的方式访问服务端等方式进行，具体手段在此不做限定，符合实际需求即可；客户下单后，服务端接收到客户订单请求，服务端根据客户的订单请求生成请求信息，根据客户的订单请求生成请求信息是现有网购APP软件采用的常规技术，在此不做赘述；另外，请求信息也可以是服务端的操作人员通过操作服务端发出的控制指令；

S1：广播请求信息至所有门店端，门店端用于通过信息通道筛选出对应的请求信息并对请求信息进行处理返回反馈信息；

具体的：参照图2和图3，在服务端生成请求信息后，在本实施例中服务端采用计算机，服务端调用Req/Resp模块根据请求信息构造请求包，并将请求包转发给GatewayCore模块，GatewayCore模块将请求包发送到GatewayConn模块，服务端获取门店端的连接信号信息，并确定请求信息的类型，请求信息的类型可以通过识别标识字符串进行区分，连接信号信息可以是Channel或IdentityID，为方便说明本实施例将连接信号信息定为Channel，其中，请求信息的类型包括指令型以及订单型；

若请求信息为订单型，则说明此请求信息为客户的订单请求，若请求信息为指令型，则说明此请求信息为人员通过操作服务端发出的控制指令，控制指令包括对于门店端的更新等操作指令信息；判断请求信息对应的连接信号信息即Channel是否存在，若存在则说明客户请求信息对应的门店端在线，则服务端通过数据传输通道Transport将请求包的数据广播到所有门店端，其中指令型的请求信息可以对应多个连接信号信息，其中门店端可以是计算机，也可以是手机或者其他智能设备；

另外需要说明的是与服务端连接并接收广播出的请求信息的设备也不局限于门店端也可以是其他的服务端，在与服务端连接的设备是其他的服务端时，服务端之间的请求信息通过ServiceBroker来实现转发，其他的服务端与门店端会同时对请求信息进行响应，将请求信息通过上述方式广播到自身对应的门店端中。

在门店端接收到请求信息后，会根据请求信息进行相应的操作，比如若是请求信息是订单类的请求信息，那么门店端在屏幕上进行弹窗展示，人员通过点击弹窗的选择项，选择接受订单或者拒绝订单，之后门店端会根据人员的选择发送订单处理信息到服务端中，具体门店端到服务端的信息传递过程如下：

人员通过点击弹窗选择接受订单或者拒绝订单后，门店端对于人员的选择做出相应的处理，生成反馈信息，并通过识别请求信息中地址信息，得到服务端的通讯地址，之后根据服务端的通讯地址将反馈信息发送给服务端。具体发送步骤包括：门店端返回反馈信息对应的数据包给Transport，此时数据包的类型为ACK，之后Transport将该数据包转发给服务端的GatewayCore模块，GatewayCore模块将数据包转发给Req/Resp模块，使得服务端接收门店端的应答。

再参照图1：

S2：在预设的第一时间内接收所有门店端的反馈信息；

具体的：预设的第一时间可以是服务器广播请求信息后的2-4秒，为方便说明本实施例第一时间采用3秒为例，服务器在请求信息开始广播后进入计时状态，统计服务器广播请求信息后经过的时间，在服务器广播请求信息后经过的时间超过3秒后，服务端停止接收门店端的反馈信息；

S3：提取所有在预设的第一时间内接收反馈信息中的ID信息，并基于ID信息处理规则得出订单处理结果；

具体的：在服务端停止接收门店端的反馈信息后，会对所有在预设的第一时间中接收到反馈信息进行处理，识别反馈信息中的ID信息，ID信息可以是反馈信息中特定位置的字符串，并基于ID信息处理规则对ID信息进行处理得出订单处理结果，其中，订单处理结果为订单成功处理结果或订单失败结果；

其中，ID信息处理规则具体包括：

识别请求信息的类型，其中，请求信息的类型包括订单型以及指令型；若是反馈信息对应的请求信息为订单型的请求信息，则服务端会简单判断自身是否在3秒内接收到反馈信息，若在3秒内接收到反馈信息，则说明人员已经在门店端进行操作得出订单成功处理结果，通过服务端会在接收到反馈信息的时候，立刻结束对反馈信息的接收，开始处理下一请求信息，并对已经接收到的反馈信息中的结果信息，结果信息与ID信息类同也是反馈信息中特定位置的字符串，在识别到结果信息后，服务端根据结果信息查询预置的处理结果表得出门店处理结果，出门店处理结果为接受结果或拒绝结果，并将门店处理结果作为订单成功处理结果；

若服务端在3秒内没有接收到反馈信息，则说明人员未在门店端进行操作，说明门店人员大概率因为某些原因暂时没空或忘记在门店端处理请求信息，为了不耽误客户的时间，如果在3秒结束后，服务端仍然没有接收到反馈信息，则服务端会得出订单失败结果。

此外在其他实施例中，ID信息处理规则不仅仅用来处理订单请求，也可以用做处理强制版本更新、数据下发以及状态检查等请求信息的处理，门店端在接收到指令型的请求信息后会直接对该请求信息进行处理，具体的，ID信息处理规则还包括：

根据指令型的请求信息，识别指令型的请求信息中的目标指令信息，将目标指令信息与预置的指令表对应，得出门店端ID集合，将门店端ID集合中的门店端ID逐一与预设时间内接收的所有反馈信息中的ID信息比对，得到门店端响应结果，其中门店端响应结果包括全部响应结果或部分响应结果；

在得出全部响应结果后，则结束该请求信息的处理，等待处理下一请求信息；

在得出部分响应结果后，记忆该请求信息并在第一时间内，即3秒内，间隔预设间隔时间重复广播该请求信息，其中预设间隔时间可以是20毫秒，也可以是30毫秒、40毫秒，此处对预设间隔时间的具体值不做限定，符合实际需求即可。

关于这一部分ID信息处理规则需要说明的是：由于指令型的请求信息通常是需要服务端连接一批或者全部的门店端进行响应的，所以在接收到指令型的请求信息后会验证门店端的反馈信息，如果不是请求信息对应的全部的门店端均进行反馈，那么得出部分响应结果，之后服务端便会在第一时间内间隔预设间隔时间重复广播请求信息，直到对应的门店端全部反馈或到第一时间结束后，进入待机状态以处理下一请求信息。

S4：将订单处理结果发送至客户端；

具体的，服务端在得到订单成功处理结果后，会依据具体的订单成功处理结果；例如接收结果，服务端会将接收结果发送到客户端告知客户订单以被门店接收，能够进行之后的交易流程；如果订单成功处理结果为拒绝结果，那么服务端会将接收结果发送到客户端告知客户订单以被门店拒绝接收，在其他实施例中，反馈信息还包括有拒绝原因信息，服务端可以根据拒绝原因信息，使得客户能够了解门店拒绝订单的原因；此外服务端在得到订单失败结果后，服务器会直接将订单失败结果发送给客户，并可以附带文字信息告知客户因为通讯关系订单未成功被门店接收处理。

此外在其他实施例中，在保证广播通讯效率的基础上，对本申请的方法进一步作出改进，改进步骤如下：

S5：在广播请求信息至所有门店端后，同时广播请求信息到监控服务端；

其中，在本实施例中监控服务端采用计算机，监控服务端主要对服务端以及门店端之间的广播通讯做监控调节的作用，具体的：

监控服务端接收请求信息后提取请求信息中的目标指令信息后，监控服务端与所有门店端通过信道连接，监控服务端存储有所有门店端与对应服务端的Channel信息，在监控服务端接收到广播请求信息后，监控服务端会检测与目标指令信息对应的门店端的状态信息是否正常；门店端的状态信息检测可以通过门店端在与对应服务端建立连接时发送上线信息到监控服务端以及门店端在与对应服务端断开连接时发送下线信息到监控服务端，依据监控服务端最近一次接收到每个门店端的上线信息或下线信息判断对应门店端的状态信息是否正常；如果对应门店端最近一次发送到监控服务端是上线信息，那么得出门店端的状态信息处于正常结果，说明门店端处于在线状态；反之，如果对应门店端最近一次发送到监控服务端是下线信息，那么得到门店端的状态信息处于异常结果，说明门店端处于离线状态；

在本实施例中，监控服务端在门店端传感处于离线状态后，会发送门店端下线信息到服务端，门店端下线信息中具有对应的下线门店端ID，服务端从门店端下线信息中获取下线门店端ID，之后从门店端ID集合中将与下线门店端ID对应的门店端ID屏蔽，被屏蔽的门店端ID不参加与预设时间内接收的所有反馈信息中的ID信息比对的步骤，从而使得离线门店不易对订单处理结果造成影响。

此外在其他实施例中，监控服务端可以是独立服务端外的智能设备，监控服务端在得到门店端的状态信息正常结果后，监控服务端通过内置在门店端中的网络信号强度监控模块进一步检侧测门店端的通讯状态，该模块可以通过在网络质量检测评分软件以及门店端系统评分软件进行网络通讯情况的评估，用网络质量检测评分软件对门店端的网络进测评得出的网络质量检测评分，将网络质量检测评分乘以第一比重系数得到网络质量比重评分，将门店端系统评分软件得出的门店端系统评分乘以第二比重系数得到系统比重评分，将网络质量比重评分与系统比重评分相加得到通讯稳定性评分，如网络质量检测评分为80、门店端系统评分为90、第一比重系数为0.6、第二比重系数为0.4，则最后得出的通讯稳定性评分为84，之后将通讯稳定性评分与预置评分值进行比较，得到检测结果，其中检测结果为稳定结果、不稳定结果或离线结果，离线结果由目标指令信息对应的门店端的状态信息处于异常结果得出，若通讯稳定性评分低于预置评分值，为方便说明预置评分值可以设置为80，在通讯稳定性评分低于80后，则说明门店端与服务端之间的通讯不稳定则得出不稳定结果，反之则得出稳定结果，门店端根据检测结果发出相应的检测信息到监控服务端；

S6：监控服务端接收请求信息，根据请求信息与检测结果发送处理信息，处理信息包括延时操作信息以及结束操作信息；

具体的，监控服务端在接收请求信息后，会根据请求信息找出所有与请求信息对应的门店端，即会对请求信息进行响应的门店端，若是检测到有一个以上门店端的检测结果为不稳定结果，则监控服务端会发送延时操作信息到对应的服务端，若是所有与请求信息对应的门店端的检测结果为离线结果，那么监控服务端会发送结束操作信息到服务端。

S7：接收监控服务端发送的处理信息，根据延时处理信息，将第一时间延长至预设时间值；

具体的：服务端会在接收延时操作信息后，将第一时间延时到预置的第二时间，例如第一时间为3秒，第二时间为4秒，在服务端接收延时操作信息后，将第一时间延时至4秒。

S8：接收监控服务端发送的结束操作信息，根据结束操作信息，使得接收所有门店端的反馈信息的步骤结束；

具体的：监控服务端发送的结束操作信息后，说明请求信息对应的门店端离线，在实际场景中对于人员订单所属的门店端关机，为了提升系统运行效率，将接收所有门店端的反馈信息的步骤结束，作出订单失败结果，同时为提升客户体验服务端也可以发送相应的文字信息表示歉意。此处需要说明的是：步骤S5是步骤S1之后进行的步骤，并非步骤S4的下一步骤。

此外，在另一实施例中，由于监控服务端内存储有所有服务端与对应的门店端的Channel信息，所以监控服务端具备对各个服务端进行数据调节的功能，例如在其中一个服务端的故障后，服务端不再应答监控服务端发出的正常使用校验信息，监控服务端在正常使用校验信息发出后，若没有预设第三时间，比如10分钟，没有接收到故障服务端应答信号，则会将故障服务端对应的所有门店端的Channel信息发送给其他服务端，并通过手持端通知相关人员维修并关闭该故障服务端，其中其他服务端的具体选择可以是广播请求信息频率最低的服务端，使得其他服务端暂时代替故障服务端对对应的门店进行请求信息的发送，从而增强了系统稳定性，此选择的原因是基于广播请求信息频率最低说明服务端接收的订单少，任务处理量是不饱和的，不易因其他门店端的Channel信息的导入导致系统过于繁忙，于此选择广播请求信息频率最低的服务端暂替故障服务端；

另外在门店端的Channel信息发送给广播请求信息频率最低的服务端后，为方便说明将门店端的Channel信息发送到的服务端定位为转移服务端，监控服务端还会对转移服务端的广播请求信息的频率进行监控，若是转移服务端的广播请求信息的频率超过预置频率，预置频率根据服务器的信息处理能力进行设定，比如预置频率为1分钟20次，超过1分钟20次就超过了服务器的信息处理能力，那么需要进行再调节操作，监控服务端在监测到转移服务端的广播请求信息的频率超过预置频率时，统计转移服务端请求信息的频率超过预置频率期间每个门店端对应的请求信息出现频率，得出门店端排序列表；在门店端排序列表中，各个门店端按照该服务端请求信息的频率超过预置频率期间对应的请求信息出现次数从多到少进行排序，得出门店端排序列表中排名最前的原属于故障服务端的门店端，将该门店端的Channel信息从转移服务端转移到现在广播请求信息频率最低的服务端中，重复进行再调节操作，直到转移服务端的广播请求信息的频率低于预置频率。在监控服务端检测到故障服务端修复重新上线工作前，监控服务端会将所有服务端内原属于故障服务端门店端的Channel信息全部删除，避免造成干扰。

此外，监控服务端还会统计服务端请求信息发出后对应门店端的响应时间，对每个门店端均进行N次响应时间的统计，N可以是20次或30次，N的具体数量在此不做限定，除去N次统计中N/4个最长响应时间以及N/4个最短响应时间，对剩余的响应时间做均值计算，得出门店端平均响应时间，判断门店端平均响应时间是否超过预置平均响应时间，若是则判断该门店端对应的服务端下是否有一半以上的门店端的平均响应时间超过预置平均响应时间，若是则说明是服务端的响应较慢，向人员手持端发出维护提示信息以提醒人员对该服务端进行维护；若否则说明是门店端的响应较慢，其中一个原因可能是设备不适配，基于此原因则将该门店端的Channel信息分享给其他服务端，其他服务端根据Channel信息依次向该门店端广播测试信息，根据门店端对每个服务端发出的测试信息的响应时间进行比较，若是每个服务端发出的测试信息的响应时间均大于预置平均响应时间，说明是门店端反应过慢，则向门店端发出更新提示信息，通知门店更换设备；若是每个服务端发出的测试信息的响应时间并不都大于预置平均响应时间，则找出能够让该门店端响应时间最短的最佳服务端，监控服务端发送清除信息到最佳服务端以外的其他服务端清除该门店端的Channel信息，从而更换门店端所连接的服务端，以提升系统运行效率。

本申请实施例一种去中心化反向服务调用方法的方法的实施原理为：客户端通过网络下订单到服务端或者人员直接在服务端上进行相应操作后，服务端生成相应的请求信息，并通过广播的方式发生请求信息到门店端或其他服务器，请求信息经过服务器或者其他服务器的网关筛选进入信道被对应的门店端接收，门店端接收请求信息后，经过处理生成反馈信息发送给服务端，使得服务端能够快速告知客户订单处理结果，使得客户的订单处理不易被耽误。

本申请实施例还公开一种去中心化反向服务调用方法的系统。

参照图4，一种去中心化反向服务调用方法的系统，包括：

广播通讯模块1，用于广播请求信息至所有门店端，门店端用于通过信息通道筛选出对应的请求信息并对请求信息进行处理返回反馈信息；

反馈接收模块2，用于在预设的第一时间内接收所有门店端的反馈信息；

订单处理模块3，用于提取所有在预设时间内接收反馈信息中的ID信息，并基于ID信息处理规则得出订单处理结果；

信息发送模块4，用于将订单处理结果发送至客户端。

本申请实施例还公开一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时使处理器实现如图1至图3中所示的一种去中心化反向服务调用方法。

其中，计算机程序可以存储于计算机可读介质中，计算机程序包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间件形式等，计算机可读介质包括能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器（ROM）、随机存取存储器（RAM）、电载波信号、电信信号以及软件分发介质等，需要说明的是，计算机可读介质包括但不限于上述元器件。

其中，通过本计算机可读存储介质，将上述实施例的近端机的监控方法存储于计算机可读存储介质中，并且，被加载并执行于处理器上，以方便上述方法的存储及应用。

以上均为本申请的较佳实施例，并非依此限制本申请的保护范围，故：凡依本申请的结构、形状、原理所做的等效变化，均应涵盖于本申请的保护范围之内。

Claims (10)

1.一种去中心化反向服务调用方法，其特征在于，包括以下步骤：

广播请求信息至所有门店端，门店端用于通过信息通道筛选出对应的请求信息并对请求信息进行处理返回反馈信息；

在预设的第一时间内接收所有门店端的反馈信息；

提取所有在预设时间内接收反馈信息中的ID信息，并基于ID信息处理规则得出订单处理结果；

将订单处理结果发送至客户端。

2.根据权利要求1所述的一种去中心化反向服务调用方法，其特征在于，其中，订单处理结果为订单成功处理结果或订单失败结果，所述ID信息处理规则包括：

识别请求信息的类型，其中，请求信息的类型包括订单型；

根据订单型的请求信息，判断是否接收到反馈信息；

若是，则得出订单成功处理结果；

若否，则得出订单失败结果。

3.根据权利要求1所述的一种去中心化反向服务调用方法，其特征在于，在广播请求信息至所有门店端前，还包括以下步骤：

接收其他服务端广播的请求信息。

4.根据权利要求1所述的一种去中心化反向服务调用方法，其特征在于，在广播请求信息至所有门店端前，还包括以下步骤：

根据客户订单请求或控制指令生成请求信息。

5.根据权利要求2所述的一种去中心化反向服务调用方法，其特征在于，其中，请求信息的类型还包括指令型，所述ID信息处理规则还包括：

根据指令型的请求信息，识别指令型的请求信息中的目标指令信息；

将目标指令信息与预置的指令表对应，得出门店端ID集合；

将门店端ID集合中的门店端ID逐一与预设时间内接收的所有反馈信息中的ID信息比对，得到门店端响应结果，其中门店端响应结果包括全部响应结果或部分响应结果；

在得出部分响应结果后，记忆该请求信息并在第一时间内间隔预设间隔时间重复广播该请求信息。

6.根据权利要求5所述的一种去中心化反向服务调用方法，其特征在于，在广播请求信息至所有门店端后，还包括以下步骤：

同时广播请求信息到监控服务端，其中，监控服务端接收请求信息后提取请求信息中的目标指令信息后，检测与目标指令信息对应的门店端的状态信息是否正常，得出检测结果，根据请求信息与检测结果发送延时操作信息到服务端；

接收监控服务端发送的处理信息；

根据延时操作信息，将第一时间延长至预置的第二时间。

7.根据权利要求5所述的一种去中心化反向服务调用方法，其特征在于，在广播请求信息至所有门店端后，还包括以下步骤：

接收监控服务端发出的结束操作信息，使得接收所有门店端的反馈信息的步骤结束。

8.根据权利要求1所述的一种去中心化反向服务调用方法，其特征在于，在将门店端ID集合中的门店端ID逐一与预设时间内接收的所有反馈信息中的ID信息比对，得到门店端响应结果前，还包括以下步骤：

获取监控服务端发送的门店端下线信息；

根据门店端下线信息，获取下线门店端ID并从门店端ID集合中,将与下线门店端ID对应的门店端ID屏蔽。

9.一种基于权利要求1-8任意一项所述的去中心化反向服务调用方法的系统，其特征在于，包括：

广播通讯模块(1)，用于广播请求信息至所有门店端，门店端用于通过信息通道筛选出对应的请求信息并对请求信息进行处理返回反馈信息；

反馈接收模块(2)，用于在预设的第一时间内接收所有门店端的反馈信息；

订单处理模块(3)，用于提取所有在预设时间内接收反馈信息中的ID信息，并基于ID信息处理规则得出订单处理结果；以及，

信息发送模块(4)，用于将订单处理结果发送至客户端。

10.一种电子设备，其特征在于，包括：处理器和存储器；其中，所述存储器存储有计算机程序，所述计算机程序适于由所述处理器加载并执行如权利要求1-8任意一项的方法步骤。

Images