即该平台是否需要进行重启)；例如在具体的场景中，该重启标志位可以具体为0和1两个数值，在初始状态时，可以设置重启标志位为0时，即表示平台处于无需重启状态；而当系统发生改变，需要重启，则可以设置重启标志位为1，表示平台处于待重启状态，在此情况下重启标志位的状态从无需重启状态变成待重启状态，就可以通过将重启标志位从ο变为1来实现，当然还有很多别的方式也是可以实现的(例如可以设置初始状态时，重启标志位为1)，并不限于这一种方式，只要能区别两种重启标志位的状态就都可以。
[0064]具体的，重启设备识别重启标志位的状态，可以有以下两种方式:
[0065]方式一，所述重启设备可以通过所述非应用级别进程周期性检测所述重启标志位的状态来识别所述重启标志位的状态。
[0066]具体的，平台上搭载的应用，都是通过应用级别的进程来实现的，而本申请中所涉及的非应用级别进程则是与应用级别进程不一样的进程，即非应用级别进程是与应用级别进程相互独立，也即与平台独立，不会受到平台的影响，因而通过该非应用级别进程进行检测的过程与平台无关，不受平台重启进程的影响，不会因为平台重启导致检测中断。
[0067]方式二，所述重启设备可以根据接收到包含所述重启标志位的状态信息来识别所述重启标志位的状态。
[0068]当然具体的识别过程还可以有很多别的方式，只要使得重启设备能确定当前重启标志位的状态即可，并不限于上述两种方式。
[0069]其次，在识别完成之后，当识别结果为待重启状态时，则确定所述平台需要进行重启；当识别结果为无需重启状态时，则确定所述平台不需要进行重启。
[0070]步骤102，当所述判断结果为所述平台需要进行重启时，所述重启设备通过非应用级别进程重启所述平台以发布系统修改部分对应的功能；其中，所述非应用级别进程独立于所述平台运行。
[0071]具体的，本申请中所涉及的非应用级别进程则是与应用级别进程不一样的进程，即非应用级别进程是与应用级别进程相互独立，不会受到平台的重启进程的影响，重启设备通过该非应用级别进程触发执行平台的重启也不会受到平台重启的影响，由于该非应用级别进程独立于所述平台运行，不会受平台应用的重启影响，所以重启设备通过非应用级别进程执行重启脚本的过程不会中断，因而能顺利完成重启的过程；其中，该非应用级别进程可以为系统级别的进程，但并不仅限于系统级别的进程，还可以为其他进程，只要能不受平台应用的重启影响就都可以。
[0072]本申请实施例一中通过重启设备判断平台是否需要重启；当所述判断结果为是时，重启设备通过独立于所述平台运行的非应用级别进程重启所述平台以发布系统修改部分对应的功能，实现整个重启操作的自动化，使得整个过程无需后台维护人员的介入，同时能及时将系统修改部分对应的特性或者功能提供给平台用户，提升了平台可用率。
[0073]以上是基于重启设备侧对本申请做的说明，现基于平台侧对本申请做进一步的说明，如图2所示，本申请实施例二中还提出了一种功能发布方法，包括以下步骤:
[0074]步骤201,平台初始设置重启标志位为无需重启状态；
[0075]步骤202,当所述平台需要重启时,更改所述重启标志位为待重启状态，以使重启设备通过非应用级别进程对所述平台进行重启来发布系统修改部分对应的功能；其中，所述非应用级别进程独立于所述平台运行的进程。
[0076]具体的，在步骤202(也即当所述平台需要重启时，更改所述重启标志位为待重启状态)之后，还可以包括:
[0077]所述平台将包含所述重启标志位的状态的信息发送给所述重启设备。
[0078]这样，由于平台将包含所述重启标志位的状态的信息发送给所述重启设备，所述重启设备可以了解到当前的重启标志位的状态信息，从而进行后续判断，确定是否需要重启平台。
[0079]其中，在具体的场景下，当更改所述重启标志位为待重启状态是基于确定指定位置存在重启脚本时，在更改所述重启标志位为待重启状态之后，还可以包括:所述平台将包含指定位置存在重启脚本的信息发送给所述重启设备。
[0080]另外，具体的，在完成重启所述平台之后，还可以包括:所述平台重置所述重启标志位为无需重启状态。
[0081 ] 这样，由于是否重启是基于该重启标志位的状态来进行判断的，当平台重启之后，若该重启标志位的状态没有发生变化，会导致陷入重启死循环的状态，在这种情况下，可以将该重启标志位设置为无需重启状态，可以是由平台来执行的，当然也可以是否别的第三方设备，或者程序等来执行，只要能使得重启之后，该重启标志位的状态被设置为无需重启状态即可。
[0082]其中，在具体的场景下，当更改所述重启标志位为待重启状态是基于确定指定位置存在重启脚本时，所述重置所述重启标志位为所述无需重启状态，还可以包括:所述平台删除所述重启脚本。
[0083]这种情况下，因为当指定位置存在重启脚本时，重启标志位的状态会被设置为待重启状态，若将其删除，重启标志位就会被设置为无需重启状态，自然也是可以避免系统陷入重启死循环的，同样的，可以是平台来删除该重启脚本，也可以是由别的第三方设备，或者程序等来删除，只要能删除该重启脚本即可。
[0084]本申请实施例二中，平台首选设置重启标志位为无需重启状态，当平台需要重启时，可以更改重启标志位的状态为待重启状态，从而使得重启设备独立于所述平台运行的非应用级别进程重启所述平台以发布系统修改部分对应的功能，实现整个重启操作的自动化，使得整个过程无需后台维护人员的介入，同时能及时将系统修改部分对应的特性或者功能提供给平台用户，提升了平台可用率。
[0085]以下结合具体的应用场景对本发明实施例进行详细说明，如图3所示，本发明实施例三中提出了在具体应用场景下的功能发布方法。
[0086]其中，以mockservice平台(即一个统一 mock服务平台，当用户有新的接口 mock需求时，会在前台进行操作添加配置，应用需要重启后才能将新的mock接口发布出来提供mock服务)为例。
[0087]当用户在前台变更了平台mock配置文件后，会自动触发执行重启触发通用模块，具体的:该重启触发通用模块执行设置重启标志位的动作，具体的会复制用于重启平台的shell脚本到cron job指定的目录；这样，当cron tab异步定时任务进程检测到指定目录的重启脚本存在后便会直接执行来达到重启平台/系统的目的
[0088]当确定指定目录下存在该重启脚本时，linux系统会通过系统级别的进程执行该重启脚本(该系统级别进程不会受平台应用的重启影响，所以不会中断)。如果不存在该脚本，则直接跳过，等待下次定时任务再判断；如此循环，具体定时任务的频率可以根据需求随意设置，其中，该定时任务利用的是linux服务器的crontab命令(crontab命令常见于Unix和类Unix的操作系统之中，用于设置周期性被执行的指令；该命令从标准输入设备读取指令，并将其存放于crontab文件中，以供之后读取和执行)。通常，crontab储存的指令被守护进程激活，其常常在后台运行，每一分钟检查是否有预定的作业需要执行，这类作业一般称为cron jobs ο
[0089]在进行重启平台之后，还需要一个initReboot模块(是平台/系统的一个启动初始化功能模块)，该initReboot模块会在重启过程中重置重启脚本，防止下次cron定时任务再次将系统重启，导致陷入重启死循环。该initReboot模块的实现方式有很多种，以mockservice平台为例，其实现方式是，利用系统启动过程中的初始化方法，增加功能代码删除指定位置的重启脚本；当然其他的实现方式也可以实现，比如在执行重启后，再增加一段删除重启脚本的逻辑。
[0090]本申请实施例三中，变更了平台mock配置文件之后，会自动触发通用模块复制用于重启平台的shell脚本到cron job指定的目录，以此定时任务会按照设定的频率来检测是否指定的目录下存在用于重启平台的shell脚本，若有则通过系统级别的进程执行该用于重启平台的shell脚本；在执行完重启后，会有initReboot模块将该用于重启平台的shell脚本删除，以避免系统陷入重启死循环。以此通过上述步骤，实现了重启操作的自动化，整个过程无需后台维护人员的介入，这样能及时将系统修改部分对应的特性或者功能提供给平台用户，提升了平台可用率。
[0091]如图4所示，本发明实施例四还提出了一种重启设备，包括:
[0092]判断模块401，用于判断平台是否需要重启；
[0093]重启模块402，用于当所述判断结果为是时，通过非应用级别进程重启所述平台，以发布系统修改部分对应的功能；其中，所述非应用级别进程独立于所述平台运行的进程。
[0094]其中，如图5所示，判断模块402，还可以包括:
[0095]识别模块4021，用于识别重启标志位的状态；
[0096]确定模块4022，用于当识别结果为待重启状态时，确定所述平台需要进行重启；当识别结果为无需重启状态时，