业务监测方法、系统及相关装置与流程

1.本技术属于智能家居/智慧家庭技术领域，具体涉及一种业务监测方法、系统及相关装置。


背景技术：

2.互联网业务的高速发展带来了日益增长的流量压力，业务逻辑也日趋复杂，传统的单机应用已经无法满足需求，越来越多的网站逐渐采用了分布式部署架构。同时，随着spring cloud/dubbo等基础开发框架的不断成熟，越来越多的企业开始对网站架构按照业务模块进行垂直拆分，形成了更适合团队协同开发、快速迭代的分布式的微服务架构。
3.分布式的微服务架构在开发效率上具备先进性，但给业务监测、运维、诊断技术带来了巨大挑战。以业务监测为例，依托于目前的分布式的微服务架构，应用服务(app server)接入数据收集引擎代理(logstash agent)，然后将数据/日志传递给kafka(或者redis)，并将队列中消息或数据间接传递给数据收集引擎(logstash)，由数据收集引擎过滤、分析后将数据传递给分布式搜索和分析引擎(elasticsearch)存储；最后由分析与可视化平台(kibana)将日志和数据呈现给用户。这种业务监测方案至少存在接入成本高，实时性差等问题。


技术实现要素：

4.为了解决上述问题，即为了解决业务监测方案至少存在接入成本高，实时性差等问题，本技术提供了一种业务监测方法、系统及相关装置。
5.第一方面，本技术提供了一种业务监测系统，该业务监测系统包括：客户端软件开发工具组件、输出设备和数据库；其中，客户端软件开发工具组件，用于收集和追踪应用服务的日志数据，对收集的日志数据进行预处理，并将预处理后的数据发送至对应的输出设备；输出设备，用于将预处理后的数据传递给数据库存储，预处理包括数据过滤和/或数据分析；数据库，用于与可视化端进行交互，以提供业务查询服务。
6.一种可能的实施方式中，客户端软件开发工具组件包括：日志链路追踪器和日志链路收集器，其中：日志链路追踪器，用于追踪应用服务的日志链路；日志链路收集器，用于收集日志链路追踪器追踪到的日志链路的日志数据，对收集的日志数据进行预处理，并将预处理后的数据发送至对应的输出设备。
7.一种可能的实施方式中，日志链路收集器，包括收集组件和勘测组件，其中：勘测组件，用于管理收集组件，以及确定待读取的日志文件；收集组件，用于读取待读取的日志文件中的文件内容，对文件内容进行预处理，并将读取到的文件内容发送至对应的输出设备。
8.一种可能的实施方式中，数据库采用starrocks架构。
9.一种可能的实施方式中，该业务监测系统还包括：可视化端，用于与数据库交互，以将通过业务查询服务查询到的数据进行可视化，其中，可视化的数据包括用于反映业务
与服务调用的关联关系的数据。
10.一种可能的实施方式中，可视化端中集成有可视化工具，可视化工具通过可视化界面进行查询到的数据的显示，可视化界面包含第一区域和第二区域，第一区域用于显示查询到的数据，第二区域包含至少一种数据处理方式分别对应的控件，可视化端用于在检测到将查询到的数据拖拽至第二区域的目标控件时，对查询到的数据按照目标控件对应的数据处理方式进行数据处理，数据处理方式包括数据分享和图表制作。
11.第二方面，本技术提供了一种业务监测方法，可以应用于第一方面提供的业务监测系统中的客户端软件开发工具组件，该业务监测方法包括：收集和追踪应用服务的日志数据；对收集的日志数据进行预处理，预处理包括数据过滤和/或数据分析；将预处理后的数据发送至对应的输出设备，输出设备用于将预处理后的数据传递给数据库存储，数据库用于提供业务查询服务。
12.一种可能的实施方式，客户端软件开发工具组件包括日志链路追踪器和日志链路收集器，收集和追踪应用服务的日志数据，包括：通过日志链路追踪器追踪应用服务的日志链路；通过日志链路收集器收集日志链路追踪器追踪到的日志链路的日志数据，对收集的日志数据进行预处理，并将预处理后的数据发送至对应的输出设备。
13.第三方面，本技术提供了一种电子设备，包括：第一方面的业务监测系统中的客户端软件开发工具组件，用于执行第二方面的业务监测方法。
14.第四方面，本技术提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，计算机程序指令被处理器执行时用于实现第二方面的业务监测方法。
15.第五方面，本技术提供了一种计算机程序产品，计算机程序产品包含计算机程序，计算机程序被处理器执行时用于实现第二方面的业务监测方法。
16.本技术提供的业务监测方法、系统及相关装置，业务监测系统的客户端软件开发工具组件，用于收集和追踪应用服务的日志数据，对收集的日志数据进行预处理，并将预处理后的数据发送至对应的输出设备；输出设备，用于将预处理后的数据传递给数据库存储，预处理包括数据过滤和/或数据分析；数据库，用于与可视化端进行交互，以提供业务查询服务。由客户端软件开发工具组件收集和追踪应用服务的日志数据，以及对收集的日志数据进行预处理，并将预处理后的数据发送至对应的输出设备，可以通过减少接入链路，降低接入成本以及资源消耗和数据丢失风险，提升实时性，且更灵活，扩展性增强。
附图说明
17.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。
18.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
19.图1是目前普遍采用的业务监测系统的架构示意图；
20.图2是本技术实施例提供的业务监测系统的整体设计框架示意图；
21.图3是本技术一实施例提供的业务监测系统的架构示意图；
22.图4是本技术实施例提供的业务监测系统中的一http追踪的示例序列示意图；
23.图5是本技术实施例提供的业务监测系统中的日志链路收集器的工作过程示意图；
24.图6是本技术实施例提供的业务监测系统采用的数据库的架构示意图；
25.图7是本技术实施例提供的业务监测系统的可视化界面示意图；
26.图8是本技术一实施例提供的业务监测方法的流程图。
具体实施方式
27.为了使本技术领域的人员更好地理解本技术方案，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分的实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本技术保护的范围。
28.对于分布式的微服务架构给业务监测、运维、诊断技术带来的巨大挑战，以分布式的微服务架构实践的过程为例，遇到的主要挑战有：
29.定位问题难：分布式的微服务架构中的一个网站请求通常要经过多个服务/节点后返回结果，一旦请求出现错误，往往需要在多台机器上反复翻看日志才能初步定位问题，对简单问题的排查也常常涉及多个团队；
30.发现瓶颈难：当用户反馈网站出现卡顿现象，很难快速发现瓶颈在哪里，是用户终端到服务端的网络问题？还是服务端负载过高导致响应变慢？还是数据库压力过大？即使定位到了导致卡顿的环节，也很难快速定位到代码层面出现的问题；
31.架构梳理难：在业务逻辑变得逐渐复杂以后，很难从代码层面去梳理某个应用依赖了哪些下游服务(数据库、http api、缓存)，以及被哪些外部调用所依赖。业务逻辑的梳理、架构的治理和容量的规划也变得更加困难。
32.以业务监测为例，图1为目前普遍采用的业务监测系统的架构示意图。如图1所示，该业务监测系统依托于目前传统的分布式的微服务架构，应用服务(appserver)接入数据收集引擎代理(logstash agent)，然后将数据/日志传递给数据库(kafka或者redis)或数据库集群中的相应日志主题中，并将日志主题队列中的消息或数据间接传递给数据收集引擎(logstash)，由数据收集引擎作为数据库消费组，进行过滤、分析后将数据传递给分布式搜索和分析引擎(elasticsearch)存储；最后由分析与可视化平台(kibana)将日志和数据呈现给用户。但该技术存在接入成本高，链路长，消耗资源多，数据丢失风险较大，灵活性差，扩展性不强等问题。
33.另外，上述技术是通过一定数据抽取、清洗、转换、装载等技术获取数据库的数据，再放入数据仓库(即分布式搜索和分析引擎)里面，接着对数据仓库的数据进行统计处理，达到业务数据监测的效果。这种方式对于时效性不高的场合比较常用，而对于时效性要求较高的场合不可采用。
34.针对上述问题，本技术提出了一种业务监测系统，将收集端logstash替换为客户端软件开发工具组件，由客户端软件开发工具组件收集和追踪应用服务的日志数据，以及对收集的日志数据进行预处理，并将预处理后的数据进行存储，以通过减少接入链路，降低了接入成本以及资源消耗和数据丢失风险，提升实时性，且更灵活，扩展性增强。
35.其中，软件开发工具对应的英文为software development kit，可以简称为sdk，因此，客户端软件开发工具组件还可以称为客户端sdk组件。
36.下面，通过具体实施例对本技术的技术方案进行详细说明。需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。
37.图2为本技术实施例提供的业务监测系统的整体设计框架示意图。如图2所示，该业务监测系统执行数据采集、数据存储、数据处理和数据预测等操作。具体地，所采集的数据包括应用服务的日志数据，其中，应用服务可以包括但不限于应用(app)、h5/小程序、pc、交易系统、订单系统、发票系统和用户系统等；对于数据预测，可以基于数据预测的结果进行多种图标类型的可视化或告警等，图标类型例如包括折线图或柱状图等。
38.在上述业务监测系统中，对执行数据采集得到的数据进行数据存储；然后，对已获取的数据进行数据处理；最后，对经过数据处理后的数据进行数据预测，获得用户需要的数据预测结果，并通过可视化界面进行显示。
39.在上述业务监测系统中，示例地，告警的具体方式可以是通过可视化界面弹出一个用户选择界面框，基于该用户选择界面框，用户可以选择重新读取该应用服务的日志数据并进行监测，或选择放弃监测等。
40.图3为本技术一实施例提供的业务监测系统的架构示意图。如图3所示，该业务监测系统30包括：客户端软件开发工具组件31、输出设备32和数据库33。其中，客户端软件开发工具组件31，用于收集和追踪应用服务的日志数据，对收集的日志数据进行预处理，并将预处理后的数据发送至对应的输出设备32；输出设备32用于将预处理后的数据传递给数据库33存储，预处理包括数据过滤和/或数据分析；数据库33用于与可视化端(未示出)进行交互，以提供业务查询服务。
41.示例地，客户端软件开发工具组件31可标识为log_sdk。该业务监测系统30可通过java-agent等低侵入或零侵入的方式，实时采集日志数据上报。
42.可选地，客户端软件开发工具组件31可安装在各种类型的客户端中，用于对客户端中已安装的应用服务进行日志数据的追踪和收集。例如，参考图3，客户端中安装的应用服务包括app1、app2和app3，在用户允许的情况下，客户端软件开发工具组件31可追踪和收集app1、app2和app3这三个应用服务的日志数据。
43.示例地，数据库可以具体为mpp数据库等关系型数据库，输出设备32可以为消息队列(message queue，简称mq)集群，但本技术实施例不对其进行限制。
44.本技术实施例中，由客户端软件开发工具组件收集和追踪应用服务的日志数据，以及对收集的日志数据进行预处理，并将预处理后的数据发送至对应的输出设备，无需先存入数据库再对数据库中的数据进行数据抽取、清洗、转换、装载等操作后放入数据仓库，从而可以通过减少接入链路，降低了接入成本以及资源消耗和数据丢失风险，提升实时性，且更灵活，扩展性增强。
45.在上述实施例中，客户端软件开发工具组件31可以进一步包括：日志链路追踪器和日志链路收集器。其中，日志链路追踪器，用于追踪应用服务的日志链路；日志链路收集器，用于收集日志链路追踪器追踪到的日志链路的日志数据，对收集的日志数据进行预处理，并将预处理后的数据发送至对应的输出设备。通过java-agent等低侵入或零侵入的方
式，实时采集业务数据上报。
46.其中，应用服务可对应多个微服务，微服务与微服务之间可以通过远程过程调用(remote procedure call，简称rpc)或者超文本传输协议(hyper text transfer protocol，简称http)方式等方式进行相互调用，并且一个请求会涉及多个微服务，而微服务本身可能也会依赖其他微服务，因此，整个请求路径就构成了一个网状的调用链，而在整个调用链中一旦某个节点发生异常，整个调用链的稳定性就会受到影响。因此，需要将系统行为、链路信息收集上报，以便发生故障的时候能够快速定位和解决问题，工作原理如图4所示例。图4所示是一个http追踪的示例序列，其中，用户通过http发起调用请求，用户代码(user code)调用资源/foo，日志链路追踪器接收到调用资源的调用请求(invoke request)后，会生成一个线程号，如x-b3-traceid:aa，x-b3-spanid:6b。调用过程中会记录调用信息如记录标签(record tags)、添加追踪头(add trace headers)、记录时间戳(record timestamp)、记录间隔时长(record duration)等，该记录过程以代码零侵入的方式实现，记录的调用信息会保存在日志链路追踪收集器(trace collector)中。信息调用成功后给用户一个反馈，如200ok。该调用资源过程会产生一个时长跨度，在用户代码接收到http响应后上报。
47.进一步地，日志链路收集器可以包括收集组件和勘测组件，这两个组件可以协同工作将文件变动发送到指定的输出中。具体地：
48.勘测组件用于管理收集组件，以及确定待读取的日志文件。示例地，日志链路收集器可以具体为sg_log_collector，日志链路追踪器可以具体为sg_log_trace，勘测组件具体为prospectors。勘测组件会找到应用服务对应的日志文件，例如找到/apps/logs/*目录下的所有info.log文件，并为每个日志文件启动一个收集组件。勘测组件会检查每个日志文件，确定该日志文件对应的收集组件是否已经启动，或者是否需要启动，又或者日志文件是否可以忽略。若收集组件关闭，勘测组件只有在日志文件大小发生变化的时候才会执行检查。可选地，勘测组件只能检测本地的日志文件。
49.收集组件用于读取待读取的日志文件中的文件内容，对文件内容进行预处理，并将读取到的文件内容发送至对应的输出设备。示例地，收集组件可以为harvesters。
50.如上所述，每个日志文件会对应一个收集组件，每个收集组件会逐行读取其对应的日志文件，对已经读取的日志文件可以发送到处理程序(spooler)，进行日志管理，并进行格式化处理等，然后将文件内容发送到指定输出中，工作过程如图5所示例。
51.另外，收集组件还负责打开和关闭日志文件，这意味着在收集组件运行的时候，文件描述符处于打开状态，如果日志文件在收集中被重命名或者被删除，日志链路收集器会继续读取此日志文件，所以在收集组件关闭之前，磁盘不会被释放。默认情况下，收集组件会保持文件打开的状态，直到满足关闭条件。示例地，如果收集组件开启，日志链路收集器会在指定时长内将不再更新的文件句柄关闭，指定时长从收集组件读取最后一行的时刻开始计时；若文件句柄被关闭后，日志文件发生变化，则会启动一个新的收集组件。
52.可选地，关闭文件句柄的时刻不取决于文件的修改时刻，若与关闭文件句柄的时刻相关的参数配置不当，则可能发生收集日志数据不实时的情况，示例地，默认该参数为10秒。
53.可选地，收集组件使用内部时间戳来记录文件最后被收集的时刻，最后被收集的
时刻例如默认5分钟，则在收集组件读取文件的最后一行之后，开始倒计时5分钟，若5分钟内读取的文件无变化，则关闭文件句柄。
54.在一些实施例中，日志链路收集器将日志文件的文件状态记录在日志文件中。该文件状态可以表征收集组件收集日志文件的偏移量。若连接不上输出设备，日志链路收集器会记录发送前的最后一行，并再在可以连接的时候继续发送。日志链路收集器在运行的时候，勘测组件的状态会被记录在内存中。日志链路收集器在重启时，利用注册(registry)记录的状态来进行重建，用来还原到重启之前的状态。每个勘测组件会为每个找到的日志文件记录一个状态，对于每个日志文件，日志链路收集器存储唯一标识符以检测日志文件是否先前被收集。
55.需要说明的是，日志链路收集器可以保证事件至少被传递到配置的输出一次，没有数据丢失。因为日志链路收集器将每个事件的传递状态保存在日志文件中。在未得到输出方确认时，日志链路收集器会尝试一直发送，直到得到回应。若日志链路收集器在传输过程中被关闭，则不会在关闭之前确认所有事件。在日志链路收集器关闭之前未确认的事件，会在日志链路收集器重启之后重新发送。这可确保至少发送一次，但有可能会重复。此时，可通过设置下电时限(shutdown_timeout)参数来设置关闭之前的等待事件回应的时间(默认禁用)。
56.可选地，数据库可以采用starrocks架构。starrocks架构示意图如图6所示，starrocks架构简洁，包含前端节点(frontend，简称fe)和后端节点(backend，简称be)，不依赖外部组件，方便部署与维护。另外，前端节点和后端节点都可以在线水平扩展，元数据和数据都有副本机制，从而确保整个数据库无单点。
57.前端节点包括目录管理程序(catalog manager)和查询优化程序(query optimizer)，负责管理元数据，管理客户端连接，进行查询规划，查询调度等工作。前端节点根据配置会有两种角色：跟随者(follower)节点和观测者(observer)节点。每个前端节点都会在内存保留一份完整的元数据，这样每个前端节点都能够提供无差别的服务。
58.可选地，跟随者节点会通过类paxos的bdbje协议选主出一个领导者(leader)节点；实现选主需要集群中有半数以上的跟随者节点实例存活；领导者节点用于对元数据进行写操作；非领导者节点会自动的将元数据写入请求路由到领导者节点。每次元数据写入时，必须有多数跟随者节点成功才能确认是写入成功。
59.可选地，观测者节点不参与选主操作，只会异步同步并且回放日志，主要用于扩展集群的查询并发能力。
60.后端节点包括存储引擎(storage engine)和执行引擎(execution engine)，负责数据存储以及结构化查询语言(structured query language，简称sql)执行等工作。
61.在数据存储方面，后端节点是对等的，前端节点按照一定策略将数据分配到对应的后端节点。在数据导入时，数据会直接写入到后端节点，不会通过前端节点中转，后端节点负责将导入数据写成对应的格式以及生成相关索引。
62.可选地，在执行sql计算时，一条sql语句首先会按照具体的语义规划成逻辑执行单元，然后再按照数据的分布情况拆分成具体的物理执行单元，物理执行单元会在数据存储的节点上进行执行，这样可以避免数据的传输与拷贝，从而能够得到极致的查询性能。
63.可选地，数据库采用的starrocks架构整体对外暴露的是一个mysql协议接口，支
持标准sql语法，用户通过已有的mysql客户端能够方便地对采用starrocks架构的数据库中的数据进行查询和分析。
64.考虑到目前技术的业务监测工具大多从基础架构、应用系统和请求等角度去衡量应用健康度，然而这些衡量指标缺乏业务语义，无法直观地体现。基于此，业务监测系统还可以包括：用于与数据库交互的可视化端，以将通过业务查询服务查询到的数据进行可视化。其中，可视化的数据可以包括但不限于用于反映业务与服务调用的关联关系的数据，例如某个业务信息与统一资源定位系统(uniform resource locator，简称url)、rpc接口的映射关系，包括需要匹配的信息和拆分的维度，完成业务与服务调用的关联。本技术实施例通过追踪并收集应用服务中的业务信息，对业务的关键交易进行全链路的监测，实时性高，灵活性强，实时展现业务级的指标，如业务的响应时长、次数和错误率，解决应用程序和业务表现之间无法映射关联的难题，达到可视化友好。
65.可选地，可视化端中集成有可视化工具，该可视化工具通过可视化界面进行查询到的数据的显示。可选地，可视化界面包含第一区域和第二区域，第一区域用于显示查询到的数据，第二区域包含至少一种数据处理方式分别对应的控件，可视化端用于在检测到将查询到的数据拖拽至第二区域的目标控件时，对查询到的数据按照目标控件对应的数据处理方式进行数据处理，数据处理方式包括数据分享和图表制作等。
66.示例地，图7示出一可视化工具的可视化界面。如图7所示，该可视化界面包括仪表板、视图、数据集、数据源以及管理与安全这几个模块。
67.上述可视化界面中的各个模块：
68.仪表板：仪表板可基于apache echarts实现，支持丰富的图表类型、支持拖拉拽方式快速制作仪表板；支持快速安全分享；支持多端查看；支持统一资源定位符(uniform resource locator，简称url)查看。其中，仪表板里可以添加多种图表，每种图表可以有多个，图表类型如柱状图、折线图等。生成的图表可以制作成一个链接，进行快速安全分享，支持他人查看。多端查看，包括pc端、移动端或大屏设备等。
69.视图：支持多图库、支持指标计算与过滤规则、支持多级下钻，可视化匹配具有多种属性与样式。
70.数据集：支持直连模式和本地模式，其中，本地模式可基于apachedoris/starrocks实现，支持多数据集关联、支持数据集字段计算，支持定时同步等。
71.数据源：包括数据仓库/数据湖、分布式关系数据库、数据文件、应用程序接口(application program interface，简称api)数据源等，其中，数据类型包括关系型数据库和非关系型数据库，关系型数据库如亚马逊数据库(amazon redshift)、开源列式数据库(clickhouse)、mysql等，非关系型数据库如nosql等。分布式关系数据库包括联机事务处理(on-line transaction processing，简称oltp)数据库和联机分析处理(on-line analytical processing，简称olap)数据库。数据文件如excel文件。
72.管理与安全：包括单击登录组件、用户与租户组件、角色与权限组件、日志审计组件、嵌入式集成组件、表现层状态转移(representational state transfer，简称rest)接口组件等，是一个页面系统的基本组件。可选地，用户登录系统后，可以根据已有的用户权限查看日志信息。
73.本技术实施例提供的可视化工具至少具有以下优势：
74.1.简单易用：可通过鼠标点击和拖拽数据集，完成相应数据集的分析。其中，可以把数据集拖拽至仪表板，从而生成相应的图表类型。
75.2.安全分享：支持多种数据分享方式，确保数据安全。
76.3.秒级响应：该可视化工具集成apache doris/starrocks，支持超大数据量下秒级查询返回延时。
77.可选地，可视化端具体可以为pc端、移动端或大屏设备等。
78.本技术实施例提供的业务监测系统链路较短，各个节点维护更方便，从而可以缓解问题排查困难的缺陷。
79.在上述业务监测系统的基础上，本技术实施例还提供一种应用于该业务监测系统中的客户端软件开发工具组件的业务监测方法，接下来，对该业务监测方法进行说明。
80.图8为本技术一实施例业务监测方法的流程图。如图8所示，该业务监测方法包括：
81.s801：收集和追踪应用服务的日志数据。
82.s802：对收集的日志数据进行预处理，所述预处理包括数据过滤和/或数据分析。
83.s803：将预处理后的数据发送至对应的输出设备，输出设备用于将预处理后的数据传递给数据库存储，数据库用于提供业务查询服务。
84.可选地，客户端软件开发工具组件包括日志链路追踪器和日志链路收集器。对应地，s801可以进一步包括：通过日志链路追踪器追踪应用服务的日志链路；通过日志链路收集器收集日志链路追踪器追踪到的日志链路的日志数据，对收集的日志数据进行预处理，并将预处理后的数据发送至对应的输出设备。
85.本技术实施例的业务监测方法，其实现原理和技术效果与上述实施例类似，此处不再赘述。
86.本技术实施例还提供一种电子设备，包括：如上所述的业务监测系统中的客户端软件开发工具组件，用于执行如上业务监测方法。
87.本技术实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，当处理器执行计算机执行指令时，实现如上业务监测方法。
88.本技术实施例还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现如上的业务监测方法。
89.该业务监测方法广泛应用于智慧家庭(smart home)、智能家居、智能家用设备生态、智慧住宅(intelligence house)生态等全屋智能数字化控制应用场景。
90.上述网络可以包括但不限于以下至少之一：有线网络，无线网络。
91.上述有线网络可以包括但不限于以下至少之一：广域网，城域网，局域网，等等。
92.上述无线网络可以包括但不限于以下至少之一：无线保真(wirelessfidelity，简称wifi)，蓝牙，等等。客户端(或称为“终端设备”或“用户设备”或“终端”等)可以包括但并不限定于为个人计算机(personal computer，简称pc)、手机、平板电脑、智能空调、智能烟机、智能冰箱、智能烤箱、智能炉灶、智能洗衣机、智能热水器、智能洗涤设备、智能洗碗机、智能投影设备、智能电视、智能晾衣架、智能窗帘、智能影音、智能插座、智能音响、智能音箱、智能新风设备、智能厨卫设备、智能卫浴设备、智能扫地机器人、智能擦窗机器人、智能拖地机器人、智能空气净化设备、智能蒸箱、智能微波炉、智能厨宝、智能净化器、智能饮水机、智能门锁等。
93.上述的计算机可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(static random access memory，简称sram)，电可擦除可编程只读存储器(electric erasable programmable read-only memory，简称eeprom)，可擦除可编程只读存储器(erasable programmable read-only memory，简称eprom)，可编程只读存储器(programmable read-only memory，简称prom)，只读存储器(read only memory，简称rom)，磁存储器，快闪存储器，磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。
94.以上所述仅是本技术的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本技术的保护范围。