本公开涉及微服务调用技术领域，特别涉及一种保证幂等的微服务调用监管系统及方法。
背景技术：
本部分的陈述仅仅是提供了与本公开相关的背景技术，并不必然构成现有技术。
在微服务架构下，原本单体式应用以及数据库被拆分为多个微服务应用和多个数据库，原本单体式应用内的代码逻辑调用变为了多个应用之间的微服务调用，业务数据由单一数据库保存变为分库分表。单体式应用内代码调用的调用端与提供端之间不存在网络和分库等因素，两端数据库操作的一致性得到保证，提供端不需要保证操作幂等。
本公开发明人发现，在微服务架构下，调用两端处于不同数据库，调用端与提供端之间容易受网络等因素影响出现提供端处理结果反馈不到调用端的情况，这种情况下调用端只能重新发起调用再次获取到处理结果，才能保证两端数据库操作的一致性，这就需要提供方要保证幂等，而让微服务的开发者每一个微服务都保证幂等，无疑增加了微服务开发的难度和工作量。
技术实现要素：
为了解决现有技术的不足，本公开提供了一种保证幂等的微服务调用监管系统及方法，保证了微服务的严格幂等，屏蔽了在不同系统以及不同数据库之间调用时造成的数据库操作一致性问题。
为了实现上述目的，本公开采用如下技术方案：
本公开第一方面提供了一种保证幂等的微服务调用监管系统。
一种保证幂等的微服务调用监管系统，包括交易申请模块和交易调用模块；
所述交易申请模块包括调用端交易申请模块和提供端交易申请模块，调用端发起调用申请时，通过调用端交易申请模块向提供端交易申请模块发起申请，提供端交易申请模块将生成的交易编号返回至调用端，调用端根据交易编号组装调用参数；
所述交易调用模块包括调用端交易调用模块和提供端交易调用模块，调用端通过调用端交易调用模块根据调用参数发起微服务调用，提供端交易调用模块接到调用请求，进行交易信息校验；
如果交易是首次发生，所述提供端交易调用模块将交易信息保存，调用微服务实现类，并保存交易结果，将交易结果通过调用端交易调用模块返回至调用端；
如果交易非首次发生，所述提供端交易调用模块获取交易信息，判断交易是否已经完成，如果上次调用交易已经完成，则将交易结果通过调用端交易调用模块返回至调用端，如果交易未完成，调用微服务实现类并保存交易结果，将交易结果通过调用端交易调用模块返回至调用端。
作为可能的一些实现方式，所述调用监管系统还包括交易后续结果存取模块，用于接收提供端的交易后续结果，调用端发送交易后续结果的调用请求到提供端，提供端判断后续结果是否设置，如果交易完成并且后续结果已经设置，交易后续结果存取模块将后续结果返回至调用端，调用端根据后续结果处理；如果交易未完成或者后续结果未设置，由调用端等待时机再次发起后续结果获取请求。
作为可能的一些实现方式，所述调用监管系统还包括交易管理模块，用于管理所有的微服务交易，查看每一次交易的详情，并针对交易异常的情况给出解决方案。
作为可能的一些实现方式，所述交易编号用于标志一次的微服务交易，一次微服务交易可以发生多次的微服务调用，每一次调用的交易编号相同。
作为可能的一些实现方式，微服务调用的幂等性通过提供端交易调用模块内对交易信息的校验来保证。
本公开第二方面提供了一种保证幂等的微服务调用方法。
一种保证幂等的微服务调用方法，包括以下步骤：
步骤601：调用端发起调用申请时，首先通过调用端的交易申请模块向提供端的交易申请模块发起申请，提供端的交易申请模块将生成的交易编号返回；
步骤602：调用端根据交易编号组装调用参数；
步骤603：调用端发起微服务调用；
步骤604：提供端接到调用请求，提供端微服务交易调用模块进行交易信息校验，校验交易是不是首次发生，如果是首次发生则转向605步骤进行处理，如果是非首次发生，表示之前交易调用发生异常，转向609步骤进行处理；
步骤605：交易首次发生，将交易信息保存，用于604步骤判断是否发生过交易；
步骤606：调用微服务实现类，获取交易结果；
步骤607：保存交易结果；
步骤608：返回交易结果；
步骤609：交易非首次发生时，获取交易信息；
步骤610：判断交易是否已经完成，本步骤发生在非首次调用时，用于判断上次调用是否已经产生了交易结果，如果上次调用交易已经完成那么转向608步骤，如果交易未完成，那么转向606步骤重新进行交易处理。
作为可能的一些实现方式，提供端完成业务处理以后，由提供端进行微服务交易后续结果的设置，后续结果的获取由调用端发起，具体为：
步骤701：调用端发起请求获取后续结果；
步骤702：提供端判断后续结果是否设置，如果交易完成并且后续结果已经设置则转向703步骤，如果交易未完成或者后续结果未设置，那么返回701步骤由调用端等待时机再次发起后续结果获取请求；
步骤703：获取后续结果；
步骤704：调用端根据后续结果处理。
作为可能的一些实现方式，集中可视化管理所有的微服务交易，实时查看每一次交易的详情，并针对交易异常的情况给出异常解决方案。
作为可能的一些实现方式，一次微服务交易可以发生多次的微服务调用，每一次调用的交易编号相同，微服务调用的幂等性通过提供端交易调用模块内对交易信息的校验来保证。
与现有技术相比，本公开的有益效果是：
1、本公开所述的内容通过微服务交易申请模块与微服务交易调用模块相结合，保证了微服务的严格幂等，屏蔽了在不同系统以及不同数据库之间调用时造成的数据库操作一致性问题。
2、本公开通过设置微服务交易后续模块，为处理周期较长的微服务提供了避免调用方等待和调用超时的处理方式，避免因为微服务处理时间过长导致调用端一直等待甚至出现超时的问题。
3、本公开通过设置微服务交易管理模块，为幂等微服务的调用提供了便捷可视化的管控，能够方便直接的查看调用情况和处理调用异常问题。
附图说明
图1为本公开实施例1提供的微服务调用过程以及设置获取后续结果的时序图。
图2为本公开实施例1提供的微服务交易调用过程流程示意图。
图3为本公开实施例1提供的微服务交易后续结果获取调用过程流程示意图。
具体实施方式
应该指出，以下详细说明都是例示性的，旨在对本公开提供进一步的说明。除非另有指明，本文使用的所有技术和科学术语具有与本公开所属技术领域的普通技术人员通常理解的相同含义。
需要注意的是，这里所使用的术语仅是为了描述具体实施方式，而非意图限制根据本公开的示例性实施方式。如在这里所使用的，除非上下文另外明确指出，否则单数形式也意图包括复数形式，此外，还应当理解的是，当在本说明书中使用术语“包含”和/或“包括”时，其指明存在特征、步骤、操作、器件、组件和/或它们的组合。
在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。
实施例1：
本公开实施例1提供了一种保证幂等的微服务调用监管系统，如图1所示，包括交易申请模块和交易调用模块；
所述交易申请模块包括调用端交易申请模块和提供端交易申请模块，调用端发起调用申请时，通过调用端交易申请模块向提供端交易申请模块发起申请，提供端交易申请模块将生成的交易编号返回至调用端，调用端根据交易编号组装调用参数；
所述交易调用模块包括调用端交易调用模块和提供端交易调用模块，调用端通过调用端交易调用模块根据调用参数发起微服务调用，提供端交易调用模块接到调用请求，进行交易信息校验；
如果交易是首次发生，所述提供端交易调用模块将交易信息保存，调用微服务实现类，并保存交易结果，将交易结果通过调用端交易调用模块返回至调用端；
如果交易非首次发生，所述提供端交易调用模块获取交易信息，判断交易是否已经完成，如果上次调用交易已经完成，则将交易结果通过调用端交易调用模块返回至调用端，如果交易未完成，调用微服务实现类并保存交易结果，将交易结果通过调用端交易调用模块返回至调用端。
还包括交易后续结果存取模块，用于接收提供端的交易后续结果，调用端发送交易后续结果的调用请求到提供端，提供端判断后续结果是否设置，如果交易完成并且后续结果已经设置，交易后续结果存取模块将后续结果返回至调用端，调用端根据后续结果处理；如果交易未完成或者后续结果未设置，由调用端等待时机再次发起后续结果获取请求。
还包括交易管理模块，用于管理所有的微服务交易，查看每一次交易的详情，并针对交易异常的情况给出解决方案。
所述交易编号用于标志一次的微服务交易，一次微服务交易可以发生多次的微服务调用，每一次调用的交易编号相同，微服务调用的幂等性通过提供端交易调用模块内对交易信息的校验来保证。
实施例2：
本公开实施例2提供了一种保证幂等的微服务调用方法，调用端发起微服务交易到交易结束分为两个过程，一个是微服务交易调用，一个是后续结果获取。
微服务交易调用的过程，如图2，具体为：
步骤201：服务调用端向微服务交易申请模块申请交易编号，并将交易编号保存。
在图1中详细描述了本过程，调用端发起调用申请101时，首先通过调用端的交易申请模块向提供端的交易申请模块发起申请，提供端的交易申请模块将生成的交易编号返回；
步骤202：调用端根据交易编号组装调用参数；
步骤203：调用端发起微服务调用；
步骤204：提供端接到调用请求，微服务交易调用模块进行交易信息校验。校验交易是不是首次发生，如果是首次发生则转向205步骤进行处理，如果是非首次发生，表示之前交易调用发生异常，转向209步骤进行处理；
步骤205：交易首次发生，将交易信息保存，用于204步骤判断是否发生过交易；
步骤206：调用微服务实现类，拿到交易结果；
步骤207：保存交易结果；
步骤208：返回交易结果；
步骤209：交易非首次发生时，获取交易信息；
步骤210：判断交易是否已经完成，本步骤发生在非首次调用时，用于判断上次调用是否已经产生了交易结果，如果上次调用交易已经完成那么转向208步骤，如果交易未完成，那么转向206步骤重新进行交易处理。
微服务交易后续结果的设置由服务提供端进行设置，过程发生在提供端完成业务处理以后。
后续结果的获取由调用端发起，如图1中的请求102。
获取的过程如图3所示：
步骤301：调用端发起请求获取后续结果；
步骤302：提供端判断后续结果是否设置，如果交易完成并且后续结果已经设置则转向303步骤，如果交易未完成或者后续结果未设置，那么返回301步骤由调用端等待时机再次发起后续结果获取请求；
步骤303：获取后续结果；
步骤304：调用端根据后续结果处理。
以上所述仅为本公开的优选实施例而已，并不用于限制本公开，对于本领域的技术人员来说，本公开可以有各种更改和变化。凡在本公开的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。
1.一种保证幂等的微服务调用监管系统，其特征在于，包括交易申请模块和交易调用模块；
所述交易申请模块包括调用端交易申请模块和提供端交易申请模块，调用端发起调用申请时，通过调用端交易申请模块向提供端交易申请模块发起申请，提供端交易申请模块将生成的交易编号返回至调用端，调用端根据交易编号组装调用参数；
所述交易调用模块包括调用端交易调用模块和提供端交易调用模块，调用端通过调用端交易调用模块根据调用参数发起微服务调用，提供端交易调用模块接到调用请求，进行交易信息校验；
如果交易是首次发生，所述提供端交易调用模块将交易信息保存，调用微服务实现类，并保存交易结果，将交易结果通过调用端交易调用模块返回至调用端；
如果交易非首次发生，所述提供端交易调用模块获取交易信息，判断交易是否已经完成，如果上次调用交易已经完成，则将交易结果通过调用端交易调用模块返回至调用端，如果交易未完成，调用微服务实现类并保存交易结果，将交易结果通过调用端交易调用模块返回至调用端。
2.如权利要求1所述的保证幂等的微服务调用监管系统，其特征在于，所述调用监管系统还包括交易后续结果存取模块，用于接收提供端的交易后续结果，调用端发送交易后续结果的调用请求到提供端，提供端判断后续结果是否设置，如果交易完成并且后续结果已经设置，交易后续结果存取模块将后续结果返回至调用端，调用端根据后续结果处理；如果交易未完成或者后续结果未设置，由调用端等待时机再次发起后续结果获取请求。
3.如权利要求1所述的保证幂等的微服务调用监管系统，其特征在于，所述调用监管系统还包括交易管理模块，用于管理所有的微服务交易，查看每一次交易的详情，并针对交易异常的情况给出解决方案。
4.如权利要求1所述的保证幂等的微服务调用监管系统，其特征在于，所述交易编号用于标志一次的微服务交易，一次微服务交易可以发生多次的微服务调用，每一次调用的交易编号相同。
5.如权利要求1所述的保证幂等的微服务调用监管系统，其特征在于，微服务调用的幂等性通过提供端交易调用模块内对交易信息的校验来保证。
6.一种保证幂等的微服务调用方法，其特征在于，包括以下步骤：
步骤601：调用端发起调用申请时，首先通过调用端的交易申请模块向提供端的交易申请模块发起申请，提供端的交易申请模块将生成的交易编号返回；
步骤602：调用端根据交易编号组装调用参数；
步骤603：调用端发起微服务调用；
步骤604：提供端接到调用请求，提供端微服务交易调用模块进行交易信息校验，校验交易是不是首次发生，如果是首次发生则转向605步骤进行处理，如果是非首次发生，表示之前交易调用发生异常，转向609步骤进行处理；
步骤605：交易首次发生，将交易信息保存，用于604步骤判断是否发生过交易；
步骤606：调用微服务实现类，获取交易结果；
步骤607：保存交易结果；
步骤608：返回交易结果；
步骤609：交易非首次发生时，获取交易信息；
步骤610：判断交易是否已经完成，本步骤发生在非首次调用时，用于判断上次调用是否已经产生了交易结果，如果上次调用交易已经完成那么转向608步骤，如果交易未完成，那么转向606步骤重新进行交易处理。
7.如权利要求6所述的保证幂等的微服务调用方法，其特征在于，提供端完成业务处理以后，由提供端进行微服务交易后续结果的设置，后续结果的获取由调用端发起，具体为：
步骤701：调用端发起请求获取后续结果；
步骤702：提供端判断后续结果是否设置，如果交易完成并且后续结果已经设置则转向703步骤，如果交易未完成或者后续结果未设置，那么返回701步骤由调用端等待时机再次发起后续结果获取请求；
步骤703：获取后续结果；
步骤704：调用端根据后续结果处理。
8.如权利要求6所述的保证幂等的微服务调用方法，其特征在于，集中可视化管理所有的微服务交易，实时查看每一次交易的详情，并针对交易异常的情况给出异常解决方案。
9.如权利要求6所述的保证幂等的微服务调用方法，其特征在于，一次微服务交易可以发生多次的微服务调用，每一次调用的交易编号相同，微服务调用的幂等性通过提供端交易调用模块内对交易信息的校验来保证。
技术总结