Service node determination method and device, equipment, medium and product

Abstract

The embodiment of the invention discloses a service node determination method and device, equipment, a medium and a product, and the method comprises the steps: deploying a plurality of service nodes corresponding to each service in the same namespace of a Kubernetes cluster for each service with a mutual calling relationship; based on the name information and the port information of the service, creating a Kubernetes service object corresponding to each service; based on the Kubernetes service object of each service, accessing each service to the same registration center; when a service calling request sent by a service consumer is received, obtaining a service provider name corresponding to the service calling request from the registration center; according to the method, the target service node for providing the service for the service consumer is determined based on the name of the service provider and each Kubernetes service object, so that the service consumer can call the service node capable of normally providing the service even in the online and offline process of the service node, and the continuity of the service is ensured.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a service node determination method, device, equipment, medium and product. Background Art

[0002] With the deepening of digital transformation, microservice architecture has become the mainstream architecture model of enterprises. In the microservice architecture model, the registration center is the most basic and important component. The registration center is essentially to decouple microservices, mainly used to provide service discovery and registration, and realize mutual calls between services. The basic principle of the registration center is: service providers register with the registration center, the registration center maintains metadata information such as the service provider IP address list, and the service consumer subscribes to the registration center and caches the obtained service provider IP address list information locally. When a consumer calls a service, it will first obtain a service node from the locally cached IP address list to provide services to the service consumer.

[0003] However, in actual production environments, service consumers and service providers are generally highly available and have multiple instances. When a service provider goes online or offline, the service node of the current service provider cannot provide services normally. However, the service provider IP address list cached by the service consumer may not be updated in a timely manner, resulting in the service consumer calling the service and requesting the node that is being upgraded, which causes the request to fail and production problems to occur. Based on this, the above method cannot achieve lossless online and offline services during the process of the service node of a certain type of service going online or offline, resulting in the service node called by the service consumer may fail to call, and there is a technical problem of poor service continuity. Summary of the invention

[0004] The present invention provides a service node determination method, device, equipment, medium and product, so that when a service node goes online or offline, a service consumer can call a service node that can provide services normally, thereby ensuring the continuity of the service.

[0005] In a first aspect, an embodiment of the present invention provides a method for determining a service node, the method comprising:

[0006] For at least one service that has a mutual calling relationship, deploy at least one service node corresponding to each service in the same namespace of the Kubernetes cluster;

[0007] For each of the services, based on the service name information and service port information of the service, a Kubernetes service object corresponding to each of the services is created; wherein the Kubernetes service object includes a mapping relationship between the object name information of the service and the corresponding service node information;

[0008] Based on the Kubernetes service object corresponding to each service, each service is connected to the same registration center;

[0009] When receiving a service call request from a service consumer, obtaining the service provider name corresponding to the service call request from the registration center;

[0010] Based on the service provider name and each of the Kubernetes service objects, a target service node for providing services to the service consumer is determined.

[0011] In a second aspect, an embodiment of the present invention further provides a service node determination device, the device comprising:

[0012] A service node deployment module is used to deploy at least one service node corresponding to each service in the same namespace of the Kubernetes cluster for at least one service having a mutual calling relationship;

[0013] A service object determination module is used to create a Kubernetes service object corresponding to each of the services based on the service name information and service port information of the service; wherein the Kubernetes service object includes a mapping relationship between the object name information of the service and the corresponding service node information;

[0014] A registration center access module, used to connect each of the services to the same registration center based on the Kubernetes service object corresponding to each of the services;

[0015] A service request receiving module, configured to obtain the name of the service provider corresponding to the service call request from the registration center when receiving a service call request from a service consumer;

[0016] A service node determination module is used to determine a target service node for providing services to the service consumer based on the service provider name and each of the Kubernetes service objects.

[0017] In a third aspect, an embodiment of the present invention further provides an electronic device, the electronic device comprising:

[0018] one or more processors;

[0019] a storage device for storing one or more programs,

[0020] When one or more programs are executed by one or more processors, the one or more processors implement a service node determination method as described in any one of the embodiments of the present invention.

[0021] In a fourth aspect, an embodiment of the present invention further provides a storage medium comprising computer executable instructions, which, when executed by a computer processor, are used to perform a service node determination method as described in any one of the embodiments of the present invention.

[0022] The technical solution of the embodiment of the present invention, for at least one service with a mutual calling relationship, at least one service node corresponding to each service is deployed in the same namespace of the Kubernetes cluster, and then, for each service, based on the service name information and service port information of the service, a Kubernetes service object corresponding to each service is created, wherein the Kubernetes service object includes a mapping relationship between the object name information of the service and the corresponding service node information, and based on the Kubernetes service object corresponding to each service, each service is connected to the same registration center. Then, when a service call request issued by a service consumer is received, the service provider name corresponding to the service call request is obtained from the registration center, so that the target service node for providing services to the service consumer can be determined based on the service provider name and each Kubernetes service object. The technical solution of this embodiment, through a method based on service name registration, specifies its registration address as the corresponding Kubernetes service object name when the service registers with the registration center, and in the process of the service node going online and offline, avoids the problem of untimely update of the IP address list, so that the service consumer requests the service node being upgraded when calling the service, and can allow the service consumer to call the service node that can provide services normally, ensuring the continuity of the service. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the following briefly introduces the drawings required to describe the embodiments. Obviously, the drawings introduced are only drawings of a part of the embodiments to be described in the present invention, rather than all the drawings. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0024] Figure 1 A schematic diagram of a flow chart of a service node determination method provided by an embodiment of the present invention;

[0025] Figure 2 A schematic diagram of the structure of a service node determination device provided by an embodiment of the present invention;

[0026] Figure 3 The present invention is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0027] Figure 1This is a flow chart of a service node determination method provided in an embodiment of the present invention. This embodiment can be applicable to any microservice architecture system. The method can be executed by a service node determination device, which can be implemented in the form of software and / or hardware. The hardware can be an electronic device, such as a mobile terminal, a PC or a server.

[0028] The technical solution provided in this embodiment can be applied to any microservice architecture system. The microservice architecture system includes multiple services that can implement different service functions. Each service in the microservice architecture is an independent, autonomous, reusable software module, which usually implements a specific business function. Each service has its own code, data, and resources, and can be deployed, expanded, and upgraded independently. Services interact and collaborate through lightweight communication mechanisms. In order to improve the request response efficiency of the microservice architecture system, a service can be divided into multiple service nodes, each of which can provide the same service. Each service node can be understood as a service instance.

[0029] In an actual production environment, service consumers and service providers are generally highly available and multi-instance. When a service provider goes online or offline, the current service provider instance cannot provide services normally. However, the service provider IP address list cached by the service consumer may not be updated in a timely manner, which may cause the service consumer to request the service provider instance that is being upgraded when calling the service, and the request fails, resulting in production problems. In order to avoid this situation, existing solutions generally upgrade or stop services during off-peak business periods, resulting in service discontinuity and affecting normal customer use. In order to solve the problem that in the microservice architecture mode, the service provider cannot provide lossless services during the process of going online and offline, resulting in the possibility of call failure when the service consumer calls the service. An embodiment of the present invention provides a service node determination method, which aims to allow service consumers to call service nodes that can provide services normally during the process of service node going online and offline, thereby ensuring service continuity.

[0030] like Figure 1 As shown, the service node determination method includes:

[0031] S110. For at least one service having a mutual calling relationship, deploy at least one service node corresponding to each service in the same namespace of the Kubernetes cluster.

[0032] Among them, a Kubernetes cluster is a collection of physical or virtual machines that are organized into a single computing resource pool and run the Kubernetes platform on it. The main purpose of a Kubernetes cluster is to provide high availability, scalability, and fault tolerance to ensure that applications can always run normally.

[0033] In the Kubernetes platform, namespace is a logical partitioning mechanism used to divide the resources in the cluster into different environments or teams to achieve resource isolation and management. An independent namespace allows multiple users to work independently in the same Kubernetes cluster without resource conflicts.

[0034] In this embodiment, multiple services for executing certain actual business can be pre-built, each service corresponds to multiple service units, and these services can call each other through pre-set calling rules. On this basis, multiple service nodes corresponding to these services can be deployed in the same namespace of the Kubernetes cluster. The purpose of this setting is to deploy these service nodes with calling relationships in the same namespace, so as to facilitate efficient mutual calls between different types of service nodes.

[0035] Exemplarily, four services with mutual calling relationships are pre-configured to realize certain actual business. These services include Class A services, Class B services, Class C services, and Class D services. Service nodes A1, A2, A3, and A4 corresponding to Class A services can all provide Class A service functions; service nodes B1, B2, and B3 corresponding to Class B services can all provide Class B service functions; service nodes C1, C2, and C3 corresponding to Class C services can all provide Class C service functions; service nodes D1 and D2 corresponding to Class D services can all provide Class D service functions. Based on this, the service nodes corresponding to these services can be deployed in the same namespace of the Kubernetes cluster.

[0036] S120. For each service, based on the service name information and service port information of the service, create a Kubernetes service object corresponding to each service.

[0037] The service name information may be text information or character information describing a certain type of service function. The service port information refers to the port number and related data used by a certain type of service in network communication.

[0038] Among them, the Kubernetes service object can be understood as a Service under the Kubernetes architecture. In the Kubernetes architecture, a Service is a logical abstraction used to access one or more Pods. It provides a stable IP address and DNS name for a group of Pods so that other applications or users can access them. Service allows Pods to be added or deleted dynamically without affecting the availability of the service. Service also supports load balancing, which can distribute requests to multiple Pods to improve scalability and reliability.

[0039] In this embodiment, the Kubernetes service object includes a mapping relationship between the object name information of the service and the corresponding service node information. The object name information refers to the name of the Kubernetes service object corresponding to a service, and the service node information refers to the identification information of at least one service node corresponding to the service, for example, the service node information may be the IP address and / or access port corresponding to the service node.

[0040] Specifically, a Kubernetes service object corresponding to each type of service can be created. In this embodiment, the creation method of the Kubernetes service object corresponding to each type of service is the same. Here, any type of service is used as the current service, and the current service is used as an example for exemplary description.

[0041] In this embodiment, based on the service name information and service port information of the service, the specific implementation method of creating a Kubernetes service object corresponding to each service may include: determining the object name information based on the service name information of the current service; determining the object port information based on the service port information of the current service; building a mapping relationship between the object name information of the service and the corresponding service node information; creating a Kubernetes service object corresponding to the current service based on the object name information, the object port information and the mapping relationship. The port protocol of the Kubernetes service object corresponding to the current service can also be set to the transmission control protocol, and the access method of the Kubernetes service object corresponding to the current service can be set to the cluster internal IP address access method or the node port access method.

[0042] In the present embodiment, for the current service, the service name information and service port information corresponding to the current service are preset and configured, and are easily obtained here. Based on this, the service name information corresponding to the current service can be set to the object name information of the Kubernetes service object, and the service port information corresponding to the current service can be set to the object port information of the Kubernetes service object. According to the various service nodes corresponding to the current service, a mapping relationship between the object name information of the current service and the corresponding service node information can be constructed. After completing the above settings and obtaining the mapping relationship, the Kubernetes service object corresponding to the current service can be obtained. Further, the port protocol and access method of the Kubernetes service object corresponding to the current service can be set. In the present embodiment, the port protocol of the Kubernetes service object corresponding to the current service can be set to the transmission control protocol, and the access method of the Kubernetes service object corresponding to the current service can be set to the cluster internal IP address access method or the node port access method. Based on the same creation method, the Kubernetes service object corresponding to each type of service can be obtained.

[0043] S130. Based on the Kubernetes service object corresponding to each service, connect each service to the same registration center.

[0044] Among them, the registry is a key component in the microservice architecture, which provides functions such as service registration, service discovery, service monitoring and configuration management. In a distributed system, the registry makes communication and management between services easier and more efficient.

[0045] In this embodiment, various services can be connected to the same registration center, so that when executing various services, the relevant information corresponding to the service provider can be determined according to the information recorded in the registration center. For a certain type of service, the object name information of the Kubernetes service object can be used as the registration IP, and the object port information of the Kubernetes service object can be used as the registration port information to connect this type of service to the pre-configured registration center.

[0046] Specifically, based on the Kubernetes service object corresponding to each service, the specific implementation method of connecting each service to the same registration center may include: for each service, based on the object name information and object port information corresponding to the current Kubernetes service object, determining the registration configuration information corresponding to the current service; based on the registration configuration information corresponding to each service, connecting each service to the same registration center.

[0047] In this embodiment, when a service is connected to the registration center, it is necessary to determine the configuration file corresponding to the service, in which the registration IP and port information of the service need to be set. Based on this, for a certain type of service, the registration configuration information can be determined according to the service port information and service port information of the Kubernetes service object, so that the service of this type is connected to the registration center according to the registration configuration file. Based on the same method, each type of service can be connected to the same registration center.

[0048] S140: When a service call request from a service consumer is received, the service provider name corresponding to the service call request is obtained from the registration center.

[0049] The service call request refers to the call request information from a service node during the operation of the microservice architecture system, which is intended to achieve specific business goals or requirements. The service consumer is the service node that generates the service call request at the current moment. The service provider name refers to the name information corresponding to the service category called by the service consumer.

[0050] In this embodiment, when the service node corresponding to a certain type of service generates a service call request during the operation of the microservice architecture system, the service node is the service consumer at this time. The service call request carries the request method and request parameter information, based on which it can be determined which type of service the service consumer needs to call. Since the registration center includes registration information corresponding to various types of services, the name information corresponding to such services can be obtained from the registration center (the name information is actually the object name information of the Kubernetes service object of such services), which is the service provider name.

[0051] For example, the A1 service node of the A-type service sends a service call request. At this time, the A1 service node is the service consumer. According to the request method and request parameter information carried in the service call request, it can be determined what type of service the service consumer needs to call, for example, the B-type service. At this time, the registration information of the service call B-type service can be obtained from the registration center, that is, the service provider name.

[0052] S150: Based on the service provider name and each Kubernetes service object, determine a target service node for providing services to the service consumer.

[0053] The target service node is the service node that is finally determined to provide services to the service consumer.

[0054] In this embodiment, by querying the object name information corresponding to each Kubernetes service object according to the service provider name, the target Kubernetes service object corresponding to the service provider can be obtained, so that the target service node for providing services to the service consumer can be determined by load balancing based on the service nodes recorded in the target Kubernetes service object.

[0055] Optionally, the specific implementation method of determining the target service node for providing services to the service consumer based on the service provider name and each Kubernetes service object may include: determining the target Kubernetes service object from each Kubernetes service object based on the service provider name and the object name information corresponding to each Kubernetes service object; determining the target service node for providing services to the service consumer from each service node corresponding to the target Kubernetes service object based on the load balancing policy of the target Kubernetes service object.

[0056] In this embodiment, the object name information corresponding to each Kubernetes service object can be queried through the service provider name. When the target object name information consistent with the service provider name is obtained, the Kubernetes service object corresponding to the target object name information can be determined as the target Kubernetes service object. Further, according to the load balancing strategy of the target Kubernetes service object, the target service node for providing services to the service consumer can be determined from the service nodes corresponding to the target Kubernetes service object.

[0057] The technical solution of the embodiment of the present invention, for at least one service with a mutual calling relationship, at least one service node corresponding to each service is deployed in the same namespace of the Kubernetes cluster, and then, for each service, based on the service name information and service port information of the service, a Kubernetes service object corresponding to each service is created, wherein the Kubernetes service object includes a mapping relationship between the object name information of the service and the corresponding service node information, and based on the Kubernetes service object corresponding to each service, each service is connected to the same registration center. Then, when a service call request issued by a service consumer is received, the service provider name corresponding to the service call request is obtained from the registration center, so that the target service node for providing services to the service consumer can be determined based on the service provider name and each Kubernetes service object. The technical solution of this embodiment, through a method based on service name registration, specifies its registration address as the corresponding Kubernetes service object name when the service registers with the registration center, and in the process of the service node going online and offline, avoids the problem of untimely update of the IP address list, so that the service consumer requests the service node being upgraded when calling the service, and can allow the service consumer to call the service node that can provide services normally, ensuring the continuity of the service.

[0058] Embodiment 2

[0059] Figure 2 This is a structural diagram of a service node determination device provided by an embodiment of the present invention, the device includes: a service node deployment module 210, a service object determination module 220, a registration center access module 230, a service request receiving module 240 and a service node determination module 250.

[0060] The service node deployment module 210 is used to deploy at least one service node corresponding to each service in the same namespace of the Kubernetes cluster for at least one service having a mutual calling relationship;

[0061] A service object determination module 220 is used to create a Kubernetes service object corresponding to each of the services based on the service name information and service port information of the service; wherein the Kubernetes service object includes a mapping relationship between the object name information of the service and the corresponding service node information;

[0062] A registration center access module 230, configured to access each of the services to the same registration center based on the Kubernetes service object corresponding to each of the services;

[0063] The service request receiving module 240 is used to obtain the service provider name corresponding to the service call request from the registration center when receiving the service call request sent by the service consumer;

[0064] The service node determination module 250 is used to determine a target service node for providing services to the service consumer based on the service provider name and each of the Kubernetes service objects.

[0065] Based on the above device, optionally, the service object determination module 220 includes:

[0066] An object name determining unit, configured to determine object name information based on the service name information of the current service;

[0067] an object port determination unit, configured to determine object port information based on the service port information of the current service;

[0068] A mapping relationship determination unit, used to construct a mapping relationship between the object name information of the service and the corresponding service node information;

[0069] A service object construction unit is used to create a Kubernetes service object corresponding to the current service based on the object name information, the object port information and the mapping relationship.

[0070] Based on the above-mentioned device, optionally, the service object determination module 220 is also used to set the port protocol of the Kubernetes service object corresponding to the current service to the transmission control protocol; and set the access method of the Kubernetes service object corresponding to the current service to the cluster internal IP address access method or the node port access method.

[0071] Based on the above device, optionally, the registration center access module 230 includes:

[0072] A configuration information determining unit, configured to determine, for each of the services, registration configuration information corresponding to the current service based on the object name information and the object port information corresponding to the current Kubernetes service object;

[0073] The registration center access unit is used to access each of the services to the same registration center based on the registration configuration information corresponding to each of the services.

[0074] Based on the above device, optionally, the service node determination module 250 includes:

[0075] a target object determining unit, configured to determine a target Kubernetes service object from each of the Kubernetes service objects based on the service provider name and object name information corresponding to each of the Kubernetes service objects;

[0076] A target node determination unit is used to determine a target service node for providing services to the service consumer from each of the service nodes corresponding to the target Kubernetes service object based on the load balancing policy of the target Kubernetes service object.

[0077] The technical solution of the embodiment of the present invention, for at least one service with a mutual calling relationship, at least one service node corresponding to each service is deployed in the same namespace of the Kubernetes cluster, and then, for each service, based on the service name information and service port information of the service, a Kubernetes service object corresponding to each service is created, wherein the Kubernetes service object includes a mapping relationship between the object name information of the service and the corresponding service node information, and based on the Kubernetes service object corresponding to each service, each service is connected to the same registration center. Then, when a service call request issued by a service consumer is received, the service provider name corresponding to the service call request is obtained from the registration center, so that the target service node for providing services to the service consumer can be determined based on the service provider name and each Kubernetes service object. The technical solution of this embodiment, through a method based on service name registration, specifies its registration address as the corresponding Kubernetes service object name when the service registers with the registration center, and in the process of the service node going online and offline, avoids the problem of untimely update of the IP address list, so that the service consumer requests the service node being upgraded when calling the service, and can allow the service consumer to call the service node that can provide services normally, ensuring the continuity of the service.

[0078] The service node determination device provided in the embodiment of the present invention can execute the service node determination method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0079] It is worth noting that the various units and modules included in the above system are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of the functional units are only for the convenience of distinguishing each other, and are not used to limit the protection scope of the embodiments of the present invention.

[0080] Embodiment 3

[0081] Figure 3The present invention is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. Figure 3 A block diagram of an exemplary electronic device 30 suitable for implementing exemplary embodiments of the present invention is shown. Figure 3 The electronic device 30 shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0082] like Figure 3 As shown, the electronic device 30 is in the form of a general computing device. The components of the electronic device 30 may include but are not limited to: one or more processors or processing units 301, a system memory 302, and a bus 303 connecting different system components (including the system memory 302 and the processing unit 301).

[0083] Bus 303 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor or a local bus using any of a variety of bus structures. For example, these architectures include but are not limited to Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MAC) bus, Enhanced ISA bus, Video Electronics Standards Association (VESA) local bus and Peripheral Component Interconnect (PCI) bus.

[0084] The electronic device 30 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by the electronic device 30, including volatile and non-volatile media, removable and non-removable media.

[0085] The system memory 302 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 304 and / or cache memory 305. The electronic device 30 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 306 may be used to read and write non-removable, non-volatile magnetic media ( Figure 3 not shown, usually called a "hard drive"). Although Figure 3 Not shown in the figure, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk"), and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, a DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to the bus 303 via one or more data medium interfaces. The memory 302 may include at least one program product having a set (e.g., at least one) of program modules that are configured to perform the functions of the various embodiments of the present invention.

[0086] A program / utility 308 having a set (at least one) of program modules 307 may be stored, for example, in the memory 302, such program modules 307 including but not limited to an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment. The program modules 307 generally perform the functions and / or methods of the embodiments described herein.

[0087] The electronic device 30 may also communicate with one or more external devices 309 (e.g., keyboards, pointing devices, displays 810, etc.), may communicate with one or more devices that enable a user to interact with the electronic device 30, and / or may communicate with any device that enables the electronic device 30 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication may be performed through an input / output (I / O) interface 311. Furthermore, the electronic device 30 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) through a network adapter 312. As shown, the network adapter 312 communicates with other modules of the electronic device 30 through the bus 303. It should be understood that although Figure 3 Not shown, other hardware and / or software modules may be used in conjunction with the electronic device 30, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0088] The processing unit 301 executes various functional applications and page processing by running the program stored in the system memory 302, for example, implementing the service node determination method provided in the embodiment of the present invention.

[0089] Embodiment 4

[0090] An embodiment of the present invention further provides a storage medium including computer executable instructions, where the computer executable instructions are used to execute a service node determination method when executed by a computer processor, the method comprising:

[0091] For at least one service that has a mutual calling relationship, deploy at least one service node corresponding to each service in the same namespace of the Kubernetes cluster;

[0092] For each of the services, based on the service name information and service port information of the service, a Kubernetes service object corresponding to each of the services is created; wherein the Kubernetes service object includes a mapping relationship between the object name information of the service and the corresponding service node information;

[0093] Based on the Kubernetes service object corresponding to each service, each service is connected to the same registration center;

[0094] When receiving a service call request from a service consumer, obtaining the service provider name corresponding to the service call request from the registration center;

[0095] Based on the service provider name and each of the Kubernetes service objects, a target service node for providing services to the service consumer is determined.

[0096] The computer storage medium of the embodiment of the present invention can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.

[0097] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0098] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0099] Computer program code for performing the operation of embodiments of the present invention may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0100] Note that the above are only preferred embodiments of the present invention and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A method for determining a service node, characterized in that: include: For at least one service that has a mutual calling relationship, deploy at least one service node corresponding to each service in the same namespace of the Kubernetes cluster; For each of the services, based on the service name information and service port information of the service, a Kubernetes service object corresponding to each of the services is created; wherein the Kubernetes service object includes a mapping relationship between the object name information of the service and the corresponding service node information; Based on the Kubernetes service object corresponding to each service, each service is connected to the same registration center; When receiving a service call request from a service consumer, obtaining the service provider name corresponding to the service call request from the registration center; Based on the service provider name and each of the Kubernetes service objects, a target service node for providing services to the service consumer is determined.

2. The method according to claim 1, characterized in that The creating a Kubernetes service object corresponding to each of the services based on the service name information and service port information of the services includes: Determine object name information based on the service name information of the current service; Determine object port information based on the service port information of the current service; Constructing a mapping relationship between the object name information of the service and the corresponding service node information; Based on the object name information, the object port information, and the mapping relationship, create a Kubernetes service object corresponding to the current service.

3. The method according to claim 2, characterized in that Also includes: Set the port protocol of the Kubernetes service object corresponding to the current service to the Transmission Control Protocol; The access mode of the Kubernetes service object corresponding to the current service is set to the cluster internal IP address access mode or the node port access mode.

4. The method according to claim 3, characterized in that The step of connecting each of the services to the same registration center based on the Kubernetes service object corresponding to each of the services includes: For each of the services, based on the object name information and the object port information corresponding to the current Kubernetes service object, determine the registration configuration information corresponding to the current service; Based on the registration configuration information corresponding to each of the services, each of the services is connected to the same registration center.

5. The method according to claim 1, characterized in that The determining, based on the service provider name and each of the Kubernetes service objects, a target service node for providing services to the service consumer comprises: Determine a target Kubernetes service object from among the Kubernetes service objects based on the service provider name and the object name information corresponding to each of the Kubernetes service objects; Based on the load balancing policy of the target Kubernetes service object, a target service node for providing service to the service consumer is determined from the service nodes corresponding to the target Kubernetes service object.

6. A service node determination device, characterized in that: The device includes: A service node deployment module is used to deploy at least one service node corresponding to each service in the same namespace of the Kubernetes cluster for at least one service having a mutual calling relationship; A service object determination module is used to create a Kubernetes service object corresponding to each of the services based on the service name information and service port information of the service; wherein the Kubernetes service object includes a mapping relationship between the object name information of the service and the corresponding service node information; A registration center access module, used to connect each of the services to the same registration center based on the Kubernetes service object corresponding to each of the services; A service request receiving module, configured to obtain the name of the service provider corresponding to the service call request from the registration center when receiving a service call request from a service consumer; A service node determination module is used to determine a target service node for providing services to the service consumer based on the service provider name and each of the Kubernetes service objects.

7. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can perform the service node determination method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the service node determination method according to any one of claims 1 to 5 when executed.

9. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the computer program implements the service node determination method according to any one of claims 1 to 5.

Images