CN116361172A - Development joint debugging method and system - Google Patents
Development joint debugging method and system Download PDFInfo
- Publication number
- CN116361172A CN116361172A CN202310336188.6A CN202310336188A CN116361172A CN 116361172 A CN116361172 A CN 116361172A CN 202310336188 A CN202310336188 A CN 202310336188A CN 116361172 A CN116361172 A CN 116361172A
- Authority
- CN
- China
- Prior art keywords
- service
- request
- development
- joint debugging
- research
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Stored Programmes (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention provides a method and a system for developing joint debugging, wherein the method comprises the following steps: performing flow dyeing on a request initiated by a front end, identifying a target service of the request, and formulating a load balancing strategy among micro services for separating a research and development request and a test request; scheduling a load balancing strategy among the micro services, and acquiring a request header mark through a request header; comparing the mark of the request head with the mark of the registered micro service, and if the marks are the same, routing the request head; if the request is a research and development request, searching joint debugging service corresponding to mark marks, and after searching fails, converting into using the test node as a default degradation scheme for routing. The invention ensures the logical isolation of research and development and test requests and ensures the research and development joint debugging dependent stable service.
Description
Technical Field
The invention relates to the technical field of research and development, in particular to a method and a system for developing joint debugging.
Background
At present, a plurality of sets of environments exist in a conventional development mode, namely a development environment, an incremental test environment, an integrated test environment, a production environment and the like, wherein the development environment is used for developing daily development, adjustment and test, and the incremental test environment and the integrated test environment are used for overlay test of different links of a test.
Chinese invention patent name: joint debugging test method, access system, front end and storage medium, patent number: CN114490336a provides a joint debugging test method, an access system, a front end and a storage medium, wherein the method comprises: acquiring a joint debugging test request of a business service, wherein the joint debugging test request carries a joint debugging function identifier corresponding to a joint debugging function; the joint debugging function identifier is transmitted among a plurality of business process nodes of business service; and executing joint debugging test by using service data of the first business process node and executing the joint debugging function corresponding to the joint debugging function identifier on the basis of the joint debugging function identifier transmitted to the first business process node at the first business process node of the business service. According to the method and the device for testing the joint debugging, the developer can access the joint debugging test of the business service by self and use the joint debugging function, and the joint debugging test efficiency is improved.
According to the conventional environment, the development environment is built, the method is only suitable for the scenes that the product micro-services are relatively few, the mutual dependency relationship among the micro-services is not much, if the product modules are numerous, and complex dependency relationship exists among the services, when joint debugging is developed, the test function of a certain product is strongly dependent on some basic services or related services of other products, the calling link is relatively long, the hunting area is relatively wide, the joint debugging function is limited by blocking, and in addition, because a plurality of independent environments are involved, a completely independent network and server resource are required, and the environment is a expenditure with relatively high resource quantity requirement. Based on the background, how to reduce the cost and increase the efficiency in the development joint debugging process and solve the problem of dependence on the development environment is always a problem studied by the technicians in the field.
Disclosure of Invention
Aiming at the problems in the prior art, the invention provides a method and a system for developing joint debugging, which are used for rewriting a service discovery load balancing strategy among micro services by connecting a request identifier in series with a whole request link node, so that the application of a test environment can be relied on for developing joint debugging requests, the purpose that the dependent service is a stable version service when the development environment joint debugging is developed is realized, and the purpose of developing and testing stability is achieved.
The technical scheme adopted by the invention is as follows:
a method of developing a joint debugging, comprising the steps of:
performing flow dyeing on a request initiated by a front end, identifying a target service of the request, and formulating a load balancing strategy among micro services for separating a research and development request and a test request;
scheduling a load balancing strategy among the micro services, and acquiring a request header mark through a request header;
comparing the mark of the request head with the mark of the registered micro service, and if the marks are the same, routing the request head;
if the request is a research and development request, searching joint debugging service corresponding to mark marks, and after searching fails, converting into using the test node as a default degradation scheme for routing.
A system for developing a joint debugging, the system being adapted for use in the method for developing joint debugging, comprising:
the increment test module is used for providing a test environment and has gray level release capability, and comprises gray level and formal two nodes;
the gray scale module is used for providing a research and development environment;
gray level release Jenkins module: basic tool software provided for automatic release service of product team;
the front end is used for issuing a request;
and the middle platform is used for building a framework and realizing the request issued by the front end.
The beneficial effects of the invention are as follows:
the invention adds the research and development release service based on the test environment, shares middleware resources with the test environment, such as a sharable micro service registration center (Nacos) to uniformly register and manage all micro services, a shared message queue (RocketMQ) to store and forward all messages through uniform message middleware, a shared cache (Redis) to cache hot spot data of high-request data, share network bandwidth, purchase the same bandwidth and IP for all requested accesses, share the same disk storage resources and CPU and memory resources, and the provided research and development environment does not need to independently build independent environment, independent network, independent middleware and other related basic resources;
the invention realizes the goal of separating development requests and test requests by carrying out flow dyeing on requests initiated by a front end, identifying target services of the requests, writing a load balancing strategy among micro services, the load balancing strategy of micro service scheduling is used for acquiring mark marks from a request head, comparing the mark marks with mark marks of micro services registered by a registry, carrying out routing on the requests and the micro services of the same mark marks, and preferentially depending on test environment services to route the requests which are not found to match the mark marks, thereby realizing that the developed requests can be scheduled to self-joint debugging service through the load balancing strategy, the tested requests can be scheduled to the service of the test environment through the load balancing strategy, and developing the service which can be scheduled to the test environment through the load balancing strategy for non-joint debugging requests. The invention ensures the logical isolation of research and development and test requests and ensures the research and development joint debugging dependent stable service.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only embodiments of the present application, and that other drawings may be obtained according to the provided drawings without inventive effort to a person skilled in the art.
FIG. 1 is a flow chart of a method for developing joint debugging according to the present invention;
FIG. 2 is a schematic diagram of the logical isolation of test and development requests under normal conditions;
FIG. 3 is a schematic diagram of the logical isolation requested when there are no joint nodes for developing dependent services;
FIG. 4 is a schematic diagram of an architecture for observing the entire system from a single development product development perspective;
FIG. 5 is a schematic diagram of a request isolation architecture under a scenario where all products are observed in an overall system.
Detailed Description
The invention is further illustrated by the following examples in conjunction with the accompanying drawings: in order to clearly illustrate the technical features of the present solution, the present invention will be described in detail below with reference to the following detailed description and the accompanying drawings. The following disclosure provides many different embodiments, or examples, for implementing different structures of the invention. In order to simplify the present disclosure, components and arrangements of specific examples are described below. Furthermore, the present invention may repeat reference numerals and/or letters in the various examples. This repetition is for the purpose of simplicity and clarity and does not in itself dictate a relationship between the various embodiments and/or configurations discussed. It should be noted that the components illustrated in the figures are not necessarily drawn to scale. Descriptions of well-known components and processing techniques and processes are omitted so as to not unnecessarily obscure the present invention.
As shown in fig. 1, the present invention provides a method for developing joint debugging, comprising:
performing flow dyeing on a request initiated by a front end, identifying a target service of the request, and formulating a load balancing strategy among micro services for separating a research and development request and a test request;
scheduling a load balancing strategy among the micro services, and acquiring a request header mark through a request header;
comparing the mark of the request head with the mark of the registered micro service, and if the marks are the same, routing the request head;
if the request is a research and development request, searching joint debugging service corresponding to mark marks, and after searching fails, converting into using the test node as a default degradation scheme for routing.
Fig. 2 illustrates a request link call condition for a development request and a test request under a normal isolation condition, where a request is initiated by a front end, and the request reaches a back end service through a load balancing policy, and the back end service has a dual-node registration condition, except that for the same service, different registration instances have different mark marks, and mark selectable values include test and development. After the request is initiated, the consistency of the mark of the request and the target service is judged through a load equalizer scheduling strategy, and dynamic load balancing processing is carried out on the request with the same mark.
The load balancing strategy is embedded into the service code in the form of SDK, and for common research and development, the part of logic is a black box, the middle scheduling process is not required to be concerned, and only the test and research and development flow is required to be known to be shunted according to mark marks.
Fig. 3 illustrates an exemplary non-joint debugging situation, and a request link call situation for a research and development request and a test request, as shown in fig. 3, a request is initiated by a front end, when the request is determined to be the research and development request, the request is tried to find joint debugging service corresponding to mark marks, a strategy corresponding to the failure is not fused in error, a test node is used as a default degradation scheme for routing, and according to the logic, the purpose that research and development of the service depended on the service can preferentially depend on the service of a test environment in a non-joint debugging mode, and self-test depended on stable service is achieved.
Fig. 4 illustrates an overview of the support capability available as a product team in a single product development team perspective, using the present solution.
Noun interpretation in fig. 4:
incremental test environment: namely, the test environment mentioned in the above description is divided into two nodes of gray scale and formal because the test environment has gray scale release capability.
Gray scale environment: i.e. the development environment mentioned in the foregoing.
An electronic medical record exclusive server: and taking the team of electronic medical records as a main view, and distributing the exclusive server resources of the team.
Gray scale release Jenkins: basic tool software provided for automatic release service of product team (Jenkins is a tool software for constructing and releasing Java program in open source).
System management console, settlement console, electronic medical record application, etc.: are product exemplary service names and may be used instead as backend service aliases herein.
As shown in fig. 4, from the view point of electronic medical record team, dedicated server resources are allocated to product team for deploying services required for development, services issued by the electronic medical record team through Jenkins are all started on dedicated servers thereof, registered service instances are marked as 'electronic medical record development', interface requests in the development and testing process are preferentially matched with services on the dedicated servers according to the load balancing policy dispatching rules, and if matching fails, the gray nodes of the testing environment are degraded and dispatched.
Fig. 5 illustrates an overall architecture concept of the present solution, which generally depicts an exemplary diagram of the goals that can be achieved by testing, developing products, and using the present solution together.
Legend explanation in fig. 5:
the upper half of fig. 5 is a service case of a test environment, and services deployed in the test environment support a gray level release function, which are divided into two sets of service nodes, namely gray level service nodes and formal service nodes, wherein mz, trade, emr and the like shown in the legend are all product service alias descriptions, and can be regarded as different product service examples.
The middle gray area in fig. 5 is a logically significant service group, and the egress gateway in the illustration is a different micro service instance for this layer, and the micro service for this layer is a service marked as "gray default".
The lower half of fig. 5 is a grouping example of the development deployed services, and different grouping modes are divided for different product groups, and service instances used by the development per se are collected and deployed under each product group.
According to the example of fig. 5, when normal service is performed by using the test domain name, the requested service is formal and gray node in the test environment. Research and development are conducted for joint debugging, and the research and development self-independent domain name is used for requesting access, and the requested links meet the rules shown in the examples of the figures 1 and 2: internal service discovery is preferentially researched and developed, and service which is degraded to gray-scale default marks (used for public research and development joint debugging service) after failure is discovered, and gray-scale default service is continuously degraded to test environment service after failure. Different product teams directly do not rely on calls to each other.
Aiming at the external third party interface call, the called link can try to call the service transversely among the product research and development, the three-party domain name shown in the legend is the exceptional case, the load balancing strategy rule can schedule the service in the product preferentially according to the exceptional case, if the failure is found, the same mark research and development service deployed in other product teams is tried, if the failure is found continuously, the rule route is carried out, and the service is degraded to a gray level default layer and a test layer in sequence. Therefore, the service called by the three-way interface is a service provided by research and development, and the link support is provided for the whole transverse call.
Finally, it should be noted that: the above embodiments are only for illustrating the technical aspects of the present invention and not for limiting the same, and although the present invention has been described in detail with reference to the above embodiments, it should be understood by those of ordinary skill in the art that: modifications and equivalents may be made to the specific embodiments of the invention without departing from the spirit and scope of the invention, which is intended to be covered by the claims.
Claims (10)
1. The development joint debugging method is characterized by comprising the following steps of:
performing flow dyeing on a request initiated by a front end, identifying a target service of the request, and formulating a load balancing strategy among micro services for separating a research and development request and a test request;
scheduling a load balancing strategy among the micro services, and acquiring a request header mark through a request header;
and comparing the mark of the request head with the mark of the registered micro service, and if the marks are the same, routing the request head.
2. The method of developing joint debugging of claim 1, wherein the method further comprises:
if the request is a research and development request, searching joint debugging service corresponding to mark marks, and after searching fails, converting into using the test node as a default degradation scheme for routing.
3. The development joint debugging method of claim 2, wherein the request header mark is compared with the mark of the registered micro service, and if no request header matching the registered micro service mark is found, the request header is routed by the test environment service preferentially.
4. The method of developing joint debugging according to claim 2, wherein the load balancing policy is embedded in the service code in the form of an SDK.
5. The development joint debugging method of claim 2, wherein the requested service is formal and gray nodes in the test environment when the test is performed for normal service using the test domain name.
6. The method for developing joint debugging according to claim 2, wherein when developing joint debugging test, the development self-separate domain name is used to request access, and the links of the development request are: preferentially researching and developing internal service discovery research and development requests; if the research and development request is not found in research and development, degrading to gray-scale default marking public research and development joint debugging service; if the gray scale default service discovery fails, the service is continuously degraded into the test environment service.
7. The method of claim 2, wherein if the external third party interface invokes a service, the invoked link will sense a lateral invocation of the service between the product developments, specifically:
a third party is used for limiting and dispatching the internal service of the product, and if dispatching fails, the research and development services with the same mark marks deployed in other product teams are dispatched;
if the research and development services deployed in other product teams are failed to be scheduled, degrading to gray-scale default marking public research and development joint debugging services; if the gray scale default service discovery fails, the service is continuously degraded into the test environment service.
8. A development joint debugging system adapted for use in the method of any one of claims 1-7, comprising:
the increment test module is used for providing a test environment and has gray level release capability, and comprises gray level and formal two nodes;
the gray scale module is used for providing concrete realization logic for bearing the load balancing strategy;
gray level release Jenkins module: basic tool software provided for automatic release service of product team;
the front end is used for issuing a request;
the exclusive server is used for distributing server resources for a development team as a view angle and is used for deploying services required by development;
the middle station is used for building a framework and supporting the service requested by the interface.
9. The development joint debugging system of claim 8, wherein after the dedicated server deploys the services required for development, the development team is started to release the services released by the Jenkins module through gray scale; and for the interface request in the research and development and test process, preferentially matching the service provided by the exclusive server, and if the matching fails, degrading and dispatching to the gray node of the test environment.
10. A computer storage medium having stored thereon a computer program for implementing the method according to any of claims 1-7 when executed by a processor.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310336188.6A CN116361172A (en) | 2023-03-29 | 2023-03-29 | Development joint debugging method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310336188.6A CN116361172A (en) | 2023-03-29 | 2023-03-29 | Development joint debugging method and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116361172A true CN116361172A (en) | 2023-06-30 |
Family
ID=86919324
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310336188.6A Pending CN116361172A (en) | 2023-03-29 | 2023-03-29 | Development joint debugging method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116361172A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117149264A (en) * | 2023-10-31 | 2023-12-01 | 山东浪潮科学研究院有限公司 | Multi-lane research and development environment construction method, device, equipment and storage medium |
-
2023
- 2023-03-29 CN CN202310336188.6A patent/CN116361172A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117149264A (en) * | 2023-10-31 | 2023-12-01 | 山东浪潮科学研究院有限公司 | Multi-lane research and development environment construction method, device, equipment and storage medium |
| CN117149264B (en) * | 2023-10-31 | 2024-01-30 | 山东浪潮科学研究院有限公司 | Multi-lane research and development environment construction method, device, equipment and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106663033B (en) | System and method for supporting a wraparound domain and proxy model and updating service information for cross-domain messaging in a transactional middleware machine environment | |
| US8375122B2 (en) | Web service information management in service-oriented architecture applications | |
| US8447881B2 (en) | Load balancing for services | |
| US20030126196A1 (en) | System for optimizing the invocation of computer-based services deployed in a distributed computing environment | |
| US7167861B2 (en) | Mobile application service container | |
| US20020087734A1 (en) | System and method for managing dependencies in a component-based system | |
| JPH10187641A (en) | Method for supporting address interaction between 1st entity and 2nd entity, converter for address interaction, and computer system | |
| US7818752B2 (en) | Interface for application components | |
| US20070266035A1 (en) | Methods, Systems and Computer Program Products for Web Service Interaction with a Resource Management System | |
| CN116361172A (en) | Development joint debugging method and system | |
| CN109104368B (en) | Connection request method, device, server and computer readable storage medium | |
| WO2023040498A1 (en) | User service utilization | |
| CZ20032918A3 (en) | Group access privatization in clustered computer system | |
| JP2013543169A (en) | System including middleware machine environment | |
| Migliardi et al. | Heterogeneous distributed virtual machines in the Harness metacomputing framework | |
| Schmidt et al. | SoapME: a lightweight Java ME web service container | |
| US20060080331A1 (en) | Common interface system administration service library | |
| Vilas et al. | High availability with clusters of web services | |
| CN115361298B (en) | Service management method based on data subscription distribution network | |
| CN112073449B (en) | Kubernetes-based environment switching processing method and equipment | |
| US20050235339A1 (en) | Limiting access to publicly exposed object-oriented interfaces via password arguments | |
| CN117544637A (en) | Method and system for supporting external service access by cluster containerization deployment | |
| CN118113460A (en) | Service aggregation method based on micro-service | |
| Migliardi et al. | Plug-ins, layered services and behavioral objects: Application programming styles in the HARNESS metacomputing system | |
| Ping | Application of the Extension Point and Plug-Ins Idea in Transmission Network Management System |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |