Service calling method and device, electronic equipment, storage medium and program product

Abstract

The embodiment of the invention provides a service calling method and device, electronic equipment, a storage medium and a program product, and the service calling method comprises the steps that first service instances in a first instance set are deleted, and the first service instances are service instances in a current limiting state in a preset service set; if a calling request for a second service initiated by a first service is detected, a second instance set belonging to the second service is determined, and the first service and the second service are different services in a preset service set; deleting service instances which are the same as the first instance set in the second instance set to obtain a target instance set; and determining a to-be-called target instance in the target instance set, and responding to the calling request based on the target instance. In this way, mistaken calling of the deleted service instance caused by perception lag can be avoided.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a service calling method, device, electronic device, storage medium and program product. Background Art

[0002] With the development of electronic technology, the application of microservice systems has become more and more extensive. Microservice systems can have multiple services, and each service can call each other. Each service has one or more instances. Considering that the data processing capacity of each instance is limited, the parallel processing capacity of the service can be improved by increasing the number of instances. However, as the number of instances increases, the management difficulty of the microservice system increases. Summary of the invention

[0003] The embodiments of the present application provide a service calling method, device, electronic device, storage medium and program product, which can avoid erroneous calling of deleted service instances due to perception lag.

[0004] In a first aspect, an embodiment of the present application provides a service calling method, including:

[0005] Deleting a first service instance in a first instance set, where the first service instance is a service instance in a current-limited state among services in a preset service set;

[0006] If a call request for a second service initiated by a first service is detected, a second instance set belonging to the second service is determined, and the first service and the second service are different services in the preset service set;

[0007] Deleting the same service instances as those in the first instance set in the second instance set to obtain a target instance set;

[0008] A target instance to be called is determined in the target instance set, and the calling request is responded to based on the target instance.

[0009] In a second aspect, an embodiment of the present application provides a service calling device, including:

[0010] A deleting unit, configured to delete a first service instance in a first instance set, wherein the first service instance is a service instance in a current limiting state among services in a preset service set;

[0011] a determining unit, configured to determine, if a call request for a second service initiated by a first service is detected, a second set of instances belonging to the second service, wherein the first service and the second service are different services in the preset service set;

[0012] The deleting unit is further configured to delete the same service instance as the first instance set in the second instance set, to obtain a target instance set;

[0013] The determining unit is further configured to determine a target instance to be called in the target instance set, and respond to the calling request based on the target instance.

[0014] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a processor; and a memory configured to store computer executable instructions, wherein the computer executable instructions, when executed, cause the processor to execute the service calling method as described in the first aspect.

[0015] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium for storing computer-executable instructions, which, when executed by a processor, implement the service calling method as described in the first aspect.

[0016] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the service calling method of the first aspect.

[0017] It can be seen that in an embodiment of the present application, first, the first service instance in the first instance set is deleted, and the first service instance is a service instance in the preset service set that is in a current-limited state; then, if a call request for a second service initiated by the first service is detected, a second instance set belonging to the second service is determined, and the first service and the second service are different services in the preset service set; then, the service instances in the second instance set that are the same as the first instance set are deleted to obtain a target instance set; finally, the target instance to be called is determined in the target instance set, and the call request is responded to based on the target instance. In this way, by deleting the service instances in the preset service set that are in the current limiting state, the service instances that have actually been deleted can be in the current limiting state before deletion. In the process of the first service calling the second service, it is necessary to select a target instance to be called from the service instances belonging to the second service. Considering that there may be a perception lag between the first service and the second service, the second instance set obtained belonging to the second service may include the service instances that have actually been deleted. By deleting the service instances that are the same as the first instance set in the second instance set, the target instance set is obtained, and the first service instances in the second instance set can be excluded, that is, the target instance set does not include any service instances in the current limiting state. In this way, regardless of whether the second instance set includes the service instances that have actually been deleted, by excluding the service instances in the current limiting state, it can be ensured that the target instance set does not include any service instances that have actually been deleted. Furthermore, by determining the target instance to be called in the target instance set, the erroneous call to the deleted service instance caused by the perception lag can be avoided. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative labor.

[0019] Figure 1 A schematic diagram of an implementation environment of a service calling method provided in an embodiment of the present application;

[0020] Figure 2 A processing flow chart of a service calling method provided in an embodiment of the present application;

[0021] Figure 3 A processing flow chart of step-by-step traffic diversion in a service calling method provided in an embodiment of the present application;

[0022] Figure 4 A data flow diagram of another service calling method provided in an embodiment of the present application;

[0023] Figure 5 A schematic diagram of a service calling device provided in an embodiment of the present application;

[0024] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to enable those skilled in the art to better understand the technical solutions in the embodiments of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments of the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0026] This specification provides a service calling method embodiment:

[0027] A microservice system can include multiple services, and services can call each other. For example, when using the payment service, the order service can be called to generate the order required for this payment. The payment service sends a call request, and the order service receives the call request. The order service is the target service to be called.

[0028] Each service can have one or more instances. An instance can be thought of as a "copy" of a service.

[0029] For each service, for any request from the outside, when the request is handed over to any one of the multiple instances for processing, the data processing process is exactly the same. On the one hand, the amount of data that each instance can process is limited. For example, an instance can process 100 requests at the same time. Therefore, by increasing the number of instances, the service can process more requests. For example, three instances can process a total of 300 requests at the same time. On the other hand, among the multiple instances running at the same time, if one of them crashes and cannot work, the remaining instances can still work normally.

[0030] When there are multiple services, each service has a lag in knowing whether instances of other services have been deleted, which can easily lead to erroneous calls to deleted instances.

[0031] For example, service 1 includes three instances, of which the third instance is deleted at time point T1. A few tens of seconds after T1, that is, T2, service 2 senses that the third instance of service 1 has been deleted and no longer sends requests to the instance. However, in the meantime, service 2 may have sent multiple requests to the third instance, which will trigger an error.

[0032] Therefore, in order to solve the above problems, an embodiment of the present application provides a service calling method.

[0033] The service calling method provided in one or more embodiments of the present specification may be applicable to an implementation environment of the service calling method, which implementation environment at least includes a server 101 for processing a calling request.

[0034] The server 101 may be a single server, or a server cluster consisting of a plurality of servers, or one or more cloud servers in a cloud computing platform, for processing call requests.

[0035] In this implementation environment, when processing a call request, the server 101 first deletes the first service instance in the first instance set, where the first service instance is a service instance in a preset service set that is in a current-limited state; then, if a call request for a second service initiated by the first service is detected, a second instance set belonging to the second service is determined, where the first service and the second service are different services in the preset service set; then, the service instances in the second instance set that are identical to the first instance set are deleted to obtain a target instance set; finally, the target instance to be called is determined in the target instance set, and the call request is responded to based on the target instance. In this way, by deleting the service instances in the preset service set that are in the current limiting state, the service instances that have actually been deleted can be in the current limiting state before deletion. In the process of the first service calling the second service, it is necessary to select a target instance to be called from the service instances belonging to the second service. Considering that there may be a perception lag between the first service and the second service, the second instance set obtained belonging to the second service may include the service instances that have actually been deleted. By deleting the service instances that are the same as the first instance set in the second instance set, the target instance set is obtained, and the first service instances in the second instance set can be excluded, that is, the target instance set does not include any service instances in the current limiting state. In this way, regardless of whether the second instance set includes the service instances that have actually been deleted, by excluding the service instances in the current limiting state, it can be ensured that the target instance set does not include any service instances that have actually been deleted. Furthermore, by determining the target instance to be called in the target instance set, the erroneous call to the deleted service instance caused by the perception lag can be avoided.

[0036] Figure 2 A processing flow chart of a service calling method provided in an embodiment of the present application. Figure 2 The service calling method provided in this embodiment specifically includes steps S202 to S208.

[0037] Step S202: Delete a first service instance in a first instance set, where the first service instance is a service instance in a current-limited state among services in a preset service set.

[0038] To facilitate understanding of the service calling method provided in this embodiment, basic concepts related to services and service calling are explained below.

[0039] Service call means that in a microservice system, any two services can perceive each other's service address information through the registration center. When one service calls another service, it can directly use the service address information of the other service to access the other service through a direct connection without going through gateway routing. This direct connection method can be called a service-based call method. This direct connection method is suitable for internal networks, will not put pressure on the gateway, and has high communication efficiency.

[0040] Microservices (or microservice architecture) is a cloud-native architecture approach that includes many small, loosely coupled and independently deployable components or services in a single application. These services usually have their own technology stack, including databases and data management models; communicate with each other through a REST API (Representational State Transfer Application Programming Interface), event streams, and message brokers; and are organized according to business capabilities, with service demarcation lines usually called bounded contexts.

[0041] The characteristic of microservices is that the code is easier to update, new features or functions can be added directly without updating the entire application, and the team can use different technology stacks and different programming languages ​​for different components. Components can be expanded independently of each other, thus reducing the waste and cost associated with having to expand the entire application.

[0042] The service address information includes but is not limited to an IP (Internet Protocol) address, a port number, etc. The service address information can be used to determine and access a service corresponding to the service address information.

[0043] The registration center of the microservice system can be used to centrally manage various services in the microservice system.

[0044] Exemplarily, the registration center may be Eureka. Eureka is a service discovery framework, which is a REST (Representational State Transfer)-based service, mainly used to locate middle-layer services to achieve load balancing and middle-layer service failover.

[0045] A microservice system can include multiple services. For a service in a microservice system, if the service needs to initiate a call to another service during its operation, the other service receiving the call is the upstream service of the service initiating the call, and the service initiating the call is the downstream service of the other service receiving the call. "Upstream" and "downstream" are relative concepts, which can reflect the call direction when there is a call relationship between two services.

[0046] For example, in the process of using the payment service to make this payment, the order service can be called to generate the order required for this payment. The payment service sends a call request and the order service receives the call request. The order service is the upstream service that accepts the call, and the payment service is the downstream service that initiates the call.

[0047] A service instance is a specific service at runtime. It is a physical or virtual running entity of a service logic that can process requests from other services or clients and provide corresponding service functions. Each service can have one or more service instances at runtime. A service instance can be regarded as a "copy" of a service, and they work together to handle load, improve availability and fault tolerance.

[0048] For each service, for any request received by the service, when the request is handed over to any service instance among multiple service instances for processing, the data processing process is exactly the same. On the one hand, the amount of data that each service instance can process is limited. For example, a service instance can process 100 requests at the same time. By increasing the number of service instances, the service can process more requests. For example, when the service has three service instances during operation, the three service instances can process a total of 300 requests at the same time. On the other hand, among the multiple service instances running at the same time, if one of them crashes and cannot work, the remaining service instances can still work normally, thus ensuring that the service will not stop running easily.

[0049] Exemplarily, the process of service calling is as follows: a service instance of service 1 sends a calling request to a service instance of service 2, and the service instance of service 2 returns response data to the service instance of service 1.

[0050] Specifically in this embodiment, the preset service set may include one or more services, where each "service" may be a service in the microservice system. Each service included in the preset service set may be centrally managed by the registration center of the microservice system. Each service in the preset service set may include one or more service instances.

[0051] Before executing step S202, a first instance set may be obtained.

[0052] The first instance set consists of first service instances in a current limiting state.

[0053] The first instance set may include one or more first service instances, wherein each first service instance belongs to a service in the preset service set, and each first service instance is in a current limiting state.

[0054] For each service in the preset service set, the service may include one or more service instances in the flow-limited state, or may not include a service instance in the flow-limited state.

[0055] For example, the preset service set includes service 1, service 2, and service 3. Service 1 includes service instance a1, service instance a2, and service instance a3. Service 2 includes service instance b1 and service instance b2. Service 3 includes service instance c1 and service instance c2. Among them, service instance a1 and service instance b1 are in the current limiting state, and service instance a2, service instance a3, service instance b2, service instance c1, and service instance c2 are in the non-current limiting state.

[0056] The first instance set includes: service instance a1 and service instance b1.

[0057] The first instance set may be stored in a preset storage area, which may be a persistent storage area or a non-persistent temporary storage area.

[0058] The ordinal numbers such as "first" and "second" appearing in this specification are used to distinguish different technical features and have no actual meaning and will not be elaborated below.

[0059] Current limiting means limiting the flow rate, which can be understood as the number of requests pushed to the first service instance. The first service instance is in a current limiting state, which means that no request will be pushed to the first service instance, or the number of requests pushed to the first service instance is less than or equal to the preset request number threshold.

[0060] For example, service 1 includes service instance 1, service instance 2, and service instance 3. Among them, service instance 1, service instance 2, and service instance 3 are all in a non-current-limited state. When other services other than service 1 call service 1, 150 requests are sent to service 1 at the same time. These 150 requests will be pushed to each service instance of service 1. Then, service instance 1 processes 50 requests, service instance 2 processes 50 requests, and service instance 3 processes 50 requests.

[0061] After the flow control operation is performed on service instance 1, service instance 1 is the first service instance in the flow control state, and service instance 2 and service instance 3 are both in the non-flow control state. In the process of other services other than service 1 calling service 1, 150 requests are sent to service 1 at the same time. These 150 requests will be pushed to each service instance of service 1. Then service instance 1 processes 0 requests, service instance 2 processes 75 requests, and service instance 3 processes 75 requests.

[0062] Alternatively, the preset request quantity threshold is 10. After the flow control operation is performed on service instance 1, service instance 1 is the first service instance in the flow control state, and service instance 2 and service instance 3 are both in the non-flow control state. In the process of other services other than service 1 calling service 1, 150 requests are sent to service 1 at the same time. The 150 requests will be pushed to each service instance of service 1. Then service instance 1 processes 10 requests, service instance 2 processes 70 requests, and service instance 3 processes 70 requests.

[0063] In a specific implementation, the first instance set is updated in the following manner: after detecting a flow limiting operation for a service instance of any service in a preset service set, adding the service instance of the flow limiting operation to the first instance set; or, after detecting a flow recovery operation for any first service instance in the first instance set, deleting the first service instance of the flow recovery operation from the first instance set.

[0064] The current limiting operation can be a flow switching operation. In microservices, flow switching mainly refers to switching requests from one microservice instance to another microservice instance. This usually occurs in scenarios such as service upgrades, failover, or traffic scheduling. For example, when a microservice instance fails, the request flow can be switched to other healthy instances; or when performing a service upgrade, some requests can be switched to the new version of the instance to achieve a smooth upgrade. Flow switching involves technologies such as service governance and service orchestration, and it is necessary to ensure data consistency, request continuity, and service availability during the flow switching process.

[0065] After a service instance is switched, no more requests are passed to the service instance.

[0066] A current limiting operation may also be a flow control operation, which may be used to reduce the number of requests delivered to a service instance targeted by the flow control operation.

[0067] For example, originally a total of 100 requests were passed to a service instance. After the flow control operation was performed on the service instance, the 100 requests were sampled and processed according to the preset sampling ratio of 10%, and 10 requests were obtained. Then, the 10 requests were passed to the service instance, and the remaining 90 requests were evenly distributed to the service instances of the same service in a non-flow-limited state.

[0068] Alternatively, service 1 has three service instances: service instance A, service instance B, and service instance C. Originally, when 300 requests were received, each service instance processed 100 requests. After the flow control operation is performed on service instance C, the allocation ratio changes, so that after the allocation, service instance A processes 140 requests, service instance B processes 140 requests, and service instance C processes 20 requests.

[0069] After detecting a current limiting operation on a service instance of any service in the preset service set, the service instance subjected to the current limiting operation may be determined as a first service instance and added to the first instance set.

[0070] After detecting a traffic recovery operation for any first service instance in the first instance set, the first service instance targeted by the traffic recovery operation is deleted from the first instance set.

[0071] The flow recovery operation may be to cancel the flow switching operation or to cancel the flow control operation. For canceling the flow switching operation, refer to the corresponding description of the flow switching operation, and for canceling the flow control operation, refer to the corresponding description of the flow control operation.

[0072] After the undoing of the flow switching operation is performed on one or more first service instances in the first instance set, the one or more first service instances can normally receive and process requests. Here, “normal” can refer to the traffic before the flow switching.

[0073] For example, service 1 has three service instances: service instance A, service instance B, and service instance C. Originally, when 300 requests were received, each service instance processed 100 requests. After the flow switching operation was performed on service instance C, the allocation ratio changed, so that after the allocation, service instance A processed 250 requests, service instance B processed 250 requests, and service instance C processed 0 requests. After the flow switching operation was canceled on service instance C, when 300 requests were received, each service instance processed 100 requests.

[0074] After the flow control cancellation operation is performed on one or more first service instances in the first instance set, the one or more first service instances can receive and process requests normally. Here, "normal" can refer to the flow before flow control.

[0075] For example, service 1 has three service instances: service instance A, service instance B, and service instance C. Originally, when 300 requests were received, each service instance processed 100 requests. After the flow control operation was performed on service instance C, the allocation ratio changed, so that after the allocation, service instance A processed 140 requests, service instance B processed 140 requests, and service instance C processed 20 requests. After the flow control operation was revoked on service instance C, when 300 requests were received, each service instance processed 100 requests.

[0076] After the traffic recovery operation is performed on the service instance C, the state of the service instance C is switched from the current limiting state to the non-current limiting state, and the service instance C can be deleted from the first instance set.

[0077] By adding the service instance of the flow limiting operation to the first instance set after detecting the flow limiting operation for the service instance of any service in the preset service set; or, after detecting the flow recovery operation for any first service instance in the first instance set, deleting the first service instance targeted by the flow recovery operation from the first instance set, it can be achieved that, at any point in time, all service instances in the preset service set that are in the flow limiting state belong to the first instance set, and all service instances in the preset service set that are in the non-flow limiting state do not belong to the first instance set.

[0078] In specific implementation, the data management component of the preset storage area can execute the addition of the service instance of the flow limiting operation to the first instance set, or the data management component can execute the deletion of the first service instance targeted by the flow recovery operation from the first instance set. Each service in the microservice system can detect the change of the first instance set after the data management component executes the addition operation or the deletion operation. Furthermore, each service can read the real-time first instance set from the preset storage area, thereby realizing real-time perception of the service instance in the flow limiting state.

[0079] The aforementioned obtaining of the first instance set may be, when it is detected that the first instance set has changed, obtaining the changed first instance set.

[0080] Detecting whether the first instance set has changed may include detecting whether the number of instances of the first instance set has changed. If the number of instances has changed, it indicates that the first instance set has changed; if the number of instances remains unchanged, it indicates that the first instance set remains unchanged.

[0081] For example, the number of instances of the first instance set is K1. When it is detected that K1 is changed to K2, it can be determined that a change in the first instance set is detected. K1 and K2 are two integers greater than or equal to 0 with different values.

[0082] Detecting whether the first instance set has changed may also be detecting whether an operation event for the first instance set has occurred. If an operation event is detected, it indicates that the first instance set has changed; if no operation event is detected, it indicates that the first instance set remains unchanged. The operation event may be one or more of the following: a data insertion event, a data deletion event, a data modification event, and the like.

[0083] For example, an event is detected at time point T1, and the event is a data deletion event for the first instance set. It can be determined that a change in the first instance set is detected.

[0084] Another way to detect whether the first instance set has changed is to detect whether a traffic restriction operation or a traffic recovery operation is performed on any service instance. If a traffic restriction operation or a traffic recovery operation is detected, it means that the first instance set has changed; if no traffic restriction operation or traffic recovery operation is detected, it means that the first instance set remains unchanged.

[0085] For example, when it is detected that a traffic restriction operation is currently being performed on service instance 1, it can be determined that a change in the first instance set is detected.

[0086] The various methods listed above for detecting whether the first instance set has changed are merely exemplary. For the service calling method provided in the embodiments of the present application, any detection method that can be used to determine whether the first instance set has changed can be used.

[0087] In specific implementation, detecting whether the first set of instances has changed can be performed by an SDK (Software Development Kit) or other components with detection capabilities. In a microservice system, each instance of each service can have a corresponding SDK. SDK can be a collection of development tools used by some software engineers to build application software for a specific software package, software framework, hardware platform, operating system, etc.

[0088] Acquiring the changed first instance set may be reading the changed first instance set from a preset storage area. The changed first instance set may include identification information of each first service instance. Acquiring the changed first instance set refers to acquiring an identification set including one or more identification information, each identification information in the identification set representing a first service instance.

[0089] Acquiring the changed first instance set may also be reading a data update record, and performing data update processing on the changed first instance set acquired last time according to the data update record to obtain the changed first instance set this time.

[0090] The data update record may include: identification information and update method. The data update record may also include: identification information, update method and update content. The update method may be insert, delete, modify, etc. The update content may include feature data or description text of the first service instance to be inserted.

[0091] For example, the first instance set undergoes a first change at time point T1, a second change at time point T2, and a third change at time point T3. Time point T1 is before time point T2, and time point T2 is before time point T3.

[0092] At time point T1, the changed first instance set is obtained: identifier 001 of first service instance 1, identifier 002 of first service instance 2, and identifier 003 of first service instance 3.

[0093] At time point T2, a data update record is obtained: inserting the first service instance 4. Data update processing is performed on the first instance set after the last change obtained according to the data update record, and the first instance set after this change is obtained: the identifier 001 of the first service instance 1, the identifier 002 of the first service instance 2, the identifier 003 of the first service instance 3, and the identifier 004 of the first service instance 4.

[0094] At time point T3, the data update record is obtained: the first service instance 2 is deleted. According to the data update record, the data of the first instance set after the last change obtained is updated to obtain the first instance set after this change: the identifier 001 of the first service instance 1, the identifier 003 of the first service instance 3, and the identifier 004 of the first service instance 4.

[0095] By acquiring the changed first instance set when a change in the first instance set is detected, real-time perception of the first service instance in the current limiting state can be achieved.

[0096] After obtaining the first instance set, one or more first service instances therein may be deleted.

[0097] For example, the microservice system includes service 1, service 2, and service 3. Service 1 has service instances 101, 102, and 103; service 2 has service instances 201 and 202; and service 3 has service instance 301. The first instance set includes two first service instances, namely, service instance 102 and service instance 201. The service instance 102 belongs to service 1, and the service instance 201 belongs to service 2. Delete service instance 102.

[0098] The first service instance may be deleted by obtaining the heartbeat status information of each service instance of each service in the microservice system according to a preset time period, and if the heartbeat status information of the same service instance is a preset heartbeat status for a preset number of consecutive times, the first service instance is deleted.

[0099] The heartbeat status information can reflect whether the first service instance is operating normally. When the first service instance is operating normally, heartbeat feedback information can be sent to the registration center regularly, and the registration center can determine the heartbeat status information of the first service instance based on the heartbeat feedback information. In addition, the normal operation here has nothing to do with whether the flow is limited. Even if the first service instance is in the flow-limited state, as long as the first service instance can operate normally, the heartbeat feedback information can be sent to the registration center in a timely manner.

[0100] For example, the preset heartbeat state may be an unhealthy state.

[0101] The first service instance sends a heartbeat feedback message to the registration center every 10 seconds.

[0102] For the registration center, if the first service instance sends heartbeat feedback information on time, it can be determined that the heartbeat status information of the first service instance is in a healthy state; if the first service instance fails to send heartbeat feedback information on time once, it can be determined that the heartbeat status information of the first service instance is changed from a healthy state to an unhealthy state, that is, the heartbeat status information is in an unhealthy state once; if the first service instance fails to send heartbeat feedback information on time for two consecutive times, it can be determined that the two consecutive heartbeat status information are in an unhealthy state; if the first service instance fails to send heartbeat feedback information on time for three consecutive times, it can be determined that the three consecutive heartbeat status information are in an unhealthy state, and the first service instance can be deregistered.

[0103] The first service instance may be deleted by receiving a deletion instruction, where the deletion instruction carries an instance identifier of the first service instance, and deleting the first service instance according to the instance identifier.

[0104] The above implementation process of deleting the first service instance is merely exemplary, and the deletion of the first service instance may be triggered manually, or may be triggered when a pre-configured deletion condition is detected, and so on.

[0105] In a microservice system, for any service, in the life cycle of each service instance of the service:

[0106] First, after establishing a service instance, it needs to be registered with the registration center. After the registration process, other services can perceive that there is a new service instance available by reading data from the registration center.

[0107] During the registration process, the service instance sends its own instance information to the registration center.

[0108] Exemplarily, the instance information may include service address information for accessing the service instance, may include an instance identifier, and may include a running status of the service instance.

[0109] The instance identifier is used to determine the unique corresponding service instance. The running state can be one of multiple preset states, such as current limiting state, healthy state, etc.

[0110] Then, the service instance runs for a period of time. During the operation of the service instance, other services can access the service instance. Specifically, other services can send call requests to the service instance, and the service instance can return response data to the other services that sent the call requests after receiving and processing the call requests.

[0111] Finally, the service instance is deleted. Specifically, the container running the service instance can be deleted. After the service instance is deleted, the registration center is notified to delete the instance information of the service instance.

[0112] It should be noted that although a service instance will immediately notify the registry to delete its own instance information after being deleted, there may be a time delay in the process of other services determining whether a service instance is accessible by reading data from the registry. In other words, one service's perception of the deletion of another service instance is delayed.

[0113] For example, service 1 reads data from the registration center every 30 seconds, and the read data includes a set of registered service instances. If a service instance is in the set of service instances, the service instance is accessible to service 1.

[0114] Service instance A of service 2 is deleted at time point T1. Service 2 immediately notifies the registration center to delete the instance information of service instance A after time point T1. However, at time point T1, service 1 is 15 seconds away from the last time it reads data from the registration center, and 15 seconds away from the next time it reads data from the registration center. Therefore, within 15 seconds before the next data read, service 1 cannot perceive that service instance A has been deregistered, and service 1 may still send one or more requests to service instance A.

[0115] For another example, the preset service set includes service 1, service 2, and service 3.

[0116] Service 1 has instance 1, instance 2, and instance 3; service 2 has instance 4 and instance 5; service 3 has instance 6 and instance 7. Instance 1 and instance 4 are in a current limiting state. The first instance set includes: instance 1 and instance 4.

[0117] After deleting instance 1, because instance 1 belongs to service 1, service 1 can immediately know that instance 1 has been deleted, but service 2 and service 3 are lagged in their perception of instance 1. That is, although instance 1 has been deleted, in the perception of service 2 and service 3, service 1 still includes: instance 1, instance 2 and instance 3, and it may take some time to perceive the deletion of instance 1. Similarly, after deleting instance 4, service 1 and service 3 are lagged in their perception of the deletion of instance 4.

[0118] In a specific implementation, deleting the first service instance may include deleting a container running the first service instance in the microservice system and notifying a registration center to delete instance information of the first service instance.

[0119] It should be noted that, on the one hand, the first instance set obtained is essentially a set composed of identification information, and the update of the identification information may lag behind the deletion of the first service instance. On the other hand, the first instance set is obtained first and then the first service instance is deleted. Even if the deletion of the first service instance triggers the update of the identification information, it affects the first instance set stored in the preset storage area, rather than the first instance set obtained before executing step S202. Combining the above two aspects, it can be seen that deleting the first service instance will not change the first instance set obtained before executing step S202.

[0120] For example, when a change in the first instance set is detected at time point T1, service 1 obtains the first instance set from the preset storage area: 001, 002, 003. The first service instance represented by 001 is deleted at time point T2, and time point T2 is located after time point T1. At time point T3, the changed first instance set in the preset storage area is updated to: 002, 003, and time point T3 is located after time point T2. However, at time point T3, the first instance set obtained by service 1 remains unchanged, and the first instance set includes: 001, 002, 003.

[0121] By deleting the service instances in the preset service set that are in the current limiting state, the service instances that have actually been deleted can be in the current limiting state before deletion. This is conducive to excluding the service instances that have actually been deleted but not discovered due to perception lag by excluding the first service instance in the current limiting state in the subsequent steps.

[0122] Step S204: if a call request for a second service initiated by the first service is detected, a second instance set belonging to the second service is determined, and the first service and the second service are different services in a preset service set.

[0123] If a call request for a second service initiated by the first service is detected, the second instance set belonging to the second service is determined, and the second instance set belonging to the second service can be obtained locally in the first service; the second instance set stored locally in the first service is updated according to a preset time period.

[0124] The preset service set may include multiple services, wherein the first service and the second service are two different services in the preset service set.

[0125] The first service is a request sender that actively initiates a call request, and the second service is a request receiver that receives the call request.

[0126] It should be noted that in the specific implementation process of the first service calling the second service, the first service needs to send a call request to a service instance of the second service and receive response information for the call request returned by the service instance.

[0127] In the case where the first service is known, the second service may be determined in the following manner: according to the data processing flow preconfigured by the first service, the second service to be called is determined in the preset service set.

[0128] For example, the first service that actively initiates the call is the payment service. In the data processing flow pre-configured for the payment service, the order needs to be obtained first before payment processing can be performed on the order. Therefore, during the operation of the payment service, the order service needs to be called, that is, the second service to be called is the order service.

[0129] In the case where the first service is known, a service selection instruction may also be received, the service selection instruction carrying a service identifier, and the second service to be called is determined in the preset service set according to the service identifier.

[0130] If a call request for a second service initiated by the first service is detected, a second instance set belonging to the second service is determined.

[0131] The second set of instances may include one or more service instances belonging to the second service.

[0132] If a call request for a second service initiated by the first service is detected, a second instance set belonging to the second service is determined. The first service may obtain the second instance set of the second service locally. The second instance set may be an identification set composed of identification information, and each identification information in the identification set represents a service instance of the second service.

[0133] The second instance set may include the first service instance, that is, the second instance set includes the service instance in the current limiting state. The second instance set may also not include the first service instance, that is, the second instance set does not include the service instance in the current limiting state.

[0134] It should be noted that the second instance set of the second service obtained by the first service locally may have a perception lag between different services. This is because, in the preset service set, each service can be centrally managed by the registration center, and the second instance set of the second service stored locally by the first service can be obtained from the registration center and updated according to a preset time period. That is, the first service reads data from the registration center once every period of time, rather than reading the latest data from the registration center in real time. This results in that between the time points when the first service reads data from the registration center twice in a row, if an instance of any service other than the first service is deregistered, the first service cannot perceive it immediately. Therefore, the second instance set of the second service obtained by the first service locally from the service may include service instances that have actually been deregistered, or may not include service instances that have actually been deregistered.

[0135] In some implementations, the second set of instances obtained locally in the service may be data that the first service reads in advance from a registration center and stores locally in the service, and the read data includes the second set of instances.

[0136] For example, the first service reads data from the registration center every 30 seconds. At time point T1, the first service reads data from the registration center for the Kth time. At time point T2, the first service reads data from the registration center for the K+1th time. Time point T2 is after time point T1, and the interval between time points T2 and T1 is 30 seconds. K is an integer greater than 0.

[0137] The service instance 1 of the second service is deleted at time point T3, where time point T3 is before time point T2 and after time point T1.

[0138] For the first service, the data read for the Kth time includes a second instance set, which includes service instance 1, and the data read for the K+1th time includes another second instance set, which does not include service instance 1.

[0139] Furthermore, in the time period (T3, T2), service instance 1 has actually been deleted, but there is a lag in the perception of the first service, and the second instance set in the data read for the Kth time is still used to determine which service instance to send the request to. Therefore, the perception lag may lead to an erroneous call to the deleted service instance.

[0140] In the time period (T3, T2), if a call request for the second service initiated by the first service is detected, a second instance set belonging to the second service is determined. The second instance set is the data read for the Kth time locally by the first service. Therefore, the second instance set includes the deleted service instance 1.

[0141] In some other implementations, the second instance set obtained locally in the service may be data read in advance by the first service from a registration center and stored locally in the service, the read data including a data update record for the second instance set of the second service, and based on the data update record, data update processing is performed on the second instance set of the second service read last to obtain the second instance set of the second service read this time.

[0142] If the data update record is a preset null value, it means that the second instance set corresponding to the last read is the same as the second instance set corresponding to the current read, and the second instance set corresponding to the last read is directly used as the second instance set corresponding to the current read.

[0143] If a call request for a second service initiated by the first service is detected, the second instance set belonging to the second service is determined. Alternatively, the instance set of each service in the preset service set stored locally in the first service can be queried based on the service identifier of the second service to obtain the second instance set of the second service.

[0144] Step S208: Delete the service instances in the second instance set that are the same as those in the first instance set, and obtain a target instance set.

[0145] It should be emphasized that the first instance set in this step is the same as the first instance set obtained before executing step S202 , that is, the first instance set is not changed due to executing step S202 .

[0146] For example, before executing step S202, the first instance set obtained includes: instance 1, instance 2 and instance 3. By executing step S202, instance 3 is deleted. The first instance set used in the process of executing step S208 includes: instance 1, instance 2 and instance 3.

[0147] The second instance set may include one or more first service instances, and may also include one or more service instances in a non-current-limited state other than the first service instance. Each service instance in the second instance set belongs to the second service.

[0148] For example, the second instance set includes: service instance 1, service instance 2, and service instance 3. Among them, service instance 1 is the first service instance, service instance 2 and service instance 3 are service instances in a non-current-limited state. And service instance 1, service instance 2, and service instance 3 all belong to the second service.

[0149] The first instance set includes one or more first service instances. In the first service instances, each first service instance may belong to the second service, or may belong to other services other than the second service in the preset service set.

[0150] For example, the first instance set includes service instance 1, service instance 4, and service instance 5. Service instance 1, service instance 4, and service instance 5 are all first service instances, wherein service instance 1 belongs to the second service, service instance 4 belongs to the third service, and service instance 5 belongs to the fourth service.

[0151] The target instance set does not include the first service instance. The target instance set includes one or more service instances in a non-current-limited state. Each service instance in the target instance set belongs to the second service.

[0152] For example, the target instance set includes: service instance 2 and service instance 3. Service instance 2 and service instance 3 are service instances in a non-current-limited state. And both service instance 2 and service instance 3 belong to the second service.

[0153] The service instances in the second instance set that are identical to those in the first instance set are deleted to obtain the target instance set. This may be done by determining the first service instance in the second instance set based on the first instance set, deleting the first service instance from the second instance set, and obtaining the target instance set.

[0154] In a specific implementation, service instances identical to those in the first instance set are deleted from the second instance set to obtain a target instance set, including: performing intersection processing on the first instance set and the second instance set to obtain a target intersection; and deleting the target intersection from the second instance set to obtain a target instance set.

[0155] The definition of intersection is as follows: In set theory, let A and B be two sets. The set consisting of all elements that belong to set A and set B is called the intersection of set A and set B, denoted by A∩B.

[0156] An intersection process is performed on the first instance set and the second instance set to obtain a target intersection.

[0157] For example, the first instance set includes: instance 101 of service 1, instance 202 of service 2, instance 301 of service 3, the second service is service 2, and the second instance set of service 2 includes: instance 201, instance 202, and instance 203. The target intersection: instance 202 can be obtained by intersection processing.

[0158] The target intersection may include 0 first service instances, may include only one first service instance, or may include multiple first service instances.

[0159] The target intersection is deleted from the second instance set to obtain a target instance set.

[0160] If the target intersection includes 0 first service instances, the target intersection is an empty set, and deleting an empty set from the second instance set does not actually change the second instance set, so the second instance set is the same as the target instance set.

[0161] If the target intersection includes one or more first service instances, each first service instance in the target intersection is deleted from the second instance set to obtain a target instance set.

[0162] In a specific implementation method, service instances in the second instance set that are identical to those in the first instance set are deleted to obtain a target instance set, including: obtaining heartbeat status information of each service instance in the second instance set; if the heartbeat status information of the service instance is in an unhealthy state, deleting the service instance from the second instance set to obtain an intermediate instance set; deleting service instances in the intermediate instance set that are identical to those in the first instance set to obtain a target instance set.

[0163] The heartbeat status information of each service instance may be one of a preset status set.

[0164] The preset state set may include a healthy state and an unhealthy state.

[0165] The healthy status indicates that the service instance can work normally and feed back heartbeat data to the registration center according to the preset heartbeat cycle; the unhealthy status indicates that the service instance cannot work normally and has not fed back heartbeat data to the registration center for N consecutive preset heartbeat cycles, where N is an integer greater than 0 and the value of N can be customized.

[0166] If the heartbeat status information of the service instance is in an unhealthy state, the service instance is deleted from the second instance set to obtain an intermediate instance set. Furthermore, each service instance in the intermediate instance set is a service instance whose heartbeat status information is in a healthy state.

[0167] Delete the service instances in the intermediate instance set that are the same as the first instance set to obtain the target instance set. Refer to the corresponding description part of "perform intersection processing based on the first instance set and the second instance set to obtain the target intersection; delete the target intersection from the second instance set to obtain the target instance set" in the aforementioned implementation method.

[0168] The heartbeat status information is in an unhealthy state, indicating that the service instance may be abnormal and cannot process requests from other services. Therefore, the service instance is not suitable as a target instance to be called and can be excluded from the second instance set in advance.

[0169] Step S208: determine the target instance to be called in the target instance set, and respond to the calling request based on the target instance.

[0170] Determining the target instance to be called in the target instance set can be performed by determining the selection probability of each service instance being selected as the target instance based on the number of service instances included in the target instance set, and determining the target instance to be called in the target instance set based on the selection probability.

[0171] For example, if the target instance set includes three service instances, the selection probability of each service instance being selected as the target instance is 1 / 3, and the target instance to be called is determined in the target instance set according to the selection probability.

[0172] The target instance to be called can be determined in the target instance set. Alternatively, a random number generation range can be determined based on the number of service instances included in the target instance set, a random number can be generated within the random number generation range, and the target instance to be called can be determined in the target instance set based on the random number.

[0173] For example, the target instance set includes 3 service instances, service instance 1 corresponds to 1, service instance 2 corresponds to 2, and service instance 3 corresponds to 3. The random number generation range is determined to be [1, 3]. A random number "2" is generated within [1, 3]. According to the random number "2", the target instance to be called is determined to be service instance 2.

[0174] By sending the call request sent by the first service to the target service instance of the second service, the target service instance can return response data to the first service that sent the call request after receiving and processing the call request. Through the response data, the first service can call the second service. For example, the first service is an order service and the second service is a payment service. In this way, the order service can successfully call the payment service.

[0175] After receiving the call request, the target service instance may generate first response data indicating acceptance of the call request and return the first response data to the first service, or may generate second response data indicating rejection of the call request and return the second response data to the first service.

[0176] When the target service instance returns the first response data to the first service, the first service successfully calls the second service. When the target service instance returns the second response data to the first service, the first service fails to call the second service.

[0177] Whether the target service instance accepts the call request can be determined based on the available resources of the target service instance. For example, when the target service instance receives the call request, it compares the number of available resources of the target service instance with a preset resource quantity threshold. If the number of available resources is greater than the preset resource quantity threshold, it generates first response data indicating acceptance of the call request; otherwise, it generates second response data indicating rejection of the call request.

[0178] Whether the target service instance accepts the call request can also be determined based on the permission authentication result. For example, when the target service instance receives the call request, it performs permission authentication processing according to the permission information of the first service carried in the call request to obtain the permission authentication result. If the permission authentication result indicates that the permission authentication is passed, a first response data indicating acceptance of the call request is generated; otherwise, a second response data indicating rejection of the call request is generated.

[0179] The two above-listed determination processes of whether the target service instance accepts the call request are merely exemplary, and this specification does not impose any special restrictions on the determination process of whether the target service instance accepts the call request.

[0180] In a specific implementation, the service calling method also includes: adding a new service instance to the second instance set; obtaining the diversion configuration information of the new service instance; the diversion configuration information includes an interval duration and multiple weight parameter values ​​arranged in a preset priority order; configuring the weight parameters of the new service instance according to a preset initial value; the weight parameters are used to determine the probability of the new service instance being selected as the target instance; and updating the weight parameters of the new service instance according to the interval duration and the multiple weight parameter values.

[0181] In actual applications, the following problems may occur when calling services:

[0182] When a new service instance is created and added to the second instance set of the second service, the probability of receiving requests for this service instance is the same as that of other old service instances by default. Therefore, a service instance may receive a large number of requests right after it is created. However, in fact, a new service instance requires a "warm-up" process, for example, loading resource data, configuring environmental parameters, etc. during the warm-up phase. The warm-up phase takes some time. For example, if the theoretical data processing capacity of the service instance is to process 100 requests at the same time, during the warm-up phase, because the service instance is not "ready", it may crash after receiving 80 requests at once. That is, for a new service instance, if the traffic accessing the service instance is too large, it may cause slow response to service requests, excessive resource consumption, and even crash the service instance in severe cases.

[0183] In order to solve the above problems, this implementation adopts a step-by-step drainage method.

[0184] First, let's explain the definition of traffic diversion: In microservices, traffic diversion mainly refers to directing external traffic or requests to the corresponding microservice instances. This usually involves technologies such as service discovery, load balancing, and routing. Service discovery means that service consumers can automatically find the network location of service providers; load balancing distributes requests to multiple service instances to achieve high availability and scalability; routing routes requests to the correct service instance based on the characteristics of the request, such as URL (uniform resource location), HTTP (Hypertext Transfer Protocol) method, request header, etc. Through an effective traffic diversion strategy, it can ensure that external requests can be processed correctly and improve the overall performance and stability of the system.

[0185] In layman's terms, traffic diversion can be understood as: originally no requests were passed to the service instance, but after diversion, some requests were passed to the service instance. That is, traffic diversion for a service instance means that the access traffic is directed to a service instance.

[0186] Step-by-step traffic diversion can be understood as the number of requests delivered to the service instance increasing in a step-by-step manner during the traffic diversion process.

[0187] Obtain the traffic diversion configuration information of the newly added service instance; the traffic diversion configuration information includes an interval duration and multiple weight parameter values ​​arranged in a preset priority order. Among them, the interval duration is used to indicate the length of the interval between any two adjacent updates during the process of multiple updates of the weight parameters of the newly added service instance. Multiple weight parameter values ​​arranged in a preset priority order can be used to update the weight parameters of the newly added service instance multiple times.

[0188] For example, the multiple weight parameter values ​​arranged in a preset priority order include k1, k2, and k3. When the weight parameter of the newly added service instance is updated for the first time, the weight parameter of the newly added service instance is updated from 0 to k1; when the weight parameter of the newly added service instance is updated for the second time, the weight parameter of the newly added service instance is updated from k1 to k2; when the weight parameter of the newly added service instance is updated for the third time, the weight parameter of the newly added service instance is updated from k2 to k3.

[0189] Exemplarily, the traffic diversion configuration information of the newly added service instance can refer to the following Table 1.

[0190]

[0191] Table 1

[0192] The traffic diversion configuration information may include one or more configuration items, each of which is a parameter. Referring to Table 1, the configuration items include parameter 1, parameter 2, ..., parameter 6.

[0193] Among them, parameter 1 represents whether to enable the step drainage function switch. The default value is false (error), indicating that the switch is not started. When the parameter value of parameter 1 is changed to true (correct), the parameter value indicates that the switch is started.

[0194] Parameter 2 represents the step-by-step drainage weight rule, the default value of which includes multiple weight parameter values ​​arranged in a preset priority order: 10, 20, 30, 40, 50, 60, 70, 80, 90, 100.

[0195] Parameter 3 represents the interval time of each diversion execution, that is, the interval time included in the diversion configuration information. The default value of this time is 30 seconds.

[0196] Parameter 4 represents the overall traffic diversion timeout, and the default value of this time is 100 seconds.

[0197] Parameter 5 represents the final weight value, that is, the weight parameter value at the end of step-by-step drainage. The default value of the final weight value is 100.

[0198] Parameter 6 represents the initial weight value, that is, the weight parameter value at the beginning of step-by-step drainage. The default value of the initial weight value is 0.

[0199] The configuration items and their default values ​​shown in Table 1 above are merely exemplary. In actual applications, the traffic diversion configuration information can be customized according to business requirements.

[0200] The weight parameter of the newly added service instance is configured according to the preset initial value; the weight parameter is used to determine the selection probability of the newly added service instance being selected as the target instance.

[0201] For example, the preset initial value is 0. Configure the weight parameter of the newly added service instance to 0.

[0202] In the second instance set, the weight parameter of each service instance except the newly added service instance can be determined as 100, and then the selection probability of the newly added service instance being selected as the target instance can be determined based on the weight parameters of each service instance and the weight parameter of the newly added service instance.

[0203] For example, the second instance set includes: service instance 1, service instance 2, and a newly added service instance. Among them, the weight parameter of service instance 1 is 100, the weight parameter of service instance 2 is 100, and the weight parameter of the newly added service instance is 0. Then, according to the weight parameters of service instance 1, service instance 2, and the newly added service instance, it can be determined that the probability of the newly added service instance being selected as the target instance is 0.

[0204] For another example, the second instance set includes: service instance 1, service instance 2, and a newly added service instance. The weight parameter of service instance 1 is 100, the weight parameter of service instance 2 is 100, and the weight parameter of the newly added service instance is 10. Then, according to the weight parameters of service instance 1, service instance 2, and the newly added service instance, it can be determined that the probability of the newly added service instance being selected as the target instance is 10 / (100+100+10)=1 / 21.

[0205] The weight parameters of the newly added service instance are updated according to the interval duration and multiple weight parameter values. For example, the initial weight parameter is 0, and after 30 seconds the weight parameter is updated from 0 to 10, and after another 30 seconds the weight parameter is updated from 10 to 20... and after another 30 seconds the weight parameter is updated from 90 to 100. The weight parameter value gradually increases with time, and the change of the weight parameter value is in a step-like manner, thereby realizing the aforementioned step-by-step drainage, so that the number of requests transmitted to the newly added service instance increases in a step-by-step manner.

[0206] Based on the same technical concept, we can combine Figure 3 The specific implementation process of the step drainage in the embodiment of the present application is illustrated by way of example.

[0207] Figure 3 A processing flow chart of step-by-step diversion in a service calling method provided in an embodiment of the present application.

[0208] Step S302, setting the initial weight value of the current instance.

[0209] Step S304, determining the delayed registration time.

[0210] Step S306: whether it is a verification instance.

[0211] A verification instance is a special service instance that is used by test staff for manual verification. Therefore, there is no need to direct traffic and you can directly register the instance.

[0212] If the newly added service instance is a verification instance, step S308 may be executed; if the newly added service instance is not a verification instance, step S310 may be executed.

[0213] Step S308: register the instance.

[0214] Instance registration refers to the sending of instance information by a newly added service instance to a registration center, so that the registration center can register the newly added service instance based on the instance information.

[0215] Step S310, obtaining local instance diversion configuration information.

[0216] Exemplarily, the diversion configuration information may refer to the aforementioned Table 1.

[0217] Step S312: Whether to turn on the drainage switch.

[0218] Referring to Table 1, if the parameter value of parameter 1 is false, it means that the drainage switch is not turned on, and step S324 is executed; if the parameter value of parameter 1 is true, it means that the drainage switch is turned on, and step S314 is executed.

[0219] Step S314, setting an execution timeout point according to the configured timeout time.

[0220] The configured timeout period can refer to parameter 4 in the aforementioned Table 1.

[0221] The timeout period is a duration, for example, 300 seconds. Setting the execution timeout point according to the configured timeout period refers to determining the timeout point according to the timeout period at the time point of executing step S314.

[0222] For example, the time point for executing step S314 is T1, the time point for timeout is T2, and the interval between T1 and T2 is 300 seconds, which is the timeout period.

[0223] Step S316, determining whether it is the last to last stage.

[0224] Referring to parameter 2 of the aforementioned Table 1, parameter 2 represents a step-by-step drainage weight rule, the default value of which includes a plurality of weight parameter values ​​arranged in a preset priority order: 10, 20, 30, 40, 50, 60, 70, 80, 90, 100.

[0225] The last-to-last stage refers to that multiple weight parameter values ​​are arranged in a preset priority order. According to the preset priority order, a weight parameter value of 10 corresponds to the first stage of step drainage, a weight parameter value of 20 corresponds to the second stage of step drainage, ..., a weight parameter value of 100 corresponds to the 10th stage of step drainage, i.e., the last-to-last stage.

[0226] If the weight parameter value is 100, it is determined to be the last-to-last stage, and step S322 is executed; if the weight parameter value is not 100, it is determined not to be the last-to-last stage, and step S320 is executed.

[0227] Step S318, determine whether the timeout point has been reached.

[0228] If yes, execute step S322; if no, execute step S320.

[0229] Step S320, obtain the weight value of the current stage and execute the instance registration logic.

[0230] The weight parameter value is updated at regular intervals. After the update, the instance registration logic needs to be executed to notify the registration center of the current weight parameter value.

[0231] Step S322, obtain the final weight value and execute the instance registration logic.

[0232] Step S324, set the weight to 100 and register the instance.

[0233] Step S326, delay waiting.

[0234] Step S328, clear the local traffic weight mark.

[0235] Step S330: publish an instance registration event.

[0236] In a specific implementation, determining the target instance to be called in the target instance set includes: determining a weight parameter of each service instance in the target instance set; and determining the target instance to be called in the target instance set according to the weight parameter of each service instance.

[0237] According to the weight parameters of each service instance, the target instance to be called is determined in the target instance set. It can be that according to the weight parameters of each service instance, the selection probability of each service instance being selected as the target instance is determined; according to the selection probability of each service instance, the target instance to be called is determined in the target instance set.

[0238] If all service instances in the target instance set are old service instances that have already been warmed up, then the weight parameter of each service instance is 100. The same weight parameters are actually equivalent to no weight parameters. In essence, multiple requests calling this service are evenly distributed to each service instance of this service.

[0239] There may be one or more service instances in the target instance set that are still warming up, and their weight parameter values ​​are gradually increasing over time. In this case, the weight parameter values ​​of the service instance are different from those of other old service instances, which leads to different selection probabilities.

[0240] The service local of the first service may also store a weight parameter of each service instance in the second instance set. The weight parameter of each service instance in the target instance set may be determined by obtaining the weight parameter of each service instance in the target instance set from the service local. For details, please refer to the corresponding description part of obtaining the second instance set belonging to the second service in the service local of the first service in step S204.

[0241] Based on the weight parameters of each service instance, the probability of each service instance being selected as the target instance is determined. This can be by determining the sum of the weight parameter values ​​of each service instance, and for each service instance, determining the ratio of the weight parameter value of the service instance to the sum of the aforementioned weight parameter values, and using the ratio as the probability of the service instance being selected as the target instance.

[0242] According to the selection probability of each service instance, the target instance to be called is determined in the target instance set. This may be achieved by using a random weighted algorithm to determine the target instance to be called in the target instance set according to the selection probability of each service instance.

[0243] The random weighted algorithm is a common algorithm in deep learning, and is generally used in the following scenarios: There is a set S, which contains four items, such as A, B, C, and D. At this time, you want to randomly extract an item from it, but the probability of extraction is different, for example, the probability of extracting A is 50%, the probability of extracting B and C is 20%, and the probability of D is 10%. At this time, you can attach a weight to each item, and the probability of extraction is proportional to this weight. The core code of the random weighted algorithm: first calculate the sum of the weights, then randomly select a number R between 1 and the sum of the weights, then traverse the entire set, count the sum of the weights of the traversed items, and return the item when it meets the selected probability.

[0244] Considering that the probability of each service instance being selected as the target instance is determined by the weight parameter of each service instance, by adopting the step-by-step diversion method, the number of requests received by the service instance can be reduced during the warm-up phase of the service instance. This can solve the problem of a large number of requests entering during the startup of the service instance, resulting in slow service or service downtime. In addition, step-by-step diversion has strong business flexibility and can meet the needs of diversion in different business scenarios.

[0245] In a specific implementation, the service calling method also includes: when receiving a registration request for a pending service instance, querying whether the first instance set includes the pending service instance; if the first instance set includes the pending service instance, configuring the weight parameter of the pending service instance according to a preset initial value so that the probability of the pending service instance being called by any service in the preset service set is less than a preset probability threshold.

[0246] In actual applications, the following problems may occur when calling services:

[0247] After limiting the flow of a service instance, the service instance in the flow-limited state may be suspended for a period of time. There is no necessary connection between flow limiting and suspended state, and suspended state is a probability. Suspended state means that due to the excessive number of requests processed by the service instance, all computing resources are occupied, the response is very slow and it can no longer process new requests, and it no longer sends heartbeat feedback information to the registration center. If the suspended state lasts too long, the registration center will think that the service instance has been deleted and delete the instance information of the service instance stored. However, it is possible that the suspended service instance will recover later and send heartbeat feedback information to the registration center again, which will cause the registration center to think that a new service instance has been created. The probability of receiving requests by the newly created service instance is the same as that of other old service instances by default. In this case, the service instance that has recovered from suspended state should be in a flow-limited state and cannot receive any requests, but in fact it receives a large number of requests.

[0248] In order to solve the above problem, in this implementation, when a registration request for a pending service instance is received, it can be queried whether the first instance set includes the pending service instance. If the first instance set includes the pending service instance, it means that the pending service instance is an old service instance recovered from suspended animation, rather than a newly created service instance. The weight parameter of the pending service instance is configured according to a preset initial value so that the probability of the pending service instance being selected as the request receiving object of the service call request by any service in the preset service set is less than a preset probability threshold, that is, the probability of the pending service instance being called by any service in the preset service set is less than the preset probability threshold. In this way, the pending service instance can remain in a current limiting state before and after recovering from suspended animation.

[0249] The preset initial value can be 0 or other customized weight parameter values. By configuring the weight parameters of the pending service instances according to the preset initial values, the probability of the pending service instances being called by any service in the preset service set can be changed by configuring the weight parameters, so that the pending service instances can be kept in a current limiting state.

[0250] In such Figure 2 In the illustrated embodiment, first, a first service instance in a first instance set is deleted, where the first service instance is a service instance in a preset service set that is in a current-limited state; then, if a call request for a second service initiated by the first service is detected, a second instance set belonging to the second service is determined, where the first service and the second service are different services in the preset service set; then, the service instances in the second instance set that are identical to those in the first instance set are deleted to obtain a target instance set; finally, a target instance to be called is determined in the target instance set, and the call request is responded to based on the target instance. In this way, by deleting the service instances in the preset service set that are in the current limiting state, the service instances that have actually been deleted can be in the current limiting state before deletion. In the process of the first service calling the second service, it is necessary to select a target instance to be called from the service instances belonging to the second service. Considering that there may be a perception lag between the first service and the second service, the second instance set obtained belonging to the second service may include the service instances that have actually been deleted. By deleting the service instances that are the same as the first instance set in the second instance set, the target instance set is obtained, and the first service instances in the second instance set can be excluded, that is, the target instance set does not include any service instances in the current limiting state. In this way, regardless of whether the second instance set includes the service instances that have actually been deleted, by excluding the service instances in the current limiting state, it can be ensured that the target instance set does not include any service instances that have actually been deleted. Furthermore, by determining the target instance to be called in the target instance set, the erroneous call to the deleted service instance caused by the perception lag can be avoided.

[0251] Based on the same technical concept, the embodiment of the present application also provides another service calling method. Figure 4 A data flow diagram of another service calling method provided in an embodiment of the present application.

[0252] like Figure 4 As shown, the microservice system includes an application service 402 , an application service 404 , a registration center 406 , a traffic control adapter 408 , and a preset storage area 410 .

[0253] Application service 404 is a service that actively initiates a call. Application service 402 is a target service to be called.

[0254] The preset storage area 410 stores a first instance set.

[0255] When the application service 404 detects that the first instance set has changed, it obtains the changed first instance set from the preset storage area 410. For details, please refer to the corresponding description part of obtaining the first instance set in the aforementioned method embodiment. The first instance set may include one or more first service instances, and the first service instance is a service instance in the preset service set that is in a current-limited state.

[0256] The application service 402 deletes the first service instance. For details, please refer to the corresponding description part of the aforementioned step S202.

[0257] Application service 404 determines the second service to be called in the preset service set, namely application service 402, and obtains a second instance set of application service 402; the second instance set includes the first service instance, and details can be referred to the corresponding description part of the aforementioned step S204.

[0258] The application service 404 deletes the service instances in the second instance set that are the same as those in the first instance set to obtain a target instance set. For details, please refer to the corresponding description of the aforementioned step S206.

[0259] The application service 404 determines the target instance to be called in the target instance set, and the details may refer to the corresponding description part of the aforementioned step S208.

[0260] The flow control adapter 408 can be used to perform flow limiting operations on the service instances in the application service 404 .

[0261] In specific implementation, the service calling method may include the following steps:

[0262] (1) When a service instance of the application service 402 goes online, during the startup process, it reports its instance information to the registration center 406. The instance information includes but is not limited to: service name, IP, port, and extended information metadata. Extended information, for example, weight parameter value.

[0263] (2) A service instance 001 of the application service 404 will also be registered with the registration center 406, and a service list will be pulled from the registration center 406. Since the weight parameter value of the registered service instance 001 of the application service 402 is 0, the service instance 001 will not be selected in the process of determining the target instance to be called by the application service 404.

[0264] (3) After the service is started, service instance 001 will perform step-by-step traffic diversion according to the diversion configuration information, thereby completing the smooth introduction of service-oriented traffic to the service instance and solving the problems of slow requests and large traffic crashes during the service-oriented startup period.

[0265] (4) During normal operation, service instance 001 will regularly maintain heartbeats with registration center 406 to maintain a healthy state.

[0266] (5) During the normal operation of service instance 001, if it is necessary to perform a flow limiting operation or a flow recovery operation on it, the manual operation process will be entered, and the flow control adapter 408 will be called. Depending on whether it is a flow limiting operation or a flow recovery operation, the interface of the registration center 406 will be called to modify the metadata extension information of the service instance 001. If it is a flow limiting operation, it will be changed to 0, and if it is a flow recovery operation, it will be changed to 100; if it is a flow limiting operation, the instance information of the service instance 001 will also be written into the preset storage area 410, and if it is a flow recovery operation, the instance information of the service instance 001 in the preset storage area 410 will be deleted.

[0267] (6) Application service 404 detects changes in the first instance set in the preset storage area 410. Once there is an update, the changed first instance set will be pulled down. In the process of calling application service 402, application service 404 will preferentially exclude first service instances in the current limiting state and will not select these first service instances to send requests, thereby achieving the purpose of real-time perception of other services after current limiting.

[0268] (7) Before deleting, service instance 001 first calls flow control adapter 408 to perform flow limiting operation on itself, which is the same as the above step (5). After completion, the instance is deleted and the instance information of service instance 001 is deleted from the registration center. Since the above step (6) has excluded service instance 001 in advance, deleting service instance 001 will not affect application service 404 calling application service 402. That is, by excluding service instances in the flow limiting state in the process of determining the target instance, it is possible to exclude service instances that have actually been deleted but have not been perceived by application service 404 due to the perception lag between different services, thereby avoiding application service 404 from mistakenly calling the deleted service instance 001 of application service 402.

[0269] (8) When a service instance initiates registration, the registration center 406 checks whether the service instance currently initiating registration has instance information in the preset storage area 410. If yes, the weight parameter value is reset to 0. If no, it is skipped directly. This step is to ensure that the service instance in the current limiting state is in a suspended state and remains in the current limiting state after it recovers to normal.

[0270] Since the technical concept is the same, the description in this embodiment is relatively simple, and the relevant parts may refer to the corresponding description of the method embodiment provided above.

[0271] An embodiment of a service calling device provided in this specification is as follows:

[0272] In the above-mentioned embodiment, a service calling method is provided. Based on the same technical concept, the embodiment of the present application also provides a service calling device, which is described below in conjunction with the accompanying drawings.

[0273] Figure 5 A schematic diagram of a service invocation device provided in an embodiment of the present application. This embodiment provides a service invocation device 500, including:

[0274] A deleting unit 502 is configured to delete a first service instance in a first instance set, where the first service instance is a service instance in a current limiting state in a service of a preset service set;

[0275] A determining unit 504 is configured to determine, if a call request for a second service initiated by a first service is detected, a second instance set belonging to the second service, wherein the first service and the second service are different services in the preset service set;

[0276] The deleting unit 502 is further configured to delete the same service instances as those in the first instance set in the second instance set, to obtain a target instance set;

[0277] The determining unit 504 is further configured to determine a target instance to be called in the target instance set, and respond to the calling request based on the target instance.

[0278] Optionally, the first instance set is updated in the following manner:

[0279] After detecting a flow limiting operation for a service instance of any service in the preset service set, adding the service instance of the flow limiting operation to the first instance set; or,

[0280] After detecting a traffic recovery operation for any first service instance in the first instance set, the first service instance of the traffic recovery operation is deleted from the first instance set.

[0281] Optionally, when deleting the service instance in the second instance set that is the same as the first instance set and obtaining the target instance set, the deleting unit 502 performs the following steps:

[0282] Performing intersection processing on the first instance set and the second instance set to obtain a target intersection;

[0283] The target intersection is deleted from the second instance set to obtain the target instance set.

[0284] Optionally, the service calling device 500 further includes: an adding unit, an acquiring unit, a configuring unit and an updating unit;

[0285] The adding unit is used to add a new service instance to the second instance set;

[0286] The acquisition unit is used to acquire the traffic diversion configuration information of the newly added service instance; the traffic diversion configuration information includes an interval duration and a plurality of weight parameter values ​​arranged in a preset priority order;

[0287] The configuration unit is used to configure the weight parameter of the newly added service instance according to a preset initial value; the weight parameter is used to determine the selection probability of the newly added service instance being selected as the target instance;

[0288] The updating unit is used to update the weight parameter of the newly added service instance according to the interval duration and the multiple weight parameter values.

[0289] Optionally, when the determining unit 504 determines the target instance to be called in the target instance set, it performs the following steps:

[0290] Determining a weight parameter of each service instance in the target instance set;

[0291] According to the weight parameter of each service instance, a target instance to be called is determined in the target instance set.

[0292] Optionally, the service calling device 500 further includes:

[0293] A query unit, configured to query whether the first instance set includes the service instance to be processed when a registration request for the service instance to be processed is received;

[0294] A configuration unit is used to configure the weight parameter of the service instance to be processed according to a preset initial value if the first instance set includes the service instance to be processed, so that the probability of the service instance to be processed being called by any service in the preset service set is less than a preset probability threshold.

[0295] Optionally, when deleting the service instance in the second instance set that is the same as the first instance set and obtaining the target instance set, the deleting unit 502 performs the following steps:

[0296] Obtaining heartbeat status information of each service instance in the second instance set;

[0297] If the heartbeat status information of the service instance is in an unhealthy state, deleting the service instance from the second instance set to obtain an intermediate instance set;

[0298] The service instances in the intermediate instance set that are the same as the first instance set are deleted to obtain a target instance set.

[0299] In an embodiment of the present application, a service calling device includes: a deleting unit, which is used to delete a first service instance in a first instance set, where the first service instance is a service instance in a preset service set that is in a current limiting state; a determining unit, which is used to determine a second instance set belonging to the second service if a call request for a second service initiated by the first service is detected, where the first service and the second service are different services in the preset service set; the deleting unit is also used to delete the service instances in the second instance set that are the same as the first instance set to obtain a target instance set; the determining unit is also used to determine the target instance to be called in the target instance set, and respond to the call request based on the target instance. In this way, by deleting the service instances in the preset service set that are in the current limiting state, the service instances that have actually been deleted can be in the current limiting state before deletion. In the process of the first service calling the second service, it is necessary to select a target instance to be called from the service instances belonging to the second service. Considering that there may be a perception lag between the first service and the second service, the second instance set obtained belonging to the second service may include the service instances that have actually been deleted. By deleting the service instances that are the same as the first instance set in the second instance set, the target instance set is obtained, and the first service instances in the second instance set can be excluded, that is, the target instance set does not include any service instances in the current limiting state. In this way, regardless of whether the second instance set includes the service instances that have actually been deleted, by excluding the service instances in the current limiting state, it can be ensured that the target instance set does not include any service instances that have actually been deleted. Furthermore, by determining the target instance to be called in the target instance set, the erroneous call to the deleted service instance caused by the perception lag can be avoided.

[0300] Corresponding to the service calling method described above, based on the same technical concept, an embodiment of the present application also provides an electronic device, which is used to execute the service calling method provided above. Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0301] like Figure 6As shown, the electronic device may have relatively large differences due to different configurations or performances, and may include one or more processors 601 and memory 602, and the memory 602 may store one or more storage applications or data. Among them, the memory 602 can be a temporary storage or a permanent storage. The application stored in the memory 602 may include one or more modules (not shown in the figure), and each module may include a series of computer executable instructions in the electronic device. Furthermore, the processor 601 can be configured to communicate with the memory 602 to execute a series of computer executable instructions in the memory 602 on the electronic device. The electronic device may also include one or more power supplies 603, one or more wired or wireless network interfaces 604, one or more input / output interfaces 605, one or more keyboards 606, etc.

[0302] In a specific embodiment, the electronic device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer executable instructions for the electronic device, and the one or more programs configured to be executed by one or more processors include the following computer executable instructions:

[0303] Deleting a first service instance in a first instance set, where the first service instance is a service instance in a current-limited state among services in a preset service set;

[0304] If a call request for a second service initiated by a first service is detected, a second instance set belonging to the second service is determined, and the first service and the second service are different services in the preset service set;

[0305] Deleting the same service instances as those in the first instance set in the second instance set to obtain a target instance set;

[0306] A target instance to be called is determined in the target instance set, and the calling request is responded to based on the target instance.

[0307] The computer-readable storage medium provided in this embodiment is used to store computer-executable instructions. When the computer-executable instructions are executed by a processor, the following process is implemented:

[0308] Deleting a first service instance in a first instance set, where the first service instance is a service instance in a current-limited state among services in a preset service set;

[0309] If a call request for a second service initiated by a first service is detected, a second instance set belonging to the second service is determined, and the first service and the second service are different services in the preset service set;

[0310] Deleting the same service instances as those in the first instance set in the second instance set to obtain a target instance set;

[0311] A target instance to be called is determined in the target instance set, and the calling request is responded to based on the target instance.

[0312] It should be noted that the embodiment of the computer-readable storage medium in this specification and the embodiment of the service calling method in this specification are based on the same inventive concept, so the specific implementation of this embodiment can refer to the implementation of the aforementioned corresponding method, and the repeated parts will not be repeated.

[0313] Another embodiment of the present disclosure further provides a computer program product, the computer program product comprising a computer program, and when the computer program is executed by a processor, the following process is implemented:

[0314] Deleting a first service instance in a first instance set, where the first service instance is a service instance in a current-limited state among services in a preset service set;

[0315] If a call request for a second service initiated by a first service is detected, a second instance set belonging to the second service is determined, and the first service and the second service are different services in the preset service set;

[0316] Deleting the same service instances as those in the first instance set in the second instance set to obtain a target instance set;

[0317] A target instance to be called is determined in the target instance set, and the calling request is responded to based on the target instance.

[0318] The computer program product in the embodiment of the present disclosure can implement each process of the above-mentioned service calling method embodiment and achieve the same effect and function, which will not be repeated here.

[0319] In an embodiment of the present application, first, the first service instance in the first instance set is deleted, and the first service instance is a service instance in the preset service set that is in a current-limited state; then, if a call request for a second service initiated by the first service is detected, a second instance set belonging to the second service is determined, and the first service and the second service are different services in the preset service set; then, the service instances in the second instance set that are the same as the first instance set are deleted to obtain a target instance set; finally, the target instance to be called is determined in the target instance set, and the call request is responded to based on the target instance. In this way, by deleting the service instances in the preset service set that are in the current limiting state, the service instances that have actually been deleted can be in the current limiting state before deletion. In the process of the first service calling the second service, it is necessary to select a target instance to be called from the service instances belonging to the second service. Considering that there may be a perception lag between the first service and the second service, the second instance set obtained belonging to the second service may include the service instances that have actually been deleted. By deleting the service instances that are the same as the first instance set in the second instance set, the target instance set is obtained, and the first service instances in the second instance set can be excluded, that is, the target instance set does not include any service instances in the current limiting state. In this way, regardless of whether the second instance set includes the service instances that have actually been deleted, by excluding the service instances in the current limiting state, it can be ensured that the target instance set does not include any service instances that have actually been deleted. Furthermore, by determining the target instance to be called in the target instance set, the erroneous call to the deleted service instance caused by the perception lag can be avoided.

[0320] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0321] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems or computer program products. Therefore, the embodiments of the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, this specification may adopt the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0322] This specification is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable electronic device to produce a machine, so that the instructions executed by the processor of the computer or other programmable electronic device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0323] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable electronic device to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0324] These computer program instructions may also be loaded onto a computer or other programmable electronic device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0325] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0326] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0327] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0328] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0329] Embodiments of the present application may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0330] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0331] The above description is only an embodiment of this document and is not intended to limit this document. For those skilled in the art, this document may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this document should be included in the scope of the claims of this document.

Claims

1. A service calling method, It is characterized in that include: Deleting a first service instance in a first instance set, where the first service instance is a service instance in a current-limited state among services in a preset service set; If a call request for a second service initiated by a first service is detected, a second instance set belonging to the second service is determined, and the first service and the second service are different services in the preset service set; Deleting the same service instances as those in the first instance set in the second instance set to obtain a target instance set; A target instance to be called is determined in the target instance set, and the calling request is responded to based on the target instance.

2. The method according to claim 1, It is characterized in that The first instance set is updated in the following manner: After detecting a flow limiting operation for a service instance of any service in the preset service set, adding the service instance of the flow limiting operation to the first instance set; or, After detecting a traffic recovery operation for any first service instance in the first instance set, the first service instance of the traffic recovery operation is deleted from the first instance set.

3. The method according to claim 1, It is characterized in that The deleting the service instances in the second instance set that are the same as those in the first instance set to obtain a target instance set includes: Performing intersection processing on the first instance set and the second instance set to obtain a target intersection; The target intersection is deleted from the second instance set to obtain the target instance set.

4. The method according to claim 1, It is characterized in that The method further comprises: Adding a new service instance to the second instance set; Obtaining the traffic diversion configuration information of the newly added service instance; the traffic diversion configuration information includes an interval duration and a plurality of weight parameter values ​​arranged in a preset priority order; Configuring a weight parameter of the newly added service instance according to a preset initial value; the weight parameter is used to determine a selection probability of the newly added service instance being selected as the target instance; The weight parameter of the newly added service instance is updated according to the interval duration and the multiple weight parameter values.

5. The method according to claim 4, It is characterized in that The step of determining the target instance to be called in the target instance set includes: Determining a weight parameter of each service instance in the target instance set; According to the weight parameter of each service instance, a target instance to be called is determined in the target instance set.

6. The method according to claim 1, It is characterized in that The method further comprises: In case of receiving a registration request for a service instance to be processed, querying whether the first instance set includes the service instance to be processed; If the first instance set includes the service instance to be processed, the weight parameter of the service instance to be processed is configured according to a preset initial value so that the probability of the service instance to be processed being called by any service in the preset service set is less than a preset probability threshold.

7. The method according to claim 1, It is characterized in that The deleting the service instances in the second instance set that are the same as those in the first instance set to obtain a target instance set includes: Obtaining heartbeat status information of each service instance in the second instance set; If the heartbeat status information of the service instance is in an unhealthy state, deleting the service instance from the second instance set to obtain an intermediate instance set; The service instances in the intermediate instance set that are the same as the first instance set are deleted to obtain a target instance set.

8. An electronic device, It is characterized in that include: processor; And, a memory configured to store computer executable instructions, which, when executed, cause the processor to perform the service calling method according to any one of claims 1 to 7.

9. A computer-readable storage medium, It is characterized in that The computer-readable storage medium is used to store computer-executable instructions, and the computer-executable instructions, when executed by a processor, implement the service calling method according to any one of claims 1 to 7.

10. A computer program product, It is characterized in that It comprises a computer program, which, when executed by a processor, implements the service calling method as claimed in any one of claims 1 to 7.

Images