Method, device and equipment for updating module in scripting language application program of server and computer readable storage medium

Abstract

The invention provides a method, device and equipment for updating a module in a scripting language application program of a server, a computer program product and a computer readable storage medium, and the method comprises the steps: modifying a built-in module import mechanism of the scripting language application program to intercept a loading request for a target module; the proxy module is returned to the scripting language application program, and codes of the target module are asynchronously loaded according to metadata obtained from the remote module management and control platform to serve as execution entities of the proxy module; in response to a version updating instruction for the target module, obtaining a code of a new version specified by the version updating instruction, and clearing an instance related to an old version of the target module in a module cache in the scripting language application program; the internal reference of the proxy module is updated such that the internal reference points to the newly loaded instance of the new version established based on the code of the new version. According to the method and the device, the dynamic updating of the module during operation can be realized under the condition that the service is not restarted.

Description

Technical Field

[0001] This application relates to computer and internet technology, and more particularly to a method, apparatus, device, computer-readable storage medium, and computer program product for updating modules in a scripting language application on a server. Background Technology

[0002] In modern server-side application development, runtime applications such as Node.js are widely used. To improve code reusability and development efficiency, developers typically encapsulate common business logic or functionality into independent software modules (such as npm packages). Server-side applications then use these modules to build complete business systems.

[0003] Typically, during the build or startup phase, server-side applications read and load these dependent modules from a local disk directory (such as node_modules). When the code of a module needs to be changed (e.g., business rule adjustments or feature iterations), applications that depend on that module usually follow a pre-defined release process: developers update dependency configurations, re-download and install the new version of the module, rebuild the application, and restart the service process or redeploy the application instance. During application runtime, the module code loaded in memory maintains the version state corresponding to when the service started. Summary of the Invention

[0004] This application provides a method, apparatus, computer-readable storage medium, and computer program product for updating modules in a scripting language application on a server, which enables dynamic runtime updates of target modules without restarting the application.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides a method for updating modules in a scripting language application on a server, wherein the scripting language application integrates a software development kit, and the method includes: The software development kit performs the following update steps: Modify the module import mechanism built into the scripting language application to intercept loading requests for the target module issued by the scripting language application; The proxy module is returned to the scripting language application, and the code of the target module is asynchronously loaded based on the metadata obtained from the remote module management platform, so as to serve as the execution entity of the proxy module; In response to a version update instruction for the target module, the following update processes are performed: obtaining the code of the new version specified by the version update instruction; clearing instances related to the old version of the target module from the module cache within the scripting language application; and updating the internal references of the proxy module so that the internal references point to the newly loaded instance of the new version built based on the new version of the code.

[0006] This application provides an apparatus for updating modules in a scripting language application on a server, wherein a software development kit is integrated into the scripting language application, and the apparatus includes: The software development kit performs the following module update process: The interception unit is used to modify the module import mechanism built into the scripting language application to intercept the loading request for the target module issued by the scripting language application. The loading unit is used to return a proxy module to the scripting language application and asynchronously load the code of the target module based on the metadata obtained from the remote module management platform, so as to serve as the execution entity of the proxy module; An update unit is configured to, in response to a version update instruction for the target module, perform the following update processes: obtain the code of the new version specified by the version update instruction; clear instances related to the old version of the target module from the module cache within the scripting language application; and update the internal references of the proxy module so that the internal references point to the newly loaded instance of the new version built based on the new version of the code.

[0007] In the above scheme, the interception unit is further configured to: when the scripting language application starts, obtain its built-in module path resolution function as the original resolution function and save it, and replace the original resolution function with a new resolution function; wherein, the new resolution function is configured to: when the loading request is intercepted, if the target module targeted by the loading request does not exist in the preset micro-module mapping relationship, call the original resolution function to load the local module; if the target module exists in the micro-module mapping relationship, execute the step of returning the proxy module to the scripting language application.

[0008] In the above scheme, the interception unit is further configured to: call the initialization interface provided by the software development kit before the core business logic of the scripting language application starts, wherein the initialization interface is configured to receive the micro-module mapping relationship as input parameters, trigger the first asynchronous loading of all target modules in the micro-module mapping relationship, and wait for all the asynchronous loading tasks to be completed before ending the execution.

[0009] In the above scheme, the interception unit is further configured to: write the proxy module into the module cache of the scripting language application after returning the proxy module; and write the local module into the module cache of the scripting language application after loading the local module.

[0010] In the above scheme, the loading unit is further configured to: establish a persistent communication link with the remote module management platform, through which the version update instruction can be received.

[0011] In the above scheme, the version update instruction is received from the remote module management platform, and before executing the update process, the loading unit is further configured to: make an update decision based on preset custom rules, wherein the custom rules include canary release rules or version locking rules; if the update decision result indicates acceptance of this version update, the update process continues to be executed; if the update decision result indicates rejection, the update process is terminated.

[0012] In the above scheme, the loading unit is further configured to: when the proxy module is loaded for the first time, the software development kit dynamically generates it locally according to the template and stores it in a preset proxy module directory.

[0013] In the above scheme, the metadata in the loading unit is stored in a metadata file, which at least includes: application data and version data; the version data includes: product version number, root path of resource server and path list of all code files of target module.

[0014] In the above scheme, the update unit is further configured to: query the new version of the code from the local cache; if the new version of the code is not found, download the new version of the code from the resource server and store the new version of the code in the local cache in a versioned manner; if the new version of the code is found, directly use the new version of the code in the local cache.

[0015] In the above scheme, after storing the new version of the code in the local cache in a versioned manner, the update unit is further configured to: check the number of version directories in the local cache; if the number of version directories exceeds a preset limit, remove at least one of the oldest version directories so that the number of version directories in the local cache does not exceed the preset limit.

[0016] In the above scheme, the instance of the new version based on the new version of the code in the update unit is a module object exported after the new version of the code is executed by the module loading function of the scripting language application.

[0017] In the above scheme, before asynchronously loading the code of the target module, the loading unit is further configured to: check the status of the asynchronous loading task for the target module; if the asynchronous loading task is in progress, suspend the current loading request to put it into a waiting state until the asynchronous loading task is completed; if the asynchronous loading task is not in progress, start the asynchronous loading task for the code.

[0018] In the above scheme, the loading unit is further configured to: when the proxy module receives a call request from the scripting language application, query the internal reference maintained within the software development kit that points to the latest version of the real module instance through the proxy module, and forward the call request to the latest version of the real module instance for execution through the internal reference.

[0019] In the above scheme, when the target module is a shared business module that is simultaneously depended on by multiple scripting language application projects, after the code of the target module is changed, the update unit is further configured to: publish the changed code of the target module to the remote module management platform, and in each scripting language application, the software development kit performs the module update process.

[0020] In the above scheme, the loading unit further includes an end-to-end workflow covering both the module provider and the module user. This end-to-end workflow includes: a module preparation workflow executed by the module provider, which includes: initializing a micro-module project via a command-line tool and writing source code within the micro-module project; executing a build command to generate a package body as the release form of the target module, the package body having dual identities, including a traditional module artifact for static reference and a micro-module artifact for dynamic loading, the micro-module artifact containing at least a metadata file; and publishing the dual-identity package body to a package manager repository. The module integration workflow executed by the module user includes: installing the package body from the package manager repository as the target module; and in the scripting language application, calling the interface provided by the software development kit to establish a mapping relationship between the name of the target module and the micro-module artifact.

[0021] In the above scheme, the version update instruction of the update unit is generated and sent by the remote module management platform after receiving the version change operation issued through the visual interface, or the version update instruction is generated by the internal code of the scripting language application by calling the version switching interface provided by the software development kit to request the loading of a specific version of the target module.

[0022] This application provides an electronic device, the electronic device comprising: Memory is used to store executable instructions or computer programs. When a processor executes computer-executable instructions or computer programs stored in the memory, it implements a method for updating modules in a scripting language application on a server, as provided in this application embodiment.

[0023] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing, when executed by a processor, a method for updating modules in a scripting language application on a server, as provided in this application.

[0024] This application provides a computer program product, including a computer program or computer-executable instructions. When the computer program or computer-executable instructions are executed by a processor, they implement a method for updating modules in a scripting language application on a server, as provided in this application.

[0025] The embodiments of this application have the following beneficial effects: By integrating a software development kit (SDK) into a scripting language application, this application intercepts loading requests for the target module and returns a proxy module. Using the proxy module as a stable access interface, the application's calls are decoupled from the specific module code implementation. Simultaneously, combined with a metadata-based asynchronous loading mechanism, and operations such as obtaining new code, clearing old version caches, and updating internal references of the proxy module in response to version update commands, it is possible to load the new version of the code in real-time while the application remains running and seamlessly switch the execution entity of the proxy module to the new version instance. This approach enables runtime dynamic updates of the target module in the server-side scripting language environment, ensuring service continuity while achieving real-time iteration of business logic. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the system architecture of a method for updating modules in a scripting language application on a server, provided in an embodiment of this application. Figure 2 This is a schematic diagram of the structure of an update module device in a scripting language application on a server, provided in an embodiment of this application. Figure 3A This is a first flowchart illustrating a method for updating a module in a scripting language application on a server, as provided in an embodiment of this application. Figure 3B This is a second flowchart illustrating a method for updating a module in a scripting language application on a server, as provided in an embodiment of this application. Figure 3C This is a third flowchart illustrating a method for updating a module in a scripting language application on a server, as provided in an embodiment of this application. Figure 3D This is a fourth flowchart illustrating a method for updating a module in a scripting language application on a server, as provided in an embodiment of this application. Figure 4 This is a first flowchart illustrating the module dynamic update method provided in this application embodiment; Figure 5 This is a second flowchart illustrating the module dynamic update method provided in this application embodiment; Figure 6 This is a schematic diagram of the helpack architecture provided in the embodiments of this application; Figure 7 This is a schematic diagram of the module construction product provided in the embodiments of this application; Figure 8 This is a schematic diagram of the application store interface of the module management platform provided in this application embodiment; Figure 9 This is a schematic diagram of the traditional mode release process provided in the embodiments of this application; Figure 10 This is a schematic diagram of the micro-module mode release process provided in the embodiments of this application; Figure 11 This is a schematic diagram of the core entity relationships and interaction principles provided in the embodiments of this application.

[0027] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0029] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0030] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0031] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0032] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0033] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0034] 1) JavaScript: A lightweight, interpreted or just-in-time (JIT) compiled programming language with function-first characteristics. In this application, JavaScript is the primary language for writing server-side business logic, shared modules, and the hel-micro-node SDK. It runs within the Node.js application and carries the logic implementation and interaction of modules.

[0035] 2) Node.js: An open-source, cross-platform JavaScript runtime environment built on the Chrome V8 engine, which allows developers to run JavaScript code on the server side. For example, the "Node service" in this application runs in a Node.js application and uses its module system (such as CommonJS) to load and execute dynamically updated micro-modules.

[0036] 3) JavaScript modules: These are code units imported and used in Node.js applications. They typically encapsulate specific business logic or utility functions. By default, Node.js searches for and loads these modules from the node_modules directory on the local disk. For example, a "pricing module" or "user authentication module" in an e-commerce system might exist as a static file in the traditional model, but in this application, it can be promoted to a micro-module that supports dynamic updates.

[0037] 4) Node Package Manager (NPM): This is the default package management tool for Node.js. Users can download packages from remote repositories and install them into the node_modules directory of their local project using command-line tools. For example, during the initialization phase of this application, the developer used the `npm install` command to install the hel-micro-node SDK and the initial versions of the business modules.

[0038] 5) Node Service: This refers to a server-side application written in Node.js, used to handle network requests or execute background tasks. For example, in a microservice architecture, a standalone "order service" or "product service" is a Node service, which integrates the SDK of this application to enable updates of dependent modules without restarting.

[0039] 6) Dynamic updates: This refers to a technical mechanism that replaces the modules already loaded in memory with the latest version without stopping the application, restarting the service, or redeploying. For example, when the "risk control module" releases version V2, the Node service using dynamic update technology will automatically pull the V2 code and replace the V1 version in memory, so that subsequent business requests can immediately use the logic of version V2 without going through the traditional rebuild and deployment process.

[0040] 7) Software Development Kit (SDK): A SDK is a collection of development tools for building application software, including specific software packages, software frameworks, hardware platforms, and operating systems. In this application, it specifically refers to the hel-micro-node SDK, which encapsulates core functions such as module mapping, proxy generation, version retrieval, and cache cleanup. Developers can easily integrate it to enable their applications to have the ability to hot-update modules.

[0041] 8) hel-micro-node Software Development Kit (hel-micro-node SDK): This application provides an SDK implementation specifically designed to enable dynamic updates of server-side JavaScript modules. For example, when a developer imports this SDK at the start of a Node service, it will intercept specific module import requests by overriding the underlying module path resolution function of the Node.js application, thereby returning dynamically fetched micro-module proxy objects instead of local static files.

[0042] 9) hel Micro-module: A hel micro-module is a specially constructed JavaScript module that can be recognized and dynamically loaded by the hel-micro-nodeSDK. For example, a regular npm package, after being built using the tools provided in this application, will generate a micro-module artifact containing metadata description files, giving it a dual identity: it can be used as a regular package, or it can be remotely loaded by the SDK to achieve hot version updates.

[0043] 10) Command Line Interface (CLI): This refers to a tool library that allows interaction with computer programs via text commands. For example, in this application, the module provider uses a provided CLI tool (such as hel-cli) to execute hel init to initialize the project, or to execute build commands to generate compliant micro-module artifacts and publish them to the repository.

[0044] 11) Content Delivery Network (CDN): A CDN is an intelligent virtual network built on top of existing networks. It relies on edge servers deployed in various locations and utilizes a central platform's load balancing, content distribution, and scheduling modules to enable users to access the content they need from the nearest location. In this application, the CDN is used to store static resource files (such as JS code and metadata) after the micro-modules are built, ensuring that the Node service can quickly and stably download the specified version of the module code.

[0045] 12) Responding to: used to indicate the conditions or states on which the operation performed depends. When the conditions or states on which it depends are met, one or more operations performed may be performed in real time or with a set delay. Unless otherwise specified, there is no restriction on the order in which the multiple operations are performed.

[0046] 13) A network socket is an abstraction of an endpoint for bidirectional communication between application processes on different hosts in a network. In this application, it specifically refers to the persistent connection channel (such as WebSocket) established between the client SDK and the helpack management console. For example, when the operations and maintenance personnel perform a "version rollback" operation in the management console, the server pushes update signals to all online Node services in real time through this socket channel, thereby triggering the client's module pull logic.

[0047] 14) Proxy Module: The proxy module is an intermediate module that maintains consistency with the target module in terms of program interface and contains an internal reference pointing to the real instance of the target module. It is configured to forward the call request to the real instance of the target module for execution through the internal reference when a call request is received.

[0048] 15) Module Import Mechanism: The module import mechanism refers to the programmatic process built into the scripting language application, which responds to module loading function (e.g., require or import) calls and performs a series of operations such as path resolution, file loading, code execution, and module caching to return a module instance.

[0049] 16) Internal Reference: An internal reference is a data structure maintained in memory by the software development kit for dynamically associating the proxy module with the latest version instance of the target module. For example, it is a hash table or dictionary entry that maps module names to module instance objects.

[0050] 17) Execution Entity: The execution entity refers to the actual module instance generated in memory after the software development kit asynchronously loads and executes the code of the target module, and is capable of responding to business call requests.

[0051] 18) Micromodule Mapping Relationship: The micromodule mapping relationship is a preset data structure that associates the name of the target module that needs to be dynamically updated at runtime with the micromodule artifacts of the target module. It is used to identify the target module that needs to be taken over by the software development kit when the module is loaded.

[0052] 19) Dual Identity: The dual identity refers to the fact that the package body simultaneously contains two product forms that can be used by different loading mechanisms: one is a traditional module product that is statically referenced through the native module import mechanism; the other is a micro-module product that is dynamically loaded at runtime by the software development kit.

[0053] In related technologies, in server-side scripting application development, business logic is typically broken down into multiple independent modules for management. The application loads these modules at startup and maintains the unchanged code logic throughout its runtime. During the implementation of the embodiments of this application, the applicant discovered that related technical solutions may face the following challenges when dealing with high-frequency business iterations or emergency repair scenarios: 1) Timeliness and service continuity issues of module updates: In traditional development and operations models, once the code of an underlying shared module changes, all upper-layer microservice applications that depend on that module must go through a complete release process of "updating dependencies, rebuilding, stopping services, deploying new packages, and restarting services." This end-to-end release method is not only time-consuming and difficult to respond to urgent business changes within seconds, but the service restart process inevitably affects the continuity of online business or requires complex traffic switching strategies to maintain high availability.

[0054] 2) Compatibility issues between dynamic loading and the development ecosystem: Introducing a dynamic module loading mechanism often requires developers to modify their existing coding habits (e.g., using specific asynchronous loading functions instead of standard import statements), or results in the loss of native support such as code completion and type checking in the local development environment. Maintaining seamless compatibility with native development workflows (such as local debugging and IDE support) while implementing remote dynamic loading, and ensuring consistent module behavior between local and production environments, are key challenges in building a micro-module system.

[0055] 3) Risk control issues of runtime updates: When implementing runtime hot replacement of module code, without a fine-grained version control mechanism, a single erroneous update may instantly spread to all service instances, causing widespread failures. Ensuring that the dynamic update mechanism can achieve the same canary release, specific version locking, and rapid rollback capabilities in abnormal situations as static releases in the runtime environment is crucial for the safe implementation of dynamic update mechanisms in production environments.

[0056] This application provides a method, apparatus, computer-readable storage medium, and computer program product for updating modules in a scripting language application on a server, aiming to improve the efficiency, compatibility, and security of module updates, as detailed below: To address the aforementioned technical problem 1), this application embodiment constructs an interception and forwarding system based on a "proxy module" by integrating a software development kit (SDK) into the application and modifying the built-in module import mechanism. When responding to a version update command, the SDK asynchronously obtains the new version code, clears the old version cache, and updates the internal references of the proxy module, thus seamlessly switching the execution logic to the new version instance without restarting the application process. This solution solves the problems of time-consuming traditional release processes and the need to restart services. Through a runtime dynamic update mechanism, it significantly improves the timeliness of releasing shared business modules and ensures continuous online service.

[0057] To address the aforementioned technical problem 2), this application's embodiments employ a "micro-module mapping and dual-identity package" technique. By providing an initialization interface to configure the mapping relationship between module names and micro-module artifacts, business code can continue to use standard native import syntax to access remote modules. Combined with a dual-identity package generated by the build tool, which possesses characteristics of both traditional static packages and dynamic micro-module packages, developers can directly utilize locally installed traditional code to obtain a complete development experience during local development. This solution solves the problem that dynamic loading mechanisms typically disrupt development ecosystem compatibility, achieving zero-intrusion access to business code and maintaining the consistency and efficiency of the development workflow.

[0058] To address the aforementioned technical problem 3), this application's embodiments introduce an update decision-making mechanism that combines remote management metadata with local custom rules. By establishing a persistent connection with a remote module management platform, it receives update instructions containing version metadata in real time and makes decisions based on preset custom rules (such as canary release strategies) before executing the update locally. It also supports cache management based on version directories. This solution resolves the risk of full-scale diffusion that dynamic updates may bring, achieving fine-grained control over module versions (such as second-level canary releases and rollbacks), ensuring the stability and security of the production environment due to system changes.

[0059] The following describes an exemplary application of the device update module in a scripting language application on a server, as provided in the embodiments of this application. The device provided in the embodiments of this application can be implemented as various types of terminals such as laptops, tablets, desktop computers, set-top boxes, smartphones, smart speakers, smartwatches, smart TVs, and in-vehicle terminals, or it can be implemented as a server. The following will describe an exemplary application when the device is implemented as a server.

[0060] See Figure 1 , Figure 1 This is a schematic diagram of the system architecture for a method of updating modules in a scripting language application on a server, provided in an embodiment of this application. This is to support an application that updates modules within a scripting language application on a server. Figure 1The example involves a server 100 and terminals connected via a network 300 (terminals 200-1 and 200-2 are shown as examples). The network 300 can be a wide area network (WAN), a local area network (LAN), or a combination of both.

[0061] As a specific application scenario of this implementation method, a large-scale internet business platform needs to perform efficient operation and maintenance management and agile development of its backend microservice cluster. The method for updating modules in a scripting language application on the server, as described in this application embodiment, is deployed on this platform. Here, server 100 represents multiple service nodes in the microservice cluster, for example, simultaneously running multiple independent scripting language application projects such as "order service," "product service," and "marketing service."

[0062] In this scenario, a target module named "Promotion Calculation Module" is a shared business module that is depended upon by all three services. When a unified adjustment of the promotion strategy is needed, the developers update the code of this shared module on terminal 200-1 and publish it to the remote module management platform. Subsequently, the operations and maintenance personnel can issue a version update command on the management platform through terminal 200-2. This command is distributed via network 300 to all scripting language application instances that depend on this module; that is, the software development kits integrated within the "Order Service," "Product Service," and "Marketing Service" will all receive the command. Each service instance independently executes the method of this embodiment: asynchronously loading the new version of the "Promotion Calculation Module" code in the background, generating a new version instance, and seamlessly switching the proxy module references within their respective applications to the new instance.

[0063] This approach enables "one-time deployment, widespread application" of shared business modules. The platform can uniformly and in real-time apply new promotional logic across all business processes without requiring a separate restart or redeployment of any service within the massive microservice cluster. This not only significantly improves the operational efficiency of multi-service collaborative development but also provides crucial technical support for advanced operational capabilities such as lossless deployment, canary release verification, and second-level rollback of the business platform.

[0064] In some embodiments, server 100 may be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Terminals and servers can be connected directly or indirectly via wired or wireless communication, which is not limited in this embodiment.

[0065] See Figure 2 , Figure 2 This is a schematic diagram of the structure of the server 100 provided in the embodiments of this application. Figure 2 The server 100 shown includes at least one processor 110, memory 130, and at least one network interface 120. The various components of server 100 are coupled together via a bus system 140. It is understood that the bus system 140 is used to implement communication between these components. In addition to a data bus, the bus system 140 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 140.

[0066] The processor 110 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0067] The memory 130 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 130 may optionally include one or more storage devices physically located away from the processor 110.

[0068] The memory 130 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 130 described in this application embodiment is intended to include any suitable type of memory.

[0069] In some embodiments, memory 130 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0070] Operating system 131 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, and driver layer, for implementing various basic business functions and handling hardware-based tasks. The network communication module 132 is used to reach other electronic devices via one or more (wired or wireless) network interfaces, exemplary network interfaces including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc. In some embodiments, the processing apparatus for the application programming interface provided in this application can be implemented in software. Figure 2 A scripting language application update module device 133 stored in memory 130 on a server is shown. This device can be software in the form of programs and plugins, and includes the following software modules: an interception unit 1331, a loading unit 1332, and an update unit 1333. These modules are logically linked and can therefore be arbitrarily combined or further separated according to their implemented functions. The functions of each module will be described below.

[0071] The following will describe the information processing method provided in the embodiments of this application, taking the server as the execution subject, with exemplary applications and implementations of the electronic device provided in the embodiments of this application.

[0072] See Figure 3A , Figure 3A This is a flowchart illustrating a method for updating modules in a scripting language application on a server, as provided in an embodiment of this application. Figure 3A The steps shown are explained.

[0073] The server's scripting language application integrates a software development kit (SDK). The module update process executed by the SSD can be achieved through the following steps 101 to 103, which are explained in detail below.

[0074] In step 101, the built-in module import mechanism of the scripting language application is modified to intercept the loading request for the target module issued by the scripting language application.

[0075] Step 101 can be implemented as follows: In the initial stage of scripting language application startup, the software development kit (SDK) intervenes and replaces its underlying module resolution function. This process is accomplished by saving a reference to the original resolution function and replacing it with a new resolution function defined by the SSD that has interception capabilities. This new function can capture all module loading calls, providing an entry point for subsequent dynamic processing.

[0076] As an example of step 101, in the entry file of a Node.js application (such as app.js), the software development kit (SDK) provided in this embodiment is first imported. When the package is loaded, its initialization logic is automatically executed. By accessing `require.main.constructor._resolveFilename`, it obtains and saves the original Node.js module path resolution function, and then points this property to a custom new function. When subsequent code in the application executes `require('pricing-module')`, this call will be intercepted by this new function.

[0077] Step 101 achieves non-intrusive control over the module loading behavior of scripting language applications. This approach establishes a unified module loading interception point at the underlying level without modifying the module import syntax of the business code. This lays the foundation for dynamic management of target modules and injection of proxy modules, ensuring the solution's compatibility with the existing development ecosystem.

[0078] See Figure 3B The "modification of the built-in module import mechanism of the scripting language application" in step 101 can be achieved through step 1011, which will be explained in detail below.

[0079] In step 1011, when the scripting language application starts, its built-in module path resolution function is obtained and saved as the original resolution function, and a new resolution function is used to replace the original resolution function. The new resolution function is configured to: when a loading request is intercepted, if the target module of the loading request does not exist in the preset micro-module mapping relationship, the original resolution function is called to load the local module; if the target module exists in the micro-module mapping relationship, the step of returning the proxy module to the scripting language application is executed.

[0080] Step 1011 can be implemented as follows: The new parsing function contains a core branching logic. It first extracts the requested module name from the loading request, then queries a micro-module mapping table maintained by the software development kit. If the module name exists in the mapping table, it determines that the module is a target module that needs dynamic management and executes the logic to return a proxy module; if it does not exist, it seamlessly passes all parameters of the loading request to the previously saved original parsing function, using the application's default module loading behavior.

[0081] As an example of step 1011, assume the preset micro-module mapping relationship is {'pricing-module': 'remote-pricing-module'}. When the new parsing function intercepts `require('pricing-module')`, it finds `pricing-module` in the mapping relationship, thus determining that it is a target module, and then proceeds to generate or return the proxy module. When it intercepts `require('express')`, since `express` is not defined in the mapping relationship, the new parsing function will call the original parsing function, causing it to load the `express` framework from the `node_modules` directory in the normal way.

[0082] Step 1011 enables intelligent routing of different module types. This step ensures that only target modules explicitly designated as micro-modules enter the dynamic management process, while the loading behavior of all other standard modules remains completely unaffected. This introduces dynamic update capabilities while maintaining the overall stability of the application and compatibility with third-party libraries.

[0083] After step 1011 “Return to Proxy Module”, the following scheme can also be performed: write the proxy module into the module cache of the scripting language application.

[0084] The above-mentioned scheme of writing the proxy module to the cache can be implemented in the following way: After the software development kit successfully generates or locates the proxy module file, it calls the module management interface built into the scripting language environment, and writes the path of the proxy module and its exported module object as a key-value pair into the application's global module cache (such as require.cache in Node.js applications).

[0085] As an example, once `pricing-module` is identified as the target module and a proxy module located at ` / .hel_modules / .proxy / pricing-module.js` is generated, the SDK will perform an operation similar to `require.cache[' / path / to / proxy / pricing-module.js'] = proxyModuleObject;`. This way, when other parts of the application call `require('pricing-module')` again, they will directly retrieve and return this proxy module object from the cache, avoiding repeated path resolution and file generation.

[0086] By writing the proxy module into the cache as described above, the performance of proxy module loading is optimized. Caching the proxy module ensures that multiple import requests for the same target module throughout the application's lifecycle return the same proxy module instance in the most efficient way, avoiding unnecessary duplicate processing and reducing overhead.

[0087] After step 1011 "Load local module", the following scheme can also be performed: write the local module into the module cache of the scripting language application.

[0088] The above-described scheme for writing local modules to the cache can be implemented as follows: Since this scheme directly calls the original parsing function to complete the loading when processing non-target modules, and the default loading mechanism of scripting language environments (such as Node.js) inherently includes the logic of writing successfully loaded modules to the module cache, this scheme naturally inherits this feature without requiring additional steps.

[0089] As an example, when the application executes `require('express')`, the custom new parsing function calls the original parsing function. After the original parsing function loads the express module from `node_modules`, the Node.js module loader automatically writes an instance of the express module to `require.cache`. Subsequent `require` calls to express will retrieve the data directly from the cache, which is completely consistent with the behavior when the SDK is not integrated.

[0090] By writing local modules into the cache as described above, the loading behavior of non-target modules is ensured to be completely consistent with the native environment. This further confirms the non-intrusiveness and high compatibility of the embodiments of this application with existing technologies and development ecosystems, and ensures the stability and reliability of the solution.

[0091] In step 1011, the following scheme can also be executed: before the core business logic of the scripting language application starts, the initialization interface provided by the software development kit is called. The initialization interface is used to receive the micro-module mapping relationship as input parameters, trigger the first asynchronous loading of all target modules in the micro-module mapping relationship, and wait for all asynchronous loading tasks to be completed before ending the execution.

[0092] The above-mentioned scheme for asynchronously loading the target module for the first time can be implemented as follows: In the application's startup script, before the core business service (such as starting an HTTP server) starts, an initialization interface such as mapAndPreload provided by the software development kit is explicitly called. This interface accepts an object that defines the module mapping relationship as a parameter and starts a parallel, asynchronous code fetching task for each target module in the object. Internally, the interface uses mechanisms such as Promise.all to wait for all these asynchronous tasks to complete before its own Promise becomes resolved, thus allowing the main process to continue execution.

[0093] As an example, the application code looks like this: `await helMicroNode.mapAndPreload({'pricing-module': 'remote-pricing'}); console.log('Preload finished'); app.listen(3000);`. When `mapAndPreload` executes, it immediately starts an asynchronous remote code fetch task for the `pricing-module`. `await` only ends and the console prints "Preload finished" after the code for the `remote-pricing` module has been successfully downloaded and loaded into memory. Only then does the HTTP server begin listening on port 3000.

[0094] The above-described asynchronous initial loading of the target module implements a service availability guarantee mechanism. It ensures that all core dynamic modules have completed their initial version loading before the application officially provides services, avoiding network latency or loading failures caused by the first call to the target module after service startup, and improving the response speed and stability of the first request after application startup.

[0095] See also Figure 3A In step 102, a proxy module is returned to the scripting language application, and the code of the target module is asynchronously loaded based on the metadata obtained from the remote module management platform, as the execution entity of the proxy module.

[0096] Step 102 can be implemented as follows: When step 101 determines that a loading request is for a target module, the software development kit (SDK) immediately generates a placeholder proxy module file locally and synchronously returns its path to the loader. Simultaneously, an independent asynchronous process is initiated. This process first connects to a remote module management platform to obtain the target module's metadata, and then downloads the actual module code from a resource server (such as a CDN) according to the URL address specified in the metadata. After downloading, this code is executed in memory to obtain a real module instance, which is then associated with the proxy module.

[0097] As an example of step 102, when `pricing-module` is requested, the Software Development Kit (SDK) synchronously returns a proxy module with content similar to `module.exports = createProxy('pricing-module');`. Simultaneously, an asynchronous task begins execution: it requests the management platform API `GET / api / meta / pricing-module / latest`, retrieving metadata containing `"url":"https: / / cdn.example.com / pricing / v1.0.js"`. Next, it downloads the JS file, loads the actual module instance using `require(' / path / to / downloaded / v1.0.js')`, and stores it in a mapping table within the SSDK with the key `pricing-module`.

[0098] Step 102 decouples the synchronous return and asynchronous implementation of module loading. This "return the proxy first, then load the entity asynchronously" pattern allows the synchronous require syntax of the upper-layer business code to be retained without having to be changed to asynchronous import, while placing time-consuming network operations in the background to ensure the non-blocking nature of the application startup process, thus improving the development experience and runtime efficiency.

[0099] The proxy module in step 102 is dynamically generated locally by the software development kit based on the template and stored in the preset proxy module directory when the target module is loaded for the first time.

[0100] The above-mentioned proxy module generation and storage scheme can be implemented in the following way: The software development kit (SDK) pre-constructs a proxy module code template in string form. When a proxy needs to be generated for a target module (such as pricing-module) for the first time, the SSD will replace the placeholders in the template (such as __MODULE_NAME__) with the actual module name pricing-module, and then write the generated new string content to a fixed local directory managed by the SSD (such as / .hel_modules / .proxy / pricing-module.js in the project root directory).

[0101] As an example, the template for the proxy module might be `const sdk = require('hel-micro-node'); module.exports = sdk.createProxy('__MODULE_NAME__');`. When a proxy is generated for the `pricing-module`, `__MODULE_NAME__` is replaced, and the final content written to the file is `const sdk = require('hel-micro-node'); module.exports = sdk.createProxy('pricing-module');`.

[0102] By using the aforementioned method for generating and storing proxy modules, on-demand, automated generation of proxy modules is achieved. This mechanism avoids the tedious work of manually creating proxy files for each target module, making the entire process transparent to developers. Furthermore, storing all proxy modules centrally in a specific directory facilitates management and debugging.

[0103] The metadata in step 102 is stored in a metadata file, which contains at least: application data and version data; the version data includes: the artifact version number, the root path of the resource server, and a list of paths to all code files of the target module.

[0104] The above-described scheme for retrieving metadata from metadata files can be implemented as follows: The remote module management platform generates a JSON-formatted metadata file for each version of each target module. This file is stored as a static resource on a resource server. When the software development kit (SDK) needs to load or update a module, it will first request this JSON file.

[0105] As an example, the metadata file meta.json for version v1.2.0 of the pricing-module might look like this: { "app": { "name": "pricing-module", "owner": "e-commerce-team"}, "version": { "sub_app_ver": "1.2.0", "online_version": "1.2.0", "cdn_path": "https: / / cdn.example.com / hel / ", "files": [ "pricing-module / 1.2.0 / index.js", "pricing-module / 1.2.0 / utils.js" ]}}. Here, cdn_path is the root path of the resource server, and files is a list of code file paths.

[0106] The above-described scheme for retrieving metadata from metadata files achieves the separation of module information from code entities. Separating the module's descriptive information (metadata) from the executable code allows for centralized and structured management of information such as version control, dependencies, and resource location. This facilitates advanced platform operations such as version control and canary releases, and provides clear and standardized resource retrieval commands for the client SDK.

[0107] Before step 102, “Asynchronously loading the code of the target module”, the following scheme can also be performed: check the status of the asynchronous loading task for the target module; if the asynchronous loading task is in progress, suspend the current loading request to put it into a waiting state until the asynchronous loading task is completed; if the asynchronous loading task is not in progress, start the asynchronous loading task for the code.

[0108] The above-described scheme for checking and managing the status of concurrent loading tasks can be implemented as follows: The software development kit (SDK) maintains a state machine or locking mechanism to manage the loading status (e.g., idle, loading, loaded) of each target module. Before triggering the asynchronous loading of a module, its status is checked. If the status is loading, a new loading task is not started; instead, the callback function of the current request or the resolve method of a Promise is added to a waiting queue. When the ongoing loading task completes, all callbacks in the waiting queue are iterated and executed.

[0109] As an example, when the application starts, two different business files, A and B, require('pricing-module') almost simultaneously. The first request changes the state of 'pricing-module' from idle to loading and starts the download. The second request checks that the state is loading, so it stores its own Promise resolve function in the waiting queue. When the download and loading are complete, the first task changes the state to loaded and then executes the resolve function in the waiting queue, so the second require call also obtains the resolved result.

[0110] The above-described scheme for checking and managing the status of concurrent loading tasks effectively manages concurrent loading requests. It avoids initiating multiple repeated network requests and loading operations on the same module at the same time, ensuring efficient resource utilization, preventing data inconsistencies or state errors that may arise from concurrent contention, and improving robustness.

[0111] In step 102, the following scheme can also be executed: when the proxy module receives a call request from the scripting language application, it queries the internal reference maintained inside the software development kit that points to the latest version of the real module instance, and forwards the call request to the latest version of the real module instance for execution through the internal reference.

[0112] The above-described scheme of dynamically forwarding call requests via a proxy module can be implemented as follows: The proxy module itself is an empty object, and all its property reads, settings, or function call operations are intercepted by a handler. In Node.js, this can be achieved using a Proxy object. When business code accesses a property of the proxy module (such as proxy.calculatePrice()), the Proxy's get trap is triggered. In the implementation of the get trap, the code accesses a global mapping table within the software development kit (SDK) to find the latest real module instance corresponding to the current module name, and then forwards the property access or method call to this real instance.

[0113] As an example, the business logic calls `pricingModule.calculatePrice(args)`. `pricingModule` is a `Proxy` instance. Its `get` trap is triggered to retrieve the `calculatePrice` property. The trap function executes `sdk.getModule('pricing-module')`, retrieving the latest loaded v2.0 version of the real module instance `realModuleV2` from within the SDK. It then returns `realModuleV2.calculatePrice`. Subsequently, the JavaScript engine executes a call to this returned function, passing `args` as the argument.

[0114] The above-described scheme of dynamically forwarding call requests via a proxy module achieves dynamic routing of call requests. The proxy module acts as a transparent middleware layer, decoupling business logic from specific module implementation versions. Regardless of how the backend modules are updated, the business logic always interacts with the same stable proxy object. The proxy ensures that every call is accurately forwarded to the latest logic implementation, which is the core mechanism for achieving runtime hot updates.

[0115] In step 102, the following scheme can also be implemented: when the target module is a shared business module that multiple scripting language application projects depend on, after the code of the target module is changed, the changed code of the target module is published to the remote module management platform, and the software development kit performs module update processing in each scripting language application.

[0116] The above-described scheme for remotely publishing and updating shared modules can be implemented as follows: After modifying the code of the shared module locally, the module provider (developer) uses the accompanying build tool to execute the publish command. This command packages the new version of the code and uploads it to the CDN (Content Delivery Network), while simultaneously registering the new version's metadata (version number, file path, etc.) with the remote module management platform. Subsequently, operations and maintenance personnel issue version update instructions through the management platform's interface. All online application instances that integrate the software development kit (SDK) and depend on this shared module will receive the instruction and trigger their respective internal update processes.

[0117] As an example, a "user authentication module" is jointly depended upon by the order service and the product service. After the developers fixed a security vulnerability in the authentication module and released version 2.1, the operations and maintenance personnel switched the online version of the "user authentication module" from v2.0 to v2.1 on the management platform. The order service and product service instances deployed on different servers each received an update notification, and each independently performed a hot update process, downloading, clearing caches, and updating references.

[0118] This remote deployment and update of shared modules enables a highly efficient distribution mechanism that allows for a single deployment to take effect across multiple platforms. It simplifies the traditional process of building and deploying each dependent project multiple times into a single module deployment and a single remote command issuance. This significantly reduces the time it takes for shared modules to take effect across the entire platform after code changes, and substantially improves the efficiency of collaborative development and maintenance across multiple services.

[0119] In step 103, in response to the version update instruction for the target module, the following update processes are performed: obtain the code of the new version specified by the version update instruction; clear the instances related to the old version of the target module in the module cache inside the scripting language application; update the internal references of the proxy module so that the internal references point to the newly loaded instance of the new version built on the new version of the code.

[0120] Step 103 can be implemented as follows: The software development kit (SDK) listens in real-time for instructions from a remote module management platform via a persistent connection (such as WebSocket). When it receives a version update instruction for a target module, it first parses the instruction to obtain the version number and metadata address of the new version. Then, it performs an atomic operation containing three core actions: First, it retrieves the code file of the new version from the resource server; second, it removes the entry for the old version module from the module cache using the API of the scripting language environment (such as Node.js's delete require.cache[modulePath]); finally, it updates an internally maintained mapping table from module name to actual module instance, pointing the entry for the target module to the new instance just generated by loading the new version code.

[0121] As an example of step 103, the Software Development Kit (SDK) receives the instruction `{ module: 'pricing-module', version: '2.0.0'}`. It then downloads the code for v2.0.0 and executes `delete require.cache[' / path / to / downloaded / pricing-module / v1.0.0 / index.js']`. Next, it loads the newly downloaded v2.0.0 code to obtain `newRealModule`, and finally updates the internal state `sdk.internalModules['pricing-module'] = newRealModule`. After this, any calls to the `pricing-module` proxy module will be forwarded to `newRealModule`.

[0122] Step 103 establishes a complete, runtime-based closed-loop module hot update mechanism. This step precisely defines the core three-step process from receiving instructions to completing the logical switch. Through a series of coherent operations—"acquiring new code, clearing old cache, and updating internal references"—it ensures that module instances can be safely and thoroughly replaced without restarting the application. This is crucial for ensuring service continuity while achieving real-time logical updates.

[0123] See Figure 3C The version update instruction in step 103 is received from the remote module management platform. Furthermore, before performing the update process, steps 104 to 105 can also be executed, as will be explained in detail below.

[0124] In step 104, an update decision is made based on preset custom rules, including canary release rules or version locking rules.

[0125] Step 104 can be implemented as follows: In the software development kit (SDK) configuration, users can define one or more update decision rule functions. When the SDK receives a version update instruction, it calls these rule functions before executing the actual update operation, passing the content of the update instruction and some contextual information of the current application instance (such as server IP, user ID, etc.) as parameters. The rule function returns a boolean value, determining whether to continue the update.

[0126] As an example of step 104, a canary release rule can be defined as follows: `function(updateInfo, context) { const serverIp = context.ip; return serverIp.endsWith('.1') || serverIp.endsWith('.2');}`. This means that only instances whose server IP addresses end with '.1' or '.2' will accept updates. A version locking rule can be: `function(updateInfo) { return updateInfo.moduleName !== 'critical-payment-module';}`, which means that the `critical-payment-module` is locked and rejects any dynamic updates.

[0127] Step 104 introduces sophisticated risk control capabilities to the dynamic update mechanism. Through custom rules, operations personnel can implement complex release strategies, such as canary rollouts based on IP address, user group, or geographic location, or version locking for critical core modules to prevent accidental updates. This mechanism significantly enhances the security, controllability, and flexibility of dynamic updates in production environments.

[0128] In step 105, if the update decision result indicates acceptance of the version update, the update process continues; if the update decision result indicates rejection, the update process is terminated.

[0129] Step 105 can be implemented as follows: This step is a direct execution of the decision logic in Step 104. A conditional statement within the software development kit checks the return values ​​of all custom rule functions. If all rules (or any one rule, depending on the configured logic) return true, the code flow continues to execute update steps such as fetching new code. If any decisive rule returns false, the update process is immediately interrupted, and a log entry can be optionally logged indicating that the update was skipped due to rule restrictions.

[0130] As an example of step 105, when an instance with server IP 10.0.0.3 receives an update command, the canary release rule `serverIp.endsWith('.1') || serverIp.endsWith('.2')` in step 104 will return false. Therefore, in the judgment of step 105, the update process is terminated, and this instance will not download and update the module, continuing to use the old version. The instance with IP 10.0.0.1, however, will pass the check and continue to perform the update.

[0131] Step 105 ensures that the release strategy defined in step 104 is strictly enforced. This is the connection point that transforms abstract release rules into concrete actions, and it is the concrete manifestation of advanced operation and maintenance strategies such as canary releases and blue-green deployments at the client level, ensuring that version updates are carried out in a controlled manner.

[0132] See Figure 3D The step 103, "obtaining the code of the new version specified by the version update instruction", can be achieved through the following steps 1031 to 1032, which are explained in detail below.

[0133] In step 1031, the new version of the code is retrieved from the local cache.

[0134] Step 1031 can be implemented as follows: The software development kit maintains a cache directory (e.g., / .hel_modules / pricing-module / v2.0.0 / ) organized by module name and version number on the local file system. When a new version of the code is needed, it first constructs an expected local file path based on the module name and version number in the version update instruction, and then checks whether the path exists.

[0135] As an example of step 1031, after receiving the instruction to update to pricing-module v2.0.0, the SDK will check if the file / .hel_modules / pricing-module / v2.0.0 / index.js exists locally. If the file exists, it means that the code for this version has been downloaded before.

[0136] Step 1031 implements a network request optimization strategy. By prioritizing checks of the local cache, unnecessary duplicate network requests to already downloaded code versions can be avoided. This is especially beneficial in scenarios involving version rollback or multiple application instances sharing the same physical disk, significantly saving network bandwidth and download time, and accelerating updates or rollbacks.

[0137] In step 1032, if the new version of the code is not found, the new version of the code is downloaded from the resource server and stored in the local cache in a versioned manner; if the new version of the code is found, the new version of the code in the local cache is used directly.

[0138] Step 1032 can be implemented as follows: If the check result of step 1031 indicates that the code version does not exist locally, the software development kit (SDK) will download the code file from the resource server via an HTTP request based on the URL in the metadata. Upon successful download, it will create the corresponding versioned directory (e.g., / .hel_modules / pricing-module / v2.0.0 / ) and store the downloaded code file there. If step 1031 detects that the code already exists, the download is skipped, and subsequent processes directly read the local file.

[0139] As an example of step 1032, after checking and finding that the v2.0.0 code does not exist locally, the SDK sends a download request to https: / / cdn.example.com / pricing / v2.0.0 / index.js and saves the obtained file content to / .hel_modules / pricing-module / v2.0.0 / index.js. In another rollback request to v2.0.0, since the file already exists, it is directly loaded using this local file, and no further network requests are made.

[0140] Step 1032 establishes a complete code retrieval process with a caching mechanism. This process combines network downloading and local cache reading, forming an efficient and reliable code supply mechanism that ensures access to any specified version of the code while maximizing efficiency through cache reuse.

[0141] After "store the new version of the code in the local cache in a versioned manner" in step 1032, the following scheme can also be executed: check the number of version directories in the local cache; if the number of version directories exceeds the preset limit, remove at least one of the oldest version directories so that the number of version directories in the local cache does not exceed the preset limit.

[0142] This automatic cleanup of excess local cache can be achieved as follows: After each successful download and storage of a new version, the software development kit (SDK) will count the total number of cached version directories under a specific module. If this number exceeds the limit set by the user in the configuration (e.g., 5), it will determine and delete one or more old version directories and their contents according to a preset strategy (e.g., Least Recently Used, or directly sorting by version number and removing the oldest).

[0143] As an example, suppose the pricing module has a cache limit of 3, and versions v1.0, v1.1, and v1.2 are already stored locally. When version v1.3 is downloaded, the number of cache directories increases to 4, exceeding the limit. At this point, the SDK will sort by version number and delete the oldest v1.0 directory, returning the number of cache directories to 3.

[0144] This automatic cleanup of excess local cache implements an automated local cache space management mechanism. It effectively prevents the local cache from expanding indefinitely due to version iterations, thus avoiding disk space exhaustion. By periodically cleaning up infrequently used older versions, a balance can be struck between maintaining fast access to recent versions and controlling storage costs.

[0145] See also Figure 3A In step 103, the "new version instance created based on the new version of the code" is a module object exported after the new version of the code is executed by the module loading function of the scripting language application.

[0146] The above method for generating a new version instance can be implemented as follows: After obtaining the local path of the new version's code file (whether downloaded from the network or read from a local cache), the software development kit (SDK) directly calls the module loading function built into the scripting language environment (such as `require(filePath)` in Node.js) to execute this code. This loading function synchronously executes the JavaScript code in the file and returns the object exported by `module.exports` or `exports`. This returned object is the new version instance.

[0147] As an example of this implementation, after obtaining the new version code path as ' / path / to / hel_modules / pricing / v2.0 / index.js', the SDK internally executes `const newInstance = require(' / path / to / hel_modules / pricing / v2.0 / index.js');`. The object referenced by the `newInstance` variable is the module instance exported after the v2.0 version code is executed.

[0148] By using the native loading function to generate instances, the above approach ensures that dynamically loaded modules can run in the same execution context and environment as the rest of the application. Using the native loading function guarantees that newly loaded modules can correctly resolve their dependencies, access global variables, and seamlessly integrate with the rest of the application, just as if they were statically loaded at startup.

[0149] The “version update instruction” in step 103 is generated and sent by the remote module management platform after receiving the version change operation issued through the visual interface, or it is generated by the internal code of the scripting language application by calling the version switching interface provided by the software development kit to request the loading of a specific version of the target module.

[0150] The above-mentioned version update instruction generation scheme can be implemented in the following ways: the source of the version update instruction can be two types: one is the "push" mode, which is initiated by the external system (remote module management platform); the other is the "pull" mode, which is triggered by the application's own logic.

[0151] As an example, in "push" mode: The operations and maintenance personnel click the "Publish" button for "pricing-module" in the application store on the web interface, select version v2.0, and confirm. The management platform's backend service then generates an update command in JSON format and pushes it to all connected client SDKs via WebSocket. In "pull" mode: In a management backend interface of the application, there is a piece of code: `if (condition) { await helMicroNode.importMod('pricing-module',{ version: '2.1-beta'});}`. When certain conditions are met, the application will actively call the SDK's interface to request the loading of a specific beta version for testing, which will also generate an internal update command.

[0152] The "push" and "pull" triggering methods described above provide flexible and diverse triggering pathways for module updates. It supports both centralized release processes managed uniformly by the operations and maintenance platform and decentralized dynamic loading triggered on demand by the application's own logic, meeting the needs of different scenarios from formal releases in the production environment to temporary debugging in development and testing environments.

[0153] In step 103, the following technical solution can also be implemented: establish a persistent communication link with the remote module management platform, through which version update commands can be received. The persistent communication link is a WebSocket connection.

[0154] The above-described scheme for establishing a persistent WebSocket communication link can be implemented as follows: During software development kit (SDK) initialization, it starts a client that connects to the server address specified by the remote module management platform using the WebSocket protocol. Once the connection is successful, it remains active, with a heartbeat mechanism configured to maintain its activity and detect disconnections. When the management platform needs to issue commands, it can directly send JSON-formatted command messages to the client SDK through this established WebSocket connection.

[0155] As an example, the SDK client connects to wss: / / hel-api.example.com / ws. After the connection is established, it sends a ping message periodically (e.g., every 30 seconds), and the server responds with a pong message. When the operations team releases a new version, the server sends a message through this connection: '{"type":"update", "payload":{"moduleName":"pricing-module", "version":"2.0.0"}}'. The SDK's onmessage event listener receives this message and parses and processes it.

[0156] The above-described scheme for establishing a persistent WebSocket communication link enables a low-latency, real-time command delivery channel. Compared to the traditional HTTP polling method, WebSocket long connections avoid a large number of invalid polling requests, significantly reducing resource consumption on both the server and client sides. Furthermore, it ensures that update commands reach all online service instances from the platform within milliseconds, making it a key technological foundation for achieving second-level deployment.

[0157] Steps 101 to 103 are implemented through an end-to-end workflow covering both the module provider and the module user. This end-to-end workflow includes: a module preparation workflow executed by the module provider, which includes: initializing a micro-module project using a command-line tool and writing source code within the micro-module project; executing a build command to generate a package body as the target module's release form, the package body having dual identities, including a traditional module artifact for static reference and a micro-module artifact for dynamic loading, the micro-module artifact containing at least a metadata file; and publishing the dual-identity package body to the package manager repository. The module integration workflow executed by the module user includes: installing the package body from the package manager repository as the target module; and in the scripting language application, calling the interface provided by the software development kit to establish a mapping between the target module's name and the micro-module artifact.

[0158] This end-to-end workflow can be implemented in the following ways: Module provider: 1. Developers initialize a micro-module project by executing `npx create-hel-app lib-new` in the terminal. 2. Write the business logic code for `lib-new` in the `src` directory. 3. Execute `npm run build`. The build tool (such as a custom plugin for Webpack / Rollup) will generate two artifacts: one is the compiled code (e.g., `dist / index.js`) conforming to the CommonJS / ESM specification and used for `node_modules` references; the other is the micro-module artifact for remote loading, including the code chunk uploaded to the CDN (e.g., `cdn_dist / 1.0.0 / chunk.js`) and the metadata file `meta.json`. 4. Execute `npm publish` to publish the package containing `dist / index.js` and the proxy file to NPM.

[0159] Module user instructions: 1. Execute `npm install lib-new` in your project. 2. In the application entry point `app.js`, write the following code: `const helNode = require('hel-micro-node'); helNode.mapAndPreload({ 'lib-new': 'lib-new'});`

[0160] As an example, the developer created a `pricing-module`. Its `package.json` file's `main` field points to `dist / index.js`, and it also has a `hel_proxy.js` file. After building, `dist / index.js` contains the complete static logic, while the `cdn_dist` directory is uploaded to the CDN. After installation, if `mapAndPreload` is not configured, `require('pricing-module')` will load `dist / index.js`; if mapping is configured, it will load the proxy file `hel_proxy.js` and trigger the remote loading process.

[0161] This end-to-end workflow provides a complete, self-consistent, and developer-friendly solution. By automating the toolchain, it hides the complex dual-identity package building and publishing process from module providers, while offering module users a simple and consistent installation and referencing experience. This allows developers to seamlessly create and use dynamically updated micro-modules without altering their existing development habits (writing, publishing, and installing npm packages), significantly lowering the barrier to entry for the solution.

[0162] In some embodiments, see Figure 11 , Figure 11 This is a schematic diagram of the core entity relationships and interaction principles for realizing dynamic module updates provided in the embodiments of this application. It intuitively demonstrates the technical solution provided in the embodiments of this application, which mainly involves two functional domains: server-side application environment and remote management and resource facilities.

[0163] In a server-side application environment, the core entities include: Scripting language applications: As the end users of the target module, they are the main entities that run the business logic.

[0164] Software Development Kit (SDK): As the core executor of the technical solution of this application, it is integrated into the application and is responsible for intercepting module loading, managing module instances, and executing update logic.

[0165] Proxy module: A stable interface returned by the SDK to the application in response to a loading request, acting as an intermediary layer to decouple business calls from specific module implementations.

[0166] Internal reference: A critical data structure maintained in memory by the SDK, used to dynamically point to the actual instance of the target module that should be executed.

[0167] Target module instance: A real object generated in memory after the target module's code is loaded and executed, containing the actual business logic.

[0168] Module caching: A built-in caching mechanism in scripting language applications used to store loaded module instances.

[0169] In remote management and resource facilities, entities include: Remote module management platform: a management service used for centralized management of module versions and issuing version update commands.

[0170] Resource server: usually a content delivery network (CDN), used to store the code files and metadata of the target modules for each version.

[0171] Figure 11 The numbered arrows clearly illustrate a complete runtime dynamic update process: Before the update, calls from the scripting language application would be forwarded to the old version of the target module instance via a proxy module and internal references. When the remote module management platform issues a version update command, the SDK receives the command, downloads the new version's code from the CDN resource server, loads the code into memory, and generates the new version's target module instance. Subsequently, the SDK performs a crucial switchover operation: first, it clears entries related to the old version from the module cache, and then it updates the internal references to switch the module from the old version instance to the new version instance.

[0172] After the update is complete, subsequent calls to the application, when passing through the same proxy module, will be seamlessly forwarded to the new version of the target module instance for execution, thus achieving real-time updates of business logic without service interruption.

[0173] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0174] This application provides a module dynamic update method and system that can be applied to the backend microservice architecture of large internet enterprises, such as a complex e-commerce platform. In this scenario, there are typically multiple independent Node.js microservice projects (such as order services, user services, and product services), which commonly depend on and share some core business modules (such as pricing and coupon modules, user authentication modules, and risk control rule modules). When the business logic of these shared modules needs urgent updates or fixes, traditional processes require all microservice projects that depend on the module to undergo a complete process of "updating dependencies, rebuilding, and deploying," which is not only time-consuming and labor-intensive but also slow to take effect, making it difficult to cope with rapidly changing market demands. The method provided in this application enables shared modules to "deploy once and take effect in multiple places in real time," achieving second-level version updates, canary rollouts, and rollbacks, greatly improving R&D iteration efficiency and online operation and maintenance capabilities.

[0175] See Figure 4 and Figure 5 , Figure 4 This is a first flowchart illustrating the module dynamic update method provided in this application embodiment. Figure 5 This is a second flowchart illustrating the module dynamic update method provided in this application embodiment. Figure 4 and Figure 5 Together, they constitute the overall flowchart of the module dynamic update method provided in the embodiments of this application. Figure 4 The main demonstration showcased the service initialization and module initial loading process. Figure 5 This demonstrates the dynamic update process of the module at runtime. The steps shown in the figure will be explained below.

[0176] See Figure 4 The service initialization and module loading process is as follows: Step 201: Start the node service.

[0177] In some embodiments, this step is the starting point of the entire process. The user's server-side JavaScript application (i.e., the scripting language application mentioned above), such as the order service of an e-commerce platform, begins executing its startup script.

[0178] Step 202: Load the hel-midro-node SDK (i.e., the software development kit mentioned above) and rewrite the module import mechanism (i.e., the module import mechanism mentioned above).

[0179] In some embodiments, the module user can install the published module by executing the command `npm i lib-new`, and simultaneously install the SDK provided in this application embodiment by executing the command `npm i hel-micro-node`. At the entry point of the application code, the hel-micro-node software development kit is required or imported. Once loaded, the SDK immediately executes its core logic: rewriting the underlying module path resolution function of Node.js (i.e., the original resolution function mentioned above). To achieve this, the SDK first obtains and saves the original module path interpretation function of the Node.js module management object, and then generates a new function (i.e., the new resolution function mentioned above) to replace it, preparing for subsequent module import interception.

[0180] To better understand the SDK's place in the overall architecture, please refer to Figure 6 . Figure 6 This is a schematic diagram of the helpack architecture provided in an embodiment of this application. See also... Figure 6 The developer pushes the code (my application) to the Git repository, triggering Gitook to start an automated build. The build artifacts are separated: module metadata is extracted and stored in a database, while static resource files are versioned and uploaded to a Content Delivery Network (COS / CDN) (i.e., the resource server mentioned above). The management backend reads the metadata from the database, allowing operations personnel to configure versioning policies such as grayscale, full rollout, or rollback. Finally, the running Node.js application pulls the specified version of the module code from the CDN according to the instructions from the management backend.

[0181] Step 203: The user configures the mapping relationship between native modules and micro-modules through the SDK (i.e., the preset micro-module mapping relationship mentioned above).

[0182] In some embodiments, developers can call the configuration function provided by the SDK (i.e., the initialization interface mentioned above) and use the mapAndPreload interface to map the lib-new module name. This means that lib-new can be dynamically updated and needs to be intercepted by the SDK and processed according to the micro-module mechanism. For example, in the order service, configuring {'pricing-module': 'pricing-module'} (this is just an example, it can actually be lib-new) clarifies which dependencies should be removed from the traditional static loading mode.

[0183] Step 204: Importing keywords into the JS module triggers module loading.

[0184] In some embodiments, the business code of the order service executes a statement such as require(“pricing-module”), which triggers the Node.js module loading process (i.e., the loading request mentioned above), which is then taken over by the mechanism rewritten in step 202. Here, “pricing-module” is an exemplary target module (i.e., the target module mentioned above).

[0185] Step 205: Check the micro-module mapping relationship.

[0186] In some embodiments, the SDK's custom parsing function first checks whether the imported module name "pricing-module" exists in the micro-module mapping relationship configured in step 203. If a mapping relationship exists, it is determined to be a micro-module, and the process proceeds to the "Yes" branch; if it does not exist, it is a regular module, and the process proceeds to the "No" branch.

[0187] Before explaining the logic of this branch, it's necessary to understand that the module package provided in this solution has a dual identity (i.e., the dual identity mentioned above). Before proceeding, developers need to initialize and create a compliant module project. For example, they can use the command `pnpm start .create-mod lib-new` to create a new module named `lib-new` within the project. After the code is written, developers can execute the command `pnpm start lib-newbuild:nbsm` to build a package with both traditional package (i.e., the traditional module artifact mentioned above) and micro-module package (i.e., the micro-module artifact mentioned above) identities. Then, by navigating to the `lib-new` directory and executing `pnpm publish`, the module can be published to the repository. For a detailed description of the module package's structure, please refer to [link to documentation / reference]. Figure 7 , Figure 7 This is a schematic diagram of the module construction product provided in the embodiments of this application. For example... Figure 7 As shown, after being processed by the build tool, the module source code is transformed into output forms corresponding to different use cases: One form is the compiled code of an npm module, which is encapsulated in a standard npm package. When a project imports this module as a regular package, the application uses this statically compiled code, which does not have dynamic update capabilities.

[0188] Another form is the micro-module form of this application embodiment. The build tool generates the compiled code of the hel module and uploads it to a remote CDN storage, while simultaneously pushing the module's version metadata to the helpack management console for unified management. The locally distributed npm package contains a corresponding hel module proxy file. When a project is imported as a hel micro-module package, it is actually loading this proxy file.

[0189] During runtime, both server-side and browser-side applications trigger the proxy file's logic when loading this micro-module, sending a request to the CDN storage to retrieve the latest resources (such as "snapshot / index.js" or "snapshot / index.html"). Once an update is detected, the client pulls the new version of the code from the CDN and directly replaces the old version with the new code, thus enabling the business logic to take effect immediately without service interruption.

[0190] Step 206: Check if there is a proxy module.

[0191] In some embodiments, when a module is determined to be a micro-module, the SDK checks whether a corresponding proxy module file (i.e., the proxy module mentioned above) has already been generated for that module in the local file system. The proxy module is a placeholder managed by the SDK; the business code actually requires it.

[0192] Step 207: Generate the proxy module to the hel_modules directory.

[0193] In some embodiments, if the result of the check in step 206 is "none", that is, the micro-module is loaded for the first time, the SDK will dynamically generate a JS file of a proxy module in a specific local directory (such as / .hel_modules / .proxy / ) based on the template.

[0194] Step 208: Obtain the hel_modules proxy module In some embodiments, whether a proxy module is detected in step 206 or a new proxy module is created in step 207, the main process will synchronously return the proxy module.

[0195] Step 209: Write to the js module cache.

[0196] In some embodiments, whether it is a regular module (from step 210) or a proxy module (from step 208), Node.js will write it into its own module cache (require.cache) (i.e., the module cache inside the scripting language application mentioned above) so that subsequent require calls can quickly retrieve it and avoid repeated loading.

[0197] Step 210: Obtain the modules in the node_modules directory.

[0198] In some embodiments, if the result of step 205 is "none", the SDK will call the original module resolution function, following the default behavior of Node.js, and directly load the compiled code of the module from the node_modules directory.

[0199] Step 211: Asynchronously obtain the real module (i.e., asynchronously load the target module as described above).

[0200] In some embodiments, while the main process returns to the proxy module (step 208), the SDK starts an asynchronous task to retrieve the metadata and actual code of the pricing module from a remote CDN. The execution flow of this asynchronous task will then jump to... Figure 5 The area starting with the identifier B.

[0201] Step 212: When calling, query the latest version of the actual module.

[0202] In some embodiments, when business code calls a method on a proxy module, the proxy object intercepts the call, queries the SDK's internally maintained reference to the latest version of the real module, and then forwards the call to that real module instance for execution (i.e., forwarding the call request to the latest version of the real module instance as described above). This process is transparent to the business code.

[0203] Step 213: Asynchronous acquisition of the real module is complete.

[0204] In some embodiments, when the asynchronous task initiated in step 211 (such as...) Figure 5 Once the process within the dashed box is complete, a completion signal will be emitted. This signal indicates that the first version of the actual module has been downloaded and loaded into memory.

[0205] Step 214: Start user business services.

[0206] In some embodiments, the application's main logic waits until all micro-modules configured in step 203 have completed their initial asynchronous acquisition process (i.e., received the signal from step 213) before actually starting the core business service (such as starting an HTTP server to listen on a port). This ensures that all dependencies are ready before the service is made available to the outside world.

[0207] Step 215: Import modules at the business layer.

[0208] In some embodiments, after the user business service starts, each business logic file begins to execute, and the require or import statements inside them will directly obtain the corresponding module (ordinary module or proxy module) from the cache written in step 209 and use it.

[0209] See the following procedure. Figure 5 , Figure 5 The runtime dynamic update process is demonstrated as follows: Step 301: Start the socket connection helpack and listen for module version change signals (i.e., the version update command mentioned above).

[0210] In some embodiments, this step is performed during service initialization (corresponding to...). Figure 4 The SDK client establishes a persistent long connection (i.e., the persistent communication link) based on a socket between the SDK client and the helpack control console (i.e., the remote module control platform mentioned above) to receive instructions from the server in real time.

[0211] Step 302: Module version switching is detected.

[0212] In some embodiments, after the operation and maintenance personnel operate on the control console, the SDK client receives a signal of a specific module version change through a long connection, thereby triggering this step and starting the dynamic update process.

[0213] Step 303: If a custom rule is hit, decide whether to accept the current version.

[0214] In some embodiments, the SDK determines whether the current service instance should perform this update based on locally preset canary release rules (i.e., the custom rules mentioned above) (e.g., only allowing instances with specific IP addresses or user identifiers to update). If the determination is "no", the process jumps to step 3015 and ends.

[0215] Step 304: Does the version exist in the module download area?

[0216] In some embodiments, if the instance accepts an update, the SDK first checks whether the target version of the code has already been downloaded from the local cache directory (i.e., the local cache mentioned above) (e.g., / .hel_modules / ). If yes, the download can be skipped and the loading process can proceed directly; if no, it needs to be downloaded from a remote location.

[0217] Step 305: Download the module source code (i.e., the code of the new version specified in the above-mentioned version update command).

[0218] In some embodiments, if the target version does not exist locally, the SDK will download the new version of the module source code file from the CDN based on the network address in the metadata.

[0219] Step 306: Versioned storage in the hel_modules directory In some embodiments, the downloaded source code files are stored in a specific local directory according to their version number, such as / .hel_modules / pricing-module / v2 / , for subsequent loading and version management.

[0220] Step 307: Check if the version directory exceeds the limit. In some embodiments, to prevent the local cache from growing indefinitely, the SDK checks whether the number of versions currently cached exceeds a preset limit.

[0221] Step 308: Clear the current module cache.

[0222] In some embodiments, this is a crucial step for dynamic updates. The SDK uses deleterequire.cache[' / path / to / old_version_module.js'] to clear old version module instances cached in Node.js memory, clearing the way for loading new version modules.

[0223] Step 309: Export the module using the downloaded source code file (i.e., the new version instance built based on the new version of the code mentioned above).

[0224] In some embodiments, the SDK loads newly downloaded local code files (corresponding to...) via require. Figure 5 The identifier C), thereby generating a new module instance in memory.

[0225] Step 310: Replace with the latest version of the module In some embodiments, users (or SDK internal automation processes) can use the importMod interface provided by hel-micro-node to switch the version of the lib-new module at runtime. The SDK updates its internal references (i.e., the internal references of the updated proxy module mentioned above), pointing the proxy module to the new version module instance created in step 309 (corresponding to...). Figure 5 (Identifier D). At this point, the core process of dynamic updates is complete, and all subsequent calls through the proxy module will execute the new version of the code.

[0226] Step 311: Remove the oldest directory.

[0227] In some embodiments, if the result of step 307 is "yes", the SDK will delete the least frequently used old version code directory locally according to a specific strategy (such as LRU, Least Recently Used) to free up disk space.

[0228] Step 312: Check the actual module.

[0229] In some embodiments, this step serves as the entry point for concurrency control. Before performing a download or load, the SDK checks the current state of the module.

[0230] Step 313: Is it being processed?

[0231] In some embodiments, this step determines whether the module is in a "downloading" or "loading" processing state. If the determination result is "yes", it indicates that there are concurrent operations, and the process enters a waiting state.

[0232] Step 314: Wait for the source code files to download.

[0233] In some embodiments, if a module is detected to be being processed, the current process is paused and waits for the previous task to complete before continuing, thereby ensuring the atomicity and stability of the update process.

[0234] Step 315: End.

[0235] In some embodiments, if the rule check in step 303 fails, the update process will terminate here, and the current service instance will not be updated.

[0236] Step 316: The helpack module control console receives and sends information.

[0237] In some embodiments, the helpack module control console acts as a central node, responsible for receiving and sending information. It receives instructions from the user's operating platform regarding version changes and notifies all connected SDK clients of the version change via a persistent connection.

[0238] The user interface of the helpack module control console can be found here. Figure 8 . Figure 8 This is a schematic diagram of the application store interface of the module management platform provided in this application embodiment. See also... Figure 8 The top of the interface provides navigation tabs such as "App Store", "Create App" and "My Category" to facilitate quick switching between function areas for maintenance personnel.

[0239] In the main operation area, maintenance personnel can enter keywords in the "Application Name" input box to perform fuzzy searches, and click the "Query" button to filter applications, or click the "Refresh" button to update the list. The interface displays the released micro-module applications in a grid card format at the bottom. These applications cover different business areas, including: WeData Big Data series applications, TDS Financial Risk Control series applications, News Portal series applications, and the general "media-components-common" application. Among them, the WeData Big Data series applications include "wedata-studio" (WeData Data Development), "wedata-dataservice-dev" (Data Service Development Environment), "wedata-do" (WeData Data Development), "wedata Data Development" (WeData Data Service Application), "wedata-dataplan" (WeData Data Planning), "wedata-dq" (WeData Data Quality), and "wedata-exploration" (WeData Data Exploration); the TDS Financial Risk Control series applications include "aml-cis-web" (Anti-Money Laundering CIS Service Front-End Module) and "risk-aggregate-web" (Micro-Front-End for Authorized Inquiry, Freezing, and Deduction); and the News Portal series applications include "qqnews-pc-channel" (News Channel Page) and "qqnews-pc-dc" (News PC-dc). Each application card clearly displays key metadata such as its "App ID", "Latest Version", "Owner" (e.g., "hel"), "Create At", and "App Type". Through these cards, operations personnel can not only monitor the module status globally, but also click to enter the details page to perform fine-grained operations such as canary releases and version rollbacks.

[0240] The efficiency improvement brought about by this dynamic update mechanism can be achieved through… Figure 9 and Figure 10 Make a direct comparison. Figure 9This is a schematic diagram of the traditional mode release process provided in the embodiments of this application. Figure 10 This is a schematic diagram of the micro-module mode release process provided in the embodiments of this application. Figure 9 It demonstrates the "traditional deployment process," where after an npm module is changed, it needs to be built and published, and then all projects that depend on it need to be reinstalled and redeployed. Figure 10 The presentation showcased the "HEL micro-module deployment process," demonstrating that after a module change, a single dynamic update applies the change directly to all projects. This demonstrates how this solution simplifies the N+1 deployment process into a single deployment, significantly improving efficiency.

[0241] To illustrate the module dynamic update method provided in this application embodiment more specifically, the following will describe it through a specific scenario of a large-scale Internet business platform.

[0242] This application's embodiments involve the following entities and their states at an initial time point: Application service example: Three independent Node.js application processes, as components of a microservice architecture, are as follows: Order Service: Deployed at network address 10.0.0.1, its function is to handle order creation and calculation.

[0243] Product services: Deployed on network address 10.0.0.2, its function is to provide product information query.

[0244] Marketing service: Deployed at network address 10.0.0.3, its function is to perform marketing logic calculations.

[0245] Shared business module: A target module named promotion-calculation-module, which is depended on by the three services mentioned above.

[0246] Initial version: 1.0.0, its function is to implement the calculation logic of "price x 0.9".

[0247] Initial state: The code resources for this version have been stored on a Content Delivery Network (CDN), its version metadata has been registered on a remote module management platform, and it has been marked as the current stable online version.

[0248] Software Development Kit (SDK): A library called hel-micro-node is integrated into the runtime environment of each of the above application service instances.

[0249] In the initial system state (t=0), the three instances—Order Service, Product Service, and Marketing Service—are all running stably. Each instance's SDK has been initialized and has loaded version 1.0.0 of the promotion-calculation-module as the currently executing business logic. Simultaneously, each instance's SDK maintains a persistent WebSocket connection with the remote module management platform to receive update commands at any time.

[0250] Phase 1: System Initialization and Initial Module Loading Process (e.g.) Figure 4 (As shown).

[0251] This phase describes the internal process of any application service instance (taking "Order Service" as an example) from startup to stable service provision.

[0252] First, during the process startup and SDK initialization phase (such as...) Figure 4 As shown in steps 201 and 202, the order service process is started. Its entry script first loads the hel-micro-nodeSDK. When the SDK is loaded, it executes initialization logic: it accesses the internal module loading mechanism of the Node.js runtime, saves the reference to the original `Module._resolveFilename` function, and replaces it with a new function defined by the SDK that has interception capabilities. This behavior ensures that all subsequent module resolution requests will be handled by the SDK first.

[0253] Secondly, in the mapping configuration and preloading triggering phase (such as...) Figure 4 As shown in steps 203 and 214, the business startup script of the order service calls the configuration interface provided by the SDK, passing in a mapping relationship that maps the logical module name promotion-calculation-module to its own identifier. The SDK receives this configuration, registers promotion-calculation-module as a dynamically managed module, blocks the startup process of the business service, and instead executes the preloading task.

[0254] Next, during the module preloading execution phase (as shown in steps 211 and 213 of section 4), the SDK initiates an asynchronous task to obtain the actual module of `promotion-calculation-module`. It requests the online stable version information of this module from the remote module management platform, which returns version number 1.0.0 and its metadata. Based on the metadata, the SDK requests the download of the version 1.0.0 code file from the CDN and stores it in a versioned cache directory on the local file system. After the download is complete, the SDK loads the local file using Node.js's require mechanism, generating a version 1.0.0 module instance and caching this instance in an internal module mapping table. With the preloading task complete, the SDK releases its blocking of the business service startup process. The order service continues to execute subsequent logic, ultimately starting its HTTP service port.

[0255] Subsequently, during the runtime module import and proxy module generation phase (such as...) Figure 4 (Steps 204-209) The order service's business logic executes `require('promotion-calculation-module')` for the first time. The SDK's interceptor function captures this request. By checking the internal registration information, it determines that it is a managed module. The SDK checks the local proxy module directory; if the proxy module does not yet exist, it dynamically generates a proxy module file. The exported object of this proxy module is a proxy instance, and all its method calls are forwarded to the SDK's internal handler. The SDK's interceptor function ultimately returns the path of this proxy module to the upper-level `require` mechanism. Node.js loads this proxy module and returns it to the business logic.

[0256] Finally, in the phase of executing business calls through a proxy (such as...) Figure 4 (As shown in step 212), the business logic of the order service calls the method provided by the proxy module. This call is intercepted by the SDK's proxy handler. The handler queries its internal module mapping table to obtain the currently active 1.0.0 version module instance and forwards the call parameters to the corresponding method of that instance for execution. The execution result is finally returned to the business logic along the call chain. By introducing the proxy module, the business code is completely decoupled from the specific module implementation version, providing a foundation for subsequent seamless dynamic updates.

[0257] Phase Two: The process of building and releasing new version modules (e.g.) Figure 7 , Figure 10 (As shown).

[0258] This section describes the generation and registration process of the new version 1.1.0 of the promotion-calculation-module.

[0259] First, in the module building phase ( Figure 7 The module development and build system processes the source code of the promotion-calculation-module, generating a build artifact with version number 1.1.0. This artifact has a dual structure: one is a static file that conforms to the Node.js general module specification and can be used for local development and debugging; the other is a micro-module file specifically for dynamic distribution, containing versioned code and a metadata file.

[0260] Secondly, during the module release phase (such as...) Figure 10 As shown, the module release tool executes the release process. It first pushes the micro-module code file for version 1.1.0 to the CDN. Then, the tool parses the metadata file and sends a request to the API of the remote module management platform to register version 1.1.0 as a new available version. (Comparison) Figure 9 Compared to the traditional process shown, this release mode centralizes version updates within the module itself, avoiding the complex process of modifying and redeploying each of the N dependencies, thus significantly improving operational efficiency.

[0261] Phase Three: Dynamic Version Update Process for Online Services (e.g.) Figure 5 , Figure 6 , Figure 8 (As shown).

[0262] This section describes the internal automated process for all online service instances from receiving instructions to completing module updates.

[0263] First, in the instruction issuance phase ( Figure 8 , Figure 6 , Figure 5 In step 316), the remote module management platform receives an external instruction to update the online stable version identifier of the promotion-calculation-module from 1.0.0 to 1.1.0. The platform immediately broadcasts a version update instruction to all application service instances that have subscribed to the module via all established WebSocket connections. This instruction includes the module name and the new version number 1.1.0.

[0264] Secondly, in the instruction receiving and update decision-making stage (such as...) Figure 5 As shown in steps 301-303, within the order, product, and marketing service instances, the SDK receives the instruction via a WebSocket connection. The SDK checks the internally configured canary release strategy. In this embodiment, there are no special rules, therefore it is determined to be a full update, the decision result is "yes," and the update process continues.

[0265] Secondly, in the new version acquisition and caching phase ( Figure 5(Steps 304-306) The SDK checks its local versioned cache directory and finds that version 1.1.0 does not exist. The SDK requests and downloads the code file for version 1.1.0 from the CDN and stores it in the corresponding local cache path.

[0266] Subsequently, during the old version cleanup and new version loading phase (such as...) Figure 5 As shown in steps 308-309, the SDK removes the entry from Node.js's `require.cache` whose key is the absolute path to the old version 1.0.0 code file. This step removes the runtime's memory reference to the old version module instance, which is crucial for achieving hot replacement. Then, the SDK loads the 1.1.0 version file that was just downloaded locally via the `require` mechanism, thereby generating a new 1.1.0 version module instance in memory.

[0267] Finally, during the internal reference switching phase (such as...) Figure 5 In step 310, the SDK updates its internally maintained module mapping table, switching the reference of the module instance corresponding to the logical name `promotion-calculation-module` from the old version 1.0.0 instance to the newly generated version 1.1.0 instance. The update process is now complete. The entire process is executed asynchronously in the background of the service process, without interrupting any ongoing business requests. Newly arriving business requests will be seamlessly routed to the new version instance through the proxy module.

[0268] Phase 4: Verification of the updated system status.

[0269] This section describes the system's behavior after the version update is completed.

[0270] First, a new business request arrives at the order service. Second, the service's business logic again calls the method of the proxy module returned by `require('promotion-calculation-module')`. At this point, the SDK's proxy handler intercepts this call, queries the internal module mapping table, and obtains the updated version 1.1.0 module instance. Then, the call is forwarded to the version 1.1.0 instance, which executes the new tiered discount business logic and returns the calculation result. Finally, the system behavior is confirmed: all application service instances have uniformly and in real-time switched to version 1.1.0 of the `promotion-calculation-module` without restarting processes and are correctly executing their business logic.

[0271] The following continues to describe the exemplary structure of the implementation of the update module device 133 in the scripting language application of the server provided in the embodiments of this application as a software module. In some embodiments, such as Figure 2As shown, the software module stored in the memory 130 in the scripting language application update module device 133 on the server may include: Interception unit 1331 modifies the module import mechanism built into the scripting language application to intercept loading requests for the target module issued by the scripting language application. The loading unit 1332 is used to return a proxy module to the scripting language application and asynchronously load the code of the target module based on the metadata obtained from the remote module management platform, so as to serve as the execution entity of the proxy module; Update unit 1333 is configured to perform the following update process in response to a version update instruction for the target module: obtain the code of the new version specified by the version update instruction; clear instances related to the old version of the target module from the module cache inside the scripting language application; and update the internal reference of the proxy module so that the internal reference points to the newly loaded instance of the new version based on the new version of the code.

[0272] In some embodiments, the interception unit 1331 is further configured to: when the scripting language application starts, obtain its built-in module path resolution function as the original resolution function and save it, and replace the original resolution function with a new resolution function; wherein, the new resolution function is configured to: when the loading request is intercepted, if the target module targeted by the loading request does not exist in the preset micro-module mapping relationship, call the original resolution function to load the local module; if the target module exists in the micro-module mapping relationship, execute the step of returning the proxy module to the scripting language application.

[0273] In some embodiments, the interception unit 1331 is further configured to: before the core business logic of the scripting language application starts, call the initialization interface provided by the software development kit, wherein the initialization interface is configured to receive the micro-module mapping relationship as input parameters, trigger the first asynchronous loading of all target modules in the micro-module mapping relationship, and wait for all the asynchronous loading tasks to be completed before ending execution.

[0274] In some embodiments, the interception unit 1331 is further configured to: write the proxy module into the module cache of the scripting language application after returning the proxy module; and write the local module into the module cache of the scripting language application after loading the local module.

[0275] In some embodiments, the loading unit 1332 is further configured to: establish a persistent communication link with the remote module management platform, through which the version update instruction can be received.

[0276] In some embodiments, the version update instruction is received from the remote module management platform, and before executing the update process, the loading unit 1332 is further configured to: make an update decision based on preset custom rules, wherein the custom rules include canary release rules or version locking rules; if the update decision result indicates acceptance of this version update, the update process continues to be executed; if the update decision result indicates rejection, the update process is stopped.

[0277] In some embodiments, the loading unit 1332 is further configured to: when the target module is loaded for the first time, the proxy module is dynamically generated locally by the software development kit according to the template and stored in a preset proxy module directory.

[0278] In some embodiments, the metadata in the loading unit 1332 is stored in a metadata file, which includes at least: application data and version data; the version data includes: product version number, root path of resource server and path list of all code files of target module.

[0279] In some embodiments, the update unit 1333 is further configured to: query the new version of the code from the local cache; if the new version of the code is not found, download the new version of the code from the resource server and store the new version of the code in the local cache in a versioned manner; if the new version of the code is found, directly use the new version of the code in the local cache.

[0280] In some embodiments, after the new version of the code is versioned and stored in the local cache, the update unit 1333 is further configured to: check the number of version directories in the local cache; if the number of version directories exceeds a preset limit, remove at least one of the oldest version directories so that the number of version directories in the local cache does not exceed the preset limit.

[0281] In some embodiments, the instance of the new version built based on the new version of the code in the update unit 1333 is a module object exported after the new version of the code is executed by the module loading function of the scripting language application.

[0282] In some embodiments, before asynchronously loading the code of the target module, the loading unit 1332 is further configured to: check the status of the asynchronous loading task for the target module; if the asynchronous loading task is in progress, suspend the current loading request to put it into a waiting state until the asynchronous loading task is completed; if the asynchronous loading task is not in progress, start the asynchronous loading task for the code.

[0283] In some embodiments, the loading unit 1332 is further configured to: when the proxy module receives a call request from the scripting language application, query the internal reference maintained within the software development kit that points to the latest version of the real module instance through the proxy module, and forward the call request to the latest version of the real module instance for execution through the internal reference.

[0284] In some embodiments, when the target module is a shared business module that is simultaneously depended upon by multiple scripting language application projects, after the code of the target module is changed, the update unit 1333 is further configured to: publish the changed code of the target module to the remote module management platform, and in each scripting language application, the software development kit performs the module update process.

[0285] In some embodiments, the loading unit 1332 further includes an end-to-end workflow covering both the module provider and the module user. The end-to-end workflow includes: a module preparation workflow executed by the module provider, comprising: initializing a micro-module project via a command-line tool and writing source code within the micro-module project; executing a build command to generate a package body as a release form of the target module, the package body having dual identities, including a traditional module artifact for static reference and a micro-module artifact for dynamic loading, the micro-module artifact containing at least a metadata file; and publishing the dual-identity package body to a package manager repository; and a module integration workflow executed by the module user, comprising: installing the package body from the package manager repository as the target module; and in the scripting language application, calling an interface provided by the software development kit to establish a mapping between the name of the target module and the micro-module artifact.

[0286] In some embodiments, the version update instruction of the update unit 1333 is generated and sent by the remote module management platform after receiving a version change operation issued through the visual interface; or, the version update instruction is generated by the internal code of the scripting language application by calling the version switching interface provided by the software development kit to request the loading of a specific version of the target module.

[0287] This application provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the method described above in a scripting language application on a server.

[0288] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the update module method in a scripting language application on a server provided in this application, for example, such as... Figure 3A This illustrates a method for updating modules in a server-side scripting language application.

[0289] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0290] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0291] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0292] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0293] In summary, this application provides a complete technical solution for dynamically updating modules in a server-side scripting language application. This solution introduces a lightweight software development kit (SDK) to rewrite the underlying module import mechanism in a non-intrusive manner and utilizes a proxy module to provide a stable intermediary for accessing target modules. This enables the application to replace module code in real-time via remote command responses without restarting the service process, achieving second-level version releases, canary deployments, and rollbacks, significantly improving the efficiency of business iteration and the flexibility of online operations and maintenance. Furthermore, the dual-identity package scheme proposed in this application balances the dynamism of the production environment with the native experience of the local development environment. Without altering the developer's original workflow, it endows the server-side application with powerful micro-modularization and dynamic update capabilities, ultimately enhancing the agility and robustness of the entire R&D system while ensuring high service availability.

[0294] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for updating modules in a scripting language application on a server, characterized in that, The method, which integrates a software development kit (SDK) into the scripting language application, includes: the SSD performing the following module update process: Modify the module import mechanism built into the scripting language application to intercept loading requests for the target module issued by the scripting language application; The proxy module is returned to the scripting language application, and the code of the target module is asynchronously loaded based on the metadata obtained from the remote module management platform, so as to serve as the execution entity of the proxy module; In response to a version update instruction for the target module, the following update processes are performed: obtaining the code of the new version specified by the version update instruction; clearing instances related to the old version of the target module from the module cache within the scripting language application; and updating the internal references of the proxy module so that the internal references point to the newly loaded instance of the new version built based on the new version of the code.

2. The method according to claim 1, characterized in that, The modification of the built-in module import mechanism of the scripting language application includes: When the scripting language application starts, its built-in module path resolution function is obtained and saved as the original resolution function, and then the original resolution function is replaced with a new resolution function. The new parsing function is configured to: when the loading request is intercepted, If the target module for which the loading request is directed does not exist in the preset micro-module mapping relationship, then the original parsing function is invoked to load the local module; If the target module exists in the micro-module mapping relationship, then the step of returning the proxy module to the scripting language application is executed.

3. The method according to claim 2, characterized in that, The method further includes: Before the core business logic of the scripting language application starts, the initialization interface provided by the software development kit is called. The initialization interface is used to receive the micro-module mapping relationship as input parameters, trigger the first asynchronous loading of all target modules in the micro-module mapping relationship, and wait for all the asynchronous loading tasks to be completed before ending the execution.

4. The method according to claim 2, characterized in that, The method further includes: After returning the proxy module, the proxy module is written into the module cache of the scripting language application; After loading the local module, the local module is written into the module cache of the scripting language application.

5. The method according to claim 1, characterized in that, The method further includes: A persistent communication link is established with the remote module management platform, through which the version update command can be received.

6. The method according to claim 1, characterized in that, The version update instruction is received from the remote module management platform, and before executing the update process, the method further includes: Update decisions are made based on preset custom rules, wherein the custom rules include canary release rules or version locking rules; If the update decision result indicates acceptance of the update, the update process continues; if the update decision result indicates rejection, the update process terminates.

7. The method according to claim 1, characterized in that, The proxy module is dynamically generated locally by the software development kit based on a template and stored in a preset proxy module directory when the target module is loaded for the first time.

8. The method according to claim 1, characterized in that, The metadata is stored in a metadata file, which contains at least: application data and version data; the version data includes: the artifact version number, the root path of the resource server, and a list of paths to all code files of the target module.

9. The method according to claim 1, characterized in that, The code for obtaining the new version specified by the version update instruction includes: Retrieve the code for the new version from the local cache; If the new version of the code is not found, the new version of the code is downloaded from the resource server and stored in the local cache in a versioned manner. If the new version of the code is found, the locally cached version of the new version of the code will be used directly.

10. The method according to claim 9, characterized in that, After storing the new version of the code in the local cache in a versioned manner, the method further includes: Check the number of version directories in the local cache; If the number of version directories exceeds a preset limit, at least one of the oldest version directories is removed so that the number of locally cached version directories does not exceed the preset limit.

11. The method according to claim 1, characterized in that, The instance of the new version built based on the new version of the code is a module object exported after the new version of the code is executed by the module loading function of the scripting language application.

12. The method according to claim 1, characterized in that, Before asynchronously loading the code of the target module, the method further includes: Check the status of the asynchronous loading task for the target module; If the asynchronous loading task is in progress, the current loading request is suspended to put it into a waiting state until the asynchronous loading task is completed; If the asynchronous loading task is not in progress, then the asynchronous loading task for the code is started.

13. The method according to claim 1, characterized in that, The method further includes: When the proxy module receives a call request from the scripting language application, it queries the internal reference maintained within the software development kit that points to the latest version of the real module instance, and forwards the call request to the latest version of the real module instance for execution through the internal reference.

14. The method according to any one of claims 1 to 13, characterized in that, When the target module is a shared business module that is depended upon by multiple scripting language application projects, the method further includes the following after the code of the target module is changed: The modified code of the target module is published to the remote module management platform, and the module update process is executed by the software development kit in each scripting language application.

15. The method according to any one of claims 1 to 13, characterized in that, The method further includes: The end-to-end workflow covers both the module provider and the module user; The end-to-end workflow includes: The module preparation workflow executed by the module provider includes: initializing a micro-module project via a command-line tool and writing source code in the micro-module project; executing a build command to generate a package body as the release form of the target module, the package body having dual identities, wherein the dual identities include a traditional module artifact for static reference and a micro-module artifact for dynamic loading, the micro-module artifact containing at least a metadata file; and publishing the package body with dual identities to a package manager repository. The module integration workflow executed by the module user includes: installing the package body from the package manager repository as the target module; and calling the interface provided by the software development kit in the scripting language application to establish a mapping relationship between the name of the target module and the micro-module artifact.

16. The method according to any one of claims 1 to 13, characterized in that, The version update instruction is generated and sent by the remote module management platform after receiving the version change operation issued through the visual interface, or... The version update instruction is generated by the internal code of the scripting language application by calling the version switching interface provided by the software development kit to request the loading of a specific version of the target module.

17. An apparatus for updating modules in a scripting language application on a server, characterized in that, The software development kit is integrated into the scripting language application, and the device includes: The software development kit performs the following module update process: The interception unit is used to modify the module import mechanism built into the scripting language application to intercept the loading request for the target module issued by the scripting language application. The loading unit is used to return a proxy module to the scripting language application and asynchronously load the code of the target module based on the metadata obtained from the remote module management platform, so as to serve as the execution entity of the proxy module; An update unit is configured to, in response to a version update instruction for the target module, perform the following update processes: obtain the code of the new version specified by the version update instruction; clear instances related to the old version of the target module from the module cache within the scripting language application; and update the internal references of the proxy module so that the internal references point to the newly loaded instance of the new version built based on the new version of the code.

18. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method according to any one of claims 1 to 16.

19. A computer-readable storage medium, characterized in that, It stores executable instructions for implementing the method of any one of claims 1 to 16 when executed by a processor.

20. A computer program product comprising a computer program or computer-executable instructions, characterized in that, When the computer program or computer-executable instructions are executed by a processor, they implement the method according to any one of claims 1 to 16.

Images