CN116647603A - Distribution method, device, equipment and storage medium for distributed application - Google Patents
Distribution method, device, equipment and storage medium for distributed application Download PDFInfo
- Publication number
- CN116647603A CN116647603A CN202310630029.7A CN202310630029A CN116647603A CN 116647603 A CN116647603 A CN 116647603A CN 202310630029 A CN202310630029 A CN 202310630029A CN 116647603 A CN116647603 A CN 116647603A
- Authority
- CN
- China
- Prior art keywords
- application
- target
- downstream
- deployed
- version
- 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
- 238000000034 method Methods 0.000 title claims abstract description 62
- 238000012545 processing Methods 0.000 claims abstract description 95
- 238000012360 testing method Methods 0.000 claims abstract description 29
- 238000012423 maintenance Methods 0.000 claims description 21
- 239000000523 sample Substances 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 11
- 238000004891 communication Methods 0.000 description 8
- 238000004590 computer program Methods 0.000 description 6
- 238000011161 development Methods 0.000 description 6
- 230000000694 effects Effects 0.000 description 5
- 230000008569 process Effects 0.000 description 3
- 238000011144 upstream manufacturing Methods 0.000 description 3
- 101100368725 Bacillus subtilis (strain 168) tagF gene Proteins 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000000802 evaporation-induced self-assembly Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/10015—Access to distributed or replicated servers, e.g. using brokers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
-
- 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)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Stored Programmes (AREA)
Abstract
The method, the device, the equipment and the storage medium for publishing the distributed application can be used in the distributed field. The method comprises the following steps: the service server can acquire a service processing request corresponding to the target service through the current application, determine a downstream application to be invoked by the current application according to the target service, determine flow proportions of the downstream applications of different versions deployed in the target deployment devices according to the version numbers of the downstream applications deployed by each target deployment device, and invoke different versions of the downstream applications deployed in the target deployment devices according to the flow proportions to perform service processing to obtain service processing results. And determining test results of versions to be distributed of downstream applications deployed in the multiple target deployment devices according to the service processing results, wherein the test results are used for indicating whether the versions to be distributed of the downstream applications meet distribution conditions. If yes, the version to be issued of the downstream application can be issued, and the application improves the efficiency of issuing the new version of the distributed application.
Description
Technical Field
The present application relates to the field of distributed applications, and in particular, to a method, an apparatus, a device, and a storage medium for publishing a distributed application.
Background
With the popularization of distributed system architecture, more and more enterprises change application systems from single application to distributed application, and a plurality of systems coordinate to work, so that the complexity is increased.
And with the rapid development of the service, the frequency and the times of developing new versions by the distributed application system are obviously increased. At present, a new version of a distributed application can be released through a gray level release method, a small-scale application of the new version to be released is additionally deployed in the same machine room besides the existing application of a stable version (old version), a part of users continue to use the old version, another part of users start to use the new version, if the users respond well to the use of the new version, the range is gradually widened, and all users are migrated to the new version.
The application can be a micro-service application of a component-level application, and due to the development of services, the situation that a plurality of micro-service applications of the component-level application are deployed on different devices of different machine rooms occurs, and new versions are released by the gray level release method for each machine room, so that the release efficiency of the new versions is lower.
Disclosure of Invention
The application provides a method, a device, equipment and a storage medium for releasing a distributed application, which solve the problem of low release efficiency of a new version in the related technology.
In a first aspect, the present application provides a method for publishing a distributed application, applied to a service server, where the method includes:
acquiring a service processing request corresponding to a target service through a current application;
determining the downstream application to be called by the current application according to the target service;
determining version numbers of the downstream application deployed in a plurality of target deployment devices, wherein the version numbers comprise version numbers to be released;
according to the version numbers of the downstream applications deployed by each target deployment device, determining the flow proportions of the downstream applications of different versions deployed in the target deployment devices;
according to the flow proportion, calling different versions of downstream applications deployed in the target deployment devices to perform service processing to obtain service processing results;
and determining a test result of a version to be distributed of the downstream application deployed in the target deployment devices according to the service processing result, wherein the test result is used for indicating whether the version to be distributed of the downstream application meets a distribution condition.
In a second aspect, the present application provides a method for publishing a distributed application, applied to an operation and maintenance server, where the method includes:
displaying a route rule creating interface;
creating a routing rule in the routing rule creating interface, wherein the routing rule comprises a plurality of version numbers of the target application and flow proportions corresponding to each version number;
determining a service server corresponding to the routing rule;
and sending the routing rule to the service server.
In a third aspect, the present application provides a publishing device of a distributed application, including:
the acquisition module is used for acquiring a service processing request corresponding to the target service through the current application;
the first determining module is used for determining the downstream application to be called by the current application according to the target service;
the second determining module is used for determining version numbers of the downstream application deployed in the target deployment devices, wherein the version numbers comprise version numbers to be released;
the third determining module is used for determining the flow ratio of the downstream applications of different versions deployed in the target deployment devices according to the version numbers of the downstream applications deployed by each target deployment device;
The processing module is used for calling different versions of downstream applications deployed in the target deployment devices to perform service processing according to the flow proportion to obtain service processing results;
and the fourth determining module is used for determining a test result of a version to be distributed of the downstream application deployed in the plurality of target deployment devices according to the service processing result, wherein the test result is used for indicating whether the version to be distributed of the downstream application meets a distribution condition.
In a fourth aspect, the present application provides a publishing device of a distributed application, including:
the display module is used for displaying the interface for creating the routing rule;
the creating module is used for creating a routing rule in the routing rule creating interface, wherein the routing rule comprises a plurality of equipment types and flow proportions corresponding to each equipment type by the target application;
the determining module is used for determining a service server corresponding to the routing rule;
and the sending module is used for sending the routing rule to the service server.
In a fifth aspect, the present application provides an electronic device, comprising: a processor, and a memory communicatively coupled to the processor;
the memory stores computer-executable instructions;
The processor executes computer-executable instructions stored by the memory to implement the method of issuing a distributed application as described in the first or second aspect.
In a sixth aspect, the present application provides a computer-readable storage medium having stored therein computer-executable instructions for implementing the method of publishing a distributed application as described in the first or second aspect when executed by a computer.
In a seventh aspect, the present application provides a computer program product comprising a computer program for implementing the method of publishing a distributed application according to the first or second aspect when the computer program is executed by a computer.
According to the distributed application publishing method, device, equipment and storage medium, a service server can acquire a service processing request corresponding to a target service through a current application, then determine downstream applications to be called by the current application according to the target service, determine version numbers of the downstream applications in a plurality of target deployment devices, determine flow proportions of the downstream applications of different versions deployed in the plurality of target deployment devices according to the version numbers of the downstream applications deployed by each target deployment device, and call the different versions of the downstream applications deployed in the plurality of target deployment devices according to the flow proportions to perform service processing to obtain service processing results. And determining test results of versions to be distributed of downstream applications deployed in the plurality of target deployment devices according to the service processing results, wherein the test results are used for indicating whether the versions to be distributed of the downstream applications meet distribution conditions. If the release condition is met, the version to be released of the downstream application can be released, and the method and the device can meet the release of the new version of the component-level application in the scene that a plurality of micro service applications are deployed on different devices of different machine rooms, so that the release efficiency of the new version of the distributed application is improved.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application.
FIG. 1 is a schematic diagram of an application scenario to which the present application is applicable;
FIG. 2 is a schematic diagram of a call between applications of an example of the present application;
fig. 3 is a flow chart of a method for publishing a distributed application according to a first embodiment of the present application;
fig. 4 is a flow chart of another method for publishing a distributed application according to the second embodiment of the present application;
fig. 5 is a signaling flow chart of a release method of another distributed application according to the third embodiment of the present application;
FIG. 6 is a schematic diagram of an interface for creating routing rules according to an example of the present application;
fig. 7 is a schematic structural diagram of a distributing device for distributed applications according to a fourth embodiment of the present application;
fig. 8 is a schematic structural diagram of a distributing device for distributed applications according to a fifth embodiment of the present application;
fig. 9 is a schematic structural diagram of an electronic device according to a sixth embodiment of the present application.
Specific embodiments of the present application have been shown by way of the above drawings and will be described in more detail below. The drawings and the written description are not intended to limit the scope of the inventive concepts in any way, but rather to illustrate the inventive concepts to those skilled in the art by reference to the specific embodiments.
Detailed Description
Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the application. Rather, they are merely examples of apparatus and methods consistent with aspects of the application as detailed in the accompanying claims.
It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application are information and data authorized by the user or fully authorized by each party, and the collection, use and processing of the related data need to comply with related laws and regulations and standards, and provide corresponding operation entries for the user to select authorization or rejection.
It should be noted that the method, the device, the equipment and the storage medium for publishing the distributed application provided by the application can be used in the distributed field, and can also be used in any field except the distributed field.
With the rapid growth of users and the rapid development of services, the iteration period for developing and developing new versions is faster and faster, on one hand, stable services are required to be provided for users, and on the other hand, rapid service iteration is required.
At present, a new version of a distributed application can be released through a gray level release method, a small-scale application of the new version to be released is additionally deployed in the same machine room besides the existing application of a stable version (old version), a part of users continue to use the old version, another part of users start to use the new version, if the users respond well to the use of the new version, the range is gradually widened, and all users are migrated to the new version.
The application may be a micro-service application of a component-level application, and due to the development of services, a situation occurs in which a plurality of micro-service applications of the component application are deployed on different devices of different machine rooms, and the gray level release method is executed for each machine room to release a new version, so that the release efficiency of the new version is lower.
Therefore, after a service server obtains a service processing request of a target service through a current application, the service server can call different versions of downstream applications deployed in a plurality of deployment devices to process the service according to flow proportions of the downstream applications deployed in the deployment devices to obtain a service processing result, and can determine whether a version to be distributed of the downstream applications meets a distribution condition or not based on the service processing result, if so, the release can be performed, and release of new versions of a plurality of micro-service applications of component-level applications deployed in scenes of different devices of different machine rooms can be met, thereby improving the release efficiency of the new versions of the distributed applications.
For a clearer description of the present application, the following description will be made with reference to terms related to embodiments of the present application:
an application may generally be formed by a plurality of components, which may be referred to as component-level applications, each component representing a different functional module (which may be referred to as a service in the present application), and each component including a plurality of micro-service applications, for example, an application including functional modules such as "deposit service", "credit card service", and "deposit service" including a plurality of micro-service applications to provide services to users.
Gateway application: may be an application for communication between components, i.e. a call between components, which requires a call through a gateway application.
Non-gateway applications: refers to an application in a component, namely a common micro-service application.
For easy understanding, an application scenario to which the embodiment of the present application is applied is described below in conjunction with the example of fig. 1.
Fig. 1 is a schematic diagram of an application scenario to which the present application is applicable, please refer to fig. 1, including: the operation server 101, the service server a102, the service server B103, and the service server C104 can communicate with each other via the internet, among the operation server 101, the service server a102, the service server B103, and the service server C104.
Illustratively, the current application is deployed in the service server a102, the version 1 of the downstream application of the current application is deployed in the service server B103, and the to-be-deployed version of the downstream application of the current application is deployed in the service server C104, where a call relationship exists between the current application and the downstream application, for example, the order of calling the applications is that the current application and the downstream application, that is, the current application calls the downstream application.
After the service server a102 obtains the service request corresponding to the target service, it can determine the downstream application to be invoked by the current application, then determine the version numbers of the downstream application deployed in the multiple target deployment devices in the target machine room, and implement the invocation according to the flow proportion corresponding to the version numbers. The service server B103 and the service server C104 belong to the same machine room.
The operation and maintenance server 101 may be used to establish routing rules for the target application. The operation and maintenance server 101 may send the routing rule to the service server where the preset application is located.
Taking the current application as an example, if the downstream application is the target application and the target application is a non-gateway application, the operation and maintenance server 101 may send the routing rule to the non-gateway application in the component where the target application is located or the deployment device application where the gateway in the component is located, and then the current application may be the non-gateway application in the component where the target application is located or may also be the gateway application in the component where the target application is located. Then the operation and maintenance server 101 may send the routing rule to the deployment device where the current application is located (i.e. the service server a 102).
If the downstream application is the target application and the target application is the gateway application, the operation and maintenance server 101 may send the routing rule to the deployment device where any one of the non-gateway application in the component where the target application is located, the gateway application in the component, and the designated application is located, and then the current application may be any one of the non-gateway application in the component where the target application is located, the gateway application in the component, and the designated application. Then the operation and maintenance server 101 may send the routing rule to the deployment device where the current application is located (i.e. the service server a 102).
It is understood that the number of service servers a102, B103, and C104 may be plural, which are not shown in the figure.
For a clearer description of calls between applications, please refer to fig. 2, and fig. 2 illustrates the calls between applications. The current application in the component 2 may receive the service processing request initiated by the caller in the component 1, and then, according to the routing rule sent by the operation and maintenance platform, the service server a102 may route the traffic of the service processing request to the downstream application a of different versions according to different traffic proportions, in fig. 2, x% of the traffic corresponds to one link, y% of the traffic corresponds to another link, taking the link corresponding to x% of the traffic in fig. 2 as an example, after the traffic of the service processing request is routed to the downstream application a of the version to be distributed, the downstream application a of the link routes the x% of the traffic processing request to the downstream application a of the link, which is for convenience of illustration, only the downstream applications a and a are illustrated, and in practical applications, the downstream application of a may also have downstream applications, which are not shown in the figure.
The following describes the technical scheme of the present application and how the technical scheme of the present application solves the above technical problems in detail with specific embodiments. The following embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.
Fig. 3 is a flow chart of a distributed application publishing method according to an embodiment of the present application, where the method may be executed by a service server, or may be executed by a service processing device disposed in the service server, and the device may be a chip, or may be a chip module, or may be an integrated development environment (integrated development environment, IDE), etc., and referring to fig. 3, the method includes the following steps, taking the service server as an example:
s301, acquiring a service processing request corresponding to a target service through a current application.
The service server can obtain service processing requests corresponding to the target service through the current application, and the number of the service processing requests can be one or more.
In one possible implementation, the caller that initiates the business process request may be an application in an upstream component of the component in which the current application is located.
In another possible implementation, the caller that initiates the service processing request may be an upstream application of the current application, and it is understood that the upstream application of the current application belongs to the same component as the current application.
S302, determining a downstream application to be called by the current application according to the target service.
After the service processing request is obtained, the service server can determine the downstream application to be invoked by the current application according to the target service.
For example, the service server may obtain application information of a plurality of applications of the target service from a registry database, where the application information may include an identification of the applications and an identification of downstream applications of each application, and the registry database includes the plurality of applications of the plurality of services. After the service server obtains the application information of the multiple applications of the target service, the downstream application to be called by the current application can be determined in the multiple applications.
S303, determining version numbers of the downstream application deployed in a plurality of target deployment devices in the target machine room, wherein the version numbers comprise version numbers of versions to be deployed.
After determining the downstream application to be invoked by the current application, the service server may determine version numbers of the downstream application deployed in a plurality of target deployment devices in the target machine room.
In the embodiment of the application, one server is the minimum unit for application deployment, one physical unit comprises a plurality of servers, and one machine room can comprise a plurality of physical units.
S304, determining the flow ratio of the downstream applications of different versions deployed in the target deployment devices according to the version numbers of the downstream applications deployed by each target deployment device.
In the embodiment of the application, the flow ratios corresponding to the downstream applications of different versions are different, the version number of the downstream application deployed by each target deployment device is determined, and the service server can determine the flow ratios of the downstream applications of different versions deployed in a plurality of target deployment devices according to the version number of the downstream application deployed by each target deployment device.
S305, calling different versions of downstream applications deployed in a plurality of target deployment devices according to the flow proportion to perform service processing, and obtaining a service processing result.
The service server can call different versions of the downstream application deployed in the multiple target deployment devices according to the flow proportion to perform service processing, and a service processing result is obtained.
For example, the service server may route the traffic of the service processing request to the target deployment device including the V1 version number in the device information according to the x% ratio, and may route the traffic of the service processing request to the target deployment device including the V2 version number in the device information according to the y% ratio. Where the sum of x% and y% is 100%, for example, x may be 20 and y may be 80, where V2 is the version number of the version to be distributed for the downstream application.
S306, determining test results of versions to be distributed of downstream applications deployed in the multiple target deployment devices according to service processing results, wherein the test results are used for indicating whether the versions to be distributed of the downstream applications meet distribution conditions.
After determining the service processing result, the service server may determine, according to the service processing result, a test result of a version to be distributed of the downstream application deployed in the plurality of target deployment devices, where the test result is used to indicate whether the version to be distributed of the downstream application meets a distribution condition.
For example, if the service processing result indicates that the processing result of the to-be-issued version of the downstream application indicates that the processing of the service processing request is abnormal, that is, a normal processing result of the service processing request is not obtained (which may be understood as that the to-be-issued version of the downstream application fails to normally respond to the service processing of the service processing request), it may be determined that the test result of the to-be-issued version of the downstream application is abnormal, and correspondingly, the test result indicates that the to-be-issued version of the downstream application does not meet the issue condition.
For another example, if the service processing result indicates that the processing result of the version to be distributed of the downstream application indicates that the processing of the service processing request is normal, that is, the processing result includes a normal processing result (for example, a certain response value) of the service processing request, it may be determined that the test result of the version to be distributed of the downstream application is normal, and correspondingly, the test result indicates that the version to be distributed of the downstream application meets the distribution condition.
In this embodiment, the service server may obtain a service processing request corresponding to the target service through the current application, then determine a downstream application to be invoked by the current application according to the target service, determine version numbers of the downstream application in the multiple target deployment devices, determine flow proportions of the downstream applications of different versions deployed in the multiple target deployment devices according to the version numbers of the downstream application deployed by each target deployment device, and invoke different versions of the downstream application deployed in the multiple target deployment devices according to the flow proportions to perform service processing, so as to obtain a service processing result. And determining test results of versions to be distributed of downstream applications deployed in the plurality of target deployment devices according to the service processing results, wherein the test results are used for indicating whether the versions to be distributed of the downstream applications meet distribution conditions. If the release condition is met, the version to be released of the downstream application can be released, and the method and the device can meet the release of the new version of the component-level application in the scene that a plurality of micro service applications are deployed on different devices of different machine rooms, so that the release efficiency of the new version of the distributed application is improved.
Next, a second embodiment is used to describe another method for publishing a distributed application provided by the present application.
Fig. 4 is a flow chart of another method for publishing a distributed application according to the second embodiment of the present application, where the method may be executed by a service server, or may be executed by a publishing device of the distributed application provided in the service server, where the device may be a chip, a chip module, or an IDE, etc., and in the following case, taking the service server as an example, a preset entry application of a target gray environment is deployed in the service server, and referring to fig. 4, the method includes the following steps:
s401, acquiring a service processing request corresponding to a target service through a current application.
S402, determining a downstream application to be called by the current application according to the target service.
The specific description in S401 and S402 may refer to the above embodiments, and will not be repeated here.
S403, determining version numbers of the downstream application deployed in a plurality of target deployment devices in the target machine room, wherein the version numbers comprise version numbers of versions to be deployed.
In one possible implementation, the service server may obtain, from a registry database, version numbers of downstream applications deployed in a plurality of deployment devices in a plurality of rooms. Specifically, the service server obtains device information of a plurality of deployment devices of the downstream application in a plurality of physical units from the registry database, and each device information can include a version number of the downstream application deployed by the device information.
In one possible implementation, the service server may obtain device information of a plurality of deployment devices in the plurality of physical units of the downstream application from the registry database, then determine a target physical unit from the plurality of physical units according to the identification of the target physical unit in the target routing rule, and then determine the deployment device in the target physical unit as the target deployment device.
It is understood that the plurality of physical units may belong to the same machine room or may belong to different machine rooms.
S404, at least one routing rule is obtained, and each routing rule comprises a plurality of version numbers of downstream applications and flow proportions corresponding to each version number.
The service server may obtain at least one routing rule.
In one possible implementation, the service server may store at least one routing rule, the at least one routing rule being sent by the operation and maintenance server. The routing rule comprises a plurality of version numbers of the downstream application and a traffic proportion corresponding to each version number.
S405, determining a target routing rule in at least one routing rule.
The traffic server stores at least one routing rule from which the traffic server can determine the target routing rule.
In one possible implementation, the service server may determine the priority of at least one routing rule, in particular, each routing rule includes a value of priority, e.g., the value of priority is represented by a number, the smaller the value, the higher the priority. The traffic server may then determine the highest priority routing rule of the at least one routing rule as the determination target routing rule.
S406, according to the version numbers of the downstream application deployed by the plurality of target deployment devices, determining the flow proportion of the downstream application in the plurality of target deployment devices in the target routing rule.
After determining the target routing rule, the service server may determine, based on the version numbers of the downstream applications in the target routing rule and the traffic proportion corresponding to each version number, the traffic proportion of the downstream applications in the plurality of target deployment devices according to the version numbers of the downstream versions deployed in each target deployment device.
Illustratively, the target routing rule includes two versions of the downstream application: v1 and V2, wherein V1 corresponds to a flow ratio of 20% and V2 corresponds to a flow ratio of 80%, for example, there are 10 target deployment devices: a1, a2, a3, a4, a5, a6, a7, a8, a9, and a10, where the version of the downstream application deployed by the 4 target deployment devices (a 1, a2, a3, a 4) is V1, and the version of the downstream application deployed by the 6 target deployment devices (a 5, a6, a7, a8, a9, a 10) is V2, then the service server may determine that the traffic proportion corresponding to the 4 target deployment devices (a 1, a2, a3, a 4) is 20%, and the traffic proportion corresponding to the 6 target deployment devices (a 5, a6, a7, a8, a9, a 10) is 80%.
S407, calling different versions of downstream applications deployed in the target deployment devices according to the flow proportion to perform service processing, and obtaining a service processing result.
After the flow ratio is determined, the service server can call different versions of downstream applications deployed in the multiple target deployment devices to perform service processing, so as to obtain a service processing result.
Taking the example in S406 as an example, the service server may route 20% of the traffic of the service processing request to the 4 target deployment devices (a 1, a2, a3, a 4) while routing 80% of the traffic of the service processing request to the 6 target deployment devices (a 5, a6, a7, a8, a9, a 10).
In one possible implementation manner, if a test result of a to-be-issued version of a downstream application deployed in a first deployment device of the multiple target deployment devices indicates that the to-be-issued version of the downstream application deployed in the first deployment device does not meet the issue condition, the service server may send indication information to the first deployment device where the downstream application is located, where the indication information is used to instruct the first deployment device to perform a version rollback operation on the downstream application, rollback the to-be-issued version of the downstream application to a previous version of the to-be-issued version, where the previous version of the downstream application is used to provide services for the service processing request, so that an anomaly of the downstream application and an interruption of services can be avoided.
In this embodiment, the service server may obtain, by using the current application, a service processing request corresponding to the target service, and then determine, according to the target service, a downstream application to be invoked by the current application, and determine version numbers of the downstream application in multiple target deployment devices. And then at least one routing rule is obtained, a target routing rule is determined in the at least one routing rule, the flow proportion of the downstream applications of different versions deployed in the plurality of target deployment devices is determined in the target routing rule according to the device type of each target deployment device, and then the different versions of the downstream applications deployed in the plurality of target deployment devices are called for service processing according to the flow proportion, so that a service processing result is obtained. And determining test results of versions to be distributed of downstream applications deployed in the plurality of target deployment devices according to the service processing results, wherein the test results are used for indicating whether the versions to be distributed of the downstream applications meet distribution conditions. If the release condition is met, the version to be released of the downstream application can be released, and the method and the device can meet the release of the new version of the component-level application in the scene that a plurality of micro service applications are deployed on different devices of different machine rooms, so that the release efficiency of the new version of the distributed application is improved.
Next, a method for publishing a distributed application according to a third embodiment of the present application will be described. The interaction between the operation server and the service server is specifically described.
Fig. 5 is a signaling flow chart of a release method of another distributed application according to the third embodiment of the present application, and referring to fig. 5, the method includes the following steps:
s501, the operation and maintenance server displays a route rule creating interface.
The operation and maintenance manager can click on the newly built routing rule on the corresponding interface and jump to the page for creating the routing rule.
S502, the operation and maintenance server creates a routing rule in a routing rule creating interface.
And the operation and maintenance manager creates a routing rule through the operation and maintenance server in a routing rule creating interface, wherein the routing rule comprises a plurality of version numbers of downstream application and flow proportions corresponding to each version number.
S503, the operation and maintenance server determines a service server corresponding to the routing rule.
In one possible implementation manner, the routing rule may further include a caller parameter, that is, the operation and maintenance server may determine, according to the caller parameter, a preset application for calling the target application, and then determine, as a service server corresponding to the routing rule, a deployment device in which the preset application is located, where the caller parameter includes an application type of the preset application.
If the type of the target application is a gateway application, the preset application is any one of a non-gateway application in a component where the target application is located, a gateway application in a component where the target application is located, and a designated application. That is, if the type of the target application is a gateway application, the routing rule may be sent to all non-gateway applications in the component where the target application is located, the gateway application of the component where the target application is located, and the deployment device where any one of the designated applications is located.
If the type of the target application is a non-gateway application, the preset application is the non-gateway application in the component where the target application is located or the gateway application of the component where the target application is located. That is, if the type of the target application is a non-gateway application, the routing rule may be sent to the non-gateway application in the component where the target application is located or the deployment device where the gateway application of the component where the target application is located.
Specifically, all non-gateway applications in the component where the target application is located, and designated applications can be determined through preset labels, and all non-gateway applications in the component where the target application is located, and devices where the designated applications are located are devices in a designated physical unit.
For example, as shown in fig. 6, fig. 6 is an interface schematic diagram for creating a routing rule, where the application types of the preset application in the caller parameters may be components, applications or custom applications, and each application type includes a matching relationship, and a tag value, where the matching relationship is any one of equal, unequal, including and not including.
For the option that the application type is a component, the matching relationship may be equal to, and the tag value may be the name of the component.
For an option where the application type is an application, the matching relationship may be equal to, and the tag value may be the name of the application.
For the option that the application type is the custom application, the matching relationship may be any one of equal, unequal, including and not including, and the tag value may be a preset tag value, for example, tag1, that is, the application that is equal to, unequal, including or not including tag1 in the application information is the custom application. It is understood that the custom application is the above-specified application.
For example, the application type in the routing rule is a component, the tag value may set the name 1 of the component, and the matching relationship is equal, and then the preset application is all non-gateway applications of the name 1.
For another example, the application type in the routing rule is an application, the tag value may set the name 2 of the application, and the matching relationship is equal to that, and then the preset application is an application with the name 2.
For another example, the application type in the routing rule is a custom application, and since the application is a specified application, the tag value may be a preset tag value, for example, tag1, and the matching relationship is unequal, for example, if the application information of a certain application includes tag2 and tag3, and both tag2 and tag3 are unequal to tag1, that is, tag1 does not exist in the application information, the application may be determined to be a preset application.
In fig. 6, the routing rule may also include a rule name, the availability status (available or unavailable) of the rule, and priority.
In one possible implementation, the routing rule may further include application information of the target application, where the application information includes a name of a component where the target application is located, an application name of the target application, and an identifier of a physical unit where the target application is located. The destination parameter in fig. 6 is application information of the target application, and the corresponding flow ratio may be determined according to the version number of the deployed target application in the device information of the deployed device where the target application is located, and the V2 version in fig. 6 may be a version to be deployed.
Taking fig. 6 as an example, if the version number of the deployed target application in the device information of the deployed device where the target application is located is V1, the flow rate ratio corresponding to the device is 80%, and if the version number of the deployed target application in the device information of the deployed device where the target application is located is V2, the flow rate ratio corresponding to the device is 20%. The specific reference to the second embodiment may be referred to for the target application according to the flow ratio, which is not described herein again, and the downstream application in the second embodiment may be understood as the target application in the present embodiment.
It can be understood that when the operation and maintenance personnel creates the routing rule through the operation and maintenance server, the corresponding flow proportion can be set according to the version number of the deployment device deployment, for example, the number of service processing requests processed by the device deployed with the downstream application of the version to be deployed can be smaller than that of the device deployed with the downstream application of the old version. It will be appreciated that the version number of the application it deploys will also be included in the device information of the device to which the target application belongs, which version number can be used to determine the traffic proportion.
S504, the operation and maintenance server sends the routing rule to the service server corresponding to the routing rule.
In this embodiment, the operation and maintenance server may create a routing rule, then determine a service server corresponding to the routing rule, and send the routing rule to the service server corresponding to the routing rule, so that the service server may perform call processing applied to the service processing request according to the routing rule. The application can realize the flow diversion of the service processing request according to the version number of the downstream application so as to realize the calling of the version to be distributed of the downstream application, can meet the requirement of the release of the new version of the component-level application in the scene that a plurality of micro service applications are deployed on different devices of different machine rooms, and improves the release efficiency of the new version of the distributed application.
Fig. 7 is a schematic structural diagram of a distributing device for distributed applications according to a fourth embodiment of the present application. Referring to fig. 7, the apparatus 70 includes: an acquisition module 701, a first determination module 702, a second determination module 703, a third determination module 704, a processing module 705, and a fourth processing module 706.
The acquiring module 701 is configured to acquire, by using a current application, a service processing request corresponding to a target service.
A first determining module 702, configured to determine, according to the target service, a downstream application to be invoked by the current application.
A second determining module 703, configured to determine version numbers of downstream applications deployed in a plurality of target deployment devices in the target computer room, where the version numbers include version numbers to be published.
A third determining module 704, configured to determine, according to the version number of the downstream application deployed by each target deployment device, a traffic proportion of the downstream applications of different versions deployed in the multiple target deployment devices.
And the processing module 705 is configured to call different versions of the downstream applications deployed in the multiple target deployment devices according to the traffic proportion to perform service processing, so as to obtain a service processing result.
A fourth determining module 706, configured to determine, according to the service processing result, a test result of a version to be distributed of the downstream application deployed in the multiple target deployment devices, where the test result is used to indicate whether the version to be distributed of the downstream application meets a distribution condition.
In one possible implementation, the third determining module 704 is specifically configured to:
and obtaining at least one routing rule, wherein each routing rule comprises a plurality of version numbers of downstream application and flow proportions corresponding to each version number.
Among the at least one routing rule, a target routing rule is determined.
And determining the flow proportions of the downstream applications of different versions deployed by the plurality of target deployment devices in the target routing rule according to the version numbers of the downstream applications deployed by the plurality of target deployment devices.
In one possible implementation, the third determining module 704 is specifically configured to:
the priority of each routing rule is determined.
And determining the routing rule with the highest priority among the at least one routing rule as a target routing rule.
In one possible implementation of the present invention,
in one possible implementation, the second determining module 703 is specifically configured to:
the version numbers of the downstream applications deployed in the plurality of deployment devices in the plurality of machine rooms are obtained from the registry database.
From version numbers of downstream applications deployed in a plurality of deployment devices in a plurality of machine rooms, version numbers of downstream applications deployed in a plurality of target deployment devices in a target machine room are determined.
In one possible implementation, the apparatus 70 further includes a transmitting module.
The sending module is specifically used for:
if the test result of the to-be-issued version of the downstream application deployed in the first deployment device in the multiple target deployment devices indicates that the to-be-issued version of the downstream application deployed in the first deployment device does not meet the issuing condition, sending indication information to the first deployment device, where the indication information is used to instruct the first deployment device to perform a version rollback operation on the downstream application, rollback the to-be-issued version of the downstream application deployed in the first target deployment device to a previous version of the to-be-issued version, where the previous version of the downstream application is used to provide services for the service processing request.
The device of the present embodiment may be used to execute the technical solutions of the foregoing method embodiments, and the specific implementation manner and the technical effects are similar, and are not repeated herein.
Fig. 8 is a schematic structural diagram of a distributing device for distributed applications according to a fifth embodiment of the present application. Referring to fig. 8, the apparatus 80 includes: a display module 901, a creation module 902, a determination module 903, and a transmission module 904.
And the display module 901 is used for displaying the created routing rule interface.
The creating module 902 is configured to create a routing rule in the routing rule creating interface, where the routing rule includes a plurality of version numbers of the target application and a traffic proportion corresponding to each version number.
A determining module 803, configured to determine a service server corresponding to the routing rule.
A sending module 804, configured to send the routing rule to the service server.
In one possible implementation, the routing rule further includes a caller parameter.
The determining module 803 is specifically configured to:
and determining a preset application for calling the target application according to the calling party parameters, wherein the calling party parameters comprise the application type of the preset application.
And determining the deployment equipment where the preset application is located as a service server corresponding to the routing rule.
In one possible implementation manner, if the type of the target application is a gateway application, the preset application is any one of a non-gateway application in a component where the target application is located, a gateway application in a component where the target application is located, and a designated application.
If the type of the target application is a non-gateway application, the preset application is the non-gateway application in the component where the target application is located or the gateway application of the component where the target application is located.
The device of the present embodiment may be used to execute the technical solutions of the foregoing method embodiments, and the specific implementation manner and the technical effects are similar, and are not repeated herein.
Fig. 9 is a schematic structural diagram of an electronic device according to a sixth embodiment of the present application, and as shown in fig. 9, an electronic device 90 may include: at least one processor 901 and a memory 902.
A memory 902 for storing programs. In particular, the program may include program code including computer-executable instructions.
The Memory 902 may include random access Memory (Random Access Memory, RAM) and may also include Non-volatile Memory (Non-volatile Memory), such as at least one disk Memory.
The processor 901 is configured to execute computer-executable instructions stored in the memory 902 to implement the methods described in the foregoing method embodiments. The processor 901 may be a central processing unit (Central Processing Unit, CPU), or an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits configured to implement embodiments of the present application.
Optionally, the electronic device 90 may further include: a communication interface 903. In a specific implementation, if the communication interface 903, the memory 902, and the processor 901 are implemented independently, the communication interface 903, the memory 902, and the processor 901 may be connected to each other through buses and perform communication with each other. The bus may be an industry standard architecture (Industry Standard Architecture, ISA) bus, an external device interconnect (Peripheral Component, PCI) bus, or an extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus, among others. Buses may be divided into address buses, data buses, control buses, etc., but do not represent only one bus or one type of bus.
Alternatively, in a specific implementation, if the communication interface 903, the memory 902, and the processor 901 are integrated on a chip, the communication interface 903, the memory 902, and the processor 901 may complete communication through internal interfaces.
The electronic device 90 may be a chip, a chip module, an IDE, a server, or the like.
The electronic device of the present embodiment may be used to execute the technical solutions of the foregoing method embodiments, and the specific implementation manner and the technical effects are similar, and are not repeated herein.
A seventh embodiment of the present application provides a computer-readable storage medium, which may include: various media capable of storing computer execution instructions, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a RAM, a magnetic disk, or an optical disc, etc., specifically, the computer execution instructions are stored in the computer readable storage medium, and when the computer execution instructions are executed by a computer, the technical scheme shown in the foregoing method embodiment is executed, and specific implementation manner and technical effects are similar and are not repeated herein.
An eighth embodiment of the present application provides a computer program product, which includes a computer program, and when the computer program is executed by a computer, the technical solution shown in the foregoing method embodiment is executed, and the specific implementation manner and the technical effect are similar, and are not repeated herein.
Other embodiments of the application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.
It is to be understood that the application is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the application is limited only by the appended claims.
Claims (12)
1. A method for distributing a distributed application, applied to a service server, the method comprising:
acquiring a service processing request corresponding to a target service through a current application;
determining the downstream application to be called by the current application according to the target service;
determining version numbers of the downstream application deployed in a plurality of target deployment devices in a target machine room, wherein the version numbers comprise version numbers of versions to be deployed;
According to the version numbers of the downstream applications deployed by each target deployment device, determining the flow proportions of the downstream applications of different versions deployed in the target deployment devices;
according to the flow proportion, calling different versions of downstream applications deployed in the target deployment devices to perform service processing to obtain service processing results;
and determining a test result of a version to be distributed of the downstream application deployed in the target deployment devices according to the service processing result, wherein the test result is used for indicating whether the version to be distributed of the downstream application meets a distribution condition.
2. The method of claim 1, wherein the determining the traffic proportion of the downstream applications of different versions deployed by the plurality of target deployment devices according to the version numbers of the downstream applications deployed by each deployment device comprises:
acquiring at least one routing rule, wherein each routing rule comprises a plurality of version numbers of the downstream application and a flow ratio corresponding to each version number;
determining a target routing rule in the at least one routing rule;
and according to the version numbers of the downstream applications deployed by the target deployment devices, determining the flow proportions of the downstream applications of different versions deployed by the target deployment devices in the target routing rule.
3. The method of claim 2, wherein determining the target routing rule among the at least one routing rule comprises:
determining the priority of each routing rule;
and determining the routing rule with the highest priority among the at least one routing rule as the target routing rule.
4. A method according to claim 2 or 3, characterized in that,
the determining version numbers of the downstream application deployed in the plurality of target deployment devices includes:
acquiring version numbers of the downstream application deployed in a plurality of deployment devices in a plurality of machine rooms from a registry database;
and determining the version numbers of the downstream application deployed in the target deployment devices in the target machine room from the version numbers of the downstream application deployed in the deployment devices in the machine rooms.
5. The method of claim 4, wherein if the test result of the to-be-published version of the downstream application deployed in the first deployment device of the plurality of target deployment devices indicates that the to-be-published version of the downstream application deployed in the first deployment device does not satisfy the publication condition, the method further comprises:
And sending indication information to the first deployment device, wherein the indication information is used for indicating the first deployment device to execute version rollback operation on the downstream application, rollback a version to be issued of the downstream application deployed in the first target deployment device to a previous version of the version to be issued, and the previous version of the downstream application is used for providing service for the service processing request.
6. A method for publishing a distributed application, the method being applied to an operation and maintenance server, the method comprising:
displaying a route rule creating interface;
creating a routing rule in the routing rule creating interface, wherein the routing rule comprises a plurality of version numbers of the target application and flow proportions corresponding to each version number;
determining a service server corresponding to the routing rule;
and sending the routing rule to the service server.
7. The method of claim 6, wherein the routing rule further comprises a caller parameter;
the determining the service server corresponding to the routing rule comprises the following steps:
determining a preset application for calling the target application according to the calling party parameters, wherein the calling party parameters comprise the application type of the preset application;
And determining the deployment equipment where the preset application is located as a service server corresponding to the routing rule.
8. The method of claim 7, wherein the step of determining the position of the probe is performed,
if the type of the target application is gateway application, the preset application is any one of non-gateway application in a component where the target application is located, gateway application of the component where the target application is located and appointed application;
if the type of the target application is a non-gateway application, the preset application is a non-gateway application in a component where the target application is located or a gateway application of a component where the target application is located.
9. A distribution device for a distributed application, comprising:
the acquisition module is used for acquiring a service processing request corresponding to the target service through the current application;
the first determining module is used for determining the downstream application to be called by the current application according to the target service;
the second determining module is used for determining version numbers of the downstream application deployed in the target deployment devices, wherein the version numbers comprise version numbers to be released;
the third determining module is used for determining the flow ratio of the downstream applications of different versions deployed in the target deployment devices according to the version numbers of the downstream applications deployed by each target deployment device;
The processing module is used for calling different versions of downstream applications deployed in the target deployment devices to perform service processing according to the flow proportion to obtain service processing results;
and the fourth determining module is used for determining a test result of a version to be distributed of the downstream application deployed in the plurality of target deployment devices according to the service processing result, wherein the test result is used for indicating whether the version to be distributed of the downstream application meets a distribution condition.
10. A distribution device for a distributed application, comprising:
the display module is used for displaying the interface for creating the routing rule;
the creating module is used for creating a routing rule in the routing rule creating interface, wherein the routing rule comprises a plurality of equipment types and flow proportions corresponding to each equipment type by the target application;
the determining module is used for determining a service server corresponding to the routing rule;
and the sending module is used for sending the routing rule to the service server.
11. An electronic device, comprising: a processor, and a memory communicatively coupled to the processor;
the memory stores computer-executable instructions;
The processor executes the computer-executable instructions stored in the memory to implement the method of publishing a distributed application as claimed in any one of claims 1 to 5 or the method of publishing a distributed application as claimed in any one of claims 6 to 8.
12. A computer readable storage medium, wherein computer executable instructions are stored in the computer readable storage medium, which when executed by a processor is adapted to implement the method of publishing a distributed application according to any one of claims 1-5 or the method of publishing a distributed application according to any one of claims 6-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310630029.7A CN116647603A (en) | 2023-05-30 | 2023-05-30 | Distribution method, device, equipment and storage medium for distributed application |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310630029.7A CN116647603A (en) | 2023-05-30 | 2023-05-30 | Distribution method, device, equipment and storage medium for distributed application |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116647603A true CN116647603A (en) | 2023-08-25 |
Family
ID=87639496
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310630029.7A Pending CN116647603A (en) | 2023-05-30 | 2023-05-30 | Distribution method, device, equipment and storage medium for distributed application |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116647603A (en) |
-
2023
- 2023-05-30 CN CN202310630029.7A patent/CN116647603A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108900353B (en) | Fault warning method and terminal equipment | |
| CN111970198A (en) | Service routing method, device, electronic equipment and medium | |
| CN111901249A (en) | Service current limiting method, device, equipment and storage medium | |
| CN114189525B (en) | Service request method and device and electronic equipment | |
| CN110427775A (en) | Data query authority control method and device | |
| CN110602056A (en) | Service parameter transmission method and device | |
| CN108664343B (en) | State calling method and device for micro-service | |
| Griffeth et al. | Extending telecommunications systems: The feature-interaction problem | |
| CN111367694B (en) | Event processing method, server and computer storage medium | |
| CN108280024B (en) | Flow distribution strategy testing method and device and electronic equipment | |
| CN113312675A (en) | Attribute checking method and device, electronic equipment and storage medium | |
| CN112804099A (en) | Parameter batch configuration method and device, computer equipment and readable storage medium | |
| CN116647603A (en) | Distribution method, device, equipment and storage medium for distributed application | |
| US9323509B2 (en) | Method and system for automated process distribution | |
| CN116633856A (en) | Service processing method, device, equipment and storage medium | |
| CN111475226B (en) | Electronic device, micro-service calling method, and computer-readable storage medium | |
| CN113590352A (en) | Data calling method, device, equipment and readable storage medium | |
| CN116643787A (en) | Distribution method, device, equipment and storage medium for distributed application | |
| CN114356516A (en) | Resource scheduling method, related device, equipment and storage medium | |
| CN114528074A (en) | Dynamic baffle implementation method, system and equipment based on micro-service architecture | |
| CN112188012A (en) | Method and device for establishing customer service session, electronic equipment and readable storage medium | |
| CN112860398A (en) | Data processing method, device, equipment and medium based on rule engine | |
| CN112837156A (en) | Transaction method and device with fixed execution sequence | |
| CN112350856A (en) | Distributed service sign-off method and equipment | |
| CN112383434A (en) | Interface simulation method and device for network request, electronic equipment and storage medium |
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 |