一种面向分布式系统的故障信息关联上报方法及相关设备与流程

1.本技术涉及计算机研究领域，尤其涉及一种面向分布式系统的故障信息关联上报方法及相关设备。


背景技术：

2.为满足日益增大的业务量的需求，应对大规模的应用场景，分布式系统应用的越来越广泛。分布式系统可靠性高、可扩展性好、通信快捷，同时能更方便地实现用户间的资源共享，但是由于分布式系统中的分布式业务所涉及到的设备规模庞大，设备间的调用和设备内模块间的调用错综复杂，导致出现故障时难以对故障进行定位。
3.现有的故障定位方法中，首先通过trace id埋点来跟踪各设备间的调用，在出现故障后根据出现异常的业务的trace id进行全局索引，然后再进行分析定位。在上述过程中，故障设备单端感知，这就意味着，当出现故障时，只有故障设备会上报故障信息，其它参与处理该异常业务的设备可能并不会上报故障相关信息，因此，服务器获取到的与故障相关的信息非常有限，不利于后续故障定位分析。另外，该故障定位方法会采集大量正常的业务流程数据，所采集的正常业务流程数据大概率与故障无关，会带来不必要的数据存储成本和分析成本，再者，当业务量增大时，采集的数据量增多，很可能出现重复的trace id，此时分析难度也会增加。
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.第七方面，提供了计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，当该计算机程序被处理器执行时，可以实现上述第一方面以及结合上述第一方面中的任意一种实现方式所提供的面向分布式系统的故障信息关联上报方法的功能。
48.第八方面，提供了计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，当该计算机程序被处理器执行时，可以实现上述第二方面以及结合上述第二方面中的任意一种实现方式所提供的面向分布式系统的故障信息关联上报方法的功能。
49.第九方面，本技术提供了一种计算机程序产品，该计算机程序包括指令，当该计算机程序被计算机执行时，使得计算机可以执行上述第一方面以及结合上述第一方面中的任意一种实现方式所提供的面向分布式系统的故障信息关联上报方法的流程。
50.第十方面，本技术提供了一种计算机程序产品，该计算机程序包括指令，当该计算
机程序被计算机执行时，使得计算机可以执行上述第二方面以及结合上述第二方面中的任意一种实现方式所提供的面向分布式系统的故障信息关联上报方法的流程。
51.第十一方面，本技术提供了一种芯片系统，该芯片系统包括处理器，用于支持第一设备实现上述第一方面中所涉及的功能。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存数据发送设备必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。
52.第十二方面，本技术提供了一种芯片系统，该芯片系统包括处理器，用于支持第二设备实现上述第二方面中所涉及的功能。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存数据发送设备必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。
53.可以理解地，上述提供的第三方面提供的第一设备、第五方面提供的一种计算设备、第七方面提供的一种计算机可读存储介质、第九方面提供的一种计算机程序产品，以及第十一方面提供的芯片系统均用于执行第一方面所提供的面向分布式系统的故障信息关联上报方法。因此，其所能达到的有益效果可参考第一方面所提供的面向分布式系统的故障信息关联上报方法中的有益效果，此处不再赘述。
54.可以理解地，上述提供的第四方面提供的第二设备、第六方面提供的一种计算设备、第八方面提供的一种计算机可读存储介质、第十方面提供的一种计算机程序产品，以及第十二方面提供的芯片系统均用于执行第二方面所提供的面向分布式系统的故障信息关联上报方法。因此，其所能达到的有益效果可参考第二方面所提供的面向分布式系统的故障信息关联上报方法中的有益效果，此处不再赘述。
附图说明
55.图1为本技术实施例提供的一种面向分布式系统的故障信息关联上报方法的系统架构的示意图；
56.图2为本技术实施例提供的另一种面向分布式系统的故障信息关联上报方法的系统架构的示意图；
57.图3为本技术实施例提供的一种面向分布式系统的故障信息关联上报方法的流程示意图；
58.图4为本技术实施例提供的一种调用关系缓存的示意图；
59.图5为本技术实施例提供的另一种调用关系缓存的示意图；
60.图6为本技术实施例提供的一种远程调用的示意图；
61.图7为本技术实施例提供的一种关联失败事件的缓存机制的示意图；
62.图8为本技术实施例提供的一种关联失败事件的缓存处理流程示意图；
63.图9为本技术实施例提供的一种第一设备的结构示意图；
64.图10为本技术实施例提供的一种第二设备的结构示意图；
65.图11为本技术实施例提供的一种计算设备的结构示意图；
66.图12为本技术实施例提供的另一种计算设备的结构示意图。
具体实施方式
67.下面结合附图对本技术实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例仅仅是本技术的一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
68.首先，结合附图对本技术中所涉及的部分用语和相关技术进行解释说明，以便于本领域技术人员理解。
69.分布式系统(distributed system)是建立在网络之上的软件系统。在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。系统拥有多种通用的物理和逻辑资源，可以动态的分配任务，分散的物理和逻辑资源通过计算机网络实现信息交换。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件(middle ware)负责实现这个模型。
70.埋点是数据采集领域(尤其是用户行为数据采集领域)的术语，指的是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。埋点的技术实质，是先监听软件应用运行过程中的事件，当需要关注的事件发生时进行判断和捕获。埋点包括代码埋点、可视化埋点和无埋点。其中，代码埋点通过加入一些代码使得用户触发相应行为时，进行数据上报；可视化埋点利用了可视化交互手段，先配置相关事件，再进行数据采集；无埋点是指开发人员集成采集软件开发工具包(software development kit，sdk)后，sdk便直接开始捕捉和监测用户在应用里的所有行为，并全部上报，不需要开发人员添加额外代码。需要说明的是，在本技术实施例中，埋点与用户行为无关，只与业务流上的故障相关。
71.远程过程调用(remote procedure call，rpc)的出现主要是为了解决分布式系统间的通信透明性的问题。也就意味着，rpc让用户不用理会调用的是哪个设备上的服务，在用户的角度，这个远程服务和调用本地服务一样安全可靠。远程调用一般涉及四个过程：客户端发送(client send，cs)、服务端接收(service receive，sr)、服务端发送(service send，ss)和客户端接收(client receive，cr)。
72.通用唯一识别码(universally unique identifier，uuid)是一种软件建构的标准，亦为开放软件基金会组织在分布式计算环境领域的一部分，目前最广泛应用的uuid是微软的microsoft's globally unique identifiers(guids)。uuid的目的是让分布式系统中的所有元素，都能有唯一的辨识资讯，而不需要透过中央控制端来做辨识资讯的指定。如此一来，每个元素都可以建立不与其它元素冲突的uuid。在这样的情况下，就不需考虑数据库建立时的名称重复问题。uuid是指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。通常平台会提供生成的应用程序编程接口(application programming interface,api)。按照开放软件基金会(osf)制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片id码和许多可能的数字。
73.uuid由以下几部分组成：
74.(1)当前日期和时间，uuid的第一个部分与时间有关，如果你在生成一个uuid之后，过几秒又生成一个uuid，则第一个部分不同，其余相同。
75.(2)时钟序列。
76.(3)全局唯一的ieee机器识别号。
77.事件id(event id)是一个数字，表示错误信息，即阻碍业务继续进行的原因，不同的event id表示的错误信息不同，根据event id可以大概知道故障模块、故障影响、甚至根因，进而解决问题。
78.故障日志，即错误日志，是软件用来记录运行时出错信息的文本文件。编程人员和维护人员等可以利用错误日志对系统进行调试和维护。
79.open api即开放api，也称开放平台。所谓的开放api(open api)是服务型网站常见的一种应用，网站的服务商将自己的网站服务封装成一系列应用编程接口(application programming interface，api)开放出去，供第三方开发者使用，这种行为就叫做开放网站的api，所开放的api就被称作open api(开放api)。
80.为了便于理解本技术实施例，首先对本技术实施例基于的一种面向分布式系统的故障信息上报系统架构进行描述。如图1所示，图1是本技术实施例提供的一种故障信息上报系统架构，包括至少一个服务器、至少一个设备。图1中以包括多个服务器和多个设备为例进行说明。其中，设备a、b、c、d、e是用户发起的某个分布式业务流程所涉及到的设备，该分布式业务中有4对rpc调用，分别发生在设备a与设备b之间、设备b与设备c之间、设备c与设备d之间以及设备d与设备e之间。在设备a、b、c、d、e处理该分布式业务的过程中有设备出现故障，导致该分布式业务出现异常，那么出现故障的设备会向服务器上报其故障信息。
81.需要说明的是，分布式业务包括但不限于无线端请求、网页请求、open api请求。以网页请求为例，当用户在某个网页上进行点击操作时，可能涉及到该网页对其它设备(如子服务器)的调用，还可能涉及与其他应用收、发消息的操作，即涉及消息服务，还可能涉及到分布式数据库的查询与更新、分布式缓存的读缓存与写缓存、分布式对象的存储等。
82.另外，分布式业务还包括智能终端与周边设备协同场景下的一些操作，比如协同传输文件，这意味着本技术可应用于大屏投屏、pc协同、pad协同、智能穿戴等近场分布式协同场景。
83.在分布式系统中，设备间的调用错综复杂，往往一个设备可能会被多个设备调用。如图2所示，图2是本技术实施例提供的另一种故障信息上报的系统架构。设备a、c、d、f、h是用户发起的一个分布式业务所涉及到的设备，该分布式业务中有6对rpc调用，分别发生在设备a与设备c之间、设备a与设备d之间、设备c与设备d之间、设备c与设备f之间、设备c与设备h之间以及设备d与设备h之间。在设备a、c、d、f、h处理该分布式业务的过程中有设备出现故障，导致该分布式业务出现异常，那么出现故障的设备会向服务器上报其故障信息。
84.可理解，图1和图2中的设备包括但不限于服务器、路由器、交换机、网关，以及手机、电脑、平板等终端设备。
85.另外，上述图1和图2中的服务器可以是普通服务器(也可以叫做物理服务器)，它们是可以放在机房来运行的真实存在的物理设备，普通服务器有独立的硬盘、带宽等；也可以是普通服务器经过不同程度的虚拟化之后产生的服务器，这一类服务器的一部分已经虚拟化了，可能只有一部分是真实的物理设备；还可以是云服务器，即指云服务提供商拥有的，用于提供计算、存储、通信资源的中心计算设备集群，云服务器是具有高度分布式、高度虚拟化等特点的一类服务器，其计算资源是从大量经过整合虚拟化的物理服务器中调度获取的，从节点规模看，这样的虚拟化规模可能是几台、数十台、数百台物理服务器，也可能是跨数据中心的成千上万台实体硬件构建起来的大型云端虚拟资源池，因此，云服务器支持
资源的弹性调，这意味着我们可以自由地增加或缩减cpu、内存、磁盘、带宽等资源，同时也具有良好的可扩展性、高可靠性。
86.可理解，图1和图2所示的故障信息上报的系统架构只是本技术实施例的两种示例性的实施方式，本技术实施例中的故障信息上报的系统架构包括但不仅限于以上结构。
87.为了避免采集大量正常的业务流程数据，减少数据存储及分析成本，同时尽可能收集更多的与故障相关的信息，提高故障定位的精度，本技术提供了一种面向分布式系统的故障信息关联上报方法，该方法可以在故障发生时，让发生故障的设备不仅上报自己的故障相关信息，而且还通知对端设备上报故障信息，使得服务器在进行故障定位时有更多故障相关信息可以利用，这种故障信息上报方法提高了故障定位的效率。
88.下面具体参见图3示出的本技术实施例提供的一种面向分布式系统的故障信息关联上报方法的流程示意图，对本技术实施例的面向分布式系统的故障信息关联上报方法进行说明。如图3所示，该方法可以包括以下步骤：
89.s310：第一设备缓存第一调用关系。
90.具体地，当用户发起一个或多个分布式业务，其中针对每个发起的分布式业务流程都可以涉及至少一个设备，且设备间存在调用关系。如下表1：
[0091][0092][0093]
表1
[0094]
另外，涉及处理分布式业务的每个设备都可以缓存自身的调用关系。例如，本技术实施例中的第一设备和第二设备是涉及处理用户发起的一个或多个分布式业务的设备。第一设备缓存第一调用关系，第二设备缓存第二调用关系。如下表2：
[0095][0096]
表2
[0097]
可选的，第一设备可以是图1和图2所示的面向分布式系统的故障信息上报的系统架构中的任意一个设备，比如第一设备可以是图1中的设备a，此时，第二设备是图1中的设备b；第一设备可以是图2中的设备c，此时，第二设备是图2中的设备a、设备b和设备c。
[0098]
如表2所示，第一调用关系包括第一设备参与处理的分布式业务的设备调用信息，该设备调用信息是指第一设备参与处理的分布式业务中与第一设备有关的调用信息，即第一设备调用其它设备的信息和第一设备被其它设备调用的信息。
[0099]
需要说明的是，在本技术的一个实施例中，所述第一设备参与处理的一个或多个分布式业务的设备调用信息可以包括第一设备的对端类型、所述分布式业务的业务类型、所述分布式业务中与第一设备相关的通信信息、时间戳。其中，对端类型包括对端设备的uuid、对端设备类型，所述对端设备是指在所述分布式业务中第一设备所调用的设备或者调用第一设备的设备，所述对端设备类型包括但不限于终端、服务器、路由器、软件和/或硬件系统内的模块；业务类型包括但不限于：固定通信业务、蜂窝移动通信业务、第一类卫星通信业务、第一类数据通信业务等第一类基础电信业务，集群通信业务、无线寻呼业务、第二类卫星通信业务、第二类数据通信业务、网络接入业务、国内通信设施服务业务、网络托管业务等第二类基础电信业务，第一类增值电信业务、第二类增值电信业务等增值电信业务；通信信息包括但不限于第一设备作为调用方时和被调用方设备间的通信信息、该分布式业务设备作为被调用方时和调用设备间的通信信息；时间戳包括但不限于第一设备作为调用方设备时的调用时间和作为被调用方设备时的被调用时间。
[0100]
另外，可以将所述第一调用关系根据业务的生命周期分为至少两种状态，然后将
所述不同状态的第一调用关系分开缓存，其中，不同状态的第一调用关系对应的业务的生命周期不同。
[0101]
在本技术的一个实施例中，可以根据业务的生命周期将第一调用关系分为冷状态、温状态和热状态，然后将被标记为冷状态、温状态和热状态的第一调用关系分开缓存。具体地，当业务的生命周期小于或等于第一阈值时，将所述第一调用关系标记为热状态；当业务的生命周期大于第一阈值且小于或等于第二阈值时，将所述第一调用关系标记为温状态；当业务的生命周期大于第二阈值时，将所述第一调用关系标记为冷状态。上述三种状态的第一调用关系将分别缓存在三个区域，互不影响。
[0102]
可理解，第一阈值和第二阈值由研发人员根据实际情况进行设置，本技术中对此不作限定。
[0103]
示例性的，设置第一阈值为3分钟，设置第二阈值为4小时，若将手机屏幕投到pc屏幕上这一投屏操作维持3小时的时候，手机和pc间的调用关系被标记为温状态；若一次蓝牙设备匹配维持了5个小时才解绑，那么该蓝牙设备间调用关系被标记为冷状态。
[0104]
在本技术的另一个实施例中，可以根据业务的生命周期将第一调用关系分为第一状态、第二状态、第三状态和第四状态，然后将被标记为第一状态、第二状态、第三状态和第四状态的第一调用关系分开缓存。具体地，当业务的生命周期小于或等于第三阈值时，将所述第一调用关系标记为第一状态；当业务的生命周期大于或等于第四阈值且小于或等于第五阈值时，将所述第一调用关系标记为第二状态；当业务的生命周期大于或等于第六阈值且小于或等于第七阈值时时，将所述第一调用关系标记为第三状态；当业务的生命周期大于或等于第八阈值时，将所述第一调用关系标记为第四状态。上述四种状态的第一调用关系将分别缓存在三个区域，互不影响。
[0105]
可理解，第四阈值大于第三阈值，第五阈值大于或等于第四阈值，第六阈值大于第五阈值，第七阈值大于或等于第六阈值，第八阈值大于第七阈值。另外，第三阈值、第四阈值、第五阈值、第六阈值、第七阈值和第八阈值可由研发人员根据实际情况进行设置，本技术中对其具体数值不作限定。
[0106]
示例性的，设置第四阈值和第五阈值都为2小时，当且仅当业务的生命周期为2小时的时候，该业务涉及到的设备调用关系被标记为第二状态。
[0107]
s320：第一设备处理第一分布式业务发生故障时，上报第一故障信息到服务器。
[0108]
具体地，当第一设备在处理第一分布式业务发生故障时，会生成第一故障信息，并将第一故障信息上报到服务器。
[0109]
需要说明的是，在本技术的一个实施例中，所述第一故障信息包括第一故障事件和第一故障日志。其中，第一故障事件包括故障设备(即第一设备)的设备类型、event id、故障时间、故障模块、异常类型，所述设备类型包括但不限于终端、服务器、路由器、软件和/或硬件系统内的模块，所述故障模块是指第一设备中发生故障的模块，该模块可以是硬件模块，也可以是软件模块，所述异常类型是指第一设备发生故障的类型，可以是无响应、卡顿、协商失败、超时等；第一故障日志是指第一设备与故障相关的日志。
[0110]
s330：第一设备从第一调用关系中查找第二设备。
[0111]
具体地，由上文可知，第一设备缓存有第一调用关系，而第一调用关系包括第一设备参与处理的分布式业务的设备调用信息，因此可以通过第一调用关系来查找第二设备，
所述第二设备包括执行所述第一分布式业务时调用所述第一设备或被所述第一设备调用的设备。
[0112]
在本技术的一个实施例中，可以通过给每个分布式业务分配一个标识来达到查找对端设备的目的。
[0113]
需要说明的是，标识可以缓存在第一设备中的第一调用关系里，具体地，如图4所示，图4是一种缓存分布式业务的设备调用关系的示意图，由图4可看出，可以将标识作为关键字索引来缓存分布式业务的设备调用信息，即将标识作为区分不同分布式业务的标识，并分别缓存不同分布式业务的设备调用信息，这就意味着，若要查找某个分布式业务的设备调用信息，可以通过检索该分布式业务的标识，进而得到缓存的该分布式业务的设备调用信息。可选的，如图5所示，图5是另一种缓存分布式业务的设备调用关系的示意图，由图5可看出，还可以将同一分布式业务的标识与其设备调用信息一起存储，并且不同分布式业务的标识和其设备调用信息会放在不同的缓存空间里，不同的分布式业务的标识及其设备调用信息会分开存储，这意味着，需要查找某个分布式业务的设备调用关系时，需要逐个查看，直至找到该分布式业务对应的标识所在的缓存空间，从而找到该分布式业务的设备调用信息。
[0114]
当采取给每个分布式业务分配一个标识这种方式后，第一调用关系就会包括用户发起的一个或多个分布式业务的标识，还包括对端设备的uuid，而当第一设备在处理第一分布式业务发生故障时，会生成第一故障信息，该第一故障信息中不仅如上文所述包括第一故障事件和第一故障日志，还应包括与第一分布式业务对应的第一标识，因此第一设备可以通过查找第一标识，在第一调用关系中找到第一设备调用信息，所述第一设备调用信息为所述第一调用关系中所述第一分布式业务的设备调用信息，从而找到第一设备的对端设备的uuid及通信信息，即找到第二设备的uuid及第一设备与第二设备之间的通信信息。
[0115]
需要说明的是，在本技术的一个实施例中，可以采取对分布式系统中间件埋点的方式来获取标识，同时也可以获取到设备的调用关系，这是因为通过对分布式系统中的中间件进行埋点，可以在分布式业务发生的过程中跟踪业务流程，使得参与不同分布式业务的设备中，与所述不同业务相关的日志记录可以和不同的标识相关联，同时也可以获取该分布式业务涉及的设备的uuid、分支信息、设备类型等设备信息及设备间的调用关系。可理解，所述中间件包括但不限于远程过程调用中间件、数据访问中间件、消息中间件、交易中间件、对象中间件和终端仿真/屏幕转换中间件。
[0116]
示例性的，可以采取华为分布式调用链追踪系统(hitrace系统)实现标识、第一调用关系和第二调用关系的获取，对hitrace系统增加开关配置，首先打开第一级开关，启动跟踪，若用户此时发起分布式业务，hitrace系统会跟踪该分布式业务并记录处理该分布式业务的工作信息，另外，hitrace系统会给相关设备对应的日志记录一个标识符，即trace id，用该trace id将所述对应的日志记录与该分布式业务关联起来，以便于之后可以根据该trace id顺利地在相关设备的日志中找到与该分布式业务对应的记录，所述相关设备为参与处理该分布式业务的所有设备。然后打开第二级开关，确定跟踪设备间的信息，此时hitrace系统会记录该分布式业务调用信息，即获取每次调用的两端设备的信息，从而确定设备调用的先后关系，例如，如图6所示，图6表示设备a对设备b的远程调用，设备a(客户端)会发起请求(cs)，设备b(服务端)收到请求(sr)，然后设备b(服务端)进行处理并将结果发
送给设备a(客户端)(ss)，最后设备a(客户端)获取到设备b(服务端)的返回信息(cr)，可理解，当第二级开关打开时，可明确获知设备a和设备b之间调用的先后顺序，并且可以输出cs\sr\ss\cr这四个时间节点的相关日志记录。
[0117]
可选的，除了可以通过打开开关来确定跟踪设备间的信息，在本技术的一些实施例中，可以通过打开开关来确定跟踪进程间的信息，还可以通过打开开关来确定跟踪线程间的信息。
[0118]
可理解，示例中提到的trace id是上文所述标识的一种表现方式，标识还可以有其它获取方式以及表现形式，本技术中对此不作限制。
[0119]
s340：第一设备向第二设备发送第一通知。
[0120]
具体地，当第一设备在第一调用关系中获取到第二设备的uuid后，根据第二设备的uuid向第二设备发送第一通知，所述第一通知包括所述event id和第一标识。
[0121]
可选的，第一设备可以检测设备内是否存在所述第一标识和第二设备的uuid，若存在，则说明第一设备已经向第二设备发送第一通知，即第二设备已经上报过第二故障信息，此时第一设备无需给第二设备发送第一通知，即无需将第二设备的uuid、所述event id以及第一标识传送给第二设备。
[0122]
值得注意的是，第一设备可能无法成功向第二设备发送第一通知，例如，当第一设备与第二设备间出现通信故障时，第一设备无法给第二设备发送消息，也就意味着，第一设备此时不能通知第二设备上报第二故障信息。
[0123]
上述情况发生时，如图7所示，第一设备缓存第一关联失败事件，在缓存所述第一关联失败事件之前，第一设备先确定是否有足够的缓存空间来缓存所述第一关联失败事件，当前有足够的缓存空间用来缓存所述第一关联失败事件时，缓存所述第一关联失败事件；当前无足够的缓存空间用来缓存所述第一关联失败事件时，清除第二关联失败事件；若清除所述第二关联失败事件后，有足够的缓存空间用来缓存所述第一关联失败事件，缓存所述第一关联失败事件；若清除所述第二关联失败事件后，仍无足够的缓存空间用来缓存所述第一关联失败事件，清除第三关联失败事件。
[0124]
需要说明的是，所述第二关联失败事件是所述第一设备中缓存时间最长的关联失败事件；所述第三关联失败事件是清除所述第二关联失败事件后，所述第一设备中缓存时间最长的关联失败事件。在本技术的一个实施例中，关联失败事件包括通知失败的时间、标识、event id、对端设备的uuid，其中，对端设备是指在出现异常的分布式业务中故障设备所调用的设备或者调用该故障设备的设备，此时，第一关联失败事件包括第一设备发送第一通知失败的时间、与第一设备出现的故障对应的event id、第一标识以及第二设备的uuid。
[0125]
另外，上述缓存空间可以是预设空间，即是区别于系统存储或内存的空间。
[0126]
可理解，上文所述的第一设备向第二设备发送第一通知失败，包括第一设备未成功发送第一通知以及第二设备未成功接收第一通知。
[0127]
另外，如图8所示，当第一设备重新上线或者再次处理分布式业务时，第一设备查询或检查设备内是否存在所述第一关联失败事件；若存在所述第一关联失败事件，第一设备给第二设备发送第一通知，即将第一关联失败事件中的event id和第一标识传送给第二设备，来通知对端(第二设备)上报故障信息；若第一通知发送成功时，清除缓存的所述第一
关联失败事件。
[0128]
s350：第二设备接收第一设备发送的第一通知。
[0129]
具体地，第二设备接收第一设备发送的第一通知，即第二设备可以收到与第一设备出现的故障对应的event id和第一标识，所以，第二设备可通过收到的第一标识得知第一分布式业务出现了异常。
[0130]
在第二设备接收第一设备发送的第一通知前，第二设备也需要缓存第二调用关系，所述第二调用关系包括第二设备参与处理的分布式业务的设备调用信息，该设备调用信息是指第二设备参与处理的分布式业务中与第二设备有关的调用信息，即第二设备调用其它设备的信息和第二设备被其它设备调用的信息。
[0131]
与第一调用关系类似，第二设备参与处理的分布式业务的设备调用信息可以包括第一设备的对端类型、所述分布式业务的业务类型、所述分布式业务中与第二设备相关的通信信息、时间戳。这里可参照第一设备参与处理的一个或多个分布式业务的设备调用信息的内容，此处不再赘述。
[0132]
另外，可以将所述第二调用关系根据业务的生命周期分为至少两种状态，不同状态的第二调用关系对应的业务的生命周期不同，然后将所述不同状态的第二调用关系分开缓存。可参照上文第一调用关系的例子，此处不再赘述。
[0133]
s360：第二设备将第二故障信息上报给服务器。
[0134]
具体地，在第二设备收到第一设备发送的第一通知后，第二设备将第二故障信息上报给服务器。需要说明的是，在本技术的一个实施例中，所述第二故障信息包括第一标识、event id以及第二故障日志，所述第二故障日志是指第二设备的日志中与故障相关的日志记录。
[0135]
可理解，第一设备和第二设备都参与处理第一分布式业务，因此它们都缓存有第一分布式业务的设备调用信息和第一标识。
[0136]
可选的，在第二设备收到第一设备发送的第一通知后，第二设备检测设备内是否存在第一标识，若存在，则说明第二设备已经上报过第二故障信息，此时，第二设备无需将第二故障信息上报到服务器，即无需将收到的event id和第一标识以及第二故障日志上报到服务器。
[0137]
示例性的，如图2所示，在图2所示的故障信息上报的系统架构中，用户发起的一个分布式业务涉及设备a、设备c、设备d、设备f和设备h这五个设备，设备a与设备c、设备a与设备d、设备c与设备d、设备c与设备f、设备c与设备h以及设备d与设备h均存在调用关系，一般情况下，当设备a出现故障时，设备a上报故障信息并给与其有调用关系的设备c和设备d发送消息，通知设备c和设备d上报故障信息。然而，当设备c中有与设备a相关信息时，需要进行多级关联，即设备c在接收设备a发送的消息后会给与其有调用关系的设备d、设备f和设备h发送消息，设备d在接收设备a发送的消息后会给与其有调用关系的设备c和设备h发送消息，可理解，由于设备a和设备c以及设备d都存在调用关系，在第二设备收到第一设备发送的第一通知后，第二设备会检测设备内是否存在第一标识，若存在则无需上报，此时，设备c在收到设备d发送的消息时检查是否上报过与该故障相关的故障信息，检查到设备c确实上报过与该故障相关的故障信息，则不再进行上报。
[0138]
需要说明的是，在本技术的一个实施例中，故障设备(第一设备)上报到服务器的
故障信息，以及与该故障设备有调用关系的其它设备(如第二设备)上报到服务器的故障信息，是不相同的。在该实施例中，设备出现故障时，生成故障事件，同时会显示相应业务的标识，此时设备会采集故障事件对应的故障日志，然后将该故障事件、故障日志以及标识上报到服务器，而故障设备再发送消息来通知与其有调用关系的设备上报故障信息，所述与其有调用关系的设备收到消息后，再将故障信息上报到服务器。可理解，所述故障事件可以包括设备类型、故障时间、event id、故障模块和异常类型，其中，设备类型可以是手机等终端设备，也可以是路由器等其它设备；故障时间包括发生故障的时间；故障类型对应event id表示的错误信息，比如windows event id的id范围是0～5073，每个event id表示的错误信息不同，由此，故障发生时，可以根据event id知道设备发生的是什么类型的故障；故障模块可以是设备内部的某个硬件或者软件模块，也可以是一个进程或者中间件；异常类型包括但不限于无响应、卡顿、协商失败、超时。
[0139]
s370：第二设备从第二调用关系中查找第三设备。
[0140]
具体地，由上文可知，第二调用关系包括用户发起的一个或多个分布式业务的标识，还包括对端设备的uuid，而当第二设备在收到第一设备发送的第一通知后，第二设备可以根据收到的第一通知中的第一标识在第二调用关系中找到第二设备调用信息，所述第二设备调用信息为第二调用关系中所述第一分布式业务的设备调用信息，从而找到第二设备的对端设备的uuid及通信信息，即找到第三设备的uuid以及第二设备与第三设备之间的通信信息。
[0141]
s380：第二设备向第三设备发送第一通知。
[0142]
具体地，当第二设备在第二调用关系中获取到第三设备的uuid后，根据第三设备的uuid向第三设备发送二通知，所述第二通知包括所述event id和第一标识。
[0143]
可选的，第二设备可以检测设备内是否存在所述第一标识和第三设备的uuid，若存在，则说明第二设备已经向第三设备发送第一通知，即第三设备已经上报过第三故障信息，此时第二设备无需给第三设备发送第二通知，即无需将第三设备的uuid、所述event id以及第一标识传送给第三设备。
[0144]
值得注意的是，第二设备可能无法成功向第三设备发送第一通知，这种情况发生时，第二设备确定是否有足够的缓存空间用来缓存所述第四关联失败事件；当前有足够的缓存空间用来缓存所述第四关联失败事件时，缓存所述第四关联失败事件；当前无足够的缓存空间用来缓存所述第四关联失败事件时，清除第五关联失败事件；若清除所述第五关联失败事件后，有足够的缓存空间用来缓存所述第四关联失败事件，缓存所述第四关联失败事件；若清除所述第五关联失败事件后，仍无足够的缓存空间用来缓存所述第四关联失败事件，清除第六关联失败事件。
[0145]
需要说明的是，所述第五关联失败事件是所述第二设备中缓存时间最长的关联失败事件；所述第六关联失败事件是清除所述第五关联失败事件后，所述第二设备中缓存时间最长的关联失败事件。
[0146]
可理解，第二设备向第三设备发送第二通知失败，包括第二设备未成功发送第二通知以及第三设备未成功接收第二通知。
[0147]
另外，当第二设备重新上线或者再次处理分布式业务时，第二设备检查设备内是否存在所述第四关联失败事件；若存在所述第四关联失败事件，第二设备给第三设备发送
第二通知，即将第四关联失败事件中的event id和第一标识传送给第三设备；若发送成功时，清除缓存的所述第四关联失败事件。
[0148]
可理解，第二设备通知第三设备上报第三故障信息的方式与上述第一设备通知第二设备上报第二故障信息的方式相同，在此不再进行举例说明，参考第一设备通知第二设备上报第二故障信息的过程中的例子即可。
[0149]
上述详细阐述了本技术实施例的方法，为了便于更好的实施本技术实施例的上述方案，相应地，下面还提供用于配合实施的相关设备。
[0150]
如图9所示，图9是本技术提供的一种第一设备的结构示意图，该第一设备用于执行上述图3所述的面向分布式系统的故障定位方法。本技术对该第一设备的功能单元的划分不做限定，可以根据需要对该第一设备中的各个单元进行增加、减少或合并。此外，第一设备中的各个单元的操作和/或功能分别为了实现上述图3所描述的方法的相应流程，为了简洁，在此不再赘述。图9示例性的提供了一种功能单元的划分：
[0151]
第一设备900包括第一缓存单元910、第一处理单元920和第一发送单元930。
[0152]
第一缓存单元910，用于缓存第一调用关系，所述第一调用关系包括用户发起的第一设备参与处理的一个或多个分布式业务的设备调用信息。
[0153]
第一处理单元920，用于当第一设备处理第一分布式业务发生故障时，上报第一故障信息到服务器；从所述第一调用关系中查找第二设备；所述第二设备包括执行所述第一分布式业务时调用所述第一设备或被所述第一设备调用的设备。
[0154]
第一发送单元930，用于向所述第二设备发送第一通知，所述第一通知用于指示所述第二设备将第二故障信息上报给所述服务器；或者，在所述第二设备没有上报所述第二故障信息的情况下，所述第一设备向所述第二设备发送所述第一通知；所述第二故障信息包括所述第二设备处理第一分布式业务时的故障信息。
[0155]
上述三个单元之间互相可通过通信通路进行数据传输，应理解，第一设备900包括的各单元可以为软件单元、也可以为硬件单元，还可以部分为软件单元部分为硬件单元。
[0156]
如图10所示，图10是本技术提供的一种第二设备的结构示意图，该第二设备用于执行上述图3所述的面向分布式系统的故障信息关联上报方法。本技术对该第二设备的功能单元的划分不做限定，可以根据需要对该第二设备中的各个单元进行增加、减少或合并。此外，第二设备中的各个单元的操作和/或功能分别为了实现上述图3所描述的方法的相应流程，为了简洁，在此不再赘述。图10示例性的提供了一种功能单元的划分：
[0157]
第二设备1000包括第二缓存单元1010、第一接收单元1020和第二处理单元1030。
[0158]
第二缓存单元1010，用于缓存第二调用关系，所述第二调用关系包括用户发起的第二设备参与处理的一个或多个分布式业务的设备调用信息。
[0159]
第一接收单元1020，用于接收第一设备发送的第一通知，所述第一通知用于指示所述第二设备将第二故障信息上报给所述服务器。
[0160]
第二处理单元1030，所述第二设备将第二故障信息上报给所述服务器；或者，在所述第二设备没有上报所述第二故障信息的情况下，所述第二设备将第二故障信息上报给所述服务器；所述第二故障信息包括所述第二设备处理第一分布式业务时的故障信息。
[0161]
在一种可能的实现方式中，所述第二设备1000还包括：第二发送单元1040，所述第二发送单元，用于向所述第三设备发送第二通知，所述第二通知用于指示所述第三设备将
第三故障信息上报给所述服务器；或者，在所述第三设备没有上报所述第三故障信息的情况下，所述第二设备向所述第三设备发送所述第二通知；所述第三故障信息包括所述第三设备处理第一分布式业务时的故障信息。
[0162]
上述四个单元之间互相可通过通信通路进行数据传输，应理解，第二设备1000包括的各单元可以为软件单元、也可以为硬件单元，还可以部分为软件单元部分为硬件单元。
[0163]
参见图11，图11是本技术实施例提供的一种计算设备的结构示意图。如图11所示，该计算设备1100包括：处理器1110、通信接口1120以及存储器1130，所述处理器1110、通信接口1120以及存储器1130通过内部总线1140相互连接。
[0164]
所述计算设备1100可以是图9中的第一设备900，图9中的第一设备900所执行的功能实际上是由所述第一设备900的处理器1110来执行。
[0165]
所述处理器1110可以由一个或者多个通用处理器构成，例如中央处理器(central processing unit，cpu)，或者cpu和硬件芯片的组合。上述硬件芯片可以是专用集成电路(application-specific integrated circuit，asic)、可编程逻辑器件(programmable logic device，pld)或其组合。上述pld可以是复杂可编程逻辑器件(complex programmable logic device，cpld)、现场可编程逻辑门阵列(field-programmable gate array，fpga)、通用阵列逻辑(generic array logic，gal)或其任意组合。
[0166]
通信接口1120用于与其他设备或通信网络通信，如以太网，无线接入网(ran)，核心网，无线局域网(wireless local area networks，wlan)等。
[0167]
总线1140可以是外设部件互连标准(peripheral component interconnect，pci)总线或扩展工业标准结构(extended industry standard architecture，eisa)总线等。所述总线1140可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但不表示仅有一根总线或一种类型的总线。
[0168]
存储器1130可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，ram)；存储器1130也可以包括非易失性存储器(non-volatile memory)，例如只读存储器(read-only memory，rom)、快闪存储器(flash memory)、硬盘(hard disk drive，hdd)或固态硬盘(solid-state drive，ssd)；存储器1130还可以包括上述种类的组合。存储器1130用于存储执行以上述面向分布式系统的故障信息关联上报方法实施例的程序代码，在一种实施方式中，存储器1130还可以缓存其他数据，并由处理器1110来控制执行，以实现第一设备900所示的功能单元，或者用于实现图3所示的方法实施例中以第一设备900为执行主体的方法步骤。具体如下：
[0169]
处理器1110控制存储器1130缓存第一调用关系，所述第一调用关系包括用户发起的第一设备参与处理的一个或多个分布式业务的设备调用信息；
[0170]
当第一设备900处理第一分布式业务发生故障时，处理器1110控制通信接口1120上报第一故障信息到服务器；
[0171]
处理器1110从所述第一调用关系中查找第二设备；所述第二设备包括执行所述第一分布式业务时调用所述第一设备900或被所述第一设备900调用的设备；
[0172]
处理器1110控制通信接口1120向所述第二设备发送第一通知，所述第一通知用于指示所述第二设备将第二故障信息上报给所述服务器；或者，在所述第二设备没有上报所述第二故障信息的情况下，所述第一设备900向所述第二设备发送所述第一通知；所述第二
故障信息包括所述第二设备处理第一分布式业务时的故障信息。
[0173]
在其中一种实现方式中，处理器1110从所述第一调用关系中查找第二设备，包括：处理器1110通过第一标识，从第一设备调用信息中查找第二设备；所述第一设备调用信息为所述第一调用关系中所述第一分布式业务的设备调用信息。
[0174]
在其中一种实现方式中，处理器1110将所述第一调用关系根据业务的生命周期分为至少两种状态；不同状态的第一调用关系对应的业务的生命周期不同；处理器1110将所述不同状态的第一调用关系分开缓存在存储器1130中。
[0175]
在其中一种实现方式中，若所述第一设备900向所述第二设备发送所述第一通知时，发送失败，存储器1130缓存第一关联失败事件；所述第一关联失败事件用于表征发送所述第一通知失败。
[0176]
在其中一种实现方式中，处理器1110确定是否有足够的缓存空间用来缓存所述第一关联失败事件；当前有足够的缓存空间用来缓存所述第一关联失败事件时，处理器1110控制存储器1130缓存所述第一关联失败事件；当前无足够的缓存空间用来缓存所述第一关联失败事件时，处理器1110清除第二关联失败事件；所述第二关联失败事件是所述第一设备中缓存时间最长的关联失败事件；若清除所述第二关联失败事件后，有足够的缓存空间用来缓存所述第一关联失败事件，处理器1110控制存储器1130缓存所述第一关联失败事件；若清除所述第二关联失败事件后，仍无足够的缓存空间用来缓存所述第一关联失败事件，处理器1110清除第三关联失败事件；所述第三关联失败事件是清除所述第二关联失败事件后，所述第一设备中缓存时间最长的关联失败事件。
[0177]
在其中一种实现方式中，当所述第一设备900重新上线或者再次处理分布式业务时，处理器1110检查是否存在所述第一关联失败事件；当存在所述第一关联失败事件时，处理器1110控制通信接口1120向所述第二设备发送所述第一通知；成功发送所述第一通知时，处理器1110清除缓存的所述第一关联失败事件。
[0178]
参见图12，图12是本技术实施例提供的一种计算设备的结构示意图。如图12所示，该计算设备1200包括：处理器1210、通信接口1220以及存储器1230，所述处理器1210、通信接口1220以及存储器1230通过内部总线1240相互连接。
[0179]
所述计算设备1200可以是图12中的第二设备1000，图10中的第二设备1000所执行的功能实际上是由所述第二设备1000的处理器1210来执行。
[0180]
所述处理器1210可以由一个或者多个通用处理器构成，例如中央处理器(central processing unit，cpu)，或者cpu和硬件芯片的组合。上述硬件芯片可以是专用集成电路(application-specific integrated circuit，asic)、可编程逻辑器件(programmable logic device，pld)或其组合。上述pld可以是复杂可编程逻辑器件(complex programmable logic device，cpld)、现场可编程逻辑门阵列(field-programmable gate array，fpga)、通用阵列逻辑(generic array logic，gal)或其任意组合。
[0181]
通信接口1220用于与其他设备或通信网络通信，如以太网，无线接入网(ran)，核心网，无线局域网(wireless local area networks，wlan)等。
[0182]
总线1240可以是外设部件互连标准(peripheral component interconnect，pci)总线或扩展工业标准结构(extended industry standard architecture，eisa)总线等。所述总线1240可以分为地址总线、数据总线、控制总线等。为便于表示，图12中仅用一条粗线
表示，但不表示仅有一根总线或一种类型的总线。
[0183]
存储器1230可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，ram)；存储器1230也可以包括非易失性存储器(non-volatile memory)，例如只读存储器(read-only memory，rom)、快闪存储器(flash memory)、硬盘(hard disk drive，hdd)或固态硬盘(solid-state drive，ssd)；存储器1230还可以包括上述种类的组合。存储器1230用于存储执行以上述面向分布式系统的故障信息关联上报方法实施例的程序代码，在一种实施方式中，存储器1230还可以缓存其他数据，并由处理器1210来控制执行，以实现第二设备1000所示的功能单元，或者用于实现图3所示的方法实施例中以第二设备1000为执行主体的方法步骤。具体如下：
[0184]
处理器1210控制存储器1230缓存第二调用关系，所述第二调用关系包括用户发起的第二设备1000参与处理的一个或多个分布式业务的设备调用信息；
[0185]
第二设备1000中的处理器1210通过控制通信接口1220接收第一设备发送的第一通知，所述第一通知用于指示所述第二设备将第二故障信息上报给所述服务器；
[0186]
处理器1210将第二故障信息上报给所述服务器；或者，在所述第二设备1000没有上报所述第二故障信息的情况下，所述第二设备1000将第二故障信息上报给所述服务器；所述第二故障信息包括所述第二设备1000处理第一分布式业务时的故障信息。
[0187]
在其中一种实现方式中，处理器1210从所述第二调用关系中查找第三设备；所述第三设备包括执行所述第一分布式业务时调用所述第二设备1000或被所述第二设备1000调用的设备；处理器1210控制通信接口1220向所述第三设备发送第二通知，所述第二通知用于指示所述第三设备将第三故障信息上报给所述服务器；或者，在所述第三设备没有上报所述第三故障信息的情况下，所述第二设备1000向所述第三设备发送所述第二通知；所述第三故障信息包括所述第三设备处理第一分布式业务时的故障信息。
[0188]
在其中一种实现方式中，处理器1210通过第一标识，从所述第二设备调用信息中查找第三设备；所述第二设备调用信息为所述第二调用关系中所述第一分布式业务的设备调用信息。
[0189]
在其中一种实现方式中，处理器1210将所述第二调用关系根据业务的生命周期分为至少两种状态；不同状态的第二调用关系对应的业务的生命周期不同；处理器1210将所述不同状态的第二调用关系分开缓存到存储器1230中。
[0190]
在其中一种实现方式中，若处理器1210通过控制通信接口1220向所述第三设备发送所述第二通知时，发送失败，处理器1210控制存储器1230缓存第四关联失败事件；所述第四关联失败事件用于表征发送所述第二通知失败。
[0191]
在其中一种实现方式中，处理器1210确定是否有足够的缓存空间用来缓存所述第四关联失败事件；当前有足够的缓存空间用来缓存所述第四关联失败事件时，处理器1210控制存储器1230缓存所述第四关联失败事件；当前无足够的缓存空间用来缓存所述第四关联失败事件时，处理器1210清除第五关联失败事件；所述第五关联失败事件是所述第二设备中缓存时间最长的关联失败事件；若清除所述第五关联失败事件后，有足够的缓存空间用来缓存所述第四关联失败事件，处理器1210控制存储器1230缓存所述第四关联失败事件；若清除所述第五关联失败事件后，仍无足够的缓存空间用来缓存所述第四关联失败事件，处理器1210清除第六关联失败事件；所述第六关联失败事件是清除所述第五关联失败
事件后，所述第二设备中缓存时间最长的关联失败事件。
[0192]
在其中一种实现方式中，当所述第二设备1000重新上线或者再次处理分布式业务时，处理器1210检查是否存在所述第四关联失败事件；当存在所述第四关联失败事件时，处理器1210控制存储器1230向所述第三设备发送所述第二通知；成功发送所述第二通知时，处理器1210清除缓存的所述第四关联失败事件。
[0193]
本技术实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时，可以实现上述方法实施例中记载的任意一种的部分或全部步骤，以及实现上述图9所描述的任意一个功能单元的功能。
[0194]
本技术实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时，可以实现上述方法实施例中记载的任意一种的部分或全部步骤，以及实现上述图10所描述的任意一个功能单元的功能。
[0195]
本技术实施例还提供了一种计算机程序产品，当其在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中以第一设备900为执行主体的方法步骤的一个或多个步骤。上述所涉及的设备的各组成模块如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在所述计算机可读取存储介质中。
[0196]
本技术实施例还提供了一种计算机程序产品，当其在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中以第二设备1000为执行主体的方法步骤的一个或多个步骤。上述所涉及的设备的各组成模块如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在所述计算机可读取存储介质中。
[0197]
本技术实施例还提供了一种芯片系统，该芯片系统包括处理器，用于支持第一设备900实现上述任一个方法中以第一设备900为执行主体的方法步骤的一个或多个步骤。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存数据发送设备必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。
[0198]
本技术实施例还提供了一种芯片系统，该芯片系统包括处理器，用于支持第二设备1000实现上述任一个方法中以第二设备1000为执行主体的方法步骤的一个或多个步骤。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存数据发送设备必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。
[0199]
在上述实施例中，对各个实施例的描述各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。
[0200]
应理解，本文中涉及的第一、第二、第三、第四以及各种数字编号仅为描述方便进行的区分，并不用来限制本技术的范围。
[0201]
应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
[0202]
还应理解，在本技术的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。
[0203]
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟
以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
[0204]
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0205]
在本技术所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0206]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0207]
另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
[0208]
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
[0209]
本技术实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。
[0210]
本技术实施例装置中的模块可以根据实际需要进行合并、划分和删减。
[0211]
以上所述，以上实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。