一种B/S系统架构的网络监控方法、装置、介质及设备与流程

一种b/s系统架构的网络监控方法、装置、介质及设备
技术领域
1.本技术涉及软件开发技术领域，特别是一种b/s系统架构的网络监控方法、装置、存储介质及设备。


背景技术：

2.b/s系统架构即客户端和服务器架构模式。b/s架构是web兴起后的一种网络架构模式，web浏览器是客户端最主要的应用软件。这种模式统一了客户端，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和使用。
3.但是在b/s系统架构的应用中，网络请求时，客户端会受到网络环境的影响，出现客户端界面请求响应时间长，但是后台执行记录正常的情况，而现有技术中却无法定位响应时间过长的原因。


技术实现要素：

4.本发明提供一种b/s系统架构的网络监控方法，能够记录客户端发送请求到服务端接收到请求的网络延时，便于解决客户端界面请求响应时间长，但是后台执行记录正常的情况，以及无法定位响应时间过长原因的的问题，进一步方便查看网络延时，使得故障排查变得有数据可依，从而提高软件运行维护的效率。
5.为了解决上述问题，本发明采用的一个技术方案是：提供一种b/s系统架构的网络监控方法，该方法包括：
6.利用预定客户端向服务端请求网络数据时，若预定客户端能够接收到服务端的响应，则获取预定客户端发起请求时的客户端瞬时时间以及服务端的收到请求时的第一服务端瞬时时间；以及
7.利用客户端瞬时时间，第一服务端瞬时时间以及预先确定的预定客户端的系统时间差，计算得到预定客户端的当前网络延时，并将预定客户端的当前网络延时记录到b/s系统架构的系统日志；
8.其中预定客户端的系统时间差为，预定客户端发起请求时的第二服务端瞬时时间与客户端瞬时时间的时间差。
9.本发明采用的另一个技术方案是：提供一种b/s系统架构的网络监控装置，该装置包括：
10.用于利用预定客户端向服务端请求网络数据时，若预定客户端能够接收到服务端的响应，则获取预定客户端发起请求时的客户端瞬时时间以及服务端的收到请求时的第一服务端瞬时时间的模块；以及
11.用于利用客户端瞬时时间，第一服务端瞬时时间以及预先确定的预定客户端的系统时间差，计算得到预定客户端的当前网络延时，并将预定客户端的当前网络延时记录到b/s系统架构的系统日志的模块；
12.其中预定客户端的系统时间差为，预定客户端发起请求时的第二服务端瞬时时间
与客户端瞬时时间的时间差。
13.在本发明的另一个技术方案中，提供一种计算机可读存储介质，其存储有计算机指令，其中计算机指令被操作以执行方案中的b/s系统架构的网络监控方法。
14.在本发明的另一技术方案中，提供一种计算机设备，其包括至少一个处理器；以及与至少一个处理器进行通信连接的存储器，其中，存储器存储有可被至少一个处理器执行的计算机指令，至少一个处理器操作计算机指令以执行方案中的b/s系统架构的网络监控方法。
15.本发明技术方案可以达到的有益效果是：本发明提出一种b/s系统架构的网络监控方法、装置、计算机可读存储介质以及计算机设备，能够记录客户端发送请求到服务端接收到请求的网络延时，便于解决客户端界面请求响应时间长，但是后台执行记录正常的情况，以及无法定位响应时间过长原因的的问题，进一步方便查看网络延时，使得故障排查变得有数据可依，从而提高软件运行维护的效率。
附图说明
16.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
17.图1为本发明一种b/s系统架构的网络监控方法一个具体实施方式的示意图；
18.图2为本发明一种b/s系统架构的网络监控装置一个具体实施方式的示意图。
19.通过上述附图，已示出本技术明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本技术构思的范围，而是通过参考特定实施例为本领域技术人员说明本技术的概念。
具体实施方式
20.下面结合附图对本发明的较佳实施例进行详细阐述，以使本发明的优点和特征能更易于被本领域技术人员理解，从而对本发明的保护范围做出更为清楚明确的界定。
21.需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
22.图1所示为本发明一种b/s系统架构的网络监控方法一个具体实施方式的示意图。
23.在该具体实施方式中，b/s系统架构的网络监控方法主要包括：
24.过程s101：利用预定客户端向服务端请求网络数据时，若预定客户端能够接收到服务端的响应，则获取预定客户端发起请求时的客户端瞬时时间以及服务端的收到请求时的第一服务端瞬时时间；以及
25.过程s102：利用客户端瞬时时间，第一服务端瞬时时间以及预先确定的预定客户端的系统时间差，计算得到预定客户端的当前网络延时，并将预定客户端的当前网络延时记录到b/s系统架构的系统日志；
26.其中预定客户端的系统时间差为，预定客户端发起请求时的第二服务端瞬时时间与客户端瞬时时间的时间差。
27.通过本发明提出的一种b/s系统架构的网络监控方法，能够记录客户端发送请求到服务端接收到请求的网络延时，便于解决客户端界面请求响应时间长，但是后台执行记录正常的情况，以及无法定位响应时间过长原因的的问题，进一步方便查看网络延时，使得故障排查变得有数据可依，从而提高软件运行维护的效率。
28.在图1所示的具体实施方式中，本发明的b/s系统架构的网络监控方法包括，过程s101：利用预定客户端向服务端请求网络数据时，若预定客户端能够接收到服务端的响应，则获取预定客户端发起请求时的客户端瞬时时间以及服务端的收到请求时的第一服务端瞬时时间。此过程以便于进一步计算得到预定客户端的当前网络延时。
29.具体地，现有技术中已知的判断客户端能否接收到服务端响应的方法只有通过访问系统api(应用程序接口)来判断，这是客户端自带的功能属性，因此可以通过判断客户端有没有请求状态码来判断客户端能否接收到服务端响应。请求api有响应的情况下客户端会有响应状态码；请求api无响应的情况下客户端是没有请求状态码的。
30.在本发明的一个具体实例中，上述利用预定客户端向服务端请求网络数据时，若预定客户端能够接收到服务端的响应，则获取预定客户端发起请求时的客户端瞬时时间以及服务端的收到请求时的第一服务端瞬时时间的过程包括，通过访问系统api(应用程序接口)来判断预定客户端能否接收到服务端响应，若预定客户端能够接收到服务端的响应，即客户端有响应状态码的情况，获取预定客户端发起请求时的客户端瞬时时间以及服务端的收到请求时的第一服务端瞬时时间，在该具体实例中，假设预定客户端发起请求时的客户端瞬时时间为2021/9/9/01：00：01，服务端的收到请求时的第一服务端瞬时时间为2021/9/9/01：00：05。
31.在图1所示的具体实施方式中，本发明的b/s系统架构的网络监控方法包括，过程s102：利用客户端瞬时时间，第一服务端瞬时时间以及预先确定的预定客户端的系统时间差，计算得到预定客户端的当前网络延时，并将预定客户端的当前网络延时记录到b/s系统架构的系统日志；
32.其中预定客户端的系统时间差为，预定客户端发起请求时的第二服务端瞬时时间与客户端瞬时时间的时间差。此过程能够记录客户端发送请求到服务端接收到请求的网络延时，便于解决客户端界面请求响应时间长，但是后台执行记录正常的情况，以及无法定位响应时间过长原因的的问题，进一步方便查看网络延时，使得故障排查变得有数据可依，从而提高软件运行维护的效率。
33.在本发明的一个具体实施例中，本发明的b/s系统架构的网络监控方法还包括，利用预定客户端的至少一个接口请求获取与每个接口对应的第二服务端瞬时时间，并获取与每一个所述接口对应的客户端瞬时时间；计算与每个接口对应的第二服务端瞬时时间以及客户端瞬时时间的差值，并计算所有差值的平均值得到预定客户端的系统时间差；以及将系统时间差利用预定客户端的特殊信息进行标记后缓存至服务端。此过程预先计算预定客
户端的系统时间差，并将其进行标记后缓存至服务端，以便于后期计算网络延时的时候可以直接从服务端提取，并且由于系统时间差已经利用预定客户端的特殊信息进行标记，因此保证每一客户端从服务端提取系统时间差时能够一一对应。
34.在本发明的一个具体实例中，上述利用预定客户端的至少一个接口请求获取与每个接口对应的第二服务端瞬时时间，并获取与每一个所述接口对应的客户端瞬时时间的过程包括，可以在预定客户端设定至少一个接口，客户端每次打开的时候这些接口都会请求获取其对应的第二服务端瞬时时间和客户端瞬时时间，此处的第二服务端瞬时时间为预定客户端发起请求时的服务端瞬时时间。
35.在该具体实例中，假设在预定客户端设定了一个接口用来计算系统时间差，假设这个接口请求获取到其对应的客户端瞬时时间为2021/9/8/10：00：01，这个接口请求获取到其对应的第二服务端瞬时时间为2021/9/8/10：00：03。由于计算与每个接口对应的第二服务端瞬时时间以及客户端瞬时时间的差值，并计算所有差值的平均值即可得到预定客户端的系统时间差。但此处客户端瞬时时间与第二服务端瞬时时间的差值只有一个，因此不需要计算差值的平均值，直接将此差值确定为系统时间差。因此设定一个接口时预定客户端的系统时间差为2021/9/8/10：00：01与2021/9/8/10：00：03的差值，该预定客户端的系统时间差为2秒。
36.优选的，由于不同接口，响应时间长短不一，为了使系统时间差更加精确，可以设定多个接口来计算系统时间差。假设在预定客户端设定了三个接口(a接口、b接口、c接口)用来计算系统时间差，设a接口请求获取到其对应的客户端瞬时时间为2021/9/8/10：00：01，a接口请求获取到其对应的第二服务端瞬时时间为2021/9/8/10：00：02，因此a接口对应的第二服务端瞬时时间以及客户端瞬时时间的差值为1秒；设b接口请求获取到其对应的客户端瞬时时间为2021/9/8/10：00：01，b接口请求获取到其对应的第二服务端瞬时时间为2021/9/8/10：00：03，因此b接口对应的第二服务端瞬时时间以及客户端瞬时时间的差值为2秒；设c接口请求获取到其对应的客户端瞬时时间为2021/9/8/10：00：01，c接口请求获取到其对应的第二服务端瞬时时间为2021/9/8/10：00：02，因此c接口对应的第二服务端瞬时时间以及客户端瞬时时间的差值为1秒。计算所有差值的平均值即可得到预定客户端的系统时间差，所有接口的差值为：1秒、2秒、1秒，因此其差值的平均值约为1.33秒，即预定客户端的系统时间差为1.33秒。
37.在本发明的一个具体实例中，将系统时间差利用预定客户端的特殊信息进行标记后缓存至服务端的过程包括，由于b/s系统架构一般是多个客户端面对一个服务端的模式，这就代表着每个客户端打开后都会将其对应的系统时间差缓存至服务端，因此必须将这些系统时间差区分客户端进行缓存，在实际应用中，可以将预定客户端进行接口请求时对应的接口请求参数中的基础参数(token)作为预定客户端的特殊信息，也可以将安装预定客户端的电子通信产品(如计算机、手机等)对应的唯一mac地址作为预定客户端的特殊信息，在本发明中预定客户端的特殊信息不进行限定。将系统时间差利用预定客户端的特殊信息进行标记后缓存至服务端即可，便于后期计算网络延时的时候可以直接参考。在该具体实例中，将上述实例中计算出的预定客户端的系统时间差1.33秒缓存至服务端。
38.可选的，由于b/s系统架构一般是多个客户端面对一个服务端的模式，因此必然会出现多个客户端同时缓存系统时间差，以及同时提取系统时间差的情况，因此可以在服务
端中设置redis缓存，redis基于内存操作从而拥有强大的性能，可以达到每秒10万次的请求，因此可以专门用以保存多个客户端的系统时间差。
39.在本发明的一个具体实施例中，上述利用预定客户端的系统时间差，计算得到预定客户端的当前网络延时的过程包括，通过预定客户端的特殊信息从服务端的缓存中获取系统时间差；计算第一服务端瞬时时间与客户端瞬时时间的差值，再减去系统时间差得到预定客户端的当前网络延时。此过程计算得到的当前网络延时能够使得故障排查变得有数据可依，从而提高软件运行维护的效率。
40.在本发明的一个具体实例中，上述通过预定客户端的特殊信息从服务端的缓存中获取系统时间差；计算第一服务端瞬时时间与客户端瞬时时间的差值，再减去系统时间差得到预定客户端的当前网络延时的过程包括，由于上述实例中已经将预定客户端的系统时间差1.33秒缓存至服务端，此处将预定客户端的特殊信息作为提取系统时间差的钥匙，从服务端的redis缓存中获取预定客户端的系统时间差1.33秒，在前述的实例中已经得到预定客户端发起请求时的客户端瞬时时间为2021/9/9/01：00：01，服务端的收到请求时的第一服务端瞬时时间为2021/9/9/01：00：05。因此先计算第一服务端瞬时时间与客户端瞬时时间的差值，即2021/9/9/01：00：01与2021/9/9/01：00：05的差值为4秒，再用4秒减去系统时间差1.33秒得到预定客户端的当前网络延时为2.67秒。
41.实际应用中，可以在预定客户端通过点击查询系统日志，进而可视化查看当前网络延时。
42.在本发明的一个具体实施例中，本发明的b/s系统架构的网络监控方法还包括，若预定客户端不能接收到服务端的响应，则将相应的无响应请求信息缓存至预定客户端，并在预定客户端能够接收到服务端的响应的时候将无响应请求信息记录到系统日志。此过程以便于能够记录客户端请求超时或请求无响应的请求记录，使得故障排查变得有数据可依，从而提高软件运行维护的效率。
43.在本发明的一个具体实施例中，上述在预定客户端能够接收到服务端的响应的时候将无响应请求信息记录到系统日志的过程包括，预定客户端以预定周期将无响应请求信息向服务端进行发送；服务端在接收到无响应请求信息后将其记录到系统日志。此过程以便于定时将无响应请求信息回传到系统日志进行记录，使得故障排查变得有数据可依，从而提高软件运行维护的效率。
44.具体地，可以为预定客户端设置预定周期，用以将无响应请求信息向服务端进行发送，例如设置3秒发送一次，如果发送瞬间预定客户端不能接收到服务端的响应，那么可以等待下一个周期再次进行发送，如果发送瞬间预定客户端能接收到服务端的响应，服务端在接收到无响应请求信息后将其记录到系统日志。实际应用中，可以在预定客户端通过点击查询系统日志，进而可视化查看无响应请求信息。
45.通过本发明b/s系统架构的网络监控方法的应用，能够记录客户端发送请求到服务端接收到请求的网络延时，便于解决客户端界面请求响应时间长，但是后台执行记录正常的情况，以及无法定位响应时间过长原因的的问题，进一步方便查看网络延时，使得故障排查变得有数据可依，从而提高软件运行维护的效率。
46.图2所示为本发明一种b/s系统架构的网络监控装置一个具体实施方式的示意图。
47.在该具体实施方式中，b/s系统架构的网络监控装置主要包括：
48.模块201：用于利用预定客户端向服务端请求网络数据时，若预定客户端能够接收到服务端的响应，则获取预定客户端发起请求时的客户端瞬时时间以及服务端的收到请求时的第一服务端瞬时时间的模块，此模块以便于以便于进一步计算得到预定客户端的当前网络延时。
49.模块202：用于利用客户端瞬时时间，第一服务端瞬时时间以及预先确定的预定客户端的系统时间差，计算得到预定客户端的当前网络延时，并将预定客户端的当前网络延时记录到b/s系统架构的系统日志的模块，此模块能够记录客户端发送请求到服务端接收到请求的网络延时，便于解决客户端界面请求响应时间长，但是后台执行记录正常的情况，以及无法定位响应时间过长原因的的问题，进一步方便查看网络延时，使得故障排查变得有数据可依，从而提高软件运行维护的效率。
50.其中预定客户端的系统时间差为，预定客户端发起请求时的第二服务端瞬时时间与客户端瞬时时间的时间差。
51.通过本发明b/s系统架构的网络监控装置的应用，能够记录客户端发送请求到服务端接收到请求的网络延时，便于解决客户端界面请求响应时间长，但是后台执行记录正常的情况，以及无法定位响应时间过长原因的的问题，进一步方便查看网络延时，使得故障排查变得有数据可依，从而提高软件运行维护的效率。
52.在本发明的一个具体实施例中，本发明的b/s系统架构的网络监控装置还包括，用于若预定客户端不能接收到服务端的响应，则将相应的无响应请求信息缓存至预定客户端，并在预定客户端能够接收到服务端的响应的时候将无响应请求信息记录到系统日志的模块。此模块以便于能够记录客户端请求超时或请求无响应的请求记录，使得故障排查变得有数据可依，从而提高软件运行维护的效率。
53.在本发明的另一个具体实施方式中，一种计算机可读存储介质，其存储有计算机指令，其特征在于，计算机指令被操作以执行任一实施例描述的b/s系统架构的网络监控方法。其中，该存储介质可直接在硬件中、在由处理器执行的软件模块中或在两者的组合中。
54.软件模块可驻留在ram存储器、快闪存储器、rom存储器、eprom存储器、eeprom存储器、寄存器、硬盘、可装卸盘、cd-rom或此项技术中已知的任何其它形式的存储介质中。示范性存储介质耦合到处理器，使得处理器可从存储介质读取信息和向存储介质写入信息。
55.处理器可以是中央处理单元(英文：central processing unit，简称：cpu)，还可以是其他通用处理器、数字信号处理器(英文：digital signal processor，简称：dsp)、专用集成电路(英文：application specific integrated circuit，简称：asic)、现场可编程门阵列(英文：field programmable gate array，简称：fpga)或其它可编程逻辑装置、离散门或晶体管逻辑、离散硬件组件或其任何组合等。通用处理器可以是微处理器，但在替代方案中，处理器可以是任何常规处理器、控制器、微控制器或状态机。处理器还可实施为计算装置的组合，例如dsp与微处理器的组合、多个微处理器、结合dsp核心的一个或一个以上微处理器或任何其它此类配置。在替代方案中，存储介质可与处理器成一体式。处理器和存储介质可驻留在asic中。asic可驻留在用户终端中。在替代方案中，处理器和存储介质可作为离散组件驻留在用户终端中。
56.在本发明的一个具体实施方式中，提供一种计算机设备，其包括至少一个处理器；以及与至少一个处理器进行通信连接的存储器，其中，存储器存储有可被至少一个处理器
执行的计算机指令，至少一个处理器操作计算机指令以执行方案中的b/s系统架构的网络监控方法。
57.在本技术所提供的实施方式中，应该理解到，所揭露的系统和方法，可以通过其它的方式实现。例如，以上所描述的系统实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
58.作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
59.以上仅为本技术的实施例，并非因此限制本技术的专利范围，凡是利用本技术说明书及附图内容所作的等效结构变换，或直接或间接运用在其他相关的技术领域，均同理包括在本技术的专利保护范围内。