云原生应用健康检测方法、装置、计算机设备及存储介质与流程

1.本发明涉及云原生技术领域，尤其涉及一种云原生应用健康检测方法、装置、计算机设备及存储介质。


背景技术：

2.云原生应用，是具备云计算基因，以云计算的思想构建并适用于云计算环境的应用。云原生应用具有如下特性：可以通过网络访问、远端部署执行、可扩展弹性伸缩、共享、按需使用自主服务、高可用、可远程监控计费审计、标准化交付与位置无关等，使得云原生应用，使得云原生应用越来越受到人们的重视。在云原生应用使用过程中，一般是将云原生应用直接部署在容器平台上，无法保障云原生应用的安全性。


技术实现要素：

3.本发明实施例提供一种云原生应用健康检测方法、装置、计算机设备及存储介质，以解决现有云原生应用无法保障其安全性的问题。
4.一种云原生应用健康检测方法，包括：
5.获取云原生应用，从所述云原生应用中确定至少一个应用组件；
6.对每一所述应用组件进行静态数据分析，获取每一所述应用组件对应的静态分析结果；
7.对每一所述应用组件进行动态数据分析，获取每一所述应用组件对应的动态分析结果；
8.根据至少一个所述应用组件对应的静态分析结果和动态分析结果，获取所述云原生应用对应的健康检测结果。
9.一种云原生应用健康检测装置，包括：
10.应用组件确定模块，用于获取云原生应用，从所述云原生应用中确定至少一个应用组件；
11.静态分析结果获取模块，用于对每一所述应用组件进行静态数据分析，获取每一所述应用组件对应的静态分析结果；
12.动态分析结果获取模块，用于对每一所述应用组件进行动态数据分析，获取每一所述应用组件对应的动态分析结果；
13.健康检测结果获取模块，用于根据至少一个所述应用组件对应的静态分析结果和动态分析结果，获取所述云原生应用对应的健康检测结果。
14.一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述云原生应用健康检测方法。
15.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述云原生应用健康检测方法。
16.上述云原生应用健康检测方法、装置、计算机设备及存储介质，将每一云原生应用的健康检测过程，拆分为对至少一个应用组件进行健康检测，获取每一应用组件对应的静态分析结果和动态分析结果，进而利用所有应用组件对应的静态分析结果和动态分析结果进行融合处理，有助于保障获取到的云原生应用的健康检测结果的准确性，以根据健康检测结果，确定云原生应用的安全性。
附图说明
17.为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
18.图1是本发明一实施例中云原生应用健康检测方法的一应用环境示意图；
19.图2是本发明一实施例中云原生应用健康检测方法的一流程图；
20.图3是本发明一实施例中云原生应用健康检测方法的另一流程图；
21.图4是本发明一实施例中云原生应用健康检测方法的另一流程图；
22.图5是本发明一实施例中云原生应用健康检测方法的另一流程图；
23.图6是本发明一实施例中云原生应用健康检测方法的另一流程图；
24.图7是本发明一实施例中云原生应用健康检测方法的另一流程图；
25.图8是本发明一实施例中云原生应用健康检测方法的另一流程图；
26.图9是本发明一实施例中云原生应用健康检测装置的一示意图；
27.图10是本发明一实施例中计算机设备的一示意图。
具体实施方式
28.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
29.本发明实施例提供的云原生应用健康检测方法，该云原生应用健康检测方法可应用如图1所示的应用环境中。具体地，该云原生应用健康检测方法应用在云原生应用健康检测系统中，该云原生应用健康检测系统包括如图1所示的客户端和服务器，客户端与服务器通过网络进行通信，用于实现对云原生应用进行健康检测，以保障部署在容器平台中的云原生应用的安全性。其中，客户端又称为用户端，是指与服务器相对应,为客户提供本地服务的程序。客户端可安装在但不限于各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备上。服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
30.在一实施例中，如图2所示，提供一种云原生应用健康检测方法，以该方法应用在图1中的服务器为例进行说明，包括如下步骤：
31.s201：获取云原生应用，从云原生应用中确定至少一个应用组件；
32.s202：对每一应用组件进行静态数据分析，获取每一应用组件对应的静态分析结
果；
33.s203：对每一应用组件进行动态数据分析，获取每一应用组件对应的动态分析结果；
34.s204：根据至少一个应用组件对应的静态分析结果和动态分析结果，获取云原生应用对应的健康检测结果。
35.其中，云原生应用是具备云计算基因，以云计算的思想构建并适用于云计算环境的应用，是需要进行健康检测的应用。应用组件是指云原生应用中实现特定功能的组件。
36.作为一示例，步骤s201中，服务器可从应用仓库中，获取需要进行健康检测的至少一个云原生应用，对每个云原生应用进行解析识别，从每个云原生应用中确定至少一个应用组件。可理解地，每一云原生应用包括至少一个应用组件，在对云原生应用进行健康检测时，需先确定至少一个应用组件，以便逐一检测分析每一应用组件的健康状态，以便根据所有应用组件的健康状态，确定云原生应用对应的健康检测结果。
37.其中，静态数据是指每一应用组件预先生成且不会随时间变化的数据。
38.作为一示例，步骤s202中，服务器在确定每一云原生应用对应的至少一个应用组件时，需对每一应用组件对应的静态数据进行检测，具体可以对每一应用组件对应的资源文件上记录的静态数据进行检测，以分析每一应用组件的健康状态，从而获取每一应用组件对应的静态分析结果。本示例中，应用组件对应的静态分析结果可以为用于反映应用组件对应的静态数据是否健康的评分结果。
39.其中，动态数据是指每一应用组件实时生成的数据，具体为随时间变化的数据。
40.作为一示例，步骤s203中，服务器在确定每一云原生应用对应的至少一个应用组件时，需对每一应用组件对应的动态数据进行检测，具体采用动态数据监控工具，对每一应用组件在云原生应用使用过程中形成的动态数据进行检测，以分析每一应用组件的健康状态，从而获取每一应用组件对应的动态分析结果。其中，动态数据监控工具是预先配置的用于监控动态数据的工具。本示例中，应用组件对应的动态分析结果可以为反映应用组件对应的动态数据是否健康的评分结果。
41.作为一示例，步骤204中，服务器在获取云原生应用中每一应用组件对应的静态分析结果和动态分析结果之后，可对至少一个应用组件对应的静态分析结果和动态分析结果进行融合处理，例如，包括但不限于加权处理，以获取每一云原生应用对应的健康检测结果。
42.本实施例所提供的云原生应用健康检测方法中，将每一云原生应用的健康检测过程，拆分为对至少一个应用组件进行健康检测，获取每一应用组件对应的静态分析结果和动态分析结果，进而利用所有应用组件对应的静态分析结果和动态分析结果进行融合处理，有助于保障获取到的云原生应用的健康检测结果的准确性，以根据健康检测结果，确定云原生应用的安全性。
43.在一实施例中，如图3所示，步骤s202，即对每一应用组件进行静态数据分析，获取每一应用组件对应的静态分析结果，包括：
44.s301：从每一应用组件对应的组件资源文件中，提取至少一个静态评估指标对应的组件静态数据；
45.s302：根据每一静态评估指标对应的静态评分对照表，对每一静态评估指标对应
的组件静态数据进行评分，获取每一静态评估指标对应的静态指标分值；
46.s302：根据至少一个静态评估指标对应的静态指标分值，获取每一应用组件对应的静态分析结果。
47.其中，组件资源文件是指每一应用组件对应的资源文件。
48.其中，静态评估指标是预先配置的用于评估静态数据是否健康的指标。本示例中，针对云原生应用的专用属性，需将pod数量、资源限制、健康检查、日志配置和部署方式等指标确定为静态评估指标。pod数量是指应用组件中记录的容器数量。资源限制可以为request和limit中的任一种。健康检查是用于实现健康检测的方式，可以为liveness方式和readiness方式中的任一种，liveness方式主要用来确定何时重启容器的检测方式，readiness方式主要来确定容器是否已经就绪的方式。日志配置是用于反映应用组件中的日志如何配置的信息。部署方式是用于反映应用组件如何部署的方式，可以为deployment和deployment config pod中的任一种。
49.其中，组件静态数据是指每一应用组件对应的静态数据，具体为记录在组件资源文件中与静态评估指标相对应的静态数据。
50.作为一示例，步骤s301中，服务器在对应用组件进行健康检测时，需根据静态数据检测标准，确定至少一个静态评估指标，即从pod数量、资源限制、健康检查、日志配置和部署方式中，确定至少一个静态评估指标。接着，服务器从每一应用组件对应的组件资源文件中，提取与至少一个静态评估指标相对应的组件静态数据，以便后续针对该组件静态数据进行健康检测。
51.其中，静态评分对照表是预先配置的用于反映静态数据及其对应分值的对照表。
52.作为一示例，步骤s302中，服务器在提取每一应用组件中至少一个静态评估指标对应的组件静态数据之后，需将每一静态评估指标对应的组件静态数据查询静态评分对照表，将静态评分对照表中与组件静态数据相对应的分值，确定为每一静态评估指标对应的静态指标分值。可理解地，根据每一静态评估指标对应的组件静态数据进行查表操作，可快速准确地获取到每一静态评估指标对应的静态指标分值。
53.作为一示例，步骤s302中，服务器在获取至少一个静态评估指标对应的静态指标分值之后，还可获取至少一个静态评估指标对应的静态指标权重，对所有静态评估指标对应的静态指标分值和静态指标权重进行加权处理，将加权处理的分值，确定为每一应用组件对应的静态分析结果。其中，静态指标权重是预先配置的每一静态评分指标的权重。本示例中，至少一个静态评估指标对应的静态指标权重，由至少一个静态评估指标对应用组件健康评估的重要性决定，重要性越高，其静态指标权重越高。
54.本实施例中，利用应用组件对应的组件资源文件中，提取到的至少一个静态评估指标对应的组件静态数据查表，可快速准确地获取每一静态评估指标对应的静态指标分值，再利用静态指标分值与其对应的静态指标权重进行加权处理，可快速获取其对应的静态分析结果，可使静态分析结果综合考虑至少一个静态评估指标的重要性，保障静态分析结果的准确性。
55.在一实施例中，如图4所示，步骤s203，即对每一应用组件进行动态数据分析，获取每一应用组件对应的动态分析结果，包括：
56.s401：采用容器监控工具，对每一应用组件对应的动态数据进行监控分析，获取第
一动态监控结果；
57.s402：采用日志采集器，对每一应用组件对应的动态数据进行监控分析，获取第二动态监控结果；
58.s403：采用健康状态监控工具，对每一应用组件对应的动态数据进行监控分析，获取第三动态监控结果；
59.s404：根据第一动态监控结果、第二动态监控结果和第三动态监控结果，获取每一应用组件对应的动态分析结果。
60.其中，容器监控工具是预先配置的用于实现对容器平台的资源及网络进行监控的工具。第一动态监控结果是容器监控工具对应用组件的动态数据进行监控分析的结果。
61.作为一示例，步骤s401中，服务器在对应用组件进行健康检测时，需采用容器监控工具，对部署在容器平台上的云原生应用工作过程中形成的动态数据进行动态监控，具体对每一应用组件工作过程形成的动态数据进行动态监控，以获取第一动态监控结果。
62.本示例中，服务器采用容器监控工具，对每一应用组件工作过程中的资源用量及网络情况等动态数据进行动态监控，以获取第一动态监控结果。其中，资源用量是指cpu或内存等资源的使用情况，可有效反映云原生应用中的每一应用组件的资源使用情况。例如，在0-50％时，认定存在资源浪费；在50％-80％时，认定正常使用；在80％-90％时，认定需要警惕处理；在超过90％时，认定处于危险状态。网络情况是用于反映网络访问或者其他与网络相关的情况，可有效反映云原生应用中的每一应用组件的网络通信情况。可理解地，采用容器监控工具，对应用组件中的资源用量及网络情况进行动态监控，可保障第一动态监控结果获取的实时性。
63.其中，日志采集器是预先配置的用于实现对云原生应用工作过程中形成的动态数据进行监控的工具。第二动态监控结果是日志采集器对应用组件的动态数据进行监控分析的结果。
64.作为一示例，步骤s402中，服务器在对应用组件进行健康检测时，需采用日志采集器，对云原生应用工作过程中形成的动态数据进行动态监控，具体对每一应用组件工作过程形成的动态数据进行动态监控，以获取第二动态监控结果。
65.本示例中，服务器采用日志采集器，对每一应用组件工作过程中形成的日志数据及磁盘空间用量等动态数据进行动态监控，以获取第二动态监控结果。其中，日志数据是用于反映每一应用组件中的所有访问日志及其响应情况所形成的数据，可在一定程度上反映云原生应用中的每一应用组件的繁忙情况。磁盘空间用量是用于反映每一应用组件工作过程所需采用到的磁盘空间，即每一应用组件工作过程中存储数据所需采用到的磁盘空间，可在一定程度上反映云原生应用中的每一应用组件的繁忙情况。
66.其中，健康状态监控工具是预先配置的用于对云原生应用工作过程中形成的与健康状态相关的信息进行监控的工具。第二动态监控结果是健康状态监控工具对应用组件的动态数据进行监控分析的结果。
67.作为一示例，步骤s403中，服务器对应用组件进行健康检测时，需采用健康状态监控工具，对云原生应用工作过程中形成的动态数据进行动态监控，具体对每一应用组件工作过程形成的动态数据进行动态监控，以获取第三动态监控结果。
68.本示例中，服务器采用健康状态监控工具，对每一应用组件工作过程中形成的服
务链路追踪、service健康和router健康等动态数据进行动态监控，获取应用组件对应的第三动态监控结果。服务链路追踪是指至少一个服务形成的链路的追踪情况。service健康是指服务的健康情况，具体可理解为某个服务是否正常进行的情况。router健康是指路由的健康情况，具体中理解为某个路由转发数据是否正常的情况。
69.作为一示例，步骤404中，服务器可基于第一动态监控结果、第二动态监控结果和第三动态监控结果，分别查询预先配置的动态评分对照表，将动态评分对照表中，与第一动态监控结果、第二动态监控结果和第三动态监控结果相对应的分值，分别确定为第一动态评分值、第二动态评分值和第三动态评分值。接着，服务器获取预先配置的第一动态权重、第二动态权重和第三动态权重，对第一动态评分值。第一动态权重、第二动态评分值、第二动态权重、第三动态评分值和第三动态权重进行加权处理，将加权处理后的分值，确定为每一应用组件对应的动态分析结果。本示例中，第一动态权重、第二动态权重和第三动态权重，分别为第一动态评分值、第二动态评分值和第三动态评分值对应的权重，以预先根据资源用量及网络情况、日志数据及磁盘空间用量、服务链路追踪、service健康和router健康等动态数据的重要性配置的权重。
70.本实施例中，采用容器监控工具、日志采集器和健康状态监控工具分别进行动态数据监控，以获取第一动态监控结果、第二动态监控结果和第三动态监控结果，再对获取到的三个动态监控结果进行加权，以快速获取其对应的动态分析结果，使得动态分析结果综合考虑三个动态监控结果，保障动态分析结果的准确性。
71.在一实施例中，如图5所示，步骤s204，即根据至少一个应用组件对应的静态分析结果和动态分析结果，获取云原生应用对应的健康检测结果，包括：
72.s501：根据每一应用组件对应的静态分析结果和动态分析结果，获取每一应用组件对应的组件检测结果；
73.s502：根据至少一个应用组件对应的组件检测结果，获取云原生应用对应的健康检测结果。
74.作为一示例，步骤s501中，服务器可获取预先配置的组件静态权重和组件动态权重，对每一应用组件对应的静态分析结果、组件静态权重、动态分析结果和组件动态权重进行加权处理，根据加权处理结果，获取每一应用组件的组件检测结果。其中，组件静态权重是预先配置的用于评估静态分析结果的权重。组件动态权重是预先配置的用于评估动态分析结果的权重。
75.作为一示例，步骤s502中，服务器在获取每一应用组件对应的组件检测结果之后，可根据预先配置的组件综合评估规则，对至少一个应用组件对应的组件检测结果进行综合分析，以综合分析每一云原生应用的健康情况，获取云原生应用对应的健康检测结果。组件综合评估规则是预先配置的用于对所有应用组件的组件检测结果进行综合评估的规则。
76.本实施例中，根据每一应用组件的静态分析结果和动态分析结果，确定其组件检测结果，再对所有应用组件的组件检测结果进行综合分析，有助于保障最终获取到的健康检测结果的准确性。
77.在一实施例中，如图6所示，步骤s502，即根据至少一个应用组件对应的组件检测结果，获取云原生应用对应的健康检测结果，包括：
78.s601：根据每一应用组件对应的组件检测结果，确定每一应用组件对应的组件安
全等级；
79.s602：若存在应用组件对应的组件安全等级为高风险等级，则获取存在风险的健康检测结果；
80.s603：若不存在应用组件对应的组件安全等级为高风险等级，则根据至少一个应用组件对应的组件安全等级，获取云原生应用对应的风险评分值；
81.s604：若风险评分值大于目标评分阈值，则获取存在风险的健康检测结果；
82.s605：若风险评分值不大于目标评分阈值，则获取不存在风险的健康检测结果。
83.作为一示例，步骤s601中，服务器获取每一应用组件对应的组件检测结果，该组件检测结果是对每一应用组件对应的静态分析结果、组件静态权重、动态分析结果和组件动态权重进行加权处理的结果；再基于该组件检测结果查询预先配置的风险等级对照表，将风险等级对照表中与组件检测结果相匹配的风险等级，确定为应用组件对应的组件安全等级。其中，风险等级对照表是预先配置的用于反映组件检测结果与其风险等级之间对应关系的对照表。应用组件对应的组件安全等级为基于组件检测结果查表获取的安全等级，可以为高风险等级、中风险等级和低风险等级中的任一个。
84.作为一示例，步骤s602中，服务器在至少一个应用组件对应的组件安全等级中，存在应用组件对应的组件安全等级为高风险等级时，认定云原生应用中存在至少一个高风险的应用组件，此时，可直接获取存在风险的健康检测结果，以便后续根据健康检测结果对云原生应用进行处理。
85.作为一示例，步骤s603中，服务器在至少一个应用组件对应的组件安全等级中，不存在应用组件对应的组件安全等级为高风险等级时，即所有应用组件的组件安全等级均为中风险等级或低风险等级时，也就是说云原生应用不存在高风险的应用组件时，此时，需采用预先配置的风险综合评估规则，对至少一个应用组件对应的组件安全等级进行分析处理，以获取云原生应用对应的风险评分值。该风险综合评估规则是预先配置的用于实现对所有应用组件的组件安全等级进行综合处理，以确定其最终的评分值的规则。
86.其中，目标评分阈值是预先配置的用于评分是否达到存在风险标准的阈值。
87.作为一示例，步骤s604中，服务器在根据至少一个组件安全等级，确定其风险评分值之后，需将该风险评分值与预先配置的目标评分阈值进行比较；若风险评分值大于目标评分阈值，认定达到存在风险标准，此时，可获取存在风险的健康检测结果。
88.作为一示例，步骤s605中，服务器在根据至少一个组件安全等级，确定其风险评分值之后，需将该风险评分值与预先配置的目标评分阈值进行比较；若风险评分值不大于目标评分阈值，认定没有达到存在风险标准，此时，可获取不存在风险的健康检测结果。
89.本实施例中，根据应用组件对应的组件检测结果，确定其组件安全等级之后，若存在组件安全等级为高风险等级，则可直接获取存在风险的健康检测结果，以保障存在风险的健康检测结果的获取效率，有助于保障后续对云原生应用进行处理的时效性。若不存在组件安全等级为高风险等级，可根据综合分析出的风险评分值与目标评分阈值的比较结果，确定是否存在风险，获取相应的健康检测结果，有助于保障健康检测结果获取的准确性。
90.在一实施例中，如图7所示，步骤s603，即根据至少一个应用组件对应的组件安全等级，获取云原生应用对应的风险评分值，包括：
91.s701：统计组件安全等级为中风险等级对应的应用组件的数量，确定为第一组件数量；
92.s702：统计云原生应用中所有应用组件的数量，确定为第二组件数量；
93.s703：根据第一组件数量和第二组件数量，获取云原生应用对应的风险评分值。
94.作为一示例，步骤s701中，服务器在需要根据至少一个应用组件对应的组件安全等级，获取其对应的风险评分值的前提是所有组件安全等级均不为高风险等级，则说明所有应用组件的组件安全等级均为中风险等级或低风险等级。由于中风险等级反映应用组件存在风险的概率较高，因此，服务器需统计组件安全等级为中风险等级对应的应用组件的数量，确定为第一组件数量，以便根据第一组件数量，确定云原生应用中有多少个应用组件的组件安全等级为中风险等级。
95.作为一示例，步骤s702中，服务器在需要根据至少一个应用组件对应的组件安全等级，获取其对应的风险评分值的情况下，需统计云原生应用中所有应用组件的数量，以确定第二组件数量，该第二组件数量可反映云原生应用中有多少个应用组件。
96.作为一示例，步骤s703中，服务器在获取第一组件数量和第二组件数量之后，可将该第一组件数量和第二组件数量的商值，确定为云原生应用对应的风险评分值。该风险评分值可有效反映中风险等级的应用组件的数量占所有应用组件的数量的占比，该占比越高，说明越大比例的应用组件为中风险等级对应的应用组件，风险越高。
97.本实施例中，根据组件安全等级为中风险等级的应用组件的第一组件数量，和所有应用组件对应的第二组件数量，确定云原生应用对应的风险评分值，可有效反映中风险等级对应的应用组件的占比，进而反映云原生应用的风险情况。
98.在一实施例中，如图8所示，步骤s204之后，即在根据至少一个应用组件对应的静态分析结果和动态分析结果，获取云原生应用对应的健康检测结果之后，云原生应用健康检测方法还包括：
99.s801：若云原生应用对应的健康检测结果为存在风险，则执行溯源提醒策略，向部署云原生应用的容器平台发送风险提醒消息；
100.s802：若云原生应用对应的健康检测结果为不存在风险，则重复执行获取云原生应用，从云原生应用中确定至少一个应用组件。
101.其中，溯源提醒策略是指需要溯源确定哪些容器平台部署有存在风险的云原生应用，并对部署的容器平台进行提醒的策略。
102.作为一示例，步骤s801中，服务器在确定每一云原生应用对应的健康检测结果为存在风险时，服务器可执行溯源提醒策略，先根据云原生应用形成形成风险提醒消息，该风险提醒消息具体可以包括所有应用组件对应的组件安全等级等详细信息；需查询云原生应用的部署详情信息表，确定哪些容器平台部署有该云原生应用；最后，将风险提醒消息发送给部署有存在风险的云原生应用的容器平台，以使该容器平台的用户可根据接收到的风险提醒消息进行后续的风险管控，进而保障容器平台上部署的云原生应用的安全性。
103.作为一示例，步骤s802中，服务器在确定每一云原生应用对应的健康检测结果为不存在风险时，可在预先配置的定时监控时段后，重复执行获取云原生应用，从云原生应用中确定至少一个应用组件，即重复执行上述步骤s201-s204，以实现对云原生应用进行定时健康检测，以保障保障容器平台上部署的云原生应用的安全性。
104.应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
105.在一实施例中，提供一种云原生应用健康检测装置，该云原生应用健康检测装置与上述实施例中云原生应用健康检测方法一一对应。如图9所示，该云原生应用健康检测装置包括应用组件确定模块901、静态分析结果获取模块902、动态分析结果获取模块903和健康检测结果获取模块904。各功能模块详细说明如下：
106.应用组件确定模块901，用于获取云原生应用，从云原生应用中确定至少一个应用组件；
107.静态分析结果获取模块902，用于对每一应用组件进行静态数据分析，获取每一应用组件对应的静态分析结果；
108.动态分析结果获取模块903，用于对每一应用组件进行动态数据分析，获取每一应用组件对应的动态分析结果；
109.健康检测结果获取模块904，用于根据至少一个应用组件对应的静态分析结果和动态分析结果，获取云原生应用对应的健康检测结果。
110.在一实施例中，静态分析结果获取模块902，包括：
111.组件静态数据获取单元，用于从每一应用组件对应的组件资源文件中，提取至少一个静态评估指标对应的组件静态数据；
112.静态指标分值获取单元，用于根据每一静态评估指标对应的静态评分对照表，对每一静态评估指标对应的组件静态数据进行评分，获取每一静态评估指标对应的静态指标分值；
113.静态分析结果获取单元，用于根据至少一个静态评估指标对应的静态指标分值，获取每一应用组件对应的静态分析结果。
114.在一实施例中，动态分析结果获取模块903，包括：
115.第一动态监控结果获取单元，用于采用容器监控工具，对每一应用组件对应的动态数据进行监控分析，获取第一动态监控结果；
116.第二动态监控结果获取单元，用于采用日志采集器，对每一应用组件对应的动态数据进行监控分析，获取第二动态监控结果；
117.第三动态监控结果获取单元，用于采用健康状态监控工具，对每一应用组件对应的动态数据进行监控分析，获取第三动态监控结果；
118.动态分析结果获取单元，用于根据第一动态监控结果、第二动态监控结果和第三动态监控结果，获取每一应用组件对应的动态分析结果。
119.在一实施例中，健康检测结果获取模块904，包括：
120.组件检测结果获取单元，用于根据每一应用组件对应的静态分析结果和动态分析结果，获取每一应用组件对应的组件检测结果；
121.健康检测结果获取单元，用于根据至少一个应用组件对应的组件检测结果，获取云原生应用对应的健康检测结果。
122.在一实施例中，健康检测结果获取单元，包括：
123.组件安全等级获取子单元，用于根据每一应用组件对应的组件检测结果，确定每
一应用组件对应的组件安全等级；
124.第一健康检测结果获取子单元，用于若存在应用组件对应的组件安全等级为高风险等级，则获取存在风险的健康检测结果；
125.组件安全等级获取子单元，用于若不存在应用组件对应的组件安全等级为高风险等级，则根据至少一个应用组件对应的组件安全等级，获取云原生应用对应的风险评分值；
126.第二健康检测结果获取子单元，用于若风险评分值大于目标评分阈值，则获取存在风险的健康检测结果；
127.第三健康检测结果获取子单元，用于若风险评分值不大于目标评分阈值，则获取不存在风险的健康检测结果。
128.在一实施例中，组件安全等级获取子单元，包括：
129.第一组件数量确定次级单元，用于统计组件安全等级为中风险等级对应的应用组件的数量，确定为第一组件数量；
130.第二组件数量确定次级单元，用于统计云原生应用中所有应用组件的数量，确定为第二组件数量；
131.风险评分值确定次级单元，用于根据第一组件数量和第二组件数量，获取云原生应用对应的风险评分值。
132.在一实施例中，云原生应用健康检测装置还包括：
133.溯源提醒单元，用于若云原生应用对应的健康检测结果为存在风险，则执行溯源提醒策略，向部署云原生应用的容器平台发送风险提醒消息；
134.重复检测单元，用于若云原生应用对应的健康检测结果为不存在风险，则重复执行获取云原生应用，从云原生应用中确定至少一个应用组件。
135.关于云原生应用健康检测装置的具体限定可以参见上文中对于云原生应用健康检测方法的限定，在此不再赘述。上述云原生应用健康检测装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
136.在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图10所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储执行云原生应用健康检测方法过程中采用或生成的数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种云原生应用健康检测方法。
137.在一实施例中，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述实施例中云原生应用健康检测方法，例如图2所示s201-s204，或者图3至图8中所示，为避免重复，这里不再赘述。或者，处理器执行计算机程序时实现云原生应用健康检测装置这一实施例中的各模块/单元的功能，例如图9所示的应用组件确定模块901、静态分析结果获取模块902、动态分析结果
获取模块903和健康检测结果获取模块904的功能，为避免重复，这里不再赘述。
138.在一实施例中，提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中云原生应用健康检测方法，例如图2所示s201-s204，或者图3至图8中所示，为避免重复，这里不再赘述。或者，该计算机程序被处理器执行时实现上述云原生应用健康检测装置这一实施例中的各模块/单元的功能，例如图9所示的应用组件确定模块901、静态分析结果获取模块902、动态分析结果获取模块903和健康检测结果获取模块904的功能，为避免重复，这里不再赘述。
139.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。
140.所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。
141.以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。