An ERP system upgrade method, device, equipment and medium

Abstract

The present invention discloses a method, device, equipment and medium for upgrading an ERP system. The method includes: starting a new version of the ERP system instance; after the new version of the ERP system instance runs normally, registering the new service corresponding to the new version of the ERP system instance to the registration center and modifying the load balancing policy service; uninstalling the old version of the ERP system instance from the registration center and the load balancing policy service, where the old version of the ERP system instance processes the business requests received in the early stage of operation, and the new version of the ERP system instance processes the newly received business requests; verifying the new version of the ERP system instance, and when the old version of the ERP system instance has processed the previous business requests and the new version of the ERP system instance passes the verification, then shutting down the old version of the ERP system instance. Without affecting the use of front-end customers or the invocation of back-end interfaces, the present invention realizes the uninterrupted business data flow through the customized management data flow, ensures the business integrity, and completes the graceful upgrade of the version.

Description

Technical Field

[0001] The present invention relates to a method, device, equipment and medium for upgrading an ERP system. Background Art

[0002] When upgrading the existing ERP system version, it mainly includes three parts: notice before upgrade, during upgrade, and post-upgrade processing.

[0003] Before upgrade: First, notify the relevant parties (including system operation and maintenance, system users, system-related interfaces, etc.) that the system will be unavailable at a specified time.

[0004] During upgrade: System operation and maintenance personnel need to first close the system web access address and system interfaces to ensure that no new business enters. For associated systems that call through API interfaces, the call rules need to be modified. In addition, system operation and maintenance personnel also need to turn off the system scheduled tasks and log in to the system database to ensure that all jobs have been completed. After determining that all jobs have been processed, the running instance of the old version can be stopped and the running instance of the new version can be started.

[0005] After upgrade: System operation and maintenance personnel can notify testers to conduct version verification only after determining that the new version is running normally. If the verification fails, the new version needs to be rolled back and the upgrade process needs to be repeated. In addition, regardless of whether the version test is successful, it is necessary to process the garbage data generated during the upgrade, including the garbage data generated when the system has no business during operation and maintenance inspection and the system randomly starts a thread to run; or, the garbage data generated when the instance of business processing stops running; or, the garbage data generated due to errors caused by failed interface calls during the system upgrade process, etc. Summary of the Invention

[0006] In order to provide an ERP system upgrade method that does not affect the use of front-end customers and does not affect the call of back-end interfaces, embodiments of the present invention provide an ERP system upgrade method, device, equipment and medium. Specifically:

[0007] An ERP system upgrade method includes at least:

[0008] Start the running instance of the new version of the ERP system;

[0009] After the running instance of the new version of the ERP system runs normally, register the new service corresponding to the running instance of the new version of the ERP system to the registration center and modify the load balancing policy service;

[0010] Uninstall the running instance of the old version of the ERP system from the registration center and the load balancing policy service. The business requests received in the early stage of the running of the old version of the ERP system instance are processed by the new version of the ERP system instance, and the newly received business requests are processed by the new version of the ERP system instance;

[0011] Verify the instance of the new version of the ERP system. After the instance of the old version of the ERP system has processed the previous business requests and the instance of the new version of the ERP system passes the verification, then shut down the instance of the old version of the ERP system.

[0012] Furthermore, starting the instance of the new version of the ERP system includes:

[0013] Use the Jenkins integration tool to compile, package, and go live with the instance of the new version of the ERP system, and perform corresponding deployments in the Consul registry, API Server service component, Controller Manager service component, and business modules.

[0014] Furthermore, after the instance of the new version of the ERP system runs normally, register the new service in the registry and modify the load balancing policy service, including:

[0015] Use the ServiceRegister service of the Consul registry to complete the registration of the instance of the new version of the ERP system, and use the Ingress-Control routing to synchronize the access address of the new service to the load balancing policy service in real time.

[0016] Furthermore, uninstalling the instance of the old version of the ERP system from the registry and the load balancing policy service includes:

[0017] Use the Deregister Service service of the Consul registry to uninstall the instance of the old version of the ERP system, and use the API interface provided by the API Server externally called in the preset script to delete the old version example in the serve.

[0018] Furthermore, shutting down the instance of the old version of the ERP system again includes:

[0019] Use the API Server service component to initiate a shutdown command for the instance of the old version of the ERP system;

[0020] After the API interface receives the shutdown command, trigger the Controller Manager service component to call the business module to initiate a shutdown;

[0021] After the business node receives the shutdown command, check whether it is involved in the pre-shutdown operation. If there is a pre-shutdown script and it is checked that the execution is successful, it will no longer accept new web requests. For the requests that have already been received, continue to process them normally. After processing is completed, terminate the application process; for the scheduled tasks executed inside the application, no new scheduled tasks will be started, and wait for all the currently executing scheduled tasks to be completed before terminating the application process.

[0022] Further, initiating a shutdown using the API Server service component includes:

[0023] Write a sh script in Jenkins, use the curl command to call the patch interface, update the replicas field of the old version of the deployment, and change the replicas to 0.

[0024] Further, using the Controller Manager service component to call the business module to initiate a shutdown includes:

[0025] Set the Pod to the Terminating state and remove it from the Endpoints list of all Services;

[0026] Execute the PreStop Hook;

[0027] Send the SIGTERM signal to the containers in the Pod;

[0028] Wait for a specified time for the business module of the old version of the ERP system to shut down. If the business module is still running after the termination grace period, send the SIGKILL signal to force the shutdown of the old version.

[0029] Further, for the scheduled tasks executed inside the application, no new scheduled tasks are started, and wait for all the currently executing scheduled tasks to finish before terminating the application process. Specifically, it includes:

[0030] Obtain multiple thread pools for Quartz task scheduling;

[0031] Repeat multiple rounds of traversing all thread pools to determine if there are tasks. If there are no tasks after repeating multiple rounds of traversing all thread pools, it is determined that all the currently executing scheduled tasks have finished.

[0032] On the other hand, the present invention also discloses an ERP system upgrade device, including a new version startup module, a new service registration module, an old version uninstallation module, and an old version shutdown module, where:

[0033] The new version startup module is used to start a new version of the ERP system instance;

[0034] The new service registration module is used to register the new services corresponding to the new version of the ERP system instance to the registration center and modify the load balancing policy service after the new version of the ERP system instance runs normally;

[0035] The old version uninstallation module is used to uninstall the old version ERP system instance on the registry and the load balancing policy service. For the business requests received in the early stage of the operation of the old version ERP system instance, the new version ERP system instance runs the newly received business requests;

[0036] The old version shutdown module is used to verify the new version ERP system instance. When the old version ERP system instance has processed the previous business requests and the new version ERP system instance passes the verification, then the old version ERP system instance is shut down.

[0037] The beneficial effects of the above technical solutions provided by the embodiments of the present invention at least include:

[0038] In the ERP system upgrade method provided by the embodiments of the present invention, first start the new version ERP system instance. After the new version ERP system instance runs normally, register the new service to the registry and modify the load balancing policy service. At the same time, uninstall the old version ERP system instance on the registry and the load balancing, but the old version ERP system instance does not stop running. After that, the new business requests are taken over by the new version ERP system instance, and the business requests received in the early stage of the operation of the old version ERP system instance are processed. Then, the new version ERP system instance can be verified. After determining through the background program that the old version business has been processed and the new version passes the verification, the old version ERP system instance is shut down. The embodiments of the present invention achieve the uninterrupted business data flow through the customized management data flow without affecting the use of the front-end customers and the call of the back-end interfaces, ensure the business integrity, and complete the graceful upgrade of the version. No additional garbage data or dirty data will be generated during the upgrade process, which does not affect the transaction consistency, and there is no need to make additional business compensation for the upgrade. At the same time, the version upgrade time is greatly shortened.

[0039] The technical solutions of the present invention will be further described in detail below through the drawings and embodiments. Description of the Drawings

[0040] The drawings are used to provide a further understanding of the present invention and constitute a part of the specification. They are used to explain the present invention together with the embodiments of the present invention and do not constitute a limitation to the present invention. In the drawings:

[0041] Figure 1 It is a schematic flow chart of the ERP system upgrade method in the first embodiment;

[0042] Figure 2 It is a schematic diagram of the data flow direction of the entire system during the ERP system upgrade in the first embodiment;

[0043] Figure 3 It is a schematic flow chart of shutting down the old version ERP system instance in step S40 in the first embodiment;

[0044] Figure 4 It is a schematic flowchart of step S402 in Embodiment 1;

[0045] Figure 5 It is a schematic diagram showing the flow direction of the management data stream in Embodiment 1;

[0046] Figure 6 It is a schematic structural diagram of the ERP system upgrade device in Embodiment 2. Detailed implementation manners

[0047] In the following description, specific details such as specific system structures and technologies are presented for the purpose of illustration rather than limitation, so as to thoroughly understand the embodiments of the present application. However, those skilled in the art should clearly understand that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid unnecessary details from interfering with the description of the present application.

[0048] The reference to "one embodiment" or "some embodiments" etc. described in the specification of the present application means that specific features, structures, or characteristics described in connection with the embodiment are included in one or more embodiments of the present application. Thus, the statements "in one embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments", etc. that appear in different places in this specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "comprising", "including", "having", and their variants all mean "including but not limited to", unless otherwise specifically emphasized in other ways. It should be understood that the magnitudes of the sequence numbers of the steps in the following embodiments do not mean the order of execution is prior or posterior, and the execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0049] To illustrate the technical solution of the present application, the present invention first makes a corresponding simple explanation of relevant existing professional terms, and more detailed explanations can be referred to the existing technical documents.

[0050] Kubernetes, abbreviated as K8s or "kube", is an open-source Linux container automated operation and maintenance platform, which eliminates many manual operations involved in the deployment and scaling of containerized applications.

[0051] K8s includes the following basic concepts:

[0052] (1) Master (main node): The machine that controls the Kubernetes nodes and is also the place where job tasks are created.

[0053] (2) Node: These machines execute the assigned tasks under the control of the Kubernetes master node.

[0054] (3) Pod: A collection consisting of one or more containers, deployed as a whole to a single node. Containers within the same pod share the IP address, inter-process communication (IPC), hostname, and other resources. Pod abstracts the network and storage of the underlying containers, making it more convenient to migrate containers within the cluster.

[0055] (4) Service: Separates the service content from the specific pod. The Kubernetes service proxy is responsible for automatically distributing service requests to the correct pod, regardless of where the pod moves within the cluster or even if it is replaced.

[0056] (5) Kubelet: This daemon runs on each worker node and is responsible for obtaining the list of containers and ensuring that the declared containers have been started and are running properly.

[0057] Consul: The registration and discovery process of services in a distributed environment, discovered through HTTP or DNS interfaces. The main interface of Consul is the Restful HTTP API, which can perform basic CRUD operations on objects such as nodes, services, checks, and configurations.

[0058] API Server: An important management API layer in K8s. It is responsible for providing restful API access endpoints and persisting data to the etcd server. In the Kubernetes cluster, the API Server plays the role of an interaction entry point. The API Server is not only responsible for interacting with etcd (other components do not directly operate on etcd, only the API Server does so).

[0059] API Endpoint: When an API interacts with another system, this contact point of the communication is regarded as an endpoint. For an API, an endpoint can include the URL of a server or service. Each endpoint is the location where the API can access the resources required to execute its functions. APIs work using "requests" and "responses". When an API requests information from a web application or web server, it receives a response. The location where the API sends the request and the location where the resources are located are called endpoints.

[0060] An Endpoint is an accessible service endpoint, that is, a pod with a status of running. It is the destination point for service access. Only pods associated with a service can become endpoints.

[0061] Controller Manager: It plays a role in managing and controlling the entire cluster in the Pod workflow. It mainly manages resource objects. When a Pod object running on a Node or the Node itself encounters an accident or failure, Controller Manager will detect and handle it in a timely manner to ensure that the entire cluster is in an ideal working state.

[0062] Jenkins: It is an open-source software project and a continuous integration tool developed based on Java. It is used to monitor continuously repeated tasks and aims to provide an open and easy-to-use software platform for software projects to perform continuous integration.

[0063] Quartz: Quartz is an open-source job scheduling framework written entirely in Java. Its framework includes: job - tasks, Trigger - triggers, Scheduler - task scheduling.

[0064] After introducing some basic concepts, the technical solutions disclosed in the present invention will be described below through specific embodiments.

[0065] The inventor found that in the prior art, after the entire ERP system is launched, in addition to business personnel who operate the front-end page, there are also interface calls for background data synchronization and data distribution. When the online system version is upgraded, the old version should no longer accept new business requests, and the old business requests running on the old version should not be affected either. To achieve this, a common method is to notify all parties of the upgrade time in a timely manner, and the system does not accept business requests during the upgrade time. Therefore, the front-end page module needs to be upgraded during other free time and needs to coordinate dozens of peripheral systems related to the background interface, and the scope to be coordinated is too large. Therefore, the present invention hopes to achieve uninterrupted business data flow through customized management data flow without affecting the use of front-end customers or the interface calls of the back-end, ensuring business integrity and completing graceful upgrade of the version.

[0066] Embodiment 1

[0067] Combined with Figure 1 As shown, an ERP system upgrade method at least includes steps S10 - step S40. For the convenience of understanding, Figure 2It also shows the flow process of the entire system data stream during the ERP system upgrade. The entire system data stream business includes two parts: the business data stream and the management data stream during normal operation. ELB is the abbreviation of Elastic Load Balance, ERP-frontend is the front end of ERP, ERP-basis is the back end of ERP, and ERP-oracle and ERP-redis are both databases. Specifically:

[0068] Step S10, start a new version of the ERP system instance.

[0069] Specifically, the Jenkins integration tool can be used to compile, package, and launch a new version of the ERP system instance, and corresponding deployments are carried out in the Consul registry, API Server service component, Controller Manager service component, and business modules.

[0070] Step S20, after the new version of the ERP system instance runs normally, register the new service corresponding to the new version of the ERP system instance in the registry and modify the load balancing policy service.

[0071] Specifically, the ServiceRegister service of the Consul registry can be used to complete the registration of the new version of the ERP system instance, and the Ingress-Control routing is used to synchronize the access address of the new service to the load balancing policy service in real time.

[0072] The main interface of the Consul registry is the RESTful HTTP API, which can be used to add, delete, query, and modify nodes, services, checks, and configurations.

[0073] The specific implementation of serviceRegister for service registration is as follows:

[0074] / v1 / agent / service / register: Add a new service item to the local agent and transmit a json-formatted data using the PUT method.

[0075] List Services: This endpoint returns the services registered in the given data center.

[0076] / v1 / catalog / service / <service>: List the nodes in a given service.

[0077] The Ingress-Controller is not part of the Controller Manager. It is just one or a group of independent Pod resources, usually an application running with seven-layer proxy capabilities or scheduling capabilities. In this embodiment, it will synchronize the endpoints in the server to the load balancer in real time. After the new version is successfully launched, that is, after the health check passes, the endpoints of the server will be automatically updated. If the old version needs to be taken offline, just call the shutdown interface provided by the API Server, and the endpoints instances corresponding to the old version will be automatically deleted.

[0078] Step S30: Uninstall the old version of the ERP system instance on the registration center and the load balancing policy service. The old version of the ERP system instance processes the business requests received during the early stage of its operation, and the new version of the ERP system instance processes the newly received business requests.

[0079] Specifically, the Deregister Service of the Consul registration center can be used to uninstall the old version of the ERP system instance. By writing a shell script in advance, the API interface provided by the API Server is called in the script to delete the old version example in the serve. In the pipeline, before releasing the new version, call the locally written shell script.

[0080] The specific implementation of Deregister Service to cancel the specified service is:

[0081] / v1 / agent / service / deregister / <serviceid>: Cancel the service item of a local agent

[0082] Write an sh script in Jenkins, use the curl command, first call and then call the API interface to obtain the list of old services and cancel the old services.

[0083] Step S40. Verify the new version of the ERP system instance. When the old version of the ERP system instance has processed the previous business requests and the new version of the ERP system instance passes the verification, then shut down the old version of the ERP system instance.

[0084] Specifically, combined with Figure 3 As shown, when verifying the new version of the ERP system instance, after the old version of the ERP system instance has processed the previous business requests and the new version of the ERP system instance passes the verification, sub-steps S401 - S403 need to be performed to shut down the old version of the ERP system instance, where:[[]]

[0085] Step S401. Use the API Server service component to initiate a shutdown command for the old version of the ERP system instance.

[0086] API Server is the native API of Kubernetes and can be called through the API gateway. Its URL format is: https: / / {clusterid}.Endpoint / uri. Where {clusterid} is the cluster ID and uri is the resource path, that is, the path for API access. At least the following content is involved in the specific implementation:[[]]

[0087] (1) Patch part to update the specified Deployment HTTP request

[0088] PATCH / APIs / apps / v1 / namespaces / {namespace} / deployments / {name}

[0089] (2) replicas (int32) The expected number of Pods. This is a pointer used to distinguish explicit zeros and unspecified values, with a default value of 1.

[0090] An sh script needs to be written in Jenkins. You can use the curl command to call the patch interface to update the replicas field of the old version of the deployment and change replicas to 0.

[0091] Step S402. After the API interface receives the shutdown command, it triggers the Controller Manager service component to call the business module to initiate a shutdown.

[0092] When performing a rolling update in Deployment, once a new version of the Pod is started, the old Pod will be deleted. Once Kubernetes decides to terminate a Pod, a series of events will occur, and it is necessary to synchronize the status of multiple objects (such as Endpoint, Ipvs / iptables, SLB), and these synchronization operations are executed asynchronously.

[0093] When a Pod is deleted, the general life cycle is combined with Figure 4 as shown, including step S4021 - step S4025:

[0094] Step S4021, Pod status change: Set the Pod to the Terminating state and remove it from the Endpoints list of all Services. At this time, the Pod stops receiving new traffic, but the containers running in the Pod are not affected and will continue to process previous requests;

[0095] Step S4022, Execute the PreStop Hook: The PreStop Hook will be triggered when the Pod is deleted. The PreStop Hook supports Bash scripts, TCP, or HTTP requests.

[0096] Step S4023, Send the SIGTERM signal: Send the SIGTERM signal to the containers in the Pod;

[0097] Step S4024, Wait for the specified time: The TerminationGracePeriodSeconds field is used to control the waiting time. In some embodiments, the default value is 30 seconds.

[0098] This step is executed simultaneously with the PreStop Hook. Therefore, TerminationGracePeriodSeconds needs to be greater than the time of the PreStop. Otherwise, the situation may occur that the PreStop is not executed completely and the Pod is stopped (KILL).

[0099] Step S4025, Send the SIGKILL signal: After waiting for the specified time, if the container is still running after the graceful termination grace period, the SIGKILL signal will be sent and the deletion will be forced. At the same time, all Kubernetes objects will also be cleared.

[0100] The steps of the above step S4021 - step S4024 can be carried out simultaneously. Therefore, it is possible that after the Pod receives the SIGTERM signal and stops working, it has not been removed from the Endpoints yet. At this time, the request is forwarded from the Slb to the Pod, but the Pod has stopped working, resulting in a service interruption.

[0101] Therefore, it is necessary to configure a PreStop Hook for the Pod so that when the Pod receives SIGTERM, it calls the instance interface to determine whether the current business has been processed. If not, it waits for a preset time (such as 30 seconds) and then judges again until the processing is completed.

[0102] For the old version that needs to be shut down, it is necessary to ensure that the shutdown does not affect the business, and enough time can be reserved, such as 30 minutes, within which batch operations can also be fully processed.

[0103] In step S403, after the business node receives the shutdown command, it checks whether it is involved in pre-shutdown operations. If there is a pre-shutdown script and the execution is checked to be successful, it no longer accepts new web requests, continues to process the received requests normally, and terminates the application process after processing; for the scheduled tasks executed inside the application, it no longer starts new scheduled tasks and waits for all the currently executing scheduled tasks to be completed before terminating the application process.

[0104] Brutally closing the application, that is, immediately terminating the application after receiving the stop instruction, may cause the global resources held by the process not to be released, and other processes cannot process the business because they cannot obtain the resources. For example, if a certain task needs to obtain a redis lock first and the lock does not set an expiration time, if the task terminates before releasing the lock, the resources will be locked and cannot be processed anymore.

[0105] In order to ensure that the ongoing business operations are not affected after the application process sends the stop instruction, the application process should also wait for the currently executing scheduled tasks to be completed and no longer start new scheduled tasks after receiving the stop instruction. To achieve this goal, at least the following two points should be completed:

[0106] (1) For web interface requests, after the application receives the termination instruction, it no longer accepts new web requests, continues to process the received requests normally, and terminates the application after processing.

[0107] (2) For the scheduled tasks (implemented by Quartz) executed inside the application, no new scheduled tasks are started, and all the currently executing scheduled tasks are waited for to be completed before terminating.

[0108] To terminate the Quartz scheduled tasks, at least multiple thread pools of the Quartz task scheduling need to be obtained. Then, all thread pools are traversed repeatedly to judge whether there are tasks. If no tasks are found after repeatedly traversing all thread pools for multiple rounds, it is judged that all the currently executing scheduled tasks are completed.

[0109] The main idea of ​​the specific implementation is to obtain the thread pool of Quartz and safely terminate the scheduled task by operating the thread pool for safe termination. First, you can manually specify the thread pool of the scheduled task and specify the method to safely close this thread pool. Then traverse each thread pool to check whether each thread pool is completed. If the check finds that all are completed, the counter is increased by 1. As long as there are unfinished ones, the counter is not increased and cleared. Continuously loop, sleep for 1 second each loop, until the counter reaches the preset threshold (for example, the preset threshold is 3, that is, all thread pools are checked in random order three times in a row without any tasks), then it is determined that all the currently executing scheduled tasks have been completed.

[0110] In this embodiment, the thread pool may include at least the following four situations:

[0111] (1)java.util.concurrent.ThreadPoolExecutor: the most commonly used thread pool

[0112] (2)java.util.concurrent.ForkJoinPool: ForkJoin thread pool

[0113] (3) Redis connection pool

[0114] (4)Oracle database connection pool

[0115] In addition, in step S40, if the new version of the ERP system instance fails the verification, steps S10 to S40 are re-executed.

[0116] In the ERP system upgrade method provided by the embodiment of the present invention, the new version ERP system instance is first started. After the new version ERP system instance runs normally, the new service is registered to the registration center, and the load balancing policy service is modified. At the same time, the old version ERP system instance is uninstalled from the registration center and the load balancing, but the old version ERP system instance does not stop running. After that, new business requests are taken over by the new version ERP system instance, and the business requests that have been received in the early stage of the operation of the old version ERP system instance. Then start to verify the new version ERP system instance. After the background program determines that the old version business has been processed and the new version verification has passed, the old version ERP system instance is shut down.

[0117] Compared with the prior art, the upgrade of the new version involves several major steps: informing the relevant parties about the system upgrade and deactivating it; compiling, packaging and launching the new version; taking the old version offline; and rolling back if the test fails. The embodiment of the present invention omits the step of informing the relevant parties about the system upgrade and deactivating it, and optimizes the taking of the old version offline in an automated manner. The system downtime that needs to be manually handled by the operation and maintenance personnel in the prior art is realized in the present invention by calling the API interface of cloud native to first divert the traffic offline and then shut down the system after the business processing is completed. Without affecting the use of the front-end customers or the invocation of the back-end interfaces, the embodiment of the present invention realizes the integrity and continuity of the business data flow during the version update process by customizing the management of the data flow, and completes the graceful upgrade of the version. Figure 5 It shows the flow of the management data flow in the Consul registry, API Server service component, ControllerManager service component, and business module, mainly including the realization of traffic offline for the traffic offline application called by the Jenkins integration tool to the Consul registry; the realization of Pods offline for the API Server called by the Jenkins integration tool; the realization of the shutdown request for the business module called by the Controller manager, etc. Those of ordinary skill in the art can understand that the upgrade of the ERP system of the present invention also involves links such as version code inspection and automated testing, which can all adopt the prior art, so the relevant content is not introduced in detail in this embodiment.

[0118] In addition, in the prior art, there is manual triggering of shutdown, and there are many situations that need to be judged manually, and each business instance is different, so it is easy to make mistakes or be untimely in judgment, which is likely to lead to garbage data and dirty data. However, if the old version can completely process the business request in this application, no garbage data and dirty data will be generated. Therefore, the embodiment of the present invention also has the advantages that no additional garbage data and dirty data will be generated during the upgrade process, the transaction consistency is not affected, no additional business compensation needs to be made for the upgrade, and at the same time, the version upgrade time is greatly shortened.

[0119] Embodiment 2

[0120] The present invention also discloses an ERP system upgrade device, as Figure 6 shown, including a new version startup module 101, a new service registration module 102, an old version uninstallation module 103, and an old version shutdown module 104, where:

[0121] The new version startup module 101 is used to start a new version of the ERP system instance.

[0122] Specifically, the new version startup module 101 is used to compile, package, and go live with the new version of the ERP system instance using the Jenkins integration tool, and perform corresponding deployments in the Consul registry, API Server service component, Controller Manager service component, and business module.

[0123] The new service registration module 102 is used to register the new service corresponding to the new version of the ERP system instance to the registry and modify the load balancing policy service after the new version of the ERP system instance runs normally.

[0124] Specifically, the new service registration module 102 is used to complete the registration of the new version of the ERP system instance using the ServiceRegister service of the Consul registry, and synchronize the access address of the new service to the load balancing policy service in real time using Ingress-Control routing.

[0125] The old version uninstallation module 103 is used to uninstall the old version of the ERP system instance on the registry and the load balancing policy service. For the business requests received during the early stage of the operation of the old version of the ERP system instance, the new version of the ERP system instance runs the newly received business requests.

[0126] Specifically, the old version uninstallation module 103 is used to uninstall the old version of the ERP system instance using the Deregister Service service of the Consul registry. By writing a shell script through preset settings, the API interface provided by the API Server is called in the script to delete the old version example in the serve. In the pipeline, before releasing the new version, the locally written shell script is called.

[0127] The old version shutdown module 104 is used to verify the new version of the ERP system instance. After the old version of the ERP system instance has processed the previous business requests and the new version of the ERP system instance passes the verification, the old version of the ERP system instance is shut down.

[0128] Specifically, the old version shutdown module 104 is used to verify the new version ERP system instance. When the old version ERP system instance has processed the previous business requests and the new version ERP system instance passes the verification, it uses the API Server service component to initiate a shutdown command for the old version ERP system instance. It is also used to trigger the ControllerManager service component to call the business module to initiate a shutdown after the API interface receives the shutdown command. It is also used to check whether it is involved in pre-shutdown operations after the business node receives the shutdown command. If there is a pre-shutdown script and the execution is checked to be successful, it will no longer accept new web requests, continue to process the requests that have already been received normally, and then terminate the application process after processing; for the scheduled tasks executed inside the application, it will no longer start new scheduled tasks and wait for all the currently executing scheduled tasks to finish before terminating the application process.

[0129] The implementation steps of each module of this ERP system upgrade device can be referred to in Embodiment 1 and will not be elaborated here.

[0130] The ERP system upgrade device provided by the embodiment of the present invention first starts the new version ERP system instance. After the new version ERP system instance runs normally, it registers the new service to the registry center and modifies the load balancing policy service. At the same time, it unloads the old version ERP system instance from the registry center and the load balancer, but the old version ERP system instance does not stop running. After that, the new business requests are taken over by the new version ERP system instance, and the old version ERP system instance processes the business requests that have been received in the early stage of its operation. Then, it can start to verify the new version ERP system instance. After determining through the background program that the old version business has been processed and the new version passes the verification, the old version ERP system instance is shut down. The embodiment of the present invention realizes the uninterrupted business data flow through the customized management data flow without affecting the use of the front-end customers and the call of the back-end interfaces, ensures the business integrity, and completes the graceful upgrade of the version. No additional garbage data or dirty data will be generated during the upgrade process, which does not affect the transaction consistency and does not require additional business compensation for the upgrade. At the same time, the version upgrade time is greatly shortened.

[0131] Embodiment 3

[0132] Based on the same inventive concept, the embodiment of the present invention also discloses a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, it implements the ERP system upgrade method of steps S10 - S40 in Embodiment 1.

[0133] Embodiment 4

[0134] Based on the same inventive concept, an embodiment of the present invention also discloses a computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it implements the ERP system upgrade method of steps S10 - S40 in Embodiment 1.

[0135] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memories and optical memories, etc.) containing computer-usable program code.

[0136] The present invention is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present invention. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, as well as the combination of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate means for implementing the specified functions in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0137] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured article including instruction means, and the instruction means implements the specified functions in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0138] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process. Thus, the instructions executed on the computer or other programmable device provide steps for implementing the specified functions in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0139] Obviously, those skilled in the art can make various modifications and variations to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalent technologies, the present invention is also intended to include these modifications and variations.< / serviceid> < / service>

Claims

1. An ERP system upgrade method, characterized in that, At least include the following steps: Use the Jenkins integration tool to compile, package, and go live with a new version of the ERP system instance, and perform corresponding deployments in the Consul registry, API Server service component, Controller Manager service component, and business modules to start the new version of the ERP system instance; After the new version of the ERP system instance runs normally, register the new service corresponding to the new version of the ERP system instance with the registry and modify the load balancing policy service; Use the Deregister Service service of the Consul registry to uninstall the old version of the ERP system instance, and use the API interface provided by the API Server externally called in the preset script to delete the old version instance in the server. The business requests received in the early stage of the operation of the old version of the ERP system instance, and the new business requests received by the new version of the ERP system instance are processed; Verify the new version of the ERP system instance. When the old version of the ERP system instance has processed the previous business requests and the new version of the ERP system instance passes the verification, use the API Server service component to initiate a shutdown command for the old version of the ERP system instance; Among them, after the API interface provided by the API Server receives the shutdown command, set the minimum scheduling unit Pod in the system to the Terminating state and delete it from the Endpoints list of all Services; execute the PreStop Hook; send a SIGTERM signal to the container in the minimum scheduling unit Pod; wait for a specified time for the business module of the old version of the ERP system to shut down. If the business module is still running after the termination grace period, send a SIGKILL signal to force the old version to shut down, where the specified time is greater than the PreStop time; After the business node receives the shutdown command, check whether it is involved in pre-shutdown operations. If there is a pre-shutdown script and it is checked that the execution is successful, it will no longer accept new web requests. For the requests that have been received, continue to process them normally, and then terminate the application process after processing; for the scheduled tasks executed internally by the application, no new scheduled tasks will be started, and wait for all the currently executing scheduled tasks to complete before terminating the application process.

2. The ERP system upgrade method according to claim 1, characterized in that, After the new version of the ERP system instance runs normally, registering the new service with the registry and modifying the load balancing policy service includes: Use the ServiceRegister service of the Consul registry to complete the registration of the new version of the ERP system instance, and use Ingress-Control routing to synchronize the access address of the new service to the load balancing policy service in real time.

3. The ERP system upgrade method according to claim 1, characterized in that, The use of the API Server service component to initiate a shutdown command for the old version of the ERP system instance includes: Write a shell script in Jenkins, use the curl command to call the patch interface, and update the replicas field of the old version of the deployment to change the replicas to 0.

4. The ERP system upgrade method according to claim 1, characterized in that, For the scheduled tasks executed inside the application, no new scheduled tasks are started, and all currently executing scheduled tasks are waited for to complete before terminating the application process. Specifically, it includes: Obtain multiple thread pools for Quartz task scheduling; Traverse all thread pools repeatedly in multiple rounds to determine if there are tasks. If no tasks are found after repeatedly traversing all thread pools in multiple rounds, it is determined that all currently executing scheduled tasks have been completed.

5. The ERP system upgrade method according to claim 1, characterized in that, The ERP system upgrade method also includes that if the verification of the new version of the ERP system instance fails, the steps of starting the new version of the ERP system instance and subsequent steps are re-executed.

6. An ERP system upgrade device, characterized in that, It includes a new version startup module, a new service registration module, an old version uninstallation module, and an old version shutdown module, where: The new version startup module is used to compile, package, and go online the new version of the ERP system instance using the Jenkins integration tool, and perform corresponding deployments in the Consul registration center, API Server service component, Controller Manager service component, and business module to start the new version of the ERP system instance; The new service registration module is used to register the new service corresponding to the new version of the ERP system instance to the registration center and modify the load balancing policy service after the new version of the ERP system instance runs normally; The old version uninstallation module is used to uninstall the old version of the ERP system instance using the Deregister Service service of the Consul registration center, call the API interface provided externally by the API Server using a preset script to delete the old version instance in the server, handle the business requests received in the early stage of the operation of the old version of the ERP system instance, and handle the newly received business requests by the new version of the ERP system instance; The old version shutdown module is used to verify the new version of the ERP system instance. When the old version of the ERP system instance has processed the previous business requests and the verification of the new version of the ERP system instance passes, use the API Server service component to initiate a shutdown command for the old version of the ERP system instance; Among them, after receiving the shutdown command by the API interface provided externally by the API Server, set the smallest scheduling unit Pod in the system to the Terminating state and delete it from the Endpoints list of all Services; execute the PreStop Hook; send the SIGTERM signal to the containers in the smallest scheduling unit Pod; wait for a specified time for the business module of the old version of the ERP system to shut down. If the business module is still running after the termination grace period, send the SIGKILL signal to force the old version to shut down, where the specified time is greater than the PreStop time; After the service node receives the shutdown command, it checks whether it is involved in pre-shutdown operations. If there is a pre-shutdown script and the execution is checked to be successful, it will no longer accept new web requests. For the requests that have already been received, it will continue to process them normally and then terminate the application process after the processing is completed. For the scheduled tasks executed within the application, no new scheduled tasks will be started, and it will wait for all the currently executing scheduled tasks to be completed before terminating the application process.

7. A computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, it implements the ERP system upgrade method according to any one of claims 1-5.

8. A computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, and when the processor executes the computer program, it implements the ERP system upgrade method according to any one of claims 1-5.

Images