Micro-service debugging method, device and system and storage medium

Abstract

The invention discloses a micro-service debugging method, device and system and a storage medium, and relates to the technical field of software development. The method comprises the following steps: starting a local to-be-debugged business service, deploying a server-side service front end, and configuring a mapping relationship between a source and a debugging service; accessing and triggering a request through a browser, and intelligently routing the request according to debugging configuration and a local gateway state; if the request needs to be debugged and the local gateway is started, local debugging is carried out; otherwise, forwarding to the server; in addition, the configuration registration center facilitates service discovery and debugging configuration acquisition. According to the method, the debugging period is shortened, the efficiency is improved, the debugging continuity is ensured, and flexible debugging environment selection is provided; meanwhile, server resource occupation is reduced through local debugging, service processing is intelligently selected, effective utilization of resources is ensured, and resource waste is avoided.

Description

Technical Field

[0001] This application belongs to the technical field of software development, and particularly relates to a microservice debugging method, device, system and storage medium. Background Art

[0002] Microservices have now become the architecture mode selected for most software development. Under this architecture mode, the original single service is split into multiple services according to the business for independent deployment. Since multiple services need to be deployed on the server, the requirements for the server are relatively high, and it is difficult for the development computers of general software engineers to meet the requirements of driving all services. Therefore, when developing under the microservice architecture mode, a server with a relatively high configuration is generally provided as the development server, and all microservices are uniformly deployed on the development server. Developers can connect to the development server through their own computers for function development and problem investigation.

[0003] In the context of all developers sharing a single server, there will be problems of multi-person debugging conflicts. For example, there is currently a microservice architecture with two independent services deployed on the server, one belonging to the basic service and the other belonging to the personnel management service (providing management of both personnel and organizations). At this time, programmer A and programmer B need to investigate problems. A investigates problems related to personnel management, B investigates problems related to organizations, and both need to use the basic service at the same time. Under the traditional microservice architecture, after A finishes the investigation, the resources can be released for B to investigate, or A builds a complete environment on his own computer and conducts problem investigation on his own development computer. It is impossible for A and B to use the server to investigate problems simultaneously.

[0004] Under the microservices architecture, each developer sets up a complete microservices environment on their own development computer, deploying basic services, the required business services, and the services supported by microservices (a relatively large number of services are deployed) (generally, business services can only be deployed based on basic services), without relying on a server or other developers. However, sufficient computer resources are required to drive the operation of multiple services and development tools, putting a great deal of pressure on the computer. And during the debugging process, the front-end needs to be started on the development computer to trigger the program; for remote development servers, connect to the development server for debugging, without the need to set up an environment locally. However, once the server is occupied, it is exclusive to the server, and other developers or testers cannot use the services on the server normally, which will affect the team's efficiency; start the business service and front-end to be debugged on the developer's computer, connect to the basic service on the server, and conduct debugging. However, there is a potential problem. In some special scenarios where the basic service needs to call back the business service, since the basic service on the server is connected to the business service on the server, the service started locally by the developer cannot be called in such scenarios, and the debugging effect cannot be achieved. Summary of the Invention

[0005] The purpose of this application is to provide a microservices debugging method, device, system, and storage medium, which intelligently select the local or server gateway service to process requests and detect the debugging configuration of the business service to be debugged, improving the debugging efficiency and system stability.

[0006] To achieve the above objective, the solution of this application is:

[0007] In a first aspect, an embodiment of this application provides a microservices debugging method, including:

[0008] Start the business service to be debugged locally;

[0009] Deploy the service front-end, and the service front-end is deployed on the server;

[0010] Configure the mapping relationship between the source service and the debugging service to obtain the debugging configuration;

[0011] Access the business service to be debugged through a browser and trigger the execution of a request;

[0012] Determine whether there is a debugging configuration for the execution request. If not, access the server gateway, and forward the execution request to the business service to be debugged locally through the service front-end; if so, determine whether the local gateway is started. If not, report an error and end;

[0013] If started, access the local gateway and view the debugging configuration. If the execution request is to access the gateway, conduct debugging at the local gateway;

[0014] If the execution request is to access a business service, and there is a debugging configuration for the business service and the local service is started, the execution request is forwarded to the business service to be debugged locally through the service front-end;

[0015] If the execution request is to access a business service, and there is no debugging configuration for the business service or there is a debugging configuration for the business service but the local service is not started, the execution request is forwarded to the corresponding service on the server.

[0016] According to the above method of the embodiment of the present application, the following additional technical features may also be included:

[0017] Further, a registration center is configured to obtain the business service to be debugged through the registration center, and determine whether there is a debugging configuration for the execution request. If there is, the business service to be debugged is processed locally; if not, the business service to be debugged is processed on the server.

[0018] In a second aspect, an embodiment of the present application provides a microservice debugging device, including:

[0019] A local startup module configured to start the business service to be debugged locally;

[0020] A front-end deployment module configured to deploy a service front-end, and the service front-end is deployed on the server;

[0021] A debugging configuration module configured to configure the mapping relationship between the source service and the debugging service to obtain a debugging configuration;

[0022] An access request module configured to access the business service to be debugged through a browser and trigger an execution request;

[0023] A debugging processing module configured to determine whether there is a debugging configuration for the execution request. If not, access the server gateway, and forward the execution request to the business service to be debugged locally through the service front-end; if there is, determine whether the local gateway is started. If it is not started, report an error and end;

[0024] If it is started, access the local gateway and view the debugging configuration. If the execution request is to access the gateway, perform debugging on the local gateway;

[0025] If the execution request is to access a business service, and there is a debugging configuration for the business service and the local service is started, the execution request is forwarded to the business service to be debugged locally through the service front-end;

[0026] If the execution request is to access a business service, and there is no debugging configuration for the business service or there is a debugging configuration for the business service but the local service is not started, the execution request is forwarded to the corresponding service on the server.

[0027] The above-mentioned device according to the embodiment of the present application may further have the following additional technical features:

[0028] A registration center module, configured to configure a registration center, obtain a service to be debugged through the registration center, and determine whether there is a debugging configuration for an execution request. If there is, process the service to be debugged locally; if not, process the service to be debugged on the server.

[0029] In a third aspect, an embodiment of the present application provides a microservice debugging system, which includes a processor and a memory. A computer program is stored in the memory and is loaded and executed by the processor to implement the microservice debugging method provided in the first aspect of the embodiment of the present application.

[0030] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium. A computer program is stored in the storage medium and, when executed by a processor, is used to implement the microservice debugging method provided in the first aspect of the embodiment of the present application.

[0031] Adopting the microservice debugging method provided in the embodiment of the present application, compared with the prior art, it has the following beneficial technical effects:

[0032] In the embodiment of the present application, by starting the service to be debugged locally, developers can iterate and test code faster without having to deploy to a remote server every time, shortening the debugging cycle and improving development efficiency; the intelligent routing selection (based on the startup status of the gateway service) between the local and the server ensures that requests can be correctly routed to the server for processing even when the local environment is unavailable, thus ensuring the continuity of debugging.

[0033] In the embodiment of the present application, by configuring the mapping relationship between the source service and the debugging service, developers can flexibly specify which services are debugged locally and which services run on the server. This flexibility allows developers to choose the most suitable debugging environment according to their needs.

[0034] In the embodiment of the present application, through the configuration of the registration center, service discovery and obtaining of debugging configurations are made more convenient, further enhancing the flexibility of debugging. Debugging locally can reduce the occupation of server resources, especially in the initial stage of development or when the code is frequently modified. This resource optimization is particularly important; by intelligently selecting services to be processed locally or on the server, the effective utilization of resources can be ensured and unnecessary resource waste can be avoided. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 Shows a schematic flow diagram of the microservice debugging method according to the embodiment of the present application;

[0036] Figure 2 The flowchart of the microservice debugging method according to another embodiment of the present application is shown;

[0037] Figure 3 The structural block diagram of the microservice debugging device according to the embodiment of the present application is shown;

[0038] Figure 4 The structural block diagram of the microservice debugging device according to another embodiment of the present application is shown;

[0039] Figure 5 The structural block diagram of the computer device according to the embodiment of the present application is shown. Detailed implementation manners

[0040] To make the above objects, features and advantages of the present application more obvious and understandable, the following will describe the detailed implementation manners of the present application in conjunction with the accompanying drawings. It can be understood that the specific embodiments described herein are only used to explain the present application, rather than limiting the present application. Additionally, it should be noted that for the sake of convenience of description, only the parts related to the present application are shown in the drawings instead of all the structures. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present application.

[0041] The terms "including" and "having" and any variations thereof in the present application are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or units inherent to these processes, methods, products or devices.

[0042] Referring to "embodiment" in the present application means that the specific features, structures or characteristics described in combination with the embodiment can be included in at least one embodiment of the present application. The appearance of this phrase at various positions in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art explicitly and implicitly understand that the embodiments described in the present application can be combined with other embodiments.

[0043] As Figure 1 shown, the embodiment of the present application provides a microservice debugging method, including the following steps:

[0044] Step 101, start the business service to be debugged locally.

[0045] Starting the business service to be debugged locally can provide a relatively isolated development and debugging environment, avoiding interference with other services or the production environment. Developers can quickly start, stop, and restart the service locally to facilitate rapid code modification and testing, accelerating the development process. In the local environment, developers can more easily set breakpoints, view logs, monitor performance, etc., thus more effectively locating and solving problems.

[0046] Ensure that the necessary development tools and dependency libraries are installed on the local machine, such as an IDE (Integrated Development Environment), database client, message queue client, etc. Check out the source code of the business to be debugged from the version control system (such as Git). Configure the necessary configuration files according to the service's requirements, such as database connection information, message queue address, API gateway address, etc. Start the service in the IDE or through the command-line tool. This usually involves running a startup script or command that loads the service configuration, initializes the necessary resources, and then starts the service process.

[0047] Step 102, deploy the service front-end, and the service front-end is deployed on the server.

[0048] As a bridge between users and back-end services, the service front-end is responsible for receiving user requests and forwarding them to the corresponding back-end services for processing. Deploying the service front-end on the server can ensure that users can access these front-end interfaces and functions through the network.

[0049] The deployment of the service front-end usually involves uploading the front-end code (such as HTML, CSS, JavaScript, etc.) to the server and configuring and publishing it through a web server (such as Nginx, Apache, etc.). In this way, when a user accesses a specific URL through a browser, the web server will send the front-end code to the user's browser for rendering and display.

[0050] Depending on the business requirements and technology stack, different types of servers can be selected for deployment. For example, for web-based applications, they can be hosted in virtual machines or containers provided by cloud service providers (such as AWS, Azure, Alibaba Cloud, etc.). The deployment methods can include manual deployment, automated deployment (such as using a CI / CD toolchain), etc. Automated deployment can greatly improve the deployment efficiency and reduce human errors.

[0051] When deploying the service front-end, security issues need to be considered, such as using the HTTPS protocol, configuring firewall rules, conducting code audits, etc., to ensure the security and stability of the front-end service.

[0052] In the microservice debugging method, through the service front-end, developers can simulate the actual access scenarios of users, trigger the execution of requests, and observe the responses and processing results of the back-end services. At the same time, the service front-end can also serve as a display interface for debugging information to help developers more intuitively understand the problems and solutions during the debugging process.

[0053] Step 103, configure the mapping relationship between the source service and the debugging service to obtain the debugging configuration.

[0054] The source service refers to the business service to be debugged, which may be any microservice in the system. The debugging service refers to a specific service used to receive debugging requests and perform debugging processing on the source service. The establishment of the mapping relationship is usually completed in the configuration file. The mapping relationship needs to clearly specify the identifier of the source service (such as service name, version number, etc.) and the address of the debugging service (such as IP address, port number, etc.). Through this mapping relationship, when a debugging request arrives, the system can accurately identify which debugging service the request should be routed to.

[0055] The debugging configuration is usually stored in the configuration file in the form of key-value pairs. These configuration files may be in formats such as JSON, YAML, XML, etc. In the configuration file, various debugging parameters can be specified, such as log level, breakpoint settings, data simulation, etc.

[0056] In some microservice architectures, the service registry (such as Eureka, Consul, etc.) is not only used for service registration and discovery but also for storing and obtaining debugging configurations. Through the registry, the debugging configuration can be dynamically obtained and updated without modifying the code or configuration file of the service itself.

[0057] If there is a debugging configuration for the business service to be debugged and the local gateway service has been started, then the debugging request will be routed to the local debugging service for processing. During local debugging, it is convenient to view and modify the internal state of the service, perform breakpoint debugging, log analysis, etc.

[0058] If the local gateway service is not started or there is no debugging configuration for the business service to be debugged, then the debugging request will be routed to the gateway service of the server and processed by the debugging service on the server. Remote debugging is usually used for debugging outside the development environment, such as test environments, production environments, etc. During remote debugging, it is necessary to ensure the stability and security of the network connection.

[0059] When configuring mapping relationships and debugging configurations, security issues need to be noted. Avoid exposing sensitive information to unauthorized users or systems. The mapping relationships and debugging configurations should have a certain degree of flexibility so that they can be quickly modified and adjusted when needed. During the debugging process, sufficient monitoring and logging functions should be enabled so that problems can be located and investigated in a timely manner when they occur. By reasonably configuring mapping relationships and debugging parameters, the efficiency and accuracy of debugging can be greatly improved.

[0060] Step 104, access the business service to be debugged through a browser and trigger an execution request.

[0061] In a microservices architecture, business services are usually deployed on different servers or run as containerized applications in a cloud environment. To debug these services, first, they need to be accessible in some way. As a common user interface tool, a browser can be used to access web services. When the business service to be debugged provides HTTP or HTTPS interfaces, the service can be accessed by entering the corresponding URL in the browser.

[0062] Once the business service to be debugged is accessed, the next step is to trigger an execution request. This request can be an HTTP method such as GET, POST, PUT, DELETE, etc., depending on the API design of the business service. The purpose of triggering the request is to let the business service perform specific operations or return specific data in order to observe its behavior and response.

[0063] By accessing through a browser and triggering an execution request, it can be verified whether the functions of the business service work as expected. For example, it can be checked whether the data returned by the API conforms to the expected format and content.

[0064] If problems occur when the business service executes the request (such as returning error codes, throwing exceptions, etc.), the problems can be located by observing the browser's response. In addition, means such as log analysis and breakpoint debugging can be combined to further diagnose the problems. By simulating a large number of concurrent requests, the performance of the business service can be evaluated, which helps to discover potential bottlenecks and optimization points.

[0065] For business services that provide web interfaces, accessing through a browser can directly simulate the operation behavior of users, thereby evaluating whether the user experience meets expectations.

[0066] When accessing and debugging business services, it is necessary to ensure that sensitive information (such as passwords, keys, etc.) is not exposed. At the same time, it is also necessary to avoid causing unnecessary impacts on the production environment. To avoid interfering with the production environment during the debugging process, it is recommended to perform debugging in an independent test environment. This can be achieved by configuring different resources such as databases, message queues, etc. During the debugging process, the detailed logging function can also be enabled to quickly locate and solve problems when they occur.

[0067] In summary, accessing the business service to be debugged through a browser and triggering an execution request helps to verify functions, debug problems, perform performance tests, and user experience tests. When performing this step, attention needs to be paid to issues such as security, environment isolation, and logging.

[0068] Step 105, determine whether there is a debugging configuration for the execution request. If not, access the server gateway and forward the execution request to the business service to be debugged locally through the service front-end; if so, determine whether the local gateway is started. If not, report an error and end;

[0069] If it is started, access the local gateway and view the debugging configuration. If the execution request is to access the gateway, perform debugging at the local gateway;

[0070] If the execution request is to access the business service, and there is a debugging configuration for the business service and the local service is started, forward the execution request to the business service to be debugged locally through the service front-end;

[0071] If the execution request is to access the business service, and there is no debugging configuration for the business service or there is a debugging configuration for the business service but the local service is not started, forward the execution request to the corresponding service on the server.

[0072] Step 105 describes how to determine how to handle the request based on whether there is a debugging configuration for the execution request and the status of the local gateway.

[0073] Specifically, when an execution request arrives, first check whether there is a corresponding debugging configuration for this request. The debugging configuration is usually set by developers before the start of debugging to specify which requests need to be debugged locally and which requests can be normally processed by the server.

[0074] If the execution request does not have a corresponding debugging configuration, it is considered a normal business request. At this time, the request will pass through the server gateway, and the service front-end will forward it to the business service to be debugged locally. Here, "local" refers to the local development environment of the developer.

[0075] In this case, the request processing flow is similar to the online environment, but the service instance runs in the local environment.

[0076] If there is a corresponding debugging configuration for the execution request, further check whether the local gateway has been started. If the local gateway has not been started, local debugging cannot be performed, so an error will be reported and the debugging process will end. If the local gateway has been started, the local gateway will be accessed and the request will be processed according to the debugging configuration.

[0077] If the execution request is to access the gateway, debugging will be performed on the local gateway. This means that developers can debug and verify the logic of the gateway in the local environment.

[0078] If the request is to access a business service, and the business service has a debugging configuration and the local service has been started, the request will be forwarded to the business service to be debugged locally through the service front end.

[0079] If the request is to access a business service, but the business service does not have a debugging configuration or although it has a debugging configuration but the local service has not been started, the request will be forwarded to the corresponding service on the server. This ensures that business requests can be processed normally even if the local debugging environment is unavailable.

[0080] It should be noted that when performing debugging configuration, the debugging configuration should be flexible enough to support debugging requirements in different scenarios. For example, specific URL paths, request methods, request parameters, etc. can be configured as debugging conditions.

[0081] The local gateway not only provides the function of request forwarding in microservice debugging, but also allows developers to debug and verify the gateway logic in the local environment. During the debugging process, error handling and logging mechanisms can also be added to help developers quickly locate the problem and fix it.

[0082] Although the local debugging environment provides great flexibility, after debugging is completed, sufficient performance testing should be carried out to ensure the stability and performance of the service in the online environment.

[0083] As Figure 2 shown, the embodiments of the present application further include:

[0084] Step 106, configure the registry, obtain the business service to be debugged through the registry, and determine whether there is a debugging configuration for the execution request. If there is, process the business service to be debugged locally; if not, process the business service to be debugged on the server.

[0085] First, an embodiment of the present application needs to configure a registration center in the microservice architecture. The registration center is a key component in the microservice architecture, which is responsible for service registration and discovery. During the debugging process, developers need to register the business service to be debugged with the registration center so that other services or components can find and communicate with it.

[0086] Through the registration center, detailed information about the business service to be debugged can be obtained, including the service name, address, port, etc. This information is the basis for subsequent request routing and debugging. After obtaining the service information, it is necessary to determine whether there is a debugging configuration for the service. The debugging configuration usually includes some specific parameters or flags, which are used to indicate whether the service is in the debugging mode and how to perform debugging. These configurations can be managed and distributed through the registration center or other configuration management tools.

[0087] According to the judgment result, if there is a debugging configuration for the business service to be debugged, the local debugging process is executed; if not, it is processed by the server. Local debugging usually means running the service in the developer's local environment and debugging and testing it. Server processing means that the service runs on a remote server and communicates and interacts through the network.

[0088] By obtaining the information of the business service to be debugged through the registration center and judging whether there is a debugging configuration, the debugging environment and debugging method can be quickly determined. This helps developers quickly enter the debugging state and improve the debugging efficiency. According to the existence or non-existence of the debugging configuration, local debugging or server processing can be flexibly selected. This flexibility enables developers to choose a suitable debugging method according to the actual situation and requirements, so as to better meet the debugging needs. Debugging locally can reduce the occupation of server resources, especially in the initial stage of development or when the code is frequently modified. This helps to optimize resource utilization and reduce operating costs. Through the registration center for service registration and discovery, as well as the sharing and management of debugging configurations, it can promote collaboration and communication among team members. This helps team members to jointly solve problems and improve the overall development efficiency and quality.

[0089] In summary, step 106 provides an efficient, flexible, and optimized debugging method for developers by configuring the registration center and judging whether there is a debugging configuration for the execution request. These beneficial technical effects help to improve the efficiency and quality of microservice development and promote team collaboration and communication.

[0090] As Figure 3 shown, an embodiment of the present application provides a microservice debugging device, including a local startup module 201, a front-end deployment module 202, a debugging configuration module 203, an access request module 204, and a debugging processing module 205, where:

[0091] The local startup module 201 is configured to start the business service to be debugged locally;

[0092] The front-end deployment module 202 is configured to deploy the service front-end, and the service front-end is deployed on the server;

[0093] The debugging configuration module 203 is configured to configure the mapping relationship between the source service and the debugging service to obtain the debugging configuration;

[0094] The access request module 204 is configured to access the business service to be debugged through the browser and trigger the execution request;

[0095] The debugging processing module 205 is configured to determine whether there is a debugging configuration for the execution request. If not, it accesses the server gateway and forwards the execution request to the business service to be debugged locally through the service front-end; if so, it determines whether the local gateway is started. If not, it reports an error and ends;

[0096] If started, it accesses the local gateway and views the debugging configuration. If the execution request is to access the gateway, it debugs at the local gateway;

[0097] If the execution request is to access the business service, and there is a debugging configuration for the business service and the local service is started, it forwards the execution request to the business service to be debugged locally through the service front-end;

[0098] If the execution request is to access the business service, and there is no debugging configuration for the business service or there is a debugging configuration for the business service but the local service is not started, it forwards the execution request to the corresponding service on the server.

[0099] As Figure 4 shown, the device of the embodiment of the present application further includes:

[0100] The registration center module 206 is configured to configure the registration center, obtain the business service to be debugged through the registration center, and determine whether there is a debugging configuration for the execution request. If so, it processes the business service to be debugged locally; if not, it processes the business service to be debugged on the server.

[0101] The microservice debugging device provided by the embodiment of the present application can implement Figure 1 and Figure 2 each process implemented by the microservice debugging method embodiment. To avoid repetition, it will not be elaborated here.

[0102] The embodiment of the present application further provides a computer device, as Figure 5As shown in the figure, the computer device includes a processor 301 and a memory 302. A program or instruction that can run on the processor 301 is stored on the memory 302. When the program or instruction is executed by the processor 301, each step of the above-mentioned microservice debugging method is implemented, and the same technical effect can be achieved. To avoid repetition, it will not be elaborated here.

[0103] The embodiment of the present application also provides a readable storage medium. A program or instruction is stored on the readable storage medium. When the program or instruction is executed by the processor, each process of the embodiment of the above-mentioned microservice debugging method is implemented, and the same technical effect can be achieved. To avoid repetition, it will not be elaborated here.

[0104] It should be noted that in the present application, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of another identical element in the process, method, article or device including that element. In addition, it should be pointed out that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in a reverse order according to the functions involved. For example, the described method may be executed in an order different from that described, and various steps may be added, omitted, or combined. Additionally, the features described with reference to certain examples may be combined in other examples.

[0105] The embodiments of the present application have been described above in conjunction with the accompanying drawings. However, the present application is not limited to the above specific embodiments. The above specific embodiments are merely illustrative and not restrictive. Under the inspiration of the present application, those of ordinary skill in the art can also make many forms without departing from the purpose of the present application and the scope protected by the claims, and all of them belong to the protection scope of the present application.

Claims

1. A microservice debugging method, characterized in that: The method comprises: Start the local business service to be debugged; Deploy a service front end, wherein the service front end is deployed on a server; Configure the mapping relationship between the source service and the debugging service to obtain the debugging configuration; Access the business service to be debugged through a browser and trigger an execution request; Determine whether there is a debugging configuration for the execution request. If not, access the server gateway and forward the execution request to the local business service to be debugged through the service front end. If it exists, determine whether the local gateway is started. If not, report an error and end. If started, access the local gateway and check the debugging configuration. If the execution request is to access the gateway, debug on the local gateway; If the execution request is to access a business service, and there is a debugging configuration for the business service and a local service startup, forwarding the execution request to the local business service to be debugged through the service front end; If the execution request is to access a business service, and there is no debugging configuration for the business service or there is a debugging configuration for the business service but the local service is not started, the execution request is forwarded to the corresponding service of the server.

2. The microservice debugging method according to claim 1, characterized in that: The method comprises: A configuration registration center is configured, and the business service to be debugged is obtained through the registration center, and it is determined whether the execution request has a debugging configuration. If so, the business service to be debugged is processed locally; if not, the business service to be debugged is processed on the server.

3. A microservice debugging device, characterized in that: The device comprises: A local startup module is configured to start a local business service to be debugged; A front-end deployment module is configured to deploy a service front end, wherein the service front end is deployed on a server; A debugging configuration module is configured to configure a mapping relationship between a source service and a debugging service to obtain a debugging configuration; An access request module, configured to access the business service to be debugged through a browser and trigger an execution request; The debugging processing module is configured to determine whether there is a debugging configuration for the execution request. If not, access the server gateway and forward the execution request to the local business service to be debugged through the service front end; if it exists, determine whether the local gateway is started, and if not, report an error and end; If started, access the local gateway and check the debugging configuration. If the execution request is to access the gateway, debug on the local gateway; If the execution request is to access a business service, and there is a debugging configuration for the business service and a local service startup, forwarding the execution request to the local business service to be debugged through the service front end; If the execution request is to access a business service, and there is no debugging configuration for the business service or there is a debugging configuration for the business service but the local service is not started, the execution request is forwarded to the corresponding service of the server.

4. The microservice debugging device according to claim 3, characterized in that: The device comprises: The registration center module is configured to configure the registration center, obtain the business service to be debugged through the registration center, and determine whether the execution request has a debugging configuration. If so, the business service to be debugged is processed locally; if not, the business service to be debugged is processed on the server.

5. A microservice debugging system, the system comprising a processor and a memory, wherein a computer program is stored in the memory, characterized in that: The computer program is loaded and executed by the processor to implement the microservice debugging method as described in claim 1 or 2.

6. A computer-readable storage medium, wherein a computer program is stored in the storage medium, characterized in that: When the computer program is executed by a processor, it is used to implement the microservice debugging method as described in claim 1 or 2.

Images