一种基于微服务架构的配置处理方法、装置和存储介质与流程

1.本技术涉及计算机技术领域，尤其涉及一种基于微服务架构的配置处理方法、装置和存储介质。


背景技术：

2.随着科技的不断进步，家具智能化已经是一种趋势，它不仅改变了原有的家具家电的使用模式，更给用户带来了便利，随着软件架构的发展逐渐演进成分布式、微服务化，单一系统会拆分成多个微服务，每个微服务都有自己的配置，对应到智能家具设备上，每种智能家具设备都具有多个微服务应用来支持自身的正常运行，但伴随着软件系统的日益复杂化和用户需求的频繁变化，微服务应用的更新也较为频繁。
3.相关技术中的微服务配置更新是通过暂停运行设备中原有的微服务应用，再将最新的配置文件加载至原有的微服务应用上，因此在微服务应用在更新过程中处于停服状态。
4.而在智能家具领域，微服务应用因配置更新而处于停服状态，最终导致设备不能正常使用，无论时间长短都会极大的损伤用户的体验感，因此如何使智能家具设备上的微服务应用在保证设备正常运行的情况下进行配置更新是本领域的技术人员亟需解决的问题。


技术实现要素：

5.本技术实施例提供一种基于微服务架构的配置处理方法、装置和存储介质，能够使智能家具设备上的微服务应用在保证设备正常运行的情况下进行配置文件的更新。
6.第一方面，本技术实施例提供了一种基于微服务架构的配置处理方法，所述方法应用于云服务器，所述云服务器用于管理和下发多个微服务应用的配置文件，所述方法包括：
7.确定第一微服务应用需要进行更新，其中所述第一微服务应用为第一设备配置的至少两个微服务应用中的一个微服务应用，所述多个微服务应用包括所述第一微服务应用和第二微服务应用，所述第一微服务应用和所述第二微服务应用分别配置在所述第一设备和第二设备，所述第一微服务应用和所述第二微服务应用属于同一批次进行更新的微服务应用，在任意一批次进行更新的微服务应用中所述第一设备和所述第二设备均只有一个微服务应用；
8.向所述第一微服务应用发送最新的配置文件。
9.具体地，在互联网微服务场景下，应用服务日益复杂，程序中包含了各种类型的配置信息：中间件配置、框架配置、应用配置、黑白名单、灰度开关等。现有技术中的微服务配置更新是通过暂停运行设备中原有的微服务应用，再将最新的配置文件加载至原有的微服务应用上，加载完成后需要刷新配置，该微服务应用才能够正常使用，尤其是进行大版本的更新时；在智能家具领域，一个设备的正常运行由众多微服务应用提供支持，而众多微服务
应用之间存在中介，所以微服务之间松耦合，在这个基础上假如一个微服务应用进行大版本的更新，在这一个设备中仅有该微服务应用需要进行重启刷新配置，不会影响到设备的正常运行，但假如一个设备中有多个微服务应用进行更新，就可能会出现这些微服务应用同时重启刷新配置的情况，最终导致该设备无法正常运行。在其他领域，设备短时间内无法正常运行，可能不会影响用户的体验感，但在智能家具领域，智能家具设备与用户的生活息息相关，如用户在使用指纹解锁开门时，门打不开，或用户在洗完衣服使用智能晾衣架时，晾衣架无法正常启动或收起，只要发生一次都会严重影响到用户的体验感。
10.在本方案中，通过云服务器对所管理的设备中的多个微服务应用的配置文件实现中心化管理，所述云服务器即一个或多个配置中心，通过所述云服务器管理和下发所述配置文件，无需技术人员手动部署配置文件，且能够实现热更新。
11.进一步的，在本方案中提及了第一微服务应用和第二微服务应用，所述第一微服务应用和所述第二微服务应用分属于不同的智能家具设备，而所述第一微服务应用和所述第二微服务应用属于同一批次需要更新的微服务应用，则代表在微服务应用进行配置更新时，会存在多个设备中的多个微服务应用同时更新的情况，但在任意一批次进行更新的微服务应用中所述第一设备和所述第二设备均只有一个微服务应用进行更新，这也就代表着在同一设备中的微服务应用不会同时出现在同一批次中进行更新，例如所述第一设备中的多个微服务应用需要更新，那只有当所述第一微服务应用的配置文件更新完毕后，所述第一设备的其他需要更新的微服务应用才会进行更新，避免因同一设备的多个微服务应用同时进行更新，导致该设备不能正常运行，以此实现设备在运行的过程中进行微服务应用的配置更新。
12.更进一步的，在微服务应用更新过程中，所述云服务器发送第一微服务应用最新的配置文件，其中所述最新的配置文件中包括配置文件内容和所述配置文件的标识信息，所述标识信息包括命名空间、组、配置文件名称、配置格式、配置文件内容、配置描述以及版本号和md5值。
13.结合第一方面，在一种可选的方案中，所述确定第一微服务应用需要进行更新，包括：
14.接收来自所述第一微服务应用的请求消息，所述请求消息用于请求所述第一微服务应用的最新的配置文件的标识信息；
15.发送所述配置文件的标识信息，所述标识信息包括版本号和md5值，所述版本号和md5值用于确定所述第一微服务应用已备份的配置文件是否包括最新的配置文件；
16.接收来自所述第一微服务应用的配置更新请求。
17.具体的，本方案通过长轮询的方式检查配置文件是否更新，以此可实现热更新，在这个过程中，由于第一设备自身无法得知配置文件是否更新，故需要云服务器接收设备主动发送请求消息，所述请求消息用于请求所述第一微服务应用的最新的配置文件的标识信息，所述云服务器在接收到所述标识信息后，对所述标识信息进行识别，确定所述标识信息的来源，所述来源包括设备类型和微服务类型，但是所述云服务器自身无法获取所述第一设备的配置文件使用状态，所述请求消息中也不包含所述第一设备已使用的配置文件的标识信息，故所述云服务器只需将与所述标识信息的来源一致的最新的配置文件的标识信息发送给所述第一设备即可，该配置文件是在预设时间内新增或变更的配置文件，从而避免
线程堵塞，更何况所述云服务器管理的微服务数量众多，处理的消息更是庞大，将确定的工作交由所述第一设备自身来做，可在一定程度上节约线程，并且可避免出现配置文件误发的情况。
18.所述云服务器发送所述配置文件的标识信息后，在一种可选的实施方式中，在线程充足的情况下，接管发送所述配置文件的标识信息的主线程将所述标识信息对应的版本号最新的配置文件暂时挂起，等待来自所述第一微服务应用的回应，即等待来自所述第一微服务应用的配置更新请求，当接收到来自所述第一设备的响应时，所述主线程可第一时间将配置文件返回至第一设备，降低时间的浪费；在另一种可选的实施方式中，在线程不充足的情况下，接管发送所述配置文件的标识信息的主线程直接将任务结束。
19.当所述第一设备完成识别工作，确定所述云服务器发送的配置文件的标识信息归属于最新的配置文件，则所述第一微服务应用将会发送配置更新请求至所述云服务器，所述云服务器在接收到所述配置更新请求时，即为确定所述第一微服务应用需要更新，则会执行向所述第一微服务应用发送最新的配置文件的步骤。
20.结合第一方面，在一种可选的方案中，所述接收来自所述第一微服务应用的请求消息之后，所述发送所述配置文件的标识信息之前，所述方法包括：
21.与所述第一微服务应用建立通信连接，并在预设时限内将所述请求消息挂起；
22.若所述第一微服务应用的配置文件是有更新，则执行所述发送所述配置文件的标识信息的步骤。
23.具体的，在本方案中，所述云服务器在接收到来自所述第一微服务应用的请求消息后，会将所述请求消息挂起，等待配置更新后再对所述请求消息进行响应。
24.但使用常见的长轮询方式将请求消息挂起，等待新数据更新后再响应的处理方式虽然能减少所述第一微服务应用的请求次数，并带来即时性，但是如果使用同步处理请求的方式，所述请求消息到达所述云服务器后，从主线程池获取一个线程，处理业务，响应请求，然后将线程还回线程池，整个过程都是由同一个主线程在执行，而挂起请求则代表了主线程的阻塞，有多少长轮询请求未响应就代表要阻塞多少个主线程，所以长轮询必须使用异步处理的方式，避免大量请求过来之后，主线程被耗光，新来的请求消息无法处理。
25.故在本方法中，主线程可将请求转交给其他线程去处理，比如开发者自定义一个线程，然后主线程将请求消息转交给自定义线程，主线程回收，在自定义的线程中处理请求，实现线程池的隔离，避免主线程的堵塞，从而避免当请求消息众多时，云服务器无法及时响应的问题。
26.在预设时限内，当所述第一微服务应用对应的配置文件更新时，则对所述请求消息进行响应，即所述云服务器发送所述配置文件的标识信息至所述第一微服务应用。
27.结合第一方面，在一种可选的方案中，所述方法还包括：
28.若所述第一微服务应用的配置文件没有更新，则到达预设时限后所述云服务器与所述第一微服务应用断开通信连接。
29.具体的，在本方案中，所述第一微服务应用的配置文件没有更新，即在预设时间内，所述第一微服务应用的配置文件没有新增或变更，到达预设时限后所述云服务器与所述第一微服务应用断开通信连接，但考虑到网络波动的因素，所述预设时间不会太短，可选的，所述预设时间为30秒，按上述过程设置既减少请求次数，避免线程浪费，又可及时的进
行配置文件的更新。
30.结合第一方面，在一种可选的方案中，所述确定第一微服务需要进行更新，包括：
31.接收来自所述第一微服务应用的订阅请求；
32.确定所述第一微服务应用的配置文件已更新。
33.具体的，本方案中采用消息队列发布配置文件的方式实现热更新，但在相关技术中，在目前微服务架构场景中经常使用的方式是消息总线，所述消息总线应用于微服务架构的系统中，通常会使用轻量级的消息代理来构建一个共用的消息主题，并让系统中所有微服务实例都连接上来，并且该主题中产生的消息会被所有实例监听和消费，所以称它为消息队列。在总线上的各个实例，都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息，但其承载能力和吞吐量不足以承担在智能家具设备的众多微服务应用产生的庞大的消息量，而消息队列中间件的吞吐量峰值非常大，更适合在智能家具领域中使用，故在本方案中采用消息队列发布的方式实现热更新，在使用所述消息队列进行配置文件的更新的过程中，微服务应用需首先订阅与自身对应的配置文件相关的主题，以此实现配置文件更新后即可及时发布，例如当所述第一微服务应用的配置文件更新时，订阅该主题的微服务应用都会收到该配置文件，在这个过程中采用消息队列中间件来实现隔离云服务器和微服务应用。
34.因此所述云服务器应先接收来自微服务应用的订阅请求，配置所述微服务应用订阅与自身配置文件相关的主题，当确定微服务应用的配置文件已更新时，即可将配置文件发送至消息队列中间件，进行消息队列发布，以此解除或弱化云服务器与微服务应用的耦合，并且可达到异步处理、流量削峰的效果。
35.结合第一方面，在一种可选的方案中，所述配置文件的标识信息还包括所述第一微服务应用所在的第一设备的设备标识。
36.具体的，在该方案中，因所述配置文件的标识信息不仅存在所述云服务器，也存在所述第一微服务应用的已备份的配置文件中，在所述第一微服务应用的已备份的配置文件中的标识信息仅用于确定所述已备份的配置文件是否为最新的配置文件，而在所述云服务器处的配置文件的标识信息还存在方便管理配置文件，对配置文件进行分类的作用，故在本方案中所述配置文件的标识信息还包括所述第一微服务应用所在的第一设备的设备标识，所述设备标识用于在所述云服务器关联的设备数量较大时，识别配置文件所属设备时使用，值得一提的是，所述标识信息还包括如命名空间、组和配置文件名称等其他信息。
37.结合第一方面，在一种可选的方案中，所述云服务器用于管理所对接的设备中的所有微服务应用的配置文件，避免敏感信息裸露在源代码中。
38.所述配置文件的数量极为庞大，为了便于管理，所有微服务应用的配置文件均放置于所述云服务器，且所述云服务器也同样承担着发送变更或新增的配置文件的职责。
39.具体的，所有的配置文件均可具备3个属性，即：命名空间、组、配置文件名称，所以在配置管理功能设计中，需进行命名空间管理，在本方案中，所述命名空间具备新增、编辑、删除、详情、列表、统计等多种功能，能够划清职责，避免微服务管理混乱，而在进行配置文件管理时，可执行配置文件变更、新增、编辑、克隆、回滚、示例等多种功能
40.在配置文件变更时，将本次内容进行快照，并生成一个版本号、记录日期、md5值进行存储。在云服务器后台可查看某个配置的配置历史。在新增配置文件时，必须填写命名空
间、组、配置文件名称、配置格式(如text/json/xml/yaml/toml/properties)、配置文件内容以及配置描述，便于对所述配置文件进行分类，并且便于后续管理。
41.在变更或新增微服务应用的配置文件时，可将强相关的微服务应用的配置文件信息进行克隆，然后选择需要克隆到的指定的命名空间、组下面，并进行适应性修改。
42.在进行配置文件的回滚时，将指定的历史版本号的配置文件的内容，作为最新的配置文件，版本号为最新的版本号，但配置文件的内容是与所述指定的历史版本号的配置文件的内容是一致的。
43.第二方面，本技术实施例提供了一种基于微服务架构的配置处理方法，所述方法应用于第一设备，所述云服务器用于管理和下发多个微服务应用的配置文件，所述方法包括：
44.第一设备接收所述云服务器发送的第一微服务应用的配置文件，其中，所述云服务器用于管理多个微服务应用的配置文件，所述多个微服务应用包括第一微服务应用和第二微服务应用，所述第一微服务应用和所述第二微服务应用分别配置在所述第一设备和第二设备；所述第一微服务应用为所述第一设备配置的至少两个微服务应用中的一个微服务应用；
45.所述第一设备根据所述配置文件配置所述第一微服务应用。
46.具体的，所述第一设备接收的所述配置文件包括所述配置文件本身和配置文件的标识信息，所述配置文件的标识信息包括命名空间、组和配置文件名称，所述第一设备根据所述命名空间和组，将所述配置文件放置到特定位置，替换掉原有的配置文件。
47.所述第一设备在本地设有备份库，所述备份库用于存放所述第一设备已有的配置文件，而当所述配置文件到达设备本地后，会即刻进行备份，并存储在所述备份库中，在设备重启的情况下，如刷机、恢复出厂设置，所述第一设备通过运行所述备份库中的配置文件，使设备能够正常运行。
48.结合第二方面，在一种可选的方案中，在所述第一设备接收所述云服务器发送的第一微服务应用的配置文件之前，所述方法还包括：
49.确定所述第一微服务应用存在已备份的配置文件；
50.向所述云服务器发送所述请求消息，所述请求消息用于请求所述第一微服务应用的最新的配置文件的标识信息，所述标识信息包括版本号和md5值；
51.接收所述云服务器发送的所述第一微服务应用的最新的配置文件的标识信息；
52.对比所述云服务器发送的配置文件的标识信息与已备份的配置文件的标识信息，以确定所述第一微服务已备份的配置文件是否为最新的配置文件；
53.若所述第一微服务应用已备份的配置文件不为最新的配置文件，则向所述云服务器发送配置更新请求。
54.具体的，在上述方法中，所述第一微服务应用本地存在以往该应用所有的配置文件的备份，且所述配置文件的备份即已备份的配置文件，所述已备份的配置文件包括配置文件的标识信息，所述标识信息包括版本号和md5值，所述版本号和md5值用于确定所述第一微服务已备份的配置文件是否为最新的配置文件，但想要通过所述版本号和md5值确定所述第一微服务已备份的配置文件是否为最新的配置文件需要向所述云服务器确定，故在确定所述第一微服务应用存在已备份的配置文件后，向所述云服务器发送所述请求消息，
所述请求消息用于请求所述第一微服务应用的最新的配置文件的标识信息，值得说明的是，所述第一设备处设置有至少一个httpclient连接池，虽然所述第一微服务应用，与所述第一设备的其他微服务应用不会在同一批次进行更新，但在所述第一微服务应用处于更新状态时，所述第一设备的其他微服务应用仍有可能进行请求消息或其它消息的发送或接收，故所述httpclient连接池用于所述第一设备中的多个微服务应用向所述云服务器发送请求消息或其他请求，避免因线程堵塞导致所述第一微服务应用的更新状态无法进行的情况发生。
55.所述第一微服务应用接收到所述云服务器发送的标识信息后，将所述云服务器发送的标识信息与已备份的配置文件的标识信息进行比对，比对不一致则说明所述第一微服务应用存在配置文件的更新，在确定所述配置文件需要更新后，所述第一微服务应用向所述云服务器发送配置更新请求。
56.结合第二方面，在一种可选的方案中，在所述第一设备接收所述云服务器发送的第一微服务应用的配置文件之前，所述方法还包括：
57.所述第一设备向所述云服务器发送所述第一微服务应用的配置文件的订阅请求。
58.具体的，该方法采用消息队列中间件实现，在该方法中，所述第一微服务应用向所述云服务器发送所述第一微服务应用的配置文件的订阅请求，请求订阅配置文件相关的主题，而所述云服务器在接收到所述第一微服务应用的订阅请求后，配置所述第一微服务应用订阅与自身对应的配置文件的主题，当所述第一微服务应用的配置文件发生变化时，推送相关配置文件到中间件，再到订阅方，以此解除或弱化云服务器与微服务应用的耦合，并且可达到异步处理、流量削峰的效果。
59.第三方面，本技术实施例提供一种基于微服务架构的配置处理装置，所述装置至少包含第一确定单元和第一发送单元。该配置处理装置用于实现第一方面任一项实施方式所描述方法，其中第一确定单元和第一发送单元的介绍如下：
60.第一确定单元，用于确定第一微服务应用需要进行更新，其中所述第一微服务应用为第一设备配置的至少两个微服务应用中的一个微服务应用，所述多个微服务应用包括所述第一微服务应用和第二微服务应用，所述第一微服务应用和所述第二微服务应用分别配置在所述第一设备和第二设备，所述第一微服务应用和所述第二微服务应用属于同一批次进行更新的微服务应用，在任意一批次进行更新的微服务应用中所述第一设备和所述第二设备均只有一个微服务应用；
61.第一发送单元，用于向第一微服务应用发送所述第一微服务应用最新的配置文件。
62.在互联网微服务场景下，应用服务日益复杂，程序中包含了各种类型的配置信息：中间件配置、框架配置、应用配置、黑白名单、灰度开关等。现有技术中的微服务配置更新是通过暂停运行设备中原有的微服务应用，再将最新的配置文件加载至原有的微服务应用上，加载完成后需要刷新配置，该微服务应用才能够正常使用，尤其是进行大版本的更新；在智能家具领域，一个设备的正常运行由众多微服务应用提供支持，而众多微服务应用之间存在中介，所以微服务之间松耦合；假如一个微服务应用进行大版本的更新，在这一个设备中仅有该微服务应用需要进行重启刷新配置，不会影响到设备的正常运行，但假如一个设备中有多个微服务应用需要更新，就可能会出现这些微服务应用同时重启刷新配置的情
况，最终导致该设备无法正常运行。在其他领域，设备短时间内无法正常运行，可能不会影响用户的体验感，但在智能家具领域，设备与用户的生活息息相关，如用户在使用指纹解锁开门时，门打不开，或用户在洗完衣服使用智能晾衣架时，晾衣架无法正常启动或收起，只要发生一次都会严重影响到用户的体验感。
63.在本方案中，通过云服务器对所管理的设备的所有微服务应用的配置文件进行中心化管理，所述云服务器即一个或多个配置中心，通过所述云服务器管理和下发所述配置文件，无需技术人员手动部署配置文件。
64.进一步的，所述第一微服务应用和所述第二微服务应用分属于不同的智能家具设备，而所述第一微服务应用和所述第二微服务应用属于同一批次需要更新的微服务应用，则代表在微服务应用进行配置更新时，会存在多个设备中的多个微服务应用同时更新的情况，但在任意一批次需要更新的微服务应用中所述第一设备和所述第二设备均只有一个微服务应用，这也就代表着在同一设备中的微服务应用不会同时出现在同一批次中进行更新，例如所述第一设备中的多个微服务应用需要更新，那只有当所述第一微服务应用的配置文件更新完毕后，所述第一设备的其他需要更新的微服务应用才会进行更新，避免因同一设备的多个微服务应用同时进行更新，导致该设备不能正常运行，以此实现设备在运行的过程中进行微服务应用的配置更新。
65.更进一步的，在微服务应用更新过程中，所述云服务器发送第一微服务应用最新的配置文件，其中所述最新的配置文件中包括配置文件内容和所述配置文件的标识信息，所述标识信息包括命名空间、组、配置文件名称、配置格式、配置文件内容、配置描述以及版本号和md5值。
66.结合第三方面，在一种可选的方案中，所述确定第一微服务应用需要进行更新方面，所述第一确定单元具体用于：
67.接收来自所述第一微服务应用的请求消息，所述请求消息用于请求所述第一微服务应用的最新的配置文件的标识信息；
68.与所述第一微服务应用建立通信连接，并在预设时限内将所述请求消息挂起；
69.若所述第一微服务应用的配置文件是有更新，则发送所述配置文件的标识信息，所述标识信息包括版本号和md5值，所述版本号和md5值用于确定所述第一微服务应用已备份的配置文件是否包括最新的配置文件；
70.若所述第一微服务应用的配置文件没有更新，则到达预设时限后所述云服务器与所述第一微服务应用断开通信连接；
71.接收来自所述第一微服务应用的配置更新请求。
72.在该装置中，通过长轮询的方式检查配置文件是否更新，以此可实现热更新，在这个过程中，由于第一设备自身无法得知配置文件是否更新，故需要云服务器接收设备主动发送请求消息，所述请求消息用于请求所述第一微服务应用的最新的配置文件的标识信息，所述云服务器在接收到所述标识信息后，对所述标识信息进行识别，确定所述标识信息的来源，所述来源包括设备类型和微服务类型，但是所述云服务器自身无法获取所述第一设备的配置文件使用状态，所述请求消息中也不包含所述第一设备已使用的配置文件的标识信息，故所述云服务器只需将与所述标识信息的来源一致的最新的配置文件的标识信息发送给所述第一设备即可，该配置文件是在预设时间内新增或变更的配置文件，从而避免
线程堵塞，更何况所述云服务器管理的微服务数量众多，处理的消息更是庞大，将确定的工作交由所述第一设备自身来做，可在一定程度上节约线程，并且可避免出现配置文件误发的情况。
73.所述云服务器发送所述配置文件的标识信息后，在一种可选的实施方式中，在线程充足的情况下，接管发送所述配置文件的标识信息的主线程将所述标识信息对应的版本号最新的配置文件暂时挂起，等待来自所述第一微服务应用的回应，即等待来自所述第一微服务应用的配置更新请求，当接收到来自所述第一设备的响应时，所述主线程可第一时间将配置文件返回至第一设备，降低时间的浪费；在另一种可选的实施方式中，在线程不充足的情况下，接管发送所述配置文件的标识信息的主线程直接将任务结束。
74.当所述第一设备完成识别工作，确定所述云服务器发送的配置文件的标识信息归属于最新的配置文件，则所述第一微服务应用将会发送配置更新请求至所述云服务器，所述云服务器在接收到所述配置更新请求时，即为确定所述第一微服务应用需要更新，则会执行向所述第一微服务应用发送最新的配置文件的步骤。
75.进一步的，若所述第一微服务应用的配置文件没有更新，即在预设时间内，所述第一微服务应用的配置文件没有新增或变更，到达预设时限后所述云服务器与所述第一微服务应用断开通信连接，但考虑到网络波动的因素，所述预设时间不会太短，可选的，所述预设时间为30秒，按上述过程设置既减少请求次数，避免线程浪费，又可及时的进行配置文件的更新。
76.结合第三方面，在一种可选的方案中，所述确定第一微服务应用需要进行更新方面，所述第一确定单元具体用于：
77.接收来自所述第一微服务应用的订阅请求；
78.确定所述第一微服务应用的配置文件已更新。
79.在该装置中，具体采用消息队列发布配置文件的方式实现热更新，但在相关技术中，在目前微服务架构场景中经常使用的方式是消息总线，所述消息总线应用于微服务架构的系统中，通常会使用轻量级的消息代理来构建一个共用的消息主题，并让系统中所有微服务实例都连接上来，并且该主题中产生的消息会被所有实例监听和消费，所以称它为消息队列。在总线上的各个实例，都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息，但其承载能力和吞吐量不足以承担在智能家具设备的众多微服务应用的庞大的消息量，而消息队列中间件的吞吐量峰值非常大，更适合在智能家具领域中使用，故在本方案中采用消息队列发布的方式实现热更新，在使用所述消息队列进行配置文件的更新的过程中，微服务应用需首先订阅与自身对应的配置文件相关的主题，以此实现配置文件更新后即可及时发布，例如当所述第一微服务应用的配置文件更新时，订阅该主题的微服务应用都会收到该配置文件，在这个过程中采用消息队列中间件来实现隔离云服务器和微服务应用。
80.因此所述云服务器应先接收来自微服务应用的订阅请求，配置所述微服务应用订阅与自身配置文件相关的主题，当确定微服务应用的配置文件已更新时，即可将配置文件发送至消息队列中间件，进行消息队列发布，以此解除或弱化云服务器与微服务应用的耦合，并且可达到异步处理、流量削峰的效果。
81.第四方面，本技术实施例提供一种基于微服务架构的配置使用装置，所述装置至
少包含第一接收单元和配置单元。该配置使用装置用于实现第二方面任一项实施方式所描述方法，其中第一接收单元和配置单元的介绍如下：
82.第一接收单元，用于接收所述云服务器发送的第一微服务应用的配置文件，其中，所述云服务器用于管理多个微服务应用的配置文件，所述多个微服务应用包括第一微服务应用和第二微服务应用，所述第一微服务应用和所述第二微服务应用分别配置在所述第一设备和第二设备；所述第一微服务应用为所述第一设备配置的至少两个微服务应用中的一个微服务应用；
83.配置单元，用于在所述第一设备根据所述配置文件配置所述第一微服务应用。
84.在该装置中，所述第一设备接收的所述配置文件包括所述配置文件本身和配置文件的标识信息，所述配置文件的标识信息包括命名空间、组和配置文件名称，所述第一设备根据所述命名空间和组，将所述配置文件放置到特定位置，替换掉原有的配置文件。
85.所述第一设备在本地设有备份库，所述备份库用于存放所述第一设备已有的配置文件，而当所述配置文件到达设备本地后，会即刻进行备份，并存储在所述备份库中，在设备重启的情况下，如刷机、恢复出厂设置，所述第一设备通过运行所述备份库中的配置文件，使设备能够正常运行。
86.结合第四方面，在一种可选的方案中，所述装置还包括：
87.第二确定单元，用于确定所述第一微服务应用存在已备份的配置文件；
88.第二发送单元，用于向所述云服务器发送所述请求消息，所述请求消息用于请求所述第一微服务应用的最新的配置文件的标识信息，所述标识信息包括版本号和md5值；
89.第二接受单元，用于接收所述云服务器发送的所述第一微服务应用的最新的配置文件的标识信息；
90.对比单元，用于对比所述云服务器发送的配置文件的标识信息与已备份的配置文件的标识信息，以确定所述第一微服务已备份的配置文件是否为最新的配置文件；
91.第三发送单元，用于当所述第一微服务应用已备份的配置文件不为最新的配置文件时，向所述云服务器发送配置更新请求。
92.在该装置中，具体的，在上述方法中，所述第一微服务应用本地存在以往该应用所有的配置文件的备份，且所述配置文件的备份即已备份的配置文件，所述已备份的配置文件包括配置文件的标识信息，所述标识信息包括版本号和md5值，所述版本号和md5值用于确定所述第一微服务已备份的配置文件是否为最新的配置文件，但想要通过所述版本号和md5值确定所述第一微服务已备份的配置文件是否为最新的配置文件需要向所述云服务器确定，故在确定所述第一微服务应用存在已备份的配置文件后，向所述云服务器发送所述请求消息，所述请求消息用于请求所述第一微服务应用的最新的配置文件的标识信息，值得说明的是，所述第一设备处设置有至少一个httpclient连接池，虽然所述第一微服务应用，与所述第一设备的其他微服务应用不会在同一批次进行更新，但在所述第一微服务应用处于更新状态时，所述第一设备的其他微服务应用仍有可能进行请求消息或其它消息的发送或接收，故所述httpclient连接池用于所述第一设备中的多个微服务应用向所述云服务器发送请求消息或其他请求，避免因线程堵塞导致所述第一微服务应用的更新状态无法进行的情况发生。
93.所述第一微服务应用接收到所述云服务器发送的标识信息后，将所述云服务器发
送的标识信息与已备份的配置文件的标识信息进行比对，比对不一致则说明所述第一微服务应用存在配置文件的更新，在确定所述配置文件需要更新后，所述第一微服务应用向所述云服务器发送配置更新请求。
94.结合第四方面，在一种可选的方案中，所述装置还包括：
95.第四发送单元，用于向所述云服务器发送所述第一微服务应用的配置文件的订阅请求。
96.在该装置中，所述订阅请求采用消息队列中间件实现，所述第一微服务应用向所述云服务器发送所述第一微服务应用的配置文件的订阅请求，请求订阅配置文件相关的主题，而所述云服务器在接收到所述第一微服务应用的订阅请求后，配置所述第一微服务应用订阅主题，当所述第一微服务应用的配置文件发生变化时，推送相关配置文件到订阅方，即将所述第一微服务应用的配置文件发送到所述第一微服务应用，使所述第一微服务应用及时的进行配置文件的更新，并且以此解除或弱化云服务器与微服务应用的耦合，达到异步处理、流量削峰的效果。
97.第五方面，本技术实施例提供一种云服务器，该云服务器包括处理器、存储器和通信接口；存储器中存储有计算机程序；处理器执行计算机程序时，所述通信接口用于发送和/或接收数据，该云服务器可执行前述第一方面所描述的方法。
98.需要说明的是，上述第五方面所描述的云服务器所包含的处理器，可以是专门用于执行这些方法的处理器(便于区别称为专用处理器)，也可以是通过调用计算机程序来执行这些方法的处理器，例如通用处理器。可选的，至少一个处理器还可以既包括专用处理器也包括通用处理器。
99.可选的，上述计算机程序可以存在存储器中。示例性的，存储器可以为非瞬时性(non-transitory)存储器，例如只读存储器(read only memory，rom)，其可以与处理器集成在同一块器件上，也可以分别设置在不同的器件上，本技术实施例对存储器的类型以及存储器与处理器的设置方式不做限定。
100.在一种可能的实施方式中，上述至少一个存储器位于上述云服务器之外。
101.在又一种可能的实施方式中，上述至少一个存储器位于上述云服务器之内。
102.在又一种可能的实施方式之中，上述至少一个存储器的部分存储器位于上述云服务器之内，另一部分存储器位于上述云服务器之外。
103.本技术中，处理器和存储器还可能集成于一个器件中，即处理器和存储器还可以被集成在一起。
104.第六方面，本技术实施例提供一种第一设备，该第一设备包括处理器、存储器和通信接口；存储器中存储有计算机程序；处理器执行计算机程序时，所述通信接口用于发送和/或接收数据，该第一设备可执行前述第二方面所描述的方法。
105.需要说明的是，上述第六方面所描述的第一设备所包含的处理器，可以是专门用于执行这些方法的处理器(便于区别称为专用处理器)，也可以是通过调用计算机程序来执行这些方法的处理器，例如通用处理器。可选的，至少一个处理器还可以既包括专用处理器也包括通用处理器。
106.可选的，上述计算机程序可以存在存储器中。示例性的，存储器可以为非瞬时性(non-transitory)存储器，例如只读存储器(read only memory，rom)，其可以与处理器集
成在同一块器件上，也可以分别设置在不同的器件上，本技术实施例对存储器的类型以及存储器与处理器的设置方式不做限定。
107.在一种可能的实施方式中，上述至少一个存储器位于上述第一设备之外。
108.在又一种可能的实施方式中，上述至少一个存储器位于上述第一设备之内。
109.在又一种可能的实施方式之中，上述至少一个存储器的部分存储器位于上述第一设备之内，另一部分存储器位于上述第一设备之外。
110.本技术中，处理器和存储器还可能集成于一个器件中，即处理器和存储器还可以被集成在一起。
111.第七方面，本技术实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储计算机程序，当所述指令在至少一个处理器上运行时，实现前述第一方面或者第一方面的任一种可选的方案或前述第二方面或者第二方面的任一种可选的方案所描述的方法中。
112.第八方面，本技术提供了一种计算机程序产品，计算机程序产品包括计算机程序，当所述程序在至少一个处理器上运行时，实现前述第一方面或者第一方面的任一种可选的方案或前述第二方面或者第二方面的任一种可选的方案所描述的方法中。
113.可选的，该计算机程序产品可以为一个软件安装包，在需要使用前述方法的情况下，可以下载该计算机程序产品并在计算设备上执行该计算机程序产品。
114.本技术第五至第八方面所提供的技术方案，其有益效果可以参考第一方面和第二方面的技术方案的有益效果，此处不再赘述。
附图说明
115.下面将对实施例描述中所需要使用的附图作简单的介绍。
116.图1是本技术实施例提供的一种配置处理系统的架构示意图；
117.图2是本技术实施例提供的一种基于微服务架构的配置处理方法的流程示意图；
118.图3是本技术实施例提供的一种确定微服务应用更新的方法的流程示意图；
119.图4是本技术实施例提供的再一种确定微服务应用更新的方法的流程示意图；
120.图5是本技术实施例提供的再一种确定微服务应用更新的方法的流程示意图；
121.图6是本技术实施例提供的一种基于微服务架构的配置处理装置的结构示意图；
122.图7是本技术实施例提供的一种基于微服务架构的配置使用装置的结构示意图；
123.图8是本技术实施例提供的一种基于微服务架构的云服务器的结构示意图；
124.图9是本技术实施例提供的一种基于微服务架构的第一设备的结构示意图。
具体实施方式
125.下面结合附图对本技术实施例进行详细介绍。
126.本技术的说明书和权利要求书及所述附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选的还包括没有列出的步骤或单元，或可选的还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
127.下面对本技术实施例应用的系统架构进行介绍。需要说明的是，本技术描述的系统架构及业务场景是为了更加清楚的说明本技术的技术方案，并不构成对于本技术提供的技术方案的限定，本领域普通技术人员可知，随着系统架构的演变和新业务场景的出现，本技术提供的技术方案对于类似的技术问题，同样适用。
128.请参见图1，图1是本技术实施例提供的一种配置处理系统的架构示意图，该系统包括云服务器101、第一设备102和第二设备103，其中：
129.所述云服务器101，可以为一个服务器或者多个服务器组成的服务器集群，用于所述管理第一设备102和第二设备103的配置文件，该云服务器101能够与多个设备建立通信连接，因此可以接收和发送配置文件相关的信息，可选的，该云服务器101作为配置管理中心，管理员可以在该云服务器101进行配置文件的变更、新增、编辑、克隆、备份、回滚、示例等多种操作，实现配置文件的集中管理；可选的，该云服务器101中设有主线程池和自定义线程池，所述主线程池可将接收的消息转交给所述自定义线程池去处理，避免在有大量请求消息时主线程的堵塞；可选的，以上的数据持久化是在mysql数据库中进行，并采用redis缓存技术，提高配置中心的性能，所述mysql数据库支持多种存储引擎，而且提供了多版本并发控制机制和事务，使得mysql数据库不仅可以满足不同的应用场景，而且数据库的安全性也得到了保障，以及mysql数据库将查询处理及其他系统任务和数据的存储和提取相分离，这种存储引擎架构的设计可以在使用时根据性能、特性，以及其他需求来选择数据存储的方式，故在可选的实施方式中使用mysql存储平台中的结构化数据；进一步的，该云服务器101需要实现缓存服务，因为memcached只支持一种数据结构，而redis支持多种数据结构，可以大大减少工作量，并且redis采用单线程模式处理请求并且将数据存在内存中，而对内存的访问速度又远远的大于对磁盘的访问速度故在一种可能的实现方式中选择redis作为缓存的实现。
130.所述第一设备102，可为智能晾衣杆、智能冰柜、智能指纹防盗门等智能家具，在第一设备102中存在多个微服务应用，所述多个微服务应用支撑该第一设备102实现家具智能化，但在实现家具智能化的过程中，不可避免的第一设备102需要联网，故在智能家具的使用过程中，需通过家中的局域网或4g或5g网络与所述云服务器101建立联系，在第一设备102中的任一微服务应用的配置文件需要更新时，可通过主动或被动的方式获取到对应微服务应用的最新的配置文件；可选的，该第一设备102中可能包括消息中间件，具体地，由于第一设备102内部使用多个微服务来实现不同的业务功能，而业务与业务之间会涉及到消息通知，且由于现在智能家具越来越多，以及智能家具非常重要的一点在于响应用户的速度，故需要使用特定的消息中间件来实现上述过程中巨大的信息吞吐量；可选的，所述第一设备102设有备份库，所述备份库中存储有已备份的配置文件，所述已备份的配置文件为第一设备102中所有微服务应用的历史配置文件。
131.所述第二设备103，可为智能晾衣杆、智能冰柜、智能指纹防盗门等智能家具中除第一设备102之外的其他设备，在第二设备103中存在多个微服务应用，所述多个微服务应用支撑该第二设备103实现家具智能化。但在实现家具智能化的过程中，不可避免的第二设备103需要联网，故在智能家具的使用过程中，需通过家中的局域网或4g或5g网络与所述云服务器101建立联系，但上述过程需要使用特定的消息中间件，通过消息中间件可实现自身与云服务器之间的弱耦合或解耦合；可选的，所述第二设备103设有备份库，所述备份库中
存储有已备份的配置文件，所述已备份的配置文件为第二设备103中所有微服务应用的历史配置文件。
132.请参见图2，图2是本技术实施例提供的一种基于微服务架构的配置处理方法的流程示意图，该配置处理方法可以基于图1所示的系统架构示意图实现，也可以基于其他架构实现，该方法包括但不限于如下步骤：
133.步骤s201：云服务器确定第一微服务应用需要进行更新。
134.具体的，通过云服务器对所管理的设备中的多个微服务应用的配置文件实现中心化管理，所述云服务器可设置多个配置中心，通过所述云服务器管理和下发所述配置文件，无需技术人员手动进行配置文件的下发，所述多个微服务应用包括第一微服务应用和第二微服务应用，所述第一微服务应用和所述第二微服务应用分别配置在所述第一设备和第二设备；所述第一微服务应用为所述第一设备配置的至少两个微服务应用中的一个微服务应用，所述第一微服务应用和所述第二微服务应用属于同一批次进行更新的微服务应用，在任意一批次进行更新的微服务应用中所述第一设备和所述第二设备均只有一个微服务应用；所述第一设备为智能指纹门锁、智能晾衣架、智能窗帘或智能开关等智能家具的一种，而所述第二设备为智能指纹门锁、智能晾衣架、智能窗帘或智能开关等智能家具的另一种，但需说明的是，属于同一批次进行更新的设备可能不止有两个，也可能存在更多设备上的微服务应用在同一批次进行更新的情况。
135.在一种可能的实施方式中，所述云服务器每隔预设时间对所管理的部分微服务应用进行一次更新，其中，该部分微服务应用为同一批次；因需避免同一设备中的微服务应用同时更新，那下一批次的配置更新开始之前，上一批次的微服务应用必须更新结束，故该预设时间可以设置为超过微服务应用单次更新所需的时间。
136.在再一种可能的实施方式中，云服务器可设置下发微服务应用的配置文件的时间，以此避免同一设备中的微服务应用同时更新的情况发生。
137.在又一种可能的实施方式中，每个设备发来的请求更新的任务，会根据设备请求时的时间顺序形成队列，在队列中，排在前n位的微服务应用认为是一个批次，可进行同时更新，但如果一个设备按照时间顺序，有多个任务出现在前n位，则将非首位的任务顺延至第n位之后，将原本排在n位之后的任务顺位前移，以保证前n位中的任务都来自不同的设备，其中，n可以根据实际需要进行设置，比如排在前20位的微服务应用认为是一个批次。
138.进一步的，在本技术实施例中，同一批次进行更新的微服务应用应分属于不同的设备，但同一设备的微服务应用在本技术实施例中不能同时在一个批次进行更新，例如所述第一设备中的第一微服务应用的配置文件进行更新时，所述第一设备的其他微服务应用不会进行更新，避免因同一设备的多个微服务应用同时进行更新，导致该设备不能正常运行的情况。
139.可选的，所述云服务器中设有主线程池，该主线程池中包括多个主线程，当存在多个微服务应用的配置文件需要更新时，就可能存在多个微服务应用同时更新的情况，而一个主线程负责一个微服务应用的配置文件的更新任务，缓解负载压力。
140.步骤s202：云服务器向第一设备发送第一微服务应用的配置文件。
141.具体的，所述云服务器发送第一微服务应用最新的配置文件，其中所述最新的配置文件中包括配置文件内容和所述配置文件的标识信息，所述标识信息包括命名空间、组、
配置文件名称、配置格式、配置文件内容、配置描述、配置文件的版本号、配置文件的md5值。
142.在一种可能的实施方式中，所述云服务器确定同一设备的多个微服务应用存在配置文件的变更或更新，在此种情况中，所述云服务器按照该设备中多个微服务应用之间的依赖关系决定所述微服务应用的更新顺序，即在同一设备中的微服务应用不会同时出现在同一批次中进行更新。
143.在另一种可能的实施方式中，所述第二设备的第二微服务应用也需进行配置文件的更新，那所述云服务器在向第一设备发送所述第一微服务应用的配置文件的同时，也会给所述第二设备发送所述第二微服务的配置文件。
144.步骤s203：第一设备接收来自云服务器的第一微服务应用的配置文件。
145.步骤s204：第一设备根据所述配置文件配置第一微服务应用。
146.第一设备通过所述第一微服务应用的配置文件的标识信息将所述第一微服务应用的配置文件放置于特定的地址，替换掉原有的第一微服务应用的配置文件，并将所述替换后的配置文件编辑为已备份的配置文件放入备份库中，原有的配置文件已备份完成，第一设备的第一微服务应用在接收到最新配置文件后，在一种可能的实施方式中，所述第一微服务应用在运行过程中刷新配置，实现热更新；在另一种可能的实施方式中，所述第一微服务应用重启刷新配置，但不影响设备的正常运行。
147.在又一种可能的实施方式中，在所述第一设备重启的情况下，如刷机、恢复出厂设置，所述第一设备通过运行所述备份库中的配置文件，使设备能够正常运行。
148.在本技术实施例中，同一批次进行更新的微服务应用应分属于不同设备，所述不同设备包括第一设备和第二设备，同一设备的微服务应用在本技术实施例中不能在同一批次进行更新，例如所述第一设备中的第一微服务应用的配置文件进行更新时，所述第一设备的其他微服务应用不会进行更新，避免因同一设备的多个微服务应用同时进行更新，导致该设备不能正常运行的情况；以及所述云服务器中设置有主线程池，所述主线程池用于处理当来自所述不同设备的所述请求消息和其他消息，缓解负载压力。
149.本技术实施例中，云服务器确定第一微服务应用需要进行更新的方式有多种，下面进行举例说明：
150.方式一，图3和图4示意了确定微服务应用更新的方法中的两种情况，图3主要讲述的是第一微服务应用的配置文件在预设时限内存在更新的情况，具体如下：
151.步骤301：第一设备确定第一微服务应用存在已备份的配置文件。
152.具体地，第一设备内设有备份库，所述备份库内存储有所述第一微服务应用对应的已备份的配置文件，所述已备份的配置文件包括已备份的配置文件的文件内容和标识信息；所述标识信息包括版本号和md5值，因所述第一设备自身无法确定配置文件是否为最新的，故所述第一设备需要通过所述版本号和md5值确定所述第一微服务已备份的配置文件是否为最新的配置文件，需要向所述云服务器确定。
153.步骤302：第一设备向云服务器发送请求消息。
154.具体的，所述请求消息用于请求所述第一微服务应用的最新的配置文件的标识信息，值得说明的是，考虑到第一设备中的微服务应用可能同时发送请求消息，避免线程拥堵，故在所述第一设备处设置有至少一个httpclient连接池，所述httpclient连接池用于所述第一设备中的微服务应用向所述云服务器发送请求消息或其他请求，本实施例中，可
选的，所述云服务器与第一设备中的微服务之间的数据交换是在一个封闭的内部环境中进行，如集群内网，并且在所述第一设备处设置sdk(软件开发工具包)，sdk中设有线程池，定时向所述云服务器发送有关所述第一设备中的所述第一微服务应用的配置文件的相关信息(比如所述第一设备向云服务器发送请求消息，请求微服务应用的最新的配置文件的标识信息)，在一种可能的实施方式中，在线程池的基础上建立熔断机制，当第一设备出现延迟或故障时，所述第一设备可主动启动熔断措施，维护设备的正常运行。通过多次发送请求消息，在有配置文件的更新时，所述云服务器可及时的对所述第一微服务应用的请求作出响应。
155.步骤s303：云服务器接收来自第一设备的请求消息。
156.步骤s304：云服务器在预设时限内将请求消息挂起。
157.具体的，所述云服务器在接收到来自所述第一微服务应用的请求消息后，会将所述请求消息挂起，因所述云服务器可随时对所述请求消息进行响应，故将所述请求消息挂起即为建立通信连接，可选的，在预设时限内，云服务器上该第一微服务应用对应的配置更新后，该云服务器再对所述请求消息进行响应；可选的，云服务器上该第一微服务应用对应的配置在预设时限内未进行更新，该云服务器在超出预设时限后，对所述请求消息进行响应，并发送当前版本号最新的该第一微服务应用对应的配置文件；可选的，在预设时限内，所述第一微服务应用对应的配置文件一直未更新时，则对所述请求消息不响应，等待所述第一微服务应用下一次的请求消息。
158.在本实施例中，所述云服务器设有自定义线程池，主线程在接收到所述请求消息后，可将请求消息转交给自定义线程去处理，主线程回收，自定义线程将所述请求消息挂起，在一种可能的实施方式中，在使用自定义线程的基础上，使用单独的守护线程或者监听器监听响应事件队列，例如：将配置文件更新包装为响应事件放入响应事件队列中，使用一个守护线程监听该队列，以阻塞的方式获取队列中的响应事件对象，并调用自定义线程池进行处理，相比普通定时轮询，由于采用响应式设计，可以大幅降低前端请求频率和服务器负载，并在事件发生后第一时间通知前端，没有轮询周期空档导致的延迟。
159.进一步的，在预设时限内，当所述第一微服务应用对应的配置文件更新时，则对所述请求消息进行响应，即发送所述第一微服务应用对应的配置文件的标识信息至所述第一微服务应用，在所述第一微服务应用确定配置文件需要更新后，所述第一微服务应用向所述云服务器发送配置更新请求，当所述云服务器接收到所述配置更新请求时即为确定所述第一微服务应用需要更新。
160.步骤s305：云服务器确定第一微服务应用的配置文件有更新。
161.具体的，在预设时限内，所述云服务器确定技术人员对所述第一微服务应用的配置文件在云服务器上进行了修改或更新，但所述云服务器在当前环节中无法主动将所述配置文件直接发送至所述第一微服务应用，若需将配置文件发送至所述第一微服务应用，还需所述第一设备中的第一微服务应用主动请求相应的配置文件，以及所述第一微服务应用自身做验证，达到双重保险的效果，因此需要在所述第一微服务应用本地对配置文件的更新进行验证。
162.步骤s306：云服务器向第一设备发送配置文件的标识信息。
163.具体的，所述云服务器向第一设备发送所述第一微服务应用的最新的配置文件的
标识信息，所述标识信息包括版本号和md5值。
164.步骤s307：第一设备接收来自云服务器的配置文件的标识信息。
165.步骤s308：第一设备对比云服务器发送的配置文件的标识信息与已备份的配置文件的标识信息。
166.所述第一微服务应用接收到所述云服务器发送的标识信息后，将所述云服务器发送的标识信息与已备份的配置文件的标识信息进行比对，即将所述云服务器发送的版本号与已备份的配置文件的版本号进行比对，将所述云服务器发送的md5值与已备份的配置文件的版md5值进行比对，当两者均不一致时，则代表所述第一微服务应用的已备份的配置文件没有所述云服务器发送的配置文件的备份，说明所述第一微服务应用需要进行配置文件的更新；当两者一致时，则代表所述第一微服务应用的已备份的配置文件存在所述云服务器发送的配置文件的备份，说明所述第一微服务应用无需进行配置文件的更新。
167.步骤s309：第一设备确定已备份的配置文件不为最新的配置文件。
168.在本实施例中，经过比对，确定所述第一微服务应用的已备份的配置文件没有所述云服务器发送的配置文件的备份，代表所述第一微服务应用需要进行配置文件的更新。
169.步骤s310：第一设备向云服务器发送配置更新请求。
170.所述第一设备主动向所述云服务器发送配置更新请求，所述配置更新请求用于向所述云服务器请求所述第一微服务应用的最新的配置文件。
171.步骤s311：云服务器接收来自第一设备的配置更新请求。
172.图4主要讲述的是第一微服务应用的配置文件在预设时限内不存在更新的情况，具体如下：
173.步骤s41：第一设备确定第一微服务应用存在已备份的配置文件。
174.步骤s42：第一设备向云服务器发送请求消息。
175.步骤s43：云服务器接收来自第一设备的请求消息。
176.步骤s44：云服务器在预设时限内将请求消息挂起。
177.步骤s45：超出预设时限，通信连接断开。
178.具体的，所述云服务器在预设时限内未检测到所述第一微服务应用的配置文件有更新，断开与所述第一设备的通信连接，以及在一种可能的实施方式中，所述云服务器不响应所述请求消息，在达到预设时限后，连接自动断开；在另一种可能的实施方式中，所述云服务器将表示无更新的状态码反馈给所述第一设备。
179.在一种可能的实现方式中，还可以存在判断第一微服务应用的配置文件在预设时限内是否存在更新过程，所述云服务器将请求消息挂起后会进行自检，检测所述第一微服务应用的配置文件在挂起期间，即在预设时限内，是否存在配置文件或版本号的编辑或更改，若在预设时限内，所述第一微服务应用的配置文件或版本号存在编辑或更改的情况，则将所述配置文件的标识信息返回给第一设备，若在预设时限内，所述第一微服务应用的配置文件或版本号不存在编辑或更改的情况，则不返回标识信息，直接将挂起请求消息的任务暂停。可选的，云服务器上该第一微服务应用对应的配置在预设时限内未进行更新，该云服务器在超出预设时限后，对所述请求消息进行响应，并发送当前版本号最新的该第一微服务应用对应的配置文件。
180.在本技术实施例中，云服务器通过被动的方式发送配置文件，即在接收到配置更
新请求后才会进行配置文件的发送，更适合集群内网的架构或网络不佳的场景，并且第一设备通过长轮询的方式检测配置是否更新，达到及时更新的效果，而云服务器通过设置自定义线程池处理来自设备的请求消息，避免负载压力过大，以及通过挂起请求，等待配置文件更新后再响应的处理方式能减少来自设备的请求次数，并带来即时性。
181.上述过程是云服务器与第一设备保持即时通信的较简单的方式，它不使用任何特定的协议，所以也不依赖于浏览器版本或队列消息中间件等外部条件的兼容性，无需引入其他依赖，实现难度较低。
182.方式二，图5是本技术实施例提供的再一种确定微服务应用更新的方法的流程示意图，具体如下：
183.步骤s51：第一设备向云服务器发送订阅请求。
184.具体的，所述第一微服务应用向所述云服务器发送所述第一微服务应用的配置文件的订阅请求，请求订阅配置文件相关的主题，当已订阅的微服务应用的配置文件更新时，云服务器可通过订阅名单找到发布的对象。
185.步骤s52：云服务器接收来自第一设备的订阅请求。
186.步骤s53：云服务器配置第一微服务应用订阅主题。
187.具体的，云服务器配置第一微服务应用订阅配置文件相关主题后，当配置文件更新时，所述云服务器主动将所述第一微服务应用订阅的配置文件发送消息队列中间件，再由消息队列中间件转发至所述第一设备。
188.步骤s54：云服务器确定第一微服务应用的配置文件有更新。
189.在本技术实施例中，配置云服务器所管理的微服务应用订阅与自身对应的配置文件主题，在一种可能的实施方式中，当第一设备中的多个微服务应用的配置文件发生变更时，所述云服务器根据所述第一设备中的多个微服务应用的依赖关系，对该多个微服务应用进行更新排序，避免所述多个微服务应用出现同时更新的情况，比如所述第一微服务应用在配置文件配置完毕后，会给所述云服务器返回一个已更新码，当所述云服务器接收到所述已更新码后，再按照顺序依次对第一设备中其他需要更新的微服务应用发送配置文件；可选的，因消息队列中间件会对所要转发的消息进行排序，所述云服务器通过所述消息队列中间件将配置文件发送给所述第一微服务应用，不可避免会存在一定的延迟，故所述云服务器可预估所述第一微服务应用配置相应配置文件的时间，提前发送所述第一设备的另一微服务应用的配置文件进入消息队列中间件，使所述另一微服务应用的配置文件在所述第一微服务应用配置相应的配置文件完毕后，正好到达所述第一设备；可选的，所述云服务器可通过消息队列中间件实现热更新，即微服务应用在运行过程中进行更新，但此种方式仅适合配置文件在进行小版本更新或简单迭代的情况的进行。
190.在一种可能的实施方式中，第二设备中的第二微服务应用进行配置文件更新的处理与上述第一设备中的第一微服务应用进行的配置文件更新的处理类似。
191.在本技术实施例中，所述云服务器应先接收来自微服务应用的订阅请求，配置所述微服务应用订阅与自身配置文件相关的主题，当确定微服务应用的配置文件已更新时，即可将配置文件发送至消息队列中间件，进行消息队列发布，以此解除或弱化云服务器与微服务应用的耦合，并且可达到异步处理、流量削峰的效果，上述过程更适合在公网环境下进行。
192.在一种可能的实施方式中，图3、图4中所提供的方法可与图5中所提供的方法进行结合，可达到两种方式互相兜底、自由切换的效果，例如在所述第一设备中设置执行上述两种方法的功能模块，根据网络场景，如集群内网或公网，或客户需求对上述功能模块进行选择。
193.上述详细阐述了本技术实施例的方法，下面提供了本技术实施例的装置。
194.请参见图6，图6是本技术实施例提供的一种配置处理装置60的结构示意图，该装置60可以为前面提及的云服务器或者云服务器中的器件，该装置60可以包括第一确定单元601、第一发送单元602，其中，各个单元的详细描述如下。
195.第一确定单元601，用于确定第一微服务应用需要进行更新，其中所述第一微服务应用为第一设备配置的至少两个微服务应用中的一个微服务应用，所述多个微服务应用包括所述第一微服务应用和第二微服务应用，所述第一微服务应用和所述第二微服务应用分别配置在所述第一设备和第二设备，所述第一微服务应用和所述第二微服务应用属于同一批次进行更新的微服务应用，在任意一批次进行更新的微服务应用中所述第一设备和所述第二设备均只有一个微服务应用；
196.第一发送单元602，用于向第一微服务应用发送所述第一微服务应用最新的配置文件。
197.在互联网微服务场景下，应用服务日益复杂，程序中包含了各种类型的配置信息：中间件配置、框架配置、应用配置、黑白名单、灰度开关等。现有技术中的微服务配置更新是通过暂停运行设备中原有的微服务应用，再将最新的配置文件加载至原有的微服务应用上，加载完成后需要刷新配置，该微服务应用才能够正常使用，尤其是进行大版本的更新；在智能家具领域，一个设备的正常运行由众多微服务应用提供支持，而众多微服务应用之间存在中介，所以微服务之间松耦合；假如一个微服务应用进行大版本的更新，在这一个设备中仅有该微服务应用需要进行重启刷新配置，不会影响到设备的正常运行，但假如一个设备中有多个微服务应用需要更新，就可能会出现这些微服务应用同时重启刷新配置的情况，最终导致该设备无法正常运行。在其他领域，设备短时间内无法正常运行，可能不会影响用户的体验感，但在智能家具领域，设备与用户的生活息息相关，如用户在使用指纹解锁开门时，门打不开，或用户在洗完衣服使用智能晾衣架时，晾衣架无法正常启动或收起，只要发生一次都会严重影响到用户的体验感。
198.在本方案中，通过云服务器对所管理的设备的所有微服务应用的配置文件进行中心化管理，所述云服务器即一个或多个配置中心，通过所述云服务器管理和下发所述配置文件，无需技术人员手动部署配置文件。
199.进一步的，所述第一微服务应用和所述第二微服务应用分属于不同的智能家具设备，而所述第一微服务应用和所述第二微服务应用属于同一批次需要更新的微服务应用，则代表在微服务应用进行配置更新时，会存在多个设备中的多个微服务应用同时更新的情况，但在任意一批次需要更新的微服务应用中所述第一设备和所述第二设备均只有一个微服务应用，这也就代表着在同一设备中的微服务应用不会同时出现在同一批次中进行更新，例如所述第一设备中的多个微服务应用需要更新，那只有当所述第一微服务应用的配置文件更新完毕后，所述第一设备的其他需要更新的微服务应用才会进行更新，避免因同一设备的多个微服务应用同时进行更新，导致该设备不能正常运行，以此实现设备在运行
的过程中进行微服务应用的配置更新。
200.更进一步的，在微服务应用更新过程中，所述云服务器发送第一微服务应用最新的配置文件，其中所述最新的配置文件中包括配置文件内容和所述配置文件的标识信息，所述标识信息包括命名空间、组、配置文件名称、配置格式、配置文件内容、配置描述以及版本号和md5值。
201.在一种可选的方案中，所述确定第一微服务应用需要进行更新方面，所述第一确定单元601具体用于：
202.接收来自所述第一微服务应用的请求消息，所述请求消息用于请求所述第一微服务应用的最新的配置文件的标识信息；
203.与所述第一微服务应用建立通信连接，并在预设时限内将所述请求消息挂起；
204.若所述第一微服务应用的配置文件是有更新，则发送所述配置文件的标识信息，所述标识信息包括版本号和md5值，所述版本号和md5值用于确定所述第一微服务应用已备份的配置文件是否包括最新的配置文件；
205.若所述第一微服务应用的配置文件没有更新，则到达预设时限后所述云服务器与所述第一微服务应用断开通信连接；
206.接收来自所述第一微服务应用的配置更新请求。
207.在该装置中，通过长轮询的方式检查配置文件是否更新，以此可实现热更新，在这个过程中，由于第一设备自身无法得知配置文件是否更新，故需要云服务器接收设备主动发送请求消息，所述请求消息用于请求所述第一微服务应用的最新的配置文件的标识信息，所述云服务器在接收到所述标识信息后，对所述标识信息进行识别，确定所述标识信息的来源，所述来源包括设备类型和微服务类型，但是所述云服务器自身无法获取所述第一设备的配置文件使用状态，所述请求消息中也不包含所述第一设备已使用的配置文件的标识信息，故所述云服务器只需将与所述标识信息的来源一致的最新的配置文件的标识信息发送给所述第一设备即可，该配置文件是在预设时间内新增或变更的配置文件，从而避免线程堵塞，更何况所述云服务器管理的微服务数量众多，处理的消息更是庞大，将确定的工作交由所述第一设备自身来做，可在一定程度上节约线程，并且可避免出现配置文件误发的情况。
208.所述云服务器发送所述配置文件的标识信息后，在一种可选的实施方式中，在线程充足的情况下，接管发送所述配置文件的标识信息的主线程将所述标识信息对应的版本号最新的配置文件暂时挂起，等待来自所述第一微服务应用的回应，即等待来自所述第一微服务应用的配置更新请求，当接收到来自所述第一设备的响应时，所述主线程可第一时间将配置文件返回至第一设备，降低时间的浪费；在另一种可选的实施方式中，在线程不充足的情况下，接管发送所述配置文件的标识信息的主线程直接将任务结束。
209.当所述第一设备完成识别工作，确定所述云服务器发送的配置文件的标识信息归属于最新的配置文件，则所述第一微服务应用将会发送配置更新请求至所述云服务器，所述云服务器在接收到所述配置更新请求时，即为确定所述第一微服务应用需要更新，则会执行向所述第一微服务应用发送最新的配置文件的步骤。
210.进一步的，若所述第一微服务应用的配置文件没有更新，即在预设时间内，所述第一微服务应用的配置文件没有新增或变更，到达预设时限后所述云服务器与所述第一微服
务应用断开通信连接，但考虑到网络波动的因素，所述预设时间不会太短，可选的，所述预设时间为30秒，按上述过程设置既减少请求次数，避免线程浪费，又可及时的进行配置文件的更新。
211.在一种可选的方案中，所述确定第一微服务应用需要进行更新方面，所述第一确定单元601具体用于：
212.接收来自所述第一微服务应用的订阅请求；
213.确定所述第一微服务应用的配置文件已更新。
214.在该装置中，具体采用消息队列发布配置文件的方式实现热更新，但在相关技术中，在目前微服务架构场景中经常使用的方式是消息总线，所述消息总线应用于微服务架构的系统中，通常会使用轻量级的消息代理来构建一个共用的消息主题，并让系统中所有微服务实例都连接上来，并且该主题中产生的消息会被所有实例监听和消费，所以称它为消息队列。在总线上的各个实例，都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息，但其承载能力和吞吐量不足以承担在智能家具设备的众多微服务应用的庞大的消息量，而消息队列中间件的吞吐量峰值非常大，更适合在智能家具领域中使用，故在本方案中采用消息队列发布的方式实现热更新，在使用所述消息队列进行配置文件的更新的过程中，微服务应用需首先订阅与自身对应的配置文件相关的主题，以此实现配置文件更新后即可及时发布，例如当所述第一微服务应用的配置文件更新时，订阅该主题的微服务应用都会收到该配置文件，在这个过程中采用消息队列中间件来实现隔离云服务器和微服务应用。
215.因此所述云服务器应先接收来自微服务应用的订阅请求，配置所述微服务应用订阅与自身配置文件相关的主题，当确定微服务应用的配置文件已更新时，即可将配置文件发送至消息队列中间件，进行消息队列发布，以此解除或弱化云服务器与微服务应用的耦合，并且可达到异步处理、流量削峰的效果。
216.图6所示的装置的具体实现原理可以参照图2、图3、图4、图5所示的方法实施例的相应描述。
217.请参见图7，图7是本技术实施例提供的一种基于微服务架构的配置使用装置70的结构示意图，该装置70可以为前面提及的第一设备或者第一设备中的器件，该装置70可以包括第一接收单元701、配置单元702，其中，各个单元的详细描述如下。
218.第一接收单元701，用于接收所述云服务器发送的第一微服务应用的配置文件，其中，所述云服务器用于管理多个微服务应用的配置文件，所述多个微服务应用包括第一微服务应用和第二微服务应用，所述第一微服务应用和所述第二微服务应用分别配置在所述第一设备和第二设备；所述第一微服务应用为所述第一设备配置的至少两个微服务应用中的一个微服务应用；
219.配置单元702，用于在所述第一设备根据所述配置文件配置所述第一微服务应用。
220.在该装置中，所述第一设备接收的所述配置文件包括所述配置文件本身和配置文件的标识信息，所述配置文件的标识信息包括命名空间、组和配置文件名称，所述第一设备根据所述命名空间和组，将所述配置文件放置到特定位置，替换掉原有的配置文件。
221.所述第一设备在本地设有备份库，所述备份库用于存放所述第一设备已有的配置文件，而当所述配置文件到达设备本地后，会即刻进行备份，并存储在所述备份库中，在设
备重启的情况下，如刷机、恢复出厂设置，所述第一设备通过运行所述备份库中的配置文件，使设备能够正常运行。
222.在一种可选的方案中，所述装置还包括：
223.第二确定单元，用于确定所述第一微服务应用存在已备份的配置文件；
224.第二发送单元，用于向所述云服务器发送所述请求消息，所述请求消息用于请求所述第一微服务应用的最新的配置文件的标识信息，所述标识信息包括版本号和md5值；
225.第二接受单元，用于接收所述云服务器发送的所述第一微服务应用的最新的配置文件的标识信息；
226.对比单元，用于对比所述云服务器发送的配置文件的标识信息与已备份的配置文件的标识信息，以确定所述第一微服务已备份的配置文件是否为最新的配置文件；
227.第三发送单元，用于当所述第一微服务应用已备份的配置文件不为最新的配置文件时，向所述云服务器发送配置更新请求。
228.在该装置中，具体的，在上述方法中，所述第一微服务应用本地存在以往该应用所有的配置文件的备份，且所述配置文件的备份即已备份的配置文件，所述已备份的配置文件包括配置文件的标识信息，所述标识信息包括版本号和md5值，所述版本号和md5值用于确定所述第一微服务已备份的配置文件是否为最新的配置文件，但想要通过所述版本号和md5值确定所述第一微服务已备份的配置文件是否为最新的配置文件需要向所述云服务器确定，故在确定所述第一微服务应用存在已备份的配置文件后，向所述云服务器发送所述请求消息，所述请求消息用于请求所述第一微服务应用的最新的配置文件的标识信息，值得说明的是，所述第一设备处设置有至少一个httpclient连接池，虽然所述第一微服务应用，与所述第一设备的其他微服务应用不会在同一批次进行更新，但在所述第一微服务应用处于更新状态时，所述第一设备的其他微服务应用仍有可能进行请求消息或其它消息的发送或接收，故所述httpclient连接池用于所述第一设备中的多个微服务应用向所述云服务器发送请求消息或其他请求，避免因线程堵塞导致所述第一微服务应用的更新状态无法进行的情况发生。
229.所述第一微服务应用接收到所述云服务器发送的标识信息后，将所述云服务器发送的标识信息与已备份的配置文件的标识信息进行比对，比对不一致则说明所述第一微服务应用存在配置文件的更新，在确定所述配置文件需要更新后，所述第一微服务应用向所述云服务器发送配置更新请求。
230.在一种可选的方案中，所述装置还包括：
231.第四发送单元，用于向所述云服务器发送所述第一微服务应用的配置文件的订阅请求。
232.在该装置中，所述订阅请求采用消息队列中间件实现，所述第一微服务应用向所述云服务器发送所述第一微服务应用的配置文件的订阅请求，请求订阅配置文件相关的主题，而所述云服务器在接收到所述第一微服务应用的订阅请求后，配置所述第一微服务应用订阅主题，当所述第一微服务应用的配置文件发生变化时，推送相关配置文件到订阅方，即将所述第一微服务应用的配置文件发送到所述第一微服务应用，使所述第一微服务应用及时的进行配置文件的更新，并且以此解除或弱化云服务器与微服务应用的耦合，达到异步处理、流量削峰的效果。
233.图7所示的装置的具体实现原理可以参照图2、图3、图4、图5所示的方法实施例的相应描述。
234.请参见图8，图8是本技术实施例提供的一种基于微服务架构的云服务器80，所述云服务器80包括：处理器801、通信接口802及存储器803。其中，处理器801、通信接口802及存储器803可通过总线或其他方式连接，本技术实施例以通过总线连接为例。
235.其中，处理器801是云服务器80的计算核心以及控制核心，其可以解析云服务器80内的各类指令以及云服务器80的各类数据，例如：该处理器801可为中央处理器(central processing unit，cpu)，可以在云服务器80内部结构之间传输各类交互数据，等等。通信接口802可选的可以包括标准的有线接口、无线接口(如wi-fi、移动通信接口等)，受处理器801的控制可以用于收发数据；通信接口802还可以用于所述云服务器80内部信令或者指令的传输以及交互。存储器803(memory)是所述云服务器80中的记忆设备，用于存放程序和数据。可以理解的是，此处的存储器803既可以包括所述云服务器80的内置存储器，当然也可以包括所述云服务器80所支持的扩展存储器。存储器803提供存储空间，该存储空间存储了所述云服务器80的操作系统，该存储空间还存储了处理器执行相应操作所需的程序代码或指令，可选的，该存储空间还可以存储该处理器执行该相应操作后产生的相关数据。
236.在本技术实施例中，处理器801运行存储器803中的可执行程序代码，用于执行如下操作：
237.确定第一微服务应用需要进行更新，其中所述第一微服务应用为第一设备配置的至少两个微服务应用中的一个微服务应用，所述多个微服务应用包括所述第一微服务应用和第二微服务应用，所述第一微服务应用和所述第二微服务应用分别配置在所述第一设备和第二设备；
238.通过所述通信接口802向第一微服务应用发送最新的配置文件。
239.在一种可选方案中，在确定第一微服务应用需要进行更新的过程中，所述处理器801还用于：
240.通过所述通信接口802接收来自所述第一微服务应用的请求消息，所述请求消息用于请求所述第一微服务应用的最新的配置文件的标识信息；
241.与所述第一微服务应用建立通信连接，并在预设时限内将所述请求消息挂起；
242.若所述第一微服务应用的配置文件是有更新，则执行所述发送所述配置文件的标识信息的步骤，如所述第一微服务应用的配置文件没有更新，则到达预设时限后所述云服务器与所述第一微服务应用断开通信连接；
243.通过所述通信接口802发送存储在存储器803中所述配置文件的标识信息，所述标识信息包括版本号和md5值，所述版本号和md5值用于确定所述第一微服务应用已备份的配置文件是否包括最新的配置文件；
244.通过所述通信接口802接收来自所述第一微服务应用的配置更新请求。
245.在又一种可选方案中，在确定第一微服务应用需要进行更新的过程中，所述处理器801还用于：
246.通过所述通信接口802接收来自所述第一微服务应用的订阅请求；
247.确定所述第一微服务应用的配置文件已更新。
248.需要说明的是，各个操作的实现还可以对应参照图2、图3、图4和图5所示的方法实
施例中云服务器一侧的相应描述。
249.请参见图9，图9是本技术实施例提供的一种基于微服务架构的第一设备90，本技术实施例中所描述的所述第一设备90可以是在前文中描述的第一设备，所述第一设备90包括：处理器901、通信接口902及存储器903。其中，处理器901、通信接口902及存储器903可通过总线或其他方式连接，本技术实施例以通过总线连接为例。
250.其中，处理器901是第一设备90的计算核心以及控制核心，其可以解析第一设备90内的各类指令以及第一设备90的各类数据，例如：该处理器901可为中央处理器(central processing unit，cpu)，可以在第一设备90内部结构之间传输各类交互数据，等等。通信接口902可选的可以包括标准的有线接口、无线接口(如wi-fi、移动通信接口等)，受处理器901的控制可以用于收发数据；通信接口902还可以用于第一设备90内部信令或者指令的传输以及交互。存储器903(memory)是第一设备90中的记忆设备，用于存放程序和数据。可以理解的是，此处的存储器903既可以包括第一设备90的内置存储器，当然也可以包括第一设备90所支持的扩展存储器。存储器903提供存储空间，该存储空间存储了第一设备90的操作系统，可包括但不限于：android系统、ios系统、windows phone系统等等，本技术对此并不作限定，该存储空间还存储了处理器执行相应操作所需的程序代码或指令，可选的，该存储空间还可以存储该处理器执行该相应操作后产生的相关数据。
251.在本技术实施例中，处理器901运行存储器903中的可执行程序代码，用于执行如下操作：
252.通过所述通信接口902接收所述云服务器发送的第一微服务应用的配置文件，其中，所述云服务器用于管理多个微服务应用的配置文件，所述多个微服务应用包括第一微服务应用和第二微服务应用，所述第一微服务应用和所述第二微服务应用分别配置在所述第一设备和第二设备；所述第一微服务应用为所述第一设备配置的至少两个微服务应用中的一个微服务应用；
253.根据所述配置文件配置所述第一微服务应用。
254.在一种可选方案中，所述处理器901在接收所述云服务器发送的第一微服务应用的配置文件之前，还用于：
255.确定所述第一微服务应用存在已备份的配置文件；
256.通过所述通信接口902向所述云服务器发送所述请求消息，所述请求消息用于请求所述第一微服务应用的最新的配置文件的标识信息，所述标识信息包括版本号和md5值；
257.通过所述通信接口902接收所述云服务器发送的所述第一微服务应用的最新的配置文件的标识信息；
258.对比所述云服务器发送的配置文件的标识信息与已备份的配置文件的标识信息，以确定所述第一微服务已备份的配置文件是否为最新的配置文件；
259.若所述第一微服务应用已备份的配置文件不为最新的配置文件，则向所述云服务器发送配置更新请求。
260.在又一种可选方案中，所述处理器901在接收所述云服务器发送的第一微服务应用的配置文件之前，还用于：
261.通过所述通信接口902向所述云服务器发送所述第一微服务应用的配置文件的订阅请求。
262.在这个过程中设有消息队列中间件实现订阅接收，如rabbitmq、kafka等，在使用消息队列中间件的过程中，所述第一微服务应用向所述云服务器发送所述第一微服务应用的配置文件的订阅请求，请求订阅配置文件相关的主题，而所述云服务器在接收到所述第一微服务应用的订阅请求后，配置所述第一微服务应用订阅主题，当所述第一微服务应用的配置文件发生变化时，推送相关配置文件到订阅方，即将所述第一微服务应用的配置文件发送到所述第一微服务应用，达到热更新效果，并且能够保证设备的正常运行。
263.需要说明的是，各个操作的实现还可以对应参照图2、图3、图4和图5所示的方法实施例中第一设备一侧的相应描述。
264.本技术实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述计算机程序当被处理器执行时使所述处理器实现图2、图3、图4或图5所述实施例中云服务器所执行的操作，或者实现图2、图3、图4或图5所述实施例中第一设备所执行的操作。
265.本技术实施例还提供一种计算机程序产品，当所述计算机程序产品在处理器上运行时，实现图2、图3、图4或图5所述实施例中云服务器所执行的操作，或者图2、图3、图4或图5所述实施例中第一设备所执行的操作。
266.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，可以通过程序来指令相关的硬件来完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可存储程序代码的介质。