Method, device and storage medium for managing front-end static resources

Abstract

This disclosure provides a method, apparatus, device, and storage medium for managing front-end static resources, relating to the field of computer technology, and particularly to front-end service deployment technology. The specific implementation scheme is as follows: applied to a front-end service system containing a front-end service carrier, the front-end service carrier being used to carry front-end services for multiple applications, including: receiving front-end static resources from the multiple applications; deploying the front-end static resources of the multiple applications to preset storage locations, the storage locations being physically separated from the deployment location of the front-end service carrier; establishing a mapping relationship between the static resource access path of the front-end service carrier and the physical storage path of the storage location, enabling the front-end service carrier to access the front-end static resources corresponding to each application in the storage location based on the mapping relationship. This method achieves independent deployment and management of front-end static resources and the front-end service carrier.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to front-end service deployment technology, specifically to a method, apparatus, device, and storage medium for managing front-end static resources. Background Technology

[0002] In the field of multi-application front-end service deployment, to support the operation of front-end services for multiple applications, it is necessary to manage the front-end static resources of various applications. Existing technologies typically employ a solution of packaging and integrating all application front-end static resources with the carrier providing the front-end services. Specifically, the front-end static resources are embedded in the carrier service's file directory, and both are distributed and installed through the same deployment unit, thus forming a tightly coupled binding relationship at the physical level. Summary of the Invention

[0003] This disclosure provides a method, apparatus, device, and storage medium for managing front-end static resources.

[0004] According to one aspect of this disclosure, a method for managing front-end static resources is provided. The method is applied to a front-end service system containing a front-end service carrier, the front-end service carrier being used to support front-end services for various applications, including: Receive front-end static resources from the aforementioned applications; The front-end static resources of the various applications are deployed to preset storage locations, and the storage locations are physically separated from the deployment locations of the front-end service carriers. Establish a mapping relationship between the static resource access path of the front-end service carrier and the physical storage path of the storage location, so that the front-end service carrier can access the front-end static resources corresponding to each application in the storage location based on the mapping relationship.

[0005] According to another aspect of this disclosure, a management device for front-end static resources is provided. The device is configured in a front-end service system including a front-end service carrier, the front-end service carrier being used to carry front-end services for various applications, including: The receiving unit is configured to receive front-end static resources of the various applications; The deployment unit is configured to deploy the front-end static resources of the various applications to preset storage locations, wherein the storage locations are physically separated from the deployment locations of the front-end service carriers. The mapping establishment unit is configured to establish a mapping relationship between the static resource access path of the front-end service carrier and the physical storage path of the storage location, so that the front-end service carrier can access the front-end static resources corresponding to each application in the storage location based on the mapping relationship.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the methods described in the embodiments of this disclosure.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are configured to cause the computer to perform the methods described in embodiments of this disclosure.

[0008] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the methods described in the embodiments of this disclosure.

[0009] This disclosure decouples static resources from carrier services at the architectural level by physically separating and deploying the front-end static resources of various applications in independent storage locations and establishing path mappings for the front-end service carriers to access these storage locations. This solution decouples the storage location of front-end static resources from the deployment of the front-end service carriers, thereby enabling independent deployment and management of front-end static resources and front-end service carriers, significantly improving the efficiency, reliability, and flexibility of multi-application front-end service deployment and maintenance.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure.

[0012] Figure 1 This is a flowchart of the management method for front-end static resources provided in this public document.

[0013] Figure 2 This is a schematic diagram of the architecture of the front-end service system provided in this public document.

[0014] Figure 3 This is a schematic block diagram of the front-end static resource management device provided in this disclosure.

[0015] Figure 4 This is a block diagram of an electronic device used to implement the front-end static resource management method of the embodiments of this disclosure. Detailed Implementation

[0016] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0017] In the field of front-end service deployment for multiple applications, to provide unified and efficient front-end page access capabilities for multiple different business applications, existing technologies commonly adopt the technical solution of building an integrated service carrier. Specifically, this solution packages the core program carrying the front-end service and the front-end static resource files of each application into the same deployment unit; during the operation of the service carrier, it reads from its internal fixed directory and provides static resource access services externally. This solution has become a common technical approach in the industry because it simplifies the deployment architecture and enables unified management.

[0018] However, in scenarios where multiple applications iterate in parallel and require frequent, independent updates to the front-end static resources of individual applications, the above solution has significant applicability limitations. The core issue lies in the design approach adopted to simplify the deployment process, which significantly reduces the flexibility and isolation of static resource updates and easily leads to the spread of upgrade risks. Specifically, because front-end static resources are physically coupled with the service carrier, updating any application's static resources requires replacing the entire deployment package, including the service carrier. This not only expands the scope of upgrades from a single application resource to the entire service carrier and all application resources, but also causes the costs of backup, transmission, and verification to increase linearly with the number of applications. A single application's update defect can affect the normal operation of other applications.

[0019] In view of this, this disclosure provides a method for managing front-end static resources. This method is applied to a front-end service system that includes a front-end service carrier, which is used to host front-end services for various applications. This method for managing front-end static resources can be executed by an electronic device capable of data processing, including but not limited to mobile phones, tablets, personal computers, servers, smart terminals, or dedicated computing devices.

[0020] In some embodiments, the steps of the method may be performed by a virtual server or container instance deployed on a cloud platform.

[0021] In this context, the front-end service carrier refers to any software component or deployment unit used to host and provide the runtime environment and access capabilities for front-end services. For example, it can include, but is not limited to: service instances deployed based on container technology (such as Docker) that integrate static file servers (such as Nginx) and network port listening functions; or web application servers (such as Apache Tomcat, Node.js services) deployed on virtual machines or physical servers; or service modules in a microservice architecture specifically designed to handle front-end requests. Its core function is to respond to client requests and provide front-end static resources based on configured path mapping relationships.

[0022] Front-end static resources refer to resource files required to form the user interface of a front-end application, which are parsed, executed, or rendered by the browser on the client side. The content of these files typically does not need to be dynamically generated on the server side for each request. Front-end static resources can include, but are not limited to: Hypertext Markup Language files, Cascading Style Sheets (CSS) files, JavaScript files, image files, font files, icon files, and static data files used for configuration or data exchange.

[0023] Hypertext Markup Language (HTML) files define the structure and content of a webpage; Cascading Style Sheets (CSS) files control the layout and visual presentation; and JavaScript files implement the interactive logic and dynamic behavior of the webpage. Image files, font files, and icon files enrich the visual elements of the page. Static data files, such as JSON or XML files, can be used to store initial configurations, localized text, or structured data that does not change frequently. These resources collectively constitute the complete interface and interactive experience that users see when accessing the application through a browser.

[0024] Figure 1 A flowchart of the front-end static resource management method provided in the embodiments of this disclosure is shown below. Figure 1 As shown, the method may include the following steps: Step 101: Receive front-end static resources from various applications.

[0025] Step 102: Deploy the front-end static resources of various applications to preset storage locations, which are physically separated from the deployment location of the front-end service carrier.

[0026] Step 103: Establish a mapping relationship between the static resource access path of the front-end service carrier and the physical storage path of the storage location, so that the front-end service carrier can access the front-end static resources corresponding to each application in the storage location based on the mapping relationship.

[0027] As can be seen from the above process, this disclosure decouples static resources from carrier services at the architectural level by physically separating and deploying the front-end static resources of various applications in independent storage locations and establishing path mappings for the front-end service carrier to access these storage locations. This solution decouples the storage location of front-end static resources from the deployment of the front-end service carrier, thereby achieving independent deployment and management of front-end static resources and the front-end service carrier, significantly improving the efficiency, reliability, and flexibility of multi-application front-end service deployment and maintenance.

[0028] The following describes in detail each step of the above process and the effects that can be further produced, with reference to the embodiments.

[0029] First, the above step 101, namely "receiving front-end static resources of various applications", will be described in detail with reference to the embodiments.

[0030] In the embodiments of this disclosure, front-end static resources can originate from the build artifacts of the continuous integration / continuous deployment (CI / CD) pipelines of various product teams. Specifically, after a product completes the development and building of its front-end code, its build system generates an output directory containing all front-end static resources for that product. The management system or deployment process receives these output directories.

[0031] In some implementations, the received data may be a compressed archive (such as a .tar.gz or .zip file). In other implementations, it may be a file system directory already organized according to a specific directory structure. Regardless of the form, the core objective is to obtain a collection of static files belonging to a specific application that can be directly accessed via the web.

[0032] Furthermore, when receiving front-end static resources from multiple applications, it can also receive version information corresponding to each front-end static resource. This version information may include the version number and / or version update time, etc.

[0033] It should be noted that the version information can be carried in JSON, TXT, YAML format, or encoded in the meta tags of an HTML file; the version number can adopt semantic versioning or other industry-standard rules.

[0034] The following describes in detail step 102, namely "deploying the front-end static resources of various applications to preset storage locations, which are physically separated from the deployment location of the front-end service carrier," with reference to the embodiments.

[0035] In the embodiments of this disclosure, the received front-end static resources of each application are deployed to preset storage locations. The preset storage location is a file system path determined during the planning phase that is independent of the front-end service carrier runtime instance; while physical separation means that the storage location is not the internal file system (such as a directory within a container) of the front-end service carrier runtime, but rather a host directory, independent storage volume, or remote storage service outside the front-end service carrier.

[0036] Furthermore, to achieve resource organization and isolation, a separate subdirectory is typically created for each application under the storage location. The front-end static resources of the corresponding application are deployed to this subdirectory (e.g., if the storage location is / opt / frontend-static / , then / opt / frontend-static / app_a / is created for application A, and the front-end static resources of application A are placed there; / opt / frontend-static / app_b / is created for application B, and the front-end static resources of application B are placed there). This deployment method ensures that the front-end static resources of each application are isolated on physical storage.

[0037] One feasible approach is to configure a unique application identifier for each application. Based on this identifier, a corresponding storage subdirectory is created under the physical storage path of the storage location, and the front-end static resources of each application are deployed to their respective storage subdirectories. The application identifier can be the product's English name, project code, or a unique string ID. Based on the application identifier specified when receiving front-end static resources / parsed from the resource package, a subdirectory with the same name is created under the root storage path, and the resources are unzipped / copied to this subdirectory, thereby avoiding file naming conflicts between different applications.

[0038] It should be noted that deploying front-end static resources to an independent storage location can be achieved in ways including but not limited to local directory deployment, as well as through object storage services, network file systems (NFS), or version control systems (such as Git). All of these methods enable physical separation between front-end static resources and the front-end service carrier, and ensure that the resource's lifecycle and access control are independent of the front-end service carrier's runtime lifecycle.

[0039] Furthermore, upon receiving the front-end static resources and their corresponding version information from various applications, each front-end static resource containing version information can be deployed as a resource package to the corresponding storage area in the storage location. This enables each deployed front-end static resource to have self-describing version capabilities, allowing the front-end service carrier to accurately determine the current version of the static resource through the version information, thus facilitating subsequent version tracking.

[0040] In addition, in order to standardize resource management and ensure that the front-end service carrier can accurately identify and access the front-end static resources of each application, the embodiments of this disclosure configure the directory structure of application static resources stored in a preset storage location.

[0041] In one specific implementation, the static resource package built for each application follows a uniform directory format. This format typically includes a page file that serves as the access point, such as a default homepage named index.html; a subdirectory for centrally storing style definition files, such as the css / directory, which may contain files like main.css; and a subdirectory for centrally storing executable scripts, such as the js / directory, which may contain business logic files like app.js.

[0042] The following describes in detail step 103, namely, "establishing a mapping relationship between the static resource access path of the front-end service carrier and the physical storage path of the storage location, so that the front-end service carrier can access the front-end static resources corresponding to each application in the storage location based on the mapping relationship," with reference to the embodiments.

[0043] In the embodiments of this disclosure, the static resource access path is the root path or base path configured internally by the front-end service carrier for finding and providing static files (such as / usr / share / nginx / html in the Nginx container). The mapping relationship is established by configuring the front-end service carrier to redirect access to this path internally to a preset external storage location (such as / opt / frontend-static / ) during runtime. After the mapping is established, when Nginx responds to a request for / app_a / index.html, it will read the file from / opt / frontend-static / app_a / index.html.

[0044] As one feasible approach, container technology can be used to configure the running instance of the front-end service carrier and mount the physical storage path of the storage location to the static resource access path of the front-end service carrier with read-only permissions.

[0045] This method utilizes the volume mounting or bind mounting capabilities of containerization technologies (such as Docker) to achieve mapping, mounting the host machine's / opt / frontend-static / directory to the container's / usr / share / nginx / html directory in read-only (ro) mode. This method leverages standard container platform features to achieve efficient and transparent file system-level mapping, and the read-only permissions prevent front-end static resources from being tampered with, thereby ensuring resource security.

[0046] The methods for establishing the above mapping relationship include, but are not limited to, container mounting. For example, at the container technology level, Docker named volumes or storage driver-managed volumes can be mounted to the static resource access path of the carrier container; at the general technology level, the internal access path of the carrier can be associated with the external storage location through host symbolic links, reverse proxies and route redirection, NFS client mounting, etc. All of the above methods can break the fixed binding between static resources and the front-end service carrier, and establish a configurable external resource access channel.

[0047] Furthermore, after establishing the above mapping relationship, the method also includes: It receives resource update instructions for a target application from various applications. The resource update instructions carry a new resource package for the target application, which includes updated front-end static resources and corresponding new version information. Update the resource package corresponding to the target application in the storage location to the new resource package.

[0048] The resource update command can be triggered by the operation and maintenance platform, automated deployment tools or command line scripts. The core is to identify the target application (such as application identifier app_a) and provide a new resource package. The update operation only replaces the content of the subdirectory corresponding to the target application in the independent storage location. The front-end service carrier can perceive the directory content change in real time through the read-only mount mapping relationship. There is no need to restart the carrier container. Moreover, the update operation only affects the target application and is unrelated to other applications, thereby realizing independent resource updates.

[0049] To ensure the security of the update process, before updating the resource package corresponding to the target application in the storage location to the new resource package, the following may also be included: Back up the resource package corresponding to the target application in the storage location to the specified storage location; After updating the resource package corresponding to the target application in the storage location to the new resource package, it may also include: Receive resource rollback instructions from the target application; Restore the corresponding resource package in the specified storage location to the corresponding storage area of ​​the storage location.

[0050] The backup operation occurs before overwriting the old resource package and is performed only on the subdirectory where the target application resides. For example, before updating app_a, the existing / opt / frontend-static / app_a / directory is packaged, compressed, and backed up to a separate backup directory (such as / backups / frontend / app_a_backup_20231027.tar). The specified storage location can be a different disk partition on the same server, network storage, or object storage to improve backup reliability.

[0051] When an update is found to have issues requiring a rollback, a resource rollback command is triggered (via the management interface or a script). The system then decompresses the backed-up old resource package and overwrites it in the target application's storage subdirectory. This process minimizes the impact of a single application update failure and enables rapid recovery, solving the problems of high rollback costs and wide-ranging impact in traditional full upgrades.

[0052] It should be noted that the backup strategy can be a full backup or an incremental backup; the backup file name can include the application identifier, backup timestamp, and version number for easy management; the rollback command can specify to restore to a specific backup version.

[0053] like Figure 2 The diagram shown is an architectural schematic of a front-end service system provided in an embodiment of this disclosure. It is used to intuitively demonstrate the implementation method of physically separating front-end static resources from front-end service carriers and establishing access mapping through read-only mounting.

[0054] like Figure 2 As shown, the system architecture consists of two physically isolated deployment units: the host machine and the containers. Among them: On the host machine side: The default storage location is the host file system path / etc / kolla / noahee-fe-ops-ui-static / . Under this path, independent storage subdirectories are divided according to the application dimension to store the front-end static resources of each application, such as static materials of the operation platform, static materials of the upgrade platform, and static materials of the configuration center, so as to realize the physical isolation and independent management of multiple application resources.

[0055] On the container side: The Nginx service runs inside the container as the front-end service carrier. Its internal static resource access path is / home / bcc / bce-console / noahee-fe-ops-ui / static / . Under this path, the static material access paths of the operation platform, upgrade platform, and configuration center are configured according to the application dimension to receive resource access requests from user terminals.

[0056] Mapping relationship: A mount mapping is established between the host machine and the container through Docker Volume, and the mount is configured with read-only permissions. The path / etc / kolla / noahee-fe-ops-ui-static / on the host machine is associated with the path / home / bcc / bce-console / noahee-fe-ops-ui / static / on the container. This allows the Nginx service to transparently access the front-end static resources of various applications on the host machine based on this mapping relationship, while prohibiting the processes in the container from modifying the resources on the host machine, thus ensuring the security and integrity of static resources.

[0057] With the above architecture, front-end static resources are stored in an independent path on the host machine, achieving physical separation from the Nginx service in the container; the Nginx service only accesses resources through read-only mounted mapping relationships, without needing to package resources into the container image, thereby decoupling resource updates from container deployment and supporting independent updates, backups, and rollbacks of single application resources.

[0058] The following example uses a cloud computing operations and maintenance management platform. For instance, the front-end service of a cloud computing operations and maintenance management platform hosts the front-end interfaces of three applications: "Operations Platform," "Configuration Center," and "Operations and Maintenance Platform." If, on a certain day, the "Operations Platform" urgently needs to fix a display defect, the execution flow of the technical solution disclosed in this paper is as follows: Resource preparation: The "Job Platform" team completed code repair and build, generating a resource package jobcenter_v2.1.1.tar.gz containing the new static resources and version number v2.1.1; Triggering an update: Operations personnel select "Job Platform" on the deployment platform, upload the resource package, and trigger the update command; Security Update: The deployment system first backs up the / opt / static / jobcenter / directory to the specified storage location, and then unzips the new resource package to overwrite the directory; the front-end service carrier (Nginx container) detects changes to the directory content in real time through read-only mounting; Version verification: System access The version number is confirmed to be v2.1.1 at https: / / ops-console.example.com / jobcenter / version.json. Only the "Job Platform" team needs to verify and fix the function; other applications will not be affected. Quick rollback: If there is a problem with the new version, the operations and maintenance personnel can trigger a rollback command. The system will restore the old resource package in the specified storage location to the / opt / static / jobcenter / directory. The whole process only affects the "job platform" and takes only a few minutes.

[0059] In this scenario, the proposed solution transforms the updating of front-end static resources from "full-scale collaboration and batch operation" to "independent and precise operation on demand," significantly enhancing the autonomy of application iteration and release agility, reducing operational complexity and risks, and improving the overall availability and maintenance efficiency of the system.

[0060] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0061] The foregoing has described specific embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0062] According to another embodiment, a management device for front-end static resources is provided. Figure 3 A schematic block diagram of a front-end static resource management apparatus according to one embodiment is shown. Figure 3 As shown, the device 300 includes a request receiving unit 301, a deployment unit 302, and a mapping establishment unit 303. The main functions of each component are as follows: The receiving unit 301 is configured to receive front-end static resources of the various applications; Deployment unit 302 is configured to deploy the front-end static resources of the various applications to preset storage locations, wherein the storage locations are physically separated from the deployment locations of the front-end service carriers; The mapping establishment unit 303 is configured to establish a mapping relationship between the static resource access path of the front-end service carrier and the physical storage path of the storage location, so that the front-end service carrier can access the front-end static resources corresponding to each application in the storage location based on the mapping relationship.

[0063] Specifically, the mapping establishment unit 303 is configured as follows: Configure the running instance of the front-end service carrier using container technology, and mount the physical storage path of the storage location to the static resource access path of the front-end service carrier with read-only permissions.

[0064] The receiving unit 301 is further configured to: Receive version information corresponding to each of the aforementioned front-end static resources; The deployment unit 302 is specifically configured as follows: Each front-end static resource containing the version information is deployed as a resource package to the corresponding storage area in the storage location.

[0065] Furthermore, the device may also include: The resource update unit 304 is configured to receive a resource update instruction from a target application in the plurality of applications, the resource update instruction carrying a new resource package for the target application, the new resource package containing updated front-end static resources and corresponding new version information; and update the resource package corresponding to the target application in the storage location to the new resource package.

[0066] Furthermore, the device may also include: Resource backup unit 305 is configured to back up the resource package corresponding to the target application in the storage location to a specified storage location; Resource rollback unit 306 is configured as follows: Receive the resource rollback instruction from the target application; restore the corresponding resource package in the specified storage location to the corresponding storage area of ​​the storage location.

[0067] Furthermore, deployment unit 302 is specifically configured as follows: Based on the application identifier of each application, a corresponding storage subdirectory is created for each application under the physical storage path of the storage location, and the front-end static resources of each application are deployed to their respective storage subdirectories.

[0068] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0069] Figure 4 A schematic block diagram of an example electronic device 400 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0070] like Figure 4 As shown, device 400 includes a computing unit 401, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 402 or a computer program loaded from storage unit 408 into random access memory (RAM) 403. RAM 403 may also store various programs and data required for the operation of device 400. The computing unit 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.

[0071] Multiple components in device 400 are connected to I / O interface 405, including: input unit 406, such as keyboard, mouse, etc.; output unit 407, such as various types of monitors, speakers, etc.; storage unit 408, such as disk, optical disk, etc.; and communication unit 409, such as network card, modem, wireless transceiver, etc. Communication unit 409 allows device 400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0072] The computing unit 401 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 401 performs the various methods and processes described above, such as information acquisition methods. For example, in some embodiments, the information acquisition method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 408. In some embodiments, part or all of the computer program may be loaded and / or installed on device 400 via ROM 402 and / or communication unit 409. When the computer program is loaded into RAM 403 and executed by the computing unit 401, one or more steps of the content recommendation method described above may be performed. Alternatively, in other embodiments, the computing unit 401 may be configured by any other suitable means (e.g., by means of firmware) to perform methods for managing front-end static resources.

[0073] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0074] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0075] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0076] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0077] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0078] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0079] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0080] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for managing front-end static resources, the method being applied to a front-end service system containing a front-end service carrier, the front-end service carrier being used to carry front-end services for multiple applications, including: Receive front-end static resources from the aforementioned applications; The front-end static resources of the various applications are deployed to preset storage locations, and the storage locations are physically separated from the deployment locations of the front-end service carriers. Establish a mapping relationship between the static resource access path of the front-end service carrier and the physical storage path of the storage location, so that the front-end service carrier can access the front-end static resources corresponding to each application in the storage location based on the mapping relationship.

2. The method of claim 1, wherein, The process of establishing the mapping relationship between the static resource access path of the front-end service carrier and the physical storage path of the storage location includes: Configure the running instance of the front-end service carrier using container technology, and mount the physical storage path of the storage location to the static resource access path of the front-end service carrier with read-only permissions.

3. The method according to claim 1, further comprising: Receive version information corresponding to each of the aforementioned front-end static resources; The step of deploying the front-end static resources of the various applications to preset storage locations includes: Each front-end static resource containing the version information is deployed as a resource package to the corresponding storage area in the storage location.

4. The method according to claim 3, further comprising: Receive a resource update instruction for a target application from the various applications. The resource update instruction carries a new resource package for the target application. The new resource package includes updated front-end static resources and corresponding new version information. Update the resource package corresponding to the target application in the storage location to the new resource package.

5. The method according to claim 4, further comprising, before updating the resource package corresponding to the target application in the storage location to the new resource package: Back up the resource package corresponding to the target application in the storage location to the specified storage location; After updating the resource package corresponding to the target application in the storage location to the new resource package, the method further includes: Receive the resource rollback instruction from the target application; Restore the resource package corresponding to the specified storage location to the corresponding storage area of ​​the storage location.

6. The method according to claim 1, further comprising: Configure an application identifier for each of the aforementioned applications; The step of deploying the front-end static resources of the various applications to preset storage locations includes: Based on the application identifier of each application, a corresponding storage subdirectory is created for each application under the physical storage path of the storage location, and the front-end static resources of each application are deployed to their respective storage subdirectories.

7. A management device for front-end static resources, the device being configured in a front-end service system including a front-end service carrier, the front-end service carrier being used to carry front-end services for multiple applications, including: The receiving unit is configured to receive front-end static resources of the various applications; The deployment unit is configured to deploy the front-end static resources of the various applications to preset storage locations, wherein the storage locations are physically separated from the deployment locations of the front-end service carriers. The mapping establishment unit is configured to establish a mapping relationship between the static resource access path of the front-end service carrier and the physical storage path of the storage location, so that the front-end service carrier can access the front-end static resources corresponding to each application in the storage location based on the mapping relationship.

8. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.

9. A non-transitory computer readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-6.

10. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-6.

Images