Distributed application publishing method, device, equipment and storage medium

Abstract

The application provides a distributed application publishing method and device, equipment and a storage medium, which can be used in the field of distribution. The method comprises the following steps: a business server can obtain a business processing request corresponding to a target business through a current application, determine a downstream application to be called by the current application according to the target business, determine the version number of the downstream application deployed by each target deployment device, determine the traffic proportion of the downstream application with different versions deployed in the multiple target deployment devices, call the downstream application with different versions deployed in the multiple target deployment devices for business processing according to the traffic proportion, and obtain a business processing result. According to the business processing result, a test result of the to-be-published version of the downstream application deployed in the multiple target deployment devices is determined, and the test result is used to indicate whether the to-be-published version of the downstream application meets a publishing condition. If yes, the to-be-published version of the downstream application can be published, and the efficiency of publishing the new version of the distributed application is improved.

Description

Technical Field

[0001] This application relates to the field of distributed systems, and more particularly to a method, apparatus, device, and storage medium for publishing distributed applications. Background Technology

[0002] With the popularization of distributed system architecture, more and more enterprises are shifting their application systems from monolithic applications to distributed applications, increasing the complexity of coordinating multiple systems.

[0003] Furthermore, with the rapid development of business, the frequency and number of new version releases of distributed application systems have increased significantly. Currently, new versions of distributed applications can be released using the canary release method. In addition to the existing stable version (old version) of the application, a small-scale deployment of the new version is carried out in the same data center. Some users continue to use the old version, while others start using the new version. If the user feedback on the new version is positive, the scope is gradually expanded until all users are migrated to the new version.

[0004] The above application can be a component-level microservice application. Due to business development, there are situations where multiple component-level microservice applications are deployed on different devices in different data centers. The above canary release method is used to release new versions for each data center, which results in low efficiency of new version release. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for publishing distributed applications, which solves the problem of low efficiency in publishing new versions in related technologies.

[0006] Firstly, this application provides a method for publishing a distributed application, applied to a business server, the method comprising:

[0007] Obtain the business processing request corresponding to the target business through the current application;

[0008] Based on the target business, determine the downstream application to be invoked by the current application;

[0009] Determine the version number of the downstream application deployed on multiple target deployment devices, the version number including the version number to be released;

[0010] Based on the version number of the downstream application deployed on each target deployment device, determine the traffic ratio of different versions of the downstream application deployed on the multiple target deployment devices;

[0011] According to the traffic ratio, different versions of downstream applications deployed in the multiple target deployment devices are invoked for business processing to obtain business processing results;

[0012] Based on the business processing results, the test results of the release versions of the downstream applications deployed in the multiple target deployment devices are determined, and the test results are used to indicate whether the release versions of the downstream applications meet the release conditions.

[0013] Secondly, this application provides a method for deploying a distributed application, applied to an operation and maintenance server, the method comprising:

[0014] Displays the interface for creating routing rules;

[0015] In the Create Routing Rule interface, create a routing rule, which includes multiple version numbers of the target application and the traffic ratio corresponding to each version number;

[0016] Determine the business server corresponding to the routing rule;

[0017] Send the routing rules to the business server.

[0018] Thirdly, this application provides a distributed application publishing apparatus, comprising:

[0019] The acquisition module is used to obtain the business processing request corresponding to the target business through the current application.

[0020] The first determining module is used to determine the downstream application to be invoked by the current application based on the target business.

[0021] The second determining module is used to determine the version number of the downstream application deployed on multiple target deployment devices, the version number including the version number to be released.

[0022] The third determining module is used to determine the traffic ratio of different versions of downstream applications deployed in the multiple target deployment devices based on the version number of the downstream application deployed in each target deployment device.

[0023] The processing module is used to call different versions of downstream applications deployed in the multiple target deployment devices for business processing according to the traffic ratio, and obtain the business processing result;

[0024] The fourth determining module is used to determine the test results of the release version of the downstream application deployed in the plurality of target deployment devices based on the business processing results. The test results are used to indicate whether the release version of the downstream application meets the release conditions.

[0025] Fourthly, this application provides a distributed application publishing apparatus, comprising:

[0026] The display module is used to show the interface for creating routing rules;

[0027] A creation module is used to create routing rules in the creation routing rule interface. The routing rules include multiple device types and the traffic ratio of the target application for each device type.

[0028] The determination module is used to determine the business server corresponding to the routing rule;

[0029] The sending module is used to send the routing rules to the business server.

[0030] Fifthly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0031] The memory stores computer-executed instructions;

[0032] The processor executes computer execution instructions stored in the memory to implement the distributed application deployment method as described in the first or second aspect.

[0033] In a sixth aspect, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, are used to implement the method for publishing a distributed application as described in the first or second aspect.

[0034] In a seventh aspect, this application provides a computer program product, including a computer program, which, when executed by a computer, is used to implement the method for publishing the distributed application described in the first or second aspect.

[0035] The distributed application publishing method, apparatus, device, and storage medium provided in this application allow a business server to obtain business processing requests corresponding to target businesses through the current application. Then, based on the target business, it determines the downstream applications to be called by the current application and the version numbers of these downstream applications across multiple target deployment devices. Based on the version numbers of the downstream applications deployed on each target deployment device, it determines the traffic ratio of different versions of downstream applications deployed across multiple target deployment devices. Then, according to the traffic ratio, it calls different versions of the downstream applications deployed across multiple target deployment devices for business processing, obtaining the business processing results. Based on the business processing results, it determines the test results of the downstream applications to be published across multiple target deployment devices. The test results indicate whether the downstream applications to be published meet the publishing conditions. If the publishing conditions are met, the downstream applications to be published can be published. This application can meet the needs of new version publishing in scenarios where multiple microservice applications of component-level applications are deployed on different devices in different data centers, improving the efficiency of new version publishing for distributed applications. Attached Figure Description

[0036] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0037] Figure 1 This is a schematic diagram illustrating one application scenario to which this application applies;

[0038] Figure 2 A schematic diagram illustrating calls between applications as exemplified in this application;

[0039] Figure 3 This is a flowchart illustrating a method for publishing a distributed application, as provided in Embodiment 1 of this application.

[0040] Figure 4 This is a flowchart illustrating another method for publishing a distributed application provided in Embodiment 2 of this application;

[0041] Figure 5 Signaling flowchart for another distributed application publishing method provided in Embodiment 3 of this application;

[0042] Figure 6 This is a schematic diagram of an interface for creating routing rules, as exemplified in this application.

[0043] Figure 7 A schematic diagram of the structure of a distributed application publishing device provided in Embodiment 4 of this application;

[0044] Figure 8 A schematic diagram of the structure of a distributed application publishing device provided in Embodiment 5 of this application;

[0045] Figure 9 This is a schematic diagram of the structure of an electronic device provided in Embodiment Six of this application.

[0046] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0047] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0048] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0049] It should be noted that the distributed application publishing method, apparatus, device and storage medium provided in this application can be used in the distributed field, or in any field other than the distributed field. The application field of the distributed application publishing method, apparatus, device and storage medium provided in this application is not limited.

[0050] With the rapid growth of users and the fast development of business, the iteration cycle for developing and launching new versions is getting faster and faster. On the one hand, it is required to provide users with stable services, and on the other hand, it is required to carry out rapid business iteration.

[0051] Currently, a canary release method can be used to release new versions of distributed applications. In addition to the existing stable version (old version) of the application, a small-scale new version of the application is deployed in the same data center. Some users continue to use the old version, while others start using the new version. If the users' feedback on the new version is good, the scope is gradually expanded until all users are migrated to the new version.

[0052] The above application can be a component-level microservice application. Due to business development, there are situations where multiple microservice applications of the component application are deployed on different devices in different data centers. The above canary release method is used to release new versions for each data center, which makes the release efficiency of new versions low.

[0053] Therefore, this application provides a method for publishing distributed applications. After the business server obtains the business processing request of the target business through the current application, it can call different versions of the downstream applications deployed on multiple deployment devices to perform business processing according to the traffic ratio of different versions of the downstream applications deployed on multiple deployment devices, obtain the business processing result, and determine whether the version of the downstream application to be published meets the publishing conditions based on the business processing result. If it does, it is determined that it can be published. This method can meet the needs of new version publishing in scenarios where multiple microservice applications of component-level applications are deployed on different devices in different data centers, thus improving the efficiency of new version publishing of distributed applications.

[0054] To more clearly explain this application, the following is a description of the terms used in the embodiments of this application:

[0055] An application can typically be composed of multiple components, which can be called a component-level application. Each component represents a different functional module (which can be referred to as a business in this application). Each component includes multiple microservice applications. For example, an application may include functional modules such as "deposit business" and "credit card business". The "deposit business" also includes multiple microservice applications that provide services to users.

[0056] Gateway application: This can be an application used for communication between components. That is, calls between components need to be made through a gateway application.

[0057] Non-gateway applications: These refer to applications within components, i.e., ordinary microservice applications.

[0058] To facilitate understanding, the following will be combined with... Figure 1 The examples illustrate the application scenarios to which the embodiments of this application are applicable.

[0059] Figure 1 Please refer to the diagram illustrating one application scenario to which this application applies. Figure 1 It includes: maintenance server 101, business server A102, business server B103, and business server C104. Maintenance server 101, business server A102, business server B103, and business server C104 can communicate with each other via the Internet.

[0060] For example, the current application is deployed in business server A102, version 1 of the downstream application of the current application is deployed in business server B103, and the unreleased version of the downstream application of the current application is deployed in business server C104. There is a calling relationship between the current application and the downstream application. For example, the application calling order is the current application and the downstream application, that is, the current application calls the downstream application.

[0061] After receiving the business request corresponding to the target business, business server A102 can determine the downstream application to be invoked by the current application, and then determine the version number of the downstream application deployed on multiple target deployment devices in the target data center. The invocation is then performed based on the traffic ratio corresponding to that version number. Business servers B103 and C104 belong to the same data center.

[0062] Operations server 101 can be used to establish routing rules for target applications. Operations server 101 can send routing rules to the business server where the preset application resides.

[0063] 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 can send routing rules to the non-gateway application in the component where the target application resides, or to the application on the deployment device where the gateway in that component resides. Therefore, the current application can be either a non-gateway application in the component where the target application resides, or it can be a gateway application in the component where the target application resides. Then, the operation and maintenance server 101 can send routing rules to the deployment device (i.e., business server A102) where the current application resides.

[0064] If the aforementioned downstream application is the target application, and the target application is a gateway application, the operations and maintenance server 101 can send routing rules to any of the following deployment devices: non-gateway applications within the component containing the target application, gateway applications within that component, or the specified application. Therefore, the aforementioned current application can be any of the following: non-gateway applications within the component containing the target application, gateway applications within that component, or the specified application. Thus, the operations and maintenance server 101 can send routing rules to the deployment device (i.e., business server A102) where the current application resides.

[0065] It is understood that there can be multiple business servers A102, B103, and C104, which are not shown in the figure.

[0066] For example, to more clearly describe the calls between applications, please refer to... Figure 2 , Figure 2 This section explains the calls between applications. The current application in Component 2 can receive business processing requests initiated by the caller in Component 1. Then, according to the routing rules sent by the operations and maintenance platform, business server A102 can route the traffic of the business processing requests to different versions of downstream application A according to different traffic ratios. Figure 2 In this context, x% of traffic corresponds to one link, and y% of traffic corresponds to another link. Figure 2 Taking the link corresponding to x% of the traffic in the diagram as an example, after the x% traffic of the business processing request is routed to the downstream application A of the version to be released, the downstream application A of the version to be released will route the x% traffic of the business processing request to the downstream application of A in this link. Here, for the sake of simplicity, only the downstream application A and the downstream application of A are shown as examples. In actual applications, there may be other downstream applications of A, which are not shown in the diagram.

[0067] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0068] Figure 3 This is a flowchart illustrating a distributed application deployment method provided in Embodiment 1 of this application. This method can be executed by a business server or by a business processing device located within the business server. This device can be a chip, a chip module, or an integrated development environment (IDE), etc. The following example uses a business server. Figure 3 The method includes the following steps:

[0069] S301. Obtain the business processing request corresponding to the target business through the current application.

[0070] The business server can obtain the business processing request corresponding to the target business through the current application. The number of business processing requests can be one or more.

[0071] In one possible implementation, the caller initiating the business processing request can be an application in an upstream component of the component where the current application resides.

[0072] In another possible implementation, the caller initiating the business processing request can be the upstream application of the current application. It can be understood that the upstream application of the current application belongs to the same component as the current application.

[0073] S302. Based on the target business, determine the downstream applications that the current application needs to call.

[0074] After receiving a business processing request, the business server can determine the downstream application to be called by the current application based on the target business.

[0075] For example, the business server can obtain application information for multiple applications of the target business from the registry center database. This application information may include the application's identifier and the identifiers of each application's downstream applications. The registry center database contains multiple applications for multiple businesses. After obtaining the application information for the target business's multiple applications, the business server can determine the downstream application to be invoked by the current application among these applications.

[0076] S303. Determine the version number of the downstream application deployed on multiple target deployment devices in the target data center. The version number includes the version number of the version to be released.

[0077] After determining the downstream application to be invoked by the current application, the business server can determine the version number of the downstream application deployed on multiple target deployment devices in the target data center.

[0078] Among them, multiple target deployment devices belong to target deployment units in target data centers. In this application embodiment, a server is the smallest unit of application deployment, a physical unit includes multiple servers, and a data center may include multiple physical units.

[0079] S304. Based on the version number of the downstream application deployed on each target deployment device, determine the traffic ratio of different versions of downstream applications deployed on multiple target deployment devices.

[0080] In this embodiment, different versions of downstream applications correspond to different traffic ratios. The version number of the downstream application deployed on each target deployment device is determined. The business server can determine the traffic ratio of different versions of downstream applications deployed on multiple target deployment devices based on the version number of the downstream application deployed on each target deployment device.

[0081] S305. Based on the traffic ratio, call different versions of downstream applications deployed on multiple target deployment devices to perform business processing and obtain the business processing results.

[0082] The business server can call different versions of downstream applications deployed on multiple target deployment devices to perform business processing according to the traffic ratio, and obtain the business processing results.

[0083] For example, the business server can route traffic for business processing requests to a target deployment device that includes version number V1 in its device information at a rate of x%, and can route traffic for business processing requests to a target deployment device that includes version number V2 in its device information at a rate of y%. Here, the sum of x% and y% is 100%, for example, x can be 20 and y can be 80, where V2 is the version number of the downstream application's release version.

[0084] S306. Based on the business processing results, determine the test results of the release versions of downstream applications deployed in multiple target deployment devices. The test results are used to indicate whether the release versions of downstream applications meet the release conditions.

[0085] After determining the business processing result, the business server can determine the test results of the downstream application versions to be released in multiple target deployment devices based on the business processing result. The test results are used to indicate whether the downstream application versions to be released meet the release conditions.

[0086] For example, if the business processing result indicates that the processing result of the downstream application's release version indicates that the processing of the business processing request is abnormal, that is, the normal processing result of the business processing request is not obtained (which can be understood as the release version of the downstream application failing to respond to the business processing request normally), then it can be determined that the test result of the release version of the downstream application is abnormal. Correspondingly, the test result indicates that the release version of the downstream application does not meet the release conditions.

[0087] For example, if the business processing result indicates that the processing result of the downstream application's release version indicates that the business processing request was processed normally, that is, the processing result includes the normal processing result of the business processing request (such as a certain response value), then it can be determined that the test result of the release version of the downstream application is normal. Correspondingly, the test result indicates that the release version of the downstream application meets the release conditions.

[0088] In this embodiment, the business server can obtain the business processing request corresponding to the target business through the current application, then determine the downstream application to be called by the current application based on the target business, and determine the version number of the downstream application in multiple target deployment devices. Based on the version number of the downstream application deployed on each target deployment device, the traffic ratio of different versions of the downstream application deployed in multiple target deployment devices is determined. Then, according to the traffic ratio, different versions of the downstream application deployed in multiple target deployment devices are called for business processing to obtain the business processing result. Based on the business processing result, the test result of the version to be released of the downstream application deployed in multiple target deployment devices is determined. The test result is used to indicate whether the version to be released of the downstream application meets the release conditions. If the release conditions are met, the version to be released of the downstream application can be released. This application can meet the needs of new version release in scenarios where multiple microservice applications of component-level applications are deployed on different devices in different data centers, improving the efficiency of new version release of distributed applications.

[0089] The following describes another method for publishing a distributed application provided in this application through Example 2.

[0090] Figure 4 This is a flowchart illustrating another distributed application deployment method provided in Embodiment 2 of this application. This method can be executed by a business server or by a distributed application deployment device installed in the business server. This device can be a chip, a chip module, an IDE, etc. The following example uses a business server, which deploys a preset entry application for the target grayscale environment. (Refer to...) Figure 4 The method includes the following steps:

[0091] S401. Obtain the business processing request corresponding to the target business through the current application.

[0092] S402. Based on the target business, determine the downstream applications that the current application needs to call.

[0093] For a detailed description of S401 and S402, please refer to the above embodiments, which will not be repeated here.

[0094] S403. Determine the version number of the downstream application deployed on multiple target deployment devices in the target data center. The version number includes the version number of the version to be released.

[0095] In one possible implementation, the business server can obtain the version numbers of multiple deployment devices across multiple data centers for the downstream application from the registry center database. Specifically, the business server retrieves device information for multiple deployment devices of the downstream application in multiple physical units from the registry center database, and each device information may include the version number of the downstream application deployed thereon.

[0096] In one possible implementation, the business server can obtain device information of multiple deployed devices of downstream applications in multiple physical units from the registry center database, and then determine the target physical unit from the multiple physical units according to the identifier of the target physical unit in the target routing rule, and then determine the target deployment device from the deployed devices in the target physical unit.

[0097] It is understandable that multiple physical units can belong to the same data center or to different data centers.

[0098] S404. Obtain at least one routing rule, each routing rule including multiple version numbers of downstream applications and the traffic ratio corresponding to each version number.

[0099] The business server can obtain at least one routing rule.

[0100] In one possible implementation, the business server can store at least one routing rule, which is sent by the operations server. The routing rule includes multiple version numbers of downstream applications and the traffic proportion corresponding to each version number.

[0101] S405. In at least one routing rule, determine the target routing rule.

[0102] The business server stores at least one routing rule, and the business server can determine the target routing rule from at least one routing rule.

[0103] In one possible implementation, the business server can determine the priority of at least one routing rule. Specifically, each routing rule includes a priority value, for example, the priority value is represented by a number, with smaller values ​​indicating higher priority. The business server can then use the highest-priority routing rule from the at least one routing rule as the target routing rule.

[0104] S406. Based on the version numbers of downstream applications deployed on multiple target deployment devices, determine the traffic ratio of downstream applications on multiple target deployment devices in the target routing rules.

[0105] After determining the target routing rules, the business server can determine the traffic ratio of the downstream application on multiple target deployment devices based on the multiple version numbers of the downstream application in the target routing rules and the traffic ratio corresponding to each version number, according to the version number of the downstream version deployed on each target deployment device.

[0106] For example, the target routing rule includes two versions of the downstream application: V1 and V2. The traffic proportion corresponding to V1 is 20%, and the traffic proportion corresponding to V2 is 80%. For instance, there are 10 target deployment devices: a1, a2, a3, a4, a5, a6, a7, a8, a9, and a10. Among them, 4 target deployment devices (a1, a2, a3, a4) deploy the downstream application version V1, and 6 target deployment devices (a5, a6, a7, a8, a9, a10) deploy the downstream application version V2. Then, the business server can determine that the traffic proportion corresponding to these 4 target deployment devices (a1, a2, a3, a4) is 20%, and the traffic proportion corresponding to these 6 target deployment devices (a5, a6, a7, a8, a9, a10) is 80%.

[0107] S407. Based on the traffic ratio, call different versions of downstream applications deployed on multiple target deployment devices to perform business processing and obtain the business processing results.

[0108] Once the traffic ratio is determined, the business server can call different versions of downstream applications deployed on multiple target deployment devices to perform business processing and obtain the business processing results.

[0109] Taking the example in S406, the business server can route 20% of the traffic of the business processing request to the above 4 target deployment devices (a1, a2, a3, a4), and at the same time route 80% of the traffic of the business processing request to the above 6 target deployment devices (a5, a6, a7, a8, a9, a10).

[0110] In one possible implementation, if the test results of the version to be released of the downstream application deployed in the first deployment device among multiple target deployment devices indicate that the version to be released of the downstream application deployed in the first deployment device does not meet the release conditions, the business server can send an indication message to the first deployment device where the downstream application is located. The indication message is used to instruct the first deployment device to perform a version rollback operation on the downstream application, rolling back the version to be released of the downstream application to the previous version. The previous version of the downstream application is used to provide services for business processing requests, which can avoid the downstream application from encountering anomalies and interrupting services.

[0111] In this embodiment, the business server can obtain the business processing request corresponding to the target business through the current application, and then determine the downstream application to be called by the current application based on the target business, and determine the version number of the downstream application in multiple target deployment devices. Then, it obtains at least one routing rule, and within that routing rule, determines the target routing rule. Based on the device type of each target deployment device, it determines the traffic ratio of different versions of downstream applications deployed in multiple target deployment devices in the target routing rule. Then, according to the traffic ratio, it calls different versions of the downstream applications deployed in multiple target deployment devices for business processing, obtaining the business processing result. Based on the business processing result, it determines the test result of the release version of the downstream applications deployed in multiple target deployment devices. The test result is used to indicate whether the release version of the downstream applications meets the release conditions. If the release conditions are met, the release version of the downstream applications can be released. This application can meet the needs of new version releases in scenarios where multiple microservice applications of component-level applications are deployed on different devices in different data centers, improving the efficiency of new version releases for distributed applications.

[0112] The following describes another method for publishing a distributed application provided in Embodiment 3 of this application. Specifically, the interaction between the operation and maintenance server and the business server will be described.

[0113] Figure 5 The signaling flowchart for another distributed application publishing method provided in Embodiment 3 of this application is shown in the reference diagram. Figure 5 The method includes the following steps:

[0114] S501, the operation and maintenance server displays the interface for creating routing rules.

[0115] The operations and maintenance administrator can click "Create New Routing Rule" on the corresponding interface to be redirected to the routing rule creation page.

[0116] On the S502 maintenance server, create routing rules in the routing rule creation interface.

[0117] Operations administrators can create routing rules through the routing rule creation interface on the operations server. The routing rules include multiple version numbers of downstream applications and the traffic ratio corresponding to each version number.

[0118] S503, the operation and maintenance server determines the business server corresponding to the routing rule.

[0119] In one possible implementation, the routing rule may also include a caller parameter, that is, the operation and maintenance server can determine the preset application of the target application based on the caller parameter, and then determine the deployment device where the preset application is located as the business server corresponding to the routing rule. The caller parameter includes the application type of the preset application.

[0120] Specifically, if the target application is a gateway application, the default application can be any one of the following: a non-gateway application within the component containing the target application, a gateway application within the component containing the target application, or a specified application. In other words, if the target application is a gateway application, routing rules can be sent to the deployment device containing any one of the following: all non-gateway applications within the component containing the target application, the gateway application within the component containing the target application, or any specified application.

[0121] If the target application is a non-gateway application, the default application is either a non-gateway application within the component containing the target application or a gateway application within the component containing the target application. In other words, if the target application is a non-gateway application, routing rules can be sent to the deployment device where either the non-gateway application within the component containing the target application or the gateway application within the component containing the target application is located.

[0122] Specifically, preset tags can be used to identify all non-gateway applications in the component where the target application is located, the gateway application in the component where the target application is located, and a specified application, and the devices where all non-gateway applications in the component where the target application is located, the gateway application in the component where the target application is located, and the specified application are located are devices in the specified physical unit.

[0123] For example, such as Figure 6 As shown, Figure 6 This is a schematic diagram of the interface for creating routing rules. The application type of the preset application in the caller parameters can be a component, an application, or a custom application. Each application type includes a matching relationship and a tag value. The matching relationship can be any one of equal to, not equal to, contain, or not contain.

[0124] For the option with the application type "component", the matching relationship can be "equal to", and the tag value can be the name of the component.

[0125] For the option with the application type "application", the matching relationship can be "equal to", and the tag value can be the name of the application.

[0126] For the option with the application type "custom application", the matching relationship can be any of the following: equal to, not equal to, contain, or not contain. The tag value can be a preset tag value, such as tag1. That is, applications that are equal to, not equal to, contain, or do not contain tag1 in the application information are custom applications. It can be understood that a custom application is the application specified above.

[0127] For example, if the application type in the routing rule is "component" and the tag value can be set to the component's name 1, with the matching relationship being equal to, then the default application is all non-gateway applications with the name 1.

[0128] For example, if the application type in the routing rule is "application", the tag value can be set to "application name 2", and the matching relationship is "equal to", then the default application is the application with the application name "name 2".

[0129] For example, if the application type in the routing rule is a custom application, since the application is a specified application, the tag value can be a preset tag value, such as tag1. The matching relationship is not equal to. So, for example, if the application information of a certain application includes tag2 and tag3, and tag2 and tag3 are not equal to tag1, that is, tag1 does not exist in the application information, then it can be determined that the application is a preset application.

[0130] exist Figure 6 In addition, routing rules can also include the rule name, the rule's availability status (available or unavailable), and priority.

[0131] In one possible implementation, the routing rules may also include application information of the target application, which includes the name of the component where the target application resides, the application name of the target application, and the identifier of the physical unit where the target application resides. Figure 6 The destination parameter in the URL is the application information of the target application. The corresponding traffic ratio can be determined based on the version number of the target application deployed on the device where it is located. Figure 6 The V2 version in the document can be a version yet to be released.

[0132] by Figure 6 For example, if the version number of the target application in the device information of the deployment device where the target application is located is V1, then the traffic ratio corresponding to that device is 80%. If the version number of the target application in the device information of the deployment device where the target application is located is V2, then the traffic ratio corresponding to that device is 20%. For details on calling the target application according to the traffic ratio, please refer to the above embodiment two, which will not be repeated here. The downstream application in embodiment two can be understood as the target application in this embodiment.

[0133] It's understandable that when operations and maintenance personnel create routing rules through the operations and maintenance server, they can set corresponding traffic ratios based on the version number deployed on the devices. For example, they can ensure that devices deploying the upcoming version of the downstream application handle fewer business processing requests than devices deploying older versions. It's also understandable that the device information of the target application's deployed devices will include the version number of the application, which can be used to determine the traffic ratio.

[0134] S504. The operation and maintenance server sends the routing rules to the business server corresponding to the routing rules.

[0135] In this embodiment, the operations and maintenance server can create routing rules, determine the corresponding business servers, and send the routing rules to the business servers. This allows the business servers to process application calls for business processing requests according to the routing rules. This application can distribute traffic for business processing requests based on the version number of the downstream application to enable the invocation of the upcoming release version of the downstream application. This application can meet the needs of new version releases in scenarios where multiple microservice applications of component-level applications are deployed on different devices in different data centers, improving the efficiency of new version releases for distributed applications.

[0136] Figure 7 This is a schematic diagram of a distributed application publishing device provided in Embodiment 4 of this application. (Reference) Figure 7 The device 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.

[0137] The acquisition module 701 is used to acquire the business processing request corresponding to the target business through the current application.

[0138] The first determining module 702 is used to determine the downstream application to be called by the current application based on the target business.

[0139] The second determining module 703 is used to determine the version number of the downstream application deployed on multiple target deployment devices in the target data center, including the version number to be released.

[0140] The third determining module 704 is used to determine the traffic ratio of different versions of downstream applications deployed on multiple target deployment devices based on the version number of the downstream application deployed on each target deployment device.

[0141] The processing module 705 is used to call different versions of downstream applications deployed on multiple target deployment devices for business processing according to the traffic ratio, and obtain the business processing results.

[0142] The fourth determination module 706 is used to determine the test results of the release versions of downstream applications deployed in multiple target deployment devices based on the business processing results. The test results are used to indicate whether the release versions of downstream applications meet the release conditions.

[0143] In one possible implementation, the third determining module 704 is specifically used for:

[0144] Obtain at least one routing rule, each of which includes multiple version numbers of the downstream application and the traffic ratio corresponding to each version number.

[0145] In at least one routing rule, determine the target routing rule.

[0146] Based on the version numbers of downstream applications deployed on multiple target deployment devices, the traffic ratio of different versions of downstream applications deployed on multiple target deployment devices is determined in the target routing rules.

[0147] In one possible implementation, the third determining module 704 is specifically used for:

[0148] Determine the priority of each routing rule.

[0149] The highest priority routing rule among at least one routing rule is determined as the target routing rule.

[0150] In one possible implementation,

[0151] In one possible implementation, the second determining module 703 is specifically used for:

[0152] Retrieve the version number of the downstream application from multiple deployment devices in multiple data centers from the registry center database.

[0153] Determine the version number of the downstream application deployed in the target data center from the version numbers of the multiple deployment devices deployed in multiple data centers.

[0154] In one possible implementation, device 70 also includes a transmitting module.

[0155] The sending module is specifically used for:

[0156] If the test results of the downstream application to be released deployed in the first deployment device among multiple target deployment devices indicate that the downstream application to be released deployed in the first deployment device does not meet the release conditions, an instruction message is sent to the first deployment device. The instruction message is used to instruct the first deployment device to perform a version rollback operation on the downstream application, and roll back the downstream application to be released deployed in the first target deployment device to the previous version of the to be released version. The previous version of the downstream application is used to provide services for business processing requests.

[0157] The apparatus in this embodiment can be used to execute the technical solutions of the above method embodiments. The specific implementation methods and technical effects are similar, and will not be described again here.

[0158] Figure 8 This is a schematic diagram of a distributed application publishing device provided in Embodiment 5 of this application. (Reference) Figure 8 The device 80 includes: a display module 901, a creation module 902, a determination module 903, and a sending module 904.

[0159] Display module 901 is used to display the interface for creating routing rules.

[0160] The creation module 902 is used to create routing rules in the routing rule creation interface. The routing rules include multiple version numbers of the target application and the traffic ratio corresponding to each version number.

[0161] The determination module 803 is used to determine the business server corresponding to the routing rule.

[0162] The sending module 804 is used to send routing rules to the business server.

[0163] In one possible implementation, the routing rules also include caller parameters.

[0164] Module 803 is specifically used for:

[0165] Based on the caller parameters, determine the preset application for the target application. The caller parameters include the application type of the preset application.

[0166] The deployment device where the preset application is located is identified as the business server corresponding to the routing rule.

[0167] In one possible implementation, if the target application is a gateway application, the default application is any one of the following: a non-gateway application in the component containing the target application, a gateway application in the component containing the target application, or a specified application.

[0168] If the target application is a non-gateway application, the default application is either a non-gateway application within the component containing the target application or a gateway application within the component containing the target application.

[0169] The apparatus in this embodiment can be used to execute the technical solutions of the above method embodiments. The specific implementation methods and technical effects are similar, and will not be described again here.

[0170] Figure 9 This is a schematic diagram of the structure of an electronic device provided in Embodiment Six of this application, as shown below. Figure 9As shown, the electronic device 90 may include at least one processor 901 and a memory 902.

[0171] The memory 902 is used to store programs. Specifically, the program may include program code, which includes computer-executable instructions.

[0172] The memory 902 may include random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device.

[0173] The processor 901 is used to execute computer execution instructions stored in the memory 902 to implement the method described in the foregoing method embodiments. The processor 901 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0174] Optionally, the electronic device 90 may also include a communication interface 903. In specific implementations, if the communication interface 903, memory 902, and processor 901 are implemented independently, they can be interconnected via a bus to complete communication. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not imply that there is only one bus or one type of bus.

[0175] Optionally, in a specific implementation, if the communication interface 903, memory 902, and processor 901 are integrated on a single chip, then the communication interface 903, memory 902, and processor 901 can communicate through an internal interface.

[0176] Electronic devices 90 can be chips, chip modules, IDEs, servers, etc.

[0177] The electronic device in this embodiment can be used to execute the technical solutions of the above method embodiments. The specific implementation methods and technical effects are similar, and will not be repeated here.

[0178] Embodiment 7 of this application provides a computer-readable storage medium, which may include various media capable of storing computer-executable instructions, such as USB flash drives, portable hard drives, read-only memory (ROM), RAM, disks, or optical discs. Specifically, the computer-readable storage medium stores computer-executable instructions, which, when executed by a computer, cause the technical solution shown in the above method embodiment to be executed. The specific implementation method and technical effect are similar, and will not be repeated here.

[0179] This application provides a computer program product in embodiment eight, which includes a computer program. When the computer program is executed by a computer, the technical solution shown in the above method embodiment is executed. The specific implementation method and technical effect are similar, and will not be repeated here.

[0180] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0181] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method of publishing a distributed application, the method comprising: The method applied to a business server comprises: obtaining a business processing request corresponding to a target business through a current application; obtaining application information of a plurality of applications of the target business from a registration center database according to the target business, and determining a downstream application to be called by the current application among the plurality of applications; determining a version number of the downstream application deployed in a plurality of target deployment devices in a target machine room, the version number comprising a version number of a to-be-released version; determining a traffic proportion of different versions of the downstream application deployed in the plurality of target deployment devices according to the version number of the downstream application deployed in each target deployment device; calling different versions of the downstream application deployed in the plurality of target deployment devices according to the traffic proportion to perform business processing, and obtaining a business processing result; determining a test result of the to-be-released version of the downstream application deployed in the plurality of target deployment devices according to the business processing result, the test result being used to indicate whether the to-be-released version of the downstream application meets a release condition; the determining of the traffic proportion of different versions of the downstream application deployed in the plurality of target deployment devices according to the version number of the downstream application deployed in each target deployment device comprises: obtaining at least one routing rule, each routing rule comprising a plurality of version numbers of the downstream application and a traffic proportion corresponding to each version number; the routing rule is created by an operation and maintenance server in a routing rule creation interface, a preset application calling a target application is determined according to a caller parameter, the caller parameter comprises an application type of the preset application, a deployment device where the preset application is located is determined as a business server corresponding to the routing rule, and the routing rule is sent to the business server; determining a priority of each routing rule; determining a target routing rule with the highest priority among the at least one routing rule; determining the traffic proportion of different versions of the downstream application deployed in the plurality of target deployment devices in the target routing rule according to the version number of the downstream application deployed in the plurality of target deployment devices; if the test result of the to-be-released version of the downstream application deployed in a first deployment device among the plurality of target deployment devices indicates that the to-be-released version of the downstream application deployed in the first deployment device does not meet the release condition, the method further comprises: sending indication information to the first deployment device, the indication information being used to instruct the first deployment device to perform a version rollback operation on the downstream application, and to roll back the to-be-released version of the downstream application deployed in the first deployment device to a previous version of the to-be-released version, the previous version of the downstream application being used to provide services for the business processing request.

2. The method of claim 1, wherein: the determining of the version number of the downstream application deployed in the plurality of target deployment devices comprises: obtaining the version number of the downstream application deployed in a plurality of deployment devices in a plurality of machine rooms from the registration center database. Determine the version number of the downstream application deployed in the target deployment device in the target machine room from the version numbers of the downstream application deployed in the plurality of deployment devices in the plurality of machine rooms.

3. A method of publishing a distributed application, the method comprising: The method applied to an operation and maintenance server comprises: Display a route rule creation interface; Create a route rule in the route rule creation interface, wherein the route rule comprises a plurality of version numbers of target applications and a traffic proportion corresponding to each version number; Determine a service server corresponding to the route rule; Send the route rule to the service server, so that the service server acquires a service processing request corresponding to a target service through a current application, acquires application information of a plurality of applications of the target service from a registration center database according to the target service, determines a downstream application to be invoked in the plurality of applications, determines a version number of the downstream application deployed in a plurality of target deployment devices in a target machine room, the version number comprising a version number of a to-be-released version, determines a priority of each acquired route rule, determines a target route rule with the highest priority in the at least one route rule, determines a traffic proportion of different versions of the downstream application deployed by the plurality of target deployment devices in the target route rule according to the version number of the downstream application deployed by the plurality of target deployment devices, performs service processing on different versions of the downstream application deployed in the plurality of target deployment devices according to the traffic proportion, acquires a service processing result, determines a test result of the to-be-released version of the downstream application deployed in the plurality of target deployment devices according to the service processing result, the test result being used to indicate whether the to-be-released version of the downstream application meets a release condition, if the test result of the to-be-released version of the downstream application deployed in a first deployment device in the plurality of target deployment devices indicates that the to-be-released version of the downstream application deployed in the first deployment device does not meet the release condition, sends indication information to the first deployment device, the indication information being used to instruct the first deployment device to perform a version rollback operation on the downstream application, and roll back the to-be-released version of the downstream application deployed in the first deployment device to a previous version of the to-be-released version, the previous version of the downstream application being used to provide services for the service processing request; The route rule further comprises a caller parameter; and the determination of the service server corresponding to the route rule comprises: Determine a preset application invoking the target application according to the caller parameter, the caller parameter comprising an application type of the preset application; Determine a deployment device where the preset application is located as the service server corresponding to the route rule.

4. The method of claim 3, wherein: 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 the component where the target application is located, and a specified 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 the component where the target application is located.

5. An apparatus for publishing a distributed application, the apparatus comprising: Comprise: An acquisition module, configured to acquire, by a current application, a service processing request corresponding to a target service; A first determination module, configured to acquire, according to the target service, application information of a plurality of applications of the target service from a registration center database, and determine a downstream application to be invoked by the current application from the plurality of applications; A second determination module, configured to determine a version number of the downstream application deployed in a plurality of target deployment devices, the version number comprising a version number to be released; A third determination module, configured to determine, according to the version number of the downstream application deployed by each target deployment device, a traffic proportion of different versions of the downstream application deployed in the plurality of target deployment devices; A processing module, configured to invoke different versions of the downstream application deployed in the plurality of target deployment devices according to the traffic proportion to perform service processing, and obtain a service processing result; A fourth determination module, configured to determine, according to the service processing result, a test result of a version to be released of the downstream application deployed in the plurality of target deployment devices, the test result being used to indicate whether the version to be released of the downstream application meets a release condition; The third determination module is specifically configured to: acquire at least one routing rule, each routing rule comprising a plurality of version numbers of the downstream application and a traffic proportion corresponding to each version number; the routing rule is created by an operation and maintenance server on a routing rule creation interface, a preset application invoking a target application is determined according to a calling party parameter, the calling party parameter comprises an application type of the preset application, a deployment device where the preset application is located is determined as a service server corresponding to the routing rule, and the routing rule is sent to the service server; determine a priority of each routing rule; determine, from the at least one routing rule, a routing rule with the highest priority as a target routing rule; determine, according to the version number of the downstream application deployed by the plurality of target deployment devices, the traffic proportion of different versions of the downstream application deployed in the plurality of target deployment devices in the target routing rule; The apparatus further comprises a sending module. The sending module is specifically configured to: if the test result of the version to be released of the downstream application deployed in a first deployment device of the plurality of target deployment devices indicates that the version to be released of the downstream application deployed in the first deployment device does not meet the release condition, send, to the first deployment device, indication information indicating that the first deployment device performs a version rollback operation on the downstream application, and rolls back the version to be released of the downstream application deployed in the first deployment device to a previous version of the version to be released, the previous version of the downstream application being used to provide services for the service processing request.

6. An apparatus for publishing a distributed application, the apparatus comprising: Comprise: A display module, configured to display a routing rule creation interface; The creating module is configured to create a routing rule in the creating routing rule interface, wherein the routing rule comprises a plurality of device types and a traffic proportion of a target application corresponding to each device type. The determining module is configured to determine a service server corresponding to the routing rule. The sending module is configured to send the routing rule to the service server, so that the service server acquires a service processing request corresponding to a target service through a current application, acquires application information of a plurality of applications of the target service from a registration center database according to the target service, determines a downstream application to be called by the current application from the plurality of applications, determines a version number of the downstream application deployed in a plurality of target deployment devices in a target machine room, the version number comprising a version number of a to-be-released version, determines a priority of each routing rule acquired, and determines a routing rule with the highest priority in the at least one routing rule as a target routing rule; according to the version number of the downstream application deployed by the plurality of target deployment devices, determines a traffic proportion of different versions of the downstream application deployed by the plurality of target deployment devices in the target routing rule, calls different versions of the downstream application deployed in the plurality of target deployment devices according to the traffic proportion to perform service processing, and obtains a service processing result; according to the service processing result, determines a test result of a to-be-released version of the downstream application deployed in the plurality of target deployment devices, the test result being used to indicate whether the to-be-released version of the downstream application meets a release condition; if the test result of the to-be-released version of the downstream application deployed in a first deployment device in the plurality of target deployment devices indicates that the to-be-released version of the downstream application deployed in the first deployment device does not meet the release condition, sends indication information to the first deployment device, the indication information being used to instruct the first deployment device to perform a version rollback operation on the downstream application, and roll back the to-be-released version of the downstream application deployed in the first deployment device to a previous version of the to-be-released version, the previous version of the downstream application being used to provide a service for the service processing request. The routing rule further comprises a calling party parameter; and the determining module is specifically configured to: determine a preset application calling the target application according to the calling party parameter, the calling party parameter comprising an application type of the preset application; and determine a deployment device on which the preset application is located as the service server corresponding to the routing rule.

7. An electronic device, comprising: The method comprises: a processor and a memory connected to the processor in communication; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to implement the distributed application release method of claim 1 or 2, or the distributed application release method of claim 3 or 4.

8. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the distributed application release method of claim 1 or 2, or the distributed application release method of claim 3 or 4.

Images