一种固件升级方法及系统

技术领域

本申请涉及数据通信技术领域，尤其涉及一种固件升级方法及系统。

背景技术

随着信息技术的高速发展，智能化的设备越来越多。为了提升设备的性能以及使用体验等，设备的厂家或服务商会定期或不定期对设备的固件进行升级。

现目前，对设备的固件进行升级时，服务器直接向批量化的设备推送升级命令，当设备接收到升级命令后，请求下载固件包并完成固件升级。采用这种方式，可能出现大量设备因固件包、网络、存储空间等因素无法进行升级或拒绝升级的情况。

发明内容

本申请的目的在于克服现有技术的缺陷，提供一种固件升级方法及系统，用以解决现有技术中，批量化升级固件时，可能出现大量设备因固件包、网络、存储空间等因素无法进行升级或拒绝升级的问题。

为解决上述问题，本申请实施例第一方面，提供了一种固件升级方法，该方法，包括：

上传固件包；

向测试设备推送升级命令，使得所述测试设备下载所述固件包并进行固件升级；

根据所述测试设备的升级结果，判断所述固件包是否通过测试；

当所述固件包通过测试，对所述固件包所对应的升级条件进行存储；

待升级设备定时查询自身是否满足所述升级条件，当满足所述升级条件时，所述待升级设备请求下载所述固件包；

向所述待升级设备传输所述固件包。

一种可选的实现方式中，根据请求下载所述固件包的所述待升级设备的总数量，控制每个预设时段内下载所述固件包的所述待升级设备的数量。

一种可选的实现方式中，根据上一个所述预设时段内下载所述固件包的所述待升级设备的固件升级成功率，对下一个所述预设时段内下载所述固件包的所述待升级设备的数量进行调整。

一种可选的实现方式中，当上一个所述预设时段内下载所述固件包的所述待升级设备的固件升级成功率不低于预设成功率时，则提高下一个所述预设时段内下载所述固件包的所述待升级设备的数量。

一种可选的实现方式中，当上一个所述预设时段内下载所述固件包的所述待升级设备的固件升级成功率低于预设成功率时，则拒绝剩余所述待升级设备请求下载所述固件包的请求。

一种可选的实现方式中，所述“控制每个预设时段内下载所述固件包的所述待升级设备的数量”包括：

以预设速率向令牌桶内加入令牌；

当所述待升级设备请求下载所述固件包时，查询所述令牌桶内是否有所述令牌；

当所述令牌桶内有所述令牌时，则使得所述待升级设备获取所述令牌并允许所述固件包。

一种可选的实现方式中，当所述令牌桶内没有所述令牌时，则向所述待升级设备发出等待指令，以使得所述待升级设备等待预设时长后再发出下载所述固件包的请求。

一种可选的实现方式中，所述预设速率与请求下载所述固件包的所述待升级设备的总数量正相关。

一种可选的实现方式中，所述测试设备有多台，且全部所述测试设备的固件均升级成功，则判定所述固件包通过测试。

本申请实施例第二方面，提供了一种固件升级系统，该系统包括：

上传模块，用于上传固件包；

推送模块，用于向测试设备推送升级命令，使得所述测试设备下载所述固件包并进行固件升级；

判断模块，用于根据所述测试设备的升级结果，判断所述固件包是否通过测试；

存储模块，用于当所述固件包通过测试，对所述固件包所对应的升级条件进行存储；

查询模块，用于待升级设备定时查询自身是否满足所述升级条件，当满足所述升级条件时，所述待升级设备请求下载所述固件包；

传输模块，用于向所述待升级设备传输所述固件包。

本申请的有益效果是：先利用测试设备对固件包进行测试，以确保固件包的可靠性和稳定性；待升级设备在进行固件升级前，需定时查询自身是否满足升级条件。其中，只有满足升级条件的待升级设备才能够下载通过测试固件包并实现固件升级，由此提升了待升级设备固件升级的成功率。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了一种固件升级方法的流程图；

图2示出了一种令牌桶控制下载量的流程图；

图3示出了一种固件升级系统的示意图。

附图标记：

11-上传模块；12-推送模块；13-判断模块；14-存储模块；15-查询模块；16-传输模块。

具体实施方式

下面结合附图，对本申请实施例进行描述。显然，所描述的实施例仅为本申请一部分实施例，而不是全部的实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请的保护范围。

实施例

在本实施例中，提出了一种固件升级方法，其步骤包括：

S1，上传固件包；

S2，向测试设备推送升级命令，使得测试设备下载固件包并进行固件升级；

S3，根据测试设备的升级结果，判断固件包是否通过测试；

S4，当固件包通过测试，对固件包所对应的升级条件进行存储；

S5，待升级设备定时查询自身是否满足升级条件，当满足升级条件时，待升级设备请求下载固件包；

S6，向待升级设备传输固件包。

在向设备推送固件包前，会先利用测试设备对固件包进行测试，当固件包测试通过后，才会开放给待升级设备进行下载。为了设备下载固件包后能够升级成功，待升级设备在请求下载固件包前，需要定时查询自身是否满足升级条件，只有满足升级条件的待升级设备才能够请求下载固件包，由此提升了固件升级的成功率。其中，待升级设备完成固件包的下载后，并会自动开始升级固件。

可选地，升级条件包括待升级设备的型号为指定型号。

可选地，升级条件包括待升级设备当前的固件版本为指定版本。

可选地，升级条件包括待升级设备当前所处的网络符合预设要求。

除了上述升级条件外，其他会对固件升级产生影响的因素均可以包含在升级条件中。

在本实施例中，固件升级是否升级成功可以通过设备是否可以正常运行以及是否出现故障代码等方式来判断。

对固件包进行测试时，为了提高测试结果的准确性和可靠性，测试设备配置有多台，其中，全部测试设备的固件均升级成功，则判定固件包通过测试。

固件包通过测试后，对固件包所对应的升级条件进行存储，其中，可将升级信息存储在一个缓存中间件中，方便待升级设备查询自身是否满足升级条件，从而可以有效地提升数据查询的效率。

为了使升级的结果可控，避免出现大批量设备升级失败的情况出现，需要控制每个预设时段内下载固件包的待升级设备的数量。

当多台待升级设备满足升级条件时，这些待升级设备都会请求下载固件包，此时，根据请求下载固件包的待升级设备的总数量，控制每个预设时段内下载固件包的待升级设备的数量。

进一步地，根据上一个预设时段内下载固件包的待升级设备的固件的升级成功率，对下一个预设时段内下载固件包的待升级设备的数量进行调整。

需要说明的是，“上一个预设时段”与“下一个预设时段”为相邻的两个时段，且两者之间可以存在时间间隔，由此保证上一个预设时段内下载固件包的待升级设备，有充足的时间对固件包进行下载以及完成固件升级。

另外，“上一个预设时段”与“下一个预设时段”两者所对应的时长可以相同或不同。可选地，每个预设时段所对应的时长可根据该预设时段下载固件包的待升级设备的数量进行调整。

下一个预设时段允许下载固件包的待升级设备的数量，会受到上一个预设时段内下载固件包的待升级设备的固件升级成功率的影响：

当上一个预设时段内下载固件包的待升级设备的固件升级成功率不低于预设成功率时，则提高下一个预设时段内下载固件包的待升级设备的数量；

当上一个预设时段内下载固件包的待升级设备的固件升级成功率低于预设成功率时，则拒绝剩余待升级设备请求下载固件包的请求。

在本实施例中，预设成功率均可以根据实际情况进行设置和调整。

为方便理解，对上述方式举例进行说明：

假设当前时间为18:00，且有1000台待升级设备都满足升级条件，那么这1000台待升级设备都会请求下载固件包。第一预设时段可设置为18:00-18:30，其中，在第一预设时段内，允许100台(占总数的10％)待升级设备下载固件包。如果第一预设时段内的100台待升级设备中不低于90％(即升级成功率不低于90％)升级成功，则提高第二预设时段内下载固件包的待升级设备的数量，例如，在第二预设时段内，可允许200台(占总数的20％)待升级设备下载固件。

第二预设时段可设置为19:00-19:40，其中，如果第二预设时段内下载固件包的待升级设备升级成功率低于90％(大于20台待升级设备的升级失败)，那么便会拒绝剩余的700台待升级设备请求下载固件包的请求。

在上述示例中，第一预设时段相对于第二预设时段为上一个预设时段，第二预设时段相对于第一预设时段为下一个预设时段。其中，预设成功率设为90％。

如果上一个预设时段内，下载固件包的待升级设备的升级成功率不低于预设成功率，可以提高下一个预设时段内允许下载固件包的待升级设备的占总数的百分比，直至全部待升级设备都完成对固件包的下载，如此在保证升级成功率的同时，还能够提高升级的效率。

在本实施例中，为了控制每个预设时段内的下载固件包的量，可利用令牌桶实现下载量的控制，以下对令牌桶如何实现对下载量的控制进行说明。

参照图2所示，为了控制每个预设时段内下载固件包的待升级设备的数量，可进行如下设置：

S21，以预设速率向令牌桶内加入令牌；

S22，当待升级设备请求下载固件包时，查询令牌桶内是否有令牌；

S23，当令牌桶内有令牌时，则使得待升级设备获取令牌并允许固件包；

S24，当令牌桶内没有令牌时，则向待升级设备发出等待指令，以使得待升级设备等待预设时长后再发出下载固件包的请求。

可选地，预设速率可以根据实际进行设置，例如每一分钟向令牌桶内加入一百个令牌或每十分钟向令牌桶内加入一百个令牌等。

在本实施例中，预设速率可与请求下载固件包的待升级设备的总数量正相关，即请求下载固件包的待升级设备越多，预设速率就越快，由此提高下载的效率。

在本实施例中，通过预设速率向令牌桶中放置令牌，当有待升级设备下载请求来时，若令牌桶中有令牌，则说明请求流量在允许范围内，此时，待升级设备会取走令牌，其中，获得令牌的待升级设备便被允许下载固件包；若令牌桶中没有令牌，说明当前请求下载的速率超过了允许的下载速率，则会触发流控措施，其中，可通过让待升级设备等待一定时间的方式限制下载量。

在本实施例中，通过灰度升级的方式进行固件的推送，能对升级结果提前预知，方便工作人员给出针对性的解决方案，避免出现大批量待升级设备集体升级失败的情况。另外，使用基于令牌桶的流控机制，既保证了待升级设备请求下载的整体速率，又允许突发的流量请求。

与上述固件升级方法相对应的，在本实施例中，还提出了一种固件升级系统。

如图3所示，固件升级系统包括：

上传模块11，用于上传固件包；

推送模块12，用于向测试设备推送升级命令，使得测试设备下载固件包并进行固件升级；

判断模块13，用于根据测试设备的升级结果，判断固件包是否通过测试；

存储模块14，用于当固件包通过测试，对固件包所对应的升级条件进行存储；

查询模块15，用于待升级设备定时查询自身是否满足升级条件，当满足升级条件时，待升级设备请求下载固件包；

传输模块16，用于向待升级设备传输固件包。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。