Front-end service proxy method and device for docking micro-service development, and electronic equipment

Abstract

The application relates to a front-end service proxy method and device for docking micro-service development and an electronic device. A micro-service to be tested is acquired; according to a test item of the micro-service to be tested, an associated micro-service is determined; the associated micro-service is transmitted to a unified test environment; the micro-service to be tested is matched to a corresponding server through a proxy; and based on middleware processing logic, the unified test environment is started to perform function testing on the micro-service to be tested. Through the method provided in the application, when the micro-service to be tested is tested, other associated micro-services no longer need to be downloaded and started, and the memory is occupied. In addition, the problem of download error caused by too many versions of the associated micro-services is avoided. Therefore, invalid debugging can be avoided, and the testing efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of software development technology, and in particular to a front-end service proxy method, device, and electronic device for connecting to microservice development. Background Art

[0002] Before a platform or software is put into use, it must be developed by professional technicians. During the development process, technicians must continuously debug its functions to ensure that the developed content can achieve the intended display format and functions. Only when all display formats and functions can be displayed normally can the platform be considered to have initially achieved the expected results.

[0003] During the development process, front-end projects integrate with multiple microservices. Therefore, the development team assigns tasks to each technician, with each technician responsible for developing the relevant aspects of their respective microservices. However, after development is complete, if a technician tests a microservice function that involves other microservices, they must download and start the latest versions of the microservices assigned by the other technicians. This means that each functional test requires downloading the latest versions of the microservices updated by other technicians. Sometimes, due to the large number of versions of other microservices, if a non-latest version is started, the corresponding microservice function cannot be tested properly, leading to misjudgment of problems with the corresponding microservice development and ineffective debugging. This reduces testing efficiency, impacts subsequent development, and delays the overall development progress. Summary of the Invention

[0004] The present application provides a front-end service proxy method, device, and electronic device for connecting to microservice development.

[0005] In a first aspect, the present application provides a front-end service proxy method for connecting to microservice development, the method comprising:

[0006] Get the microservice to be tested;

[0007] Determine the associated microservices based on the items to be tested of the microservices to be tested;

[0008] Transmitting the associated microservices to a unified test environment;

[0009] Match the microservice to be tested to the corresponding server through proxy;

[0010] Based on the middleware processing logic, the unified test environment is started to perform functional testing of the microservice to be tested.

[0011] This application obtains the microservice to be tested and the corresponding project to be tested, determines the associated microservices required for the test, and transfers the above-mentioned associated microservices to a unified test environment. The microservice to be tested is matched to the corresponding server through a proxy, and according to the middleware processing logic, the unified test environment after the transfer is started to perform functional testing of the microservice to be tested. Through the method provided by this application, when testing the microservice to be tested, other associated microservices no longer need to be downloaded and started, occupying memory. In addition, the problem of download errors caused by too many versions of associated microservices is avoided. This can avoid invalid debugging and improve test efficiency.

[0012] Optionally, matching the microservice to be tested to a corresponding server through a proxy includes:

[0013] Get the API address corresponding to the microservice to be tested;

[0014] Based on the middleware processing logic, determine whether the proxy contains a server corresponding to the microservice to be tested.

[0015] If the proxy contains a server corresponding to the microservice to be tested, the API address is reconstructed to obtain a processed API address;

[0016] The microservice to be tested corresponding to the processed API address is sent to the corresponding server through the proxy.

[0017] Accordingly, the API address corresponding to the microservice under test is obtained, and the middleware processing logic is used to determine whether the corresponding server of the microservice under test exists in the proxy. If the server of the microservice under test exists in the proxy, the obtained API address of the microservice under test is reconstructed to obtain a processed API address, so that the microservice under test corresponding to the API address can be connected to the corresponding server through the proxy. By reconstructing the API address, the microservice under test can be identified and matched by the proxy, thereby improving the matching accuracy.

[0018] Optionally, if the proxy contains a server corresponding to the microservice to be tested, the API address is reconstructed to obtain a processed API address, including:

[0019] If the server corresponding to the microservice to be tested exists in the proxy, identify the address code in the proxy;

[0020] According to the address code, the API address is reconstructed so that the proxy can recognize and match the server.

[0021] When reconstructing the API address, we first determine whether the server corresponding to the microservice under test exists in the proxy. If so, we identify the address code in the proxy and reconstruct the API address based on the address code in the proxy so that the proxy can recognize it. This method simplifies the matching process and improves recognition efficiency.

[0022] Optionally, the method further includes:

[0023] Get the configuration file and the server's IP address;

[0024] Determine the microservice to be tested corresponding to the IP address;

[0025] Based on the configuration file, configure the proxy corresponding to the microservice to be tested.

[0026] When configuring a proxy, first obtain the configuration file and the server's IP address. Use the server's IP address to identify the microservice to be tested. Once the microservice to be tested is identified, use the configuration file to configure the proxy for the microservice to be tested. This method allows you to obtain all microservices to be tested on the server and configure the corresponding proxy. This prevents errors that might cause microservices to be missed, improving work efficiency.

[0027] Optionally, the method further includes:

[0028] Based on the middleware processing logic, if the associated microservice is proxied to the server in the proxy, an alarm reminder is activated.

[0029] In this way, when an agent error occurs, an alarm will be issued in time to avoid invalid debugging due to mistakes, which will waste time and delay development progress.

[0030] Optionally, the method further includes:

[0031] After the associated microservices are transferred to a unified test environment and the microservice to be tested is transmitted to the corresponding server through the proxy, the microservice to be tested is tested and whether the test is successful is determined;

[0032] If the test fails, analyze all the content in the microservice to be tested to determine whether there are any errors in the microservice to be tested;

[0033] If there is an error in the microservice to be tested, the source of the error will be noted based on the analysis results for modification and adjustment.

[0034] Through the method provided by this embodiment, if a problem occurs during the test, the source of the error can be analyzed and discovered in a timely manner. If it is determined that the problem is with the microservice to be tested, the source of the error can be found more quickly according to the method provided by this embodiment, thereby improving work efficiency.

[0035] Optionally, the method further includes:

[0036] If it is determined through analysis that there is no error in the microservice to be tested, the related microservices are analyzed to determine abnormal related microservices and kick the abnormal related microservices out of the unified test environment;

[0037] Obtain the updated version of the exception-related microservice;

[0038] Scan the updated version to determine whether there is any anomaly in the updated version;

[0039] If there is no abnormality in the updated version, the updated version is allowed to be transmitted to the unified test environment to test the microservice to be tested.

[0040] Through the approach provided by this embodiment, if a test failure is caused by an issue with an associated microservice, the abnormal associated microservice can be kicked out of the unified test environment, updated, and then retrieved and scanned. If it is determined that there are no issues, the unified test environment can be re-entered for subsequent testing. This approach allows for timely resolution of issues with associated microservices and avoids the problem of test failures due to the tester forgetting to obtain the updated version. At the same time, after the abnormal associated microservice is determined, it can be updated in a timely manner, improving work efficiency, avoiding wasted work, and significantly shortening the debugging cycle.

[0041] In a second aspect, the present application provides a front-end service proxy device for connecting to microservice development, including:

[0042] The microservice acquisition module to be tested is used to obtain the microservice to be tested;

[0043] The associated microservice determination module determines the associated microservices based on the items to be tested of the microservices to be tested;

[0044] An associated microservice transmission module, used to transmit the associated microservices to a unified test environment;

[0045] The microservice matching module to be tested is used to match the microservice to be tested to the corresponding server through a proxy;

[0046] The functional testing module is used to start the unified testing environment to perform functional testing of the microservice to be tested based on the middleware processing logic.

[0047] Optionally, the to-be-tested microservice matching module, when matching the to-be-tested microservice to the corresponding service end through the proxy, is specifically configured to:

[0048] acquire the api address corresponding to the to-be-tested microservice;

[0049] determine whether the proxy has the service end corresponding to the to-be-tested microservice based on the middleware processing logic;

[0050] if the proxy has the service end corresponding to the to-be-tested microservice, reconstruct the api address to obtain a processed api address;

[0051] match the to-be-tested microservice corresponding to the processed api address to the corresponding service end through the proxy.

[0052] Optionally, the to-be-tested microservice matching module, when the proxy has the service end corresponding to the to-be-tested microservice, reconstructs the api address to obtain a processed api address, and is specifically configured to:

[0053] if the proxy has the service end corresponding to the to-be-tested microservice, identify the address code in the proxy;

[0054] reconstruct the api address according to the address code to enable the proxy to identify and match the service end.

[0055] Optionally, the front-end service proxy device for interfacing microservice development further includes a proxy configuration module, configured to:

[0056] acquire a configuration file and an IP address of a service end;

[0057] determine the to-be-tested microservice corresponding to the IP address;

[0058] configure the proxy corresponding to the to-be-tested microservice based on the configuration file.

[0059] Optionally, the front-end service proxy device for interfacing microservice development further includes an alarm reminding module, configured to:

[0060] if the associated microservice proxy matches the service end in the proxy based on the middleware processing logic, start an alarm reminder.

[0061] Optionally, the front-end service proxy device for interfacing microservice development further includes an error analysis module, configured to:

[0062] After the associated microservice is transmitted to the unified test environment and the to-be-tested microservice is connected to the corresponding service end through the proxy, the test of the to-be-tested microservice is performed, and it is determined whether the test is successful;

[0063] If the test fails, all contents in the to-be-tested microservice are analyzed to determine whether the to-be-tested microservice has an error;

[0064] If the to-be-tested microservice has an error, the error source is noted according to the analysis result for modification and adjustment.

[0065] Optionally, the error analysis module is specifically configured to:

[0066] If it is determined through the analysis that the to-be-tested microservice does not have an error, the associated microservice is analyzed to determine an abnormal associated microservice and the abnormal associated microservice is kicked out of the unified test environment;

[0067] An updated version of the abnormal associated microservice is acquired;

[0068] The updated version is scanned to determine whether the updated version has an abnormality;

[0069] If the updated version does not have an abnormality, the updated version is allowed to be transmitted to the unified test environment for the test of the to-be-tested microservice.

[0070] In a third aspect, the present application provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program capable of being loaded and executed by the processor to execute the method of the first aspect.

[0071] In a fourth aspect, the present application provides a computer readable storage medium, which stores a computer program capable of being loaded and executed by a processor to execute the method of the first aspect. BRIEF DESCRIPTION OF DRAWINGS

[0072] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0073] Figure 1 An application scenario schematic diagram is provided for an embodiment of the present application;

[0074] Figure 2 A flowchart of a front-end service proxy method for docking microservice development is provided for an embodiment of the present application;

[0075] Figure 3 A flowchart of another front-end service proxy method for connecting to microservice development provided in one embodiment of the present application;

[0076] Figure 4 A flowchart of another front-end service proxy method for connecting to microservice development provided in one embodiment of the present application;

[0077] Figure 5 A schematic diagram of the structure of a front-end service proxy device for docking microservice development provided in one embodiment of the present application;

[0078] Figure 6 A schematic structural diagram of an electronic device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0079] To make the purpose, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0080] In this document, the term "and / or" simply describes a relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " in this document, unless otherwise specified, generally indicates an "or" relationship between the related objects.

[0081] The embodiments of the present application are described in further detail below with reference to the accompanying drawings.

[0082] After development is complete, if a technician tests a microservice function that involves other related microservices, they must download and start the latest version of the microservice responsible for that other technician. This means that each functional test requires downloading the latest version of the microservice updated by other technicians. Sometimes, due to the large number of versions of other microservices, if the latest version is not started or an error occurs during startup, the corresponding microservice function may not be tested properly. This can lead to misjudgment of problems in the corresponding microservice development, resulting in ineffective debugging. This reduces testing efficiency, affects subsequent development, and delays the entire development process.

[0083] Based on this, the present application provides a front-end service proxy method, device, and electronic device for connecting to microservice development.

[0084] By acquiring the to-be-tested microservice and the corresponding to-be-tested project, the required associated microservice for testing is determined, and the required associated microservice is transmitted to the unified test environment. The to-be-tested microservice is matched to the corresponding service end through the proxy, and the unified test environment is started for the functional test of the to-be-tested microservice according to the middleware processing logic. Through the method provided in the application, when the to-be-tested microservice is tested, other associated microservices no longer need to be downloaded and started, and the memory is occupied. In addition, the problem of download error caused by too many versions of associated microservices is also avoided. Therefore, invalid debugging can be avoided, and the test efficiency is improved.

[0085] Figure 1 An application scenario provided in the application is shown in the figure. After the corresponding to-be-tested microservice is acquired, the required associated microservice for testing is determined according to the test project corresponding to the to-be-tested microservice, and after corresponding processing, the to-be-tested microservice is matched to the corresponding service end through the proxy, and the associated microservice is transmitted to the unified test environment in the service end. According to the middleware processing logic, the unified test environment is started for the functional test of the to-be-tested microservice.

[0086] The specific implementation can refer to the following embodiments.

[0087] Figure 2 A flowchart of a front-end service proxy method for docking microservice development provided in an embodiment of the application. The method of the embodiment can be applied to the server in the above scenario. As shown in the figure, the method comprises the following steps. Figure 2

[0088] S201, acquiring a to-be-tested microservice.

[0089] The to-be-tested microservice is any microservice developed by the corresponding service end.

[0090] S202, determining an associated microservice according to a to-be-tested project of the to-be-tested microservice.

[0091] The to-be-tested project of the to-be-tested microservice is the functional test of the to-be-tested microservice.

[0092] The associated microservice is other microservice involved in the functional test of the to-be-tested microservice. The other microservice here can be other to-be-tested microservice developed by the service end, or a microservice developed by other service end.

[0093] Specifically, the required associated microservice to be started is acquired according to the to-be-tested project of the to-be-tested microservice.

[0094] S203, transmitting the associated microservice to a unified test environment.

[0095] ​In this embodiment, the unified test environment refers to an environment that can receive all related microservices.

[0096] Specifically, after the associated microservices are determined in step S202 above, they are transmitted to the unified test environment.

[0097] In some implementations, all associated microservices are registered with a unified gateway. If an associated microservice is updated, it can be re-registered and then imported into the associated microservices. In this case, if there are associated microservices that are re-registered and imported into the unified gateway, the previous version will be automatically replaced.

[0098] S204: Match the microservice to be tested to the corresponding server through the proxy.

[0099] The proxy can proxy requests sent to different services to different backend services according to the configuration. In this embodiment, the main purpose is to connect the corresponding server to the microservice to be tested, thereby realizing the functional testing of the microservice to be tested.

[0100] S205: Based on the middleware processing logic, start the unified test environment to perform functional testing of the microservice to be tested.

[0101] The middleware processing logic in this application can be understood as identifying the microservice to be tested and the proxy, and reconstructing the address of the microservice to be tested so that the proxy can identify the address of the microservice to be tested and then perform corresponding matching and processing. Accordingly, if the microservice is identified as a related microservice, it is transferred to a unified test environment; if the microservice is identified as an unrelated microservice, it is directly intercepted. This realizes the function of using proxy to match and develop collaborative multi-services.

[0102] Specifically, after the middleware processing logic is used to match the microservice to be tested, the transmission is completed and a unified test environment for all related microservices is started to perform functional testing on the microservice to be tested.

[0103] This application obtains the microservice to be tested and the corresponding project to be tested, determines the associated microservices required for the test, and transfers the above-mentioned associated microservices to a unified test environment. The microservice to be tested is matched to the corresponding server through a proxy, and according to the middleware processing logic, the unified test environment after the transfer is started to perform functional testing of the microservice to be tested. Through the method provided by this application, when testing the microservice to be tested, other associated microservices no longer need to be downloaded and started, occupying memory. In addition, the problem of download errors caused by too many versions of associated microservices is avoided. This can avoid invalid debugging and improve test efficiency.

[0104] In some embodiments, the API address of the microservice to be tested can be identified and reconstructed so that the proxy can recognize it and then pass it to the corresponding server. Specifically, the above method may include: obtaining the API address corresponding to the microservice to be tested; based on the middleware processing logic, determining whether the server corresponding to the microservice to be tested exists in the proxy; if the server corresponding to the microservice to be tested exists in the proxy, reconstructing the API address to obtain a processed API address; and passing the microservice to be tested corresponding to the processed API address through the proxy to the corresponding server.

[0105] Specifically, the API address corresponding to the microservice under test is obtained, and the middleware processing logic is used to determine whether the server corresponding to the microservice under test exists in the proxy. If the server corresponding to the microservice under test exists in the proxy, the obtained API address corresponding to the microservice under test is reconstructed to obtain a processed API address, so that the microservice under test corresponding to the API address is proxied to the corresponding server.

[0106] The method provided in this implementation obtains the API address corresponding to the microservice under test and uses middleware processing logic to determine whether the corresponding server of the microservice under test exists in the proxy. If the server of the microservice under test exists in the proxy, the obtained API address of the microservice under test is reconstructed to obtain a processed API address, so that the microservice under test corresponding to the API address can be connected to the corresponding server through the proxy. By reconstructing the API address, the microservice under test can be identified and matched by the proxy, thereby improving matching accuracy.

[0107] In some embodiments, the API address can be reconstructed by identifying the proxy's address code. Specifically, the method may include: if the proxy contains a server corresponding to the microservice to be tested, identifying the address code in the proxy; and reconstructing the API address based on the address code so that the proxy can recognize and match the server.

[0108] Specifically, before reconstructing, first use regular expressions to configure the proxy to a matching pattern. Then, when reconstructing the API address, the middleware processing logic determines whether the proxy corresponds to the microservice under test. If so, the proxy's address code is identified based on the regular expression replacement rules. The API address is then reconstructed based on the proxy's address code so that the proxy can recognize it. After successful identification, the corresponding server is matched.

[0109] In this embodiment, when reconstructing the API address, the proxy first determines whether the server corresponding to the microservice to be tested exists. If so, the proxy's address code is identified and the API address is reconstructed based on the proxy's address code so that the proxy can recognize it. This method simplifies the matching process and improves recognition efficiency.

[0110] In some embodiments, the proxy can be configured using a configuration file and a server IP address. Specifically, the method may include: obtaining the configuration file and the server IP address; determining the microservice to be tested corresponding to the IP address; and configuring the proxy corresponding to the microservice to be tested based on the configuration file.

[0111] The configuration file contains the information required to configure the proxy, such as the basic properties of the proxy and the corresponding server information.

[0112] Specifically, when configuring a proxy, first obtain the configuration file and the server's IP address. Use the server's IP address to determine the microservice to be tested. After determining the microservice to be tested, use the configuration file to configure the proxy corresponding to the microservice to be tested.

[0113] Using the method provided in this embodiment, when configuring a proxy, the configuration file and the server's IP address are first obtained. The corresponding microservice to be tested is determined using the server's IP address. After determining the microservice to be tested, the proxy corresponding to the microservice to be tested is configured using the configuration file. This method allows all microservices to be tested on the server to be obtained and the corresponding proxy configuration to be performed. This prevents the omission of microservices to be tested due to human error, thereby improving work efficiency.

[0114] In some embodiments, if a proxy error occurs, an alarm is activated. Specifically, the above method may include: based on the middleware processing logic, if the associated microservice is proxied to the server in the proxy, an alarm is activated.

[0115] Specifically, due to network conditions or other human factors, although the above embodiments allow the microservices under test to be mapped one-to-one to the server and perform corresponding functional tests, it is possible that a related microservice or other unrelated microservice may be mistakenly proxied to the server. In this case, the functional test items of the microservice under test can be retrieved and matched with the proxied microservice to determine whether the current microservice is the corresponding microservice under test. If not, it is determined to be a related microservice or other unrelated microservice.

[0116] In some implementations, if the aforementioned proxy error occurs, a pop-up window may be displayed to indicate the proxy error. Alternatively, a voice announcement may be used to indicate the proxy error. Accordingly, other alarm methods may also be used to provide reminders, which will not be detailed here.

[0117] By using the method provided in this embodiment, when a proxy error occurs, an alarm is issued in time to avoid invalid debugging due to errors, thereby wasting time and delaying development progress.

[0118] Since the operation and maintenance team connects multiple microservices to a front-end project, the previous front-end framework can only proxy one server, that is, the service started locally by the developer. When a function involves multiple services, if the developer wants to fully test the function, he needs to start all related microservices locally. Even if it is not the microservice he is responsible for, he needs to download it to the local and start it, which is very troublesome. Figure 3 As shown, a front-end project is connected to a local service.

[0119] First, label each API address (prefix with microservice name), and then configure the webpack proxy.

[0120] Different microservices can be configured with different server-side proxies, and unconfigured services will be matched to a unified test environment.

[0121] Introducing HTTP request processing middleware (middleware processing logic), after the request is initiated, it first intercepts and identifies the API address, and reconstructs the request address so that the request address can be recognized by the webpack proxy (proxy). The reconstructed request address is identified and matched to the corresponding server through the webpack proxy.

[0122] like Figure 4 As shown, in this way, developers only need to configure webpack proxy to proxy the services they are interested in to the local machine. Other non-own services will be automatically proxied to the unified test environment instead of being proxied to the local machine.

[0123] In some embodiments, when the test of the microservice to be tested is performed, if a test failure occurs, the microservice to be tested can be analyzed to determine whether an error occurs in the microservice to be tested. If an error occurs, the error source is found according to the analysis result and is noted for adjusting the error. Specifically, the associated microservices can be transmitted to the unified test environment, and the microservice to be tested is tested by proxying to the corresponding server. Whether the test is successful is determined. If the test fails, all contents in the microservice to be tested are analyzed to determine whether an error exists in the microservice to be tested. If an error exists in the microservice to be tested, the error source is noted according to the analysis result for modification and adjustment.

[0124] Specifically, after the associated microservices are transmitted to the unified test environment and the microservice to be tested is proxied to the corresponding server, the test is formally started, and each item of the test project of the microservice to be tested is tested. If a test failure occurs, it is determined that the failure occurs when a specific item of the test project is tested. The microservice to be tested is analyzed according to the item, the error source is determined and is noted, and the test personnel can modify and adjust the microservice to be tested according to the note.

[0125] Specifically, the program content of the microservice to be tested can be analyzed to determine whether a code error exists, or the content corresponding to the microservice to be tested is analyzed according to the test project to determine whether a problem exists.

[0126] In a specific implementation, the error source obtained by analysis can be highlighted, or in the analysis process, the error source is directly jumped to, so that the test personnel can modify.

[0127] Through the manner provided in this embodiment, if a problem occurs in the test process, the error source can be analyzed and found in time. If it is determined that the problem is caused by the microservice to be tested, the error source can be found more quickly according to the manner provided in this embodiment, and the work efficiency is improved.

[0128] In some embodiments, if the microservices to be tested are all normal, the associated microservices in the unified test environment are analyzed, the abnormal associated microservices are determined and kicked out of the unified test environment. After the abnormal associated microservice is updated, it is re-acquired and the updated version is scanned to determine whether there is an abnormality. If there is no abnormality, the unified test environment can be entered normally to continue testing. Specifically, it can include: if it is determined through analysis that there is no error in the microservice to be tested, the associated microservices are analyzed, the abnormal associated microservices are determined and the abnormal associated microservices are kicked out of the unified test environment; the updated version of the abnormal associated microservice is obtained; the updated version is scanned to determine whether the updated version has an abnormality; if the updated version does not have an abnormality, the updated version is allowed to be transmitted to the unified test environment for testing of the microservice to be tested.

[0129] Specifically, when testing the project to be tested, there may be problems with abnormalities in the associated microservices. At this time, if it is determined through the analysis of the above embodiment that there is no error in the microservice to be tested, the associated microservices in the unified test environment can be analyzed. Specifically, it can be analyzed whether the code of the associated microservice is correct, or whether the functions of the associated microservices correspond, etc. According to the analysis results, the associated microservice with abnormalities is determined and kicked out of the unified test environment to avoid the test personnel forgetting this abnormal associated microservice and causing the test to still fail, wasting time. After the abnormal associated microservice is updated, the updated version can be obtained again, and before entering the unified test environment, the updated version can be scanned to determine whether the previous problem has been resolved. If it has been resolved, the updated associated microservice can be allowed to enter the unified test environment for subsequent testing.

[0130] Through the approach provided by this embodiment, if a test failure is caused by an issue with an associated microservice, the abnormal associated microservice can be kicked out of the unified test environment, updated, and then retrieved and scanned. If it is determined that there are no issues, the unified test environment can be re-entered for subsequent testing. This approach allows for timely resolution of issues with associated microservices and avoids the problem of test failures due to the tester forgetting to obtain the updated version. At the same time, after the abnormal associated microservice is determined, it can be updated in a timely manner, improving work efficiency, avoiding wasted work, and significantly shortening the debugging cycle.

[0131] Figure 5 A schematic diagram of the structure of a front-end service proxy device for docking microservice development provided in an embodiment of the present application is shown as follows: Figure 5As shown, the front-end service proxy device 500 for docking micro-service development in the embodiment comprises: a to-be-tested micro-service acquisition module 501, an associated micro-service determination module 502, an associated micro-service transmission module 503, a to-be-tested micro-service matching module 504, and a function test module 505.

[0132] The to-be-tested micro-service acquisition module 501 is configured to acquire a to-be-tested micro-service.

[0133] The associated micro-service determination module 502 is configured to determine an associated micro-service according to a test item of the to-be-tested micro-service.

[0134] The associated micro-service transmission module 503 is configured to transmit the associated micro-service to a unified test environment.

[0135] The to-be-tested micro-service matching module 504 is configured to match the to-be-tested micro-service to a corresponding service end through a proxy.

[0136] The function test module 505 is configured to start the unified test environment to perform function test on the to-be-tested micro-service based on a middleware processing logic.

[0137] Optionally, when the to-be-tested micro-service matching module 504 matches the to-be-tested micro-service to the corresponding service end through the proxy, the to-be-tested micro-service matching module 504 is specifically configured to:

[0138] acquire an api address corresponding to the to-be-tested micro-service;

[0139] determine whether the proxy contains the service end corresponding to the to-be-tested micro-service based on the middleware processing logic;

[0140] if the proxy contains the service end corresponding to the to-be-tested micro-service, reconstruct the api address to obtain a processed api address;

[0141] match the to-be-tested micro-service corresponding to the processed api address to the corresponding service end through the proxy.

[0142] Optionally, when the to-be-tested micro-service matching module 504 matches the to-be-tested micro-service to the corresponding service end through the proxy, the to-be-tested micro-service matching module 504 is specifically configured to:

[0143] if the proxy contains the service end corresponding to the to-be-tested micro-service, identify address coding in the proxy;

[0144] reconstruct the api address according to the address coding to enable the proxy to identify and match the service end.

[0145] Optionally, the front-end service proxy device 500 for connecting to microservice development further includes a proxy configuration module 506 for:

[0146] Get the configuration file and server IP address;

[0147] Determine the microservice to be tested corresponding to the IP address;

[0148] Based on the configuration file, configure the proxy corresponding to the microservice to be tested.

[0149] Optionally, the front-end service agent device 500 for connecting to microservice development further includes an alarm reminder module 507 for:

[0150] Based on the middleware processing logic, if the associated microservice is proxied to the server in the proxy, an alarm reminder is activated.

[0151] Optionally, the front-end service agent device 500 for connecting to microservice development further includes an error analysis module 508 for:

[0152] After the associated microservices are transferred to a unified test environment and the microservice to be tested is transmitted to the corresponding server through the proxy, the microservice to be tested is tested and whether the test is successful is determined;

[0153] If the test fails, analyze all the content in the microservice to be tested to determine whether there are any errors in the microservice to be tested;

[0154] If there is an error in the microservice to be tested, the source of the error will be noted based on the analysis results for modification and adjustment.

[0155] Optionally, the error analysis module 508 is specifically configured to:

[0156] If it is determined through analysis that there is no error in the microservice to be tested, the related microservices are analyzed to determine abnormal related microservices and kick the abnormal related microservices out of the unified test environment;

[0157] Obtain the updated version of the exception-related microservice;

[0158] Scan the updated version to determine whether there is any anomaly in the updated version;

[0159] If there is no abnormality in the updated version, the updated version is allowed to be transmitted to the unified test environment to test the microservice to be tested.

[0160] The device of this embodiment can be used to execute the method of any of the above embodiments. Its implementation principles and technical effects are similar and will not be described in detail here.

[0161] Figure 6 A schematic diagram of the structure of an electronic device provided in one embodiment of the present application is shown in FIG. Figure 6 As shown, the electronic device 600 of this embodiment may include: a memory 601 and a processor 602.

[0162] The memory 601 stores a computer program that can be loaded by the processor 602 and execute the method in the above embodiment.

[0163] The processor 602 and the memory 601 are connected, for example, via a bus.

[0164] Optionally, the electronic device 600 may further include a transceiver. It should be noted that in actual applications, the number of transceivers is not limited to one, and the structure of the electronic device 600 does not constitute a limitation on the embodiments of the present application.

[0165] Processor 602 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the present disclosure. Processor 602 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, or a combination of a DSP and a microprocessor.

[0166] A bus includes a path that transmits information between the components mentioned above. Examples include a PCI (Peripheral Component Interconnect) bus and an EISA (Extended Industry Standard Architecture) bus. Buses can be categorized as address buses, data buses, and control buses. For ease of illustration, the diagram uses a single thick line, but this does not imply a single bus or type of bus.

[0167] The memory 601 may be a ROM (Read Only Memory) or other type of static storage device that can store static information and instructions, a RAM (Random Access Memory) or other type of dynamic storage device that can store information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory) or other optical disk storage, optical disk storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto.

[0168] The memory 601 is used to store application code for executing the solution of the present application, and the execution is controlled by the processor 602. The processor 602 is used to execute the application code stored in the memory 601 to implement the content shown in the above method embodiment.

[0169] Electronic devices include, but are not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. They may also include servers, etc. Figure 6 The electronic device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0170] The electronic device of this embodiment can be used to execute the method of any of the above embodiments. Its implementation principles and technical effects are similar and will not be described in detail here.

[0171] The present application also provides a computer-readable storage medium storing a computer program that can be loaded by a processor and execute the method in the above embodiment.

[0172] Those skilled in the art will appreciate that all or part of the steps in the above-described method embodiments can be implemented using hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

Claims

1. A front-end service proxy method for connecting to microservice development, characterized in that: include: Get the microservice to be tested; Determine the associated microservices based on the items to be tested of the microservices to be tested; Transmitting the associated microservices to a unified test environment; Match the microservice to be tested to the corresponding server through proxy; Based on the middleware processing logic, start the unified test environment to perform functional testing of the microservice to be tested; After the associated microservices are transferred to a unified test environment and the microservice to be tested is matched to the corresponding server through a proxy, the microservice to be tested is tested and whether the test is successful is determined; If the test fails, analyze all the content in the microservice to be tested to determine whether there are any errors in the microservice to be tested; If there is an error in the microservice to be tested, the source of the error will be noted based on the analysis results for modification and adjustment; If it is determined through analysis that there is no error in the microservice to be tested, the related microservices are analyzed to determine abnormal related microservices and kick the abnormal related microservices out of the unified test environment; Obtain the updated version of the exception-related microservice; Scan the updated version to determine whether there is any anomaly in the updated version; If there is no abnormality in the updated version, the updated version is allowed to be transmitted to the unified test environment to test the microservice to be tested.

2. The method according to claim 1, characterized in that The step of matching the microservice to be tested to the corresponding server through a proxy includes: Get the API address corresponding to the microservice to be tested; Based on the middleware processing logic, determine whether the proxy contains a server corresponding to the microservice to be tested. If the proxy contains a server corresponding to the microservice to be tested, the API address is reconstructed to obtain a processed API address; The microservice to be tested corresponding to the processed API address is sent to the corresponding server through the proxy.

3. The method according to claim 2, characterized in that If the proxy contains a server corresponding to the microservice to be tested, the API address is reconstructed to obtain a processed API address including: If the server corresponding to the microservice to be tested exists in the proxy, identify the address code in the proxy; According to the address code, the API address is reconstructed so that the proxy can recognize and match the server.

4. The method according to claim 1, wherein Also includes: Get the configuration file and server IP address; Determine the microservice to be tested corresponding to the IP address; Based on the configuration file, configure the proxy corresponding to the microservice to be tested.

5. The method according to claim 1, wherein Also includes: Based on the middleware processing logic, if the associated microservice is proxied to the server in the proxy, an alarm reminder is activated.

6. A front-end service proxy device for connecting to microservice development, characterized in that: include: The microservice acquisition module to be tested is used to obtain the microservice to be tested; The associated microservice determination module determines the associated microservices based on the items to be tested of the microservices to be tested; An associated microservice transmission module, used to transmit the associated microservices to a unified test environment; The microservice matching module to be tested is used to match the microservice to be tested to the corresponding server through a proxy; A functional testing module is used to start the unified testing environment to perform functional testing of the microservice to be tested based on the middleware processing logic; An error analysis module is used to transmit the associated microservices to a unified test environment and, after the microservice to be tested is matched to the corresponding server through a proxy, test the microservice to be tested and determine whether the test is successful; If the test fails, analyze all the content in the microservice to be tested to determine whether there are any errors in the microservice to be tested; If there is an error in the microservice to be tested, the source of the error will be noted based on the analysis results for modification and adjustment; If it is determined through analysis that there is no error in the microservice to be tested, the related microservices are analyzed to determine abnormal related microservices and kick the abnormal related microservices out of the unified test environment; Obtain the updated version of the exception-related microservice; Scan the updated version to determine whether there is any anomaly in the updated version; If there is no abnormality in the updated version, the updated version is allowed to be transmitted to the unified test environment to test the microservice to be tested.

7. An electronic device, characterized in that: include: memory and processor; The memory is used to store program instructions; The processor is configured to call and execute program instructions in the memory to perform the method according to any one of claims 1 to 5.

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

Images