CN116743574A - 服务器运维方法、系统、电子设备及存储介质 - Google Patents

Abstract

本申请提供一种服务器运维方法、系统、电子设备及存储介质，服务器运维方法应用于服务器运维系统，系统包括一个服务端和多个客户端，每个客户端安装于待运维的相应服务器中，方法包括：服务端接收运维信息，运维信息包括待运维服务器和待运维内容；服务端解析运维信息，将待运维内容发送至待运维服务器；待运维服务器中的客户端根据待运维内容对待运维服务器进行运维操作。这样，运维人员在需要对多台服务器进行运维的情况下，只需向服务器运维系统的服务端中输入包含待运维服务器和待运维内容的运维信息，服务器运维系统即可自动实现相应服务器的运维工作，减少了运维人员的运维工作量，降低运维成本。

Description

服务器运维方法、系统、电子设备及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种服务器运维方法、系统、电子设备及存储介质。

背景技术

随着互联网的不断发展，互联网企业的业务也在不断扩大，企业为实现业务所使用的服务器的数量也在不断增加。作为企业对外提供业务的载体“应用”，为了确保应用的稳定性，会将应用在服务器集群中进行部署，也就是将同一应用部署于多个不同的服务器。

目前，将应用部署于服务器集群，或者在服务器集群中对应用进行升级等维护，主要都是通过人工的方式进行。具体来说，当需要在服务器集群中部署某一应用时，运维人员先使用文件同步工具或者通过scp的方式将应用的安装包上传到指定服务器，然后再登录该服务器，运行安装包，实现应用在指定服务器中的部署。当需要在服务器集群中升级某一应用时，运维人员先登录指定服务器，然后将升级文件拷贝到该服务器中的指定目录，最后执行启动脚本，实现应用在指定服务器中的升级。

但是，如果应用部署或升级牵涉的服务器的数量较多，运维人员针对每一个服务器都需要执行一次上述操作，这样会使运维人员进行大量重复的工作，增加服务器的运维成本。并且，对服务器进行应用部署以及升级的操作，每一步都需要运维人员亲自执行，还可能存在将应用部署在错误的服务器上，或者在错误的服务器上进行应用升级，影响服务器的正常运行。

发明内容

本申请实施例的目的是提供一种服务器运维方法、系统、电子设备及存储介质，以降低服务器的运维成本，并保障服务器的正常运行。

为解决上述技术问题，本申请实施例提供如下技术方案：

本申请第一方面提供一种服务器运维方法，所述方法应用于服务器运维系统，所述服务器运维系统包括一个服务端和多个客户端，每个客户端安装于待运维的相应服务器中，所述方法包括：服务端接收运维信息，所述运维信息包括待运维服务器和待运维内容；服务端解析所述运维信息，将所述待运维内容发送至所述待运维服务器；所述待运维服务器中的客户端根据所述待运维内容对所述待运维服务器进行运维操作。

本申请第二方面提供一种服务器运维系统，所述系统包括一个服务端和多个客户端，每个客户端安装于待运维的相应服务器中，服务端，用于接收运维信息，所述运维信息包括待运维服务器和待运维内容；服务端，还用于解析所述运维信息，将所述待运维内容发送至所述待运维服务器；所述待运维服务器中的客户端，用于根据所述待运维内容对所述待运维服务器进行运维操作。

本申请第三方面提供一种电子设备，所述电子设备包括：处理器、存储器、总线；其中，所述处理器、所述存储器通过所述总线完成相互间的通信；所述处理器用于调用所述存储器中的程序指令，以执行第一方面中的方法。

本申请第四方面提供一种计算机可读存储介质，所述存储介质包括：存储的程序；其中，在所述程序运行时控制所述存储介质所在设备执行第一方面中的方法。

相较于现有技术，本申请第一方面提供的服务器运维方法、系统、电子设备及存储介质，通过运行服务器运维系统，运维人员可以通过系统中的服务端输入包括待运维服务器和待运维内容的运维信息，服务端解析运维信息，将待运维内容发送至待运维服务器，使得待运维服务器中的客户端根据待运维内容对待运维服务器自动进行运维操作。这样，运维人员在需要对多台服务器进行运维的情况下，只需向服务器运维系统的服务端中输入包含待运维服务器和待运维内容的运维信息，服务器运维系统即可自动实现相应服务器的运维工作，减少了运维人员的运维工作量，降低运维成本。并且，由于服务器运维系统减少了运维人员的运维工作量，因此能够降低运维人员在运维工作中出错的概率，在一定程度上保证了待运维服务器的正常运行。

本申请第二方面提供的服务器运维装置、第三方面提供的电子设备、第四方面提供的计算机可读存储介质，与第一方面提供的服务器运维方法具有相同或相似的有益效果。

附图说明

通过参考附图阅读下文的详细描述，本申请示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本申请的若干实施方式，相同或对应的标号表示相同或对应的部分，其中：

图1为本申请实施例中服务器运维方法的架构示意图；

图2为本申请实施例中服务器运维方法的流程示意图；

图3为本申请实施例中服务器运维方法的完整过程示意图；

图4为本申请实施例中服务器运维系统的结构示意图；

图5为本申请实施例中电子设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本申请的示例性实施方式。虽然附图中显示了本申请的示例性实施方式，然而应当理解，可以以各种形式实现本申请而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了能够更透彻地理解本申请，并且能够将本申请的范围完整的传达给本领域的技术人员。

需要注意的是，除非另有说明，本申请使用的技术术语或者科学术语应当为本申请所属领域技术人员所理解的通常意义。

在将同一应用部署于多台服务器，或者在多台服务器中升级同一应用的场景中，目前都是通过人工的方式，将安装包分别上传至每个服务器，并在每个服务器中进行应用部署，以及将升级文件分别拷贝到每个服务器，并在每个服务器中进行应用升级。而如果应用部署或升级的服务器的数量较多，那么运维人员就会进行大量重复的工作，导致服务器的运营成本增加。并且人工在服务器中进行应用的部署或升级中，几乎每一步都需要参与，出错的可能性就大大增加，进而影响服务器的正常运行。

发明人经过研究发现，如果设计一个服务器运维系统，后续应用在服务器中的部署或升级都通过该系统执行，那么，就能够减少人工运维的工作量，降低运维成本。并且，由于减少了人工运维的工作量，还能够降低运维出错的概率，极大程度的确保了服务器的正常运行。

有鉴于此，本申请实施例提供了一种服务器运维方法、系统、电子设备及存储介质，通过运行服务器运维系统，运维人员可以通过系统中的服务端输入包括待运维服务器和待运维内容的运维信息，服务端解析运维信息，将待运维内容发送至待运维服务器，使得待运维服务器中的客户端根据待运维内容对待运维服务器自动进行运维操作。这样，运维人员在需要对多台服务器进行运维的情况下，只需向服务器运维系统的服务端中输入包含待运维服务器和待运维内容的运维信息，服务器运维系统即可自动实现相应服务器的运维工作，减少了运维人员的运维工作量，降低运维成本。并且，由于服务器运维系统减少了运维人员的运维工作量，因此能够降低运维人员在运维工作中出错的概率，在一定程度上保证了待运维服务器的正常运行。

首先，对本申请实施例提供的服务器运维方法所处的架构进行说明。

图1为本申请实施例中服务器运维方法的架构示意图，参见图1所示，在服务器运维系统中，包括一个服务端和多个客户端。其中，服务端用于接收运维人员输入的运维信息。运维信息至少包括待运维服务器和待运维内容。客户端可以是多个，每个客户端分别安装于一个待运维的服务器中。有多少个待运维的服务器，就有多少个客户端。

运维人员在服务端中输入运维信息后，服务端就会解析运维信息，获得其中的待运维服务器和待运维内容，并将待运维内容发送给相应的客户端，客户端根据待运维内容对待运维服务器进行运维操作。这样，即便有多台服务器需要运维，运维人员只需在系统的服务端中一次数据待运维服务器和待运维内容，系统即可基于待运维内容对这些待运维服务器进行运维操作，节省运维人员的人力，减少出错概率。

接下来，对本申请实施例提供的服务器运维方法进行详细说明。

图2为本申请实施例中服务器运维方法的流程示意图，参见图2所示，该方法可以包括：

S201：服务端接收运维信息。

其中，运维信息包括待运维服务器和待运维内容。

当运维人员需要对服务器进行运维，尤其是运维多台服务器时，运维人员可以通过服务器运维系统的服务端输入运维信息。在运维信息中，可以包括待运维的服务器的信息以及在相应服务器上需要进行运维的具体内容。例如：在运维信息中，包括对服务器A、服务器B和服务器C将应用a升级至版本1.2。服务器A、服务器B和服务器C就是此次待运维的三个服务器，将应用a升级至版本1.2就是此次待运维的具体内容。

S202：服务端解析运维信息，将待运维内容发送至待运维服务器。

系统的服务端接收到运维信息后，就需要从运维信息中获知需要对哪一个或哪几个服务器进行云心，并且对每一个服务器进行什么样的运维。即，解析运维信息，获得待运维服务器和待运维内容。

服务端获知待运维服务器和待运维内容后，就可以将待运维内容发送给待运维服务器。如果待运维服务器为多个，待运维内容为一项，也就是对多个服务器进行同一运维操作，那么服务端就可以将该待运维内容发送给每一个待运维服务器。如果待运维服务器为多个，待运维内容为多项，也就是对多个服务器进行不同的运维操作，那么服务端需要将相应的待运维内容发送给对应的待运维服务器。如果待运维服务器为一个，待运维内容无论是多项还是一项，服务端将待运维内容全部发送给该服务器即可。

在服务端向待运维服务器发送待运维内容的过程中，可以是服务端直接将待运维内容发送到待运维服务器中，也可以是服务端将待运维内容发送到指定位置处，待运维服务器中的安装的系统客户端从该位置处获取待运维内容，从而实现待运维内容到达待运维服务器。对于待运维内容具体的传输方式，此处不做限定。

S203：待运维服务器中的客户端根据待运维内容对待运维服务器进行运维操作。

待运维服务器得到待运维内容后，待运维服务器中安装的系统客户端就能够基于待运维内容自动启动对待运维服务器的运维操作。

在客户端对服务器进行运维操作的过程中，系统中可以预先设置有各种运维内容对应的运维程序，系统客户端可以根据待运维内容调用对应的运维程序，并启动调用的运维程序。运维程序启动后，就能够实现待运维服务器基于待运维内容的自动运维操作。当然，还可以在待运维内容中携带相应的运维程序，从而使该运维程序在待运维服务器中启动，实现待运维服务器基于待运维内容的自动运维操作。具体的自动运维方式，此处不做限定。

由上述内容可知，本申请实施例提供的服务器运维方法、系统、电子设备及存储介质，通过运行服务器运维系统，运维人员可以通过系统中的服务端输入包括待运维服务器和待运维内容的运维信息，服务端解析运维信息，将待运维内容发送至待运维服务器，使得待运维服务器中的客户端根据待运维内容对待运维服务器自动进行运维操作。这样，运维人员在需要对多台服务器进行运维的情况下，只需向服务器运维系统的服务端中输入包含待运维服务器和待运维内容的运维信息，服务器运维系统即可自动实现相应服务器的运维工作，减少了运维人员的运维工作量，降低运维成本。并且，由于服务器运维系统减少了运维人员的运维工作量，因此能够降低运维人员在运维工作中出错的概率，在一定程度上保证了待运维服务器的正常运行。

进一步地，作为对上述步骤S202的细化，服务端将待运维内容发送给待运维服务器的过程中，服务端可以不直接将待运维内容发送给待运维服务器，可以将待运维内容上传至系统中的某一位置，然后等待运维服务器的客户端主动从该位置获取，这样能够在待传输内容在传输的过程中出现问题时，容易找出问题点，从而快速解决。

具体来说，每个客户端对应有一个任务频道，任务频道用于存储服务端发送的待运维内容。

在服务器运维系统中，预设有多个频道。每个客户端与系统中的一个频道对应。例如：客户端a对应频道1，客户端b对应频道2等。每个频道接收并存储的是系统服务端为其对应的服务器发送的待运维内容。

上述步骤S202可以包括：

步骤A1：服务端获取运维信息中的待运维服务器。

系统服务端接收到运维人员输入的运维信息后，需要从运维信息中解析出待运维服务器和待运维内容。解析出待运维服务器，是为了确定要将待运维内容发送给哪一个服务器。

步骤A2：服务端确定待运维服务器中安装的客户端对应的任务频道。

客户端安装在各个待运维服务器中，每个待运维服务器中的客户端都对应有一个任务频道。服务端在确定了需要将待运维内容发送给哪个待运维服务器后，就需要确定出该待运维服务器的客户端对应的任务频道，以便将待运维内容发送至该任务频道。

在确定任务频道的过程中，可以通过在预设的对应关系表中查询待运维服务器对应的任务频道。在预设的对应关系表中，存储有各个服务器-安装的客户端-任务频道的对应关系。服务端通过预设的对应关系表，先查找出待运维服务器，待运维服务器对应的客户端对应的任务频道，就是本次需要将待运维内容发送到的任务频道。

步骤A3：服务端将待运维内容发送至对应的任务频道。

在确定了待运维内容发送的任务频道后，就可以将待运维内容直接发送至该任务频道。

步骤A4：待运维服务器对应的客户端从其对应的任务频道中获取待运维内容。

由于该任务频道是与待运维处理器的客户端对应的，因此只有待运维处理器的客户端会从该任务频道中获取待运维内容，实现待运维服务器获得待运维内容，从而实现待运维服务器基于待运维内容的自动化运维。

举例来说，假设系统中存在频道1、频道2和频道3。频道1对应服务器a中安装的客户端，频道2对应服务器b中安装的客户端，频道3对应服务器c中安装的客户端。系统服务端接收到的运维信息为“在服务器a和服务器b中部署应用A”。那么，服务端就会将待运维内容“部署应用A”分别发送至频道1和频道2。

由上述内容可知，服务端通过将待运维内容发送给待运维服务器的客户端对应的任务频道，使得待运维服务器的客户端从该任务频道中主动获取待运维内容，一旦待运维内容在传输过程中出现问题，能够更加方便快捷的确定出是服务端还是客户端出现问题，提高问题的查找效率，快速解决问题，提高服务器的运维效率。

进一步地，作为对上述步骤S203的细化，客户端在服务器中进行自动化运维，可以通过调用并执行相应的脚本，即通过运行脚本实现自动化运维。

具体来说，上述步骤S203可以包括：

步骤B1：待运维服务器中的客户端基于待运维内容调用相应的脚本对待运维服务器进行运维操作。

不同的运维内容对应有不同的脚本，例如：部署应用a对应有脚本1，升级应用b对应有脚本2等等。待运维服务器中的客户端获取到待运维内容之后，就可以根据待运维内容调用其对应的脚本通过该脚本的运行，实现待运维服务器对于待运维内容的自动化运维。

由上述内容可知，通过待运维服务器中的客户端调用并运行待运维内容对应的脚本，使得待运维服务器在没有运维人员参与的情况下，能够实现自动化运维，降低由于人工操作出现运维失误的概率，在一定程度上保障了待运维服务器的正常顺利运行。

进一步地，作为对上述步骤B1的扩展，在待运维内容中，如果还携带有运维过程中需要使用到的文件，那么待运维内容的数据量就会比较大，传输会比较耗时。并且，还存在文件内容丢失的风险。因此，可以仅在待传输内容中携带待运维的任务信息，而实际需要使用的各种运维文件都可以事先存储在系统中的某一位置，在需要时可以直接下载使用。

具体来说，服务器运维系统还包括存储端，存储端用于存储服务端接收到的运维文件。也就是说，运维人员可以将本次运维服务器需要使用到的运维文件直接存入存储端，或者运维人员事先将各种运维情况下需要使用的运维文件都存入存储端。

待运维内容包括运维任务名称。也就是说，在待运维内容中，仅写明需要进行什么样的运维任务即可。例如：部署应用a、升级应用b的版本至2.0等。

在上述步骤B1之前，该方法还可以包括：

步骤B01：待运维服务器中的客户端根据待运维内容中的运维任务名称判断是否需要从存储端中获取运维文件。若是，则执行步骤B02，若否，则执行步骤B1。

在一些运维内容中，可能是不需要依靠运维文件就能够完成服务器的运维。例如：清理服务器中存储时间超出预设时间的文件、修改服务器配置中的某一个参数等。而在一些运维内容中，就是需要依靠运维文件才能够完成服务器的运维。例如：在服务器中部署应用a，那么就需要“应用a的安装包”这一运维文件。再例如：在服务器中升级应用b，那么就需要“应用b的升级配置文件”这一运维文件。

客户端在获得待运维内容后，可以根据待运维内容中的运维任务名称判断出本次运维过程是否需要运维文件。具体的，可以事先罗列出各种运维任务名称，然后标记出每个运维任务名称下是否需要运维文件。然后，客户端就可以从事先罗列出的内容中找到待运维内容中的运维任务名称，进而根据其标记确定是否需要运维文件。

步骤B02：从存储端中获取运维任务名称对应的运维文件。

在系统的存储端，存储有各种运维任务名称对应的运维文件。需要这些运维文件中，查找出待运维内容中的运维任务名称对应的运维文件。具体的，可以将待运维内容中的运维任务名称与存储端中的各种运维任务名称进行关键字匹配，当与存储端中的某一个运维任务名称的匹配率达到预设率时，该运维任务名称对应的运维文件就是需要查找的运维文件。

步骤B1：待运维服务器中的客户端根据待运维内容调用相应的脚本对待运维服务器进行运维操作。

在步骤B02之后，步骤B1就可以为：待运维服务器中的客户端调用运维任务名称对应的脚本运行从存储端中获取的运维文件。

由于脚本此时仅仅是程序运行的逻辑，因此，客户端从存储端获取到运维任务名称对应的运维文件后，就调用运维任务名称对应的脚本运行该运维文件。该运维文件运行完成后，待运维服务器就完成了待运维内容的运维工作。

由上述内容可知，通过将运维文件存入系统存储端，当客户端基于待运维内容需要对待运维服务器进行运维时，再从存储端获取相应的运维文件，从使用相应的脚本运行该运维文件，能够减小待运维内容中的数据量，避免运维文件从服务端中反复传输，加快待运维内容的传输速度，提高服务器运维效率。

进一步地，作为对上述步骤S203的扩展，客户端还可以将对服务器进行运维的详细过程和结果存储起来，以便于运维人员查看。

具体来说，运维服务系统还包括一个监听频道，用来存储各个服务器的具体运维过程以及运维结果。

在上述步骤S203之后，该方法还可以包括：

步骤C1：待运维服务器中的客户端监听运维操作的日志和状态。

待运维服务器中的客户端在对待运维服务器进行运维操作的过程中，待运维服务器的运行日志中会记录有本次运维操作的具体内容。此时，客户端可以从运行日志中获取当前运维操作的日志和状态(此时状态为运维中)。待运维服务器中的客户端在对待运维服务器进行完运维操作之后，该客户端获取的运维操作的日志就是本次运维操作的全部内容，并且此时的状态为运维完成。

步骤C2：待运维服务器中的客户端将日志和状态发送至监听频道。

无论是客户端还在对待运维服务器进行运维中，还是运维完成，客户端都可以将监听到的运维日志和状态发送到系统的监听频道。

客户端可以是每间隔一段时间就发送一次日志和状态，也可以是运维人员在监听频道中输入监听指令后，客户端基于监听指令再发送日志和状态。对于客户端发送运维日志和状态的具体时机，此处不做限定。

步骤C3：服务端从监听频道中获取日志和状态。

监听频道接收到待运维服务器运维时的日志和状态后，先将日志和状态存储。运维人员需要查看待运维服务器当前的运维情况时，运维人员会通过服务端输入查看指令，该指令会发送到监听频道。监听频道会根据查看指令，将待运维服务器当前运维过程中的日志和状态发送给服务端。

步骤C4：服务端存储并展示日志和状态。

服务端获得待运维服务器当前运维过程中的日志和状态后，可以将日志和状态存储，以便后续运维人员直接调用查看。与此同时，还可以通过服务端中的控制台，显示待运维服务器当前运维过程中的日志和状态，以便此时运维人员直接查看当前待运维服务器中的实时运维情况。

由上述内容可知，客户端通过对待运维服务器运维过程中的日志和状态进行监听，并将监听到的日志和状态存储于系统的监听频道，以便于系统服务端从监听频道获取并展示待运维服务器当前的运维情况，便于运维人员实时观察，实现了服务器运维过程的可视化展示。

进一步地，作为对上述步骤S201的扩展，在通过系统对服务器进行自动运维时，需要确保系统中的各节点，尤其是客户端能够正常工作。

具体来说，在上述步骤S201之前，该方法可以包括：

步骤D1：每个客户端定时获取并向服务端上报其所在服务器的服务器信息和应用信息。

运维人员所管理的服务器中，每一个服务器上都安装有一个系统的客户端。这些客户端需要定时获取，并向服务端上报其所在服务器的服务器信息和应用信息。

这里的定时，可以是每隔一段时间，例如：间隔10分钟、1小时等，也可以是一个固定时间，例如：每个整点时间、每天0点等。对于定时，此处不做具体限定。

这里的服务器信息，可以是指服务器的内存、中央处理器(Central ProcessingUnit，CPU)、硬盘等存量，也可以是指服务器的名称、型号、在企业中的用途、重要性等。这里的应用信息，可以是服务器中安装的所有应用的名称、版本号等。对于服务器信息和应用信息的具体内容，此处不做限定。

步骤D2：服务端获取每个客户端最近一次上报服务器信息和应用信息的时间。

服务端会定时获得每个客户端上报的服务器信息和应用信息，在一次获得客户端上报的服务器信息和应用信息后，服务端针对每一个客户端，会确认其最近一次上报服务器信息和应用信息的时间。

步骤D3：服务端根据每个客户端最近一次上报的时间与当前时间计算每个客户端的更新时间。

服务端获得每个客户端最近一次上报服务器信息和应用信息的时间后，会将当前时间分别与每个客户端的时间相减，得到每个客户端向服务端更新服务器信息和应用信息的更新时间。

步骤D4：服务端判断每个客户端的更新时间是否超出更新阈值。若是，则执行步骤D5，若否，则执行步骤D2。

每个客户端的更新时间，代表相应客户端上报信息距离当前的时长。如果更新时长超出更新阈值，即时长过长，说明该客户端很久都没有向服务端上报信息，可能是该客户端出现了问题，无法正常上报信息。如果更新时长未超出更新阈值，即时长不长，说明该客户端是正常向服务端上报信息，该客户端没有问题。

这里的更新阈值，需要根据上述的定时确定，如果定时设置的时间间隔较长，那么更新阈值也需要大一些。如果定时设置的时间间隔较短，那么更新阈值就需要小一些。

步骤D5：确定相应的客户端存在问题，发出告警信息。

当某一客户端的更新时间超出更新阈值时，说明该客户端最近一次没有向服务端上报服务器信息和应用信息，可能是该客户端出现了问题，无法获取服务器中的信息，或者可能是客户端所在的服务器出现了问题，使得客户端无法获取到服务器中的信息。此时，可以确定相应的客户端处出现了问题，发出告警信息。在该告警信息中，包含有判断出问题的客户端信息，以便运维人员能够快速定位问题客户端，尽快解决客户端处的问题。

由上述内容可知，系统通过判断各客户端上报服务器信息和应用信息的时间，能够及时发现存在异常的客户端，进而发出告警，使得运维人员能够快速定位问题客户端，找出问题，尽快使问题客户端恢复正常，确保服务器运维系统能够完全正常运行。

进一步地，作为对上述步骤S201的扩展，在使用服务器运维系统对各服务器进行自动运维时，需要先将系统在各服务器中部署。

具体来说，在服务器运维系统的开发阶段，可以基于Java语言开发。由于Java语言应用广泛，适用性强，可以使系统实现跨平台部署，即使得系统能够对不同平台的服务器实现运维管理。

在上述步骤S201之前，该方法还可以包括：

步骤E1：搭建redis集群和fastDFS集群。

其中，redis集群用于管理待运维的多个服务器，fastDFS集群用于存储运维文件。

运维人员管理多少台服务器，或者运维人员所在的企业有多少台服务器，就需要基于这些服务器搭建redis集群和fastDFS集群。

搭建redis集群，就是将这些待运维的多个服务器组成一个服务器集群，以便统一管理和调度。

搭建fastDFS集群，则是将这些待运维的多个服务器在运维过程中使用到的运维文件进行存储。

步骤E2：在待运维的多个服务器中部署redis集群和fastDFS集群，完成服务器运维系统与待运维的多个服务器的关联，启动服务器运维系统中服务端。

在redis集群和fastDFS集群搭建完成后，就可以将集群在各服务器中部署，以实现服务器运维系统与待运维的各服务器的关联。在系统与服务器关联完成后，就可以启动系统的服务端，以待运维工作的进行。

步骤E3：在待运维的多个服务器中分别安装jdk，并分别部署服务器运维系统的客户端。

系统的服务端启动完成后，就可以继续在各服务器中安装jdk，并在jdk安装完成后，就可以开始部署客户端。此时，服务器运维系统就完成了在待运维的各服务器中的部署工作，此后运维人员就可以通过系统服务端控制客户端实现对服务器的自动运维工作了。

由上述内容可知，通过在待运维的多个服务器中部署redis集群和fastDFS集群，能够轻松实现运维人员对于多个服务器的运维管理。

最后，以一个完整实例对本申请实施例提供的服务器运维方法进行再次说明。

图3为本申请实施例中服务器运维方法的完整过程示意图，参见图3所示，系统服务端用于向运维人员提供运维入口，系统客户端分别安装于各服务器，以实现服务器的自动运维。系统使用redis的发布订阅模式实现任务下发及信息上报。

在实际运维前，客户端定时获取服务器信息以及应用信息，将获取的信息上报到redis中，redis提供有存储服务器节点信息的位置，redis的key为NODE_INFO_+节点IP，用于客户端心跳检查。例如：服务器192.168.1.1中的客户端向redis上报NODE_INFO_192.168.1.1，服务器192.168.1.2中的客户端向redis上报NODE_INFO_192.168.1.2，服务器192.168.1.3中的客户端向redis上报NODE_INFO_192.168.1.3。

服务端定时获取redis中客户端上报的信息，并检查数据更新时间，如果数据更新时间超过指定的阈值，则认为当前服务器节点出现问题，发送报警到值班人员。

在实际运维时，管理员执行部署动作后，服务端发布消息到指定频道，如果需要部署多台服务器，则发送消息到多个频道中，频道的key为TASK_LIST_+节点IP。例如：在任务消息频道中，向各频道发布的消息为：TASK_LIST_192.168.1.1、TASK_LIST_192.168.1.2、TASK_LIST_192.168.1.3。

客户端订阅消费特定频道的消息，频道的key为TASK_LIST_+当前节点IP，消息内容为需要执行的任务，监听到任务后，启动任务脚本执行当前任务，如果任务执行包含文件或配置文件等，需要先从fastDFS中下载文件，解析完成后，再执行任务脚本。fastDFS中的文件都是服务端在部署时上传的。

任务执行时，客户端负责监听任务日志及任务状态，发布消息到另外一个频道，即任务日志频道。任务日志频道用于存储任务日志，该频道的key为：TASK_REPORT_LIST。例如：服务器192.168.1.1中的客户端向任务日志频道发布TASK_REPORT_LIST_192.168.1.1。

服务端订阅消费任务日志频道的消息，存储数据并实时展示到控制台。

可见，在本申请实施例提供的服务器运维系统中执行服务器运维方法，能够提供可视化管理界面，操作更加简单便捷。实时监控每台服务器信息，以及实时上报服务器上的应用信息，管理所有服务器节点。提供多种管理方式，每台服务器可单独运维，也可以使用集群分组的方式同时管理多台服务器。使用java语言开发，支持跨平台部署。支持自定义表达式，实现配置文件动态更新。支持高并发，每台服务器同时可安装多个应用，互不影响。依赖组件较少，稳定性更高。架构清晰明了，使用门槛较低，降低出错率，节省人力成本，降低运维难度。

基于同一发明构思，作为对上述方法的实现，本申请实施例还提供了一种服务器运维系统。图4为本申请实施例中服务器运维系统的结构示意图，参见图4所示，该系统可以包括：一个服务端401和多个客户端402，每个客户端402安装于待运维的相应服务器中；

服务端401，用于接收运维信息，所述运维信息包括待运维服务器和待运维内容；

服务端401，还用于解析所述运维信息，将所述待运维内容发送至所述待运维服务器；

所述待运维服务器中的客户端402，用于根据所述待运维内容对所述待运维服务器进行运维操作。

进一步地，每个客户端对应有一个任务频道，任务频道用于存储所述服务端发送的待运维内容，

所述服务端，具体用于获取所述运维信息中的待运维服务器；确定所述待运维服务器中安装的客户端对应的任务频道；将所述待运维内容发送至对应的任务频道；

所述待运维服务器对应的客户端，具体用于从其对应的任务频道中获取所述待运维内容。

进一步地，所述待运维服务器中的客户端，具体用于基于所述待运维内容调用相应的脚本对所述待运维服务器进行运维操作。

进一步地，所述服务器运维系统还包括存储端，所述存储端用于存储服务端接收到的运维文件，所述待运维内容包括运维任务名称，

所述待运维服务器中的客户端，还用于根据所述待运维内容中的运维任务名称判断是否需要从所述存储端中获取运维文件；若是，则从所述存储端中获取所述运维任务名称对应的运维文件；若否，则执行根据所述待运维内容调用相应的脚本对所述待运维服务器进行运维操作的步骤；

所述待运维服务器中的客户端，具体用于调用所述运维任务名称对应的脚本运行从所述存储端中获取的运维文件。

进一步地，所述运维服务系统还包括一个监听频道，

所述待运维服务器中的客户端，还用于监听所述运维操作的日志和状态；将所述日志和状态发送至所述监听频道；

所述服务端，还用于从所述监听频道中获取所述日志和状态；存储并展示所述日志和状态。

进一步地，每个客户端，还用于定时获取并向服务端上报其所在服务器的服务器信息和应用信息；

所述服务端，还用于获取每个客户端最近一次上报服务器信息和应用信息的时间；根据每个客户端最近一次上报的时间与当前时间计算每个客户端的更新时间；判断每个客户端的更新时间是否超出更新阈值；若是，则确定相应的客户端存在问题，发出告警信息；若否，则再次执行获取每个客户端最近一次上报服务器信息和应用信息的时间的步骤。

进一步地，所述服务器运维系统基于Java语言开发，

所述系统还包括：搭建模块，用于搭建redis集群和fastDFS集群，所述redis集群用于管理待运维的多个服务器，所述fastDFS集群用于存储运维文件；在待运维的多个服务器中部署所述redis集群和fastDFS集群，完成服务器运维系统与待运维的多个服务器的关联，启动所述服务器运维系统中服务端；在待运维的多个服务器中分别安装jdk，并分别部署所述服务器运维系统的客户端。

这里需要指出的是，以上系统实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请系统实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

基于同一发明构思，本申请实施例还提供了一种电子设备。图5为本申请实施例中电子设备的结构示意图，参见图5所示，该电子设备可以包括：处理器501、存储器502、总线503；其中，处理器501、存储器502通过总线503完成相互间的通信；处理器501用于调用存储器502中的程序指令，以执行上述一个或多个实施例中的方法。

这里需要指出的是，以上电子设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请电子设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

基于同一发明构思，本申请实施例还提供了一种计算机可读存储介质，该存储介质可以包括：存储的程序；其中，在程序运行时控制存储介质所在设备执行上述一个或多个实施例中的方法。

这里需要指出的是，以上存储介质实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种服务器运维方法，其特征在于，所述方法应用于服务器运维系统，所述服务器运维系统包括一个服务端和多个客户端，每个客户端安装于待运维的相应服务器中，所述方法包括：

服务端接收运维信息，所述运维信息包括待运维服务器和待运维内容；

服务端解析所述运维信息，将所述待运维内容发送至所述待运维服务器；

所述待运维服务器中的客户端根据所述待运维内容对所述待运维服务器进行运维操作。

2.根据权利要求1所述的方法，其特征在于，每个客户端对应有一个任务频道，任务频道用于存储所述服务端发送的待运维内容，所述服务端解析所述运维信息，将所述待运维内容发送至所述待运维服务器，包括：

服务端获取所述运维信息中的待运维服务器；

服务端确定所述待运维服务器中安装的客户端对应的任务频道；

服务端将所述待运维内容发送至对应的任务频道；

所述待运维服务器对应的客户端从其对应的任务频道中获取所述待运维内容。

3.根据权利要求1所述的方法，其特征在于，所述待运维服务器中的客户端根据所述待运维内容对所述待运维服务器进行运维操作，包括：

所述待运维服务器中的客户端基于所述待运维内容调用相应的脚本对所述待运维服务器进行运维操作。

4.根据权利要求3所述的方法，其特征在于，所述服务器运维系统还包括存储端，所述存储端用于存储服务端接收到的运维文件，所述待运维内容包括运维任务名称，在所述待运维服务器中的客户端基于所述待运维内容调用相应的脚本对所述待运维服务器进行运维操作之前，所述方法还包括：

所述待运维服务器中的客户端根据所述待运维内容中的运维任务名称判断是否需要从所述存储端中获取运维文件；

若是，则从所述存储端中获取所述运维任务名称对应的运维文件；

若否，则执行所述待运维服务器中的客户端根据所述待运维内容调用相应的脚本对所述待运维服务器进行运维操作的步骤；

所述待运维服务器中的客户端根据所述待运维内容调用相应的脚本对所述待运维服务器进行运维操作，包括：

所述待运维服务器中的客户端调用所述运维任务名称对应的脚本运行从所述存储端中获取的运维文件。

5.根据权利要求1所述的方法，其特征在于，所述运维服务系统还包括一个监听频道，在所述待运维服务器中的客户端根据所述待运维内容对所述待运维服务器进行运维操作之后，所述方法还包括：

所述待运维服务器中的客户端监听所述运维操作的日志和状态；

所述待运维服务器中的客户端将所述日志和状态发送至所述监听频道；

服务端从所述监听频道中获取所述日志和状态；

服务端存储并展示所述日志和状态。

6.根据权利要求1至5中任一项所述的方法，其特征在于，在服务端接收运维信息之前，所述方法还包括：

每个客户端定时获取并向服务端上报其所在服务器的服务器信息和应用信息；

服务端获取每个客户端最近一次上报服务器信息和应用信息的时间；

服务端根据每个客户端最近一次上报的时间与当前时间计算每个客户端的更新时间；

服务端判断每个客户端的更新时间是否超出更新阈值；

若是，则确定相应的客户端存在问题，发出告警信息；

若否，则再次执行获取每个客户端最近一次上报服务器信息和应用信息的时间的步骤。

7.根据权利要求1至5中任一项所述的方法，其特征在于，所述服务器运维系统基于Java语言开发，在服务端接收运维信息之前，所述方法还包括：

搭建redis集群和fastDFS集群，所述redis集群用于管理待运维的多个服务器，所述fastDFS集群用于存储运维文件；

在待运维的多个服务器中部署所述redis集群和fastDFS集群，完成服务器运维系统与待运维的多个服务器的关联，启动所述服务器运维系统中服务端；

在待运维的多个服务器中分别安装jdk，并分别部署所述服务器运维系统的客户端。

8.一种服务器运维系统，其特征在于，所述系统包括一个服务端和多个客户端，每个客户端安装于待运维的相应服务器中，

服务端，用于接收运维信息，所述运维信息包括待运维服务器和待运维内容；

服务端，还用于解析所述运维信息，将所述待运维内容发送至所述待运维服务器；

所述待运维服务器中的客户端，用于根据所述待运维内容对所述待运维服务器进行运维操作。

9.一种电子设备，其特征在于，所述电子设备包括：处理器、存储器、总线；其中，所述处理器、所述存储器通过所述总线完成相互间的通信；所述处理器用于调用所述存储器中的程序指令，以执行如权利要求1至7中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述存储介质包括：存储的程序；其中，在所述程序运行时控制所述存储介质所在设备执行如权利要求1至7中任一项所述的方法。