静态代码扫描规则的更新方法和更新装置与流程

1.本技术涉及计算机技术领域，尤其涉及一种静态代码扫描规则的更新方法和更新装置。


背景技术：

2.sonarqube为静态代码检查工具，采用浏览器/服务器(browser/server，b/s)架构，帮助检查代码缺陷，改善代码质量，提高开发速度。
3.sonarqube服务器可以使用自带的规则集中的规则对代码进行扫描。具体地，在sonarqube服务器执行扫描任务时，sonarqube服务器根据代码扫描需求和自带的规则集中的规则进行匹配，当匹配成功时，sonarqube服务器使用匹配成功的规则对代码进行扫描。
4.但是，在一些特定领域或问题上，代码扫描需求越来越多，sonarqube服务器自带的规则集中的规则无法满足代码扫描需求，用户需要自定义代码扫描规则。另外，不同的代码扫描规则需要不同的插件支持，用户在自定义代码扫描规则的同时，需要同步更新插件。当sonarqube服务器较多，且规则变更比较频繁时，用户需要频繁地使用手动操作对每个sonarqube服务器的规则和插件进行更新，存在操作繁琐、效率较低的问题。


技术实现要素：

5.本技术提供了一种静态代码扫描规则的更新方法和更新装置，可以提高sonarqube服务器更新规则和插件的效率，减少sonarqube服务器更新规则和插件的手动操作。
6.第一方面，本技术提供了一种静态代码扫描规则的更新方法，应用于包括第一服务器和至少一个第二服务器的系统，至少一个第二服务器部署有静态代码检查工具，该方法包括：第一服务器根据第一配置文件中的插件信息，获取与插件信息对应的多个插件；第一服务器根据第二配置文件中的规则信息，获取与规则信息对应的多个静态代码扫描规则；第一服务器每隔第一时长或者基于联机更新指令向至少一个第二服务器中的全部或部分服务器发送多个插件中的至少一个插件和多个静态代码扫描规则中的至少一个静态代码扫描规则。
7.本技术提供的静态代码扫描规则的更新方法，第一服务器可以每隔第一时长或者基于联机更新指令向第二服务器发送插件和静态代码扫描规则，可以自动更新第二服务器的插件和静态代码扫描规则，可以降低第一服务器的管理人员和第二服务器的管理人员的沟通成本，避免手动安装插件和规则出现失误而导致的扫描问题的出现，可以提高第二服务器更新规则和插件的效率，减少第二服务器更新规则和插件的手动操作，更加灵活的实现插件和规则的同步管理。
8.结合第一方面，在第一方面的某些实现方式中，上述方法还包括：第一服务器判断至少一个第二服务器中的第一目标服务器是否存在与多个插件中的第一插件名称相同的第二插件；在第一目标服务器存在第二插件的情况下，第一服务器判断第二插件的版本是
否低于第一插件的版本；第一服务器每隔第一时长或者基于联机更新指令向至少一个第二服务器中的全部或部分服务器发送多个插件中的至少一个插件和多个静态代码扫描规则中的至少一个静态代码扫描规则，包括：在第二插件的版本低于第一插件的版本的情况下，第一服务器向第一目标服务器发送第一插件。
9.本技术提供的静态代码扫描规则的更新方法，第一服务器可以先判断第一目标服务器中已有的插件中是否存在与第一插件名称相同的第二插件，再比较第一插件和第二插件的版本信息，最后决定是否要向第一目标服务器发送第一插件，可以避免第一目标服务器在存在第一插件的情况下，重复更新插件，可以提高第一目标服务器更新插件的效率。
10.结合第一方面，在第一方面的某些实现方式中，上述方法还包括：第一服务器判断至少一个第二服务器中的第一目标服务器是否存在规则集；在第一目标服务器存在规则集的情况下，判断规则集中是否包括多个静态代码扫描规则；第一服务器每隔第一时长或者基于联机更新指令向至少一个第二服务器中的全部或部分服务器发送多个插件中的至少一个插件和多个静态代码扫描规则中的至少一个静态代码扫描规则，包括：在规则集中不包括多个静态代码扫描规则中的第一静态代码扫描规则的情况下，第一服务器向第一目标服务器发送第一静态代码扫描规则。
11.本技术提供的静态代码扫描规则的更新方法，第一服务器可以先判断第一目标服务器中已有的规则集中是否存在第一静态代码扫描规则，在第一目标服务器中已有的规则集中不存在第一静态代码扫描规则的情况下，第一目标服务器将第一静态代码扫描规则添加到规则集，可以避免第一目标服务器在存在第一静态代码扫描规则的情况下，重复更新第一静态代码扫描规则，可以提高第一目标服务器更新静态代码扫描规则的效率。
12.结合第一方面，在第一方面的某些实现方式中，在第一服务器判断至少一个第二服务器中的第一目标服务器是否存在规则集之前，上述方法还包括：第一服务器获取第一目标服务器的统一资源定位器(uniform resource locator，url)地址和密码信息；第一服务器根据第一目标服务器的url地址和密码信息，获取第一目标服务器上已有的插件和静态代码扫描规则。
13.本技术提供的静态代码扫描规则的更新方法，第一服务器可以获取第一目标服务器的url地址和密码信息，可以对第一目标服务器进行操作，可以较少第一目标服务器的管理人员的手动操作，且当第一目标服务器数量较多时，可以提高多个第一目标服务器更新插件和静态代码扫描规则的效率。
14.结合第一方面，在第一方面的某些实现方式中，规则信息包括多个静态代码扫描规则中每个静态代码扫描规则的规则标识、规则等级以及规则状态。
15.第二方面，本技术提供了另一种静态代码扫描规则的更新方法，应用于包括第一服务器和至少一个第二服务器的系统，至少一个第二服务器部署有静态代码检查工具，该方法包括：至少一个第二服务器中的第一目标服务器每隔第一时长或者基于联机更新指令接收来自第一服务器的至少一个插件和至少一个静态代码扫描规则；第一目标服务器根据至少一个插件和至少一个静态代码扫描规则，对第一目标服务器中已有的插件和静态代码扫描规则进行更新；第一目标服务器在更新完成后进行重启。
16.结合第二方面，在第二方面的某些实现方式中，上述方法还包括：第一目标服务器检测到用户的第一更新操作，第一更新操作用于更新第一目标服务器的静态代码扫描规
则；第一目标服务器响应于第一更新操作，向第一服务器发送联机更新指令，联机更新指令携带第一目标服务器的url地址、规则集的名称、以及规则集对应的配置文件的路径。
17.本技术提供的静态代码扫描规则的更新方法，第一目标服务器的管理员可以通过简单的手动操作(输入第一目标服务器的url地址、规则集的名称、以及规则集对应的配置文件的路径)按需更新插件和静态代码扫描规则，可以提高第一目标服务器更新插件和静态代码扫描规则的效率。
18.结合第二方面，在第二方面的某些实现方式中，在第一目标服务器根据至少一个插件和至少一个静态代码扫描规则，对第一目标服务器中已有的插件和静态代码扫描规则进行更新之后，上述方法还包括：第一目标服务器将更新失败的插件和静态代码扫描规则生成错误日志；第一目标服务器显示错误日志，以便第一目标服务器的管理员查看。
19.本技术提供的静态代码扫描规则的更新方法，第一目标服务器可以显示错误日志，便于第一目标服务器的管理人员分析插件和静态代码扫描规则更新失败的原因，有利于第一目标服务器的管理人员了解更新插件和静态代码扫描规则的情况，还可以提高静态代码扫描规则的更新的质量。
20.第三方面，本技术提供了一种静态代码扫描规则的更新装置，该装置包括：处理模块和收发模块。处理模块用于：根据第一配置文件中的插件信息，获取与插件信息对应的多个插件；以及，根据第二配置文件中的规则信息，获取与规则信息对应的多个静态代码扫描规则；收发模块用于：每隔第一时长或者基于联机更新指令向至少一个第二服务器中的全部或部分服务器发送多个插件中的至少一个插件和多个静态代码扫描规则中的至少一个静态代码扫描规则。
21.结合第三方面，在第三方面的某些实现方式中，上述处理模块还用于：判断至少一个第二服务器中的第一目标服务器是否存在与多个插件中的第一插件名称相同的第二插件；在第一目标服务器存在第二插件的情况下，判断第二插件的版本是否低于第一插件的版本；上述收发模块还用于：在第二插件的版本低于第一插件的版本的情况下，向第一目标服务器发送第一插件。
22.结合第三方面，在第三方面的某些实现方式中，上述处理模块还用于：判断至少一个第二服务器中的第一目标服务器是否存在规则集；在第一目标服务器存在规则集的情况下，判断规则集中是否包括多个静态代码扫描规则；上述收发模块还用于：在规则集中不包括多个静态代码扫描规则中的第一静态代码扫描规则的情况下，向第一目标服务器发送第一静态代码扫描规则。
23.结合第三方面，在第三方面的某些实现方式中，上述处理模块还用于：获取第一目标服务器的统一资源定位器url地址和密码信息；根据第一目标服务器的url地址和密码信息，获取第一目标服务器上已有的插件和静态代码扫描规则。
24.结合第三方面，在第三方面的某些实现方式中，规则信息包括多个静态代码扫描规则中每个静态代码扫描规则的规则标识、规则等级以及规则状态。
25.第四方面，本技术提供了一种静态代码扫描规则的更新装置，该装置包括：收发模块和处理模块。该收发模块用于：每隔第一时长或者基于联机更新指令接收来自第一服务器的至少一个插件和至少一个静态代码扫描规则；处理模块用于：根据至少一个插件和至少一个静态代码扫描规则，对该装置已有的插件和静态代码扫描规则进行更新；在更新完
成后进行重启。
26.结合第四方面，在第四方面的某些实现方式中，上述处理模块还用于：检测到用户的第一更新操作，第一更新操作用于更新上述装置的静态代码扫描规则；上述收发模块还用于：响应于第一更新操作，向第一服务器发送联机更新指令，联机更新指令携带上述装置的url地址、规则集的名称、以及规则集对应的配置文件的路径。
27.结合第四方面，在第四方面的某些实现方式中，上述处理模块还用于：将更新失败的插件和静态代码扫描规则生成错误日志；上述装置还包括显示模块，该显示模块用于显示错误日志，以便上述装置的管理员查看。
28.第五方面，本技术提供了另一种静态代码扫描规则的更新装置，包括处理器和存储器。该处理器用于读取存储器中存储的指令，以执行上述任一方面中任一种可能实现方式中的方法。
29.可选地，处理器为一个或多个，存储器为一个或多个。
30.可选地，存储器可以与处理器集成在一起，或者存储器与处理器分离设置。
31.在具体实现过程中，存储器可以为非瞬时性(non-transitory)存储器，例如只读存储器(read only memory，rom)，其可以与处理器集成在同一块芯片上，也可以分别设置在不同的芯片上，本技术实施例对存储器的类型以及存储器与处理器的设置方式不做限定。
32.上述第五方面中的静态代码扫描规则的更新装置可以是一个芯片，该处理器可以通过硬件来实现也可以通过软件来实现，当通过硬件实现时，该处理器可以是逻辑电路、集成电路等；当通过软件来实现时，该处理器可以是一个通用处理器，通过读取存储器中存储的软件代码来实现，该存储器可以集成在处理器中，可以位于该处理器之外，独立存在。
33.第六方面，本技术提供了一种计算机可读介质，所述计算机可读介质存储有计算机程序(也可以称为代码，或指令)当其在计算机上运行时，使得计算机执行上述任一方面中任一种可能实现方式中的方法。
34.第七方面，本技术提供了一种计算机程序产品，计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当计算机程序被运行时，使得计算机执行上述任一方面中任一种可能实现方式中的方法。
附图说明
35.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。
36.图1为本技术实施例适用的一种通信系统的示意图；
37.图2为本技术实施例提供的一种静态代码扫描规则的更新方法的示意性流程图；
38.图3为本技术实施例提供的一种静态代码扫描规则的更新装置的示意性框图；
39.图4为本技术实施例提供的另一种静态代码扫描规则的更新装置的示意性框图。
40.通过上述附图，已示出本技术明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本技术构思的范围，而是通过参考特定实施例为本领域技术人员说明本技术的概念。
具体实施方式
41.下面将结合附图，对本技术中的技术方案进行描述。
42.静态代码扫描是指在软件工程中，程序员在写好代码后，无需经过编译器编译，而是直接使用一些扫描工具对代码进行扫描，找出代码当中存在的一些语义缺陷、安全漏洞的一种解决方案。
43.sonarqube是一种静态代码扫描的自动代码审查工具，可以用于检测代码中的错误、漏洞以及代码异常等缺陷。
44.其中，sonarqube是一个开源平台，用于管理代码的质量。sonarqube通过插件形式，可以支持java、c++、javascripe、c、php、c#、cobol、pl/sql、flex等二十几种编程语言的代码质量管理与检测。
45.安装sonarqube的服务器可以称为sonarqube服务器。sonarqube服务器可以使用自带的规则集中的规则对代码进行扫描。具体地，在sonarqube服务器执行扫描任务时，sonarqube服务器根据代码扫描需求和自带的规则集中的规则进行匹配，当匹配成功时，sonarqube服务器使用匹配成功的规则对代码进行扫描。
46.但是，在一些特定领域或问题上，代码扫描需求越来越多，sonarqube服务器自带的规则集中的规则无法满足代码扫描需求，用户需要自定义代码扫描规则。
47.示例性地，sonarqube服务器自带的规则集中的规则可以用于扫描c++语言的代码，但用户需要使用sonarqube服务器对java语言的代码进行扫描，此时，用户需要手动创建新的规则集，手动输入新的规则集的名称和语言类型，并需要手动筛选出新的规则，并添加到新的规则集中以适应代码扫描需求。
48.另外，不同的代码扫描规则需要不同的插件支持，用户在自定义代码扫描规则的同时，需要同步更新插件。
49.示例性地，更新插件时，用户可以使用远程连接软件(例如xshell软件)登录sonarqube服务器，进入sonarqube服务器自带的插件的目录，例如目录可以是extensions/plugins。用户可以通过指令“rm-rf插件名”删除sonarqube服务器自带的插件，并可以通过wget下载新的插件。
50.当sonarqube服务器较多，且规则变更比较频繁时，用户需要频繁地使用手动操作对每个sonarqube服务器的规则和插件进行更新，存在操作繁琐、效率较低的问题。
51.示例性地，存在3个sonarqube服务器，每个sonarqube服务器的规则和插件均需要更新，用户需要在每个sonarqube服务器上手动进行删除旧的插件、下载新的插件、创建新的规则集、在新的规则集中添加新的规则等操作。当每个sonarqube服务器需要更新的规则和插件均相同时，用户需要在每个sonarqube服务器上重复相同的操作，存在操作繁琐、效率较低的问题。
52.有鉴于此，在计算机技术领域中，本技术实施例提供了一种静态代码扫描规则的更新方法和更新装置，可以提高sonarqube服务器更新规则和插件的效率，减少sonarqube服务器更新规则和插件的手动操作。
53.为了便于理解本技术实施例，首先对本技术实施例适用的通信系统进行介绍。
54.图1为本技术实施例提供的一种通信系统100的示意图，如图1所示，通信系统100包括服务器101、服务器102、服务器103以及服务器104。其中，服务器102、服务器103以及服
务器104均安装有静态代码检查工具。示例性地，在静态代码检查工具为上述sonarqube的情况下，服务器102、服务器103以及服务器104也可以称为sonarqube服务器102、sonarqube服务器103以及sonarqube服务器104。
55.服务器101也可以称为中心服务器，用于统一管理服务器102、服务器103以及服务器104。
56.服务器102、服务器103以及服务器104也可以称为部门服务器，用于服务于一个部门员工的日常工作。
57.当服务器102、服务器103以及服务器104中的规则集中的规则和插件需要更新时，服务器101可以通过本技术实施例提供的静态代码扫描规则的更新方法自动更新服务器102、服务器103以及服务器104中的规则集中的规则和插件，可以提高服务器102、服务器103以及服务器104更新规则和插件的效率，减少服务器102、服务器103以及服务器104更新规则和插件的手动操作。
58.在介绍本技术实施例提供的静态代码扫描规则的更新方法和更新装置之前，先做出以下几点说明。
59.第一，在下文示出的实施例中第一、第二以及各种数字编号仅为描述方便进行的区分，并不用来限制本技术实施例的范围。例如，区分不同的配置文件、区分不同的服务器等。
60.第二，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b的情况，其中a，b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a、b和c中的至少一项(个)，可以表示：a，或b，或c，或a和b，或a和c，或b和c，或a、b和c，其中a，b，c可以是单个，也可以是多个。
61.图2为本技术实施例提供的一种静态代码扫描规则的更新方法200的示意性流程图，该方法200可以应用于包括第一服务器和至少一个第二服务器的系统，该至少一个第二服务器部署有静态代码检查工具。其中，静态代码扫描工具可以为sonarqube。在一种可能的实现方式中，该方法200可以应用于上述图1所示的通信系统100，应理解，本技术实施例并不限于此。
62.该方法200可以包括如下步骤：
63.s201、第一服务器根据第一配置文件中的插件信息，获取与插件信息对应的多个插件。
64.第一服务器可以是上述图1中的服务器101。
65.第一配置文件可以包括多个插件的信息，第一服务器可以根据该多个插件的信息，获得该多个插件。
66.第一配置文件中的插件信息可以是第一服务器的管理人员预设的。
67.第一配置文件中插件的个数可以为一个，也可以为两个或两个以上，本技术实施例对第一配置文件中插件的个数不作限定。
68.插件信息可以包括以下至少一个信息：历史版本、分类说明、开发者、主页、问题跟踪、许可证信息、版本修改日志链接、版本号、版本发布日期、版本修改说明、版本下载地址
或者依赖版本。其中，历史版本包括插件的历史存档版本。分类说明可以约定分类的关键字，以便于检索出相关插件，例如，分类的关键字可以为“icbc”。问题跟踪用于链接gitlab平台问题管理页面，用户可在gitlab项目中提问题到issue。
69.示例性地，第一配置文件的名称可以为update-center.properties，第一配置文件中的内容可以包括：
70.历史版本：javacustom.archivedversions＝0.0.16,0.0.19,0.0.20；
71.分类说明：javacustom.category＝icbc-java；
72.开发者：javacustom.description＝code analyzer for javacustom；
73.主页：
74.javacustom.homepageur1＝http\://www.mygitlab.com/os/sonar-icbc-java/blo b/master/update-center.properties；
75.问题跟踪：
76.javacustom.issuetrackerur1＝http\://www.mygitlab.com/os/sonar-icbc-java/blob/master/update-center.properties；
77.许可证信息：javacustom.license＝icbc license；
78.版本修改日志链接：
79.javacustom.0.0.20.changelogur1＝http\://jira.sonarsource.com/secure/releasenote.jspa？projectid\＝11732&version\＝14828；
80.版本号：javacustom.0.0.20.displayversion＝0.0.20；
81.版本发布日期：javacustom.0.0.20.date＝2019-03-18；
82.版本修改说明：javacustom.0.0.20.description＝rules\u6211\u662f\u63cf\u8ff0improvements，
83.版本下载地址：
84.javacustom.0.0.20.downloadur1＝http\://122.16.61.59:9000/nexus/service/local/repositories/sonar-publish/content/pl ugins/sonar-icbc-java-0.0.20；
85.依赖版本：javacustom.0.0.20.sqversion＝7.9.1。
86.可选地，上述系统还可以包括插件服务器，插件服务器用于为第一服务器提供插件，同时可以存储第一配置文件。例如，第一配置文件可以存储在插件服务器的根目录中。
87.第一服务器可以通过url地址从插件服务器中下载第一配置文件，并获取第一配置文件的插件信息，然后根据插件信息中版本下载地址从插件服务器中下载插件。
88.示例性地，url地址可以为http://www.pluginsserver.com/update-center.propertie，第一服务器可以通过http://www.pluginsserver.com/update-center.propertie地址从插件服务器中下载update-center.propertie(第一配置文件)。
89.s202、第一服务器根据第二配置文件中的规则信息，获取与规则信息对应的多个静态代码扫描规则。
90.第二配置文件可以包括多个静态代码扫描规则的信息，第一服务器可以根据该多个静态代码扫描规则的信息，获得该多个静态代码扫描规则。
91.示例性地，第一服务器获得该多个静态代码扫描规则后，可以将该多个静态代码
扫描规则保存在内存中，便于后续使用接口调用该多个静态代码扫描规则。
92.第二配置文件中的多个静态代码扫描规则可以对应一个规则集，该规则集的名称可以与第二配置文件的名称相同。
93.示例性地，第二配置文件的名称为icbc_all_base.xls，第二配置文件对应的规则集的名称可以为icbc_all_base。
94.第二配置文件中的规则信息可以是第一服务器的管理人员预设的。
95.第二配置文件可以存储在第一服务器中，以便于第一服务器获取第二配置文件中的规则信息。
96.第二配置文件中静态代码扫描规则的个数可以为一个，也可以为两个或两个以上，本技术实施例对第二配置文件中静态代码扫描规则的个数不作限定。
97.可选地，规则信息可以包括多个静态代码扫描规则中每个静态代码扫描规则的规则标识、规则等级以及规则状态。
98.其中，规则标识可以是规则在第一服务器中的唯一标识。规则等级可以用于表示规则的严重程度，例如，严重程度从高到低依次可以为阻断、严重、主要、次要以及提示五个等级，规则等级可以为问题处理的参考依据。规则状态用于表示该规则正常启用或者用于表示该规则被挂起。
99.示例性地，第二配置文件包括用于扫描java代码的规则的信息。静态代码扫描规则的个数可以为4个，第一个静态代码扫描规则的规则标识为squid：methodcyclomaticcomplexity、规则等级为次要以及规则状态为正常启用。第二个静态代码扫描规则的规则标识为pmd：assertusedconventions、规则等级为阻断以及规则状态为挂起。第三个静态代码扫描规则的规则标识为pmd：mustunregisterreceiver、规则等级为次要以及规则状态为正常启用。第四个静态代码扫描规则的规则标识为pmd：nospecialsystemmethod、规则等级为阻断以及规则状态为正常启用。
100.可选地，sonarqube可以支持二十几种语言，每一种语言可以对应一个第二配置文件。该第二配置文件包括用于扫描某一种语言所构成的代码的规则的信息。
101.s203、第一服务器每隔第一时长或者基于联机更新指令向至少一个第二服务器中的全部或部分服务器发送多个插件中的至少一个插件和多个静态代码扫描规则中的至少一个静态代码扫描规则，对应地，至少一个第二服务器中的第一目标服务器接收到至少一个插件和至少一个静态代码扫描规则。
102.应理解，本技术实施例的第一目标服务器即为上述全部或部分服务器中的一个服务器。示例性地，第一目标服务器可以为上述图1所示的通信系统100中的服务器102、服务器103或者服务器104。
103.第一服务器可以每隔第一时长向至少一个第二服务器中的全部服务器发送至少一个插件和至少一个静态代码扫描规则，即第一服务器可以定时向至少一个第二服务器中的全部服务器发送至少一个插件和至少一个静态代码扫描规则。其中，第一时长的长度可以由第一服务器的管理人员按需设置，第一服务器的管理人员可以实时调整第一时长的长度。
104.示例性地，第一时长可以为24小时，第一服务器可以通过定时调度工具(例如jenkins)，每隔24小时向至少一个第二服务器中的全部服务器发送至少一个插件和至少一
个静态代码扫描规则。例如，第一服务器可以每天19:00向至少一个第二服务器中的全部服务器发送至少一个插件和至少一个静态代码扫描规则。
105.第一服务器可以基于联机更新指令向至少一个第二服务器中的部分服务器发送至少一个插件和至少一个静态代码扫描规则。以其中一个服务器，即第一目标服务器为例，联机更新指令可以是第一目标服务器的管理人员按需设置的。第一目标服务器的管理人员可以通过第一目标服务器向第一服务器发送联机更新指令，第一服务器可以基于联机更新指令向该第一目标服务器发送至少一个插件和至少一个静态代码扫描规则。
106.s204、第一目标服务器根据至少一个插件和至少一个静态代码扫描规则，对第一目标服务器中已有的插件和静态代码扫描规则进行更新。
107.第一目标服务器对第一目标服务器中已有的插件和静态代码扫描规则进行更新，包括：在第一目标服务器中已有的插件和静态代码扫描规则不包括接收到的至少一个插件和至少一个静态代码扫描规则的情况下，第一目标服务器将接收到的至少一个插件和至少一个静态代码扫描规则添加到第一目标服务器中已有的插件和静态代码扫描规则。
108.在第一目标服务器中已有的插件和静态代码扫描规则包括接收到的至少一个插件和至少一个静态代码扫描规则的情况下，将第一目标服务器中已有的插件和静态代码扫描规则更新为接收到的至少一个插件和至少一个静态代码扫描规则。
109.s205、第一目标服务器在更新完成后进行重启。
110.第一目标服务器可以在更新完成后自动重启，也可以基于第一服务器发送的重启指令或者第一目标服务器的管理员的需求，在更新完成后进行重启。
111.本技术实施例提供的静态代码扫描规则的更新方法，第一服务器可以每隔第一时长或者基于联机更新指令向第一目标服务器发送插件和静态代码扫描规则，可以自动更新第一目标服务器的插件和静态代码扫描规则，可以降低第一服务器的管理人员和第一目标服务器的管理人员的沟通成本，避免手动安装插件和规则出现失误而导致的扫描问题的出现，可以提高第一目标服务器更新规则和插件的效率，减少第一目标服务器更新规则和插件的手动操作，更加灵活的实现插件和规则的同步管理。
112.作为一个可选的实施例，上述方法200还包括：第一目标服务器检测到用户的第一更新操作，第一更新操作用于更新第一目标服务器的静态代码扫描规则；第一目标服务器响应于第一更新操作，向第一服务器发送联机更新指令，联机更新指令携带第一目标服务器的url地址、规则集的名称、以及规则集对应的配置文件的路径。对应地，第一服务器接收到联机更新指令，根据规则集对应的配置文件的路径，获取配置文件中的规则信息，进而得到静态代码扫描规则，并基于联机更新指令向第一目标服务器发送静态代码扫描规则。
113.该用户即为第一目标服务器的管理员，第一目标服务器的管理员可以输入该第一目标服务器的url地址、规则集的名称、以及规则集对应的配置文件的路径(第二配置文件的路径)，然后可以点击更新按钮等控件(即第一更新操作)，第一目标服务器检测到第一目标服务器的管理员的第一更新操作，向第一服务器发送联机更新指令。第一服务器可以基于上述方法200向第一目标服务器发送静态代码扫描规则。
114.示例性地，第一服务器的管理员可以将上述方法200封装成可以供第三方调用的jar包，可以提供给第一目标服务器的管理员更新插件和静态代码扫描规则。第一目标服务器的管理员可以仅仅通过输入该第一目标服务器的url地址、规则集的名称、以及规则集对
应的配置文件的路径，然后可以点击更新按钮等控件即可实现第一目标服务器的插件和静态代码扫描规则的更新。
115.其中，第一服务器的管理员的调用方式可以为java-jar sonarapi.jar"http://www.sonarqubeserver1.com:19009"icbc_java_all_base"y:\资料与分享\sonar\sonar规则\java规则.xls"，第一目标服务器检测到该调用方式，自动更新插件和静态代码扫描规则。
116.本技术实施例提供的静态代码扫描规则的更新方法，第一目标服务器的管理员可以通过简单的手动操作(输入第一目标服务器的url地址、规则集的名称、以及规则集对应的配置文件的路径)按需更新插件和静态代码扫描规则，可以提高第一目标服务器更新插件和静态代码扫描规则的效率。
117.可选地，当第一服务器的管理员需要同时更新多个规则集时，第一服务器的管理员可以通过添加命令以组合不同的操作放到同一个bat文件中，第一目标服务器的管理员可以通过执行bat文件执行里面的操作。
118.示例性地，该bat文件的名称可以为runzhkf1.bat，该文件中的内容可以包括：
119.java-jar sonarapi.jar"http://www.sonarqubeserver1.com:19009"icbc_java_base"y:\资料与分享\sonar\sonar规则\java规则.xls"、java-jar sonarapi.jar"http://www.sonarqubeserver1.com:19009"icbc_xml_base"y:\资料与分享\sonar\sonar规则\xml规则.xls"、java-jar sonarapi.jar"http://www.sonarqubeserver1.com:19009"icbc_python_base"y:\资料与分享\sonar\sonar规则\python规则.xls"、java-jar sonarapi.jar"http://www.sonarqubeserver2.com:19008"icbc_java_base"y:\资料与分享\sonar\sonar规则\java规则.xls"、java-jar sonarapi.jar"http://www.sonarqubeserver1.com:19009"icbc_java_all_base"y:\资料与分享\sonar\sonar规则\java规则.xls"java-jar sonarapi.jar"http://www.sonarqubeserver2.com:19008"icbc_xml_base"y:\资料与分享\sonar\sonar规则\xml规则.xls"、java-jar sonarapi.jar"http://www.sonarqubeserver2.com:19008"icbc_python_base"y:\资料与分享\sonar\sonar规则\python规则.xls"。
120.作为一个可选的实施例，上述方法200还包括：第一服务器判断至少一个第二服务器中的第一目标服务器是否存在与多个插件中的第一插件名称相同的第二插件；在第一目标服务器存在第二插件的情况下，第一服务器判断第二插件的版本是否低于第一插件的版本；上述s203、第一服务器每隔第一时长或者基于联机更新指令向至少一个第二服务器中的全部或部分服务器发送多个插件中的至少一个插件和多个静态代码扫描规则中的至少一个静态代码扫描规则，包括：在第二插件的版本低于第一插件的版本的情况下，第一服务器向第一目标服务器发送第一插件。对应地，第一目标服务器接收第一插件，并将第二插件更新为第一插件。
121.第一服务器可以获取第一目标服务器已有的插件，并判断第一目标服务器已有的插件中是否存在与多个插件中的第一插件名称相同的第二插件。
122.第一服务器向第一目标服务器发送第一插件，例如，第一服务器可以通过文件传输协议(file transfer protocol，ftp)上传第一插件到第一目标服务器。
123.可选地，在第一目标服务器已有的插件中不存在与第一插件名称相同的第二插
件，第一目标服务器向第一目标服务器发送第一插件，对应地，第一目标服务器接收第一插件，并将第一插件添加到第一目标服务器已有的插件中。当第一目标服务器重启后，第一目标服务器已有的插件中包括第一插件。
124.可选地，在第二插件的版本不低于第一插件的版本(即第二插件的版本等于或高于第一插件的版本)的情况下，第一服务器不向第一目标服务器发送第一插件。
125.本技术实施例提供的静态代码扫描规则的更新方法，第一服务器可以先判断第一目标服务器中已有的插件中是否存在与第一插件名称相同的第二插件，再比较第一插件和第二插件的版本信息，最后决定是否要向第一目标服务器发送第一插件，可以避免第一目标服务器在存在第一插件的情况下，重复更新插件，可以提高第一目标服务器更新插件的效率。
126.作为一个可选的实施例，上述方法200还包括：第一服务器判断至少一个第二服务器中的第一目标服务器是否存在规则集；在第一目标服务器存在规则集的情况下，判断规则集中是否包括多个静态代码扫描规则；上述s203、第一服务器每隔第一时长或者基于联机更新指令向至少一个第二服务器中的全部或部分服务器发送多个插件中的至少一个插件和多个静态代码扫描规则中的至少一个静态代码扫描规则，包括：在规则集中不包括多个静态代码扫描规则中的第一静态代码扫描规则的情况下，第一服务器向第一目标服务器发送第一静态代码扫描规则。对应地，第一目标服务器接收第一静态代码扫描规则，并将第一静态代码扫描规则添加至规则集中。
127.在第一目标服务器存在规则集的情况下，第一服务器可以获取第一目标服务器已有的规则集，并判断规则集中是否包括多个静态代码扫描规则。
128.第一目标服务器已有的规则集中可以包括多个规则集，该多个规则集的个数可以是一个，也可以是两个及两个以上，本技术实施例对此不作限定。
129.在一种可能的实现方式中，第一目标服务器已有的规则集包括一个规则集，第一服务器可以判断该一个规则集中是否包括多个静态代码扫描规则。
130.在另一种可能的实现方式中，第一目标服务器已有的规则集包括三个规则集，第一服务器可以分别判断该三个规则集中是否包括多个静态代码扫描规则，或者，第一服务器判断该三个规则集中是否存在与第二配置文件名称相同的规则集，在存在与第二配置文件名称相同的规则集的情况下，第一服务器判断该与第二配置文件名称相同的规则集是否包括多个静态代码扫描规则。
131.在规则集中不包括多个静态代码扫描规则中的第一静态代码扫描规则的情况下，即第一目标服务器已有的规则集中不包括第一静态代码扫描规则，第一服务器向第一目标服务器发送第一静态代码扫描规则。
132.本技术实施例提供的静态代码扫描规则的更新方法，第一服务器可以先判断第一目标服务器中已有的规则集中是否存在第一静态代码扫描规则，在第一目标服务器中已有的规则集中不存在第一静态代码扫描规则的情况下，第一目标服务器将第一静态代码扫描规则添加到规则集，可以避免第一目标服务器在存在第一静态代码扫描规则的情况下，重复更新第一静态代码扫描规则，可以提高第一目标服务器更新静态代码扫描规则的效率。
133.可选地，在第一目标服务器不存在规则集的情况下，第一服务器可以在第一目标服务器中创建规则集。第一服务器向第一目标服务器发送多个静态代码扫描规则中的全部
静态代码扫描规则，对应地，第一目标服务器接收该全部的静态代码扫描规则，将该全部的静态代码扫描规则添加至该新创建的规则集中。
134.第一服务器创建的规则集的名称可以与第二配置文件的名称相同。示例性地，第一服务器可以根据第二配置文件的名称和代码的语言(例如java)调用接口在第一目标服务器中创建规则集。该调用接口可以为post api/qualityprofiles/create。
135.示例性地，调用接口代码可以通过如下代码实现：
136.private static void createruleset(string url,string rulesetname)throws ioexception{
137.string language＝rulesetname.substring(5,5+rulesetname.substring(5).indexof(
‘
_’))；
138.string createurl＝url+“/api/qualityprofiles/create？language＝”+“&name＝”+rulesetname；
139.sonarinterface.callsonarapi(createurl,sonarinterface.authtoken,params:
“”
)；
140.}
141.其中，language可以为java，参数rulesetname可以为icbc_java_base。
142.将全部的静态代码扫描规则添加至规则集中，有两种可能的实现方式。
143.在一种可能的实现方式中，第一目标服务器可以调用激活静态代码扫描规则的方法，分别将全部的静态代码扫描规则依次添加至规则集中。当静态代码扫描规则的规则状态为“挂起”，第一目标服务器则跳过这个静态代码扫描规则的规则。
144.在另一种可能的实现方式中，第一服务器可以从第二配置文件中循环获取每个规则的规则名称、规则等级和规则状态等信息，然后调用激活静态代码扫描规则的方法，分别将全部的静态代码扫描规则依次添加至规则集中，然后将该规则集发送到第一目标服务器。当静态代码扫描规则的规则状态为“挂起”，第一则跳过这个静态代码扫描规则的规则。
145.示例性地，第一服务器获取第一目标服务器的url地址，静态代码扫描规则的规则名称以及规则集名称等参数拼装成调用sonarqube接口post api/qualityprofiles/activate_rule的url，实现将静态代码扫描规则添加至规则集中，并设置该静态代码扫描规则的严重等级。
146.可选地，在规则集中包括多个静态代码扫描规则中的第一静态代码扫描规则的情况下，第一服务器可以不向第一目标服务器发送第一静态代码扫描规则。
147.作为一个可选的实施例，在上述第一服务器判断至少一个第二服务器中的第一目标服务器是否存在规则集之前，上述方法200还包括：第一服务器获取第一目标服务器的url地址和密码信息；第一服务器根据第一目标服务器的url地址和密码信息，获取第一目标服务器上已有的插件和静态代码扫描规则。
148.第一服务器根据第一目标服务器的url地址和密码信息，可以获取第一目标服务器上已有的插件和静态代码扫描规则，还可以在第一目标服务器上创建规则集，也可以向第一目标服务器发送第一插件和第一静态代码扫描规则。
149.示例性地，第一目标服务器的url地址和密码信息可以保存在数据库中，该数据库可以保存多个目标服务器的url地址和密码信息，第一服务器可以从该数据库中得到第一
目标服务器的url地址和密码信息。数据库可以保存在第一服务器或者其他服务器中，本技术实施例对该数据库保存的位置不做限定。
150.至少一个第二服务器中可以包括多个目标服务器，上述第一目标服务器属于该多个目标服务器，数据库中可以包括该多个目标服务器的url地址和密码信息。示例性地，数据库中包括3个目标服务器(分别为第一目标服务器、第二目标服务器和第三目标服务器)的url地址和密码信息，第一目标服务器的url地址为http://www.sonarqube1.com:19009和密码信息为passwordsonarpg29，第二目标服务器的url地址为http://www.sonarqube2.com:8080和密码信息为s0nar_bj，第三目标服务器的url地址为http://www.sonarqube3.com:19008和密码信息为passwordpostgres。
151.本技术实施例提供的静态代码扫描规则的更新方法，第一服务器可以获取第一目标服务器的url地址和密码信息，可以对第一目标服务器进行操作，可以较少第一目标服务器的管理人员的手动操作，且当目标服务器数量较多时，可以提高多个目标服务器更新插件和静态代码扫描规则的效率。
152.作为一个可选的实施例，在上述s204、第一目标服务器根据至少一个插件和至少一个静态代码扫描规则，对第一目标服务器中已有的插件和静态代码扫描规则进行更新之后，上述方法200还包括：第一目标服务器将更新失败的插件和静态代码扫描规则生成错误日志；第一目标服务器显示错误日志，以便第一目标服务器的管理员查看。
153.该错误日志中可以包括更新失败的插件和静态代码扫描规则的信息。
154.示例性地，该错误日志的名称为hz_kf1，该错误日志用于表示杭州一部的服务器存在两个规则没有更新成功，具体为icbc-java：checkconnections,major，icbc-java：checkprocessclose,major。第一目标服务器可以通过邮件的形式显示该错误日志。杭州一部的服务器的管理员可以通过该错误日志分析该两个规则更新失败的原因。
155.可选地，第一目标服务器可以向第一服务器发送该错误日志，第一服务器的管理员也通过该错误日志分析规则更新失败的原因。当多个目标服务器分别向第一服务器发送错误日志时，第一服务器的管理员可以进行汇总，结合多个错误日志统一分析规则更新失败的原因。
156.本技术实施例提供的静态代码扫描规则的更新方法，第一目标服务器可以显示错误日志，便于第一目标服务器的管理人员分析插件和静态代码扫描规则更新失败的原因，有利于第一目标服务器的管理人员了解更新插件和静态代码扫描规则的情况，还可以提高静态代码扫描规则的更新的质量。
157.综上所述，上述方法200中，第一服务器可以每隔第一时长(即定时)更新至少一个第二服务器中的全部服务器已有的插件和静态代码扫描规则，或者，第一服务器可以基于联机更新指令更新至少一个第二服务器中的部分服务器已有的插件和静态代码扫描规则，这里的部分服务器是指有更新需求的服务器，联机更新指令由其对应的管理员触发。因此，上述两种方法的区别可以通过表一进行说明。
158.表一
[0159][0160]
如表一所示，第一服务器定时更新第二服务器的插件和静态代码扫描规则的方法，是一种自动的实现方式，更新的频率为每隔第一时长更新，负责人是第一服务器的管理员，作用范围为全部第二服务器，执行的操作为更新全部第二服务器已有的插件和静态代码扫描规则，错误处理是生成错误日志。
[0161]
第一服务器基于联机更新指令更新第二服务器的插件和静态代码扫描规则的方法，是一种手动的实现方式，更新的频率为按需要更新，负责人是第一目标服务器的管理员，作用范围为第一目标服务器，执行的操作为更新第一目标服务器已有的插件和静态代码扫描规则，没有错误处理方式。
[0162]
由表一可知，第一服务器定时更新第二服务器的插件和静态代码扫描规则的方法，第一服务器可以自动的每隔第一时长更新全部第二服务器的插件和静态代码扫描规则，第一时长长度的确定可以由第一服务器的管理员设置。第一服务器基于联机更新指令更新第二服务器的插件和静态代码扫描规则的方法，第二服务器中的第一目标服务器的管理员可以手动按需要更新第一目标服务器已有的插件和静态代码扫描规则。
[0163]
上述方法200中，第一目标服务器更新插件是自动更新的，本技术实施例还提供一种第一目标服务器的管理员可以根据第一配置文件手动更新插件的方法。
[0164]
示例性地，第一配置文件存储在插件服务器中，第一目标服务器的管理员可以通过配置域名解析hosts文件得到插件服务器的url地址(例如www.pluginsserver.com)，然后根据该url地址从插件服务器中得到第一配置文件，第一配置文件的插件信息可以显示在第一目标服务器。第一目标服务器的管理员根据第一配置文件的插件信息中的分类说明(例如icbc)，搜索出插件，并通过“安装”或者“更新”按钮安装该插件。
[0165]
本技术实施例提供的静态代码扫描规则的更新方法，第一目标服务器的管理员可以通过第一配置文件的插件信息，手动添加插件，可以在第一目标服务器自动更新插件失败的情况下使用，可以增加静态代码扫描规则的更新方法的容错率，有利于保证插件更新的成功。
[0166]
上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。
[0167]
上文中结合图1和图2，详细描述了本技术实施例提供的静态代码扫描规则的更新方法，下面将结合图3和图4，详细描述本技术实施例提供的静态代码扫描规则的更新装置。
[0168]
图3示出了本技术实施例提供的一种静态代码扫描规则的更新装置300。该装置300包括：处理模块310和收发模块320。
[0169]
在一种可能的实现方式中，该装置300用于执行上述方法实施例中第一服务器对应的各个流程和步骤。
[0170]
该处理模块310用于：根据第一配置文件中的插件信息，获取与插件信息对应的多个插件；以及，根据第二配置文件中的规则信息，获取与规则信息对应的多个静态代码扫描规则；收发模块320用于：每隔第一时长或者基于联机更新指令向至少一个第二服务器中的全部或部分服务器发送多个插件中的至少一个插件和多个静态代码扫描规则中的至少一个静态代码扫描规则。
[0171]
可选地，上述处理模块310还用于：判断至少一个第二服务器中的第一目标服务器是否存在与多个插件中的第一插件名称相同的第二插件；在第一目标服务器存在第二插件的情况下，判断第二插件的版本是否低于第一插件的版本；上述收发模块320还用于：在第二插件的版本低于第一插件的版本的情况下，向第一目标服务器发送第一插件。
[0172]
可选地，上述处理模块310还用于：判断至少一个第二服务器中的第一目标服务器是否存在规则集；在第一目标服务器存在规则集的情况下，判断规则集中是否包括多个静态代码扫描规则；上述收发模块320还用于：在规则集中不包括多个静态代码扫描规则中的第一静态代码扫描规则的情况下，向第一目标服务器发送第一静态代码扫描规则。
[0173]
可选地，上述处理模块310还用于：获取第一目标服务器的统一资源定位器url地址和密码信息；根据第一目标服务器的url地址和密码信息，获取第一目标服务器上已有的插件和静态代码扫描规则。
[0174]
可选地，规则信息包括多个静态代码扫描规则中每个静态代码扫描规则的规则标识、规则等级以及规则状态。
[0175]
在另一种可能的实现方式中，该装置300用于执行上述方法实施例中第一目标服务器对应的各个流程和步骤。
[0176]
该收发模块320用于：每隔第一时长或者基于联机更新指令接收来自第一服务器的至少一个插件和至少一个静态代码扫描规则；处理模块310用于：根据至少一个插件和至少一个静态代码扫描规则，对该装置已有的插件和静态代码扫描规则进行更新；在更新完成后进行重启。
[0177]
可选地，上述处理模块310还用于：检测到用户的第一更新操作，第一更新操作用于更新上述装置的静态代码扫描规则；上述收发模块310还用于：响应于第一更新操作，向第一服务器发送联机更新指令，联机更新指令携带上述装置的url地址、规则集的名称、以及规则集对应的配置文件的路径。
[0178]
可选地，上述处理模块310还用于：将更新失败的插件和静态代码扫描规则生成错误日志；上述装置300还包括显示模块，该显示模块用于显示错误日志，以便上述装置的管理员查看。
[0179]
应理解，这里的装置300以功能模块的形式体现。这里的术语“模块”可以指应用特有集成电路(application specific integrated circuit，asic)、电子电路、用于执行一个或多个软件或固件程序的处理器(例如共享处理器、专有处理器或组处理器等)和存储器、合并逻辑电路和/或其它支持所描述的功能的合适组件。在一个可选例子中，本领域技
术人员可以理解，该装置300可以具体为上述实施例中的第一服务器或者第一目标服务器，或者，上述实施例中第一服务器或者第一目标服务器的功能可以集成在该装置中，该装置300可以用于执行上述方法实施例中与第一服务器或者第一目标服务器对应的各个流程和/或步骤，为避免重复，在此不再赘述。
[0180]
上述装置300具有实现上述方法200中第一服务器或者第一目标服务器执行的相应步骤的功能；上述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
[0181]
图4示出了本技术实施例提供的另一种静态代码扫描规则的更新装置400。该装置400包括：处理器410、收发器420和存储器430。其中，处理器410、收发器420和存储器430通过内部连接通路互相通信，该存储器430用于存储指令，该处理器410用于执行该存储器430存储的指令，以控制该收发器420发送信号和/或接收信号。
[0182]
上述装置400用于执行上述方法200中的各个流程和步骤。在一种可能的实现方式中，该处理器410用于：根据第一配置文件中的插件信息，获取与插件信息对应的多个插件；根据第二配置文件中的规则信息，获取与规则信息对应的多个静态代码扫描规则；每隔第一时长或者基于联机更新指令向至少一个第二服务器中的全部或部分服务器发送多个插件中的至少一个插件和多个静态代码扫描规则中的至少一个静态代码扫描规则。
[0183]
在另一种可能的实现方式中，该处理器410用于：每隔第一时长或者基于联机更新指令接收来自第一服务器的至少一个插件和至少一个静态代码扫描规则；根据至少一个插件和至少一个静态代码扫描规则，对装置400中已有的插件和静态代码扫描规则进行更新；在更新完成后进行重启。
[0184]
应理解，该装置400可以用于执行上述方法实施例中与第一服务器或者第一目标服务器对应的各个步骤和/或流程。可选地，该存储器430可以包括只读存储器和随机存取存储器，并向处理器410提供指令和数据。存储器430的一部分还可以包括非易失性随机存取存储器。例如，存储器430还可以存储设备类型的信息。该处理器410可以用于执行存储器430中存储的指令，并且当该处理器410执行存储器430中存储的指令时，该处理器410用于执行上述与该第一服务器或者第一目标服务器对应的方法实施例的各个步骤和/或流程。
[0185]
应理解，在本技术实施例中，上述装置400的处理器410可以是中央处理单元(central processing unit，cpu)，该处理器410还可以是其他通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现场可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
[0186]
在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本技术实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件单元组合执行完成。软件单元可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器执行存储器中的指令，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。
[0187]
本技术提供一种可读计算机存储介质，该可读计算机存储介质用于存储计算机程序，该计算机程序用于实现上述实施例中第一服务器或者第一目标服务器对应的方法。
[0188]
本技术提供了一种计算机程序产品，该计算机程序产品包括计算机程序(也可以称为代码，或指令)，当该计算机程序在计算机上运行时，该计算机可以执行上述实施例中第一服务器或者第一目标服务器对应的方法。
[0189]
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
[0190]
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0191]
在本技术所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0192]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0193]
另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
[0194]
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
[0195]
以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。