CN116860288A - 一种erp系统升级方法、装置、设备及介质 - Google Patents

Abstract

本发明公开了一种ERP系统升级方法、装置、设备及介质，本方法包括：启动新版本ERP系统实例；待新版本ERP系统实例运行正常后，将与新版本ERP系统实例对应的新服务注册到注册中心，并修改负载均衡策略服务；在注册中心和负载均衡策略服务上卸载旧版本ERP系统实例，旧版本ERP系统实例运行前期已经收到的业务请求，新版本ERP系统实例运行新接收的业务请求；验证新版本ERP系统实例，当旧版本ERP系统实例已处理完前期业务请求，且新版本ERP系统实例验证通过后，再对旧版本ERP系统实例停机。本发明在不影响前端客户使用，也不影响后端接口调用的情况下，通过定制的管理数据流实现了业务数据流的不间断，保证了业务完整性，完成了版本的优雅升级。

Description

一种ERP系统升级方法、装置、设备及介质

技术领域

本发明涉及一种ERP系统升级方法、装置、设备及介质。

背景技术

现有的ERP系统版本升级时主要包括三部分内容：升级前通告、升级中、升级后处理。

升级前：先通知相同相关方(包括系统运维、系统使用人、系统相关接口等)在指定的时间系统不可用。

升级中：系统运维人员需要先关闭系统web访问地址、关闭系统接口，确保不会有新的业务进入。对于会通过API接口调用的相关联系统，需要修改调用规则。另外，系统运维人员还需要关闭系统定时任务，同时登陆系统数据库，确保所有的作业已经完成。当确定作业都已经处理完后，才能停止旧版本的运行实例，启动新版本运行实例。

升级后：系统运维人员确定新版本运行正常后才可以通知测试人员进行版本验证。要是验证失败，需要对新版本进行回滚，将升级的过程重来一次。另外，不管版本测试是否成功，都需要处理升级期间导致的垃圾数据，包括运维检查时系统无业务，系统随机启动一个线程运行产生的垃圾数据；或者，有业务处理的实例停止运行而产生的垃圾数据；或者，在系统升级过程中因为接口调用失败导致的错误而产生的垃圾数据等。

发明内容

为了提供一种不影响影响前端客户使用，也不影响后端接口调用的ERP系统升级方法，本发明实施例提供了一种ERP系统升级方法、装置、设备及介质。具体的：

一种ERP系统升级方法，至少包括：

启动新版本ERP系统实例；

待新版本ERP系统实例运行正常后，将与新版本ERP系统实例对应的新服务注册到注册中心，并修改负载均衡策略服务；

在注册中心和负载均衡策略服务上卸载旧版本ERP系统实例，旧版本ERP系统实例运行前期已经收到的业务请求，新版本ERP系统实例运行新接收的业务请求；

验证新版本ERP系统实例，当旧版本ERP系统实例已处理完前期业务请求，且新版本ERP系统实例验证通过后，再对旧版本ERP系统实例停机。

进一步的，所述启动新版本ERP系统实例，包括：

利用Jenkins集成工具进行新版本ERP系统实例的编译打包上线，并在Consul注册中心、API Server服务组件、Controller Manager服务组件、业务模块进行相应部署。

进一步的，所述待新版本ERP系统实例运行正常后，将新的服务注册到注册中心，并修改负载均衡策略服务，包括：

利用Consul注册中心的ServiceRegister服务完成新版本ERP系统实例的注册，利用Ingress-Control路由实时将新的服务的访问地址同步到负载均衡策略服务。

进一步的，所述在注册中心和负载均衡策略服务上卸载旧版本ERP系统实例，包括：

利用Consul注册中心的Deregister Service服务卸载旧版本ERP系统实例，利用预设脚本中调用API Server对外提供的API接口，删除serve中的旧版本示例。

进一步的，所述再对旧版本ERP系统实例停机，包括：

利用API Server服务组件发起对旧版本ERP系统实例的停机命令；

API接口接收停机命令后，触发Controller Manager服务组件调用业务模块发起停机；

业务节点接受到停机命令后，检查自身是否涉及停机前操作，若存在停机前脚本，并检查到执行成功后，不再接受新的web请求，对于已经接收到的请求继续正常处理，处理完毕后再终止应用进程；对于应用内部执行的定时任务，不再启动新的定时任务，并等待当前正在执行的所有定时任务执行完毕，再终止应用进程。

进一步的，利用API Server服务组件发起停机，包括：

在jenkins中编写sh脚本，使用curl命名，调用patch接口，更新旧版本的deployment的replicas字段，将replicas改为0。

进一步的，利用Controller Manager服务组件调用业务模块发起停机，包括：

将Pod设置为Terminating状态，并从所有Service的Endpoints列表中删除；

执行PreStop Hook；

向Pod中的容器发送SIGTERM信号；

等待指定的时间，等待旧版本的ERP系统业务模块停机，若业务模块在终止宽限期后仍在运行，则发送SIGKILL信号强制旧版本停机。

进一步的，对于应用内部执行的定时任务，不再启动新的定时任务，并等待当前正在执行的所有定时任务执行完毕，再终止应用进程，具体包括：

获取Quartz任务调度的多种线程池；

重复多轮遍历所有线程池判断是否存在任务，若重复多轮遍历所有线程池都没有任何任务则判断当前正在执行的所有定时任务执行完毕。

另一方面，本发明还公开了一种ERP系统升级装置，包括新版本启动模块、新服务注册模块、旧版本卸载模块、旧版本停机模块，其中：

所述新版本启动模块，用于启动新版本ERP系统实例；

所述新服务注册模块，用于待新版本ERP系统实例运行正常后，将与新版本ERP系统实例对应的新服务注册到注册中心，并修改负载均衡策略服务；

所述旧版本卸载模块，用于在注册中心和负载均衡策略服务上卸载旧版本ERP系统实例，旧版本ERP系统实例运行前期已经收到的业务请求，新版本ERP系统实例运行新接收的业务请求；

所述旧版本停机模块，用于验证新版本ERP系统实例，当旧版本ERP系统实例已处理完前期业务请求，且新版本ERP系统实例验证通过后，再对旧版本ERP系统实例停机。

本发明实施例提供的上述技术方案的有益效果至少包括：

本发明实施例提供的ERP系统升级方法中先启动新版本ERP系统实例，待新版本ERP系统实例运行正常后，将新的服务注册到注册中心，并修改负载均衡策略服务，同时在注册中心和负载均衡上卸载旧版本ERP系统实例，但是旧版本ERP系统实例并没有停止运行，此后新的业务请求由新版本ERP系统实例承接，旧版本ERP系统实例运行前期已经收到的业务请求。然后就可以开始验证新版本ERP系统实例。通过后台程序确定旧版本业务已经处理完，且新版本验证通过后，才对旧版本ERP系统实例停机。本发明实施例在不影响前端客户使用，也不影响后端接口调用的情况下，通过定制的管理数据流实现了业务数据流的不间断，保证了业务完整性，完成了版本的优雅升级。升级过程中不会产生额外的垃圾数据、脏数据，不影响事务一致性，不需要为升级额外做业务补偿，同时大大缩短版本升级时间。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1为实施例一中，ERP系统升级方法的流程示意图；

图2为实施例一中，ERP系统升级时，整个系统数据流的流向示意图；

图3为实施例一中，步骤S40中，对旧版本ERP系统实例停机的流程示意图；

图4为实施例一中，步骤S402的流程示意图；

图5为实施例一中，管理数据流的流向情况示意图；

图6为实施例二中，ERP系统升级装置的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。应理解，以下实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

为了说明本申请的技术方案，本发明先对相关现有专业术语做相应简单解释，更详细的说明可以参考现有技术文件。

Kubernetes，简称K8s或者“kube”，是一个开源的Linux容器自动化运维平台，它消除了容器化应用程序在部署、伸缩时涉及到的许多手动操作。

K8s包括以下基本概念：

(1)Master(主节点)：控制Kubernetes节点的机器，也是创建作业任务的地方。

(2)Node(节点)：这些机器在Kubernetes主节点的控制下执行被分配的任务。

(3)Pod：由一个或多个容器构成的集合，作为一个整体被部署到一个单一节点。同一个pod中的容器共享IP地址、进程间通讯(IPC)、主机名以及其它资源。Pod将底层容器的网络和存储抽象出来，使得集群内的容器迁移更为便捷。

(4)Service(服务)：将服务内容与具体的pod分离。Kubernetes服务代理负责自动将服务请求分发到正确的pod处，不管pod移动到集群中的什么位置，甚至可以被替换掉。

(5)Kubelet：这个守护进程运行在各个工作节点上，负责获取容器列表，保证被声明的容器已经启动并且正常运行。

Consul：分布式环境中的服务的注册和发现流程，通过HTTP或者DNS接口发现，Consul的主要接口是Restful HTTP API，这些API可以对节点、服务、检查、配置等对象执行基本的CRUD操作。

API Server：是K8s重要的管理API层。它负责提供restful API访问端点,并且将数据持久化到etcd server中。Kubernetes集群中，API Server扮演着交互入口的位置。APIServer不仅负责和etcd交互(其他组件不会直接操作etcd，只有API Server这么做)。

API Endpoint(端点)：当API与另一个系统交互时，此通信的接触点被视为端点。对于API，端点可以包含服务器或服务的URL。每个端点都是API可以访问执行其功能所需的资源的位置。API使用“请求”和“响应”工作。当API从Web应用程序或Web服务器请求信息时，它会收到响应。API发送请求的位置和资源所在的位置称为端点。

Endpoint是可被访问的服务端点，即一个状态为running的pod，它是service访问的落点，只有service关联的pod才可能成为endpoint。

Controller Manager：在Pod工作流中起着管理和控制整个集群的作用，主要对资源对象进行管理，当Node节点中运行的Pod对象或是Node自身发生意外或故障时，Controller Manager会及时发现并处理，以确保整个集群处于理想工作状态。

Jenkins：是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件项目可以进行持续集成。

Quartz：Quartz是一个完全由java编写的开源作业调度框架，其框架包括：job-任务、Trigger-触发器、Scheduler-任务调度。

在对基本概念有了一些介绍后，下面通过具体实施例来对本发明公开的技术方案进行说明。

发明人发现，现有技术中，整个ERP系统上线后，使用的客户除了有操作前端页面的业务人员，还有后台数据同步和数据下发的接口调用。上线系统版本升级时，旧版本不应该再接受新的业务请求，旧版本上面运行的旧业务请求也不能受到影响。要做到这点，常见的方法是及时通知各方系统的升级时间，在升级时间内系统不接受业务请求，因此前台页面模块需要在其他空余时间升级，并需要协调几十个与后台接口涉及的外围系统，需要协调的范围太大。因此本发明希望期望在不影响前端客户使用，也不影响后端接口调用的情况下，通过定制的管理数据流实现了业务数据流的不间断，保证了业务完整性，完成了版本的优雅升级。

实施例一

结合图1所示，一种ERP系统升级方法至少包括步骤S10-步骤S40。为了方便理解，图2还示意出了ERP系统升级时，整个系统数据流的流向过程，整个系统数据流业务包括正常运行的业务数据流及管理数据流两部分。ELB是弹性负载均衡(Elastic Load Balance)的简称ELB)，ERP-frontend为ERP的前端，ERP-basis为ERP的后端，ERP-oracle、ERP-redis均为数据库。具体的：

步骤S10,启动新版本ERP系统实例。

具体的，可以利用Jenkins集成工具进行新版本ERP系统实例的编译打包上线，并在Consul注册中心、API Server服务组件、Controller Manager服务组件、业务模块进行相应部署。

步骤S20,待新版本ERP系统实例运行正常后，将与新版本ERP系统实例对应的新服务注册到注册中心，并修改负载均衡策略服务。

具体的，可以利用Consul注册中心的ServiceRegister服务完成新版本ERP系统实例的注册，利用Ingress-Control路由实时将新的服务的访问地址同步到负载均衡策略服务。

Consul注册中心的主要接口是RESTful HTTP API，该API可以用来增删查改nodes、services、checks、configguration。

serviceRegister用来服务注册的具体实现为：

/v1/agent/service/register:在本地agent增加一个新的服务项，使用PUT方法传输一个json格式的数据。

List Services：此端点返回在给定数据中心中注册的服务。

/v1/catalog/service/<service>:列出给定服务中的节点。

Ingress-Controller不是Controller Manager中的一部分，它只是一个或一组独立的Pod资源，通常就是一个运行着有七层代理能力或调度能力的应用，在本实施例中会实时的将server中的endpoints同步到负载均衡。新版本上线成功后，即健康检查通过后，会自动更新server的endpoints。如果需要旧版本下线，只需要调用API Server提供的停机接口，旧版本对应的endpoints实例就会自动删除。

步骤S30,在注册中心和负载均衡策略服务上卸载旧版本ERP系统实例，旧版本ERP系统实例运行前期已经收到的业务请求，新版本ERP系统实例运行新接收的业务请求。

具体的，可以利用Consul注册中心的Deregister Service服务卸载旧版本ERP系统实例，利用预设通过编写shell脚本，脚本中调用API Server对外提供的API接口，删除serve中的旧版本示例。在流水线中，在发布新版本前，调用本地编写的shell脚本。

Deregister Service注销指定服务的具体实现为：

/v1/agent/service/deregister/<serviceID>:注销一个本地agent的服务项

在jenkins中编写sh脚本，使用curl命名，先调用后调用API接口，获取旧服务列表，注销旧服务。

步骤S40,验证新版本ERP系统实例，当旧版本ERP系统实例已处理完前期业务请求，且新版本ERP系统实例验证通过后，再对旧版本ERP系统实例停机。

具体的，结合图3所示，验证新版本ERP系统实例，当旧版本ERP系统实例已处理完前期业务请求，且新版本ERP系统实例验证通过后，需要进行子步骤S401-S403以实现对旧版本ERP系统实例停机，其中：

步骤S401,利用API Server服务组件发起对旧版本ERP系统实例的停机命令。

API Server是Kubernetes的原生API，可以通过API网关调用，其URL格式为：https://{clusterid}.Endpoint/uri。其中{clusterid}为集群ID，uri为资源路径，也即API访问的路径。在具体实现时至少涉及以下内容：

(1)patch部分更新指定的Deployment HTTP请求

PATCH/APIs/apps/v1/namespaces/{namespace}/deployments/{name}

(2)replicas(int32)预期Pod的数量。这是一个指针，用于辨别显式零和未指定的值，默认为1。

需要在jenkins中编写sh脚本，可以使用curl命名，调用patch接口，更新旧版本的deployment的replicas字段，将replicas改为0。

步骤S402，API接口接收停机命令后，触发Controller Manager服务组件调用业务模块发起停机。

在Deployment做滚动更新时，一旦有新版本的Pod启动，就会删除旧的Pod，一旦Kubernetes决定终止Pod，就会发生一系列事件，需要对多个对象(如Endpoint、Ipvs/iptables、SLB)进行状态同步，并且这些同步操作是异步执行的。

Pod在删除的时候，大致的生命周期结合图4所示，包括步骤S4021-步骤S4025：

步骤S4021，Pod状态变更：将Pod设置为Terminating状态，并从所有Service的Endpoints列表中删除。此时，Pod停止获得新的流量，但在Pod中运行的容器不会受到影响，将会继续处理之前的请求；

步骤S4022，执行PreStop Hook：Pod删除时会触发PreStop Hook，PreStop Hook支持Bash脚本、TCP或HTTP请求。

步骤S4023，发送SIGTERM信号：向Pod中的容器发送SIGTERM信号；

步骤S4024，等待指定的时间：TerminationGracePeriodSeconds字段用于控制等待时间，在一些实施例中，默认值为30秒。

该步骤与PreStop Hook同时执行，因此TerminationGracePeriodSeconds需要大于PreStop的时间，否则会出现PreStop未执行完毕，Pod就被停止(KILL)的情况。

步骤S4025，发送SIGKILL信号：等待指定时间后，如果容器在优雅终止宽限期后仍在运行，则会发送SIGKILL信号并强制删除。与此同时，所有的Kubernetes对象也会被清除。

上述步骤S4021-步骤S4024的步骤可以同时进行，因此有可能存在Pod收到SIGTERM信号并且停止工作后，但还未从Endpoints中移除的情况。此时，请求从Slb转发到Pod中，而Pod已经停止工作，会出现服务中断。

因此，需要为Pod配置PreStop Hook，使Pod收到SIGTERM时，调用实例接口，判断当期业务是否处理完成，如果没有处理完成，等待预设时间(如30秒)后再次判断，直到处理完成。

对于需要停机的旧版本，需要保障的事停机不影响业务，所有时间可以预留足够长，比如可以设置为30分钟，30分钟内批量业务也能够处理完全。

步骤S403，业务节点接受到停机命令后，检查自身是否涉及停机前操作，若存在停机前脚本，并检查到执行成功后，不再接受新的web请求，对于已经接收到的请求继续正常处理，处理完毕后再终止应用进程；对于应用内部执行的定时任务，不再启动新的定时任务，并等待当前正在执行的所有定时任务执行完毕，再终止应用进程。

暴力的关闭应用程序，即应用收到停止指令后立即终止，则可能会导致进程持有的全局资源得不到释放，而其他进程也因无法获取资源而不能处理业务。比如如果某个任务处理需要首先获取一个redis锁，而锁又没有设置过期时间，如果任务获取锁后还未释放锁就终止了，会导致资源被锁无法再进行处理。

为了使应用进程发送停止指令之后依然能保证正在执行的业务操作不受影响，则应用进程接收到停止指令之后还应当等当前正在执行的定时任务执行完毕，并且不再启动新的定时任务。为了实现本目的，至少要完成以下两点：

(1)对于web接口请求，应用收到终止指令后，不再接受新的web请求，对于已经接收到的请求继续正常处理，处理完毕后再终止应用。

(2)对于应用内部执行的定时任务(Quartz实现)，不再启动新的定时任务，并等待当前正在执行的所有定时任务执行完毕，然后才终止。

为了终止Quartz定时任务，至少需要获取Quartz任务调度的多种线程池。然后重复多轮遍历所有线程池判断是否存在任务，若重复多轮遍历所有线程池都没有任何任务则判断当前正在执行的所有定时任务执行完毕。

具体实现时的主要思路是获取Quartz的线程池，通过操作线程池安全终止来达到安全终止定时任务的目的。首先可以手动指定定时任务的线程池，指定安全关闭此线程池的方法。然后遍历各线程池，检查每个线程池是否完成，如果检查发现都完成则计数器加1，只要有未完成的就不加并清零计数器。不断循环，每次循环sleep 1秒，直到计数器为预设阈值(比如预设阈值为3，也就是连续三次按随机顺序检查所有线程池都没有任何任务)，才判断当前正在执行的所有定时任务执行完毕。

在本实施例中，线程池可以至少包括以下四种情况：

(1)java.util.concurrent.ThreadPoolExecutor：最常用的线程池

(2)java.util.concurrent.ForkJoinPool：ForkJoin形式的线程池

(3)Redis连接池

(4)Oracle数据库连接池

另外，在步骤S40中，若新版本ERP系统实例验证未通过，则重新执行步骤S10至步骤S40。

本发明实施例提供的ERP系统升级方法中先启动新版本ERP系统实例，待新版本ERP系统实例运行正常后，将新的服务注册到注册中心，并修改负载均衡策略服务，同时在注册中心和负载均衡上卸载旧版本ERP系统实例，但是旧版本ERP系统实例并没有停止运行，此后新的业务请求由新版本ERP系统实例承接，旧版本ERP系统实例运行前期已经收到的业务请求。然后再开始验证新版本ERP系统实例。通过后台程序确定旧版本业务已经处理完，且新版本验证通过后，才对旧版本ERP系统实例停机。

相比于现有技术中新版本升级涉及几个大步骤：告知相关方系统升级并停用；新版本编译打包上线；旧版本下线；测试不通过回滚，本发明实施例省去了告知相关方系统升级并停用的步骤，同时通过自动化方式优化旧版本下线。现有技术需要运维人员手工处理的系统停机，而本发明停机通过调用云原生的API接口，实现流量先线下，当业务处理完后再停机。本发明实施例在不影响前端客户使用，也不影响后端接口调用的情况下，通过定制管理数据流，实现了版本更新过程中业务数据数据流程完整和不间断，完成了版本的优雅升级。图5示意出了管理数据流在Consul注册中心、API Server服务组件、ControllerManager服务组件、业务模块中的流向情况，主要包括Jenkins集成工具调用Consul注册中心的流量下线申请的流量下线实现；Jenkins集成工具调用API Server的Pods下线实现；Controller manager调用业务模块停机请求的实现等内容。本领域普通技术人员可以理解的，本发明的ERP系统升级还会涉及版本代码检查、自动化测试等环节，均可采用现有技术，因此本实施例并未对相关内容进行详细介绍。

另外，现有技术存在人工触发停机，人工所需判断的情况比较多，且每个业务实例都存在差异，很容易判断失误或者不及时，容易导致垃圾数据和脏数据。而本申请如果旧版本能完整的处理业务请求，就不会产生了垃圾数据和脏数据。因此，本发明实施例还具有升级过程中不会产生额外的垃圾数据、脏数据，不影响事务一致性，不需要为升级额外做业务补偿，同时大大缩短版本升级时间的优点。

实施例二

本发明还公开了一种ERP系统升级装置，如图6所示，包括新版本启动模块101、新服务注册模块102、旧版本卸载模块103、旧版本停机模块104，其中：

新版本启动模块101，用于启动新版本ERP系统实例。

具体的，新版本启动模块101用于可以利用Jenkins集成工具进行新版本ERP系统实例的编译打包上线，并在Consul注册中心、API Server服务组件、Controller Manager服务组件、业务模块进行相应部署。

新服务注册模块102，用于待新版本ERP系统实例运行正常后，将与新版本ERP系统实例对应的新服务注册到注册中心，并修改负载均衡策略服务。

具体的，新服务注册模块102用于利用Consul注册中心的ServiceRegister服务完成新版本ERP系统实例的注册，利用Ingress-Control路由实时将新的服务的访问地址同步到负载均衡策略服务。

旧版本卸载模块103，用于在注册中心和负载均衡策略服务上卸载旧版本ERP系统实例，旧版本ERP系统实例运行前期已经收到的业务请求，新版本ERP系统实例运行新接收的业务请求。

具体的，旧版本卸载模块103用于利用Consul注册中心的Deregister Service服务卸载旧版本ERP系统实例，利用预设通过编写shell脚本，脚本中调用API Server对外提供的API接口，删除serve中的旧版本示例。在流水线中，在发布新版本前，调用本地编写的shell脚本。

旧版本停机模块104，用于验证新版本ERP系统实例，当旧版本ERP系统实例已处理完前期业务请求，且新版本ERP系统实例验证通过后，再对旧版本ERP系统实例停机。

具体的，旧版本停机模块104用于验证新版本ERP系统实例，当旧版本ERP系统实例已处理完前期业务请求，且新版本ERP系统实例验证通过后，利用API Server服务组件发起对旧版本ERP系统实例的停机命令。还用于使API接口接收停机命令后，触发ControllerManager服务组件调用业务模块发起停机。还用于在业务节点接受到停机命令后，检查自身是否涉及停机前操作，若存在停机前脚本，并检查到执行成功后，不再接受新的web请求，对于已经接收到的请求继续正常处理，处理完毕后再终止应用进程；对于应用内部执行的定时任务，不再启动新的定时任务，并等待当前正在执行的所有定时任务执行完毕，再终止应用进程。

本一种ERP系统升级装置各模块的实现步骤可以参见实施例一，在此不再赘述。

本发明实施例提供的ERP系统升级装置先启动新版本ERP系统实例，待新版本ERP系统实例运行正常后，将新的服务注册到注册中心，并修改负载均衡策略服务，同时在注册中心和负载均衡上卸载旧版本ERP系统实例，但是旧版本ERP系统实例并没有停止运行，此后新的业务请求由新版本ERP系统实例承接，旧版本ERP系统实例运行前期已经收到的业务请求。然后就可以开始验证新版本ERP系统实例。通过后台程序确定旧版本业务已经处理完，且新版本验证通过后，才对旧版本ERP系统实例停机。本发明实施例在不影响前端客户使用，也不影响后端接口调用的情况下，通过定制的管理数据流实现了业务数据流的不间断，保证了业务完整性，完成了版本的优雅升级。升级过程中不会产生额外的垃圾数据、脏数据，不影响事务一致性，不需要为升级额外做业务补偿，同时大大缩短版本升级时间。

实施例三

基于同样的发明构思，本发明实施例还公开了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现实施例1中步骤S10-步骤S40的ERP系统升级方法。

实施例四

基于同样的发明构思，本发明实施例还公开了一种计算机设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现实施例1中步骤S10-步骤S40的ERP系统升级方法。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (12)

1.一种ERP系统升级方法，其特征在于，至少包括以下步骤：

启动新版本ERP系统实例；

待新版本ERP系统实例运行正常后，将与新版本ERP系统实例对应的新服务注册到注册中心，并修改负载均衡策略服务；

在注册中心和负载均衡策略服务上卸载旧版本ERP系统实例，旧版本ERP系统实例运行前期已经收到的业务请求，新版本ERP系统实例运行新接收的业务请求；

验证新版本ERP系统实例，当旧版本ERP系统实例已处理完前期业务请求，且新版本ERP系统实例验证通过后，再对旧版本ERP系统实例停机。

2.如权利要求1所述的ERP系统升级方法，其特征在于，所述启动新版本ERP系统实例，包括：

利用Jenkins集成工具进行新版本ERP系统实例的编译打包上线，并在Consul注册中心、API Server服务组件、Controller Manager服务组件、业务模块进行相应部署。

3.如权利要求1所述的ERP系统升级方法，其特征在于，所述待新版本ERP系统实例运行正常后，将新的服务注册到注册中心，并修改负载均衡策略服务，包括：

利用Consul注册中心的ServiceRegister服务完成新版本ERP系统实例的注册，利用Ingress-Control路由实时将新的服务的访问地址同步到负载均衡策略服务。

4.如权利要求1所述的ERP系统升级方法，其特征在于，所述在注册中心和负载均衡策略服务上卸载旧版本ERP系统实例，包括：

利用Consul注册中心的Deregister Service服务卸载旧版本ERP系统实例，利用预设脚本中调用API Server对外提供的API接口，删除serve中的旧版本示例。

5.如权利要求1所述的ERP系统升级方法，其特征在于，所述验证新版本ERP系统实例，当旧版本ERP系统实例已处理完前期业务请求，且新版本ERP系统实例验证通过后，再对旧版本ERP系统实例停机所述再对旧版本ERP系统实例停机，包括：

验证新版本ERP系统实例，当旧版本ERP系统实例已处理完前期业务请求，且新版本ERP系统实例验证通过后，利用API Server服务组件发起对旧版本ERP系统实例的停机命令；

API接口接收停机命令后，触发Controller Manager服务组件调用业务模块发起停机；

业务节点接受到停机命令后，检查自身是否涉及停机前操作，若存在停机前脚本，并检查到执行成功后，不再接受新的web请求，对于已经接收到的请求继续正常处理，处理完毕后再终止应用进程；对于应用内部执行的定时任务，不再启动新的定时任务，并等待当前正在执行的所有定时任务执行完毕，再终止应用进程。

6.如权利要求5所述的ERP系统升级方法，其特征在于，所述利用API Server服务组件发起对旧版本ERP系统实例的停机命令，包括：

在jenkins中编写sh脚本，使用curl命名，调用patch接口，更新旧版本的deployment的replicas字段，将replicas改为0。

7.如权利要求5所述的ERP系统升级方法，其特征在于，所述触发Controller Manager服务组件调用业务模块发起停机，包括：

将系统中的最小调度单元Pod设置为Terminating状态，并从所有Service的Endpoints列表中删除；

执行PreStop Hook；

向最小调度单元Pod中的容器发送SIGTERM信号；

等待指定的时间待旧版本的ERP系统业务模块停机，若业务模块在终止宽限期后仍在运行，则发送SIGKILL信号强制旧版本停机。

8.如权利要求5所述的ERP系统升级方法，其特征在于，所述对于应用内部执行的定时任务，不再启动新的定时任务，并等待当前正在执行的所有定时任务执行完毕，再终止应用进程，具体包括：

获取Quartz任务调度的多种线程池；

重复多轮遍历所有线程池判断是否存在任务，若重复多轮遍历所有线程池都没有任何任务则判断当前正在执行的所有定时任务执行完毕。

9.如权利要求1所述的ERP系统升级方法，其特征在于，所述ERP系统升级方法还包括若新版本ERP系统实例验证未通过，则重新执行启动新版本ERP系统实例及之后的步骤。

10.一种ERP系统升级装置，其特征在于，包括新版本启动模块、新服务注册模块、旧版本卸载模块、旧版本停机模块，其中：

所述新版本启动模块，用于启动新版本ERP系统实例；

所述新服务注册模块，用于待新版本ERP系统实例运行正常后，将与新版本ERP系统实例对应的新服务注册到注册中心，并修改负载均衡策略服务；

所述旧版本卸载模块，用于在注册中心和负载均衡策略服务上卸载旧版本ERP系统实例，旧版本ERP系统实例运行前期已经收到的业务请求，新版本ERP系统实例运行新接收的业务请求；

所述旧版本停机模块，用于验证新版本ERP系统实例，当旧版本ERP系统实例已处理完前期业务请求，且新版本ERP系统实例验证通过后，再对旧版本ERP系统实例停机。

11.一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行实现如权利要求1-9任一项所述的ERP系统升级方法。

12.一种计算机设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1-9任一项所述的ERP系统升级方法。