System hot update method and device based on Java and Grouping and medium

Abstract

The invention discloses a system hot update method and device based on Java and Grouping and a medium. Comprising the steps that a main system code corresponding to a main system is stored in a first Git warehouse, a service code is stored in a second Git warehouse, the main system is developed based on a Java Spring Boot framework, the service code is written based on a Grooven language, and the second Git warehouse comprises all Grooven scripts and script names thereof; the method comprises the following steps: under the condition that a main system receives an http request, analyzing request body information of the http request to obtain a business code field and a service code field associated with the http request, and splicing the business code field and the service code field associated with the http request to obtain a first script name; the method comprises the following steps: calling a tool class Groomy Util, querying a first Groomy script matched with a first script name and a version number of the first Groomy script in a cache, pulling a second Groomy script which is matched with the first script name and is the latest version from a second Git warehouse, compiling the second Groomy script based on a Groomy ClassLoader, and loading the compiled second Groomy script into the cache for execution.

Description

Technical Field

[0001] The present application relates to the field of software development technology, in particular to the field of hot update technology, and in particular to a system hot update method, device and medium based on Java and Groovy. Background Art

[0002] In the field of modern software development, continuous integration and continuous deployment (CI / CD) strategies have become the core methods to improve development efficiency and ensure product quality. The traditional software update process usually involves rebuilding and deploying the entire application, which is not only time-consuming but also has high risks. New errors may be introduced due to improper operation, affecting the stability and reliability of the system.

[0003] With the continuous evolution of technical architecture, microservice architecture and containerization technology are becoming increasingly popular, and hot update technology has emerged. Its core advantage is that it can implement code updates without interrupting application operation, greatly improving the availability and flexibility of the system.

[0004] However, when hot update strategies are currently implemented in scripting languages ​​such as Python and JavaScript, although these scripting languages ​​are highly flexible and easy to write, they are often inconsistent with the programming language of the main system, resulting in additional complexity and maintenance costs during the integration and debugging process, and may also cause potential compatibility issues, posing a hidden danger to the stable operation of the system. Summary of the invention

[0005] In view of this, the embodiments of the present application provide a system hot update method, device, equipment, medium and product based on Java and Groovy, which can use Groovy scripts to be compatible with the Java main system, reduce additional development and maintenance costs, and improve system stability.

[0006] In a first aspect, an embodiment of the present application provides a system hot update method based on Java and Groovy, the method comprising: storing a main system code corresponding to the main system in a first Git repository, storing a business code in a second Git repository, and writing the repository address information and authentication information of the second Git repository in a configuration file of the main system, wherein the main system is developed based on a Java Spring Boot framework, the business code is written based on the Groovy language, and the second Git repository contains various Groovy scripts and their script names, and the script names are generated based on the business code field and the service code field in the corresponding Groovy script; when the main system receives an http request, parsing the request body information of the http request to obtain the business code field and the service code field associated with the http request, and splicing the business code field and the service code field associated with the http request to obtain the first script name; by calling the tool class Groovy Util, querying the cache for a first Groovy script and its version number that matches the first script name, if the version number of the first Groovy script is not the latest version, accessing the second Git repository based on the repository address information and the authentication information, wherein Groovy Util is used to manage the life cycle of each Groovy script; by calling GroovyUtil, a second Groovy script matching the name of the first script and the latest version is pulled from the second Git repository, and the second Groovy script is compiled based on GroovyClassLoader and loaded into the cache for execution.

[0007] In a second aspect, an embodiment of the present application provides a system hot update device based on Java and Groovy, the device comprising: a configuration module, used to store the main system code corresponding to the main system in a first Git repository, store the business code in a second Git repository, and write the warehouse address information and authentication information of the second Git repository in the configuration file of the main system, wherein the main system is developed based on the Java Spring Boot framework, the business code is written based on the Groovy language, and the second Git repository contains various Groovy scripts and their script names, and the script names are generated based on the business code field and the service code field in the corresponding Groovy script; a parsing module, used to parse the request body information of the http request when the main system receives an http request, obtain the business code field and the service code field associated with the http request, and splice the business code field and the service code field associated with the http request to obtain the first script name; a query module, used to query the first Groovy script and its version number matching the first script name in the cache by calling the tool class Groovy Util, if the version number of the first Groovy script is not the latest version, then access the second Git repository based on the warehouse address information and the authentication information, wherein Groovy Util is used to manage the life cycle of each Groovy script; the execution module is used to pull the second Groovy script that matches the name of the first script and is the latest version from the second Git repository by calling GroovyUtil, and compile the second Groovy script based on GroovyClassLoader and load it into the cache for execution.

[0008] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the steps of the system hot update method based on Java and Groovy as in the first aspect are implemented.

[0009] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having computer program instructions stored thereon. When the computer program instructions are executed by a processor, the steps of the Java and Groovy-based system hot update method of the first aspect are implemented.

[0010] In a fifth aspect, an embodiment of the present application provides a computer program product, which is stored in a non-volatile storage medium, and when the computer program product is executed by a processor, implements the steps of the Java and Groovy-based system hot update method as in the first aspect.

[0011] In a sixth aspect, an embodiment of the present application provides a chip, which includes a processor and a communication interface, wherein the communication interface and the processor are coupled, and the processor is used to run programs or instructions to implement the steps of the Java and Groovy-based system hot update method as in the first aspect.

[0012] The present application provides a method, device, equipment, medium and product for hot updating of a system based on Java and Groovy. The main system is developed based on the Java Spring Boot framework, and the business code is written based on the Groovy language. The second Git repository can contain various Groovy scripts and their script names, and the life cycle of each Groovy script is managed by Groovy Util. Based on this, when the main system receives an http request, the request body information of the http request is parsed to obtain the business code field and the service code field associated with the http request, and the business code field and the service code field associated with the http request are spliced ​​to obtain the first script name. By calling the tool class Groovy Util, the first Groovy script and its version number matching the first script name are queried in the cache. If the version number of the first Groovy script is not the latest version, the second Git repository is accessed based on the warehouse address information and authentication information, and the second Groovy script matching the first script name and the latest version is pulled from the second Git repository by calling Groovy Util, and the second Groovy script is compiled based on GroovyClassLoader and loaded into the cache for execution. In this way, the use of Groovy scripts is effectively compatible with the Java main system, reducing development and maintenance costs. It can also reduce the workload when converting existing Java codes into Groovy scripts. Groovy scripts execute quickly and can be easily expanded and modified without introducing significant performance overhead, and can also adapt to different business needs. The script name is generated based on the business code field and service code field in the corresponding Groovy script, so that each external request can correctly find and execute the corresponding Groovy script. In addition, in order to ensure the stability and security of the system, before each execution of the Groovy script, it is verified whether it is the latest version. If not, the update process will be automatically triggered. When the new Groovy script is pulled and compiled, the GroovyUtil tool class will automatically load the latest business logic into memory. Once the script update is completed, all subsequent requests will be executed using the latest business code without any manual intervention or service restart, which improves the flexibility and responsiveness of the system and enables changes in business needs to be quickly implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the technical solution of the embodiments of the present application, the following briefly introduces the drawings in the embodiments of the present application.

[0014] Figure 1 It is a flowchart of a system hot update method based on Java and Groovy provided in an embodiment of the present application;

[0015] Figure 2 It is a system architecture diagram of a system hot update method based on Java and Groovy provided in one embodiment of the present application;

[0016] Figure 3 is a flowchart of a system hot update method based on Java and Groovy provided in another embodiment of the present application;

[0017] Figure 4 It is a structural diagram of a system hot update device based on Java and Groovy provided in an embodiment of the present application;

[0018] Figure 5 It is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0019] The principles and spirit of the present application will be described below with reference to several exemplary embodiments. It should be understood that the purpose of providing these embodiments is to make the principles and spirit of the present application clearer and more thorough, so that those skilled in the art can better understand and implement the principles and spirit of the present application. The exemplary embodiments provided herein are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments herein, all other embodiments obtained by ordinary technicians of the art without creative work are within the scope of protection of this application.

[0020] In this document, terms such as first, second, third, etc. are only used to distinguish one entity (or operation) from another entity (or operation), but not to require or imply any order or relationship between these entities (or operations).

[0021] The following is a brief description of the concepts and technical terms that may be involved in the embodiments of the present application.

[0022] Spring Boot, a rapid development tool based on the Spring framework, simplifies the initial setup and development process of new Spring applications.

[0023] Groovy, a scripting language based on the Java platform, has concise syntax and powerful functions.

[0024] Git, an open source distributed version control system for tracking and coordinating changes to computer files.

[0025] HTTPS URL is a Uniform Resource Locator (URL) with HTTPS protocol, which is used to identify and locate resources on the Internet. HTTPS is a secure version of Hypertext Transfer Protocol (HTTP) and is used to protect data transmission security.

[0026] An SSH address is a network address used for SSH (Secure Shell) connections. SSH is an encrypted network protocol used to securely transmit data in an insecure network. An SSH address usually includes the server's IP address, port number, and username.

[0027] The following is a detailed description of the Java and Groovy-based system hot update method provided in the embodiment of the present application through specific embodiments and application scenarios in conjunction with the accompanying drawings.

[0028] Figure 1 It is a flow chart of a system hot update method based on Java and Groovy provided in an embodiment of the present application. The executor of the system hot update method based on Java and Groovy may be a business system. The business system may include a main system and a Git server. The Git server is used to maintain a first Git repository and a second Git repository.

[0029] In one example, the business system may be a business system of an online recruitment platform.

[0030] The following takes the execution subject of the system hot update method based on Java and Groovy as a business system as an example to illustrate the system hot update method based on Java and Groovy of the present application. It should be noted that the above execution subject and application scenario do not constitute a limitation on the present application.

[0031] like Figure 1 As shown, the Java and Groovy-based system hot update method provided in the embodiment of the present application may include steps 110 to 140.

[0032] Step 110, storing the main system code corresponding to the main system in the first Git warehouse, storing the business code in the second Git warehouse, and writing the warehouse address information and authentication information of the second Git warehouse into the configuration file of the main system;

[0033] Step 120, when the main system receives the http request, parse the request body information of the http request to obtain the business code field and the service code field associated with the http request, and concatenate the business code field and the service code field associated with the http request to obtain the first script name;

[0034] Step 130, by calling the tool class Groovy Util, querying the cache for a first Groovy script and its version number that matches the first script name, and if the version number of the first Groovy script is not the latest version, accessing the second Git repository based on the repository address information and the authentication information;

[0035] Step 140: by calling Groovy Util, pull a second Groovy script that matches the name of the first script and is the latest version from the second Git repository, compile the second Groovy script based on GroovyClassLoader, and load it into the cache for execution.

[0036] The system hot update method based on Java and Groovy provided in the embodiment of the present application develops the main system based on the Java SpringBoot framework, writes the business code based on the Groovy language, and the second Git warehouse can contain various Groovy scripts and their script names, and manages the life cycle of each Groovy script through Groovy Util. Based on this, when the main system receives an http request, the request body information of the http request is parsed to obtain the business code field and service code field associated with the http request, and the business code field and service code field associated with the http request are spliced ​​to obtain the first script name. By calling the tool class Groovy Util, the first Groovy script and its version number matching the first script name are queried in the cache. If the version number of the first Groovy script is not the latest version, the second Git warehouse is accessed based on the warehouse address information and authentication information, and the second Groovy script matching the first script name and the latest version is pulled from the second Git warehouse by calling Groovy Util, and the second Groovy script is compiled based on GroovyClassLoader and loaded into the cache for execution. In this way, the use of Groovy scripts is effectively compatible with the Java main system, reducing development and maintenance costs. It can also reduce the workload when converting existing Java codes into Groovy scripts. Groovy scripts execute quickly and can be easily expanded and modified without introducing significant performance overhead, and can also adapt to different business needs. The script name is generated based on the business code field and service code field in the corresponding Groovy script, so that each external request can correctly find and execute the corresponding Groovy script. In addition, in order to ensure the stability and security of the system, before each execution of the Groovy script, it is verified whether it is the latest version. If not, the update process will be automatically triggered. When the new Groovy script is pulled and compiled, the GroovyUtil tool class will automatically load the latest business logic into memory. Once the script update is completed, all subsequent requests will be executed using the latest business code without any manual intervention or service restart, which improves the flexibility and responsiveness of the system and enables changes in business needs to be quickly implemented.

[0037] The specific implementation of the above steps will be described in detail below in conjunction with specific embodiments.

[0038] Involving step 110, the main system code corresponding to the main system is stored in the first Git warehouse, the business code is stored in the second Git warehouse, and the warehouse address information and authentication information of the second Git warehouse are written into the configuration file of the main system.

[0039] In step 110, the main system is developed based on the Java Spring Boot framework. The development process may include: introducing all packages of the main system, developing the tool class GroovyUtil, defining the OutController class and the CoreApi implementation class, defining a first interface for receiving the Git hook notification of the second Git repository, defining a second interface for managing the receiving status of the Git hook notification of the second Git repository, defining a third interface for actively pulling the Groovy script in the second Git repository, and defining a script status query interface.

[0040] In some embodiments, before step 110, you can use the Spring Initializr website or other tools to initialize a springboot project, introduce commonly used spring-boot-starter, spring-boot-starter-web, spring-boot-starter-actuator, fastjson, commons-io, springfox-swagger2, springfox-swagger-ui and other packages, plus the groovy-all package required by this project, plus some necessary packages required by the business system such as log link, database, etc., to introduce all the packages of the main system.

[0041] The business code is written in Groovy language. The second Git repository contains various Groovy scripts and their script names. The script names are generated based on the business code field and the service code field in the corresponding Groovy script.

[0042] The main system needs to be able to access the second Git repository that stores the business code. Therefore, the repository address information and authentication information of the second Git repository must be correctly configured in the configuration file of the main system. Specifically, it may include:

[0043] Repository address configuration: Specify the HTTPS URL or SSH address of the secondary Git repository in the configuration file of the primary system (such as application.properties or application.yml).

[0044] Authentication information configuration: Provide the necessary authentication credentials based on the selected authentication method (such as username / password, SSH key, or OAuth token). For a more secure approach, it is recommended to use environment variables or a dedicated credential management service to store sensitive information instead of hard-coding it directly in the configuration file.

[0045] For example, the configuration file is application.properties, and the configuration process is as follows:

[0046] #Git repository configuration

[0047] git.repo.url=https: / / github.com / example / business-scripts.git

[0048] git.repo.branch=main

[0049] git.repo.auth.type=oauth #may be basic, ssh, oauth, etc.

[0050] git.repo.oauth.token = ${GIT_OAUTH_TOKEN} #Use environment variables.

[0051] In this way, by integrating the Git repository, an automated hot update process is realized, which improves development efficiency. By separating the main system code and business code into different Git repositories for management, code separation is achieved, making modifications and updates to specific parts easier to track and manage, further improving development efficiency.

[0052] In some embodiments of the present application, the second Git repository may also include status information and metadata information of each Groovy script, wherein the status information is used to indicate whether the Groovy script has been loaded by the system, and can be specifically divided into: Unloaded: the script has not been loaded by the system, Loaded: the script has been successfully loaded into the memory, but has not yet been executed.

[0053] Metadata information can include:

[0054] Version number (Version): can be a Git commit hash or version tag, used to identify the specific version of the script; Last Updated time (Last Updated): the timestamp of the last time it was pulled and updated from the second Git repository; Next Check Time (Next Check Time): the next check time of the scheduled task used to check version updates; Compile Time (Compile Time): the time of the last successful compilation; Execution Count (Execution Count): the number of executions since the last compilation; Last Execution Time (Last Execution Time): the timestamp of the last execution; Execution Result (Execution Result): a summary of the execution results of the most recent execution (success / failure); Error Info (ErrorInfo): if there is an error, a specific error message or stack trace is provided.

[0055] Thus, for each Groovy script, in addition to its status, some metadata information can be recorded to help better understand the current specific situation of the Groovy script.

[0056] In some embodiments of the present application, the status information and metadata information of the Groovy script can be obtained by calling the script status query interface, which allows the user to query the status of a specific script or all scripts, including but not limited to whether it has been loaded, the time of the last update, the current version number and other information, which is very useful for understanding the script situation within the system.

[0057] When the files in the second Git repository change, the update process will be triggered. Therefore, the status judgment logic of the script status query interface includes:

[0058] Git change detection: Checks whether new commits have arrived at the specified Git branch. If so, it is marked as "outdated" and waits for update.

[0059] Compilation process monitoring: During compilation, it is set to the "Compiling" state; after compilation is completed, it is changed to "Compiled" or "Error" depending on the result.

[0060] Cache consistency check: Before each attempt to execute a Groovy script, check whether the Groovy script version in the cache is consistent with the latest version in the second Git repository. If not, reload and compile.

[0061] Involving step 120, when the main system receives an http request, the request body information of the http request is parsed to obtain the business code field and the service code field associated with the http request, and the business code field and the service code field associated with the http request are spliced ​​to obtain the first script name.

[0062] In step 120, the main system can process the http request by calling the OutController class. The OutController class is a controller located in the com.dffl.fuman.controller package. It processes external requests by mapping URL paths and HTTP methods, and calls the service layer method to execute business logic, and finally returns the response result. The OutController class defines the member variables CoreApi, outCommonHandle method, and getCoreReqDTO method. The outCommonHandle method is defined in the CoreApi implementation class. Therefore, step 120 can be performed by calling the outCommonHandle method, the getCoreReqDTO method, and the outCommonHandle method.

[0063] Specifically, the controller is located in the package com.dffl.fuman.controller. The controller is used to process external requests, convert request parameters into CoreReqDTO objects, and then call CoreApi to process specific business logic.

[0064] When defining the OutController class, use the @RestController annotation to mark this as a RESTful-style controller; use the @Slf4j annotation to automatically generate logging functions; use the @Api annotation to mark this as a Swagger-documented API; use the @RequestMapping annotation to specify that the request is mapped to the / backend path; use the @SuppressWarnings("all") annotation to ignore all warnings.

[0065] Member variable CoreApi: automatically injected core API manager, used to process business logic.

[0066] The outCommonHandle method is a method for processing external requests. It is used to receive request parameters CoreParmReqMap, business code bizCode, and interface code serviceCode; obtain the original request body (raw body) from the HTTP request and convert it into a JSON object; combine the request parameters and the request body into a CoreReqDTO object; call the CoreApi.outCommonHandle method to process business logic and return the result; record logs and output the message content returned to the outside.

[0067] The getCoreReqDTO method is a method for generating a CoreReqDTO object. It is used to read the original request body from the HTTP request and try to parse it into a JSON object; fill the CoreReqDTO object according to the URL path parameters and query parameters; if the request body contains necessary information, directly use this information to fill the CoreReqDTO; return the constructed CoreReqDTO object.

[0068] The outCommonHandle method is used to stitch out the key of the script to be found based on the business code bizCode field and the interface code serviceCode field in the CoreReqDTO object, and is used to query the script to be executed in GroovyUtil. After the script is found, the executeScript method of GroovyUtil is called to pass in parameters to execute the script.

[0069] In some embodiments of the present application, business codes and service codes are embedded in the script name so as to directly correspond to specific business requests. For example, for a service named createOrder with business code ORDER, the script can be named ORDER_createOrder.groovy. When the main interface receives an external request, it will parse out the key request parameters, business code bizCode and service code serviceCode, and then build the corresponding script name based on these parameters, and call GroovyUtil to find and execute the corresponding Groovy script. GroovyUtil will first check whether the latest version of the Groovy script exists in the cache; if it exists, it will be executed directly; otherwise, the script content of the latest Groovy script will be pulled from the second Git repository, compiled, stored in the cache and then executed.

[0070] In this way, a clear naming convention is defined for each Groovy script. The script name of the Groovy script is constructed by combining the business code field and the service code field in the request. This not only helps to organize and classify Groovy scripts, but also supports the automated Groovy script search and matching process, which can effectively improve the update efficiency during the hot update process.

[0071] In step 130, by calling the tool class Groovy Util, the cache is queried for a first Groovy script and its version number that matches the first script name. If the version number of the first Groovy script is not the latest version, the second Git repository is accessed based on the repository address information and authentication information.

[0072] In step 130 , GroovyUtil is used to manage the life cycle of each Groovy script.

[0073] In some embodiments of the present application, in order to develop the tool class GroovyUtil, before the above step 130, the method may further include the following steps:

[0074] Define Groovy Util in the main system. Groovy Util contains member variables cacheMap, cacheClassMap, executeScript method and updateScript method.

[0075] The executeScript method is used to: execute the Groovy script with the specified script name in the second Gi repository; obtain the MD5 value and corresponding class of the Groovy script from the cache; throw an exception if the Groovy script with the specified script name is not found; create a new Groovy script instance and set the binding object; run the Groovy script and return the result;

[0076] The updateScript method is used to: update the Groovy script with the specified script name in the second Gi repository; calculate the MD5 value of the updated Groovy script; if the MD5 values ​​of the Groovy script before and after the update are the same, use the class in the cache; if the MD5 values ​​of the Groovy script before and after the update are different, recompile the updated Groovy script and update the cache; clear the class of the Groovy script before the update.

[0077] Groovy Util uses ConcurrentHashMap to cache the contents of Groovy scripts and compiled classes.

[0078] cacheMap is used to cache key-value pairs of Groovy scripts. The key is the script name and the value is the MD5 value of the script content.

[0079] cacheClassMap is used to cache compiled classes of Groovy scripts. The key is the MD5 value of the script content and the value is the compiled class.

[0080] In an embodiment of the present application, a tool class GroovyUtil is developed to store and call Groovy scripts. GroovyUtil can receive parameters of external requests, pass in the script name and parameters for execution. In this way, the life cycle of the Groovy script is managed by relying on the GroovyUtil tool class, including loading, executing, and updating as needed. It can effectively execute and update the Groovy script to ensure that each business logic update can take effect immediately.

[0081] In step 140, by calling Groovy Util, a second Groovy script matching the name of the first script and being the latest version is pulled from the second Git repository, and the second Groovy script is compiled based on GroovyClassLoader and loaded into the cache for execution.

[0082] In step 140 , the second Groovy script that matches the name of the first script and is the latest version is pulled from the second Git repository by calling the executeScript method and the updateScript method in the Groovy Util.

[0083] For example, assume that the business system is processing an order creation request. At this time, the client sends an HTTP POST request to the / backend / order / create path, and the request body contains the business code ORDER and the service code createOrder. According to the above logic, the main system will construct a script name ORDER_createOrder.groovy, and use GroovyUtil to find and execute the corresponding script. If the script exists and is the latest version, it will be executed immediately and the result will be returned; if the script does not exist or is not the latest version, it will be updated before execution.

[0084] This not only simplifies the management and maintenance of scripts, but also enhances the flexibility and responsiveness of the system, ensuring timely updating and correct execution of business logic.

[0085] After step 140, the updated business code takes effect immediately without restarting the main system. When the new Groovy script is pulled and compiled, the GroovyUtil tool class automatically loads the latest business logic into memory. This means that once the script is updated, all subsequent requests will be executed using the latest business code without any manual intervention or service restart. This instant response capability greatly improves the flexibility and responsiveness of the system, allowing changes in business requirements to be quickly implemented.

[0086] Furthermore, since the main system does not need to be restarted, the existing business will not be disturbed during the update process, ensuring the continuity and stability of the service. This is especially important for business systems that need to run 24 / 7. In addition, by dynamically loading and unloading scripts, we can easily perform A / B testing or grayscale releases, further enhancing the availability and reliability of the system.

[0087] In some embodiments of the present application, before step 110, the method may further include: defining a first interface for receiving a Git hook notification of a second Git repository in the main system, wherein the first interface includes member variables webhookSecret and gitRepoInfo, and interface methods handleWebhookRequest and GroovyUtil.updateScript;

[0088] In this way, when the business code in the second Git repository changes, the main system of this application receives the Webhook notification sent by the second Git repository through the first interface, and receives the HTTP POST request by calling handleWebhookRequest and then parses it to obtain the commit ID and branch name; based on the preset webhookSecret, the signature is extracted from the request header of the HTTP POST request for verification; if the verification passes, the target Git branch is determined based on the commit ID and branch name, and the latest Groovy script is pulled from the target Git branch of the second Git repository, and compiled and cached by calling GroovyUtil.updateScript.

[0089] Among them, webhookSecret is used to verify the key of the source of Git Webhook notification to ensure that only authorized Git servers can trigger updates; gitRepoInfo is an object containing configuration items such as Git repository address and branch information, which is used to specify the repository and branch to be monitored.

[0090] In the embodiment of the present application, an interface for receiving Webhook notifications from the second Git repository is developed in the main system to obtain a first interface. When a file in the business code library is changed, the Git server automatically sends an HTTP POST request to the first interface to inform the main system of the change. In this way, after the main system receives the Webhook notification, it can immediately trigger the script update process to ensure that the business logic is always up to date.

[0091] In some embodiments of the present application, before step 110, the following may be included: defining a second interface for managing the reception status of the Git hook notification of the second Git repository in the main system, wherein the second interface includes member variables webhookStatus, lastUpdatedBy, and statusChangeLog, and interface methods toggleWebhookReception and getCurrentStatus;

[0092] In this way, during large-scale deployment or system maintenance, the present application can receive a Boolean parameter by calling toggleWebhookReception, and adjust the webhookStatus from ENABLED to DISABLED based on the Boolean parameter, where the Boolean parameter is used to indicate the closure of Webhook notification reception; obtain the current Webhook notification reception status by calling getCurrentStatus, and return an object containing webhookStatus, lastUpdatedBy, and statusChangeLog.

[0093] Among them, webhookStatus represents the enumeration of the current Webhook notification receiving status (such as ENABLED, DISABLED), and the default is ENABLED; lastUpdatedBy records the operator information who last changed this status, including the user name and operation timestamp; statusChangeLog is a list used to record the historical records of each status change, including information such as the status before and after the change, the change time, and the operator.

[0094] toggleWebhookReception is used to: receive a Boolean parameter enabled, indicating whether Webhook notification reception is enabled or disabled; update the webhookStatus member variable and set lastUpdatedBy to reflect the change; add the status change to statusChangeLog for later review; return a new response object containing the latest webhookStatus and other relevant information, such as the time and user of the last update.

[0095] getCurrentStatus is used to obtain the current Webhook notification reception status and return an object containing webhookStatus, lastUpdatedBy, and statusChangeLog.

[0096] In an embodiment of the present application, by defining a second interface in the main system and managing whether the main system receives Webhook notifications from the second Git repository, a simple method is provided to enable or disable automatic update triggers, so that the administrator can adjust the system update policy according to actual conditions. For example, during large-scale deployment or system maintenance, notification reception can be temporarily turned off to prevent unnecessary script updates from interfering with normal business processes. Before planned downtime for maintenance, the administrator can turn off Webhook notification reception by calling this interface, thereby preventing any unexpected hot updates from occurring. After the maintenance is completed, call the interface again to re-enable Webhook notification reception and resume normal operation. When abnormally frequent update requests or other potential problems are detected, notification reception is quickly turned off as a temporary countermeasure, and then restored after the problem is resolved.

[0097] It should be noted that before and after switching the Webhook receiving status, it is recommended to send a notification email or message to the relevant team to ensure that everyone is aware of the current status change. The statusChangeLog should be reviewed regularly to monitor for unauthorized status change activities. If the system receives new Webhook notifications while in the DISABLED state, these events can be recorded, but no further action is taken until the state is set back to ENABLED.

[0098] In some embodiments of the present application, before step 110, the following may be included: defining a third interface for actively pulling the Groovy script in the second Git repository in the main system, wherein the third interface includes member variables branchOrTag and forceUpdate, and an interface method pullAndDeployScripts, branchOrTag is used to indicate the Git branch name to be pulled, and forceUpdate is used to indicate whether to force update the existing Groovy script;

[0099] In this way, the application can automatically update the Groovy script in the second Git repository by calling pullAndDeployScripts.

[0100] Among them, branchOrTag is used to specify the Git branch name or tag name to be pulled, the default is the main branch; forceUpdate is a Boolean value used to indicate whether to force update of the existing script, even if no new commits are detected, the default is false.

[0101] In the embodiment of the present application, a third interface is defined in the main system, which allows the administrator or automation tool to actively call to pull the Groovy script of the specified branch or tag version from the second Git repository. In this way, a flexible way is provided for users to manually trigger business code updates when necessary without waiting for notifications from Git hooks.

[0102] In some embodiments of the present application, the above-mentioned automatic update of the Groovy script in the second Git repository by calling pullAndDeployScripts may include the following steps:

[0103] By calling pullAndDeployScripts, based on the URL and branch name of the second Git repository entered by the user, use Git commands to clone the second Git repository to the main system, or update the existing local copy to the latest status;

[0104] The file processing module based on the file system operation command or programming language traverses all files in the specified directory and filters out files with the file extension .groovy;

[0105] For each .groovy file traversed, use the updateScript method in GroovyUtil to check and update each Groovy script one by one;

[0106] When performing the update operation on each Groovy script, use the logging tool to record the result of each operation, timestamp, status change of each Groovy script, and exception information;

[0107] Returns a list of script names of Groovy scripts that were successfully updated, and exception information for each Groovy script that failed to update as a response object.

[0108] In an embodiment of the present application, taking into account changes in business requirements, the third interface is redefined in the main system, and a dynamic update mechanism is implemented by calling the third interface, allowing the system to manually synchronize the latest business code when necessary without waiting for notification from the Git hook, providing a flexible way for administrators or automation tools to actively trigger Groovy script updates to ensure that the business logic is always up to date. In this way, not only is the dynamic loading and execution of business code achieved, but it also ensures that each update can be smoothly transitioned without affecting the normal operation of the existing business logic. At the same time, such an architecture improves the flexibility and maintainability of the system, allowing developers to quickly respond to changes in business requirements.

[0109] The third interface supports on-demand deployment, so users can choose to update only certain specific scripts or the contents of the entire repository, and simplifies the script management process by directly connecting to the Git version control system.

[0110] It should be noted that before executing the automated update process of the Groovy script, you need to confirm that there is enough disk space to clone or update the repository, ensure that you have appropriate permissions to access the remote Git repository, and that the authentication information is correctly configured. Considering the possibility of concurrent requests, a locking mechanism should be implemented to avoid data competition problems caused by multiple update requests at the same time.

[0111] In some embodiments of the present application, the method may further include:

[0112] Only when an authorized user initiates a script update request, the Groovy script in the second Git repository is updated, and during the script update process, the change details, operation source, execution status, and impact scope of the Groovy script are recorded;

[0113] The change details include the script name, version number, and update timestamp. The operation source is used to indicate whether the Webhook notification is triggered or triggered manually. The execution status is used to record the results of compilation and execution, including success or failure and the exception information encountered. The impact scope is used to indicate the business modules and service modules affected by the update operation.

[0114] For example, assume that the business system is processing an order creation request. At this time, the development team submits an optimized order creation logic to the Git repository. After the system detects this change, it automatically triggers the update process: Read the Git change log: The system recognizes that the ORDER_createOrder.groovy file has changed; Download the updated script file: Download the latest ORDER_createOrder.groovy content from the Git repository; Calculate the new and old MD5 values: Compare the content differences between the new and old scripts to confirm that there are indeed modifications; Compile and load the script: Use GroovyClassLoader to recompile the script and load it into memory; Update the cache: Store the latest version of the script in the cache of GroovyUtil; Record the log: Record key information of the entire update process, including but not limited to the script name, version number, compilation time, and any problems encountered.

[0115] Then, the client sends an HTTP POST request to the / backend / order / create path. According to the above logic, the main system will construct the script name ORDER_createOrder.groovy and use GroovyUtil to find and execute the corresponding latest script. If the script is the latest version, it will be executed immediately and the result will be returned; if it is not the latest version, it will be updated first and then executed.

[0116] In the embodiment of the present application, Git is used as the version control system to manage the code, which not only provides powerful history and branch management functions, but also supports efficient collaboration between teams. Whenever a new business logic is submitted to the Git warehouse, the system will automatically detect the changes and trigger the update process. This ensures that all business codes are strictly version controlled, and any changes can be traced back to the specific time point and responsible person, which greatly facilitates problem troubleshooting and responsibility definition. All operations involving Groovy script updates must undergo strict permission verification, and only authorized users can initiate update requests. In addition, for sensitive operations (such as forced updates), we will additionally require secondary confirmation and clearly mark these operations in the log. Such a design not only ensures the security of the system, but also provides strong support for post-review. During the script update process, the change details, operation source, execution status, and impact range of the Groovy script are recorded, so that the log can fully and detailedly record the entire update process of the Groovy script, ensure the security and transparency of the update process, and implement a comprehensive logging mechanism, which provides a solid guarantee for the security and traceability of the system.

[0117] As a specific example, Figure 2 : is a system architecture diagram of a system hot update method based on Java and Groovy provided in an embodiment of the present application, such as Figure 2 As shown, the user initiates an HTTP request to the main system (Java Spring Boot). After receiving the HTTP request, OutController in the main system converts the request parameters into a CoreReqDTO object, and then calls CoreApi to process the specific business logic. Specifically, the business code bizCode and interface code serviceCode fields in the CoreReqDTO object are used to stitch together the key of the script to be found, which is used to find the script to be executed / updated in GroovyUtil, and pull the latest business code from the business code repository Git (i.e., the second Git repository) maintained by the Git server. In addition, the Git server can also actively trigger GroovyUtil to update the Groovy script through Webhook notification.

[0118] Figure 3FIG. 1 is a flow chart of a method for hot updating a system based on Java and Groovy provided in another embodiment of the present application. Figure 3 As shown, in the solution provided by the embodiment of the present application, when the client initiates an HTTP request to the main system, the main system parses the request after receiving it, and searches for and executes the Groovy script based on the script name obtained by the parsing. The search operation specifically queries the Groovy script from the cache. If the queried Groovy script is the latest version, the cached script or result is directly returned. If the queried Groovy script is not the latest version, the script cache is updated, and the updated script or result is returned. In addition, the Git server can also actively trigger script updates through Webhook notifications, and information such as update records can be written into the record log as log information.

[0119] It should be noted that, for the Java and Groovy-based system hot update method provided in this application, the scripting language may use other JVM-based scripting languages, such as Scala, Kotlin, etc., in addition to Groovy; other version control systems may be used in addition to Git, such as SVN; the script execution method may use other Groovy script execution methods, such as GroovyClassLoader, in addition to GroovyShell; the update triggering method may also trigger updates through API calls or other events in addition to scheduled tasks.

[0120] Corresponding to the method embodiment of the present application, the present application also provides a system hot update device based on Java and Groovy.

[0121] Figure 4 Schematic diagram of a Java and Groovy-based system hot update device provided in an embodiment of the present application. Figure 4 As shown, the Java and Groovy-based system hot update device 400 may include: a configuration module 410 , a parsing module 420 , a query module 430 , and an execution module 440 .

[0122] Among them, the configuration module 410 is used to store the main system code corresponding to the main system in the first Git warehouse, store the business code in the second Git warehouse, and write the warehouse address information and authentication information of the second Git warehouse in the configuration file of the main system, wherein the main system is developed based on the Java Spring Boot framework, the business code is written based on the Groovy language, and the second Git warehouse contains various Groovy scripts and their script names, and the script names are generated based on the business code field and the service code field in the corresponding Groovy script; the parsing module 420 is used to parse the request body information of the http request when the main system receives an http request, obtain the business code field and the service code field associated with the http request, and splice the business code field and the service code field associated with the http request to obtain the first script name; the query module 430 is used to query the first Groovy script and its version number matching the first script name in the cache by calling the tool class Groovy Util. If the version number of the first Groovy script is not the latest version, the second Git warehouse is accessed based on the warehouse address information and the authentication information, wherein Groovy Util is used to manage the life cycle of each Groovy script; the execution module 440 is used to pull the second Groovy script that matches the first script name and is the latest version from the second Git repository by calling Groovy Util, and compile the second Groovy script based on GroovyClassLoader and load it into the cache for execution.

[0123] The system hot update device based on Java and Groovy provided in the embodiment of the present application develops the main system based on the Java SpringBoot framework, writes the business code based on the Groovy language, and the second Git warehouse can contain various Groovy scripts and their script names, and manages the life cycle of each Groovy script through Groovy Util. Based on this, when the main system receives an http request, the request body information of the http request is parsed to obtain the business code field and service code field associated with the http request, and the business code field and service code field associated with the http request are spliced ​​to obtain the first script name. By calling the tool class Groovy Util, the first Groovy script and its version number matching the first script name are queried in the cache. If the version number of the first Groovy script is not the latest version, the second Git warehouse is accessed based on the warehouse address information and authentication information, and the second Groovy script matching the first script name and the latest version is pulled from the second Git warehouse by calling Groovy Util, and the second Groovy script is compiled based on GroovyClassLoader and loaded into the cache for execution. In this way, the use of Groovy scripts is effectively compatible with the Java main system, reducing development and maintenance costs. It can also reduce the workload when converting existing Java codes into Groovy scripts. Groovy scripts execute quickly and can be easily expanded and modified without introducing significant performance overhead, and can also adapt to different business needs. The script name is generated based on the business code field and service code field in the corresponding Groovy script, so that each external request can correctly find and execute the corresponding Groovy script. In addition, in order to ensure the stability and security of the system, before each execution of the Groovy script, it is verified whether it is the latest version. If not, the update process will be automatically triggered. When the new Groovy script is pulled and compiled, the GroovyUtil tool class will automatically load the latest business logic into memory. Once the script update is completed, all subsequent requests will be executed using the latest business code without any manual intervention or service restart, which improves the flexibility and responsiveness of the system and enables changes in business needs to be quickly implemented.

[0124] In some embodiments of the present application, the second Git repository also contains status information and metadata information of each Groovy script, wherein the status information is used to indicate whether the Groovy script has been loaded by the system, and the metadata information includes the version number, the timestamp of the last time it was pulled and updated from the second Git repository, the next check time of the scheduled task for checking version updates, the time of the most recent successful compilation, the number of executions since the last compilation, the timestamp of the last execution, and the summary of the execution results of the most recent execution.

[0125] In some embodiments of the present application, it also includes: a configuration module, which is used to define a first interface in the main system for receiving Git hook notifications from the second Git repository, wherein the first interface includes member variables webhookSecret and gitRepoInfo, and interface methods handleWebhookRequest and GroovyUtil.updateScript; a parsing module, which is used for, when the business code in the second Git repository changes, the main system receives the Webhook notification sent by the second Git repository through the first interface, and receives the HTTP POST request by calling handleWebhookRequest and then parses it to obtain the commit ID and branch name; a verification module, which is used to extract the signature from the request header of the HTTPPOST request for verification based on the preset webhookSecret; a pulling module, which is used to determine the target Git branch based on the commitID and branch name when the verification passes, and pull the latest Groovy script from the target Git branch of the second Git repository, and compile and cache update by calling GroovyUtil.updateScript.

[0126] In some embodiments of the present application, it also includes: a configuration module, which is used to define a second interface in the main system for managing the reception status of Git hook notifications of the second Git repository, wherein the second interface includes member variables webhookStatus, lastUpdatedBy and statusChangeLog, and interface methods toggleWebhookReception and getCurrentStatus; an adjustment module, which is used to receive a Boolean parameter by calling toggleWebhookReception during large-scale deployment or system maintenance, and adjust webhookStatus from ENABLED to DISABLED based on the Boolean parameter, wherein the Boolean parameter is used to indicate the closing of Webhook notification reception; a calling module, which is used to obtain the current Webhook notification reception status by calling getCurrentStatus, and return an object including webhookStatus, lastUpdatedBy and statusChangeLog.

[0127] In some embodiments of the present application, it also includes: a configuration module, which is used to define a third interface in the main system for actively pulling the Groovy script in the second Git repository, wherein the third interface contains member variables branchOrTag and forceUpdate, and an interface method pullAndDeployScripts, branchOrTag is used to indicate the Git branch name to be pulled, and forceUpdate is used to indicate whether to force the existing Groovy script to be updated; an update module, which is used to automatically update the Groovy script in the second Git repository by calling pullAndDeployScripts.

[0128] In some embodiments of the present application, the update module is specifically used to: by calling pullAndDeployScripts, according to the URL and branch name of the second Git repository input by the user, use the Git command to clone the second Git repository to the main system, or update the existing local copy to the latest status; based on the file system operation command or the file processing module of the programming language, traverse all files in the specified directory and filter out files with the file extension .groovy; for each .groovy file traversed, use the updateScript method in GroovyUtil to check and update each Groovy script one by one; in the process of performing the update operation on each Groovy script, use the logging tool to record the result of each step of the operation, the timestamp, the state change of each Groovy script, and the exception information; return the script name list of the Groovy scripts that have been updated successfully, and the exception information for each Groovy script that failed to update as a response object.

[0129] In some embodiments of the present application, it also includes: an update module, which is used to update the Groovy script in the second Git repository only when an authorized user initiates a script update request, and record the change details, operation source, execution status, and impact scope of the Groovy script during the script update process; wherein the change details include the script name, version number, and update timestamp, the operation source is used to indicate the Webhook notification trigger or manual trigger, the execution status is used to record the results of compilation and execution, including success or failure and encountered exception information, and the impact scope is used to indicate the business modules and service modules affected by the update operation.

[0130] In some embodiments of the present application, Groovy Util uses ConcurrentHashMap to cache the content of the Groovy script and the compiled class, and also includes: a configuration module for defining Groovy Util in the main system before searching the cache for a first Groovy script and its version number matching the first script name by calling the tool class Groovy Util, Groovy Util contains member variables cacheMap, cacheClassMap, and executeScript method and updateScript method; among them, the executeScript method is used to: execute the Groovy script with the specified script name in the second Gi repository; obtain the MD5 value and corresponding class of the Groovy script from the cache; if the Groovy script with the specified script name is not found, throw an exception; create a new Groovy script instance and set the binding object; run the Groovy script and return the result; the updateScript method is used to: update the Groovy script with the specified script name in the second Gi repository; calculate the MD5 value of the updated Groovy script; if the MD5 values ​​of the Groovy script before and after the update are the same, use the class in the cache; if the MD5 values ​​of the Groovy script before and after the update are different, recompile the updated Groovy script and update the cache; clear the class of the Groovy script before the update.

[0131] The Java and Groovy-based system hot update device provided in the embodiment of the present application can achieve Figure 1-3 The various processes implemented by the service platform in the method embodiment can achieve the same technical effect. To avoid repetition, they will not be described here.

[0132] Figure 5 It is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application.

[0133] like Figure 5 As shown, the electronic device 500 includes a memory 501 , a processor 502 , and a computer program stored in the memory 501 and executable on the processor 502 .

[0134] In an example, the processor 502 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0135] The memory 501 may include a read-only memory (ROM), a random access memory (RAM), a disk storage medium device, an optical storage medium device, a flash memory device, an electrical, optical or other physical / tangible memory storage device. Therefore, generally, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., a memory device) encoded with software including computer executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the system hot update method based on Java and Groovy in the embodiment according to the first aspect of the present application.

[0136] The processor 502 runs a computer program corresponding to the executable program code by reading the executable program code stored in the memory 501, so as to implement the Java and Groovy-based system hot update method in the embodiment of the first aspect.

[0137] In some examples, the electronic device 500 may further include a communication interface 503 and a bus 510. Figure 5 As shown, the memory 501, the processor 502, and the communication interface 503 are connected via a bus 510 and communicate with each other.

[0138] The communication interface 503 is mainly used to realize the communication between the modules, devices, units and / or equipment in the embodiment of the present application. The communication interface 503 can also be used to access input devices and / or output devices.

[0139] The bus 510 includes hardware, software, or both, coupling the components of the electronic device 500 to each other. By way of example and not limitation, the bus 510 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a Memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-E) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses or a combination of two or more of these. Where appropriate, the bus 510 may include one or more buses. Although embodiments of the present application describe and illustrate a particular bus, the present application contemplates any suitable bus or interconnect.

[0140] The electronic device provided in the embodiment of the present application can realize Figure 1-3 The various processes implemented by the electronic device in the method embodiment can achieve the same technical effect, and to avoid repetition, they will not be described here.

[0141] In combination with the Java and Groovy-based system hot update method in the above embodiment, the present application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when the computer program instructions are executed by a processor, the steps of any one of the Java and Groovy-based system hot update methods in the above embodiment are implemented.

[0142] In combination with the Java and Groovy-based system hot update method in the above embodiment, the present application embodiment can provide a computer program product for implementation. The (computer) program product is stored in a non-volatile storage medium, and when the program product is executed by at least one processor, it implements the steps of any one of the Java and Groovy-based system hot update methods in the above embodiment.

[0143] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, wherein the communication interface and the processor are coupled, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned Java and Groovy-based system hot update method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0144] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0145] It should be clear that the present application is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present application is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present application.

[0146] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware or a combination thereof. When implemented in hardware, it can be, for example, an electronic circuit, an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), appropriate firmware, plug-in, function card, etc. When implemented in software, the elements of the present application are programs or code segments used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. The code segment can be downloaded via a computer network such as the Internet, an intranet, etc.

[0147] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps, that is, the steps can be performed in the order mentioned in the embodiment, or in a different order from the embodiment, or several steps can be performed simultaneously.

[0148] Aspects of the present disclosure are described above with reference to the flowchart and / or block diagram of the method, device (system) and computer program product according to the embodiment of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine so that these instructions executed by the processor of the computer or other programmable data processing device enable the implementation of the function / action specified in one or more boxes of the flowchart and / or block diagram. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field programmable logic circuit. It can also be understood that each box in the block diagram and / or flowchart and the combination of boxes in the block diagram and / or flowchart can also be implemented by dedicated hardware that performs a specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0149] The above is only a specific implementation of the present application. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the protection scope of the present application is not limited to this. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in this application, and these modifications or replacements should be included in the protection scope of this application.

Claims

1. A system hot update method based on Java and Groovy, characterized in that: include: The main system code corresponding to the main system is stored in the first Git warehouse, the business code is stored in the second Git warehouse, and the warehouse address information and authentication information of the second Git warehouse are written in the configuration file of the main system, wherein the main system is developed based on the Java Spring Boot framework, the business code is written based on the Groovy language, and the second Git warehouse contains various Groovy scripts and their script names, and the script names are generated based on the business code field and the service code field in the corresponding Groovy script; When the main system receives a hypertext transfer protocol (http) request, the request body information of the http request is parsed to obtain a business code field and a service code field associated with the http request, and the business code field and the service code field associated with the http request are concatenated to obtain a first script name; By calling the tool class Groovy Util, querying the cache for a first Groovy script and its version number that matches the first script name, if the version number of the first Groovy script is not the latest version, accessing the second Git repository based on the repository address information and the authentication information, wherein the Groovy Util is used to manage the life cycle of each Groovy script; By calling Groovy Util, a second Groovy script matching the first script name and being the latest version is pulled from the second Git repository, and the second Groovy script is compiled based on GroovyClassLoader and loaded into the cache for execution.

2. The method according to claim 1, characterized in that The second Git repository also contains status information and metadata information of each Groovy script, wherein the status information is used to indicate whether the Groovy script has been loaded by the system, and the metadata information includes the version number, the timestamp of the last time it was pulled from the second Git repository and updated, the next check time of the scheduled task for checking version updates, the last successful compilation time, the number of executions since the last compilation, the timestamp of the last execution, and the summary of the execution results of the most recent execution.

3. The method according to claim 1, characterized in that Also includes: A first interface for receiving the Git hook notification of the second Git repository is defined in the main system, wherein the first interface includes member variables webhookSecret and gitRepoInfo, and interface methods handleWebhookRequest and GroovyUtil.updateScript; When the business code in the second Git repository is changed, the main system receives the Webhook notification sent by the second Git repository through the first interface, and receives the HTTP POST request by calling handleWebhookRequest and then parses it to obtain the commit ID and branch name; Extract the signature from the HTTP POST request header for verification based on the preset webhookSecret; If the verification passes, the target Git branch is determined based on the commit ID and the branch name, and the latest Groovy script is pulled from the target Git branch of the second Git repository, and compiled and cached by calling GroovyUtil.updateScript.

4. The method according to claim 3, characterized in that Also includes: A second interface for managing the receiving status of the Git hook notification of the second Git repository is defined in the main system, wherein the second interface includes member variables webhookStatus, lastUpdatedBy and statusChangeLog, and interface methods toggleWebhookReception and getCurrentStatus; During large-scale deployment or system maintenance, calling toggleWebhookReception to receive a Boolean parameter, and adjusting webhookStatus from ENABLED to DISABLED based on the Boolean parameter, wherein the Boolean parameter is used to indicate that webhook notification reception is turned off; Get the current Webhook notification reception status by calling getCurrentStatus, and return an object containing webhookStatus, lastUpdatedBy, and statusChangeLog.

5. The method according to claim 1, characterized in that Also includes: A third interface for actively pulling the Groovy script in the second Git repository is defined in the main system, wherein the third interface includes member variables branchOrTag and forceUpdate, and an interface method pullAndDeployScripts, branchOrTag is used to indicate the name of the Git branch to be pulled, and forceUpdate is used to indicate whether to force update the existing Groovy script; The Groovy script in the second Git repository is automatically updated by calling pullAndDeployScripts.

6. The method according to claim 5, characterized in that The Groovy script in the second Git repository is automatically updated by calling pullAndDeployScripts, including: By calling pullAndDeployScripts, based on the URL and branch name of the second Git repository entered by the user, use Git commands to clone the second Git repository to the main system, or update the existing local copy to the latest status; The file processing module based on the file system operation command or programming language traverses all files in the specified directory and filters out files with the file extension .groovy; For each .groovy file traversed, use the updateScript method in GroovyUtil to check and update each Groovy script one by one; When performing the update operation on each Groovy script, use the logging tool to record the result of each operation, timestamp, status change of each Groovy script, and exception information; Returns a list of script names of Groovy scripts that were successfully updated, and exception information for each Groovy script that failed to update as a response object.

7. The method according to claim 1, characterized in that Also includes: Only when an authorized user initiates a script update request, the Groovy script in the second Git repository is updated, and during the script update process, the change details, operation source, execution status, and impact scope of the Groovy script are recorded; Among them, the change details include the script name, version number, and update timestamp. The operation source is used to indicate whether it is triggered by a Webhook notification or manually. The execution status is used to record the results of compilation and execution, including success or failure and the exception information encountered. The impact scope is used to indicate the business modules and service modules affected by the update operation.

8. The method according to claim 1, characterized in that Groovy Util uses ConcurrentHashMap to cache the content of the Groovy script and the compiled class. Before searching the cache for the first Groovy script and its version number that match the first script name by calling the tool class Groovy Util, the method further includes: Define Groovy Util in the main system. Groovy Util contains member variables cacheMap, cacheClassMap, executeScript method and updateScript method. The executeScript method is used to: execute the Groovy script with the specified script name in the second Gi repository; obtain the MD5 value and corresponding class of the Groovy script from the cache; throw an exception if the Groovy script with the specified script name is not found; create a new Groovy script instance and set the binding object; run the Groovy script and return the result; The updateScript method is used to: update the Groovy script with the specified script name in the second Gi repository; calculate the MD5 value of the updated Groovy script; if the MD5 values ​​of the Groovy script before and after the update are the same, use the class in the cache; if the MD5 values ​​of the Groovy script before and after the update are different, recompile the updated Groovy script and update the cache; clear the class of the Groovy script before the update.

9. An electronic device, characterized in that: The electronic device comprises: a processor and a memory storing computer program instructions; when the electronic device executes the computer program instructions, the method according to any one of claims 1 to 8 is implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images