多平台的故障确定方法、系统、电子设备及介质与流程

1.本发明涉及计算机技术领域，特别是涉及一种多平台的故障确定方法、一种多平台的故障确定系统，相应的一种电子设备和相应的一种存储介质。


背景技术：

2.随着it(information technology，信息技术，包括现代计算机、网络、通讯等信息领域技术)行业的发展，业内系统之间的联系与合作越来越紧密，且为了尽量减少重复开发软件、重新制作封装好的组件与重复建设库，通常某个功能可通过跨越多个平台实现。
3.跨越多个平台的实现方式，主要是通过各平台间开放接口实现，但当一个请求跨越多个平台时，可能出现由于某些平台出现异常逻辑而导致返回异常响应的现象，发起端难以基于所接收到的异常响应确定异常所发生的平台节点。


技术实现要素：

4.鉴于上述问题，提出了本发明实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种多平台的故障确定方法、一种多平台的故障确定系统，相应的一种电子设备和相应的一种存储介质。
5.本发明实施例公开了一种多平台的故障确定方法，所述多平台涉及到发起端和多个调用端，所述方法包括：
6.所述发起端向多个调用端发送针对预设业务的业务请求，所述业务请求用于在所述多个调用端转发所述业务请求时分别增加自身的平台标识，以及在所述多个调用端对所增加平台标识的业务请求进行异常响应时增加自身的平台错误码，所述平台标识和所述平台错误码用于生成日志记录；
7.所述发起端接收调用端发送的异常响应并根据所述异常响应进行日志查询，基于所查询的日志记录定位与异常响应相应的调用端。
8.可选地，所述业务请求携带有业务信息和接口请求，所述多个调用端具有上下游关系，所述多个调用端中位于上游的调用端具有下游的调用端；
9.所述发起端向多个调用端发送针对预设业务的业务请求，包括：
10.所述发起端向多个调用端发送所述业务信息和接口请求，以使在多个调用端中的某个调用端接收所述业务请求时，基于所述接口请求向位于下游的调用端转发所述业务信息。
11.可选地，所述发起端向多个调用端发送所述业务信息，包括：
12.所述发起端在发送所述业务信息时在所述业务信息前增加自身的平台标识，向位于上游的调用端发送携带有发起端平台标识的业务信息，以使位于上游的调用端在接收到所述发起端平台标识的业务信息后，在所述发起端平台标识后继续增加自身的平台标识。
13.可选地，所述发起端接收调用端发送的异常响应并根据所述异常响应进行日志查询，基于所查询的日志记录定位与异常响应相应的调用端，包括：
14.所述发起端根据所接收的异常响应生成日志查询请求，并向所述多个调用端中位于上游的调用端发送日志查询请求；
15.所述发起端接收所述位于上游的调用端响应所述日志查询请求发送的针对所述业务请求的日志记录；所述日志记录包括所述业务请求在所述多个调用端中的通信情况，所述通信情况基于所述业务请求在经过各个调用端时所增加的平台标识以及在异常响应时所增加的平台错误码确定；
16.所述发起端根据所述日志记录中针对业务请求在所述多个调用端中的通信情况定位与异常响应相应的调用端。
17.本发明实施例还公开了一种多平台的故障确定方法，所述多平台涉及到发起端和多个调用端，所述方法包括：
18.所述多个调用端接收并转发所述发起端发送的针对预设业务的业务请求，并在所转发的业务请求中分别增加自身的平台标识；
19.所述多个调用端分别响应所增加平台标识的业务请求，并在所述业务请求异常时增加自身的平台错误码；所述平台标识和所述平台错误码用于生成日志记录；
20.所述多个调用端向所述发起端发送异常响应，以便所述发起端根据所述异常响应基于所查询的日志记录定位与异常响应相应的调用端。
21.可选地，所述业务请求携带有业务信息和接口请求，所述多个调用端具有上下游关系，所述多个调用端中位于上游的调用端具有下游的调用端；
22.所述发起端多个调用端接收并转发所述发起端发送的针对预设业务的业务请求，包括：
23.所述多个调用端中某一调用端接收所述发起端发送的业务信息和接口请求，基于所述接口请求向位于该调用端下游的另一调用端转发所述业务信息。
24.可选地，所述发起端发送的业务信息前增加有所述发起端的平台标识；所述在所转发的业务请求中分别增加自身的平台标识，包括：
25.所述多个调用端中位于上游的调用端基于所述发起端的平台标识，在所述发起端的平台标识后继续增加自身的平台标识，向位于下游的调用端转发携带有所述发起端的平台标识以及所增加的自身平台标识的业务信息；
26.所述调用端在所述业务信息中所具有的平台标识后继续增加自身的平台标识，继续向位于下游的调用端发送携带有所述发起端的平台标识以及至少两个调用端平台标识的业务信息。
27.可选地，所述多个调用端分别响应所增加平台标识的业务请求，并在所述业务请求异常时增加自身的平台错误码，包括：
28.所述多个调用端中的某一调用端响应增加有调用端平台标识的业务请求，在所述业务请求异常时增加自身的平台错误码，并向位于上游的调用端发送携带有自身平台错误码的异常响应；
29.所述向所述发起端发送异常响应，包括：
30.所述调用端在接收到位于下游的调用端发送的异常响应后，在所述异常响应中所具有的平台错误码后继续增加自身的平台错误码，继续向位于上游的调用端发送携带有平台错误码的异常响应，直至向位于上游的发起端发送异常响应为止。
31.本发明实施例还公开了一种多平台的故障确定系统，所述系统包括发起端和多个调用端，
32.所述发起端，用于向多个调用端发送针对预设业务的业务请求；
33.所述多个调用端，用于接收并转发所述发起端发送的针对预设业务的业务请求，并在所转发的业务请求中分别增加自身的平台标识；
34.所述多个调用端，还用于分别响应所增加平台标识的业务请求，并在所述业务请求异常时增加自身的平台错误码，以及向所述发起端发送异常响应；所述平台标识和所述平台错误码用于生成日志记录；
35.所述发起端，还用于接收调用端发送的异常响应并根据所述异常响应进行日志查询，基于所查询的日志记录定位与异常响应相应的调用端。
36.本发明实施例还公开了一种多平台的故障确定装置，所述多平台涉及到发起端和多个调用端，所述装置包括：
37.业务请求发送模块，位于所述发起端，用于向多个调用端发送针对预设业务的业务请求，所述业务请求用于在所述多个调用端转发所述业务请求时分别增加自身的平台标识，以及在所述多个调用端对所增加平台标识的业务请求进行异常响应时增加自身的平台错误码，所述平台标识和所述平台错误码用于生成日志记录；
38.日志查询模块，位于所述发起端，用于接收调用端发送的异常响应并根据所述异常响应进行日志查询，基于所查询的日志记录定位与异常响应相应的调用端。
39.本发明实施例还公开了一种多平台的故障确定装置，所述多平台涉及到发起端和多个调用端，所述装置包括：
40.业务请求转发模块，位于所述调用端，用于接收并转发所述发起端发送的针对预设业务的业务请求，并在所转发的业务请求中分别增加自身的平台标识；
41.业务请求响应模块，位于所述调用端，用于分别响应所增加平台标识的业务请求，并在所述业务请求异常时增加自身的平台错误码；所述平台标识和所述平台错误码用于生成日志记录；
42.异常响应发送模块，位于所述调用端，用于向所述发起端发送异常响应，以便所述发起端根据所述异常响应基于所查询的日志记录定位与异常响应相应的调用端。
43.本发明实施例还公开了一种电子设备，包括：处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现任一项所述多平台的故障确定方法的步骤。
44.本发明实施例还公开了一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现任一项所述多平台的故障确定方法的步骤。
45.本发明实施例包括以下优点：
46.在本发明实施例中，通过在多平台的多个调用端在转发业务请求时分别增加自身的平台标识，以及在业务请求出现异常时在异常响应中增加自身的平台错误码，基于所增加的平台标识和平台错误码生成的日志记录在发起端接收到异常响应时，能够立即基于对日志记录的查询，判断业务请求所经历的通信节点以及各个调用端节点的响应情况，基于于日志记录跨越中间断层节点初步判定存在异常的节点，以直接与发生异常的节点联系排
查故障，实现对发生异常节点的定位。
附图说明
47.图1是本发明的一种多平台的故障确定方法实施例的步骤流程图；
48.图2是本发明的另一种多平台的故障确定方法实施例的步骤流程图；
49.图3是本发明实施例提供的多平台的故障确定系统的框架示意图；
50.图4是本发明实施例提供的多平台故障确定的应用场景示意图；
51.图5是本发明的一种多平台的故障确定装置实施例的结构框图；
52.图6是本发明的另一种多平台的故障确定装置实施例的结构框图。
具体实施方式
53.为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。
54.通常某个功能可通过跨越多个平台实现，跨越多个平台的实现方式，主要是通过各平台间开放接口实现，但这种跨平台响应的方式将会使得发起端用户无法定位故障节点。具体可表现为当一个请求跨越多个平台时，每个平台所处理的是其中一部分逻辑，当某些平台出现异常逻辑时刻能会向发起端的用户反馈请求失败提示或返回错误码，但对于发起端而言在收到异常响应，例如请求失败提示或错误码后无法知晓异常所发生的平台节点，也无法解析相应节点的错误码。
55.目前，对于发起端的故障识别方式，大多数识别故障发生的网元需要进行逐级查询，具体可以是在发起端接收到异常响应后，需要向位于发起端最近的下游节点进行查询，然后再基于此下游节点向其下游节点查询，确认各级返回的错误码，即一旦上下游跨越多个平台节点，需要调用各个下游节点协助查询日志，方能知晓错误码所来源的平台节点以及对此异常节点进行定位，所花费的时间成本与通信成本较高，发起端对异常定位的效率较低。
56.本发明实施例的核心思想之一在于在多平台的多个调用端在转发业务请求时分别增加自身的平台标识，以及在业务请求出现异常时在异常响应中增加自身的平台错误码，基于所提出的日志记录方法，能够判断业务请求所经历的通信节点以及各个调用端节点的响应情况，对于大型业务实现中需要各平台系统之间调用接口而发生异常的情况下可以实现迅速定位和排查故障，提升异常接口调用的定位效率，降低沟通成本。
57.参照图1，示出了本发明的一种多平台的故障确定方法实施例的步骤流程图，所述多平台涉及到发起端和多个调用端，具体可以包括如下步骤：
58.步骤101，发起端向多个调用端发送针对预设业务的业务请求；
59.在本发明实施例中，在发起端所发送的针对预设业务的业务请求中，所针对的预设业务可以为需要调用多个平台系统的接口实现的大型业务，所发送的业务请求需要转发至用于实现预设业务的多个调用端，以通过各个调用端基于所接收到的业务请求，分别实现针对业务请求所要实现业务的部分逻辑，完成对该大型业务的实现。
60.在实际应用中，业务请求所涉及到的业务需要借助多个调用端实现，某个调用端在接收到业务请求时需要向下一调用端转发业务请求，业务请求的转发可基于接口调用实
现。其中，在多个调用端具有上下游关系，其可具体表现为作为不同层节点的各个调用端，在多个调用端中位于上游的调用端能够具有下游的调用端，对于调用端的上游与下游是相对定义的，例如存在按照层级节点发布的调用端a、b、c，此时调用端b相对调用端c而言为上游的调用端，调用端b相对调用端a而言为下游的调用端。
61.具体的，发起端所发送的业务请求可携带有业务信息和接口请求，所携带的业务信息可以是与所要实现的预设业务相关的信息，例如订单信息、流水信息等，所携带的接口请求可以包括针对基于实现预设业务所需要借助的调用端相应接口的请求，此时发起端在向多个调用端发送业务信息和接口请求时，通常是对位于发起端下游的调用端，即离发起端最近的调用端进行发送，此时该调用端可以在接收到业务请求时，基于接口请求向位于下游的调用端转发业务信息，且在多个调用端中的某个调用端接收到所转发的业务信息后，可以继续基于接口请求向位于其下游的调用端转发业务信息，直至转发至满足业务请求处理要求的平台，即不断转发至完成业务请求所请求业务的全部逻辑的调用端为止。
62.在本发明的一种实施例中，被调用端在转发请求的过程中可分别增加自身的平台标识，首先发起端在发送业务信息时，可以在业务信息前增加自身的平台标识，然后再向位于上游的调用端发送携带有发起端平台标识的业务信息，以使位于上游的调用端在接收到发起端平台标识的业务信息后，能够在发起端平台标识后继续增加自身的平台标识。
63.在基于各个调用端分别实现针对业务请求所要实现业务的部分逻辑时，即在各个调用端对所增加平台标识的业务请求进行响应时，若某个调用端检验所接收到的业务请求为异常请求，则可返回异常响应，并在进行异常响应时还可在针对业务请求的异常响应中增加自身的平台错误码，以便能够基于业务请求中所增加的平台标识，以及在异常响应中所增加的平台错误码生成日志记录，以记录业务请求在多个调用端中的通信情况。
64.其中，所增加的平台标识可用于告知用户业务请求所经历的调用端节点与节点层数，所增加的平台错误码可用于告知用户业务请求在各个调用端的异常反馈。需要说明的是，若某个调用端存在相应的平台标识，但不存在其平台相应的平台错误码，则可表示此调用端节点的响应正常，此时在响应业务请求时无需增加平台错误码，只需将其正常响应反馈给位于上游的调用端平台即可；若某个调用端不存在相应的平台标识且不存在其平台相应的平台错误码，则表示此业务请求并未转发至该调用端进行逻辑处理，此时必然不会存在平台错误码；以及，在最终转发至的调用端出现异常的情况下，并不能够实现针对业务请求所需实现的全部业务逻辑，位于此调用端上游的所有调用端均进行异常响应。
65.步骤102，发起端接收调用端发送的异常响应并根据异常响应进行日志查询，基于所查询的日志记录定位与异常响应相应的调用端。
66.多个调用端在转发业务请求时分别增加自身的平台标识，并在业务请求出现异常时在异常响应中增加自身的平台错误码，在基于所增加的平台标识和平台错误码生成日志记录后，若发起端接收到调用端发送的异常响应，此时可进行日志查询，以基于所查询的日志记录定位与异常响应相应的调用端。
67.具体的，所接收到的异常响应可以表现为请求失败提示或错误码，为了定位异常响应的调用端，此时发起端可根据所接收的异常响应生成日志查询请求，并向多个调用端中位于上游的调用端发送日志查询请求，此时可接收位于上游的调用端响应日志查询请求发送的针对业务请求的日志记录，并可根据日志记录中针对业务请求在多个调用端中的通
信情况定位与异常响应相应的调用端。
68.在具体实现中，所发送的日志查询请求可以是针对所发送业务请求的日志记录获取，所针对业务请求增加的平台标识和在请求异常情况下所增加的平台错误码，均是在保留所接收到的请求数据包和/或响应数据包中所具有标识的基础上继续增加的，此时所获取的针对业务请求的日志记录可基于业务请求在经过各个调用端时所增加的平台标识以及在异常响应时所增加的平台错误码确定，其记录了业务请求在多个调用端中的通信情况，例如此业务请求所经历的调用端节点与节点层数，此业务请求在各个调用端的异常反馈(表现为平台错误码的存在)，那么所发起日志查询请求的用户可基于日志记录中所存在的平台错误码确定最终响应异常的调用端，实现对发生异常节点的定位。
69.在本发明实施例中，通过在多平台的多个调用端在转发业务请求时分别增加自身的平台标识，以及在业务请求出现异常时在异常响应中增加自身的平台错误码，基于所增加的平台标识和平台错误码生成的日志记录在发起端接收到异常响应时，能够立即基于对日志记录的查询，判断业务请求所经历的通信节点以及各个调用端节点的响应情况，基于于日志记录跨越中间断层节点初步判定存在异常的节点，以直接与发生异常的节点联系排查故障，实现对发生异常节点的定位。
70.参照图2，示出了本发明的另一种多平台的故障确定方法实施例的步骤流程图，所述多平台涉及到发起端和多个调用端，具体可以包括如下步骤：
71.步骤201，多个调用端接收并转发发起端发送的针对预设业务的业务请求，并在所转发的业务请求中分别增加自身的平台标识；
72.在本发明实施例中，在发起端所发送的针对预设业务的业务请求中，所针对的预设业务可以为需要调用多个平台系统的接口实现的大型业务，所发送的业务请求需要转发至用于实现预设业务的多个调用端，以通过各个调用端基于所接收到的业务请求，分别实现针对业务请求所要实现业务的部分逻辑，完成对该大型业务的实现。
73.在实际应用中，业务请求所涉及到的业务需要借助多个调用端实现，某个调用端在接收到业务请求时需要向下一调用端转发业务请求，业务请求的转发可基于接口调用实现。具体的，调用端所接收到的业务请求可携带有业务信息和接口请求，发起端在向多个调用端发送业务信息和接口请求时，通常是对位于发起端下游的调用端，此时离发起端最近的调用端在接收到发起端发送的业务信息和接口请求后，可基于所接收的接口请求向位于该调用端下游的另一调用端转发业务信息，且在多个调用端中的某个调用端接收到所转发的业务信息后，可以继续基于接口请求向位于其下游的调用端转发业务信息，直至转发至满足业务请求处理要求的平台，即不断转发至完成业务请求所请求业务的全部逻辑的调用端为止。
74.在本发明的一种实施例中，发起端所发送的业务信息前可增加有针对发起端的平台标识，表示此业务请求是基于此发起端，例如平台a的用户发起的业务请求，以便在发请求入参异常时被调用端可基于所增加的平台标识确定发起端的具体平台，此时多个调用端中位于上游的调用端可基于发起端的平台标识，在发起端的平台标识后继续增加自身的平台标识，向位于下游的调用端转发携带有发起端的平台标识以及所增加的自身平台标识的业务信息，而位于下游的调用端在接收到所转发的业务信息后，还可以在业务信息中所具有的平台标识后继续增加自身的平台标识，继续向位于下游的调用端发送携带有发起端的
平台标识以及至少两个调用端平台标识的业务信息。
75.其中，所增加的平台标识可用于告知用户业务请求所经历的调用端节点与节点层数。
76.在实际应用中，多个调用端中的某个调用端在接收到所转发的业务请求后，所接收到的业务请求可以是以数据包的形式发送的，其可以包括先前平台所增加的平台标识以及其他报文信息，其他报文信息可以包括与所要实现的预设业务相关的业务信息和接口信息，与所要实现的预设业务相关的业务信息可以指的是订单信息、流水信息等，那么在调用端在继续向下游，即位于其下层级的调用端转发业务请求时，此时可重新对所要转发的数据包进行封装，具体为在已具有的平台标识后再增加其自身的平台标识，然后再进行封装，即在保留所接收到的请求数据包中所具有标识的基础上继续增加平台标识，以便后续在日志记录中可基于所记录的平台标识得知业务请求所经历的调用端节点与节点层数。
77.步骤202，多个调用端分别响应所增加平台标识的业务请求，并在业务请求异常时增加自身的平台错误码；
78.在将业务请求不断转发至完成业务请求所请求业务的全部逻辑的调用端后，在基于各个调用端分别实现针对业务请求所要实现业务的部分逻辑时，即在各个调用端对所增加平台标识的业务请求进行响应时，若某个调用端检验所接收到的业务请求为异常请求，则可返回异常响应，并在进行异常响应时还可在针对业务请求的异常响应中增加自身的平台错误码。
79.其中，所增加的平台错误码可用于告知用户业务请求在各个调用端的异常反馈。具体的，多个调用端中的某一调用端在响应增加有调用端平台标识的业务请求，可以在业务请求异常时在异常响应中增加自身的平台错误码，并向位于上游的调用端发送携带有自身平台错误码的异常响应，调用端在接收到位于下游的调用端发送的异常响应后，可以在异常响应中所具有的平台错误码后继续增加自身的平台错误码，继续向位于上游的调用端发送携带有平台错误码的异常响应，直至向位于上游的发起端发送异常响应为止。
80.在实际应用中，以所接收到的异常响应情况为例，多个调用端中的某个调用端在接收到位于下游的调用端所发送的异常响应后，所接收到的异常响应可以是以数据包的形式发送的，其可包括原始标识以及先前平台所增加的平台错误码，那么在调用端向位于上游的调用端继续反馈异常响应时，可对所接收到的异常响应数据包重新进行封装，具体为在已具有的平台错误码后再增加自身的平台错误码，然后再进行封装，即在保留所接收到的响应数据包中所具有标识的基础上继续增加平台错误码，以便在日志记录中可基于所记录的平台错误码得知业务请求在各个调用端的异常反馈。
81.需要说明的是，若某个调用端存在相应的平台标识，但不存在其平台相应的平台错误码，则可表示此调用端节点的响应正常，此时在响应业务请求时无需增加平台错误码，只需将其正常响应反馈给位于上游的调用端平台即可；若某个调用端不存在相应的平台标识且不存在其平台相应的平台错误码，则表示此业务请求并未转发至该调用端进行逻辑处理，此时必然不会存在平台错误码；以及，在最终转发至的调用端出现异常的情况下，并不能够实现针对业务请求所需实现的全部业务逻辑，位于此调用端上游的所有调用端均进行异常响应。
82.步骤203，多个调用端向发起端发送异常响应，以便发起端根据异常响应基于所查
询的日志记录定位与异常响应相应的调用端。
83.在本发明实施例中，能够基于业务请求中所增加的平台标识，以及在异常响应中所增加的平台错误码生成日志记录，以记录业务请求在多个调用端中的通信情况。
84.在多个调用端中确认业务请求存在异常时可生成异常响应，例如请求失败提示或错误码等，以告知用户其所请求的业务逻辑并未实现，此时发起端可根据所接收的异常响应生成日志查询请求，并向多个调用端中位于上游的调用端发送日志查询请求，此时可接收位于上游的调用端响应日志查询请求发送的针对业务请求的日志记录，并可根据日志记录中针对业务请求在多个调用端中的通信情况定位与异常响应相应的调用端。
85.其中，在基于平台标识与平台错误码生成日志记录的情况下，还可以对请求的转发时间和/或具体响应时间进行记录，以便能够允许上下游节点对日志和响应时间日志进行查询，便于更精确地的定位和请求反馈的总时长统计。
86.在一种优选的实施例中，除了发起端能够根据异常响应基于所查询的日志记录定位与异常响应相应的调用端，实现对异常节点的定位以外，还可以对各个平台开放日志查询接口，当发起端入参异常，即存在异常请求的情况下，此时各个被调用端均可发送日志查询请求，以基于日志记录中的平台标识确定发起端的具体平台位置。
87.需要说明的是，针对多平台业务处理中的异常响应与异常请求，在存在异常请求时必然存在异常响应，但在不存在异常请求时不一样不存在异常响应，即即便在发起端的入参正常的情况下也可能存在异常响应。对此，本发明实施例不加以限制。
88.在本发明实施例中，通过在多平台的多个调用端在转发业务请求时分别增加自身的平台标识，以及在业务请求出现异常时在异常响应中增加自身的平台错误码，基于所增加的平台标识和平台错误码生成的日志记录在发起端接收到异常响应时，能够立即基于对日志记录的查询，判断业务请求所经历的通信节点以及各个调用端节点的响应情况，基于于日志记录跨越中间断层节点初步判定存在异常的节点，以直接与发生异常的节点联系排查故障，实现对发生异常节点的定位。
89.参照图3，示出了本发明实施例提供的多平台的故障确定系统的框架示意图，多平台涉及到发起端和多个调用端，针对多平台的故障确定系统可以包括发起端11和多个调用端12。
90.本发明实施例中，在多平台的多个调用端12在转发业务请求时可以分别增加自身的平台标识，以及在业务请求出现异常时在异常响应中可以增加自身的平台错误码，此时可基于所增加的平台标识和平台错误码生成的日志记录，在发起端11接收到异常响应的情况下，能够基于所生成的日志记录对所发生异常的具体节点进行确定，以及能够在调用端12在收到异常请求，即发起端11所发送的业务请求出现异常的情况下，基于所生成的日志记录对入参异常的发起端11的具体平台位置进行确定。
91.在具体实现中，发起端11可用于向多个调用端发送针对预设业务的业务请求，调用端12可用于接收并转发所述发起端发送的针对预设业务的业务请求，并在所转发的业务请求中分别增加自身的平台标识，此时调用端12还可以用于分别响应所增加平台标识的业务请求，并在业务请求异常时增加自身的平台错误码，以及向发起端发送异常响应，发起端11在接收调用端发送的异常响应时可根据异常响应进行日志查询，基于所查询的日志记录定位与异常响应相应的调用端，完成对异常节点的定位。
92.示例性地，多平台故障的确定的应用场景可以为电子渠道订单在需要跨越多个平台系统完成业务逻辑的场景，其中，当订单在经过多个平台时在某个平台出现业务层面的报错信息，但未影响订单流转时，发起端难以定位报错信息发生在哪个平台及解析报错信息产生的原因，以及，发起端系统跨越多个系统调用到某个下游系统，在下游系统发现发起端入参存在大量异常时，难以确定发起端的具体平台系统。
93.在电子渠道订单的应用场景中，目前全渠道线上业务的订单需要经过电渠前端、中台、底层、eop、ess、4g、省等n层平台调用(充值还涉及翼支付和集团计费)，其中任何一个平台的异常或失败，都会涉及故障排查，目前主要靠各个平台接口人对接的方式，在业务量较大的时候，很难保证各层平台的接口人都能配备齐全，这样很容易出现排障瓶颈。
94.如图4所示，假设所涉及到的平台a、平台b、平台c以及平台d可以分别为线上业务的订单所需经过的平台系统，其中，平台a可以是作为发起端的电渠前段，平台b、平台c以及平台d均可以是用于实现订单请求所请求订单逻辑的各个调用端，例如底层、eop、ess、4g、省等。
95.其针对电子渠道订单场景下，跨越多个平台的实现方式主要是通过各平台间开放接口实现。
96.对于请求方面，可进行逐级带各平台标识，具体可以为发起端，例如平台a可以在主要业务信息前增加平台标识信息，例如“a-标识id”，当消息到达下游平台时，下游平台可以在保留上游平台标识信息的同时再增加本层平台标识信息，按照如图4所示的平台a-平台b-平台c-平台d的请求转发顺序，逐层增加自身的平台标识信息，直至转发至最后一层的平台，即不断转发至完成业务请求所请求业务的全部逻辑的调用端为止，形成完整的平台标识调用链。其中，每个接口请求从上游平台到下游平台，在经过每层平台后均可在请求中携带有平台标识，例如在经过平台b时所携带的平台标识信息可以为“a-标识id”与“b-标识id”，在经过平台c时所携带的平台标识信息可以为“a-标识id”、“b-标识id”与“c-标识id”等，在请求中还可以携带有其他报文信息，即主要的业务信息，例如平台信息、订单信息、流水信息以及时间，如图4所示，在请求每经过一个平台时均需对请求的数据包重新进行一次封装。
97.对于响应方面，可逐级带各平台错误码，具体可以在最后一层的平台处理完自身的逻辑，即完成请求所请求业务的全部逻辑后，向位于上游的平台反馈相应内容的响应。在本发明实施例中，以最终转发至的调用端出现异常的情况为例，主要可以在保留请求的原始标识信息，即在转发至最后一层平台时所增加的平台标识，例如“a-标识id”、“b-标识id”、“c-标识id”以及“d-标识id”的基础上增加本层的错误码“d-错误码”，再向上游平台传递，此时位于上游的每层平台在接收到异常响应时均可增加自身的返回码(错误码)然后再向上游的平台进行传递，例如平台c接收平台d的异常响应，此时平台c在向上游平台b传递携带有错误码的异常响应可以为在原始标识信息和平台d错误码“d-错误码”的基础上，增加其自身的平台错误码“b-标识id”，直至将异常响应发送至发起端平台为止形成闭环。其中，在任意一层平台的处理正常时可及时传递给下游，当存在异常时需要标注本平台自身的错误码，然后反馈给上游平台，在上游平台判断所反馈的响应为异常时，可以对异常响应中原本具有的错误码，并新增本平台自身的错误码进行封装后，将封装后的响应包再传递给上游平台。
98.在后续所进行的日志查询中，可对各个平台，包括发起端以及各个调用端开放日志查询接口，使得任意一层的人员在收到接口报文时，可基于对日志的查询分析出调用源，在保证最上游的发起端接收到异常响应后，可准确定位到异常节点所在位置，以允许上下游对日志和响应时间日志查询，便于对异常节点定位的精确度和请求响应总时长的统计，例如各层平台对接口处理时长的统计，以及还可以便于各层平台根据错误码分析上下游失败率。
99.需要说明的是，基于本发明实施例所提出的多平台故障确定方式，需要略微改造升级各级系统，实现按统一标准规范增加平台标识和响应信息，且需要各级系统开放接口，以提供给其他上下游进行日志查询，对此，本发明实施例不加以限制。
100.在本发明实施例中，通过在多平台的多个调用端在转发业务请求时分别增加自身的平台标识，以及在业务请求出现异常时在异常响应中增加自身的平台错误码，基于所增加的平台标识和平台错误码生成的日志记录在发起端接收到异常响应时，能够立即基于对日志记录的查询，判断业务请求所经历的通信节点以及各个调用端节点的响应情况，基于于日志记录跨越中间断层节点初步判定存在异常的节点，以直接与发生异常的节点联系排查故障，实现对发生异常节点的定位。
101.需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。
102.参照图5，示出了本发明的一种多平台的故障确定装置实施例的结构框图，所述多平台涉及到发起端和多个调用端，具体可以包括如下模块：
103.业务请求发送模块501，位于所述发起端，用于向多个调用端发送针对预设业务的业务请求，所述业务请求用于在所述多个调用端转发所述业务请求时分别增加自身的平台标识，以及在所述多个调用端对所增加平台标识的业务请求进行异常响应时增加自身的平台错误码，所述平台标识和所述平台错误码用于生成日志记录；
104.日志查询模块502，位于所述发起端，用于接收调用端发送的异常响应并根据所述异常响应进行日志查询，基于所查询的日志记录定位与异常响应相应的调用端。
105.在本发明的一种实施例中，所述业务请求携带有业务信息和接口请求，所述多个调用端具有上下游关系，所述多个调用端中位于上游的调用端具有下游的调用端；业务请求发送模块501可以包括如下子模块：
106.业务请求发送子模块，用于向多个调用端发送所述业务信息和接口请求，以使在多个调用端中的某个调用端接收所述业务请求时，基于所述接口请求向位于下游的调用端转发所述业务信息。
107.在本发明的一种实施例中，业务请求发送子模块可以包括如下单元：
108.业务信息发送单元，用于在发送所述业务信息时在所述业务信息前增加自身的平台标识，向位于上游的调用端发送携带有发起端平台标识的业务信息，以使位于上游的调用端在接收到所述发起端平台标识的业务信息后，在所述发起端平台标识后继续增加自身的平台标识。
109.在本发明的一种实施例中，日志查询模块502可以包括如下子模块：
110.日志查询请求发送子模块，用于根据所接收的异常响应生成日志查询请求，并向所述多个调用端中位于上游的调用端发送日志查询请求；
111.日志记录接收子模块，用于接收所述位于上游的调用端响应所述日志查询请求发送的针对所述业务请求的日志记录；所述日志记录包括所述业务请求在所述多个调用端中的通信情况，所述通信情况基于所述业务请求在经过各个调用端时所增加的平台标识以及在异常响应时所增加的平台错误码确定；
112.异常定位子模块，用于根据所述日志记录中针对业务请求在所述多个调用端中的通信情况定位与异常响应相应的调用端。
113.参照图6，示出了本发明的另一种多平台的故障确定装置实施例的结构框图，所述多平台涉及到发起端和多个调用端，具体可以包括如下模块：
114.业务请求转发模块601，位于所述调用端，用于接收并转发所述发起端发送的针对预设业务的业务请求，并在所转发的业务请求中分别增加自身的平台标识；
115.业务请求响应模块602，位于所述调用端，用于分别响应所增加平台标识的业务请求，并在所述业务请求异常时增加自身的平台错误码；所述平台标识和所述平台错误码用于生成日志记录；
116.异常响应发送模块603，位于所述调用端，用于向所述发起端发送异常响应，以便所述发起端根据所述异常响应基于所查询的日志记录定位与异常响应相应的调用端。
117.在本发明的一种实施例中，所述业务请求携带有业务信息和接口请求，所述多个调用端具有上下游关系，所述多个调用端中位于上游的调用端具有下游的调用端；业务请求转发模块601可以包括如下子模块：
118.业务请求转发子模块，用于接收所述发起端发送的业务信息和接口请求，基于所述接口请求向位于该调用端下游的另一调用端转发所述业务信息。
119.在本发明的一种实施例中，所述发起端发送的业务信息前增加有所述发起端的平台标识，业务请求转发模块601可以包括如下子模块：
120.第一平台标识增加子模块，用于基于所述发起端的平台标识，在所述发起端的平台标识后继续增加自身的平台标识，向位于下游的调用端转发携带有所述发起端的平台标识以及所增加的自身平台标识的业务信息；
121.第二平台标识增加子模块，用于在所述业务信息中所具有的平台标识后继续增加自身的平台标识，继续向位于下游的调用端发送携带有所述发起端的平台标识以及至少两个调用端平台标识的业务信息。
122.在本发明的一种实施例中，业务请求响应模块602可以包括如下子模块：
123.第一平台错误码增加子模块，用于响应增加有调用端平台标识的业务请求，在所述业务请求异常时增加自身的平台错误码，并向位于上游的调用端发送携带有自身平台错误码的异常响应；
124.异常响应发送模块603可以包括如下子模块：
125.第二平台错误码增加子模块，用于在接收到位于下游的调用端发送的异常响应后，在所述异常响应中所具有的平台错误码后继续增加自身的平台错误码，继续向位于上游的调用端发送携带有平台错误码的异常响应，直至向位于上游的发起端发送异常响应为
止。
126.对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
127.本发明实施例还提供了一种电子设备，包括：
128.包括处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，该计算机程序被处理器执行时实现上述多平台的故障确定方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
129.本发明实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储计算机程序，计算机程序被处理器执行时实现上述多平台的故障确定方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
130.本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
131.本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
132.本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
133.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
134.这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
135.尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。
136.最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包
括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
137.以上对本发明所提供的多平台的故障确定方法、系统、电子设备及介质，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。