CN111970359B - Front-end non-service architecture system based on node - Google Patents

Abstract

The invention provides a front-end non-service architecture system based on node.js server and an establishing method, wherein the system comprises the following components: a publishing terminal acquires front-end static resources corresponding to a client page and corresponding resource manifest file information; uploading the resource list file information and the front-end static resource to a shared storage device; the shared storage device provides resource list file information to the node. Providing front-end static resources corresponding to a data request according to the data request initiated by the node.js service cluster; a js service cluster receives the request identification, matches the request identification with the resource list file information, and generates a data request according to a matching result; acquiring front-end static resources from a shared storage device through a data request, and feeding back the front-end static resources to a client; and the client side initiates a request identifier to the node.

Description

Js server-based front-end non-service architecture system and establishment method

Technical Field

The invention relates to the field of computers, can be applied to the field of finance and other fields, in particular to a node.

Background

With the rapid development of the internet, the complexity of the front-end technical field is higher and higher, and the capability requirement on a front-end engineer is higher and higher. Currently, in a development mode with front and back ends separated, front-end engineering deployment depends on certain service tools. The current deployment of front-end engineering in the industry is generally carried by a Nginx or other Web server. However, the existing tools cannot meet the requirements of complicated and variable front-end engineering:

1. multiple project deployments require multiple server bearers;

2. a plurality of projects cannot be uniformly deployed, operated and maintained;

3. the fast automatic online and version switching cannot be realized;

in the industry, a solution that a front-end engineer and operation and maintenance personnel can be liberated from repeated work of multi-project deployment, so that the capability of unifying operation and maintenance of company-level front-end services can be realized while the labor and hardware resource cost are saved, and the version can be quickly switched by one key is also needed. At present, the problems of cost reduction, unified operation and version quick switching are not reasonably solved, so how to provide a new scheme is a technical problem to be solved urgently in the field.

Disclosure of Invention

The invention aims to provide a node.js server-based front-end non-service architecture system with higher server reuse rate and lower cost and an establishing method thereof, so as to unify all front-end engineering operation and maintenance and control mechanisms and reduce the operation and maintenance cost; the capability of quickly uploading and rolling back versions is provided, and the business risk is reduced.

In order to achieve the above object, the node.js server-based front-end non-service architecture system provided by the present invention comprises a distribution end, a shared storage device, a client and a node.js service cluster; the publishing terminal is used for acquiring front-end static resources corresponding to the client page and corresponding resource manifest file information; uploading the resource manifest file information and the front-end static resource to the shared storage device; the shared storage device is used for providing the resource list file information to the node.js service cluster through a preset pushing mechanism; providing the front-end static resource corresponding to the data request according to the data request initiated by the node.js service cluster; the node.js service cluster is used for receiving a request identifier, matching the request identifier with the resource list file information and generating a data request according to a matching result; obtaining the corresponding front-end static resource from the shared storage device through the data request, and feeding back the front-end static resource to a client; the client is used for generating page data according to the front-end static resource fed back by the node.

In the node.js server-based front-end non-service architecture system, preferably, the shared storage device includes a distributed data coordination library and a common file repository; the distributed data coordination database is used for providing the resource list file information to the node.js service cluster through a subscription and release mechanism; the common file repository is used for providing the front-end static resources corresponding to the data request according to the data request initiated by the node.

In the node.js server-based front-end non-service architecture system, preferably, the front-end static resource includes js data, css data and picture data; and the resource list file information is a mapping relation table between the client page and the front-end static resource under the version corresponding to the version information.

In the node.js server-based front-end non-service architecture system, preferably, the publishing end further includes obtaining version information corresponding to a client page, and obtaining resource manifest file information corresponding to the front-end static resource according to the version information; and generating a registration identifier according to the resource manifest file information, and providing the registration identifier to the distributed data coordination library.

In the above node. And binding the registration identifier and the corresponding resource list file information according to the received registration identifier and then pushing the registration identifier and the corresponding resource list file information to the node.

In the above node.js server-based front-end architecture-less system, preferably, the node.js service cluster further includes: when the request identification is matched with at least two pieces of resource list file information, matching address information in the request identification with a registration identification corresponding to the resource list file information, and determining the resource list file information according to a matching result; and generating a data request according to the determined resource list file information.

The invention also provides a node.js server-based front-end service rack-free construction method, which comprises the following steps: the method comprises the steps that a publishing terminal obtains front-end static resources corresponding to a client page and corresponding resource list file information, and uploads the resource list file information and the front-end static resources to a shared storage device; providing the resource list file information in the shared storage device to a node.js service cluster through a preset pushing mechanism; when a node.js service cluster receives a request identifier submitted by a client, matching the request identifier with the resource list file information, generating a data request according to a matching result, and requesting to acquire the corresponding front-end static resource from the shared storage device through the data request; the shared storage device provides the front-end static resource corresponding to the data request to the node.js service cluster according to the data request initiated by the node.js service cluster; and the js service cluster feeds back the obtained front-end static resource to a client, and the client generates page data according to the received front-end static resource.

In the above node.js-server-based front-end service shelf-free establishment method, preferably, the providing the resource manifest file information in the shared storage device to a node.js service cluster through a predetermined push mechanism includes: the shared storage device comprises a distributed data coordination library, and the resource list file information is provided to the node.

In the above front-end non-service-rack building method based on a node.js server, preferably, the front-end static resource includes js data, css data and picture data; the resource manifest file information is a mapping relation table of the client page and the front-end static resource under the version corresponding to the version information.

In the above node.js server-based front-end service rack-less establishment method, preferably, the issuing end obtains front-end static resources corresponding to a client page and corresponding resource manifest file information, and uploading the resource manifest file information and the front-end static resources to a shared storage device includes: acquiring version information corresponding to a client page, and acquiring resource list file information corresponding to the front-end static resource according to the version information; and generating a registration identifier according to the resource manifest file information, and providing the registration identifier to the distributed data coordination database.

In the above node.js server-based front-end service shelf-free establishment method, preferably, the providing the resource manifest file information in the shared storage device to the node.js service cluster through a predetermined push mechanism further includes: and after the registration identifier and the corresponding resource list file information are bound, pushing the registration identifier and the corresponding resource list file information to the node.

In the above method for establishing a front-end non-service-rack based on a node.js server, preferably, when a node.js service cluster receives a request identifier submitted by a client, matching the request identifier with the resource manifest file information, and generating a data request according to a matching result further includes: when the request identifier is matched with at least two pieces of resource list file information, matching address information in the request identifier with a registration identifier corresponding to the resource list file information, and determining the resource list file information according to a matching result; and generating a data request according to the determined resource list file information.

The invention also provides an electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method when executing the computer program.

The present invention also provides a computer-readable storage medium storing a computer program for executing the above method.

The invention has the beneficial technical effects that: the deployment process of the front-end engineering and the server resources are highly multiplexed, and in the operation and maintenance process, a large number of front-end engineering are not independent and have different styles, so that the deployment processes of all the front-end engineering can be unified and simplified, and centralized operation and maintenance and control are realized; meanwhile, a mechanism for managing the front-end resource version is provided from the bottom architecture level, so that one-key quick switching to a certain normal version can be realized; moreover, developers and operation and maintenance personnel of different projects do not need to build and maintain the Nginx Web server. The more items, the more obvious the resource saving effect is, and the higher the efficiency is improved; with a quick online and rollback mechanism, more frequent and quick iteration can be performed on business without worrying about business risks brought by trial and error, and the rollback can be performed in seconds once a problem is found.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the principles of the invention. In the drawings:

fig. 1 is a schematic structural diagram of a node.js server-based front-end non-service architecture system according to an embodiment of the present invention;

FIG. 2 is a schematic structural diagram of a shared memory device according to an embodiment of the present invention;

fig. 3 and fig. 4 are schematic diagrams of an application principle of a node.js server-based front-end serverless architecture system according to an embodiment of the present invention;

fig. 5 is a schematic diagram of a control logic flow in a node.js server according to an embodiment of the present invention;

fig. 6 is a schematic flow chart illustrating establishment of a node.js server-based front-end non-service architecture according to an embodiment of the present invention;

fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.

Detailed Description

The following detailed description of the embodiments of the present invention will be provided with reference to the drawings and examples, so that how to apply the technical means to solve the technical problems and achieve the technical effects can be fully understood and implemented. It should be noted that, as long as there is no conflict, the embodiments and the features of the embodiments of the present invention may be combined with each other, and the technical solutions formed are within the scope of the present invention.

Additionally, the steps illustrated in the flowcharts of the figures may be performed in a computer system such as a set of computer-executable instructions, and while a logical order is illustrated in the flowcharts, in some cases, the steps illustrated or described may be performed in an order different than here.

Referring to fig. 1, a node.js server-based front-end non-service architecture system provided by the present invention includes a distribution end, a shared storage device, a client, and a node.js service cluster; the publishing terminal is used for acquiring front-end static resources corresponding to the client page and corresponding resource list file information; uploading the resource manifest file information and the front-end static resource to the shared storage device; the shared storage device is used for providing the resource list file information to the node.js service cluster through a preset pushing mechanism; providing the front-end static resource corresponding to the data request according to the data request initiated by the node.js service cluster; the node.js service cluster is used for receiving a request identifier, matching the request identifier with the resource list file information and generating a data request according to a matching result; obtaining the corresponding front-end static resource from the shared storage device through the data request, and feeding back the front-end static resource to a client; the client is used for generating page data according to the front-end static resource fed back by the node. Therefore, the relevant static resources corresponding to the pages are all placed in a shared storage device, and the subsequent client pages are directly applied for obtaining when needing to be used, so that the resource reuse rate of the server is effectively improved, and the cost is reduced; at the same time, the user can select the desired position,

referring to FIG. 2, in the above embodiment, the shared storage device may include a distributed data coordination library and a common file repository; the distributed data coordination library is used for providing the resource list file information to the node.js service cluster through a subscription and release mechanism; the common file repository is used for providing the front-end static resources corresponding to the data request according to the data request initiated by the node. The front-end static resource comprises js data, css data and picture data; and the resource list file information is a mapping relation table between the client page and the front-end static resource under the version corresponding to the version information. It should be noted that, in the front-end no-service architecture system based on node.

For better understanding of the node.

In actual application, firstly, front-end static resources corresponding to pages are uploaded to a public file repository in combination with the front-end engineering automatic packaging capacity; meanwhile, registering the resource list file information corresponding to the current version of the page into a distributed data coordination library; thus, the version information and the corresponding resource file are stored in the shared data service, and the first step of server resource sharing is already realized: sharing of static resource storage.

Secondly, after managing the static resource file information, the node.js server needs to know: how to identify which static resources a request needs to correspond to. Therefore, after the resource list file information of the page is registered in the distributed data coordination library, the list information received in the distributed data coordination library is actively pushed to the node.js server by utilizing the subscribing and publishing mechanisms of the node.js server and the distributed data coordination library, so that the node.js server has the required resource list information and is ready for subsequent request response.

And finally, during operation, after the front-end node.js service dynamically analyzes the request identifier (URL, user identifier and the like) sent by the client, matching the corresponding static resources according to the static resource list information pushed by the distributed data coordination library, downloading the resources from the public file repository in real time, and dynamically executing at the node.js service end and responding the result to the client. Therefore, no matter how many front-end projects exist, the front-end service can be dynamically loaded, and a plurality of different front-end business services are not required to be deployed; meanwhile, the operation, maintenance, monitoring and unified control of all front-end services on the service are realized through the tool.

In an embodiment of the present invention, the publishing terminal further includes obtaining version information corresponding to a client page, and obtaining resource manifest file information corresponding to the front-end static resource according to the version information; and generating a registration identifier according to the resource manifest file information, and providing the registration identifier to the distributed data coordination library. Thus, the subsequent distributed data coordination library may further comprise: binding the registration identifier and corresponding resource list file information and pushing the binding identifier and the corresponding resource list file information to the node.js service cluster according to the received registration identifier; js service cluster matches the address information in the request identifier with the registration identifier corresponding to the resource manifest file information when the request identifier is matched with at least two pieces of resource manifest file information, and determines the resource manifest file information according to the matching result; and generating a data request according to the determined resource list file information. Therefore, in the actual use process, the whole registration identifier is controlled by the issuing end, so that the change of the client page information can be realized only by adjusting the registration identifier of the issuing end, the switching and the adjustment of the client page can be completed more conveniently, the workload of workers is greatly reduced, and the specific implementation method of the registration identifier in the actual work will be described in detail in the following embodiments and is not detailed one by one.

Referring to fig. 6, the present invention further provides a front-end service rack-less building method based on node.

S601, the publishing terminal acquires front-end static resources corresponding to a client page and corresponding resource manifest file information, and uploads the resource manifest file information and the front-end static resources to a shared storage device;

s602 provides the resource manifest file information in the shared storage device to a node.js service cluster through a predetermined push mechanism;

s603, when a node.js service cluster receives a request identifier submitted by a client, matching the request identifier with the resource manifest file information, generating a data request according to a matching result, and requesting to acquire the corresponding front-end static resource from the shared storage device through the data request;

s604, the shared storage device provides the front-end static resource corresponding to the data request to the node.js service cluster according to the data request initiated by the node.js service cluster;

and S605, the node.js service cluster feeds back the obtained front-end static resource to a client, and the client generates page data according to the received front-end static resource.

In the above embodiment, providing the resource manifest file information in the shared storage device to the node.js service cluster through a predetermined push mechanism includes: the shared storage device comprises a distributed data coordination library, and the resource list file information is provided to the node.js service cluster through a subscription and release mechanism of the distributed data coordination library. The front-end static resource comprises js data, css data and picture data; and the resource list file information is a mapping relation table between the client page and the front-end static resource under the version corresponding to the version information.

In an embodiment of the present invention, the method for uploading the resource manifest file information and the front-end static resource to a shared storage device includes: acquiring version information corresponding to a client page, and acquiring resource manifest file information corresponding to the front-end static resource according to the version information; and generating a registration identifier according to the resource manifest file information, and providing the registration identifier to the distributed data coordination database. Then, providing the resource manifest file information in the shared storage to the node.js service cluster through a predetermined push mechanism further comprises: binding the registration identification and the corresponding resource list file information and then pushing the binding identification and the corresponding resource list file information to the node.js service cluster; when the request identifier is matched with at least two pieces of resource list file information, the node.js service cluster matches the address information in the request identifier with the registration identifier corresponding to the resource list file information, and determines the resource list file information according to the matching result; and generating a data request according to the determined resource list file information.

In actual work, a node.js service immediately initiates subscription to a distributed repository after being started, and once data in the distributed repository changes, the change information is immediately notified to all subscribers, so that the node.js service and the distributed repository establish real-time communication capability. And release end one side then combines the ability of the automatic packing of front end engineering, can export the file of two kinds after the scaffold frame packing: all used static resource files (js, css, pictures and the like) and list files (mapping relation between pages and the static resource files) in the project; the scaffold is responsible for uploading the static resource files corresponding to the pages to a public file repository, and simultaneously registering the resource list file information corresponding to the current version of the pages into a distributed data coordination library; different versions of each page can correspond to different resources, so that under a node of a page address, corresponding resource mapping relations can be distinguished according to version numbers, when multiple versions of the same page need to be switched and issued, operation switching can be performed through an issuing platform, namely, the registration identifier is specifically adopted:

in a release platform, a distributed repository can be notified by selecting a version corresponding to a certain page and clicking release to determine which version is used by the current page, and therefore, in actual work, besides corresponding version information "v1" and "v2", a 'currentVersion' information, namely a registration identifier is added, and the registration identifier is a static resource file for a node. Therefore, the page version information and the corresponding resource file are stored in the shared data service, and the first step of server resource sharing is already realized: sharing of static resource storage.

Secondly, after managing the static resource file information, the node.js server needs to know: how to identify which static resources a page request needs to correspond to. In this regard, after the resource manifest file information is registered in the distributed data coordination library, the distributed data coordination library immediately pushes the manifest information in the JSON format to the node. The js service receives the list information and stores the list information in a local memory. Thus, the node.js server has the required resource list information and is ready for subsequent request response.

And finally, matching the front-end node.js service to the corresponding static resource according to the request address, namely the request identifier, sent by the client and the static resource list information (stored in the memory of the node.js service) pushed by the distributed data coordination library during operation. The specific matching process is as follows:

1. adopting a contract list page, wherein the address is as follows: xxx.tech.com.cn/contact, provided with two versions corresponding to v1 and v2 respectively;

2. selecting v2 in the publishing platform for publishing, wherein the currentVersion value in the manifest is v2;

3. when the request of xxx.tech.com.cn/contact of the browser reaches node.js service, the resource lists of v1 and v2 versions can be found according to url addresses;

4. then, determining whether to read inventory information under the v1 or v2 node according to currentVersion under the xxx.tech.com.cn/contact node;

after the current version is determined, the process of dynamic analysis is completed, the node.

Then, when the version of the page needs to be switched, only the version needing to be switched needs to be selected in the publishing platform, such as: v1, then the two processes described above are automatically executed:

1. changing currentVersion in the manifest file into v1, and then registering the changed currentVersion in the distributed repository;

2. the distributed storage library automatically pushes the modified list to node. Js service (the two always establish a subscription relationship, and long connection always exists);

therefore, no matter how many front-end projects exist, the front-end service can dynamically bear the load, and a plurality of different front-end service services do not need to be deployed. Meanwhile, the operation, maintenance, monitoring and unified control of all front-end services on the service are realized through the tool.

Referring to fig. 5 again, in the overall operation flow of the front-end service rack-less building method based on a node. A fuse: preventing the application program from continuously trying to execute the operation which may fail, wasting the CPU to wait for timeout; it is also possible to diagnose whether the error has been corrected in order to try again to invoke the operation. Safety control: cross-domain access control, cross-site request forgery, crawler access and other security control; and (3) route analysis: matching the corresponding resource file address in the 'list' information stored in the node.js service according to the requested address; loading an entry file: downloading a corresponding file to the node.js server from the static resource service according to the analyzed file address; and (3) executing the file: and directly executing a js manifest file corresponding to the request address of the client at the server side, and returning HTML text information to the client side.

The beneficial technical effects of the invention are as follows: the deployment processes of the front-end engineering and the server resources are highly multiplexed, and in the operation and maintenance process, a large number of front-end engineering are not independent from each other and have different styles, so that the deployment processes of all the front-end engineering can be unified and simplified, and centralized operation and maintenance and control are realized; meanwhile, a mechanism for managing the front-end resource version is provided from the bottom architecture level, so that one-key quick switching to a certain normal version can be realized; moreover, developers and operation and maintenance personnel of different projects do not need to build and maintain the Nginx Web server. The more the projects are, the more obvious the resource saving effect is, and the higher the efficiency is improved; with a quick online and rollback mechanism, more frequent and quick iteration can be performed on business without worrying about business risks brought by trial and error, and the rollback can be performed in seconds once a problem is found.

The invention also provides an electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method when executing the computer program.

The present invention also provides a computer-readable storage medium storing a computer program for executing the above method.

As shown in fig. 7, theelectronic device 600 may further include:communication module 110,input unit 120,audio processing unit 130,display 160,power supply 170. It is noted that theelectronic device 600 does not necessarily include all of the components shown in FIG. 7; furthermore, theelectronic device 600 may also comprise components not shown in fig. 7, which may be referred to in the prior art.

As shown in fig. 7, thecentral processor 100, sometimes referred to as a controller or operation control, may include a microprocessor or other processor device and/or logic device, thecentral processor 100 receiving input and controlling the operation of the various components of theelectronic device 600.

Thememory 140 may be, for example, one or more of a buffer, a flash memory, a hard drive, a removable media, a volatile memory, a non-volatile memory, or other suitable devices. The information relating to the failure may be stored, and a program for executing the information may be stored. And thecentral processing unit 100 may execute the program stored in thememory 140 to realize information storage or processing, etc.

Theinput unit 120 provides an input to thecpu 100. Theinput unit 120 is, for example, a key or a touch input device. Thepower supply 170 is used to provide power to theelectronic device 600. Thedisplay 160 is used to display an object to be displayed, such as an image or a character. The display may be, for example, but is not limited to, an LCD display.

Thememory 140 may be a solid state memory such as Read Only Memory (ROM), random Access Memory (RAM), a SIM card, or the like. There may also be a memory that holds information even when power is off, can be selectively erased, and is provided with more data, an example of which is sometimes referred to as an EPROM or the like. Thememory 140 may also be some other type of device.Memory 140 includes buffer memory 141 (sometimes referred to as a buffer). Thememory 140 may include an application/function storage section 142 for storing application programs and function programs or a flow for executing the operation of theelectronic device 600 by thecentral processing unit 100.

Thememory 140 may also include adata store 143 for storing data, such as contacts, digital data, pictures, sounds, and/or any other data used by the electronic device. Thedriver storage portion 144 of thememory 140 may include various drivers of the electronic device for a communication function and/or for performing other functions of the electronic device (e.g., a messaging application, a directory application, etc.).

Thecommunication module 110 is a transmitter/receiver 110 that transmits and receives signals via anantenna 111. The communication module (transmitter/receiver) 110 is coupled to thecentral processor 100 to provide an input signal and receive an output signal, which may be the same as in the case of a conventional mobile communication terminal.

Based on different communication technologies, a plurality ofcommunication modules 110, such as a cellular network module, a bluetooth module, and/or a wireless local area network module, etc., may be provided in the same electronic device. The communication module (transmitter/receiver) 110 is also coupled to aspeaker 131 and amicrophone 132 via anaudio processor 130 to provide audio output via thespeaker 131 and receive audio input from themicrophone 132 to implement general telecommunications functions.Audio processor 130 may include any suitable buffers, decoders, amplifiers and so forth. In addition, anaudio processor 130 is also coupled to thecentral processor 100, so that recording on the local can be enabled through amicrophone 132, and so that sound stored on the local can be played through aspeaker 131.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention has been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The above-mentioned embodiments are intended to illustrate the objects, technical solutions and advantages of the present invention in further detail, and it should be understood that the above-mentioned embodiments are only exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims (10)

1. A node.js server-based front-end non-service architecture system, which is characterized by comprising a publishing end, a shared storage device, a client and a node.js service cluster;

the publishing terminal is used for acquiring front-end static resources corresponding to the client page and corresponding resource list file information; uploading the resource manifest file information and the front-end static resource to the shared storage device;

the shared storage device is used for providing the resource list file information to the node.js service cluster through a preset pushing mechanism; providing the front-end static resource corresponding to the data request according to the data request initiated by the node.js service cluster;

the node.js service cluster is used for receiving a request identifier, matching the request identifier with the resource list file information and generating a data request according to a matching result; obtaining the corresponding front-end static resource from the shared storage device through the data request, and feeding back the front-end static resource to a client;

the client is used for generating page data according to the front-end static resource fed back by the node.js service cluster by using a request identifier initiated by the node.js service cluster;

the shared storage device comprises a distributed data coordination library and a public file storage library;

the distributed data coordination database is used for providing the resource list file information to the node.js service cluster through a subscription and release mechanism; the resource list file information is a mapping relation table of the client page and the front-end static resource under the version corresponding to the version information;

the public file repository is used for providing the front-end static resource corresponding to the data request according to the data request initiated by the node.js service cluster;

the publishing terminal also comprises version information corresponding to the client terminal page and resource list file information corresponding to the front-end static resource is obtained according to the version information; and generating a registration identifier according to the resource manifest file information, and providing the registration identifier to the distributed data coordination library.

2. The node.

3. The node.js server-based front-end serverless architecture system of claim 1 wherein the distributed data coordination library further comprises: and binding the registration identifier and corresponding resource manifest file information and pushing the bound registration identifier and the corresponding resource manifest file information to the node.

4. The node.js server-based front-end serverless architecture system of claim 1 wherein the node.js service cluster further comprises: when the request identifier is matched with at least two pieces of resource list file information, matching address information in the request identifier with a registration identifier corresponding to the resource list file information, and determining the resource list file information according to a matching result; and generating a data request according to the determined resource list file information.

5. A node.js server-based front-end shelf-less building method, the method comprising:

the method comprises the steps that a publishing terminal obtains front-end static resources corresponding to a client page and corresponding resource manifest file information, and uploads the resource manifest file information and the front-end static resources to a shared storage device;

providing the resource list file information in the shared storage device to a node.js service cluster through a preset pushing mechanism;

when a node.js service cluster receives a request identifier submitted by a client, matching the request identifier with the resource list file information, generating a data request according to a matching result, and requesting to acquire the corresponding front-end static resource from the shared storage device through the data request;

the shared storage device provides the front-end static resource corresponding to the data request to the node.js service cluster according to the data request initiated by the node.js service cluster;

the node.js service cluster feeds back the obtained front-end static resource to a client, and the client generates page data according to the received front-end static resource;

providing the resource manifest file information in the shared storage device to a node.js service cluster through a predetermined push mechanism comprises: the shared storage device comprises a distributed data coordination library, and the resource list file information is provided to the node.js service cluster through a subscription and release mechanism of the distributed data coordination library; the resource list file information is a mapping relation table of the client page and the front-end static resource under the version corresponding to the version information;

the method for uploading the resource manifest file information and the front-end static resource to a shared storage device comprises the following steps:

acquiring version information corresponding to a client page, and acquiring resource manifest file information corresponding to the front-end static resource according to the version information;

and generating a registration identifier according to the resource list file information, and providing the registration identifier to the distributed data coordination library.

6. Js server-based front-end off-shelf building method of claim 5, wherein the front-end static resources comprise js data, css data and picture data.

7. A node.js server based front end no service shelf building method as in claim 5 wherein providing said resource inventory file information in said shared storage to node.js service cluster through a predetermined push mechanism further comprises: and after the registration identifier and the corresponding resource list file information are bound, pushing the registration identifier and the corresponding resource list file information to the node.

8. The node.js server-based front-end service shelf-free building method of claim 5, wherein, when a node.js service cluster receives a request identifier submitted by a client, matching the request identifier with the resource manifest file information, and generating a data request according to a matching result further comprises: when the request identification is matched with at least two pieces of resource list file information, matching address information in the request identification with a registration identification corresponding to the resource list file information, and determining the resource list file information according to a matching result; and generating a data request according to the determined resource list file information.

9. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any of claims 5 to 8 when executing the computer program.

10. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program which, when executed by a processor, implements the method of any of claims 5 to 8.

Images