CN111147272A - 一种单服务器及多服务器运营平台升级方法 - Google Patents

Abstract

本发明涉及一种单服务器及多服务器运营平台升级方法，在单服务器运营平台升级方法中包括以下步骤：S100：将客户端程序安装在客户的服务器上；S200：启动客户端程序，且在客户端程序启动阶段定时开启升级任务，从客户管理中心平台下载更新信息；S300：客户端程序根据下载的更新文件列表清单判断是否下载更新文件，如果需要，则下载；S400：发出是否进行升级的提醒，当接收到升级指令时进行升级；S500：升级完成后，重启运营平台，检测运营平台的各模块是否正常启动，如果正常启动，则将升级结果上报至软件提供商的客户管理中心平台，否则，客户端程序对运营平台的本次升级进行回滚。本发明通过自动化的升级代替现有的手动升级的繁琐工作，提高了工作效率。

Description

一种单服务器及多服务器运营平台升级方法

技术领域

本发明涉及运营平台升级技术领域，尤其涉及一种单服务器及多服务器运营平台升级方法。

背景技术

软件提供商需要为每个客户安装部署运营平台，开发打包完的运营平台部署在客户内部服务器中交付给客户独立去运营，比如云平台，音视频平台等，但同时软件提供商需要保证优良的售后服务，往往为派专门的工作人员不定期对运营平台进行维护升级工作。

目前维护升级的方式是手动通过文件传输软件将更新包远程传输到客户的内部服务器中，放至运营平台对应的模块目录下，随后手动重启模块运用，同时升级(文件覆盖)前还需要手动备份运营平台模块目录下的原文件，升级启动后程序出错的话需手动恢复至上一个正常的版本，操作相当麻烦；如果由于性能要求原因运营平台不同模块需要分别部署在客户的多台服务器上，工作人员就需要将更新包在所接连接的其内部服务器中传输到另外一台未联网、无法直接访问的服务器中进行升级，无形中又增加了工作量。

发明内容

为解决上述问题，本发明一种单服务器及多服务器运营平台升级方法，用于以自动化的升级来代替现有的手动升级的繁琐工作，提高工作效率，减少工作量。

具体方案如下：

一种单服务器运营平台升级方法，包括以下步骤：

S100：将客户端程序安装在客户的服务器上；

S200：启动客户端程序，且在客户端程序启动阶段定时开启升级任务，检测本地临时文件夹中是否包含有运营平台模块的更新文件，如果有，进入S400；否则，从软件提供商的客户管理中心平台下载更新信息，所述更新信息包括更新文件列表清单；

S300：客户端程序对下载的更新文件列表清单进行解析，根据更新文件列表清单判断本地服务器上的运营平台模块目录下相应的原文件是否与更新文件列表清单对应的更新文件一致，如果不一致，则从软件提供商的客户管理中心平台下载更新文件，进入S400，如果一致，则结束；

S400：客户端程序检测运营平台模块是否正在运行，如果正在运行，则发出是否进行升级的提醒，当客户端程序接收到升级指令时，强制关闭运营平台各模块，并对运营平台模块目录下的原文件进行备份后，利用更新文件进行升级；当客户端程序接收到不升级指令时，将更新文件保存在本地临时文件夹内，结束；

S500：升级完成后，重新启动运营平台，检测运营平台的各模块是否正常启动，如果正常启动，则将升级结果上报至软件提供商的客户管理中心平台，否则，客户端程序对运营平台的本次升级进行回滚，回复到升级前可正常启动的状态，确保运营平台可以正常运营，同时通过分析日志，寻找模块启动失败的原因，并上报至客户管理中心平台。

进一步的，步骤S200中所述从软件提供商的客户管理中心平台下载更新信息还包括：向软件提供商的客户管理中心平台发起身份验证，当验证通过后，从该客户管理中心平台下载更新信息。

进一步的，步骤S200中当本地临时文件夹中包括多个更新文件时，将多个更新文件进行整合为一个更新文件。

进一步的，所述整合为去重整合。

进一步的，步骤S300中运营平台模块目录下相应的原文件是否与更新文件列表清单对应的更新文件一致的判断方法为：一一对比每个文件，首先对比文件大小，其次对比文件的哈希值，如果文件大小不一样或文件大小一样但哈希值不一样，则表示不一致。

进一步的，所述客户端程序通过FTP方式从软件提供商的客户管理中心平台下载更新文件。

一种多服务器运营平台升级方法，基于本发明实施例一所述的运营平台升级方法，设定一台能够联网的服务器为主服务器，其他服务器为从服务器，主服务器采用步骤S100-S500进行运营平台升级，当主服务器的客户端程序从客户管理中心平台下载更新文件后，唤醒所有从服务器的客户端程序，从服务器的客户端程序从主服务器中下载其需求的模块对应的更新文件，下载完成后，从服务器均采用步骤S400进行升级。

本发明采用如上技术方案，并具有有益效果：

1.本发明很好地解决了传统升级方式存在的一些问题，比如手动将更新包远程传输到客户的内部服务器中，放至运营平台对应的模块目录下、手动各重启模块运用、升级前还需要手动备份运营平台模块内的原文件、升级启动后程序出错的话需手动恢复至上一个正常的版本，等等，真正地释放了我们的一些人力、时间成本，提高了工作效率。

2.本发明具有极高的适用性，支持各种类型的运营平台，比如我们Java实现的云平台，C++实现的音视频平台等等，为我们软件平台的维护升级工作带来了很好的便利条件。

附图说明

图1所示为本发明实施例一的步骤示意图。

图2所示为本发明实施例一的结构示意图。

图3所示为本发明实施例二的结构示意图。

具体实施方式

为进一步说明各实施例，本发明提供有附图。这些附图为本发明揭露内容的一部分，其主要用以说明实施例，并可配合说明书的相关描述来解释实施例的运作原理。配合参考这些内容，本领域普通技术人员应能理解其他可能的实施方式以及本发明的优点。

现结合附图和具体实施方式对本发明进一步说明。

实施例一：

如图1和2所示，本发明实施例一提供了一种单服务器运营平台升级方法，包括以下步骤：

S100：通过客户端程序安装脚本将客户端程序安装在客户的服务器上。

所述客户端程序安装脚本为软件提供商提供的用于安装客户端程序的脚本，其内部有根据具体客户的服务器类型进行相应的配置，客户进行安装时，直接执行该脚本可以自动化的完成安装，无需再进行另行配置修改。

S200：启动客户端程序，且在客户端程序启动阶段定时开启升级任务，检测本地临时文件夹中是否包含有运营平台模块的更新文件，如果有，进入S400；否则，则通过网络(如http)向软件提供商的客户管理中心平台发起身份验证，当验证通过后，从该客户管理中心平台下载更新信息，所述更新信息包含但不限于更新说明和更新文件列表清单。

所述定时开启可以根据实际需求设定，如半天、一天等等，其根据软件提供商更新文件的频率设定，通过设定该定时开启，可以确保当软件提供商提供的软件版本更新时，能最快的检测到该更新，进而进行自动下载更新。

上述的通过检测本地临时文件夹中的更新文件来进行升级可以最大限度利用之前使用相关系统资源后产生的价值，不重复过度浪费系统资源。

进行身份验证可以确保客户合法和客户管理中心平台的服务安全。

进一步的，当本地临时文件夹中包括多个更新文件时，将多个更新文件进行整合为一个更新文件。所述整合该实施例中采用去重整合，本领域技术人员也可以采用其他的整合方式。

该实施例中，不同的更新文件保存在不同的临时文件夹内，不同时期保存的更新文件中每个文件的时间不同，如果两个更新文件中包含一部分共有文件(即文件名相同)，则通过去重整合，将两个文件夹合并，并将共有文件中时间靠前的文件删除，时间靠后的文件保留，类似于数学上的两文件取并集。

S300：客户端程序对下载的更新文件列表清单进行解析，并与本地服务器上的运营平台模块目录下相应的原文件进行比对，一一对比每个文件，首先对比文件大小，其次对比文件的哈希值(如MD5值等)，如果文件大小不一样或文件大小一样但哈希值不一样，则通过FTP方式(其他常用方式也可以，FTP方式较佳)从软件提供商的客户管理中心平台进行运营平台更新文件的下载，如果文件大小和哈希值比对均一样，则说明运营平台模块目录下相应的原文件已经为最新文件，不需要进行更新，结束。

本领域技术人员也可以采用其他参数来进行文件一致性的对比。

由于运营平台的版本概念并不是非常强，也许整个平台会有版本号，但变化频率相当低，模块、模块里的代码文件也都没有用版本号去标识了，另外版本管理容易因为工作人员疏忽而产生无法升级的问题，所以用文件比对的方法可以解决上述问题，是决定运营平台是否下载升级的最佳选择。

通过文件比对后进行FTP方式下载文件，避免了传统升级通过建立TCP长连接完成文件传输的方式，节省了服务器的网络资源利用率，减少对原本的运营平台的模块功能稳定性产生的影响，通过FTP协议下载文件，效率更高，尤其是多客户端的情况下，并且客户管理中心平台可以管理各个FTP账号的相关属性，根据时间情况控制下载，比TCP更加灵活。

S400：客户端程序检测运营平台模块是否正在运行，如果正在运行，则发出是否进行升级的提醒，当客户确认升级时，客户端程序接收到升级指令，强制关闭运营平台各模块，并对运营平台模块目录下的原文件进行备份后，利用更新文件进行升级；如果客户选择暂不升级，则客户端程序接收到不升级指令，将更新文件保存在临时文件夹内，结束。

优选的，为了方便客户了解升级进行，提高用户体验，该实施例中，运营平台的显示模块同步显示本次升级的详细过程和进度条信息。

S500：升级完成后，重新启动运营平台，检测运营平台的各模块是否正常启动，如果正常启动，则将升级结果上报至软件提供商的客户管理中心平台，否则，客户端程序对运营平台的本次升级进行回滚，回复到升级前可正常启动的状态，确保运营平台可以正常运营，同时通过分析日志，寻找模块启动失败的原因，并上报至客户管理中心平台，以便工作人员根据失败的原因对更新文件进行修改，以确保修改后的更新文件不会出现上述的启动失败现象。

本发明实施例一相比现有技术具有以下优点：

(1)独立可用性

客户端程序是一个独立的模块程序，虽然可以操作升级运营平台各模块，但他们都是属于同一个层级的模块节点，互相之间几乎没有依赖性，各程序出现问题互不影响，在给运营平台模块提供在线升级功能的基础上，同时也确保了互相之间的稳定性、可用性。

(2)高并发作业

客户端程序升级任务的定时作业性很好地实现了高并发远程在线升级等工作，另外基于FTP被动模式的高并发方式下载文件，大大提升了文件的传输效率，相对于传统的方式在性能、效率上有了很大的提升，中心平台也是自主研发，具有出色的负载能力。

(3)多环境支持

该实施例中，客户端程序可以由跨平台的Java语言开发，因此，能够适用于windows和Linux等多种系统的自动化部署，并且已经得到实践验证并使用。

(4)升级回滚机制

该客户端程序提供了文件备份、升级回滚的功能。待升级的代码文件是人为提交的，也许有可能工作人员并不知道提交的代码文件里存在影响程序模块的bug，升级完以后，客户端程序检测程序模块是否都正常启动，如果发现异常，则会进行回滚，使程序模块回到升级前的状态，保证平台功能都正常使用。

(5)高用户体验

该客户端程序从任务开启到下载更新文件完成都是在后台静默执行的，用户正常使用平台并且不会感受到这个过程，只有真正升级更新文件前需要关闭程序模块时会通知平台管理员，由管理员去决定是否升级，并且管理员可在界面上看到升级过程，最大化提升了运营平台升级的用户体验。

(6)离线升级机制

为了提升平台的用户体验，每次升级前都会通知管理员而不进行强制升级，由管理员决定是否升级，所以客户端程序针对多次下载的临时更新文件而没有升级的情况提供了相应的机制，在下一次开启任务后会进行本地离线式升级，对本地临时更新文件实施整合去重，之后重新发送通知，确保软件程序在真正升级后功能的完整性，避免了在服务端重新发布之前的升级任务的工作，节省了时间，在资源利用上的价值方面上有了很大的发挥。

(7)自身升级机制

除了运营平台需要维护升级，客户端程序本身也需要维护升级，所以客户端还增加有为自身程序远程在线升级的机制。客户端程序每次像中心平台发送身份验证请求后首先会检测有没有自身升级的任务，如果有则进行自身升级，如果没有，则进行运营平台的升级，使得客户端程序更灵活，人性化。

实施例二

如果3所示，本发明实施例二提供了一种多服务器运营平台升级方法，基于实施例一所述的单服务器运营平台升级方法。

其应用场景为：当客户需要为n(n>1)台服务器部署运营平台的不同模块，且只有一台服务器可联网时。

该实施例中，采用“一主多从”的整体架构，即设定可联网的服务器为主服务器，其他服务器为从服务器，主服务器的客户端程序采用实施例一中的步骤S100-S500进行运营平台升级，当主服务器的客户端程序从客户管理中心平台下载更新文件后，唤醒所有从服务器的客户端程序，从服务器的客户端程序通过FTP方式从主服务器中下载其需求的模块对应更新文件，当所有服务器需求的模块对应的更新文件下载完成后，进入步骤S400。

最终，所有的主、从服务器均能够完成升级的效果，即使有些服务器不能够访问外网，避免了“在所连接的其内部服务器中去连接到另外一台未联网、无法直接访问的服务器进行相关操作”的麻烦。

本发明实施例二相比现有技术具有以下优点：

(8)高效便捷性

无需使用拓补管理的方式去管理各个服务器，升级活动在都是在程序级别上进行执行，多台服务器的运营平台模块升级时各客户端程序同时进行，无需等待一台升级完再升级下一台，表现出高效性，只有将要升级的那一刻告知运营平台管理员，各个服务器无需人为实现在各台服务器上准备好了升级文件，提升了便携性。

(9)多服务器升级

针对一个客户需要升级运营平台时，并且客户提供两台机器用于部署不同的模块，一般出于其内部局域网原因两台服务器的访问方式只有一个公网SSH协议端口，然后进入到服务器去连接另外一台服务器，所以传统的升级方式真正实施起来相当麻烦，而该方法的“一主多从”的升级模式正是解决了这一问题，并且升级页面可以查看到各服务器的升级情况，形成一个统一的整体进度条。

尽管结合优选实施方案具体展示和介绍了本发明，但所属领域的技术人员应该明白，在不脱离所附权利要求书所限定的本发明的精神和范围内，在形式上和细节上可以对本发明做出各种变化，均为本发明的保护范围。

Claims (7)

1.一种单服务器运营平台升级方法，其特征在于，包括以下步骤：

S100：将客户端程序安装在客户的服务器上；

S200：启动客户端程序，且在客户端程序启动阶段定时开启升级任务，检测本地临时文件夹中是否包含有运营平台模块的更新文件，如果有，进入S400；否则，从软件提供商的客户管理中心平台下载更新信息，所述更新信息包括更新文件列表清单；

S300：客户端程序对下载的更新文件列表清单进行解析，根据更新文件列表清单判断本地服务器上的运营平台模块目录下相应的原文件是否与更新文件列表清单对应的更新文件一致，如果不一致，则从软件提供商的客户管理中心平台下载更新文件，进入S400，如果一致，则结束；

S400：客户端程序检测运营平台模块是否正在运行，如果正在运行，则发出是否进行升级的提醒，当客户端程序接收到升级指令时，强制关闭运营平台各模块，并对运营平台模块目录下的原文件进行备份后，利用更新文件进行升级；当客户端程序接收到不升级指令时，将更新文件保存在本地临时文件夹内，结束；

S500：升级完成后，重新启动运营平台，检测运营平台的各模块是否正常启动，如果正常启动，则将升级结果上报至软件提供商的客户管理中心平台，否则，客户端程序对运营平台的本次升级进行回滚，回复到升级前可正常启动的状态，确保运营平台可以正常运营，同时通过分析日志，寻找模块启动失败的原因，并上报至客户管理中心平台。

2.根据权利要求1所述的单服务器运营平台升级方法，其特征在于：步骤S200中所述从软件提供商的客户管理中心平台下载更新信息还包括：向软件提供商的客户管理中心平台发起身份验证，当验证通过后，从该客户管理中心平台下载更新信息。

3.根据权利要求1所述的单服务器运营平台升级方法，其特征在于：步骤S200中当本地临时文件夹中包括多个更新文件时，将多个更新文件进行整合为一个更新文件。

4.根据权利要求3所述的单服务器运营平台升级方法，其特征在于：所述整合为去重整合。

5.根据权利要求1所述的单服务器运营平台升级方法，其特征在于：步骤S300中运营平台模块目录下相应的原文件是否与更新文件列表清单对应的更新文件一致的判断方法为：一一对比每个文件，首先对比文件大小，其次对比文件的哈希值，如果文件大小不一样或文件大小一样但哈希值不一样，则表示不一致。

6.根据权利要求1所述的单服务器运营平台升级方法，其特征在于：所述客户端程序通过FTP方式从软件提供商的客户管理中心平台下载更新文件。

7.一种多服务器运营平台升级方法，基于权利要求1-6中任一所述的运营平台升级方法，其特征在于：设定一台能够联网的服务器为主服务器，其他服务器为从服务器，主服务器采用步骤S100-S500进行运营平台升级，当主服务器的客户端程序从客户管理中心平台下载更新文件后，唤醒所有从服务器的客户端程序，从服务器的客户端程序从主服务器中下载其需求的模块对应的更新文件，下载完成后，从服务器均采用步骤S400进行升级。

Images