Microservice module registration and testing method, apparatus, device, and storage medium

Abstract

This invention relates to the field of computer technology and discloses a method, apparatus, device, and storage medium for registering and testing microservice modules, used to improve the performance of microservice page switching. The microservice module registration and testing method includes: obtaining the identifier code of the main business module, entry page information, and the identifier code corresponding to at least one microservice module according to a microservice registration request; adding each microservice module to the entry page information according to the alias identifier corresponding to each microservice module; instantiating a view and configuring routing information for each microservice module, and mapping and storing the main business module and each microservice module in a module registration data table; and obtaining and testing the main business module to be tested and at least one microservice module to be tested from the module registration data table according to a microservice testing request, thereby obtaining the target microservice application. Furthermore, this invention also relates to blockchain technology, whereby the target microservice application can be stored in a blockchain node.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and storage medium for registering and testing microservice modules. Background Technology

[0002] Single-page applications (SPAs) are currently the mainstream application model in front-end development. They can dynamically rewrite the current page and user interaction without reloading the entire page, improving page navigation performance and enabling modular development, making the application more easily adaptable to multiple devices.

[0003] Traditional single-page applications (SPAs) can be used to build independent application systems. However, as the business volume and the number of development team members increase, independent applications face great challenges. Generally, microservices are used to integrate multiple subsystems. However, SPAs limit the implementation of microservices because the routing of SPAs is front-end routing, which is pseudo-routing. It cannot directly jump to the routes of other application instances, causing some browser functions to malfunction, such as forward and back navigation, page refresh, bookmarks, sending links, and opening links in new windows or tabs. There is a problem of low accuracy in page navigation in microservices. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and storage medium for registering and testing microservice modules, which reduces duplicate code and improves page switching performance through microservice modularization.

[0005] To achieve the above objectives, the first aspect of the present invention provides a microservice module registration and testing method, comprising: upon receiving a microservice registration request, obtaining an identifier code corresponding to a main business module and an identifier code corresponding to at least one microservice module according to the microservice registration request, and obtaining entry page information of the main business module according to the identifier code corresponding to the main business module, wherein the main business module is used to indicate access control for the at least one microservice module; setting an alias identifier corresponding to each microservice module based on the identifier code corresponding to each microservice module, and adding each microservice module to the entry page information according to the alias identifier corresponding to each microservice module to obtain updated entry page information; and in the updated entry page information... The page information instantiates views and configures routing information for each microservice module to obtain the configured entry page information. Based on the configured entry page information, the main business module and each microservice module are mapped and stored in the module registration data table. The configured entry page information is used to indicate a single-page application that associates and combines the main business module and at least one microservice module based on the view file framework. When a microservice test request is received, the main business module to be tested and at least one microservice module to be tested are obtained from the module registration data table according to the microservice test request. The main business module to be tested and at least one microservice module to be tested are then installed and tested to obtain the target microservice application.

[0006] Optionally, in a first implementation of the first aspect of the present invention, the step of obtaining the identifier code corresponding to the main business module and the identifier code corresponding to at least one microservice module according to the microservice registration request, and obtaining the entry page information of the main business module according to the identifier code corresponding to the main business module, wherein the main business module is used to instruct access control for the at least one microservice module, includes: when receiving the microservice registration request, parsing the microservice registration request to obtain a parsing result, and determining whether the parsing result is null; when the parsing result is not null, reading the identifier code corresponding to the main business module and the identifier code corresponding to at least one microservice module from the parsing result, and performing information verification on the identifier code corresponding to the main business module and the identifier code corresponding to the at least one microservice module to obtain a verification result, wherein the main business module is used to instruct access control for the at least one microservice module; when the verification result is a successful verification, querying a first preset data table according to the identifier code corresponding to the main business module to obtain the entry page path information of the main business module, and reading the entry page information of the main business module according to the entry page path information.

[0007] Optionally, in a second implementation of the first aspect of the present invention, the step of setting an alias identifier for each microservice module based on the identifier code corresponding to each microservice module, and adding each microservice module to the entry page information according to the alias identifier to obtain the updated entry page information includes: querying a second preset data table according to the identifier code corresponding to each microservice module to obtain the index number corresponding to each microservice module; obtaining a preset alias prefix, combining the preset alias prefix with the index number corresponding to each microservice module to obtain the alias identifier corresponding to each microservice module; setting a document object model node for each microservice module, and setting the alias identifier corresponding to each microservice module as the node identifier corresponding to the document object model node of each microservice module to obtain the document object model information corresponding to each microservice module, and adding the document object model information corresponding to each microservice module to the entry page information to obtain the updated entry page information.

[0008] Optionally, in a third implementation of the first aspect of the present invention, the step of instantiating the view and configuring the routing information for each microservice module in the updated entry page information to obtain the configured entry page information, and mapping and storing the main business module and each microservice module in the module registration data table according to the configured entry page information, wherein the configured entry page information is used to indicate a single-page application that associates and combines the main business module and the at least one microservice module based on the view file framework, includes: initializing the corresponding sub-view file instance according to the alias identifier corresponding to each microservice module in the entry page information, referencing the preset entry file of each microservice module based on the preset import function, and mounting the preset entry file of each microservice module to the sub-view file instance corresponding to each microservice module; obtaining the routing instance of each microservice module, and binding the routing instance of each microservice module to the sub-view file instance corresponding to each microservice module. Each microservice module's routing instance corresponds to a sub-view file instance, and each microservice module's routing instance corresponds to multiple page nodes, with routing relationships existing between each page node. A message subscription mechanism is set up for the main business module and the at least one microservice module to obtain the configured entry page information. The message subscription mechanism is used to monitor the update status of the routing address in the sub-view file instance corresponding to each microservice module. The configured entry page information is used to indicate a single-page application that associates and combines the main business module and the at least one microservice module based on the view file framework. The version identifier corresponding to the main business module and the version identifier corresponding to each microservice module are obtained. Based on the configured entry page information, the identifier code corresponding to the main business module, the version identifier corresponding to the main business module, the identifier code corresponding to each microservice module, and the version identifier corresponding to each microservice module are mapped and stored in the module registration data table.

[0009] Optionally, in the fourth implementation of the first aspect of the present invention, the step of obtaining the main business module to be tested and at least one microservice module to be tested from the module registration data table according to the microservice test request when a microservice test request is received, and performing installation testing on the main business module to be tested and the at least one microservice module to be tested to obtain the target microservice application, includes: when a microservice test request is received, parsing the parameters of the microservice test request to obtain the version identifier corresponding to the main business module to be tested, and querying the version identifier corresponding to each microservice module from the module registration data table according to the version identifier corresponding to the main business module to be tested; determining the code repository address corresponding to each module according to the version identifier corresponding to the main business module to be tested and the version identifier corresponding to each microservice module to be tested, and obtaining the microservice application to be tested according to the code repository address corresponding to each module. The test involves creating repository code files for the main business module and for each microservice module under test. A root directory is generated for each microservice module according to its alias. The repository code files for each microservice module are then moved to its root directory. This root directory is then copied to a pre-defined microservice module directory within the main business module, resulting in an updated main business module. A pre-defined module packager is used to package the updated main business module, producing a packaged project file. This packaged project file is then sent to a test terminal, which performs installation, deployment, and business logic combination testing on the packaged project file according to a pre-defined test environment configuration file, thus obtaining the target microservice application.

[0010] Optionally, in a fifth implementation of the first aspect of the present invention, after obtaining the main business module to be tested and at least one microservice module to be tested from the module registration data table according to the microservice test request when a microservice test request is received, and performing installation testing on the main business module to be tested and the at least one microservice module to be tested to obtain the target microservice application, the microservice module registration and testing method further includes: when a microservice release request is received, querying the business cluster address from a preset data table according to the microservice release request; and pushing the target microservice application to the business cluster according to the business cluster address, so that the business cluster can deploy, install, and launch the target microservice application.

[0011] Optionally, in a sixth implementation of the first aspect of the present invention, the step of pushing the target microservice application to the business cluster according to the business cluster address, so that the business cluster can deploy, install, and launch the target microservice application, includes: writing the business cluster address into a queue to be published; pushing the target microservice application to the business cluster based on the queue to be published, so that the business cluster can deploy, install, and launch the target microservice application; receiving a publishing result sent by the business cluster, the publishing result including publishing success and publishing failure; migrating the successfully published business cluster address to a preset success queue, and writing the published failure business cluster address into a preset failure queue; and republishing the target microservice application based on the business cluster address in the preset failure queue.

[0012] A second aspect of the present invention provides a microservice module registration and testing apparatus, comprising: an acquisition module, which, upon receiving a microservice registration request, acquires an identifier code corresponding to a main business module and an identifier code corresponding to at least one microservice module according to the microservice registration request, and acquires entry page information of the main business module according to the identifier code corresponding to the main business module, wherein the main business module is used to instruct access control for the at least one microservice module; an addition module, which sets an alias identifier corresponding to each microservice module based on the identifier code corresponding to each microservice module, and adds each microservice module to the entry page information according to the alias identifier corresponding to each microservice module, thereby obtaining updated entry page information; and a registration module, which is used to register the updated entry page information. The entry page information instantiates views and configures routing information for each microservice module to obtain configured entry page information. Based on this configured entry page information, the main business module and each microservice module are mapped and stored in the module registration data table. This configured entry page information is used to indicate a single-page application that associates and combines the main business module and at least one microservice module based on a view file framework. The testing module, upon receiving a microservice test request, retrieves the main business module to be tested and at least one microservice module to be tested from the module registration data table according to the microservice test request. It then performs installation testing on the main business module to be tested and the at least one microservice module to be tested to obtain the target microservice application.

[0013] Optionally, in the first implementation of the second aspect of the present invention, the acquisition module is specifically used for: when a microservice registration request is received, parsing the microservice registration request to obtain a parsing result, and determining whether the parsing result is null; when the parsing result is not null, reading the identifier code corresponding to the main business module and the identifier code corresponding to at least one microservice module from the parsing result, and performing information verification on the identifier code corresponding to the main business module and the identifier code corresponding to the at least one microservice module to obtain a verification result, wherein the main business module is used to instruct access control to be performed on the at least one microservice module; when the verification result is a successful verification, querying a first preset data table according to the identifier code corresponding to the main business module to obtain the entry page path information of the main business module, and reading the entry page information of the main business module according to the entry page path information.

[0014] Optionally, in a second implementation of the second aspect of the present invention, the adding module is specifically used for: querying a second preset data table according to the identifier code corresponding to each microservice module to obtain the index number corresponding to each microservice module; obtaining a preset alias prefix, combining the preset alias prefix with the index number corresponding to each microservice module to obtain the alias identifier corresponding to each microservice module; setting a document object model node for each microservice module, and setting the alias identifier corresponding to each microservice module as the node identifier corresponding to the document object model node of each microservice module to obtain the document object model information corresponding to each microservice module, and adding the document object model information corresponding to each microservice module to the entry page information to obtain the updated entry page information.

[0015] Optionally, in a third implementation of the second aspect of the present invention, the registration module is specifically used for: initializing a corresponding subview file instance in the entry page information according to the alias identifier corresponding to each microservice module; referencing the preset entry file of each microservice module based on a preset import function; and mounting the preset entry file of each microservice module to the subview file instance corresponding to each microservice module; obtaining the routing instance of each microservice module; and binding the routing instance of each microservice module to the subview file instance corresponding to each microservice module, wherein the routing instance of each microservice module corresponds to multiple page nodes, and there is a routing relationship between each page node; and configuring the main business module and the at least one microservice module... The service module sets up a message subscription mechanism to obtain the configured entry page information. The message subscription mechanism is used to monitor the update status of the routing address in the sub-view file instance corresponding to each microservice module. The configured entry page information is used to indicate the single-page application that associates and combines the main business module and the at least one microservice module based on the view file framework. The module obtains the version identifier corresponding to the main business module and the version identifier corresponding to each microservice module. Based on the configured entry page information, the module maps and stores the identifier code corresponding to the main business module, the version identifier corresponding to the main business module, the identifier code corresponding to each microservice module, and the version identifier corresponding to each microservice module into the module registration data table.

[0016] Optionally, in the fourth implementation of the second aspect of the present invention, the testing module is specifically used for: when receiving a microservice testing request, parsing the parameters of the microservice testing request to obtain the version identifier corresponding to the main module of the business to be tested, and querying the version identifier corresponding to each microservice module from the module registration data table according to the version identifier corresponding to the main module of the business to be tested; determining the code repository address corresponding to each module according to the version identifier corresponding to the main module of the business to be tested and the version identifier corresponding to each microservice module to be tested, and obtaining the repository code file corresponding to the main module of the business to be tested and the repository code file corresponding to each microservice module to be tested according to the code repository address corresponding to each module; and determining the code repository address corresponding to each microservice module to be tested according to the version identifier corresponding to the main module of the business to be tested and the version identifier corresponding to each microservice module to be tested. A corresponding alias is used to generate a code root directory for each microservice module to be tested. The repository code files corresponding to each microservice module to be tested are migrated to the code root directory corresponding to each microservice module to be tested. The code root directory corresponding to each microservice module to be tested is copied to the preset microservice module directory of the main business module to be tested, resulting in an updated main business module to be tested. The updated main business module to be tested is packaged using a preset module packager to obtain a packaged project file. The packaged project file is then sent to the test terminal, so that the test terminal can sequentially install, deploy, and perform business logic combination tests on the packaged project file according to the preset test environment configuration file to obtain the target microservice application.

[0017] Optionally, in a fifth implementation of the second aspect of the present invention, the microservice module registration and testing device further includes: a query module, which, when a microservice publishing request is received, is used to query the business cluster address from a preset data table according to the microservice publishing request; and a publishing module, which is used to push the target microservice application to the business cluster according to the business cluster address, so that the business cluster can deploy, install, and launch the target microservice application.

[0018] Optionally, in the sixth implementation of the second aspect of the present invention, the publishing module is specifically used for: writing the business cluster address into a publishing queue; pushing the target microservice application to the business cluster based on the publishing queue, so that the business cluster can deploy, install, and launch the target microservice application; receiving the publishing result sent by the business cluster, the publishing result including publishing success and publishing failure; migrating the successfully published business cluster address to a preset success queue, and writing the failed published business cluster address into a preset failure queue; and republishing the target microservice application based on the business cluster address in the preset failure queue.

[0019] A third aspect of the present invention provides a microservice module registration and testing device, comprising: a memory and at least one processor, wherein the memory stores instructions; the at least one processor invokes the instructions in the memory to cause the microservice module registration and testing device to execute the microservice module registration and testing method described above.

[0020] A fourth aspect of the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the microservice module registration and testing method described above.

[0021] In this embodiment of the invention, each microservice module is registered and routed in the entry page information of the main business module (a single-page application developed based on a view file framework) by using aliases. Based on the modularization of microservices, duplicate code is reduced, running efficiency and accuracy of microservice page navigation are improved, and the combined microservice modules are tested, which improves the accuracy of microservice deployment and page switching performance. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of an embodiment of the microservice module registration and testing method in this invention;

[0023] Figure 2 This is a schematic diagram of another embodiment of the microservice module registration and testing method in this invention;

[0024] Figure 3 This is a schematic diagram of an embodiment of the microservice module registration and testing device in this invention;

[0025] Figure 4 This is a schematic diagram of another embodiment of the microservice module registration and testing device in this invention;

[0026] Figure 5 This is a schematic diagram of an embodiment of the microservice module registration and testing device in this invention. Detailed Implementation

[0027] This invention provides a method, apparatus, device, and storage medium for registering and testing microservice modules. These modules are used to register and configure routing for each microservice module in the entry page information of the main business module using aliases, thereby improving the accuracy of microservice page navigation.

[0028] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” or “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0029] For ease of understanding, the specific process of the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 1 One embodiment of the microservice module registration and testing method in this invention includes:

[0030] 101. When a microservice registration request is received, obtain the identification code corresponding to the main business module and the identification code corresponding to at least one microservice module according to the microservice registration request, and obtain the entry page information of the main business module according to the identification code corresponding to the main business module. The main business module is used to indicate access control for at least one microservice module.

[0031] The identifier codes for the main business module and at least one microservice module are both unique. For example, the identifier code for the main business module is 0, and the identifier codes for at least one microservice module include 1, 2, and 3. Other unique codes can also be used for identification; specific limitations are not specified here. It can be understood that the main business module and each microservice module are business modules pre-developed according to business requirements and based on the view file of a Vue single-page application. Each module includes a corresponding file directory and related program files. The main business module includes an entry page, which is used for flexible combination with at least one microservice module. That is, the main business module can be combined with any number and any combination of microservice modules. For example, the entry page is index.html, and the server uses multiple Document Object Models (DOM) to mount at least one microservice module in index.html.

[0032] It is understood that the executing entity of this invention can be a microservice module registration and testing device, or it can be a terminal or a server; the specific implementation is not limited here. This embodiment of the invention will be described using a server as an example.

[0033] 102. Based on the identifier code corresponding to each microservice module, set an alias identifier for each microservice module, and add each microservice module to the entry page information according to the alias identifier corresponding to each microservice module to obtain the updated entry page information.

[0034] Specifically, the server sets an alias identifier for each microservice module according to the identifier code corresponding to each microservice module, and constructs a corresponding Document Object Model (DOM) node for each microservice module. The node identifier of the DOM node corresponding to each microservice module is the alias identifier of each microservice module. The server adds the DOM node corresponding to each microservice module to the entry page information to obtain the updated entry page information. For example, the server adds at least one DOM node to the entry page index.html, as shown below:

[0035] <div id＝"main">

[0036]

[0037] <div id＝"module_1">

[0038] <div id＝"module_2">

[0039]

[0040] Here, module_1 and module_2 are the alias identifiers corresponding to microservice module A and microservice module B, respectively, and are also the node identifiers of the document object model nodes corresponding to each microservice module.

[0041] 103. In the updated entry page information, instantiate the view and configure the routing information for each microservice module to obtain the configured entry page information. Based on the configured entry page information, map and store the main business module and each microservice module in the module registration data table. The configured entry page information is used to indicate the single-page application that associates and combines the main business module and at least one microservice module based on the view file framework.

[0042] In this context, a single-page application (SPA) refers to an application with only one main page (the entry page information in the main business module). The terminal only needs to load the JavaScript script and CSS resources once, and avoids a blank screen during page transitions. The main business module includes a source code directory, a common component directory, a vue-router routing configuration directory, a static resource directory, and a utility class method directory. It also includes the code directories for each microservice module, such as src / modules, and may include other directories and pre-defined files; specific details are not limited here. Each microservice module includes at least one pre-packaged Vue view component for use in the SPA. It should be noted that before creating the main business module and microservice modules, the server also downloads and installs Node.js and Vue.js view components.

[0043] 104. When a microservice test request is received, retrieve the main business module to be tested and at least one microservice module to be tested from the module registration data table according to the microservice test request, and perform installation testing on the main business module to be tested and at least one microservice module to be tested to obtain the target microservice application.

[0044] It's important to note that each microservice module can be released independently, without a strong dependency on the main business module's version. Furthermore, each microservice module and the main business module can be freely combined and deployed. To ensure that the page a user interacts with corresponds to a specific microservice and to avoid display errors, the server needs to assign different first-level routes to each microservice module. When a microservice module detects that the current route does not belong to its module, it is hidden; otherwise, it is displayed. Specifically, the server integrates, processes, and packages the main business module to be tested and each microservice module to be tested from the module registration data table, and then sends it to the test terminal. The test terminal then installs and tests the packaged main business module and each microservice module to be tested, obtaining the test results. When the test passes, the server identifies the target microservice application. Further, the target microservice application is stored in a blockchain database; the specifics are not limited here.

[0045] In this embodiment of the invention, each microservice module is registered and routed in the entry page information of the main business module (a single-page application developed based on a view file framework) by using aliases. Based on the modularization of microservices, duplicate code is reduced, running efficiency and accuracy of microservice page navigation are improved, and the combined microservice modules are tested, which improves the accuracy of microservice deployment and page switching performance.

[0046] Please see Figure 2 Another embodiment of the microservice module registration and testing method in this invention includes:

[0047] 201. When a microservice registration request is received, obtain the identification code corresponding to the main business module and the identification code corresponding to at least one microservice module according to the microservice registration request, and obtain the entry page information of the main business module according to the identification code corresponding to the main business module. The main business module is used to indicate access control for at least one microservice module.

[0048] The identification codes of the main business module and each microservice module can be identified by a universally unique identifier or by other strings (such as a combination of preset characters and timestamps). No specific restrictions are imposed here.

[0049] Optionally, when the server receives a microservice registration request, the server parses the microservice registration request, obtains the parsing result, and determines whether the parsing result is null. If the parsing result is not null, the server reads the identifier code corresponding to the main business module and the identifier code corresponding to at least one microservice module from the parsing result, and performs information verification on the identifier code corresponding to the main business module and the identifier code corresponding to at least one microservice module to obtain the verification result. The main business module is used to indicate access control for at least one microservice module. Furthermore, the server can also perform version verification on the identifier code to obtain the verification result. If the verification result is verification failure, the server sends a prompt message containing verification failure to the terminal. If the verification result is verification success, the server queries the first preset data table according to the identifier code corresponding to the main business module to obtain the entry page path information of the main business module, and reads the entry page information of the main business module according to the entry page path information.

[0050] It should be noted that the first preset data table is used to indicate the mapping relationship between the entry page path information of different versions of the main business module and the identification code of the main business module under different business scenarios.

[0051] 202. Based on the identifier code corresponding to each microservice module, set the alias identifier corresponding to each microservice module, and add each microservice module to the entry page information according to the alias identifier corresponding to each microservice module to obtain the updated entry page information.

[0052] Each microservice module has a unique alias identifier. The server adds a Document Object Model node to the entry page information to mount at least one view file instance.

[0053] Optionally, firstly, the server queries a second preset data table based on the identifier code corresponding to each microservice module to obtain the index number corresponding to each microservice module. The second preset data table indicates the mapping information between the identifier code and the index number of each microservice module. The index number can be 1, 2, ..., n, or 01, 02, ..., 09, 10, 11, ..., n, where n is a positive integer, and the specific value is not limited here. Secondly, the server obtains a preset alias prefix and combines the preset alias prefix with the index number corresponding to each microservice module to obtain the alias identifier for each microservice module. The index number is the same for the same microservice module in different versions. The preset alias prefix can be set and updated according to actual business needs. For example, if the preset alias prefix is ​​"module" and the index number is 1, then the alias identifier corresponding to microservice module A can be either "module1" or "module_1," and the specific value is not limited here. Furthermore, the server associates and updates the identifier code and alias identifier corresponding to each microservice module in the preset alias information table to improve the efficiency of alias setting. Then, the server sets a document object model node for each microservice module and sets the alias identifier corresponding to each microservice module to the node identifier corresponding to the document object model node of each microservice module, thereby obtaining the document object model information corresponding to each microservice module. The server then adds the document object model information corresponding to each microservice module to the entry page information to obtain the updated entry page information.

[0054] 203. In the updated entry page information, instantiate the view and configure the routing information for each microservice module to obtain the configured entry page information. Based on the configured entry page information, map and store the main business module and each microservice module in the module registration data table. The configured entry page information is used to indicate the single-page application that associates and combines the main business module and at least one microservice module based on the view file framework.

[0055] In other words, the server associates and maps each microservice module with the main business module. Optionally, firstly, the server initializes the corresponding subview file instance in the entry page information according to the alias identifier of each microservice module, references the preset entry file of each microservice module based on the preset import function, and mounts the preset entry file of each microservice module to the corresponding subview file instance. Specifically, the server declares the hypertext markup language content rendered by each microservice module, then obtains the document object model object corresponding to each microservice module according to the alias identifier, defines the corresponding subview file instance according to the document object model object, and mounts the preset entry file of the microservice module corresponding to each document object model object (the pre-created and encapsulated entry file of the microservice module) in the subview file instance. Each document object model object corresponds to each microservice module. It can be understood that the entry page information includes not only a root view file instance but also at least one subview file instance; each subview file instance maintains the corresponding route and page. The main business module combines at least one microservice module into a microservice application, where each microservice module can also run independently.

[0056] Then, the server retrieves the route instance for each microservice module and binds it to the corresponding subview file instance. Each microservice module's route instance corresponds to multiple page nodes, and routing relationships exist between these page nodes. The default routing function is the route management tool vue-router. The server uses vue-router to pre-create the route instance for each microservice module and maps and stores it according to the identifier encoding of the microservice module. The server performs route mapping for each microservice module so that the main business module can access the multiple page nodes of each microservice module through the corresponding Uniform Resource Locator (URL).

[0057] Secondly, the server sets up a message subscription mechanism for the main business module and at least one microservice module to obtain the configured entry page information. This message subscription mechanism monitors the update status of the route address in the sub-view file instance corresponding to each microservice module. The configured entry page information indicates the single-page application (SPA) that associates and combines the main business module and at least one microservice module based on the view file framework. Further, the server calls the preset function `router.start()` to start the route and mount it to the corresponding application element, and then calls `npm runbuild` in the command line to check if the SPA has been created successfully. If successful, the server determines that the SPA has been created successfully. It should be noted that SPA navigation involves switching related components and refreshing only partial resources, not the entire page. However, vue-router is mounted on multiple view instances. When the URL of any microservice module's vue instance changes, other related microservice modules cannot immediately change their routes. Therefore, in order to ensure normal page access, the server adopts a communication mechanism between modules (such as a message subscription mechanism). The server uses the main business module as a message relay link to publish messages that any microservice module's vue instance updates the route address, which improves the accuracy of page navigation and the page switching performance of single-page applications.

[0058] Finally, the server obtains the version identifier corresponding to the main business module and the version identifier corresponding to each microservice module, and maps and stores the identifier code corresponding to the main business module, the version identifier corresponding to the main business module, the identifier code corresponding to each microservice module, and the version identifier corresponding to each microservice module into the module registration data table according to the configured entry page information.

[0059] 204. When a microservice test request is received, retrieve the main business module to be tested and at least one microservice module to be tested from the module registration data table according to the microservice test request, and perform installation testing on the main business module to be tested and at least one microservice module to be tested to obtain the target microservice application.

[0060] The target microservice application is an application that has been tested and verified. Optionally, when the server receives a microservice test request, the server parses the parameters of the microservice test request to obtain the version identifier corresponding to the main module of the business to be tested, and queries the module registration data table for the version identifier corresponding to each microservice module based on the version identifier corresponding to the main module of the business to be tested; the server determines the code repository address corresponding to each module according to the version identifier corresponding to the main module of the business to be tested and the version identifier corresponding to each microservice module to be tested, and obtains the repository code file corresponding to the main module of the business to be tested and the repository code file corresponding to each microservice module to be tested according to the code repository address corresponding to each module; the server identifies each microservice module to be tested according to the alias identifier corresponding to each microservice module to be tested. The server generates a corresponding code root directory for each microservice module to be tested. It then migrates the repository code files for each microservice module to be tested to its corresponding code root directory and copies this directory to the pre-defined microservice module directory of the main business module to be tested, resulting in an updated main business module. The server then packages the updated main business module using a pre-defined module packager, producing a packaged project file. This packaged project file is sent to the test terminal, allowing the test terminal to sequentially install, deploy, and perform business logic combination tests on the packaged project file according to the pre-defined test environment configuration file, thus obtaining the target microservice application.

[0061] 205. When a microservice deployment request is received, the business cluster address is queried from the preset data table according to the microservice deployment request.

[0062] In other words, when the server receives a microservice deployment request, the server parses the microservice deployment request, obtains the business identifier, and reads the business cluster address from a preset data table according to the business identifier.

[0063] 206. Push the target microservice application to the business cluster according to the business cluster address, so that the business cluster can deploy, install and launch the target microservice application.

[0064] Specifically, the server writes the business cluster address into a queue to be published, and pushes the target microservice application to the business cluster based on the queue, so that the business cluster can deploy and install the target microservice application and put it into operation. The server receives the publication results sent by the business cluster, including publication success and publication failure. The server migrates the published business cluster address to a preset success queue and writes the published business cluster address to a preset failure queue. The server republishes the target microservice application based on the business cluster address in the preset failure queue.

[0065] Furthermore, when the data in the preset failure queue is empty and the number of business cluster addresses in the preset success queue is the preset number, the server determines that the target microservice application has been successfully published.

[0066] In this embodiment of the invention, each microservice module is registered and routed in the entry page information of the main business module (a single-page application developed based on a view file framework) by using aliases. Based on the modularization of microservices, duplicate code is reduced, running efficiency and accuracy of microservice page navigation are improved, and the combined microservice modules are tested, which improves the accuracy of microservice deployment and page switching performance.

[0067] The microservice module registration and testing method in the embodiments of the present invention has been described above. The microservice module registration and testing apparatus in the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 3 One embodiment of the microservice module registration and testing device in this invention includes:

[0068] The acquisition module 301, when receiving a microservice registration request, is used to obtain the identification code corresponding to the main business module and the identification code corresponding to at least one microservice module according to the microservice registration request, and to obtain the entry page information of the main business module according to the identification code corresponding to the main business module. The main business module is used to indicate access control for at least one microservice module.

[0069] Add module 302, which is used to set the alias identifier for each microservice module based on the identifier code corresponding to each microservice module, and add each microservice module to the entry page information according to the alias identifier corresponding to each microservice module to obtain the updated entry page information;

[0070] The registration module 303 is used to instantiate the view and configure the routing information for each microservice module in the updated entry page information, obtain the configured entry page information, and map and store the main business module and each microservice module to the module registration data table according to the configured entry page information. The configured entry page information is used to indicate the single-page application that associates and combines the main business module and at least one microservice module based on the view file framework.

[0071] Test module 304, when receiving a microservice test request, is used to retrieve the main business module to be tested and at least one microservice module to be tested from the module registration data table according to the microservice test request, and to install and test the main business module to be tested and at least one microservice module to be tested to obtain the target microservice application.

[0072] Furthermore, the target microservice application is stored in a blockchain database, the specifics of which are not limited here.

[0073] In this embodiment of the invention, each microservice module is registered and routed in the entry page information of the main business module (a single-page application developed based on a view file framework) by using aliases. Based on the modularization of microservices, duplicate code is reduced, running efficiency and accuracy of microservice page navigation are improved, and the combined microservice modules are tested, which improves the accuracy of microservice deployment and page switching performance.

[0074] Please see Figure 4 Another embodiment of the microservice module registration and testing device in this invention includes:

[0075] The acquisition module 301, when receiving a microservice registration request, is used to obtain the identification code corresponding to the main business module and the identification code corresponding to at least one microservice module according to the microservice registration request, and to obtain the entry page information of the main business module according to the identification code corresponding to the main business module. The main business module is used to indicate access control for at least one microservice module.

[0076] Add module 302, which is used to set the alias identifier for each microservice module based on the identifier code corresponding to each microservice module, and add each microservice module to the entry page information according to the alias identifier corresponding to each microservice module to obtain the updated entry page information;

[0077] The registration module 303 is used to instantiate the view and configure the routing information for each microservice module in the updated entry page information, obtain the configured entry page information, and map and store the main business module and each microservice module to the module registration data table according to the configured entry page information. The configured entry page information is used to indicate the single-page application that associates and combines the main business module and at least one microservice module based on the view file framework.

[0078] Test module 304, when receiving a microservice test request, is used to retrieve the main business module to be tested and at least one microservice module to be tested from the module registration data table according to the microservice test request, and to install and test the main business module to be tested and at least one microservice module to be tested to obtain the target microservice application.

[0079] Optionally, the acquisition module 301 can also be specifically used for:

[0080] When a microservice registration request is received, the request is parsed to obtain the parsing result, and it is determined whether the parsing result is null. If the parsing result is not null, the identifier code corresponding to the main business module and the identifier code corresponding to at least one microservice module are read from the parsing result, and the identifier code corresponding to the main business module and the identifier code corresponding to at least one microservice module are verified to obtain the verification result. The main business module is used to instruct access control to be performed on at least one microservice module. If the verification result is successful, the first preset data table is queried according to the identifier code corresponding to the main business module to obtain the entry page path information of the main business module, and the entry page information of the main business module is read according to the entry page path information.

[0081] Optionally, module 302 is also specifically used for:

[0082] The second preset data table is queried based on the identifier code corresponding to each microservice module to obtain the index number corresponding to each microservice module; a preset alias prefix is ​​obtained, and the preset alias prefix is ​​combined with the index number corresponding to each microservice module to obtain the alias identifier corresponding to each microservice module; a document object model node is set for each microservice module, and the alias identifier corresponding to each microservice module is set as the node identifier corresponding to the document object model node of each microservice module to obtain the document object model information corresponding to each microservice module; the document object model information corresponding to each microservice module is added to the entry page information to obtain the updated entry page information.

[0083] Optionally, the registration module 303 is also specifically used for:

[0084] The entry page information initializes the corresponding subview file instance according to the alias identifier of each microservice module. It references the preset entry file of each microservice module based on a preset import function and mounts the preset entry file of each microservice module to the corresponding subview file instance. It obtains the route instance of each microservice module and binds it to the corresponding subview file instance. Each microservice module's route instance corresponds to multiple page nodes, and there are routing relationships between each page node. A message subscription mechanism is set up for the main business module and at least one microservice module to obtain the configured entry page information. The message subscription mechanism is used to monitor the update status of the route address in the corresponding subview file instance of each microservice module. The configured entry page information is used to indicate the single-page application that associates and combines the main business module and at least one microservice module based on the view file framework. It obtains the version identifier of the main business module and the version identifier of each microservice module, and maps and stores the identifier code of the main business module, the version identifier of the main business module, the identifier code of each microservice module, and the version identifier of each microservice module to the module registration data table according to the configured entry page information.

[0085] Optionally, test module 304 can also be specifically used for:

[0086] Upon receiving a microservice test request, the parameters of the request are parsed to obtain the version identifier corresponding to the main module of the business under test. Based on this version identifier, the version identifier for each microservice module is retrieved from the module registration data table. The code repository address for each module is determined according to both the version identifiers of the main module and each microservice module. The repository code files for both the main module and each microservice module are then retrieved based on these addresses. Finally, each microservice module is assigned an alias identifier. The system generates a corresponding code root directory for each microservice module to be tested, migrates the repository code files for each microservice module to be tested to its corresponding code root directory, and copies the code root directory of each microservice module to be tested to the preset microservice module directory of the main business module to be tested, resulting in an updated main business module to be tested. The updated main business module to be tested is then packaged using a preset module packager to obtain a packaged project file, which is then sent to the test terminal. This allows the test terminal to sequentially install, deploy, and perform business logic combination tests on the packaged project file according to the preset test environment configuration file, thus obtaining the target microservice application.

[0087] Optionally, the microservice module registration and testing device also includes:

[0088] The query module 305, upon receiving a microservice deployment request, queries the business cluster address from a preset data table based on the microservice deployment request; the deployment module 306, pushes the target microservice application to the business cluster according to the business cluster address, so that the business cluster can deploy, install, and launch the target microservice application.

[0089] Optionally, the publishing module 306 can also be specifically used for:

[0090] Write the business cluster address into the deployment queue, and push the target microservice application to the business cluster based on the deployment queue so that the business cluster can deploy and install the target microservice application and put it into operation; receive the deployment results sent by the business cluster, including deployment success and deployment failure; migrate the successfully deployed business cluster address to the preset success queue, and write the failed deployment business cluster address into the preset failure queue; re-deploy the target microservice application based on the business cluster address in the preset failure queue.

[0091] In this embodiment of the invention, each microservice module is registered and routed in the entry page information of the main business module (a single-page application developed based on a view file framework) by using aliases. Based on the modularization of microservices, duplicate code is reduced, running efficiency and accuracy of microservice page navigation are improved, and the combined microservice modules are tested, which improves the accuracy of microservice deployment and page switching performance.

[0092] above Figure 3 and Figure 4 The microservice module registration and testing device in this embodiment of the invention is described in detail from a modular perspective. The microservice module registration and testing equipment in this embodiment of the invention is described in detail from a hardware processing perspective.

[0093] Figure 5This is a schematic diagram of a microservice module registration and testing device 500 provided in an embodiment of the present invention. The microservice module registration and testing device 500 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 510 (e.g., one or more processors) and memory 520, and one or more storage media 530 (e.g., one or more mass storage devices) for storing applications 533 or data 532. The memory 520 and storage media 530 can be temporary or persistent storage. The program stored in the storage media 530 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the microservice module registration and testing device 500. Furthermore, the processor 510 may be configured to communicate with the storage media 530 and execute the series of instruction operations in the storage media 530 on the microservice module registration and testing device 500.

[0094] The microservice module registration and testing device 500 may also include one or more power supplies 540, one or more wired or wireless network interfaces 550, one or more input / output interfaces 560, and / or one or more operating systems 531, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc. Those skilled in the art will understand that... Figure 5 The illustrated microservice module registration and testing equipment structure does not constitute a limitation on the microservice module registration and testing equipment. It may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.

[0095] The present invention also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when the instructions are executed on a computer, cause the computer to perform the steps of the microservice module registration and testing method.

[0096] The present invention also provides a microservice module registration and testing device, the microservice module registration and testing device including a memory and a processor, the memory storing instructions, and when the instructions are executed by the processor, the processor performs the steps of the microservice module registration and testing method in each of the above embodiments.

[0097] Furthermore, the computer-readable storage medium may primarily include a program storage area and a data storage area, wherein the program storage area may store the operating system, at least one application required for a function, etc.; and the data storage area may store data created based on the use of blockchain nodes, etc.

[0098] The blockchain referred to in this invention is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying blockchain platform, a platform product service layer, and an application service layer.

[0099] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0100] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc., any medium capable of storing program code.

[0101] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in each of the foregoing embodiments, or equivalent substitutions can be made to some of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of each embodiment of the present invention.

Claims

1. A microservice module registration and testing method, characterized in that, The microservice module registration and testing methods include: When a microservice registration request is received, the identifier code corresponding to the main business module and the identifier code corresponding to at least one microservice module are obtained according to the microservice registration request. The entry page information of the main business module is obtained according to the identifier code corresponding to the main business module. The main business module is used to indicate access control for the at least one microservice module. Based on the identifier code corresponding to each microservice module, set an alias identifier for each microservice module, and add each microservice module to the entry page information according to the alias identifier corresponding to each microservice module to obtain the updated entry page information; In the updated entry page information, view instantiation and routing information configuration are performed for each microservice module to obtain the configured entry page information. Based on the configured entry page information, the main business module and each microservice module are mapped and stored in the module registration data table. The configured entry page information is used to indicate a single-page application that associates and combines the main business module and at least one microservice module based on the view file framework. When a microservice test request is received, the main business module to be tested and at least one microservice module to be tested are obtained from the module registration data table according to the microservice test request, and the main business module to be tested and the at least one microservice module to be tested are installed and tested to obtain the target microservice application.

2. The microservice module registration and testing method according to claim 1, characterized in that, When a microservice registration request is received, the system obtains the identifier code corresponding to the main business module and the identifier code corresponding to at least one microservice module according to the microservice registration request. It then obtains the entry page information of the main business module based on the identifier code corresponding to the main business module. The main business module is used to instruct access control on the at least one microservice module, including: When a microservice registration request is received, the microservice registration request is parsed to obtain the parsing result, and it is determined whether the parsing result is null. When the parsing result is not empty, the identifier code corresponding to the main business module and the identifier code corresponding to at least one microservice module are read from the parsing result, and the identifier code corresponding to the main business module and the identifier code corresponding to the at least one microservice module are verified to obtain the verification result. The main business module is used to indicate access control for the at least one microservice module. When the verification result is successful, the first preset data table is queried according to the identifier code corresponding to the main business module to obtain the entry page path information of the main business module, and the entry page information of the main business module is read according to the entry page path information.

3. The microservice module registration and testing method according to claim 2, characterized in that, The process involves setting an alias identifier for each microservice module based on its corresponding identifier code, and adding each microservice module to the entry page information according to its alias identifier, resulting in updated entry page information, including: Query the second preset data table based on the identifier code corresponding to each microservice module to obtain the index number corresponding to each microservice module; Obtain a preset alias prefix, and combine the preset alias prefix with the index number corresponding to each microservice module to obtain the alias identifier corresponding to each microservice module; A document object model node is set for each microservice module, and the alias identifier corresponding to each microservice module is set as the node identifier corresponding to the document object model node of each microservice module to obtain the document object model information corresponding to each microservice module. The document object model information corresponding to each microservice module is then added to the entry page information to obtain the updated entry page information.

4. The microservice module registration and testing method according to claim 1, characterized in that, The process involves instantiating views and configuring routing information for each microservice module within the updated entry page information to obtain configured entry page information. Based on this configured entry page information, the main business module and each microservice module are mapped and stored in the module registration data table. The configured entry page information is used to indicate a single-page application that associates and combines the main business module and at least one microservice module based on a view file framework, including: In the entry page information, the corresponding sub-view file instance is initialized according to the alias identifier of each microservice module, the preset entry file of each microservice module is referenced based on the preset import function, and the preset entry file of each microservice module is mounted to the sub-view file instance corresponding to each microservice module. Obtain the route instance for each microservice module and bind the route instance of each microservice module to the subview file instance corresponding to each microservice module. The route instance of each microservice module corresponds to multiple page nodes, and there are routing relationships between each page node. A message subscription mechanism is set for the main business module and the at least one microservice module to obtain the configured entry page information. The message subscription mechanism is used to monitor the update status of the routing address in the subview file instance corresponding to each microservice module. The configured entry page information is used to indicate the single-page application that associates and combines the main business module and the at least one microservice module based on the view file framework. Obtain the version identifier corresponding to the main business module and the version identifier corresponding to each microservice module. Based on the configured entry page information, map and store the identifier code corresponding to the main business module, the version identifier corresponding to the main business module, the identifier code corresponding to each microservice module, and the version identifier corresponding to each microservice module into the module registration data table.

5. The microservice module registration and testing method according to claim 4, characterized in that, When a microservice test request is received, the system retrieves the main business module to be tested and at least one microservice module to be tested from the module registration data table according to the microservice test request, and performs installation testing on the main business module to be tested and the at least one microservice module to be tested to obtain the target microservice application, including: When a microservice test request is received, the parameters of the microservice test request are parsed to obtain the version identifier corresponding to the main module of the business to be tested, and the version identifier corresponding to each microservice module is queried from the module registration data table according to the version identifier corresponding to the main module of the business to be tested. The code repository address corresponding to each module is determined according to the version identifier of the main module of the business to be tested and the version identifier of each microservice module to be tested. The repository code file corresponding to the main module of the business to be tested and the repository code file corresponding to each microservice module to be tested are obtained according to the code repository address of each module. Generate a corresponding code root directory for each microservice module to be tested according to the alias identifier of each microservice module to be tested, migrate the repository code files corresponding to each microservice module to be tested to the code root directory corresponding to each microservice module to be tested, and copy the code root directory corresponding to each microservice module to be tested to the preset microservice module directory of the main business module to be tested, so as to obtain the updated main business module to be tested. The updated main module of the business to be tested is packaged using a preset module packager to obtain a packaged project file. The packaged project file is then sent to the test terminal, so that the test terminal can sequentially install, deploy, and perform business logic combination tests on the packaged project file according to the preset test environment configuration file to obtain the target microservice application.

6. The microservice module registration and testing method according to any one of claims 1-5, characterized in that, Upon receiving a microservice test request, the method retrieves the main business module to be tested and at least one microservice module to be tested from the module registration data table according to the microservice test request, and performs installation testing on the main business module to be tested and the at least one microservice module to be tested to obtain the target microservice application. The microservice module registration and testing method further includes: When a microservice deployment request is received, the business cluster address is queried from a preset data table according to the microservice deployment request. The target microservice application is pushed to the business cluster according to the business cluster address, so that the business cluster can deploy, install and launch the target microservice application.

7. The microservice module registration and testing method according to claim 6, characterized in that, The step of pushing the target microservice application to the business cluster according to the business cluster address, so that the business cluster can deploy, install, and launch the target microservice application, includes: The business cluster address is written into the deployment queue, and the target microservice application is pushed to the business cluster based on the deployment queue, so that the business cluster can deploy, install and launch the target microservice application. Receive the publishing result sent by the service cluster, the publishing result including publishing success and publishing failure; Migrate the successfully published business cluster addresses to a preset success queue, and write the unpublished business cluster addresses to a preset failure queue. The target microservice application is republished based on the business cluster address in the preset failure queue.

8. A microservice module registration and testing device, characterized in that, The microservice module registration and testing device includes: The acquisition module, upon receiving a microservice registration request, is used to acquire the identifier code corresponding to the main business module and the identifier code corresponding to at least one microservice module according to the microservice registration request, and to acquire the entry page information of the main business module according to the identifier code corresponding to the main business module. The main business module is used to instruct access control to be performed on the at least one microservice module. The add module is used to set the alias identifier for each microservice module based on the identifier code corresponding to each microservice module, and add each microservice module to the entry page information according to the alias identifier corresponding to each microservice module to obtain the updated entry page information; The registration module is used to instantiate the view and configure the routing information for each microservice module in the updated entry page information to obtain the configured entry page information, and to map and store the main business module and each microservice module to the module registration data table according to the configured entry page information. The configured entry page information is used to indicate a single-page application that associates and combines the main business module and at least one microservice module based on the view file framework. The testing module, upon receiving a microservice testing request, retrieves the main business module to be tested and at least one microservice module to be tested from the module registration data table according to the microservice testing request, and performs installation testing on the main business module to be tested and the at least one microservice module to be tested to obtain the target microservice application.

9. A microservice module registration and testing device, characterized in that, The microservice module registration and testing device includes: a memory and at least one processor, wherein the memory stores instructions; The at least one processor invokes the instructions in the memory to cause the microservice module registration and testing device to execute the microservice module registration and testing method as described in any one of claims 1-7.

10. A computer-readable storage medium having instructions stored thereon, characterized in that, When the instruction is executed by the processor, it implements the microservice module registration and testing method as described in any one of claims 1-7.

Images