微服务健康的监测方法、装置、电子设备及存储介质与流程

1.本发明涉及微服务技术领域，尤其涉及一种微服务健康的监测方法、装置、电子设备及存储介质。


背景技术：

2.目前，微服务的运行会依赖多个saas(software-as-a-service，软件即服务)层的服务组件，比如mysql关系型数据库管理系统、redis远程字典服务等，微服务的稳定运行离不开这些组件的健康运行。
3.现有监控系统大多是直接监控saas层各个组件，通过监控系统可以看到不同组件的各项详细指标的数据，且每一项详细指标数据可以设置不同的展示形式和告警规则，但是这些都是基于saas层的监控，导致无法获取微服务的整体情况。


技术实现要素：

4.本发明提供一种微服务健康的监测方法、装置、电子设备及存储介质，能够通过确定目标微服务的至少一个待监测依赖组件的健康值，并通过每个组件的健康值和对应的权重，确定微服务的健康值，这样提供了一种评价微服务的健康的方式。
5.第一方面，本发明实施例提供一种微服务健康的监测方法，包括：
6.在检测到用户触发的监测指令之后，确定目标微服务的至少一个待监测依赖组件；其中，所述待监测依赖组件为影响目标微服务运行的saas层服务的组件；
7.针对任意一个待监测依赖组件，通过所述任意一个待监测依赖组件对应的监测策略，监测表征所述任意一个待监测依赖组件运行情况的多个指标，并根据所述任意一个待监测依赖组件的每个指标对应的健康值之和，确定所述任意一个待监测依赖组件的健康值；其中，指标对应的健康值表征所述指标对待监测依赖组件正常运行的影响程度；
8.根据每个待监测依赖组件的健康值和每个待监测依赖组件对应的权重，确定目标微服务的健康值。
9.上述方法，能够提供了一种微服务健康的评价方式，具体来说，确定目标微服务的至少一个待监测依赖组件，并根据监测到的每个待监测依赖组件对应的指标的健康值之和，确定每个待监测依赖组件的健康值，再通过每个待监测依赖组件的健康值和对应的权重，确定目标微服务的健康值，这样能够从微服务的角度进行健康评价。
10.在一种可能实施的方式中，在检测到用户触发的监测指令之后，确定目标微服务的至少一个待监测依赖组件，包括：
11.在检测到用户触发的监测指令之后，显示选择界面；其中，所述选择界面中包括影响目标微服务运行的saas层服务的多个组件；
12.响应用户在所述选择界面中触发的选择指令，将所述选择指令选择的组件作为待监测依赖组件。
13.上述方法，能够提供通过用户选择指令选择组件，提高了用户体验感。
14.在一种可能实施的方式中，通过以下方式确定待监测依赖组件的每个指标对应的健康值：
15.针对待监测依赖组件的每个指标，若所述指标满足所述指标对应的预设条件，则确定所述指标对应的健康值为第一预设值；其中，所述第一预设值为待监测依赖组件的每个指标均不满足每个指标对应的预设条件时，待监测依赖组件的健康值；
16.若所述指标不满足所述指标对应的预设条件，则确定所述指标对应的健康值为目标值；其中，所述目标值是第二预设值与待监测依赖组件的指标总个数的比值；所述第二预设值为待监测依赖组件的每个指标均满足每个指标对应的预设条件时，待监测依赖组件的健康值。
17.上述方法，通过判断指标是否满足指标对应的预设条件，赋予不同的值作为健康值，从而得到不同的影响程度，使得影响程度进行量化处理，使人可以一目了然，提高了用户体验感。
18.在一种可能实施的方式中，通过以下方式确定待监测依赖组件对应的权重：
19.方式一：将所述待监测依赖组件的第一读写次数与目标微服务的所有待监测依赖组件的第一读写次数之和之间的第一比值，作为所述待监测依赖组件对应的权重；其中，所述第一读写次数为实现所述待监测依赖组件的代码中表征读功能和写功能的代码出现的总次数；或
20.方式二：将所述待监测依赖组件的第二读写次数与目标微服务的所有待监测依赖组件的第二读写次数之和之间的第二比值，作为所述待监测依赖组件对应的权重；其中，所述第二读写次数为预设时间段内所述待监测依赖组件运行过程中执行读功能和写功能的总次数；或
21.方式三：确定所述待监测依赖组件的第一读写次数与目标微服务的所有待监测依赖组件的第一读写次数之和之间的第一比值，以及所述待监测依赖组件的第二读写次数与目标微服务的所有待监测依赖组件的第二读写次数之和之间的第二比值；
22.根据所述第一比值和所述第一比值对应的系数、所述第二比值和所述第二比值对应的系数，确定每个待监测依赖组件对应的权重；其中，方式二对应的系数是根据每个待监测依赖组件运行过程中的运行时间确定的，所述方式一对应的系数为方式二对应的系数和阈值之间的差值。
23.上述方法，通过静态或动态的方式确定权重，或者通过静态和动态的方式确定权重，通过权重加权每个待监测依赖组件的健康值得到微服务的健康值，使得更加接近微服务的真实健康程度，提高了准确率。
24.在一种可能实施的方式中，其中：
25.若所述待监测依赖组件为mysql关系型数据库管理系统，则所述待监测依赖组件对应的指标为mysql启动情况、mysql中读取缓存区的大小、mysql使用量、mysql中打开文件数量中的部分或全部；
26.若所述待监测依赖组件为实现redis远程字典服务的组件，则所述待监测依赖组件对应的指标为实现redis远程字典服务的组件的启动情况、实现redis远程字典服务的组件的集群中的master节点、实现redis远程字典服务的组件备份情况、实现redis远程字典服务的组件的内存大小中的部分或全部；
27.若所述待监测依赖组件为mongodb基于分布式文件存储的数据库，则所述待监测依赖组件对应的指标为mongodb启动情况、mongodb复制延迟功能延迟的时间、mongodb中连接系统的个数、mongodb的内存大小中的部分或全部。
28.上述方法，能够通过mysql关系型数据库管理系统、实现redis远程字典服务的组件、mongodb基于分布式文件存储的数据库这些起着数据存储、消息传递、文件操作等操作基石作用的组件，来确定微服务的健康值，使得评价的健康值更加准确。
29.在一种可能实施的方式中，在根据每个待监测依赖组件的健康值和每个待监测依赖组件对应的权重，确定目标微服务的健康值之后，所述方法还包括：
30.根据健康范围和展示颜色的对应关系，确定每个待监测依赖组件的健康值所属的健康范围对应的展示颜色、以及目标微服务的健康值所属的健康范围对应的展示颜色；
31.根据每个待监测依赖组件的健康值所属的健康范围对应的展示颜色、以及目标微服务的健康值所属的健康范围对应的展示颜色，构建展示图片，并展示所述展示图片。
32.上述方法，能够通过颜色来向用户表述微服务的不同健康程度，提高了用户体验感。
33.第二方面，本发明实施例提供一种微服务器健康的监测装置，包括：
34.确定模块，用于在检测到用户触发的监测指令之后，确定目标微服务的至少一个待监测依赖组件；其中，所述待监测依赖组件为影响目标微服务运行的saas层服务的组件；
35.监测模块，用于针对任意一个待监测依赖组件，通过所述任意一个待监测依赖组件对应的监测策略，监测表征所述任意一个待监测依赖组件运行情况的多个指标，并根据所述任意一个待监测依赖组件的每个指标对应的健康值之和，确定所述任意一个待监测依赖组件的健康值；其中，指标对应的健康值表征所述指标对待监测依赖组件正常运行的影响程度；根据每个待监测依赖组件的健康值和每个待监测依赖组件对应的权重，确定目标微服务的健康值。
36.在一种可能实施的方式中，监测模块，具体用于：
37.方式一：将所述待监测依赖组件的第一读写次数与目标微服务的所有待监测依赖组件的第一读写次数之和之间的第一比值，作为所述待监测依赖组件对应的权重；其中，所述第一读写次数为实现所述待监测依赖组件的代码中表征读功能和写功能的代码出现的总次数；或
38.方式二：将所述待监测依赖组件的第二读写次数与目标微服务的所有待监测依赖组件的第二读写次数之和之间的第二比值，作为所述待监测依赖组件对应的权重；其中，所述第二读写次数为预设时间段内所述待监测依赖组件运行过程中执行读功能和写功能的总次数；或
39.方式三：确定所述待监测依赖组件的第一读写次数与目标微服务的所有待监测依赖组件的第一读写次数之和之间的第一比值，以及所述待监测依赖组件的第二读写次数与目标微服务的所有待监测依赖组件的第二读写次数之和之间的第二比值；
40.根据所述第一比值和所述第一比值对应的系数、所述第二比值和所述第二比值对应的系数，确定每个待监测依赖组件对应的权重；其中，方式二对应的系数是根据每个待监测依赖组件运行过程中的运行时间确定的，所述方式一对应的系数为方式二对应的系数和阈值之间的差值。
41.第三方面，本发明实施例提供一种电子设备，包括：
42.处理器；
43.用于存储所述处理器可执行指令的存储器；
44.其中，所述处理器被配置为执行所述指令，以实现如第一方面中任一项所述的微服务健康的监测方法。
45.第四方面，本发明实施例提供一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如第一方面中任一项所述的微服务健康的监测方法。
46.另外，第二方面至第四方面中任一种实现方式所带来的技术效果可参见第一方面中不同实现方式所带来的技术效果，此处不再赘述。
47.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。
附图说明
48.图1为本发明实施例提供的一种微服务健康的监测方法的流程图；
49.图2为本发明实施例提供的一种待监测依赖组件的指标对应的健康值的展示的示意图；
50.图3为本发明实施例提供的一种待监测依赖组件对应的权重获取的两种方法的关系示意图；
51.图4为本发明实施例提供的一种待监测依赖组件的比值的系数和运行时间的关系示意图；
52.图5为本发明实施例提供的一种微服务的健康值的展示的示意图；
53.图6为本发明实施例提供的一种微服务健康的监测装置的结构示意图；
54.图7为本发明实施例提供的一种电子设备的结构示意图。
具体实施方式
55.为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部份实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
56.目前，微服务的运行会依赖多个saas层的服务组件，微服务的稳定运行离不开这些组件的健康运行，而一般监测时都是各自监控saas组件，导致无法获知整个微服务的健康情况。
57.基于此，本发明提出一种评价整个微服务的健康方式。
58.以下结合附图进行详细说明：
59.结合图1所示，本发明实施例提供了一种微服务健康的监测方法，包括：
60.s100：在检测到用户触发的监测指令之后，确定目标微服务的至少一个待监测依赖组件；其中，待监测依赖组件为影响目标微服务运行的saas层服务的组件；
61.其中，在微服务的系统中，可以包括用户界面，在用户界面中具有“监测按钮”，当
用户点击“监测按钮”时，即用户触发了监测指令。
62.或者，在电子设备上具有“监测按钮”，该“监测按钮”为物理按钮，当用户按压“监测按钮”时，即用户触发了监测指令。
63.当然，上述说明仅为示例性的，不能作为本发明的具体限制。
64.其中，通过以下方式确定目标微服务的至少一个待监测依赖组件：
65.将影响目标微服务运行的所有的saas层服务的组件，作为待监测依赖组件；或者
66.在检测到用户触发的监测指令之后，显示选择界面；其中，选择界面中包括影响目标微服务运行的saas层服务的多个组件；
67.响应用户在选择界面中触发的选择指令，将选择指令选择的组件作为待监测依赖组件。
68.示例性的，影响目标微服务运行的saas层服务的多个组件包括mysql关系型数据库管理系统、实现redis远程字典服务的组件、实现rabbitmq消息队列的组件、kafka开源流处理平台、ftp(file transfer protocol，文件传输协议)服务器、s3(simple storage service)、mongodb基于分布式文件存储的数据库等组件。这些组件在微服务的运行过程中为数据存储、消息传递、文件操作等起着操作基石的作用，可以选择这些组件作为依赖组件。选择界面中包括上述多个组件，用户在该选择界面上选择组件，并将选择的这个组件作为待监测依赖组件。当然用户可以选择一个或者多个，对此本发明不做限制。
69.其中，s3是互联网存储解决方案，可以理解为一个可提供存储服务的软件。该服务旨在降低开发人员进行网络规模级计算的难度。s3提供了一个简单web服务接口，可用于随时在web上的任何位置存储和检索任何数量的数据。此服务让所有开发人员都能访问同一个具备高扩展性、可靠性、安全性和快速价廉的数据存储基础设施，amazon用它来运行其全球的网站网络。此服务旨在为开发人员带来最大化的规模效益。
70.s101：针对任意一个待监测依赖组件，通过任意一个待监测依赖组件对应的监测策略，监测表征任意一个待监测依赖组件运行情况的多个指标，并根据任意一个待监测依赖组件的每个指标对应的健康值之和，确定任意一个待监测依赖组件的健康值；其中，指标对应的健康值表征指标对待监测依赖组件正常运行的影响程度；
71.其中，待监测依赖组件的指标，可以从反应一定的微服务的运行情况，例如mysql服务，文中用到的指标有read_buffer_size(mysql读入缓冲区大小)，slave_max_allowed_packet(sql线程能够读取的event的最大大小)，max_used_connections(当前的连接数)，max_connections(最大连接数)，innodb_num_open_files(iinnodb层同时打开的文件数量)，open_files_limit(iinnodb层最大打开的文件数量)。
72.示例性的，若待监测依赖组件为mysql关系型数据库管理系统，则待监测依赖组件对应的指标为mysql启动情况、mysql中读取缓存区的大小、mysql使用量、mysql中打开文件数量中的部分或全部；
73.若待监测依赖组件为实现redis远程字典服务的组件，则待监测依赖组件对应的指标为实现redis远程字典服务的组件的启动情况、实现redis远程字典服务的组件的集群中的master节点、实现redis远程字典服务的组件备份情况、实现redis远程字典服务的组件的内存大小中的部分或全部；
74.若待监测依赖组件为mongodb基于分布式文件存储的数据库，则待监测依赖组件
对应的指标为mongodb启动情况、mongodb复制延迟功能延迟的时间、mongodb中连接系统的个数、mongodb的内存大小中的部分或全部。
75.例如，当待监测依赖组件为mysql关系型数据库管理系统，那么根据mysql启动情况对应的健康值、mysql中读取缓存区的大小对应的健康值、mysql使用量对应的健康值、mysql中打开文件数量对应的健康值之和，确定mysql关系型数据库管理系统的健康值；
76.当待监测依赖组件为实现redis远程字典服务的组件，那么根据实现redis远程字典服务的组件的启动情况对应的健康值、实现redis远程字典服务的组件的集群中的master节点对应的健康值、实现redis远程字典服务的组件备份情况对应的健康值、实现redis远程字典服务的组件的内存大小对应的健康值之和，确定实现redis远程字典服务的组件的健康值；
77.当待监测依赖组件为mongodb基于分布式文件存储的数据库，那么根据mongodb启动情况对应的健康值、mongodb复制延迟功能延迟的时间对应的健康值、mongodb中连接系统的个数对应的健康值、mongodb的内存大小对应的健康值之和，确定mongodb的健康值。
78.其中，监测表征任意一个待监测依赖组件运行情况的多个指标是通过指标监控器实现的。指标监控器是一种可以定时采集不同saas服务静态指标的工具，对于不同服务的不同静态指标可以按照指定格式存储。对于各静态指标可以设置告警阈值，在收集指标时，对各自设置的阈值进行告警判断,该功能可以自行实现也可以使用开源软件支持。
79.s102：根据每个待监测依赖组件的健康值和每个待监测依赖组件对应的权重，确定目标微服务的健康值。
80.示例性的，目标微服务的至少一个待监测依赖组件为mysql、实现redis远程字典服务的组件、mongodb，那么根据mysql和mysql对应的权重、实现redis远程字典服务的组件和实现redis远程字典服务的组件对应的权重、mongodb和mongodb对应的权重，确定目标微服务的健康值。
81.综上可知，本发明实施例通过确定目标微服务的至少一个待监测依赖组件的指标对应的健康值，并根据每个待监测依赖组件的指标对应的健康值之和，确定该待监测依赖组件的健康值，根据目标微服务的所有待监测依赖组件的健康值和所有待监测依赖组件对应的权重，确定整个微服务的健康值，这样提供了一种微服务的健康评价方式，使得用户能够了解微服务的整体健康情况。
82.其中，通过以下方式确定待监测依赖组件的每个指标对应的健康值：
83.针对待监测依赖组件的每个指标，若指标满足所述指标对应的预设条件，则确定指标对应的健康值为第一预设值；其中，第一预设值为待监测依赖组件的每个指标均不满足每个指标对应的预设条件时，待监测依赖组件的健康值；
84.若指标不满足所述指标对应的预设条件，则确定指标对应的健康值为目标值；其中，目标值是第二预设值与待监测依赖组件的指标总个数的比值；第二预设值为待监测依赖组件的每个指标均满足每个指标对应的预设条件时，待监测依赖组件的健康值。
85.待监测依赖组件为mysql，则选取的详细指标和每个指标对应的预设条件：
86.e1.mysql_up＝＝0；
87.意义："mysql是否启动"；
88.e2.mysql_global_variables_read_buffer_size》mysql_global_variables_
slave_max_allowed_packet；
89.意义：“读取缓冲区大小大于最大值”；
90.e3.mysql_global_status_max_used_connections》mysql_global_variables_max_connections*0.8；
91.意义："使用了超过80％的最大连接限制"；
92.e4.mysql_global_status_innodb_num_open_files》(mysql_global_variables_open_files_limit)*0.75；
93.意义：打开文件数量过高.达到最大值的75％；
94.待监测依赖组件为实现redis远程字典服务的组件，则选取的详细指标和每个指标对应的预设条件：
95.e1.redis_up＝0；
96.意义："redis是否开启"；
97.e2.(count(redis_instance_info{role＝"master"})or vector(0))《1；
98.意义："redis集群没有master节点"；
99.e3.time()-redis_rdb_last_save_timestamp_seconds》60*60*24；
100.意义："redis 24小时未备份"；
101.e4.redis_memory_used_bytes/redis_total_system_memory_bytes*100》90；
102.意义：redis系统内存不足；
103.待监测依赖组件为mongodb，则选取的详细指标和每个指标对应的预设条件：
104.e1.mongodb_up＝＝0；
105.意义："mongodb是否开启；
106.e2.mongodb_mongod_replset_member_optime_date{state＝"primary"}-on(set)mongodb_mongod_replset_member_optime_date{state＝"secondary"}》10；
107.意义："mongodb复制延迟超过10s"；
108.e3.avg by(instance)(rate(mongodb_connections{state＝"current"}[1m]))/avgby(instance)(sum(mongodb_connections)by(instance))*100》80；
[0109]
意义："连接过多(》80％)"；
[0110]
e4.(sum(mongodb_memory{type＝"virtual"})by(instance)/sum(mongodb_memory{type＝"mapped"})by(instance))》3；
[0111]
意义："内存占用高"。
[0112]
例如，第二预设值为100，第一预设值为0，mysql确立4个指标，其中指标不满足对应的预设条件时，得分为-100除以4为-25分；指标满足对应的预设条件时，得分为0；当redis有n个指标时，每个指标不满足对应的预设条件时，得分为分，指标满足对应的预设条件时，得分为0。
[0113]
待监测依赖组件的健康值为
[0114]
进一步的，对每个待监测依赖组件的每次监测到的结果进行记录，记录的字段包括“健康值，哪项详细指标扣分，哪项详细指标没扣分，监测的时间点。
[0115]
结合图2所示，中心区域代表了该待监测依赖组件的健康值，记录了当前时间节
点。剩余4扇形区域分别表示了该待监测依赖组件的4个指标是否满足指标对应的预设条件，如果指标满足指标对应的预设条件，则该扇形区域是绿色的，会显示有“正常”、
“‑
0分”等字样，如果指标不满足指标对应的预设条件，则该扇形区域是红色的，会显示有“异常，分”等字样。
[0116]
其中，通过以下方式确定待监测依赖组件对应的权重：
[0117]
方式一：将待监测依赖组件的第一读写次数与目标微服务的所有待监测依赖组件的第一读写次数之和之间的第一比值，作为待监测依赖组件对应的权重；其中，第一读写次数为实现待监测依赖组件的代码中表征读功能和写功能的代码出现的总次数；或
[0118]
方式二：将待监测依赖组件的第二读写次数与目标微服务的所有待监测依赖组件的第二读写次数之和之间的第二比值，作为待监测依赖组件对应的权重；其中，第二读写次数为预设时间段内待监测依赖组件运行过程中执行读功能和写功能的总次数；或
[0119]
方式三：确定待监测依赖组件的第一读写次数与目标微服务的所有待监测依赖组件的第一读写次数之和之间的第一比值，以及待监测依赖组件的第二读写次数与目标微服务的所有待监测依赖组件的第二读写次数之和之间的第二比值；
[0120]
根据第一比值和第一比值对应的系数、第二比值和第二比值对应的系数，确定每个待监测依赖组件对应的权重；其中，方式二对应的系数是根据每个待监测依赖组件运行过程中的运行时间确定的，方式一对应的系数为方式二对应的系数和阈值之间的差值。
[0121]
详细来说，方式一是采用静态的方法获取权重：在整个代码中静态统计各待监测依赖组件的调用点(读功能或写功能)，记录各个待监测依赖组件的读功能和写功能的次数ni,把各个待监测依赖组件的次数相加可得总次数n。
[0122]
则每个待监测依赖组件的权重为
[0123]
方式二是采用动态的方式获取权重：在各个待监测依赖组件的基类上实现读功能和写功能进行计数，分别取一段时间内各个待监测依赖组件的调用读功能和写功能的次数之和为m，各个待监测依赖组件单独的调用读功能和写功能的次数为mi，则每个待监测依赖组件的权重为
[0124]
进一步的，调用次数的获取方法：
[0125]
比如在一个django项目中，对mysql的访问方法可以通过orm的方法实现使用python的对象来读写数据库，包括实现redis远程字典服务的组件也可以通过python的redis库来达到同样效果，随后可以在orm的models基类中实现统计读功能和写功能的次数，每次执行读功能或执行写功能任意一个model，会在一张count表上对计数进行+1操作，整个项目中所有model都继承这个models基类，这样在项目中任意一次读和写mysql数据库，都会累计这个次数。如此，可以获得以天或周为时间单位的调用次数，redis、rabbitmq这些其他组件也可以使用类似方法获得某段时间的调用次数。
[0126]
对于方式三：根据经验来看，对于某一个指标来说，随着时间的推移，动态方式获取的权重对于当前指标的真实权重来说影响越来越大，静态方式获取的权重对当前指标的真实权重值影响越来约小。所以随着时间的推移，静态方式获取权重和动态方式获取权重对于一个待监测依赖组件与时间的趋势关系如3图所示。
[0127]
其中，结合图3所示，x轴代表时间t，y轴代表权重；则曲线c1代表权要w
静
，曲线c2代表权要w
动
；
[0128]
假设存在系数k，使得单个待监测依赖组件对应的权重满足如上关系则：
[0129]
wi＝kw
动
+(1-k)w
静
[0130]
其中
[0131]
则时间t和系数k的关系如下图4所示。
[0132]
其中，结合图4所示，x轴为时间，y轴为k系数的值，0《＝k《＝1，曲线c3为待监测依赖组件运行过程中的运行时间和待监测依赖组件对应的系数之间的函数关系得到的曲线。
[0133]
从曲线c3中可以看出，随着时间推移，k值逐渐趋于稳定，则静态方式获取的权重和动态方式获取的权重的比例划分也趋于稳定，如此可以计算一个逐渐趋于真实权重的比值pi。
[0134]
计算目标微服务的健康值为，使用每一项待监测依赖组件的健康值乘以各自的权重，再对各个加权后的待监测依赖组件累加求和，作为目标微服务的健康值。
[0135]
计算目标微服务的健康值的公式为：
[0136][0137]
其中，wi为第i个待监测依赖组件，w
动
为wi的通过动态方式获取的权重，w
静
为wi的通过静态方式获取的权重，k为w
动
对应的系数。
[0138]
其中，在根据每个待监测依赖组件的健康值和每个待监测依赖组件对应的权重，确定目标微服务的健康值之后，所述方法还包括：
[0139]
根据健康范围和展示颜色的对应关系，确定每个待监测依赖组件的健康值所属的健康范围对应的展示颜色、以及目标微服务的健康值所属的健康范围对应的展示颜色；
[0140]
根据每个待监测依赖组件的健康值所属的健康范围对应的展示颜色、以及目标微服务的健康值所属的健康范围对应的展示颜色，构建展示图片，并展示所述展示图片。
[0141]
示例性的，对微服务的健康值、微服务的各个待监测依赖组件的健康值进行展示。其中服务到待监测依赖组件之间的连线的粗细代表了该待监测依赖组件对应的权重，每个待监测依赖组件图形的面积代表了该待监测依赖组件的健康值。例如，绿色代表健康80～100分，黄色代表正常位于60～80之间，红色代表异常《60分。
[0142]
结合图5所示，mysql的健康值为80分，redis的健康值为60分，mongodb的健康值为90分，mysql对应的权重为0.1，redis对应的权重为0.6，mongodb对应的权重为0.3，则目标微服务的健康值为71分。详情绿色代表未超过阈值的规则，不扣分，红色超出阈值的规则需要扣分；每个待监测依赖组件中显示了各自的得分，待监测依赖组件到微服务之间的连线粗细程度用来表示该待监测依赖组件对应的权重大小，当用户点击某一个具体的待监测依赖组件时则会出现图2中待监测依赖组件的详细展示。
[0143]
综上所示，从微服务的待监测依赖组件角度出发，评估了该微服务的健康程度，对微服务的健康程度实现量化展示，使人可以一目了然，又可以具体查看待监测依赖组件对应的指标是否正常。较之前的技术相比，评价的维度变多了，并且采用了静/动态方式获取的权重来计算每个待监测依赖组件的真实权重，更加接近了微服务的真实健康程度。
[0144]
在微服务依赖链路上有突出重点，量化展示要素(微服务的健康值，待监测依赖组
件的健康值)，这样可以展示更多维度的信息，例如有整个微服务的健康情况、每个待监测依赖组件的健康情况，每个待监测依赖组件对应的权重。
[0145]
如图6所示，本发明还提供一种微服务器健康的监测装置，包括：
[0146]
确定模块600，用于在检测到用户触发的监测指令之后，确定目标微服务的至少一个待监测依赖组件；其中，所述待监测依赖组件为影响目标微服务运行的saas层服务的组件；
[0147]
监测模块601，用于针对任意一个待监测依赖组件，通过所述任意一个待监测依赖组件对应的监测策略，监测表征所述任意一个待监测依赖组件运行情况的多个指标，并根据所述任意一个待监测依赖组件的每个指标对应的健康值之和，确定所述任意一个待监测依赖组件的健康值；其中，指标对应的健康值表征所述指标对待监测依赖组件正常运行的影响程度；根据每个待监测依赖组件的健康值和每个待监测依赖组件对应的权重，确定目标微服务的健康值。
[0148]
可选的，确定模块600，具体用于：
[0149]
在检测到用户触发的监测指令之后，显示选择界面；其中，所述选择界面中包括影响目标微服务运行的saas层服务的多个组件；
[0150]
响应用户在所述选择界面中触发的选择指令，将所述选择指令选择的组件作为待监测依赖组件。
[0151]
可选的，监测模块601，具体用于：
[0152]
针对待监测依赖组件的每个指标，若所述指标满足所述指标对应的预设条件，则确定所述指标对应的健康值为第一预设值；其中，所述第一预设值为待监测依赖组件的每个指标均不满足每个指标对应的预设条件时，待监测依赖组件的健康值；
[0153]
若所述指标不满足所述指标对应的预设条件，则确定所述指标对应的健康值为目标值；其中，所述目标值是第二预设值与待监测依赖组件的指标总个数的比值；所述第二预设值为待监测依赖组件的每个指标均满足每个指标对应的预设条件时，待监测依赖组件的健康值。
[0154]
可选的，监测模块，具体用于：
[0155]
方式一：将所述待监测依赖组件的第一读写次数与目标微服务的所有待监测依赖组件的第一读写次数之和之间的第一比值，作为所述待监测依赖组件对应的权重；其中，所述第一读写次数为实现所述待监测依赖组件的代码中表征读功能和写功能的代码出现的总次数；或
[0156]
方式二：将所述待监测依赖组件的第二读写次数与目标微服务的所有待监测依赖组件的第二读写次数之和之间的第二比值，作为所述待监测依赖组件对应的权重；其中，所述第二读写次数为预设时间段内所述待监测依赖组件运行过程中执行读功能和写功能的总次数；或
[0157]
方式三：确定所述待监测依赖组件的第一读写次数与目标微服务的所有待监测依赖组件的第一读写次数之和之间的第一比值，以及所述待监测依赖组件的第二读写次数与目标微服务的所有待监测依赖组件的第二读写次数之和之间的第二比值；
[0158]
根据所述第一比值和所述第一比值对应的系数、所述第二比值和所述第二比值的系数，确定每个待监测依赖组件对应的权重；其中，方式二对应的系数是根据每个待监测依
赖组件运行过程中的运行时间确定的，所述方式一对应的系数为方式二对应的系数和阈值之间的差值。
[0159]
可选的，其中：
[0160]
若所述待监测依赖组件为mysql关系型数据库管理系统，则所述待监测依赖组件对应的指标为mysql启动情况、mysql中读取缓存区的大小、mysql使用量、mysql中打开文件数量中的部分或全部；
[0161]
若所述待监测依赖组件为实现redis远程字典服务的组件，则所述待监测依赖组件对应的指标为实现redis远程字典服务的组件的启动情况、实现redis远程字典服务的组件的集群中的master节点、实现redis远程字典服务的组件备份情况、实现redis远程字典服务的组件的内存大小中的部分或全部；
[0162]
若所述待监测依赖组件为mongodb基于分布式文件存储的数据库，则所述待监测依赖组件对应的指标为mongodb启动情况、mongodb复制延迟功能延迟的时间、mongodb中连接系统的个数、mongodb的内存大小中的部分或全部。
[0163]
可选的，所示装置还包括：
[0164]
展示模块，用于根据健康范围和展示颜色的对应关系，确定每个待监测依赖组件的健康值所属的健康范围对应的展示颜色、以及目标微服务的健康值所属的健康范围对应的展示颜色；
[0165]
根据每个待监测依赖组件的健康值所属的健康范围对应的展示颜色、以及目标微服务的健康值所属的健康范围对应的展示颜色，构建展示图片，并展示所述展示图片。
[0166]
另外，结合图1-图6描述的本发明实施例的微服务器健康的监测方法和装置可以由电子设备来实现。
[0167]
该电子设备，包括：处理器；
[0168]
用于存储所述处理器可执行指令的存储器；
[0169]
其中，所述处理器被配置为执行所述指令，以实现如上述介绍的任一项所述的微服务器健康的监测方法。
[0170]
基于上述的介绍，示例性的，提出了图7的电子设备结构。
[0171]
电子设备可以包括处理器710以及存储有计算机程序指令的存储器720。
[0172]
具体地，上述处理器710可以包括中央处理器(cpu)，或者特定集成电路(application specific integrated circuit，asic)，或者可以被配置成实施本发明实施例的一个或多个集成电路。
[0173]
存储器720可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器720可包括硬盘驱动器(hard disk drive，hdd)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(universal serial bus，usb)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器720可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器720可在数据处理装置的内部或外部。在特定实施例中，存储器720是非易失性固态存储器。在特定实施例中，存储器720包括只读存储器(rom)。在合适的情况下，该rom可以是掩模编程的rom、可编程rom(prom)、可擦除prom(eprom)、电可擦除prom(eeprom)、电可改写rom(earom)或闪存或者两个或更多个以上这些的组合。
[0174]
处理器710通过读取并执行存储器720中存储的计算机程序指令，以实现上述实施
例中的任意一种执行任务的方法。
[0175]
在一个示例中，电子设备还可包括通信接口730和总线740。其中，如图7所示，处理器710、存储器720、通信接口730通过总线740连接并完成相互间的通信。
[0176]
通信接口730，主要用于实现本发明实施例中各模块、装置、单元和/或设备之间的通信。
[0177]
总线740包括硬件、软件或两者，将电子设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(agp)或其他图形总线、增强工业标准架构(eisa)总线、前端总线(fsb)、超传输(ht)互连、工业标准架构(isa)总线、无限带宽互连、低引脚数(lpc)总线、存储器总线、微信道架构(mca)总线、外围组件互连(pci)总线、pci-express(pci-x)总线、串行高级技术附件(sata)总线、视频电子标准协会局部(vlb)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线740可包括一个或多个总线。尽管本发明实施例描述和示出了特定的总线，但本发明考虑任何合适的总线或互连。
[0178]
该电子设备可以基于接收到的任务，执行本发明实施例中的执行任务的方法，从而实现结合图1-图6描述的微服务器健康的监测方法和装置。
[0179]
另外，结合上述实施例中的电子设备，本发明实施例可提供一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如上述任一项所述的微服务器健康的监测方法。
[0180]
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0181]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0182]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0183]
尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
[0184]
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。