一种公有云多资源池运维监控系统的制作方法

1.本发明涉及运维监控技术领域，具体涉及一种公有云多资源池运维监控系统。


背景技术：

2.云计算发展至今，公有云服务在中小型企业中扮演着举足轻重的角色。对于一个互联网项目，拥有几台、几十台、甚至几百台服务器都是很正常的需求，大多数中小型企业、个人，都选择采用云计算服务商提供的云主机、云服务器等。
3.保证这些云主机、云服务器的稳定、正常运行，对服务商来说就尤为重要。开源的prometheus软件是当前监控领域的标杆，开源界绝大部分监控产品都是以prometheus为基础组件或数据协议。常见的多资源池分布式监控多以prometheus、prometheus联邦集群、thanos集群或全链路自研如open-falcon等方案落地。
4.而在上述方案中，通过现有的prometheus软件实现多资源池的运维监控，数据采集的灵活性较差。


技术实现要素：

5.本技术提供了一种公有云多资源池运维监控系统，提高了数据采集的灵活性，该技术方案如下。
6.本技术提供的一种公有云多资源池运维监控系统包括数据采集装置、数据处理装置以及数据存储装置；
7.所述数据采集装置包含数据采集工具；所述数据采集工具包括push模型以及pull模式；所述数据采集工具用于通过pull模式向被监控组件请求数据；所述数据采集工具还用于通过push接收所述监控组件推送的数据；
8.所述数据处理装置中包括prometheus模块以及thanos数据处理模块；所述prometheus模块用于接收所述数据采集装置采集到的数据，并通过thanos数据处理模块传输至数据存储装置。
9.在一种可能的实现方式中，所述数据采集工具安装在待检测设备上，所述数据采集工具包括插件池单元、采集处理单元以及采集发送单元；
10.所述插件池单元包括各个采集插件，以对待检测设备的各个数据情况进行数据采集；
11.所述采集处理单元中包括采集处理插件；所述采集处理单元用于对所述插件池单元采集到的数据进行采集处理，并发送至采集发送单元；
12.所述采集发送单元中包括第一http接口以及第二http接口；所述第一http接口用于支撑prometheus pull模式拉取数据；所述第二http接口用于通过push模式将少量数据直接发送到prometheus模块。
13.在一种可能的实现方式中，所述采集处理插件包括多个数据处理插件，以按需对采集插件的数据进行处理；所述多个数据处理插件至少包括数据精度处理插件和数据粒度
处理插件。
14.在一种可能的实现方式中，所述prometheus模块获取目标资源位置，并按照指定周期通过pull模式拉取数据；
15.所述prometheus模块还可以接收到所述待检测设备上的数据采集工具通过push模式推送的数据。
16.在一种可能的实现方式中，所述prometheus模块还用于存储在指定时长区间内接收到的数据；所述thanos数据处理模块用于按照指定时间区间对应的时间间隔，将所述prometheus模块存储的数据发送至数据存储装置。
17.在一种可能的实现方式中，所述数据存储装置中包含数据接收模块、分布式的文件存储模块和数据查询模块；
18.所述数据接收模块用于接收thanos数据处理模块发送的数据，并压缩为数据块存储至分布式的文件存储模块中；
19.所述数据查询模块用于根据接收到的用户查询请求，在所述分布式文件存储模块中查询对应的数据。
20.在一种可能的实现方式中，所述数据存储装置中还包括数据压缩模块；
21.所述数据压缩模块将各个数据包按照prometheus数据规则进行合并。
22.在一种可能的实现方式中，所述系统还包括告警装置；
23.所述告警装置中包括规则引擎模块以及通知模块；
24.所述规则引擎模块用于周期性地调用数据查询接口，以持续对数据存储装置进行告警检测；
25.所述通知模块用于接收所述规则引擎模块生成的告警信息，并将所述告警信息发送对应的终端设备。
26.在一种可能的实现方式中，所述规则引擎模块用于从web页面或api接口获取报警配置，并将所述报警配置写入数据库，以使所述规则引擎模块周期性读取数据库配置数据，并周期性调用数据查询接口，以持续对数据存储装置进行告警检测。
27.在一种可能的实现方式中，所述规则引擎模块还用于当生成各个告警数据时，根据各个告警数据的标签值，将所述各个告警数据进行聚合，以使所述通知模块将聚合后的告警数据发送给对应的终端设备。
28.本技术提供的技术方案可以包括以下有益效果：
29.为了实现对公有云多资源池进行运维监控，可以在云服务器中设置公有云多资源池运维监控系统，且该系统包括数据采集装置、数据处理装置以及数据存储装置；其中数据采集装置包括数据采集工具，该数据采集工具及可以通过pull模式向被监控组件请求数据，也可以接收通过push模式推送的数据，而数据处理装置则可以获取通过prometheus模块接收数据采集装置采集到的数据，并传输至数据存储装置。通过上述方案，prometheus作为中间数据传输组件，同时具备数据推、拉模式，用户(运维人员)可以按需将数据push到数据存储端，极大的减少了服务维护方的开发量，提高了监控数据采集的灵活性。
附图说明
30.为了更清楚地说明本技术具体实施方式或现有技术中的技术方案，下面将对具体
实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本技术的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
31.图1是根据一示例性实施例示出的一种云计算系统的结构示意图。
32.图2是根据一示例性实施例示出的一种公有云多资源池运维监控系统的结构示意图。
33.图3示出了本技术实施例涉及的一种数据采集装置的结构示意图。
34.图4示出了本技术实施例涉及的一种数据存储装置的结构示意图。
35.图5示出了本技术实施例涉及的一种告警装置示意图。
36.图6示出了本技术实施例涉及的一种自底向上的系统整体架构图。
37.图7是根据本技术一示例性实施例提供的一种计算机设备示意图。
具体实施方式
38.下面将结合附图对本技术的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
39.应理解，在本技术的实施例中提到的“指示”可以是直接指示，也可以是间接指示，还可以是表示具有关联关系。举例说明，a指示b，可以表示a直接指示b，例如b可以通过a获取；也可以表示a间接指示b，例如a指示c，b可以通过c获取；还可以表示a和b之间具有关联关系。
40.在本技术实施例的描述中，术语“对应”可表示两者之间具有直接对应或间接对应的关系，也可以表示两者之间具有关联关系，也可以是指示与被指示、配置与被配置等关系。
41.本技术实施例中，“预定义”可以通过在设备(例如，包括终端设备和网络设备)中预先保存相应的代码、表格或其他可用于指示相关信息的方式来实现，本技术对于其具体的实现方式不做限定。
42.在对本技术所示的各个实施例进行说明之前，首先对本技术涉及到的几个概念进行介绍。
43.1)云技术
44.云技术(cloud technology)是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。
45.2)云计算
46.云计算(cloud computing)是分布式计算的一种，指的是通过网络“云”将巨大的数据计算处理程序分解成无数个小程序，然后，通过多部服务器组成的系统进行处理和分析这些小程序得到结果并返回给用户。云计算早期，简单地说，就是简单的分布式计算，解
决任务分发，并进行计算结果的合并。因而，云计算又称为网格计算。通过这项技术，可以在很短的时间内(几秒钟)完成对数以万计的数据的处理，从而达到强大的网络服务。
47.图1是根据一示例性实施例示出的一种云计算系统的结构示意图。该系统包括终端120以及云服务器110。
48.可选的，该终端120可以通过api(application programming interface，应用程序接口)向该云服务器110调用应用实例，以实现应用实例对应的数据处理功能。
49.可选的，该第一应用实例可以是容器化的实例。
50.可选的，该云服务器110可以根据终端120发送的，与应用实例对应的api调用请求，对终端120发送的数据进行处理，并将结果返回至终端120中。
51.可选的，该云服务器110中加载有公有云资源池运维监控系统，该系统用于对该云服务器中的各个机器进行运维监控操作，以避免该云服务器中的机器出现问题导致云计算系统的错误或崩溃。
52.可选的，在本技术中，该公有云资源池运维监控系统可以是基于prometheus软件构建的。
53.可选的，该终端可以是具有数据处理功能以及数据存储功能的终端设备，该终端可以包括一个终端，也可以包括多个终端，本技术实施例对该终端的数量不设限制。该终端可以是智能手机、平板电脑、笔记本电脑、台式计算机等具有数据处理器以及数据存储组件的终端设备，但不局限于此。
54.可选的，该云服务器可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn、以及大数据和人工智能平台等基础运计算服务的云服务器。
55.可选的，该云服务器110与该终端120之间可以通过通信网络相连。可选的，该通信网络可以是有线网络或无线网络。
56.可选的，上述的无线网络或有线网络使用标准通信技术和/或协议。网络通常为因特网，但也可以是其他任何网络，包括但不限于局域网、城域网、广域网、移动、有限或无线网络、专用网络或者虚拟专用网络的任何组合。在一些实施例中，使用包括超文本标记语言、可扩展标记语言等的技术和/或格式来代表通过网络交换的数据。此外还可以使用诸如安全套接字层、传输层安全、虚拟专用网络、网际协议安全等常规加密技术来加密所有或者一些链路。在另一些实施例中，还可以使用定制和/或专用数据通信技术取代或者补充上述数据通信技术。
57.图2是根据一示例性实施例示出的一种公有云多资源池运维监控系统的结构示意图。该公有云多资源池运维监控系统可以安装在云服务器中该云服务器可以是如图1中所示的云计算系统中的云服务器110。如图2所示，该公有云多资源池运维监控系统可以包括数据采集装置、数据处理装置以及数据存储装置；
58.所述数据采集装置包含数据采集工具；所述数据采集工具包括push模型以及pull模式；所述数据采集工具用于通过pull模式向被监控组件请求数据；所述数据采集工具还用于通过push接收所述监控组件推送的数据；
59.所述数据处理装置中包括prometheus模块以及thanos数据处理模块；所述prometheus模块用于接收所述数据采集装置采集到的数据，并通过thanos数据处理模块传
输至数据存储装置。
60.可选的，在本技术实施例中，该数据采集装置可以是安装在云服务器中的目标设备上，该云服务器中的各个机器(也就是目标设备)上安装有监控组件(即数据采集装置中的数据采集工具)，该监控组件用于对自身所在的机器进行数据采集，例如监控该机器的运行状态、该机器所接收到的数据信息等。
61.当监控组件对机器进行数据采集，得到监控数据后，在一种可能的实现方式中，监控组件可以通过pull模式将采集到的监控数据传输至数据采集装置中的数据采集工具。即数据采集工具先确定需要监控的机器，并向其发送数据拉取请求，从而实现数据采集工具主动向各个机器通过pull模式拉取数据。
62.在另一种可能的实现方式中，监控组件还可以通过push模式主动将采集到的监控数据推送至数据采集装置。
63.当数据采集装置采集到数据(也就是监控数据)后，则可以发送至数据处理装置中的prometheus模块，并暂时保存在prometheus模块中，而后数据处理装置中的thanos数据处理模块每隔一段时间将暂存在prometheus模块中的监控数据发送至数据存储装置中。
64.在一种可能的实现方式中，所述数据采集工具安装在待检测设备上，所述数据采集工具包括插件池单元、采集处理单元以及采集发送单元；
65.所述插件池单元包括各个采集插件，以对待检测设备的各个数据情况进行数据采集；
66.所述采集处理单元中包括采集处理插件；所述采集处理单元用于对所述插件池单元采集到的数据进行采集处理，并发送至采集发送单元；
67.所述采集发送单元中包括第一http接口以及第二http接口；所述第一http接口用于支撑prometheus pull模式拉取数据；所述第二http接口用于通过push模式将少量数据直接发送到prometheus模块。
68.请参考图3，其示出了本技术实施例涉及的一种数据采集装置的结构示意图，如图3所示，数据采集装置包含一个支持prometheus数据结构的基于push/pull模式的监控agent。agent是个golang语言实现的插件agent，分为采集-处理-传输三个部分。前面的数据采集并行插件(也就是插件池单元)是并行的goroutine实现的插件池，每个routine管理一个采集插件，采集到的数据都会通过go channel发送到数据处理部分；即在一种可能的实现方式中，如图3所示，所述采集插件包括基础监控数据采集插件、进程数据采集插件、业务服务状态采集插件中的至少一者。
69.中间的数据并行pipeline插件群(也就是采集处理单元)，是串行的数据处理逻辑，我们会实现一些如数据精度处理、数据按分钟聚合的数据粒度处理等处理操作，然后将处理完的数据通过channel发送到数据发送部分。即在一种可能的实现方式中，所述采集插件包括基础监控数据采集插件、进程数据采集插件、业务服务状态采集插件中的至少一者。
70.最后的数据处理部分(也就是采集发送单元)跟数据采集部分类似也是并行处理，首先他会暴露一个http接口，供prometheus pull模式拉取数据，其次我们也实现了prometheus http client接口，可以将少量数据直接发送到目标prometheus，另外我们也根据prometheus pushgateway实现了pushgateway的数据发送方式。在一种可能的实现方式中，该采集发送单元，包括如图3所示的数据发送并行插件(sender)，该数据发送并行插
件包括kafka发送插件以及prometheusremotewrite发送插件中的至少一者。
71.在一种可能的实现方式中，在数据处理装置中所述prometheus模块获取目标资源位置，并按照指定周期通过pull模式拉取数据；
72.所述prometheus模块还可以接收到所述待检测设备上的数据采集工具通过push模式推送的数据。
73.在一种可能的实现方式中，所述prometheus模块还用于存储在指定时长区间内接收到的数据；所述thanos数据处理模块用于按照指定时间区间对应的时间间隔，将所述prometheus模块存储的数据发送至数据存储装置。
74.即资源池内数据处理装置包括了开源的prometheus和thanos数据处理模块。传统prometheus需要一个consul/etcd等服务发现组件为prometheus生成采集目标的配置，prometheus通过consul等中间件获得target位置，并周期性pull数据。而本装置agent在此基础上，还部分支持push模式，将数据直接送往prometheus http接口。prometheus存储数据，并每两小时由thanos数据处理模块将prometheus暂存的两小时数据发往中央存储装置。
75.在一种可能的实现方式中，所述数据存储装置中包含数据接收模块、分布式的文件存储模块和数据查询模块；
76.所述数据接收模块用于接收thanos数据处理模块发送的数据，并压缩为数据块存储至分布式的文件存储模块中；
77.所述数据查询模块用于根据接收到的用户查询请求，在所述分布式文件存储模块中查询对应的数据。
78.在一种可能的实现方式中，所述数据存储装置中还包括数据压缩模块；
79.所述数据压缩模块将各个数据包按照prometheus数据规则进行合并。
80.请参考图4，其示出了本技术实施例涉及的一种数据存储装置的结构示意图。如图4所示，数据存储装置以开源的thanos软件为基础架构，包括数据接收模块、分布式的文件存储模块、数据压缩与降采样模块和数据查询模块。
81.a)数据接收模块是一个无状态的服务集群(包括多个网关gateway)，会将资源池内thanos数据处理服务发送过来的prometheus数据以块为单位处理并存储到数据存储模块中。
82.b)数据存储模块采用了thanos官方推荐的minio存储集群，他可以任意的横纵向扩容，并直接使用机械硬盘，无需高额存储成本。
83.c)数据存储模块搭配了一套数据压缩和降采样模块。
84.中央数据存储装置会存储所有资源池上传上来的以两小时为传输频率的数据包，数据包是prometheus数据存储的原始格式，每个数据包都会存储为一个小文件。很明显，两个小时存储一个文件，在长时间存储时，会让存储服务器产生大量的小文件，可能造成inode耗尽的风险。此外，一次跨越多个小时时间范围的查询，也需要读取多个文件再进行合并，这降低了数据读取的性能。
85.数据压缩模块会定时的(比如每天)，将小文件按prometheus数据规则合并为大文件，以提高存储服务性能。
86.另外，用户在查询长时间跨度监控数据的时候，可能需要更粗的数据粒度以查看
数据趋势，比如查询1周的30分钟监控粒度的数据来查看磁盘使用量变化快慢。原始数据多以一分钟粒度为主，查询方需要读取出所有一分钟粒度数据然后再聚合成五分钟粒度，这样需要消耗大量的算力和时间。本模块在进行数据压缩的时候，可以根据配置同时进行数据降采样：在进行数据块压缩的同时，对大周期数据进行采样，比如每30分钟的数据只挑选第一个点存储，1分钟粒度数据存储为30分钟粒度数据，确保粗粒度数据能存储更长时间。
87.d)查询模块是一套无状态的数据查询集群。从上文得知，资源池内数据会每两小时将数据推送到中心存储，而未到两小时的数据将会存储在资源池内部。查询组件query会将用户的查询请求分别发送到资源池内核中央存储装置，再将两者查询到的结果进行汇聚，确保拿出完整的数据。
88.在一种可能的实现方式中，所述系统还包括告警装置；
89.所述告警装置中包括规则引擎模块以及通知模块；
90.所述规则引擎模块用于周期性地调用数据查询接口，以持续对数据存储装置进行告警检测；
91.所述通知模块用于接收所述规则引擎模块生成的告警信息，并将所述告警信息发送对应的终端设备。
92.在一种可能的实现方式中，所述规则引擎模块用于从web页面或api接口获取报警配置，并将所述报警配置写入数据库，以使所述规则引擎模块周期性读取数据库配置数据，并周期性调用数据查询接口，以持续对数据存储装置进行告警检测。
93.在一种可能的实现方式中，所述规则引擎模块还用于当生成各个告警数据时，根据各个告警数据的标签值，将所述各个告警数据进行聚合，以使所述通知模块将聚合后的告警数据发送给对应的终端设备。
94.请参考图5，其示出了本技术实施例涉及的一种告警装置示意图。如图5所示，规则引擎模块有别于市面上的prometheus和其分支的yaml文件管理配置的模式，传统的prometheus.rules、thanos.rules等报警匹配功能，需要通过用户手动将报警配置编写成yaml、或者是将配置发送到consul然后使用consul_template等开源组件将consul数据生成rules的配置文件，这样的流程繁琐、易出错、且不灵活。
95.而本模块可以直接接收从web页面或者api接口传入的报警配置，并将配置直接写入数据库。规则引擎则周期性的读去数据库配置数据，并模拟prometheus.rules运行模式，周期性调用数据查询接口，持续产生报警信息。
96.更重要的是，本模块可以按照用户配置，将报警按lable分组，包含同一个label值(如project＝monitor)的不同报警对象(比如多个ip)，都会被收敛到同一条报警中来，这样就避免了相同类型报警多次发送的问题。其次，同一个分组下的报警只会有限次发送。如：第一个ip产生报警的时候发送报警，此后每分钟会更新当前报警状态，但不会发送报警，10分钟之后又来了一个ip产生同样报警，这时候会发送一条新增报警，之后每分钟继续更新报警状态。如此即可达到自动报警抑制的效果，降低产生告警风暴的风险。
97.另外，长时间未更新的报警，也会以prometheus同等的效果做报警恢复。
98.通知模块独立于规则引擎，他接收规则引擎产生的报警数据，将数据通知到任意配置的包括用户、用户组的短信、电话、微信等通讯工具。
99.请参考图6，其示出了本技术实施例涉及的一种自底向上的系统整体架构图。如图
6所示，本技术实施例涉及的一种自底向上的系统架构，是以服务器端操作系统，也就是windows系统或linux系统为底层架构。在该服务器端操作系统上，构建有服务器数据采集装置，用于对服务器内的各个机器进行数据采集。
100.如图6所示的系统中还包括有资源池内数据处理组件，以对服务器数据采集装置采集到的数据进行处理。
101.如图6所示的系统中还包括数据中间件，该数据中间件设置在底层数据库和用户应用系统之间，主要用于屏蔽异构数据库的底层细节的中间件，是客户端与后台的数据库之间进行通信的桥梁。
102.如图6所示的系统中数据存储装置，该数据存储装置可以用于存储数据或查询数据。
103.在如图6所示的系统中，还可以集成有报警装置(规则引擎模块和通知模块)。
104.在如图6所示的系统中，还可以集成有其他关联组件，包括cmdb(配置管理数据库，configuration management database)、权限系统、配置服务、流程引擎等。
105.在如图6所示的系统中，还可以集成有应用服务，例如可以包括数据建模、业务集成、数据开发、辅助决策以及故障恢复等应用服务，以便用户调用上述应用服务以实现对应的功能。
106.综上所述，为了实现对公有云多资源池进行运维监控，可以在云服务器中设置公有云多资源池运维监控系统，且该系统包括数据采集装置、数据处理装置以及数据存储装置；其中数据采集装置包括数据采集工具，该数据采集工具及可以通过pull模式向被监控组件请求数据，也可以接收通过push模式推送的数据，而数据处理装置则可以获取通过prometheus模块接收数据采集装置采集到的数据，并传输至数据存储装置。通过上述方案，prometheus作为中间数据传输组件，同时具备数据推、拉模式，用户(运维人员)可以按需将数据push到数据存储端，极大的减少了服务维护方的开发量，提高了监控数据采集的灵活性。
107.并且上述方案中，设置了成套的中央存储装置，实现了数据存储、压缩、查询等tsdb所需的方方面面，并且逻辑清晰，架构简单，成本低廉。
108.告警配置无需yaml文件存储或下发到prometheus去执行，中央告警装置能简单、高效、高度自定义的实现告警功能。
109.请参阅图7，其是根据本技术一示例性实施例提供的一种计算机设备示意图，所述计算机设备包括存储器和处理器，所述存储器用于存储计算机程序，所述计算机程序被所述处理器执行时，以实现上述实施例中各个装置所涉及的功能。
110.其中，处理器可以为中央处理器(central processing unit，cpu)。处理器还可以为其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等芯片，或者上述各类芯片的组合。
111.存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序、非暂态计算机可执行程序以及模块，如本发明实施方式中的方法对应的程序指令/模块。处理器通过运行存储在存储器中的非暂态软件程序、指令以及模块，从而执行处理器的各种功能
应用以及数据处理，即实现上述方法实施方式中的方法。
112.存储器可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储处理器所创建的数据等。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
113.在一示例性实施例中，还提供了一种计算机可读存储介质，用于存储有至少一条计算机程序，所述至少一条计算机程序由处理器加载并执行以实现上述方法中的全部或部分步骤。例如，该计算机可读存储介质可以是只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、只读光盘(compact disc read-only memory，cd-rom)、磁带、软盘和光数据存储设备等。
114.在一示例性实施例中，还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备实现如图1对应的实施例所示出的公有云多资源池运维监控系统的部分或全部功能。
115.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本技术的其它实施方案。本技术旨在涵盖本技术的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本技术的一般性原理并包括本技术未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本技术的真正范围和精神由下面的权利要求指出。
116.应当理解的是，本技术并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本技术的范围仅由所附的权利要求来限制。