CN116932004A - Service release method, device, equipment, storage medium and product - Google Patents

Abstract

The disclosure provides a service release method, a device, equipment, a storage medium and a product, relates to the technical field of computers, and particularly relates to the technical field of information flow. The specific implementation scheme is as follows: determining a target instance from a to-be-issued instance list of the service; importing the newly added access traffic into other examples except the target example; responding to the history access flow in the target instance to finish, and issuing an updated instance of the target instance; and restarting the service in response to the update instance publishing being completed. The service release method can effectively avoid flow loss in the target instance before and during the release of the update instance, ensure user experience, ensure stable release of the update instance and improve release efficiency.

Description

Service release method, device, equipment, storage medium and product

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to the field of information flow technologies, and in particular, to a service publishing method, apparatus, device, storage medium, and product.

Background

With the rapid development of the internet, the frequency and complexity of service release are gradually increased, and how to guarantee the stability, reliability and security of the service becomes an increasingly important problem. Canary distribution and red-blue distribution are two common service distribution modes, but both modes can not avoid causing traffic loss in the distribution process.

Disclosure of Invention

The disclosure provides a service release method, a device, equipment, a storage medium and a product, which ensure user experience in the service release process and avoid traffic loss caused by service release.

According to a first aspect of the present disclosure, there is provided a service publishing method, including:

determining a target instance from a to-be-issued instance list of the service;

importing the newly added access flow into other examples except the target example;

responding to the history access flow in the target instance to finish, and issuing an updated instance of the target instance;

in response to the update instance publication completing, the service is restarted.

According to a second aspect of the present disclosure, there is provided a service issuing apparatus including:

a determining module configured to determine a target instance from a list of to-be-published instances of the service;

the flow guiding module is configured to guide the newly added access flow into other examples except the target example;

the issuing module is configured to issue an updated instance of the target instance in response to the completion of the response of the historical access flow in the target instance;

and a restart module configured to restart the service in response to completion of the update instance publication.

According to a third aspect of the present disclosure, there is provided an electronic device comprising:

At least one processor; and

a memory communicatively coupled to the at least one processor; wherein,,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method provided in the first aspect.

According to a fourth aspect of the present disclosure there is provided a non-transitory computer readable storage medium storing computer instructions for causing a computer to perform the method as provided in the first aspect.

According to a fifth aspect of the present disclosure, there is provided a computer program product comprising a computer program which, when executed by a processor, implements the method provided according to the first aspect.

It should be understood that the description in this section is not intended to identify key or critical features of the embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following specification.

Drawings

The drawings are for a better understanding of the present solution and are not to be construed as limiting the present disclosure. Wherein:

FIG. 1 illustrates an exemplary system architecture to which the service distribution method of the present disclosure may be applied;

FIG. 2 illustrates a flow chart of one embodiment of a service distribution method according to the present disclosure;

FIG. 3 illustrates a flow chart of another embodiment of a service distribution method according to the present disclosure;

FIG. 4 illustrates a schematic diagram of one scenario for implementing the service distribution method of the present disclosure;

FIG. 5 illustrates a schematic diagram of one embodiment of a service distribution apparatus according to the present disclosure;

fig. 6 shows a block diagram of an electronic device used to implement the service distribution method of an embodiment of the present disclosure.

Detailed Description

Exemplary embodiments of the present disclosure are described below in conjunction with the accompanying drawings, which include various details of the embodiments of the present disclosure to facilitate understanding, and should be considered as merely exemplary. Accordingly, one of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

It should be noted that, without conflict, the embodiments of the present disclosure and features of the embodiments may be combined with each other. The present disclosure will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.

With the rapid development of the internet, the frequency and complexity of service release are gradually increased, and how to guarantee the stability, reliability and security of the service becomes an increasingly important problem. Canary distribution and red-blue distribution are two common service distribution modes, but have certain limitations.

Canary release refers to deploying a new version of a service to a small number of users in a generation environment, and evaluating the quality of the new version of the service by observing the responses of the users, but the evaluation result of canary release cannot represent the responses of all the users, and cannot realize the rolling upgrade of the service.

The release of red blue refers to running a new version of service simultaneously with an old version of service and evaluating the quality of the new version of service by comparing their performance. However, the red and blue release requires double the investment of computing resources, and the service upgrade cannot be completed in a short time.

The existing release system does not provide a unified gateway to control service flow, or the service directly adopts Nginx to carry out load balancing, so that access requests of each user can be distributed to newly released examples, and different requests of one user can repeatedly and transversely jump between new and old versions of different examples, and unexpected Bug occurs. In addition, because some specific users cannot be conducted with the stream, the access flow of some external users can enter the instance in the new version test, but the instance of the new version may be Bug, so that the user experience is damaged, and the user experience is reduced.

In the prior art, no matter whether the published service has traffic access currently or not and when the current service can import traffic after the publication is successful, traffic loss exists in the publication process because the import of traffic cannot be controlled, and lossless publication cannot be realized.

The service release method is used for controlling the flow before and during the release of the service instance, realizing no perception of online users on the release process of the service, ensuring smooth replacement of new and old services, reducing adverse effects on user experience caused by service release, ensuring user experience and realizing no flow loss during the service release.

Fig. 1 illustrates an exemplary system architecture 100 to which embodiments of the service distribution method or service distribution apparatus of the present disclosure may be applied.

As shown in fig. 1, system architecture 100 may include a terminal device 101, a network 102, and a server 103. The network 102 is used to provide a communication link between the terminal device 101 and the server 103, and may include various connection types, for example, a wired communication link, a wireless communication link, or an optical fiber cable, etc.

A user can interact with the server 103 through the network 102 using the terminal device 101 to receive or transmit information or the like. Various client applications may be installed on the terminal device 101.

The terminal device 101 may be hardware or software. When the terminal device 101 is hardware, it may be a variety of electronic devices including, but not limited to, smartphones, tablets, laptop and desktop computers, and the like. When the terminal apparatus 101 is software, it may be installed in the above-described electronic apparatus. Which may be implemented as a plurality of software or software modules, or as a single software or software module. The present invention is not particularly limited herein.

The server 103 may be hardware or software. When the server 103 is hardware, it may be implemented as a distributed server cluster composed of a plurality of servers, or may be implemented as a single server. When the server 103 is software, it may be implemented as a plurality of software or software modules (for example, to provide distributed services), or may be implemented as a single software or software module. The present invention is not particularly limited herein.

The service distribution method provided by the embodiments of the present disclosure is generally performed by the server 103, and accordingly, the service distribution apparatus is generally provided in the server 103.

It should be noted that the numbers of the terminal device 101, the network 102, and the server 103 in fig. 1 are merely illustrative. There may be any number of terminal devices 101, networks 102, and servers 103, as desired for implementation.

Fig. 2 shows a flow 200 of one embodiment of a service distribution method according to the present disclosure, with reference to fig. 2, comprising the steps of:

step S201, determining a target instance from a list of to-be-distributed instances of the service.

In the embodiment of the present disclosure, an execution body of a service publishing method, for example, a server shown in fig. 1, determines a target instance to be published with a new version from a list of to-be-published instances of a service. Wherein the service is a service to be published.

The target instance may be one instance to be issued with a new version, or may be two or more instances to be issued with a new version synchronously, and the number of target instances may be set according to actual situations, which is not limited herein.

For the examples except the target example in the example list to be issued of the service, the current version of the service still operates in the issuing process of the target example, so that the service can still operate normally in the issuing process, and the access response quality of the service is ensured.

Step S202, the newly added access flow is imported into other examples except the target example.

In the embodiment of the present disclosure, after determining a target instance to be issued, an execution body of a service issuing method, such as a server shown in fig. 1, suspends importing access traffic into the target instance, and imports all the newly added access traffic into other instances except the target instance. Other examples besides the target example include other examples not listed in the list of the to-be-issued examples, and may also include other examples in the list of the to-be-issued examples that are still in line to be issued.

When the execution body imports the new access flow to other examples, the execution body may imports the new access flow to other examples except the target example at random, or imports the new access flow to other examples according to a preset importation sequence rule. When the execution main body imports the newly-increased access flow, the execution main body can importe according to the address of the instance so as to ensure the accuracy of the flow importement and avoid the error importement of the newly-increased access flow into the target instance.

In some optional implementations of embodiments of the present disclosure, importing the newly added access traffic into other instances beyond the target instance includes: acquiring an instance address list of a service; and importing the newly added access traffic into other examples except the target example according to the example address list.

In this implementation manner, the executing body acquires the instance address list of all the instances of the service, and then pauses to import the newly added access traffic into the target instance according to the instance address list, and imports the newly added access traffic into other instances except the target instance, so as to avoid the influence on user experience and instance publishing efficiency caused by the fact that the newly added access traffic cannot be responded in time due to the publishing of the target instance or the Bug is generated during the responding.

According to the implementation mode, the newly-added access flow is accurately imported into other examples except the target example according to the example address list, so that stable release of the target example is guaranteed, the problem that release efficiency is affected due to misleading of the newly-added access flow into the target example is avoided, the response efficiency and accuracy of the newly-added access flow can be improved, user experience is guaranteed, and unnecessary flow loss is avoided.

Step S203, in response to the history access flow in the target instance being completed, the updated instance of the target instance is issued.

In the embodiment of the disclosure, an execution body of the service publishing method, such as a server shown in fig. 1, publishes an updated instance of a target instance under the condition that the historical access traffic in the target instance is all responded, so as to ensure that each access traffic of the target instance is responded, avoid losing traffic in the target instance before the updated instance is published, promote user experience, and simultaneously effectively avoid failure of publishing the target instance caused by still being accessed and ensure the publishing efficiency of the target instance.

In the embodiment of the disclosure, the executing body obtains the historical access traffic response situation in the target instance after determining the target instance and suspending the introduction of the new access traffic to the target instance. When it is determined that the historical access flow in the target instance is all responded, the execution main body issues the updated instance of the target instance, stable issue of the updated instance of the target instance is guaranteed from the two aspects of avoiding newly added access flow and effectively responding to the historical access flow, the issue efficiency is prevented from being influenced due to the fact that the updated instance is accessed in the middle of issue, user experience is guaranteed, and flow loss caused by lossy user experience is avoided.

In step S204, in response to the update instance publishing being completed, the service is restarted.

In the embodiment of the present disclosure, an execution body of the service publishing method, such as the server shown in fig. 1, restarts the service after the update instance is published.

In the embodiment of the disclosure, after the execution body determines that the update instance is released, the service is restarted, so that the successfully released update instance completely replaces the target instance to operate, or the original target instance is still adopted to operate after the release of the update instance fails, thereby effectively ensuring the stable operation of the service and ensuring the user experience.

The update instance publishing completion comprises the publishing progress of the update instance reaching 100%, and can also comprise the completion of the test after the publishing progress reaches 100%.

In some alternative implementations, the executing entity may restart the service after the update instance publication progress reaches 100%. After the service is restarted, the updated instance is tested again. For example, after the test is completed, the execution body may restart the service again, so that the issued update instance or the target instance before the issue runs, and smooth running of the service is ensured.

In some alternative implementations, the executing body may test the updated instance after being released before restarting the service after the release progress of the updated instance reaches 100%. After the test is completed, restarting the service to enable the issued updated instance or the target instance before the issue to run, and ensuring the stable running of the service.

According to the service release method provided by the embodiment of the disclosure, after the target instance to be released is determined, the introduction of the newly-added access flow to the target instance is stopped, and after the historical access flow response of the target instance is completed, the updated instance of the target instance is released again; after the update instance is released, the service is restarted. The method and the system can effectively avoid the access flow which is still unresponsive in the target instance before the release, ensure that the access flow is not newly added in the release process of the updated instance, ensure the stable release of the updated instance, avoid the flow loss before and during the release of the updated instance, ensure that each access flow before the release of the updated instance is responded and ensure the user experience.

In the technical scheme of the disclosure, the acquisition, storage, application and the like of the related personal information of the user (such as the access user of the service) accord with the regulations of related laws and regulations, and the public order is not violated.

Fig. 3 illustrates a flow 300 of one embodiment of a service distribution method according to the present disclosure, with reference to fig. 3, including the steps of:

step S301, determining a target instance from a list of to-be-deployed instances of the service.

In the embodiment of the present disclosure, an execution body of a service publishing method, for example, a server shown in fig. 1, determines a target instance to be published from a list of to-be-published instances of a service.

Step S301 is substantially identical to step S201 in the embodiment shown in fig. 2, and the detailed implementation may refer to the foregoing description of step S201, which is not repeated herein.

Step S302, the newly added access flow is imported into other examples except the target example.

In the embodiment of the present disclosure, an execution body of a service publishing method, such as a server shown in fig. 1, after determining a target instance, imports new access traffic of the service into other instances except the target instance, i.e., pauses importation of the new access traffic into the target instance.

Step S302 is substantially identical to step S202 in the embodiment shown in fig. 2, and the detailed implementation may refer to the foregoing description of step S202, which is not repeated herein.

Step S303, in response to the history access flow in the target instance being completed, the updated instance of the target instance is issued.

In the embodiment of the present disclosure, after suspending the introduction of the new access flow to the target instance, the execution body of the service publishing method, such as the server shown in fig. 1, needs to determine that the historical access flows in the target instance are all responsive, and then publishes the updated instance of the target instance, so as to avoid the flow loss before the publishing of the target instance.

Step S303 is substantially identical to step S203 of the embodiment shown in fig. 2, and the detailed implementation may refer to the foregoing description of step S203, which is not repeated herein.

Step S304, in response to the completion of the update instance release, the test traffic is imported into the update instance.

In the embodiment of the present disclosure, an execution body of a service publishing method, such as a server shown in fig. 1, imports test traffic into an update instance after the update instance is published, and tests the update instance through the test traffic.

In an alternative implementation of the disclosed embodiments, importing test traffic to an update instance includes: acquiring a test flow list of the service; and importing the test traffic to the updated instance according to the test traffic list.

In the embodiment of the present disclosure, an execution body of a service publishing method, such as a server shown in fig. 1, acquires a test traffic list of a service after determining that an update instance is published (a publishing progress reaches 100%), and then imports test traffic to the update instance according to the test traffic list. For other access traffic than the test traffic in the test traffic list, the execution body imports other instances than the updated instance.

The published update instance overlays the original target instance, so the address of the update instance may be the same as the address of the target instance. Illustratively, the executing entity may import test traffic into the updated instance according to the address of the target instance in the instance address list.

In some alternative implementations, the test traffic list may be in the form of a test white list. Illustratively, the test traffic list may include several test subscribers and may also include faithful subscribers to the service.

In the embodiment of the present disclosure, after determining that the release progress of the update instance reaches 100%, the executing body imports a test flow into the update instance, and tests the update instance through the test flow. If the test of the updated instance is successful, the updated instance is successfully issued; if the test of the updated instance fails, the release of the updated instance fails.

The update instance can be considered to be released and completed as long as the update instance completes the test process, whether the test of the update instance succeeds or fails.

In the embodiment of the disclosure, after restarting the service, the execution body directs the test traffic belonging to the test traffic list to the update instance to test the update instance, and verifies the performance such as running stability of the update instance. Meanwhile, the execution main body guides other access flows which do not belong to the test flow list into other examples except the update example, such as the access flow of a new user, so that the access of each non-test flow is stably responded by other examples, the user experience is ensured, the flow loss caused by generating Bug in the test process of the update example is avoided, and the flow loss in the replacement process of the new version and the old version of the target example is greatly reduced.

Step S305 determines the test result of the update instance.

In the embodiment of the present disclosure, an execution body of the service publishing method, such as the server shown in fig. 1, monitors a test procedure of an update instance after importing test traffic to the update instance, and determines a test result of the update instance.

In some optional implementations of embodiments of the present disclosure, determining the test results for the update instance includes: responding to the update instance to run normally under the preset condition, and determining that the update instance is successfully issued; in response to an update instance running exception, the update instance is rolled back, and it is determined that the update instance failed to be published.

In the embodiment of the present disclosure, an execution body of a service publishing method, such as a server shown in fig. 1, determines that an update instance is successfully published when it is determined that the update instance is operating normally under a preset condition, and may perform a general application, for example, may import other access traffic besides a test traffic. If the update instance is determined to run abnormally under the preset condition, the update instance is rolled back to a historical version before release, and the update instance release failure is determined.

The preset condition may include at least one of a preset time condition and a preset time condition.

In some alternative implementations of embodiments of the present disclosure, the preset condition is a preset time condition, e.g., 1 day or 3 days, etc., and may also be a longer (e.g., 10 days) or shorter (e.g., 12 hours) time condition.

Taking the preset time condition as an example that the test duration is 24 hours, the execution main body determines that the update instance runs normally within 24 hours after the test run, and determines that the update instance is successfully issued, namely, the update instance is considered to be capable of running and responding stably when any access is faced. At this time, the execution body determines that the updated instance can be formally put into use, and other access traffic except the test instance list can be imported into the updated instance in the running process.

In some optional implementations of the embodiments of the present disclosure, the preset condition is a preset flow condition. Illustratively, the preset condition may be that the test access traffic continuously responded to by stabilization reaches a preset number of accesses, for example, reaches 2k times or 10k times, etc.

In some alternative implementations, the preset conditions may also include both a preset flow condition and a preset time condition. Illustratively, the preset conditions may be: and under the condition that the preset flow condition is met, the response time of each access does not exceed the preset time. For example, the preset conditions are: the test access flow rate of continuous stable response reaches 1k times, and the response time of each access is not longer than 2s.

In the embodiment of the disclosure, after the execution main body confirms that the update instance runs normally under the preset condition, the update instance is determined to be successfully issued, and the update instance can be put into normal application, so that the influence of Bug on user experience when the update instance responds to non-test traffic is effectively avoided, the user experience is further ensured, and unnecessary traffic loss is avoided. If the update instance operates abnormally under the preset condition, the execution body rolls back the update instance to an old version instance before release, and the old version instance responds to the access traffic after service restarting so as to ensure user experience and avoid traffic loss.

Illustratively, the rolled-back just-on version instance is a historical version instance prior to the update instance being published, such as a target instance prior to the update instance being published.

In some alternative implementations, the executing body acquires the rollback progress of the updated instance in real time after the updated instance is rolled back, and when the instance is rolled back completely, for example, the service is determined to be able to respond stably to the access traffic through the target instance, and if the service is restarted, the service is still operated by the target instance and is not the updated instance, so that the executing body determines that the updated instance fails to issue.

In some optional implementations of the embodiments of the present disclosure, after determining the test result of the update instance, the execution body may further save a release record of the update instance according to the test result. The release record of the update instance may include release time of the update instance, whether the test result is release success or release failure, and the like.

Step S306, restarting the service according to the test result.

In the embodiment of the present disclosure, the execution subject of the service publishing method, such as the server shown in fig. 1, restarts the service according to the test result determined in step S305, to ensure that each instance of the service can stably run.

For example, if the test result is that the test of the updated instance is successful, the service can also stably run after the updated instance is considered to replace the original target instance to run. At this point, the service may be restarted so that the update instance runs in place of the target instance after the restart.

If the test result is that the test of the updated instance fails, the updated instance is considered to be unable to replace the original target instance to operate, the published updated instance is needed to be ignored, the original target instance is still adopted to restart the service, and the stable operation of the service is ensured.

In some optional implementations of the embodiments of the present disclosure, after determining that the update instance is successfully or failed to be issued, the executing body may directly restart the service, or may continue to redefine the target instance to be issued from the to-be-issued instance list of the service, and then execute the issuing according to the above process, until the executing body confirms that the update instance corresponding to each instance in the to-be-issued instance list is issued (may include that part of the instances are failed to be issued, or that all of the instances are successfully issued), and restart the service.

According to the scheme, each target instance in the service instance list to be distributed is distributed in sequence, and tested according to the test flow list, the running condition of each updated instance after distribution is tested, and the service instance is put into normal use after the success of the test is determined; and the method can ensure that unnecessary flow loss does not exist before and after the update example of each target example is released, realize that the service has no flow loss in the gray release and the red and blue release processes, realize the smooth substitution of the update example to the target example, avoid the service unavailability caused by the service release, ensure the use experience of online users in the service release process, and greatly reduce the adverse effect on the users caused by the service release.

In some optional implementations of embodiments of the present disclosure, restarting the service includes: stopping introducing the newly added access traffic to the service; and restarting the service in response to the history access traffic of the service being completed.

In this implementation manner, after determining the test result of the update instance, the execution subject stops introducing the new access flow to the service. Whether the test result of the updated instance is test success or test failure, the execution body stops introducing the newly added access traffic into the service so that the service totally responds to the historical access traffic before restarting, thereby ensuring user experience and avoiding traffic loss.

Wherein, stopping introducing the new access traffic to the service may be by closing all access traffic portals of the service through the gateway so that the service only responds to the existing historical access traffic.

After the execution main body stops introducing the newly added access flow to the service, the response situation of the historical access flow of the service is obtained in real time, and when the historical access flow of the service is completely responded, the service is restarted, so that the condition that the service is not responded and the user experience is reduced and the flow loss is caused due to the fact that the unresponsive access flow exists in the service during restarting can be effectively avoided, the condition that the flow is not lost after the service is restarted after the update instance is released can be ensured, and the user experience is ensured; and restarting the service to enable the successfully issued updated instance or the rolled-back target instance to operate, so that each instance in the service can perform stable response on the access flow, thereby ensuring the stable operation of the service and further ensuring the user experience.

In the embodiment of the disclosure, after determining that the update instance is successfully or failed to be released, the executing body stops introducing the new access flow to the service so as to respond to the existing historical access flow of the service as soon as possible, and after determining that the historical access flow is completely responded, restarts the service so as to normally operate the released update instance or the target instance after rollback, thereby ensuring user access experience and avoiding the reduction of the user experience due to unresponsiveness of access and the loss of flow.

In the embodiment of the present disclosure, after restarting the service, the execution body of the service publishing method may import the access traffic of the service into any instance of the service.

Any example may include any one example, or may include any two or more examples.

In some optional implementations, after determining that the update instance corresponding to each instance in the to-be-issued instance list of the service is issued and operates normally under the preset condition, the executing body determines that each instance that is not issued by the service and each update instance that is issued successfully can perform stable response to any access flow. At this time, the executing host restarts the service, and the access traffic of the service can be imported into any instance of the service.

In the service publishing method of the embodiment of the disclosure, the execution body confirms each instance in the to-be-published instance list of the service, and restarts the service again after each instance is successfully published, so that any access flow can be imported to each instance of the service, the service is not limited by the tested flow list, the red and blue publishing of the service is realized, and no flow loss is ensured in the red and blue publishing process.

According to the service release method provided by the embodiment of the disclosure, after the target instance of the new version instance to be released is determined, the introduction of the new access flow to the target instance is stopped, and after the history access flow response of the target instance is completed, the updated instance of the target instance is released, so that the flow loss caused by the fact that the unresponsive access flow is still in the target instance before release is avoided, the user experience is ensured, and the influence on the release process and the user experience caused by the fact that the new access flow enters the updated instance in the release process can be avoided; and after the update instance is released, the new access flow is stopped to be imported to the service, and after the service is restarted after the historical access flow of the service is ensured to be responded, the historical access flow before the service is restarted is ensured to be responded, the flow loss is avoided, and the user experience is further ensured. Therefore, the scheme can effectively avoid the access flow which is still unresponsive in the target instance before the release, ensure that the access flow is not newly added in the release process of the updated instance, ensure the stable release of the updated instance and avoid the flow loss before and during the release of the updated instance; in addition, the unresponsive historical access traffic before the service is restarted can be avoided, and traffic loss after the update instance is released is effectively avoided. Therefore, the service release method provided by the embodiment of the disclosure can avoid the traffic loss caused by service release from multiple layers, ensure that each access traffic is responded and ensure the user experience.

Fig. 4 shows a schematic diagram of one scenario 400 of a service distribution method of an embodiment of the present disclosure. In scenario 400, the information such as the test traffic list and the instance address list of the service may be configured through the gateway, so that the access traffic of the service may be cut and controlled through the gateway according to the release requirement. Referring to FIG. 4, the following are presented for portions of scene 400:

gateway 410 is a traffic portal for service 450 that may control access traffic for service 450, including allowing access to the service or not allowing access to the service; gateway 510 may also load balance services 540 including distributing newly added access traffic among instances by at least one of preset configuration rules, by existing access traffic for each instance in the service, and by load capacity for each instance.

By way of example, any of the following gateways may generally be employed: nginx, springcloud gateway, spring cloud zuul, etc. In one implementation of the disclosed embodiments, springcloud gateway self-lapping gateways may be employed.

It should be noted that fig. 4 is only an exemplary schematic diagram, and one gateway 410 may control traffic of a plurality of services, not limited to controlling traffic of one service.

Gateway management background 420 is a background service, such as a background server, that performs configuration management on gateway 410. Illustratively, the configuration that may be made to gateway 410 in gateway management background 420 includes: routing manual configuration, service instance traffic configuration, service test traffic list (e.g., whitelist) configuration, etc.

Registry 430 provides the functionality of automatically discovering and registering services 450, and is able to generate a route for proxy services after automatically discovering the services and registering the route for the services at the gateway. Illustratively, the optional registry in the present solution includes any of consule, nacos, zookeeper, which is not limited herein.

The publishing system 440 manages the publishing of at least one service 450, can automatically publish all services and automatically interact with the gateway according to the configuration, and realizes the flow switching in the service publishing process.

According to the service publishing method provided by the present disclosure, the essence of publishing the service 450 is publishing each instance from its list of instances to be published. Accordingly, a list of to-be-published instances of the service 450 and an updated instance corresponding to each instance in the list of to-be-published instances are configured in the publishing system 440. Taking the target instance 451 to be published as an example, the publishing process of the publishing system 440 will be described.

After determining the update instance 451' corresponding to the target instance 451 in the publishing system 440, the execution body notifies the gateway that the old version instance corresponding to the publishing instance is the target instance 451. After receiving this information, gateway 410 stops importing the newly added access traffic to target instance 451, imports all newly added access traffic to other instances 452, and feeds back historical access traffic responses in target instance 451 to publishing system 440. When the publishing system 440 receives information that the historical access traffic in the target instance 451 is all responded to, the update instance 451' is published and the publication progress is sent to the gateway 410.

In some alternative implementations, the gateway 410, upon receiving information that the release progress of the update instance 451' reaches 100%, imports traffic into the update instance 451' according to a pre-configured list of test traffic to test the update instance 451'. The release system 440 monitors the running condition of the update instance 451 'in the test process, when the update instance 451' has abnormal running under the preset condition, the release system 440 rolls back the update instance 451 'to the target instance 451, confirms that the release of the update instance 451' fails, and marks the release record thereof; when the update instance 451 'operates normally under the preset condition, it is confirmed that the update instance 451' is successfully issued and its issue record is marked.

After determining that the update instance 451' is successfully or failed to be issued, the issuing system 440 notifies the gateway to stop introducing the newly added access traffic to the other instances 452, and monitors the response situation of the historical access traffic in the other instances 452; after all historical access traffic in other instances 452 has been responded to, the service 450 is restarted.

After restarting the service 450, the gateway 410 defaults to configuring traffic into the service 450 according to the traffic configuration rules for normal operation, i.e., any access traffic for the service 450 may be imported into any embodiment of the service 450.

As an implementation of the method illustrated in the above figures, fig. 5 shows one embodiment of a service issuing apparatus according to the present disclosure. The service issuing apparatus corresponds to the method embodiment shown in fig. 2, and the apparatus can be applied to various electronic devices.

Referring to fig. 5, the service issuing apparatus 500 includes: a determination module 501, a diversion module 502, a publication module 503, and a restart module 504. Wherein,,

the determining module 501 is configured to determine a target instance from a list of to-be-published instances of a service; the diversion module 502 is configured to import the newly added access traffic into other instances beyond the target instance; the publishing module 503 is configured to publish the updated instance of the target instance in response to the historical access traffic in the target instance being all responsive; the restart module 504 is configured to restart the service in response to the update instance publication completing.

In the service issuing device 500 of the embodiment of the present disclosure, specific processes of the first determining module 501, the first guiding module 502, the issuing module 503 and the restarting module 504 and technical effects thereof may refer to the related descriptions of steps S201 to S204 in the corresponding embodiment of fig. 2, and are not repeated herein.

In some optional implementations of embodiments of the present disclosure, the diversion module 502 is configured to: acquiring an instance address list of a service; and importing the newly added access traffic into other examples except the target example according to the example address list.

In some optional implementations of embodiments of the present disclosure, the restart module includes a test unit, a determination unit, and a restart unit. Wherein the test unit is configured to import test traffic to the update instance in response to completion of the update instance publication; the determining unit is configured to determine a test result of the update instance; the restarting unit is configured to restart the service according to the test result.

In the embodiment of the present disclosure, the specific processes of the test unit, the determination unit and the restarting unit and the technical effects thereof may refer to the related descriptions of steps S304-S306 in the corresponding embodiment of fig. 3, and are not repeated herein.

In some optional implementations of embodiments of the present disclosure, the test unit is further configured to: acquiring a test flow list of the service; and importing the test traffic to the updated instance according to the test traffic list.

In some optional implementations of embodiments of the present disclosure, the determining unit is further configured to: responding to the update instance to run normally under the preset condition, and determining that the update instance is successfully issued; and in response to the abnormal operation of the update instance under the preset condition, rolling back the update instance, and determining that the update instance fails to be released.

In some optional implementations of embodiments of the present disclosure, the restart module is further configured to: stopping introducing the newly added access traffic to the service; and restarting the service in response to the history access traffic of the service being completed.

In some optional implementations of embodiments of the present disclosure, the restart module is further configured to: and in response to successful release of the instances in the to-be-released instance list, importing the access flow of the service into any instance of the service.

According to embodiments of the present disclosure, the present disclosure also provides an electronic device, a readable storage medium and a computer program product.

Fig. 6 illustrates a schematic block diagram of an example electronic device 600 that may be used to implement embodiments of the present disclosure. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the disclosure described and/or claimed herein.

As shown in fig. 6, the apparatus 600 includes a computing unit 601 that can perform various appropriate actions and processes according to a computer program stored in a Read Only Memory (ROM) 602 or a computer program loaded from a storage unit 608 into a Random Access Memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the device 600 may also be stored. The computing unit 601, ROM 602, and RAM 603 are connected to each other by a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.

Various components in the device 600 are connected to the I/O interface 605, including: an input unit 606 such as a keyboard, mouse, etc.; an output unit 607 such as various types of displays, speakers, and the like; a storage unit 608, such as a magnetic disk, optical disk, or the like; and a communication unit 609 such as a network card, modem, wireless communication transceiver, etc. The communication unit 609 allows the device 600 to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunication networks.

The computing unit 601 may be a variety of general and/or special purpose processing components having processing and computing capabilities. Some examples of computing unit 601 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various specialized Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the respective methods and processes described above, such as a service distribution method. For example, in some embodiments, the service distribution method may be implemented as a computer software program tangibly embodied on a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and/or installed onto the device 600 via the ROM 602 and/or the communication unit 609. When the computer program is loaded into the RAM 603 and executed by the computing unit 601, one or more steps of the service distribution method described above may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform the service distribution method in any other suitable way (e.g. by means of firmware).

Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuit systems, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), systems On Chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs, the one or more computer programs may be executed and/or interpreted on a programmable system including at least one programmable processor, which may be a special purpose or general-purpose programmable processor, that may receive data and instructions from, and transmit data and instructions to, a storage system, at least one input device, and at least one output device.

Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the processor or controller, causes the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and pointing device (e.g., a mouse or trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, the response provided to the user may be any form of sensory response (e.g., visual response, auditory response, or tactile response); and input from the user may be received in any form, including acoustic input, speech input, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a background component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such background, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), and the internet.

The computer system may include a client and a server. The client and server are typically remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server may be a cloud server, a server of a distributed system, or a server incorporating a blockchain.

It should be appreciated that various forms of the flows shown above may be used to reorder, add, or delete steps. For example, the steps recited in the present disclosure may be performed in parallel or sequentially or in a different order, provided that the desired results of the technical solutions of the present disclosure are achieved, and are not limited herein.

The above detailed description should not be taken as limiting the scope of the present disclosure. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives are possible, depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present disclosure are intended to be included within the scope of the present disclosure.

Claims (15)

1. A service distribution method, comprising:

determining a target instance from a to-be-issued instance list of the service;

importing the newly added access traffic into other examples except the target example;

responding to the history access flow in the target instance to finish, and issuing an updated instance of the target instance;

and restarting the service in response to the update instance publishing being completed.

2. The method of claim 1, wherein the importing the newly added access traffic into other instances than the target instance comprises:

Acquiring an instance address list of the service;

and importing the newly added access flow into other examples except the target example according to the example address list.

3. The method of claim 1, wherein restarting the service in response to the update instance publication completing comprises:

in response to completion of the update instance publication, importing test traffic to the update instance;

determining a test result of the update instance;

and restarting the service according to the test result.

4. A method according to claim 3, wherein said importing test traffic to said update instance comprises:

acquiring a test flow list of the service;

and importing the test traffic to the updated instance according to the test traffic list.

5. The method of claim 3, wherein the determining the test results for the updated instance comprises:

responding to the update instance to run normally under a preset condition, and determining that the update instance is successfully issued;

and in response to the abnormal operation of the update instance under the preset condition, rolling back the update instance, and determining that the update instance fails to be issued.

6. The method of any of claims 1-5, wherein the restarting the service comprises:

Stopping introducing the newly added access traffic to the service;

and restarting the service in response to the historical access flow of the service being finished.

7. A service issuing apparatus comprising:

a determining module configured to determine a target instance from a list of to-be-published instances of the service;

the flow guiding module is configured to guide the newly added access flow into other examples except the target example;

the issuing module is configured to issue an updated instance of the target instance in response to the completion of the response of the historical access traffic in the target instance;

and a restarting module configured to restart the service in response to completion of the update instance publication.

8. The apparatus of claim 7, wherein the diversion module is configured to:

acquiring an instance address list of the service;

and importing the newly added access flow into other examples except the target example according to the example address list.

9. The apparatus of claim 7, wherein the restart module comprises:

a test unit configured to import test traffic to the update instance in response to completion of the update instance publication;

a determining unit configured to determine a test result of the update instance;

And the restarting unit is configured to restart the service according to the test result.

10. The apparatus of claim 9, wherein the test unit is configured to:

acquiring a test flow list of the service;

and importing the test traffic to the updated instance according to the test traffic list.

11. The apparatus of claim 9, wherein the determining unit is configured to:

responding to the update instance to run normally under a preset condition, and determining that the update instance is successfully issued;

and in response to the abnormal operation of the update instance under the preset condition, rolling back the update instance, and determining that the update instance fails to be issued.

12. The apparatus of any of claims 7-11, wherein the restart module is configured to:

stopping introducing the newly added access traffic to the service;

and restarting the service in response to the historical access flow of the service being finished.

13. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.

14. A non-transitory computer readable storage medium storing computer instructions for causing the computer to perform the method of any one of claims 1-6.

15. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any of claims 1-6.