Service instance calling method and device, electronic equipment and storage medium

Abstract

The invention provides a service instance calling method and device, electronic equipment and a storage medium, and relates to the technical field of computers. The method comprises the following steps: in response to an instance calling request of a first service node, obtaining a resource group identifier of a to-be-called target service instance from the instance calling request; the target resource group corresponding to the resource group identifier comprises partial service nodes in the plurality of service nodes, and the partial service nodes comprise the first service node; determining a target resource group matched with the resource group identifier from a plurality of preset resource groups, and obtaining a service instance list of the target resource group; and if the service instance list comprises the target instance identifier of the target service instance, scheduling the target service instance deployed on the second service node in the target resource group to the first service node. Therefore, the problem of stability risk caused by the fact that the service fault domain is too large, the fault is easy to diffuse in a machine room and the granularity of the fault switching operation is too coarse is solved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a service instance invocation method, apparatus, electronic device and storage medium. Background Technology

[0002] In internet service operations and maintenance, to ensure high service availability, a cross-data center (or cross-availability zone) deployment architecture is typically adopted. For example, the same service may be deployed simultaneously in two data centers (e.g., data centers). This way, when one data center becomes unavailable due to network jitter, equipment failure, or software deployment failure, operations personnel or automated systems can use global traffic scheduling to switch all user traffic stored in the aforementioned data center to the other healthy data center.

[0003] Therefore, it is evident that using the above-described fault isolation method, since the data center is a resource pool shared by multiple services (or service instances), allows localized, minor faults to rapidly propagate and spread through inter-service call relationships, ultimately crippling all service instances within the entire data center. Furthermore, treating the entire data center as a service fault domain—meaning the smallest unit of fault isolation is switching the entire data center—may lead to overload of other data centers, resulting in significant capacity risks.

[0004] Therefore, how to effectively mitigate the stability risks caused by excessively large service fault domains, the ease with which faults can spread within the data center, and overly coarse-grained failover operations is a problem that urgently needs to be addressed. Summary of the Invention

[0005] This application provides a service instance invocation method, apparatus, electronic device, and storage medium to improve stability risks caused by excessively large service fault domains, easy spread of faults within the data center, and overly coarse granularity of fault switching operations.

[0006] In a first aspect, embodiments of this application provide a service instance invocation method, the method comprising: In response to the instance invocation request of the first service node, the resource group identifier of the target service instance to be invoked is obtained from the instance invocation request; the target resource group corresponding to the resource group identifier includes some service nodes among multiple service nodes, and some service nodes include the first service node; From a set of multiple pre-defined resource groups, determine the target resource group that matches the resource group identifier, and obtain the service instance list of the target resource group; the service instance list includes the service instance identifier of at least one service instance deployed on each service node in the partial service nodes. If the target instance identifier of the target service instance is included in the service instance list, the target service instance deployed on the second service node in the target resource group will be scheduled to the first service node.

[0007] In an optional embodiment, prior to responding to the instance invocation request of the first service node, the method further includes: Obtain the location distribution of multiple service nodes in the service data center and the node response time corresponding to each service node; where the node response time represents the request response speed of the corresponding service node; Based on location distribution and response time of multiple nodes, multiple service nodes are divided into multiple resource groups; Set different resource group identifiers for multiple resource groups, and associate multiple service nodes with the corresponding resource group identifiers.

[0008] In an optional embodiment, after dividing multiple service nodes into multiple resource groups based on location distribution and response time of multiple nodes, the method further includes: For each of the multiple services in the server room, perform the following operations: A resource group list for the first service is constructed based on multiple resource groups; wherein, the first service is any one of the multiple services, and the resource group list indicates that each resource group is used to deploy service instances of the first service; Based on the service instance deployment strategy associated with the first service, service instances of the first service are deployed in each resource group; wherein, the service instance deployment strategy includes: the total number of service instances deployed corresponding to the first service and the service instance deployment ratio corresponding to each resource group.

[0009] In an optional embodiment, after dividing multiple service nodes into multiple resource groups based on location distribution and response time of multiple nodes, the method further includes: Perform the following operations for each of the multiple resource groups: In response to a resource capacity adjustment request for the first resource group, the resource capacity adjustment amount for the first resource group is obtained from the resource capacity adjustment request; wherein the first resource group is any one of multiple resource groups. Based on the resource capacity percentage of at least one service in the first resource group and the resource capacity adjustment amount, the initial resource capacity of at least one service is adjusted.

[0010] In an optional embodiment, the process of obtaining the resource group identifier of the target service instance to be invoked from the instance invocation request further includes: Perform resource group identifier verification on instance scheduling requests and obtain the identifier verification result; If the identifier verification result indicates that the resource group identifier carried in the instance scheduling request is the resource group identifier of the target service instance, then the instance scheduling request is determined to be a scheduling request for the target service instance. If the identifier verification result indicates that the resource group identifier carried in the instance scheduling request is not the resource group identifier of the target service instance, then an indication message is generated; the indication message is used to instruct the first service node to re-initiate the scheduling request carrying the resource group identifier of the target service instance.

[0011] In an optional embodiment, after obtaining the list of service instances for the target resource group, the method further includes: The performance of multiple service instances indicated by the service instance list is verified to obtain the performance verification results; the performance verification results indicate whether the multiple service instances are abnormal service instances with faults. If the performance verification results indicate that there are abnormal service instances among multiple service instances, then the abnormal instance identifier of the abnormal service instance will be removed from the service instance list.

[0012] In an optional embodiment, after obtaining the list of service instances for the target resource group, the method further includes: If the target instance identifier is not included in the service instance list, then alternative resource groups whose service instance lists include the target instance identifier will be selected from multiple resource groups. The target service instance deployed on the third service node in the standby resource group will be scheduled to the first service node.

[0013] Secondly, embodiments of this application also provide a service instance invocation apparatus, the apparatus comprising: The request parsing module is used to respond to the instance call request of the first service node and obtain the resource group identifier of the target service instance to be called from the instance call request; the target resource group corresponding to the resource group identifier includes some service nodes among multiple service nodes, and some service nodes include the first service node; The list retrieval module is used to determine the target resource group that matches the resource group identifier from a plurality of preset resource groups, and to obtain the service instance list of the target resource group; the service instance list includes: the service instance identifier of at least one service instance deployed on each service node in the partial service nodes; The instance scheduling module is used to schedule the target service instance deployed on the second service node in the target resource group to the first service node if the target service instance is included in the service instance list.

[0014] In an optional embodiment, before responding to the instance invocation request of the first service node, the list retrieval module is further configured to: Obtain the location distribution of multiple service nodes in the service data center and the node response time corresponding to each service node; where the node response time represents the request response speed of the corresponding service node; Based on location distribution and response time of multiple nodes, multiple service nodes are divided into multiple resource groups; Set different resource group identifiers for multiple resource groups, and associate multiple service nodes with the corresponding resource group identifiers.

[0015] In an optional embodiment, after dividing multiple service nodes into multiple resource groups based on location distribution and response time of multiple nodes, the list retrieval module is further used to: For each of the multiple services in the server room, perform the following operations: A resource group list for the first service is constructed based on multiple resource groups; wherein, the first service is any one of the multiple services, and the resource group list indicates that each resource group is used to deploy service instances of the first service; Based on the service instance deployment strategy associated with the first service, service instances of the first service are deployed in each resource group; wherein, the service instance deployment strategy includes: the total number of service instances deployed corresponding to the first service and the service instance deployment ratio corresponding to each resource group.

[0016] In an optional embodiment, after dividing multiple service nodes into multiple resource groups based on location distribution and response time of multiple nodes, the list retrieval module is further used to: Perform the following operations for each of the multiple resource groups: In response to a resource capacity adjustment request for the first resource group, the resource capacity adjustment amount for the first resource group is obtained from the resource capacity adjustment request; wherein the first resource group is any one of multiple resource groups. Based on the resource capacity percentage of at least one service in the first resource group and the resource capacity adjustment amount, the initial resource capacity of at least one service is adjusted.

[0017] In an optional embodiment, during the process of obtaining the resource group identifier of the target service instance to be invoked from the instance invocation request, the list retrieval module is further configured to: Perform resource group identifier verification on instance scheduling requests and obtain the identifier verification result; If the identifier verification result indicates that the resource group identifier carried in the instance scheduling request is the resource group identifier of the target service instance, then the instance scheduling request is determined to be a scheduling request for the target service instance. If the identifier verification result indicates that the resource group identifier carried in the instance scheduling request is not the resource group identifier of the target service instance, then an indication message is generated; the indication message is used to instruct the first service node to re-initiate the scheduling request carrying the resource group identifier of the target service instance.

[0018] In an optional embodiment, after obtaining the list of service instances of the target resource group, the list acquisition module is further configured to: The performance of multiple service instances indicated by the service instance list is verified to obtain the performance verification results; the performance verification results indicate whether the multiple service instances are abnormal service instances with faults. If the performance verification results indicate that there are abnormal service instances among multiple service instances, then the abnormal instance identifier of the abnormal service instance will be removed from the service instance list.

[0019] In an optional embodiment, after obtaining the list of service instances for the target resource group, the instance scheduling module is further configured to: If the target instance identifier is not included in the service instance list, then alternative resource groups whose service instance lists include the target instance identifier will be selected from multiple resource groups. The target service instance deployed on the third service node in the standby resource group will be scheduled to the first service node.

[0020] Thirdly, embodiments of this application provide an electronic device, including: processor; Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the service instance invocation method as described in the first aspect.

[0021] Fourthly, embodiments of this application provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the service instance invocation method as described in the first aspect.

[0022] Fifthly, this application provides a computer program product that, when invoked by a computer, causes the computer to execute the service instance invocation method steps as described in the first aspect.

[0023] The beneficial effects of this application are as follows: In the service instance invocation method provided in this application embodiment, in response to the instance invocation request of the first service node, the resource group identifier of the target service instance to be invoked is obtained from the instance invocation request; the target resource group corresponding to the resource group identifier includes some service nodes among multiple service nodes, and some service nodes include the first service node; then, from the preset multiple resource groups, the target resource group that matches the resource group identifier is determined, and the service instance list of the target resource group is obtained; the service instance list includes: the service instance identifier of at least one service instance deployed on each service node among the some service nodes; finally, if the service instance list includes the target instance identifier of the target service instance, the target service instance deployed on the second service node in the target resource group is scheduled to the first service node.

[0024] Therefore, dividing the multiple service nodes within the service data center into multiple resource groups allows the first service node, when calling a target service instance, to determine the second service node deploying the target service instance from the resource group identifier corresponding to the target service instance. This allows the target service instance deployed by the second service node to be scheduled to the first service node, thus meeting the service instance requirements of the first service node. Therefore, shifting the resources used by the first service node from the entire service data center to a specific resource group (i.e., a portion of the service nodes within the service data center) effectively mitigates the stability risks caused by excessively large service fault domains, the ease with which faults can propagate within the data center, and overly coarse-grained failover operations.

[0025] Furthermore, other features and advantages of this application will be set forth in the following description and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described herein are used to provide a further understanding of this application, constitute a part of this application, and do not constitute an improper limitation of this application. In the accompanying drawings: Figure 1 This is a schematic diagram of an optional system architecture applicable to the embodiments of this application.

[0027] Figure 2 This is a schematic diagram illustrating the implementation process of a service instance invocation method provided in an embodiment of this application.

[0028] Figure 3 This is a schematic diagram illustrating a specific scenario of resource group division in a service room, as provided in an embodiment of this application.

[0029] Figure 4 This is a schematic diagram of the composition structure of an instance calling device provided in an embodiment of this application.

[0030] Figure 5 This is a schematic diagram illustrating the specific process of service instance scheduling provided in an embodiment of this application.

[0031] Figure 6 This is a schematic diagram of a service instance invocation device provided in an embodiment of this application.

[0032] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0033] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0034] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0035] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this application are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0036] It should be noted that the terms "a" and "a plurality of" used in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0037] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0038] The design concept of the embodiments of this application is briefly introduced below: In internet service operations and maintenance, to ensure high service availability, a cross-data center (or cross-availability zone) deployment architecture is typically adopted. For example, the same service may be deployed simultaneously in two data centers (e.g., data center A and data center B). This way, when one data center (e.g., data center A) becomes unavailable due to network jitter, equipment failure, or software release failure, operations personnel or automated systems will use global traffic scheduling (e.g., global server load balancing (GSLB) or domain name system (DNS)) to switch all user traffic stored in that data center to another healthy data center (e.g., data center B).

[0039] The aforementioned data center-level fault isolation and failover is the mainstream method for ensuring service stability, but it has the following drawbacks: 1. Excessively large fault domain and rapid risk propagation: Treating a single data center as a whole fault domain, and all service instances within the data center as a large resource pool, any local, minor fault (such as a single physical machine crashing or a service instance entering an infinite loop due to a bug and consuming a large amount of central processing unit (CPU)) can rapidly spread through inter-service call relationships, ultimately dragging down all service instances within the entire data center, causing a "snowball effect".

[0040] 2. Coarse-grained failover and high capacity risk: Since the fault domain is the entire data center, the smallest unit of fault isolation is "switching the entire data center." Taking a dual-data center deployment as an example, once a data center switchover is triggered, the total number of online service instances instantly decreases by 50%. For businesses handling massive requests, this will cause a huge capacity shock, easily triggering a chain reaction of overload in the remaining data centers, leading to complete service unavailability. Therefore, the decision-making cost is high and the risk is enormous.

[0041] 3. The impact of changes such as "canary release" is uncontrollable: When service version or configuration changes are made, even if only a few machines in the data center are changed, these "problem" instances may still receive calls from any instance in the data center because traffic is globally scheduled. The resulting impact (such as errors and slow responses) will affect the entire data center, making troubleshooting and risk control very difficult.

[0042] As can be seen, existing fault isolation methods suffer from stability risks due to excessively large service fault domains, easy fault propagation within data centers, and coarse-grained fault switching operations. In view of this, to address or improve the aforementioned problems, this application provides a service instance invocation method, which specifically includes: responding to an instance invocation request from a first service node, obtaining the resource group identifier of the target service instance to be invoked from the instance invocation request; the target resource group corresponding to the resource group identifier includes some service nodes among multiple service nodes, and some service nodes may include the first service node; then, determining the target resource group matching the resource group identifier from a preset plurality of resource groups, and obtaining a service instance list of the target resource group; the service instance list may include: service instance identifiers of at least one service instance deployed on each of the service nodes in the partial service nodes; finally, if the service instance list includes the target instance identifier of the target service instance, the target service instance deployed on the second service node in the target resource group is scheduled to the first service node. This approach divides the multiple service nodes within the service data center into multiple resource groups. When a first service node calls a target service instance, it can determine the second service node deploying the target service instance from the resource group identifier corresponding to the target service instance. The target service instance deployed by the second service node is then scheduled to the first service node to meet its service instance requirements. Therefore, by shifting the resources used by the first service node from the entire service data center to a specific resource group (i.e., a subset of service nodes within the service data center), the stability risks arising from excessively large service fault domains, the ease with which faults can propagate within the data center, and overly coarse-grained failover operations are effectively mitigated.

[0043] In particular, the preferred embodiments of this application will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments of this application and the features in the embodiments can be combined with each other unless otherwise specified.

[0044] See Figure 1 The diagram shown illustrates an optional system architecture applicable to an embodiment of this application. This system architecture may include a service data center 101 and an instance invocation device 102. The service data center 101 may include multiple service nodes, i.e., the service data center 101 may be a node cluster (e.g., a Kubernetes cluster). Each service node may deploy one or more service instances, and each service instance is used to implement a corresponding service or business function.

[0045] It should be understood that each service node (or service instance) can be a physical or virtual resource. For example, each service node can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0046] In this embodiment, the instance invocation device 102 can be used to respond to an instance invocation request from any service node (e.g., the first service node) in the service data center 101, and obtain the resource group identifier of the target service instance to be invoked from the instance invocation request; the target resource group corresponding to the resource group identifier may include some service nodes among multiple service nodes in the service data center 101, and some service nodes may include the first service node; then, from a preset multiple resource groups, a target resource group matching the resource group identifier is determined, and a service instance list of the target resource group is obtained; the service instance list may include the service instance identifier of at least one service instance deployed on each service node in the partial service nodes; finally, if the service instance list includes the target instance identifier of the target service instance, the target service instance deployed on the service node (e.g., the second service node) in the target resource group is scheduled to the first service node.

[0047] The following describes the service instance invocation method provided by the exemplary embodiments of this application in conjunction with the above system architecture and with reference to the accompanying drawings. It should be noted that the above system architecture is only shown for the purpose of understanding the spirit and principles of this application, and the embodiments of this application are not limited in any way in this respect.

[0048] See Figure 2 The diagram illustrates the implementation flow of a service instance invocation method provided in this application embodiment. Taking an instance invocation device as an example, the method can be applied to a service room with multiple service nodes. The specific implementation flow of this method is as follows: S201: In response to the instance invocation request of the first service node, obtain the resource group identifier of the target service instance to be invoked from the instance invocation request.

[0049] The target resource group corresponding to the resource group identifier of the aforementioned target service instance may include: some service nodes from multiple service nodes, including the first service node. See also... Figure 3As shown, taking a service data center comprising 10 service nodes (e.g., Node.1 to Node.10) as an example, these 10 service nodes are divided into three resource groups: Resource Group 1, Resource Group 2, and Resource Group 3. Resource Group 1 may include Node.1, Node.4, Node.5, and Node.9; Resource Group 2 may include Node.2, Node.6, and Node.10; and Resource Group 3 may include Node.3, Node.7, and Node.8. The first service node can be Node.6, meaning the first service node belongs to Resource Group 2.

[0050] For example, during step S201, the instance invocation device can receive and respond to the instance invocation request from the first service node, and then obtain the resource group identifier of the target service instance to be invoked from the instance invocation request. In this way, after obtaining the resource group identifier of the target service instance, the instance invocation device can determine the resource group to which the service node deploying the target service instance belongs. Still using... Figure 3 Taking the three resource groups shown as an example, the resource group identifier of resource group 1 is Group.ID.1, the resource group identifier of resource group 2 is Group.ID.2, and the resource group identifier of resource group 3 is Group.ID.3. If the instance invocation device can receive and respond to the instance invocation request of the first service node (i.e., Node.6), then the resource group identifier of the target service instance can be obtained from the instance invocation request as Group.ID.2, which is the resource group identifier of resource group 2.

[0051] In one optional implementation, before executing step S201, the instance calling device can obtain the location distribution of multiple service nodes in the service room and the node response time corresponding to each of the multiple service nodes; then, based on the location distribution and the response time of multiple nodes, the multiple service nodes are divided into multiple resource groups; finally, different resource group identifiers are set for each of the multiple resource groups, and the multiple service nodes are associated with the corresponding resource group identifiers.

[0052] The response time of each node can characterize the request response speed of the corresponding service node. The aforementioned location distribution can be used to determine the location coordinates of multiple service nodes in the service room. That is, the aforementioned location distribution can be used to indicate the location coordinates of multiple service nodes in the service room. Each resource group includes one or more service nodes.

[0053] Optionally, when the instance calling device divides multiple service nodes into multiple resource groups based on location distribution and response time of multiple nodes, it can combine the reference coordinates of the service room to determine the coordinate distance between the location coordinates of each service node in the service room and the reference coordinates, and combine at least one preset response time interval to determine the response time interval corresponding to each of the multiple nodes. Then, based on the coordinate distances and response time intervals corresponding to each service node, the multiple service nodes are divided into multiple resource groups. For example, based on the distance intervals to which each coordinate distance belongs and the response time intervals corresponding to each service node, the multiple service nodes are divided into 3 resource groups, where the resource group identifiers of the aforementioned 3 resource groups are, in order: group-a, group-b, and group-c.

[0054] The reference coordinates mentioned above can be any location coordinate within the server room. For example, the reference coordinates can be the location coordinates of a service node, or they can be something other than the location coordinates of a service node.

[0055] Understandably, the instance invocation device associates multiple service nodes with corresponding resource group identifiers, that is, binds service nodes to predefined resource groups. Optionally, the instance invocation device can associate or bind the service node's Internet Protocol (IP) address, hostname, or asset ID identifier with a predefined resource group.

[0056] Furthermore, after the instance invocation device associates or binds multiple service nodes with their corresponding resource group identifiers, it can persistently store these associations or bindings for subsequent queries of the service data center's resource groups. It should be noted that the core data structure of these associations or bindings is a mapping table, such as a Map.<Resource.ID,Group.ID> This is used to store the mapping between resources (i.e., service nodes) and resource groups. For example, in scenarios based on container orchestration platforms such as Kubernetes, the mapping between service nodes and resource groups can be achieved by assigning specific labels to service nodes, such as topology.company.com / resource-group:group-a.

[0057] Based on the above approach, by dividing multiple service nodes into multiple resource groups according to their respective node locations in the service data center and their corresponding node response times, more granular and isolated resource clusters and service units (i.e., resource groups) can be created within a single service data center using computing resources (e.g., multiple service nodes). This limits the potential impact of faults to a single resource group, significantly reducing the "explosion radius" of faults, enabling refined fault isolation and capacity management, and thus improving the overall stability and availability of the service data center.

[0058] In one optional implementation, after the instance invocation device divides multiple service nodes into multiple resource groups based on location distribution and response time of multiple nodes, it can also perform the following operations for any one of the multiple service nodes in the service data center, such as the first service node: Construct a resource group list for the first service based on the multiple resource groups, and then deploy service instances of the first service in each resource group according to the service instance deployment strategy associated with the first service. The resource group list indicates that each resource group is used to deploy service instances of the first service; the service instance deployment strategy includes: the total number of service instances deployed corresponding to the first service and the proportion of service instances deployed in each resource group.

[0059] Taking the first service as service X and the multiple service nodes in the service data center as being divided into three resource groups: group-a, group-b, and group-c, the instance calling device can deploy the 20 service instances corresponding to service X into group-a, group-b, and group-c according to the service instance deployment ratio of "30% : 40% : 30%".

[0060] It should be noted that when deploying service instances, the instance scheduling device can first query the available resources in each resource group (e.g., the resource usage of each service node included in each resource group), and then schedule the service instances of the first service to the corresponding service nodes according to the service instance deployment strategy of the first service.

[0061] In one optional implementation, after the instance calling device divides multiple service nodes into multiple resource groups based on location distribution and response time of multiple nodes, it can also perform the following operations for any one of the resource groups, such as the first resource group: In response to a resource capacity adjustment request for the first resource group, it obtains the resource capacity adjustment amount for the first resource group from the resource capacity adjustment request, and then adjusts the initial resource capacity corresponding to at least one service based on the resource capacity ratio corresponding to at least one service in the first resource group and the resource capacity adjustment amount. The aforementioned at least one service of the first resource group is also the service that the first resource group can provide.

[0062] The aforementioned resource capacity adjustment amount can be either an increase or a decrease in the resource capacity of the first resource group, and this embodiment does not specifically limit this. Therefore, when the instance scheduling device expands or shrinks the first resource group, it will dynamically calculate and maintain the preset instance distribution ratio as much as possible to ensure that the capacity of each group is balanced.

[0063] Therefore, it can be seen that when deploying service instances and expanding or shrinking resource groups, the instance scheduling device can reasonably distribute service instances to different resource groups according to the preset service instance deployment strategy, and expand or shrink the various resource groups included in the service data center according to the preset capacity expansion and shrinking strategy.

[0064] In one optional implementation, during the process of obtaining the resource group identifier of the target service instance to be invoked from the instance invocation request, the instance scheduling device can also perform resource group identifier verification on the instance scheduling request and obtain an identifier verification result. If the identifier verification result indicates that the resource group identifier carried in the instance scheduling request is the resource group identifier of the target service instance, then the instance scheduling request is determined to be a scheduling request for the target service instance. Conversely, if the identifier verification result indicates that the resource group identifier carried in the instance scheduling request is not the resource group identifier of the target service instance, then indication information is generated. The aforementioned indication information is used to instruct the first service node to re-initiate the scheduling request carrying the resource group identifier of the target service instance.

[0065] It should be understood that the resource group identifier carried in the instance scheduling request of the first service node can also be called the resource group identifier of the service caller, and the resource group identifier corresponding to the target service instance to be called (or the resource group identifier corresponding to the second service node of the deployed target service instance) can also be called the resource group identifier of the service callee.

[0066] Based on the above approach, by adding a mandatory filtering condition of "resource group identifier of service caller = resource group identifier of service callee", the accuracy of service instance scheduling is ensured. In other words, filtering queries based on their own resource group identifiers achieve traffic isolation against application code intrusion and also ensure the security of the service data center to a certain extent.

[0067] S202: From a set of preset resource groups, determine the target resource group that matches the resource group identifier and obtain the list of service instances of the target resource group.

[0068] The service instance list mentioned above may include service instance identifiers of at least one service instance deployed on each service node in a subset of service nodes (or target resource group). The service instance list identifies the service instances that can run or the services that can be provided by each service node included in the target resource group.

[0069] Taking the aforementioned preset resource groups as five resource groups (e.g., Group.1 to Group.5) as an example, the resource group identifiers corresponding to the aforementioned five resource groups are, respectively: Group-A, Group-B, Group-C, Group-D, and Group-E. Assuming that after the instance scheduling device obtains the resource group identifier of the target service instance (e.g., Group-C), it can set the resource group Group.3 corresponding to resource group identifier Group-C as the target resource group. Furthermore, after determining that the target resource group is resource group Group.3, the instance scheduling device can obtain the list of service instances in resource group Group.3.

[0070] In one optional implementation, after obtaining the service instance list of the target resource group, the instance scheduling device can further perform performance verification on multiple service instances indicated by the service instance list, obtain performance verification results, and then determine whether to remove the abnormal instance identifier of the abnormal service instance from the service instance list based on the performance verification results. Here, the aforementioned performance verification results indicate whether the aforementioned multiple service instances are faulty or abnormal service instances.

[0071] In other words, if the performance verification results indicate that there are abnormal service instances among the multiple service instances, then the abnormal instance identifier of the abnormal service instance is removed from the service instance list. If the performance verification results indicate that there are no abnormal service instances among the multiple service instances, then it can be determined that all the service instances indicated by the service instance list are healthy service instances.

[0072] S203: If the service instance list includes the target instance identifier of the target service instance, the target service instance deployed on the second service node in the target resource group will be scheduled to the first service node.

[0073] Based on the service instance invocation methods described in steps S201-S203 above, taking a fault isolation scenario as an example, suppose one or more service nodes B1 in resource group-b of the service data center fail, causing the X@B and Y@B instances deployed on them to become invalid. Service calls from resource group-a (i.e., X@A calling Y) are unaffected because only Y@A instances within resource group-a are discovered and invoked. Similarly, service calls from resource group-c (i.e., X@C calling Y) are unaffected. Only other callers within resource group-b will find that the number of Y@B instances has decreased or completely disappeared when invoking Y, thus being affected. Therefore, a service node failure is successfully confined to resource group-b, which accounts for approximately 40% of the total capacity (or service unit), preventing the failure from spreading to the entire service data center. The remaining 60% of service capacity remains completely healthy. Operations personnel can calmly repair or cut off traffic to resource group-b without causing catastrophic impact on the entire service data center.

[0074] In one optional implementation, after obtaining the service instance list of the target resource group, if the target instance identifier is not included in the service instance list, the instance scheduling device can select a backup resource group from the aforementioned preset resource groups whose service instance list includes the target instance identifier. The target service instance deployed on the third service node in the backup resource group is then scheduled to the first service node. In this case, the instance scheduling device adopts a cross-resource group service instance invocation strategy, avoiding the problem of "hard isolation" where, by default, if a healthy callee service instance cannot be found among the multiple service instances in the same resource group, the instance invocation will directly fail. That is, through configurable degradation strategies, such as allowing cross-group invocation attempts under specific conditions (e.g., target service instance failure), and generating alarms, "soft isolation" is achieved.

[0075] See Figure 4The diagram illustrates the structural composition of an instance invocation device provided in this embodiment. This device may include a resource management module, a service deployment and orchestration module, and a service discovery and traffic scheduling module. The resource management module is responsible for logically grouping physical or virtual resources (e.g., service nodes). The service deployment and orchestration module, during service instance deployment and scaling, distributes service instances reasonably into different resource groups according to a preset service instance deployment strategy, and scales up or down the various resource groups within the service data center according to a preset capacity scaling strategy. The service deployment and orchestration module exists as an extension or plugin to the underlying orchestration system (e.g., KubernetesAoperator, Spinnaker Pipeline). For example, for Kubernetes, features such as Node Selector, Node Affinity, or Topology Spread Constraints, combined with the Node Labels applied by the resource management module, can precisely control the deployment location of service instances (or container groups), thereby achieving binding and proportional control between service instances (or service nodes) and resource groups. The service discovery and traffic scheduling module is primarily used to ensure intra-group invocation and inter-group isolation. When creating a service instance, the service deployment and orchestration module injects the resource group identifier value of the service node containing the service instance into the service instance itself via the Downward API or environment variables, for the instance to read at startup. Additionally, see [link to relevant documentation]. Figure 5 The diagram illustrates a specific process for service instance scheduling provided in this embodiment. During service instance scheduling, the instance scheduling device can also implement service proxy discovery / client / modification, which requires extending the client of the remote procedure call (RPC) framework or the sidecar proxy of the service mesh. For example, the service discovery logic can be extended by adding a step of "obtaining its own Group.ID and using it as a filtering parameter" before initiating a request to the service registry. It should also be noted that the service registry needs to support metadata-based filtering and querying functions.

[0076] In summary, the service instance invocation method provided in this application divides the multiple service nodes in the service data center into multiple resource groups. When a first service node invokes a target service instance, it can determine the second service node deploying the target service instance from the resource group corresponding to the resource group identifier of the target service instance. The target service instance deployed by the second service node is then scheduled to the first service node to meet the service instance requirements of the first service node. Therefore, adjusting the resources used by the first service node from the entire service data center to a specific resource group (i.e., a portion of the service nodes in the service data center) effectively improves the stability risks caused by excessively large service fault domains, easy fault propagation within the data center, and overly coarse-grained fault switching operations. In other words, through the service instance discovery and traffic scheduling mechanism, it ensures that invocations between service instances are prioritized or completed only within the same resource group. Thus, when any resource group fails, its impact is strictly limited to that resource group, preventing the fault from spreading to other resource groups. This achieves fine-grained fault isolation, significantly reduces the capacity impact during service data center fault switching, and thereby greatly improves the overall stability and availability of the service data center.

[0077] Furthermore, based on the same technical concept, embodiments of this application provide a service instance invocation apparatus, which is used to implement the above-described method flow of embodiments of this application. See also... Figure 6 As shown, the service instance invocation device 600 includes: a request parsing module 601, a list acquisition module 602, and an instance scheduling module 603, wherein: The request parsing module 601 is used to respond to the instance call request of the first service node and obtain the resource group identifier of the target service instance to be called from the instance call request; the target resource group corresponding to the resource group identifier includes some service nodes among multiple service nodes, and some service nodes include the first service node; The list acquisition module 602 is used to determine the target resource group that matches the resource group identifier from a plurality of preset resource groups, and to obtain the service instance list of the target resource group; the service instance list includes: the service instance identifier of at least one service instance deployed on each service node in the partial service nodes; The instance scheduling module 603 is used to schedule the target service instance deployed on the second service node in the target resource group to the first service node if the target service instance is included in the service instance list.

[0078] In an optional embodiment, before responding to the instance invocation request of the first service node, the list retrieval module 602 is further configured to: Obtain the location distribution of multiple service nodes in the service data center and the node response time corresponding to each service node; where the node response time represents the request response speed of the corresponding service node; Based on location distribution and response time of multiple nodes, multiple service nodes are divided into multiple resource groups; Set different resource group identifiers for multiple resource groups, and associate multiple service nodes with the corresponding resource group identifiers.

[0079] In an optional embodiment, after dividing multiple service nodes into multiple resource groups based on location distribution and response time of multiple nodes, the list retrieval module 602 is further configured to: For each of the multiple services in the server room, perform the following operations: A resource group list for the first service is constructed based on multiple resource groups; wherein, the first service is any one of the multiple services, and the resource group list indicates that each resource group is used to deploy service instances of the first service; Based on the service instance deployment strategy associated with the first service, service instances of the first service are deployed in each resource group; wherein, the service instance deployment strategy includes: the total number of service instances deployed corresponding to the first service and the service instance deployment ratio corresponding to each resource group.

[0080] In an optional embodiment, after dividing multiple service nodes into multiple resource groups based on location distribution and response time of multiple nodes, the list retrieval module 602 is further configured to: Perform the following operations for each of the multiple resource groups: In response to a resource capacity adjustment request for the first resource group, the resource capacity adjustment amount for the first resource group is obtained from the resource capacity adjustment request; wherein the first resource group is any one of multiple resource groups. Based on the resource capacity percentage of at least one service in the first resource group and the resource capacity adjustment amount, the initial resource capacity of at least one service is adjusted.

[0081] In an optional embodiment, during the process of obtaining the resource group identifier of the target service instance to be invoked from the instance invocation request, the list retrieval module 602 is further configured to: Perform resource group identifier verification on instance scheduling requests and obtain the identifier verification result; If the identifier verification result indicates that the resource group identifier carried in the instance scheduling request is the resource group identifier of the target service instance, then the instance scheduling request is determined to be a scheduling request for the target service instance. If the identifier verification result indicates that the resource group identifier carried in the instance scheduling request is not the resource group identifier of the target service instance, then an indication message is generated; the indication message is used to instruct the first service node to re-initiate the scheduling request carrying the resource group identifier of the target service instance.

[0082] In an optional embodiment, after obtaining the list of service instances of the target resource group, the list acquisition module 602 is further configured to: The performance of multiple service instances indicated by the service instance list is verified to obtain the performance verification results; the performance verification results indicate whether the multiple service instances are abnormal service instances with faults. If the performance verification results indicate that there are abnormal service instances among multiple service instances, then the abnormal instance identifier of the abnormal service instance will be removed from the service instance list.

[0083] In an optional embodiment, after obtaining the list of service instances for the target resource group, the instance scheduling module 603 is further configured to: If the target instance identifier is not included in the service instance list, then alternative resource groups whose service instance lists include the target instance identifier will be selected from multiple resource groups. The target service instance deployed on the third service node in the standby resource group will be scheduled to the first service node.

[0084] Based on the description of the method and apparatus embodiments above, an exemplary embodiment of the present invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, which, when executed by the at least one processor, causes the electronic device to perform the method according to an embodiment of the present invention.

[0085] This application also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0086] This application also provides a computer program product, including a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0087] See Figure 7The diagram shown below illustrates the structure of an electronic device 700 that can serve as a server or client in this application, and is an example of a hardware device that can be applied to various aspects of this application. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0088] like Figure 7 As shown, the electronic device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 702 or a computer program loaded from a storage unit 708 into a random access memory (RAM) 703. The RAM 703 may also store various programs and data required for the operation of the device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0089] Multiple components in electronic device 700 are connected to I / O interface 705, including: input unit 706, output unit 707, storage unit 708, and communication unit 709. Input unit 706 can be any type of device capable of inputting information to electronic device 700. Input unit 706 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 707 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 708 may include, but is not limited to, disk and optical disk. Communication unit 709 allows electronic device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers and / or chipsets, such as Bluetooth devices, WiFi devices, worldwide interoperability for microwave access (WiMax) devices, cellular communication devices, and / or the like.

[0090] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above. For example, in some embodiments, the above-described service instance invocation method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 700 via ROM 702 and / or communication unit 709. In some embodiments, the computing unit 701 can be configured to perform the above-described service instance invocation method by any other suitable means (e.g., by means of firmware).

[0091] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0092] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM) or flash memory, optical fibers, compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0093] As used in this application, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device, PLD) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0094] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0095] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0096] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

[0097] Furthermore, it should be understood that the above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of the invention. Therefore, any equivalent variations made in accordance with the claims of this invention are still within the scope of this application.

Claims

1. A method for invoking a service instance, characterized in that, Applied to service data centers with multiple service nodes, including: In response to an instance invocation request from the first service node, the resource group identifier of the target service instance to be invoked is obtained from the instance invocation request; the target resource group corresponding to the resource group identifier includes some of the service nodes among the plurality of service nodes, and the some service nodes include the first service node; From a plurality of preset resource groups, determine the target resource group that matches the resource group identifier, and obtain a service instance list of the target resource group; the service instance list includes: service instance identifiers of at least one service instance deployed on each of the service nodes in the subset of service nodes; If the service instance list includes the target instance identifier of the target service instance, then the target service instance deployed on the second service node in the target resource group will be scheduled to the first service node.

2. The method as described in claim 1, characterized in that, Before responding to the instance call request of the first service node, the method further includes: The location distribution of the multiple service nodes in the service room and the node response time corresponding to each of the multiple service nodes are obtained; wherein, the node response time represents the request response speed of the corresponding service node; Based on the location distribution and the response time of multiple nodes, the multiple service nodes are divided into the multiple resource groups; Different resource group identifiers are set for the multiple resource groups, and the multiple service nodes are associated with the corresponding resource group identifiers.

3. The method as described in claim 2, characterized in that, After dividing the multiple service nodes into multiple resource groups based on the location distribution and the response time of multiple nodes, the method further includes: For each of the multiple services in the aforementioned server room, perform the following operations respectively: A resource group list for a first service is constructed based on the plurality of resource groups; wherein, the first service is any one of the plurality of services, and each resource group indicated by the resource group list is used to deploy service instances of the first service; Based on the service instance deployment strategy associated with the first service, service instances of the first service are deployed in each resource group; wherein, the service instance deployment strategy includes: the total number of service instances deployed corresponding to the first service and the service instance deployment ratio corresponding to each resource group.

4. The method as described in claim 2, characterized in that, After dividing the multiple service nodes into multiple resource groups based on the location distribution and the response time of multiple nodes, the method further includes: For each of the aforementioned resource groups, perform the following operations: In response to a resource capacity adjustment request for a first resource group, the resource capacity adjustment amount for the first resource group is obtained from the resource capacity adjustment request; wherein, the first resource group is any one of the plurality of resource groups. Based on the resource capacity percentage corresponding to at least one service in the first resource group and the resource capacity adjustment amount, the initial resource capacity corresponding to each of the at least one service is adjusted.

5. The method as described in claim 1, characterized in that, The process of obtaining the resource group identifier of the target service instance to be invoked from the instance invocation request also includes: The instance scheduling request is subjected to resource group identifier verification to obtain the identifier verification result; If the identifier verification result indicates that the resource group identifier carried in the instance scheduling request is the resource group identifier of the target service instance, then the instance scheduling request is determined to be a scheduling request for the target service instance. If the identifier verification result indicates that the resource group identifier carried in the instance scheduling request is not the resource group identifier of the target service instance, then an indication message is generated; the indication message is used to instruct the first service node to re-initiate a scheduling request carrying the resource group identifier of the target service instance.

6. The method according to any one of claims 1-5, characterized in that, After obtaining the list of service instances for the target resource group, the process further includes: The performance of multiple service instances indicated by the service instance list is verified to obtain the performance verification result; the performance verification result indicates whether the multiple service instances are abnormal service instances with faults. If the performance verification result indicates that there is an abnormal service instance among the multiple service instances, then the abnormal instance identifier of the abnormal service instance is removed from the service instance list.

7. The method according to any one of claims 1-5, characterized in that, After obtaining the list of service instances for the target resource group, the process further includes: If the target instance identifier is not included in the service instance list, then alternative resource groups whose service instance lists include the target instance identifier are selected from the plurality of resource groups; The target service instance deployed on the third service node in the backup resource group is scheduled to the first service node.

8. A service instance invocation device, characterized in that, Applied to service data centers with multiple service nodes, including: The request parsing module is used to respond to the instance call request of the first service node and obtain the resource group identifier of the target service instance to be called from the instance call request; the target resource group corresponding to the resource group identifier includes some service nodes among the plurality of service nodes, and the some service nodes include the first service node; The list acquisition module is used to determine the target resource group that matches the resource group identifier from a plurality of preset resource groups, and to acquire a list of service instances of the target resource group; the list of service instances includes: service instance identifiers of at least one service instance deployed on each of the service nodes in the partial service nodes; The instance scheduling module is used to schedule the target service instance deployed by the second service node in the partial service nodes to the first service node if the service instance list includes the target service instance.

9. An electronic device, characterized in that, include: processor; A memory storing a program; wherein the program includes instructions that, when executed by the processor, cause the processor to perform the method as described in any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method as described in any one of claims 1-7.

Images