基于微服务的协作处理方法、系统及服务器与流程

本发明涉及分布式系统技术领域，特别涉及基于微服务的协作处理方法、系统及服务器。

背景技术：

微服务是一个新兴的软件架构，把一个大型的单个应用程序和服务拆分为数十个的支持微服务，一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

然而，各个服务之间的协作会因为各种原因而变的不同步，比如A服务请求B服务完成一个任务，并且这个服务的操作不具备幂等性。那么如果在请求后出现错误，A服务就不清楚服务是否完成，由于B服务功能不具备幂等性，所以A服务不能向B服务重新发请操作。比如，B服务是一个扣费操作，如果先前的操作是成功的，但只是在返回给A服务时出现了估障导致A服务没有收到成功消息，如果A服务再次向B服务发出同样请求那么就会出现多扣费的现情况。因此微服务中的非幂等与幂等操作还存在协作问题亟需解决。

因而现有技术还有待改进和提高。

技术实现要素：

鉴于上述现有技术的不足之处，本发明的目的在于提供基于微服务的协作处理方法、系统及服务器，通过查询的方式将处理失败的微服务交给查询接口处理，并将功能操作与数据返回进行拆分，存在非幂等操作时可避免由于重复操作导致的数据不一致，在幂等操作中则可减少服务请求次数，减轻负载压力。

为了达到上述目的，本发明采取了以下技术方案：

一种基于微服务的协作处理方法，其包括如下步骤：

A、服务接口向后台的微服务的工作接口发起请求；

B、所述服务接口接收所述微服务的处理结果，并根据处理结果更新对应微服务的请求状态数据；

C、查询所有微服务的请求状态数据，并判断是否存在处理状态为失败的微服务，若是，则执行步骤D；若否，则执行步骤E；

D、向处理状态为失败的微服务重新发起请求，所述服务接口接收所有处理状态为失败的微服务的处理结果；

E、整合所有微服务的处理结果返回至用户请求端。

所述的基于微服务的协作处理方法中，所述步骤A之前还包括步骤：

A01、服务接口进行数据预处理，并获取一预设标识符作为密钥，将所述密钥、每个微服务的请求状态数据和处理结果一并存入数据库中。

所述的基于微服务的协作处理方法中，所述步骤A01之后、步骤A之前还包括步骤：

A02、将所有微服务的初始请求状态数据设置为处理中，初始处理结果设置为空，并存入数据库中；

A03、判断存入数据库时是否出错，若是，则直接返回处理错误至请求端；若否，则继续执行步骤A。

所述的基于微服务的协作处理方法中，所述步骤A具体包括：

所述服务接口选择后台微服务中的一个微服务，向其工作接口发起请求，并将所述密钥一并发送至该微服务。

所述的基于微服务的协作处理方法中，所述步骤B包括步骤：

B1、所述服务接口接收该被选择的微服务的处理结果；

B2、所述服务接口根据接收的处理结果更新该被选择的微服务的请求状态数据，并返回步骤A，继续向下一个微服务的工作接口发起请求，直到所有微服务都执行完毕。

所述的基于微服务的协作处理方法中，所述步骤C包括步骤：

C1、通过所述密钥请求调用所述服务接口的查询接口；

C2、所述查询接口查询所有微服务的请求状态数据，并判断是否存在处理失败的微服务；

C3、若存在处理状态为失败的微服务，根据所述密钥查询所有处理状态为失败的微服务，并执行步骤D；若不存在处理状态为失败的微服务，则执行步骤E。

所述的基于微服务的协作处理方法中，所述步骤D包括步骤：

D1、向其中一个处理状态为失败的微服务的工作接口重新发起请求；

D2、所述服务接口接收该处理状态为失败的微服务返回的处理结果；

D3、返回步骤D1，继续向下一个处理状态为失败的微服务的工作接口发起请求，直到所有处理状态为失败的微服务都执行完毕。

一种基于微服务的协作处理系统，其包括：

第一请求发起模块，用于控制服务接口向后台的微服务的工作接口发起请求；

第一接收更新模块，用于控制服务接口接收所述微服务的处理结果，并根据处理结果更新对应微服务的请求状态数据；

查询模块，用于查询所有微服务的请求状态数据，并判断是否存在处理状态为失败的微服务；

第二请求发起模块，用于当存在处理状态为失败的微服务时，向各个处理状态为失败的微服务重新发起请求，以及控制所述服务接口接收所有处理状态为失败的微服务的处理结果；

数据返回模块，用于整合所有微服务的处理结果返回至用户请求端。

所述的基于微服务的协作处理系统中，还包括：

预处理模块，用于控制服务接口进行数据预处理，并获取一预设标识符作为密钥，将所述密钥、每个微服务的请求状态数据和处理结果一并存入数据库中；

初始化模块，用于将所有微服务的初始请求状态数据设置为处理中，初始处理结果设置为空，并存入数据库中；

判断模块，用于判断存入数据库时是否出错，若是，则直接返回处理错误至请求端，若否则控制服务接口向后台的微服务的工作接口发起请求。

一种服务器，其包括如上所述的基于微服务的协作处理系统。

相较于现有技术，本发明提供的基于微服务的协作处理方法、系统及服务器中，所述基于微服务的协作处理方法通过服务接口向后台的微服务的工作接口发起请求；之后所述服务接口接收所述微服务的处理结果，并根据处理结果更新对应微服务的请求状态数据，查询所有微服务的请求状态数据，并判断是否存在处理状态为失败的微服务，若是，则向处理状态为失败的微服务重新发起请求，所述服务接口接收所有处理状态为失败的微服务的处理结果；之后整合所有微服务的处理结果返回至用户请求端，通过查询的方式将处理失败的微服务交给查询接口处理，并将功能操作与数据返回进行拆分，存在非幂等操作时可避免由于重复操作导致的数据不一致，在幂等操作中则可减少服务请求次数，减轻负载压力。

附图说明

图1 为本发明提供的基于微服务的协作处理方法的流程图。

图2 为本发明提供的基于微服务的协作处理方法中步骤S101、S102、S103的流程图。

图3 为本发明提供的基于微服务的协作处理方法中步骤S20的流程图。

图4 为本发明提供的基于微服务的协作处理方法中步骤S30的流程图。

图5 为本发明提供的基于微服务的协作处理方法中步骤S40的流程图。

图6为本发明提供的基于微服务的协作处理系统的结构框图。

图7为本发明提供的基于微服务的协作处理中第一接收更新模块的结构框图。

图8为本发明提供的基于微服务的协作处理中查询模块的结构框图。

图9为本发明提供的基于微服务的协作处理中第二请求发起模块的结构框图。

具体实施方式

鉴于现有技术中多个服务之间非幂等操作与幂等操作间无法协作等缺点，本发明的目的在于提供基于微服务的协作处理方法、系统及服务器，通过查询的方式将处理失败的微服务交给查询接口处理，并将功能操作与数据返回进行拆分，存在非幂等操作时可避免由于重复操作导致的数据不一致，在幂等操作中则可减少服务请求次数，减轻负载压力。

为使本发明的目的、技术方案及效果更加清楚、明确，以下参照附图并举实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

请参阅图1，本发明提供的基于微服务的协作处理方法包括如下步骤：

S10、服务接口向后台的微服务的工作接口发起请求；

S20、所述服务接口接收所述微服务的处理结果，并根据处理结果更新对应微服务的请求状态数据；

S30、查询所有微服务的请求状态数据，并判断是否存在处理状态为失败的微服务，若是，则执行步骤S40；若否，则执行步骤S50；

S40、向处理状态为失败的微服务重新发起请求，所述服务接口接收所有处理状态为失败的微服务的处理结果；

S50、整合所有微服务的处理结果返回至用户请求端。

在微服务概念提出之后，通常将单个应用程序拆分成多个微服务，进行独立横线扩展，使得工作更加简便，当一个操作涉及到多个后台微服务是，本发明通过服务接口向多个微服务的工作接口发起请求，其中所述工作接口为提供服务的接口，例如扣费接口、订单接口、显示接口等等，多个微服务在接收到请求后处理各自的请求工作并将相应的处理结果返回至服务接口，即每个微服务根据各自的请求内容进行处理，例如第一微服务接收的请求内容为生成订单、第二微服务接收的请求内容为进行支付扣费、第三微服务接收的请求内容为显示支付结果等等，并将相应的处理结果返回至服务接口，服务接口根据处理结果更新各个微服务的请求状态数据，该请求状态数据根据返回的处理结果可更新为成功success、失败failed或者根据实际情况可或者其他请求状态数据。

之后通过利用查询接口查询所有微服务的请求状态数据，来判断是否存在处理失败的微服务，若不存在，即所有微服务的请求状态数据均为success，则直接整合所有微服务的处理结果（也可称为请求结果数据）返回至用户请求端，例如当第一微服务、第二微服务和第三微服务均处理成功时，直接将订单数据、扣费数据以及支付结果显示数据返回至用户请求端，例如某购物app等等，告知用户此次操作已成功；而当存在处理失败的微服务时，此时处理成功的微服务无需再次执行，仅仅向所有处理状态为失败的微服务重新发送请求，处理失败的微服务再次处理各自的请求工作并返回相应的处理结果至服务接口，再整合所有微服务的处理结果返回至用户请求端，例如当第一微服务和第二微服务均处理成功，第三微服务处理失败时，则单独向第三微服务再次发起请求，而不向第一微服务和第二微服务发起请求，以避免重复生成订单和重复扣费，第三微服务再次执行处理完毕后返回处理结果至服务接口，此时整合三个微服务两次请求处理的结果数据返回至用户请求端，即订单数据、扣费数据以及支付结果显示失败数据，则用户可得知此时已经扣费仅仅为支付结果显示失败，无需再次发起支付操作。通过查询的方式获取状态数据，将处理失败的微服务交给查询接口处理，在存在非幂等操作时可避免由于重复操作导致的数据不一致，加强了分布式系统的鲁棒性，同时当操作涉及的均为幂等操作的微服务时，通过查询也可在用户不重发请求的情况下再次执行处理失败的微服务，减少服务请求次数，降低重复请求带来的负载压力。

进一步地，请一并参阅图2，所述步骤S10之前还包括步骤：

S101、服务接口进行数据预处理，并获取一预设标识符作为密钥，将所述密钥、每个微服务的请求状态数据和处理结果一并存入数据库中。

当需进行某项操作时，从用户请求端会传输数据至服务接口，或者根据传输数据读取系统中的其他数据，例如进行支付操作时，用户请求端会传输支付数额、支付卡号等数据至服务接口，服务接口对这些数据进行如清洗、过滤等预处理，准备请求微服务工作接口所需要的前期工作。并且服务接口还获取一预设标识符作为密钥，本实施例中，所述预设标识符为保存在本地的全局唯一标识符，其为一个128位整数，此标识符重复的可能性极小，用于分配具有唯一性的标识符，结合所述全局唯一标识符、每个微服务请求状态数据和处理结果存入数据库中，作为核心数据，当然也可扩展其他数据一同存入数据库中。

更进一步地，所述步骤S101之后、步骤S10之前还包括步骤：

S102、将所有微服务的初始请求状态数据设置为处理中，初始处理结果设置为空，并存入数据库中；

S103、判断存入数据库时是否出错，若是，则直接返回处理错误至请求端；若否，则继续执行步骤S10。

当服务接口进行了数据预处理并且获取了全局唯一标识符作为密钥后，在将每个微服务的请求状态数据和处理结果一同存入数据库中时，此时还未发起请求，则需将所有微服务的初始请求状态数据均设置为处理中processing，而将初始处理结果设置为空null，并存入数据库中，此时若存入数据库出错，则直接返回处理错误的信息至请求端，不进行任何后续处理，若没有出错则正常执行后续的发起请求流程，这个请求开始之前的点称为事务点，由于有可能会发生处理数据丢失，因此在每个真实请求开始之前必需有事务点记录，避免数据丢失导致的未知情况，后续的状态数据检测等都与事务点相关。

优选地，所述步骤10具体包括：所述服务接口选择后台的微服务中的一个微服务，向其工作接口发起请求，并将所述密钥一并发送至该微服务。

同时，请一并参阅图3，所述步骤S20包括步骤：

S21、所述服务接口接收该被选择的微服务的处理结果；

S22、所述服务接口根据接收的处理结果更新该被选择的微服务的请求状态数据，并返回步骤S10，继续向下一个微服务的工作接口发起请求，直到所有微服务都执行完毕。

当完成上述的请求工作接口所需前期工作，并将初始数据包括请求状态数据和处理结果存入数据库后，服务接口向其中一个微服务的工作接口发起请求，例如对第一微服务的订单接口发起请求，请求生成订单，此时一并将所述密钥即全局唯一标识符发送至第一微服务，便于后续查询工作，之后第一微服务处理生成订单的请求工作，并在处理完成后将结果返回至服务接口，服务接口根据处理结果更新第一微服务的请求状态数据，即步骤S102中的初始请求状态数据，根据处理结果将初始值processing更新为success或者failed或者其他状态数据，用于表示事务点处理状态，之后返回步骤S11，即继续向下一个微服务的工作接口发起请求，例如继续向第二微服务的扣费接口发起请求，请求扣费支付，第二微服务处理该请求工作并返回结果，服务接口同样在接收到处理结果后更新第二微服务的状态数据，以此类推，重复上述请求、处理、返回结果、更新状态数据过程，直到所有的微服务都执行完毕，此时可得到所有微服务更新后的请求状态数据和返回的处理结果。

在所有的微服务均执行完毕后，采用查询的方式查询事务点状态，即每个微服务的请求状态数据，具体地，请参阅图4，所述步骤S30包括步骤：

S31、通过所述密钥请求调用所述服务接口的查询接口；

S32、所述查询接口查询所有微服务的请求状态数据，并判断是否存在处理失败的微服务；

S33、若存在处理状态为失败的微服务，根据所述密钥查询所有处理状态为失败的微服务，并执行步骤S40；若不存在处理状态为失败的微服务，则执行步骤S50。

当所有的微服务都执行完毕，并且所有微服务的请求状态数据均已更新后，通过所述密钥即全局唯一标识符请求服务接口的查询接口，查询接口查询各个事务点，并读取事务点状态，如上所述在向每个微服务请求发起之前均有事务点记录，各个微服务在处理完成后会更新各自的请求状态数据，即各个事务点的状态，本发明通过在返回实际数据之前，先查询所有微服务的请求状态数据，判断是否存在处理失败的微服务，将请求操作的状态与实际数据返回进行分割，避免由于处理错误导致的数据改变。

当不存在处理失败的微服务时，即所有事务点状态均为success，则直接整合所有微服务的处理结果返回至用户请求端；当存在处理状态为失败的微服务时，根据先前发送请求时一并发送的全局唯一标识符查询来所有的处理失败的微服务，并向所有处理失败的微服务重新发送请求，例如通过查询接口以所述密钥查询到第二微服务和第三微服务均处理失败，即扣费失败同时支付结果显示失败，而第一微服务处理的生成订单成功，此时向第二微服务和第三微服务重新发起请求，使第二微服务和第三微服务重新执行一遍各自的请求工作并返回结果，最后整合两次请求处理的结果数据返回至用户请求端，无论第二微服务和第三微服务在二次请求时处理成功或失败，第一微服务的订单数据也只改变一次，不会因为第二微服务和第三微服务的重新执行而改变第一微服务的返回数据，导致重复生成订单，并且用户也可通过最终返回的数据判断具体是哪个微服务执行出错，例如扣费错误，此时用户可再发起扣费请求即可，无需再次生成重复订单，提高处理效率。

类似地，在存在处理失败的微服务需要对其重新发起请求时，如图5所示，所述步骤S40包括步骤：

S41、向其中一个处理状态为失败的微服务的工作接口重新发起请求；

S42、所述服务接口接收该处理状态为失败的微服务返回的处理结果；

S43、返回步骤S41，继续向下一个处理状态为失败的微服务的工作接口发起请求，直到所有处理状态为失败的微服务都执行完毕。

通过查询接口查询到所有请求处理失败的微服务，并向其中一个处理失败的微服务重新发起请求，例如重新向第二微服务的工作接口即扣费接口重新发起请求，第二微服务在二次接收到扣费请求时再次执行扣费请求工作，由于前一次处理为失败状态因此二次执行时扣费的数据并没有改变，不会由于重复操作导致该非幂等操作的数据不一致，第二微服务在处理完成后再次返回处理结果至服务接口，根据处理结果服务接口选择保持或更新第二微服务的请求状态数据，之后继续向下一个处理失败的第三微服务的工作接口发起请求，重复上述过程，直到所有处理失败的微服务均执行完毕，得到二次请求后的所有微服务的请求状态数据以及处理结果。通过单独将失败的微服务交给查询接口处理，有效避免了由于微服务中存在非幂等操作，在重复操作时导致的数据错误，解决了多个服务之间非幂等操作与幂等操作的协同处理，保证数据正确性。同时在幂等操作中则可减少服务请求次数，减轻负载压力。

根据如上所述的基于微服务的协作处理方法，本发明还相应提供基于微服务的协作处理系统，如图6所示，所述基于微服务的协作处理系统包括第一请求发起模块10、第一接收更新模块20、查询模块30、第二请求发起模块40、数据返回模块50、预处理模块60、初始化模块70和判断模块80，所述第一请求发起模块10、第一接收更新模块20、查询模块30、第二请求发起模块40、数据返回模块50依次连接，所述查询模块40还连接数据返回模块50，所述预处理模块60、初始化模块70和判断模块80依次连接，所述判断模块80还连接第一请求发起模块10。

其中，所述第一请求发起模块10用于控制服务接口向后台的微服务的工作接口发起请求；所述第一接收更新模块20用于控制服务接口接收所述微服务的处理结果，并根据处理结果更新对应微服务的请求状态数据；具体用于控制服务接口选择后台多个微服务中的其中一个微服务，向其工作接口发起请求，并将所述密钥一并发送至该微服务；所述查询模块30用于查询所有微服务的请求状态数据，并判断是否存在处理状态为失败的微服务；所述第二请求发起模块40用于当存在处理状态为失败的微服务时，向各个处理状态为失败的微服务重新发起请求，以及控制所述服务接口接收所有处理状态为失败的微服务的处理结果；所述数据返回模块50用于整合所有微服务的处理结果返回至用户请求端；所述预处理模块60用于控制服务接口进行数据预处理，并获取一预设标识符作为密钥，将所述密钥、每个微服务的请求状态数据和处理结果一并存入数据库中；所述初始化模块70用于将所有微服务的初始请求状态数据设置为处理中，所述初始处理结果设置为空，并存入数据库中；所述判断模块80用于判断存入数据库时是否出错，若是，则直接返回处理错误至请求端，若否则控制服务接口向后台的微服务的工作接口发起请求。由于上述方法实施例中已详细描述该部分具体实施例，具体请参阅上述方法对应的实施例。

进一步地，请一并参阅图7，所述第一接收更新模块20包括第一接收单元201和第一更新单元202，所述第一接收单元201连接第一更新单元202，所述第一接收单元201用于控制服务接口接收该被选择的微服务的处理结果；所述第一更新单元202用于控制服务接口根据接收的处理结果更新该被选择的微服务的请求状态数据，并继续向下一个微服务的工作接口发起请求，直到所有微服务都执行完毕。由于上述方法实施例中已详细描述该部分具体实施例，具体请参阅上述方法对应的实施例。

进一步地，请参阅图8，所述查询模块30包括请求单元301、查询判断单元302和处理单元303，所述请求单元301、查询判断单元302和处理单元303依次连接，所述请求单元301用于通过所述密钥请求调用所述服务接口的查询接口；所述查询判断单元302用于控制查询接口查询所有微服务的请求状态数据，并判断是否存在处理失败的微服务；所述处理单元303用于若存在处理状态为失败的微服务，根据所述密钥查询所有处理状态为失败的微服务，并向处理状态为失败的微服务重新发起请求；若不存在处理状态为失败的微服务，则整合所有微服务的处理结果返回至请求端。由于上述方法实施例中已详细描述该部分具体实施例，具体请参阅上述方法对应的实施例。

更进一步地，请一并参阅图9，所述第二请求发起模块40包括发起单元401、第二接收单元402和第二更新单元403，所述发起单元401、第二接收单元402和第二更新单元403依次连接，所述发起单元401用于向其中一个处理状态为失败的微服务重新发起请求；所述第二接收单元402用于控制服务接口接收该处理状态为失败的微服务返回的处理结果；所述第二更新单元403用于控制服务接口接收到处理结果后更新该微服务的请求状态数据，继续向下一个处理状态为失败的微服务的工作接口发起请求，直到所有处理状态为失败的微服务都执行完毕。由于上述方法实施例中已详细描述该部分具体实施例，具体请参阅上述方法对应的实施例。

根据如上所述的基于微服务的协作处理系统，本发明还相应提供一种服务器，其包括如上所述的基于微服务的协作处理系统，由于上文已对所述基于微服务的协作处理系统进行了详细描述，此处不作详述。

综上所述，本发明提供的基于微服务的协作处理方法、系统及服务器中，所述基于微服务的协作处理方法通过服务接口向后台的微服务的工作接口发起请求；之后所述服务接口接收所述微服务的处理结果，并根据处理结果更新对应微服务的请求状态数据，查询所有微服务的请求状态数据，并判断是否存在处理状态为失败的微服务，若是，则向处理状态为失败的微服务重新发起请求，所述服务接口接收所有处理状态为失败的微服务的处理结果；之后整合所有微服务的处理结果返回至用户请求端，通过查询的方式将处理失败的微服务交给查询接口处理，并将功能操作与数据返回进行拆分，存在非幂等操作时可避免由于重复操作导致的数据不一致，在幂等操作中则可减少服务请求次数，减轻负载压力。

可以理解的是，对本领域普通技术人员来说，可以根据本发明的技术方案及其发明构思加以等同替换或改变，而所有这些改变或替换都应属于本发明所附的权利要求的保护范围。