CN119576644A - A method, device, equipment, medium and product for determining a service node - Google Patents
A method, device, equipment, medium and product for determining a service node Download PDFInfo
- Publication number
- CN119576644A CN119576644A CN202411622975.8A CN202411622975A CN119576644A CN 119576644 A CN119576644 A CN 119576644A CN 202411622975 A CN202411622975 A CN 202411622975A CN 119576644 A CN119576644 A CN 119576644A
- Authority
- CN
- China
- Prior art keywords
- service
- kubernetes
- node
- information
- services
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Quality & Reliability (AREA)
- Computer Hardware Design (AREA)
- Computer And Data Communications (AREA)
Abstract
The embodiment of the invention discloses a service node determining method, a device, equipment, a medium and a product, wherein for each service with a calling relationship, a plurality of service nodes corresponding to each service are deployed under the same name space of a Kubernetes cluster, a Kubernetes service object corresponding to each service is created based on name information and port information of the service, each service is accessed into the same registry based on the Kubernetes service object of each service, when a service calling request sent by a service consumer is received, a service provider name corresponding to the service calling request is acquired from the registry, a target service node for providing the service for the service consumer is determined based on the service provider name and each Kubernetes service object, and even in the process of accessing the service node, the service consumer can call the service node capable of normally providing the service, and the continuity of the service is ensured.
Description
Technical Field
The present invention relates to the field of data processing technologies, and in particular, to a method, an apparatus, a device, a medium, and a product for determining a service node.
Background
With the deep advancement of digital transformation, the micro-service architecture becomes a mainstream architecture mode of enterprises. In the micro-service architecture mode, a registry is the most basic and important component, and is essentially used for decoupling micro-services, and is mainly used for providing service discovery and registration, so as to realize the mutual call between services. The basic principle of the registry is that a service provider registers with the registry, the registry maintains metadata information such as an IP address list of the service provider, a service consumer subscribes to the registry, and the acquired IP address list information of the service provider is cached locally. When the consumer calls the service, a service node is preferentially obtained from the locally cached IP address list to provide the service for the service consumer.
However, in a practical production environment, service consumers and service providers are generally highly available, multi-instance. When a service provider goes online or offline, the service node of the current service provider cannot normally provide services. However, the service provider IP address list cached by the service consumer may not be updated timely, resulting in a failure of the request to the node being upgraded when the service consumer invokes the service, and a production problem. Based on the above, in the process of connecting and disconnecting the service node of a certain type of service, the service can not be connected and disconnected in a lossless manner, so that the service node called by a service consumer can have a call failure, and the technical problem of poor service continuity exists.
Disclosure of Invention
The invention provides a service node determining method, a device, equipment, a medium and a product, which can enable a service consumer to call a service node capable of normally providing service in the process of connecting the service node to the internet, thereby ensuring the continuity of the service.
In a first aspect, an embodiment of the present invention provides a service node determining method, where the method includes:
for at least one service with a calling relationship, deploying at least one service node corresponding to each service under the same naming space of the Kubernetes cluster;
For each service, based on service name information and service port information of the service, creating a Kubernetes service object corresponding to each service, wherein the Kubernetes service object comprises a mapping relation between the object name information of the service and corresponding service node information;
Accessing each service to the same registry based on the Kubernetes service object corresponding to each service;
when a service call request sent by a service consumer is received, acquiring a service provider name corresponding to the service call request from the registry;
a target service node for providing a service to the service consumer is determined based on the service provider name and each of the Kubernetes service objects.
In a second aspect, an embodiment of the present invention further provides a service node determining apparatus, where the apparatus includes:
the service node deployment module is used for deploying at least one service node corresponding to each service under the same naming space of the Kubernetes cluster for at least one service with a calling relation;
A service object determining module, configured to create, for each of the services, a Kubernetes service object corresponding to each of the services based on service name information and service port information of the service, where the Kubernetes service object includes a mapping relationship between object name information of the service and corresponding service node information;
the registry access module is used for accessing each service to the same registry based on the Kubernetes service object corresponding to each service;
The service request receiving module is used for acquiring a service provider name corresponding to a service call request from the registry when receiving the service call request sent by a service consumer;
And the service node determining module is used for determining a target service node for providing service for the service consumer based on the service provider name and each Kubernetes service object.
In a third aspect, an embodiment of the present invention further provides an electronic device, including:
One or more processors;
Storage means for storing one or more programs,
The one or more programs, when executed by the one or more processors, cause the one or more processors to implement a service node determination method as in any of the embodiments of the present invention.
In a fourth aspect, embodiments of the present invention also provide a storage medium containing computer-executable instructions which, when executed by a computer processor, are used to perform a service node determination method as in any of the embodiments of the present invention.
According to the technical scheme of the embodiment of the invention, for at least one service with a calling relation, at least one service node corresponding to each service is deployed under the same naming space of the Kubernetes cluster, and then, for each service, based on 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 comprises a mapping relation between object name information of the service and corresponding service node information, and based on the Kubernetes service object corresponding to each service, each service is accessed into the same registry. Further, when a service call request issued by a service consumer is received, a service provider name corresponding to the service call request is acquired from the registry, so that a target service node for providing a service for the service consumer can be determined based on the service provider name and each Kubernetes service object. According to the technical scheme, through the method based on the service name registration, the registration address is designated as the corresponding Kubernetes service object name when the service is registered to the registration center, the problem that an IP address list is not updated timely in the process of online and offline of a service node, so that a service consumer requests to an upgrading service node when calling the service is solved, the service consumer can call the service node capable of normally providing the service, and the continuity of the service is ensured.
Drawings
In order to more clearly illustrate the technical solution of the exemplary embodiments of the present invention, a brief description is given below of the drawings required for describing the embodiments. It is obvious that the drawings presented are only drawings of some of the embodiments of the invention to be described, and not all the drawings, and that other drawings can be made according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a flow chart of a service node determining method according to an embodiment of the present invention;
fig. 2 is a schematic structural diagram of a service node determining apparatus according to an embodiment of the present invention;
fig. 3 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.
Detailed Description
Fig. 1 is a flow chart of a service node determining method according to an embodiment of the present invention, where the method may be applied to any micro service architecture system, and the method may be performed by a service node determining device, where the device may be implemented in software and/or hardware, and the hardware may be an electronic device, such as a mobile terminal, a PC end, or a server.
The technical scheme provided by the embodiment can be applied to any micro-service architecture system. The micro-service architecture system comprises a plurality of services which can realize different service functions. Each service in the micro-service architecture is an independent, autonomous, reusable software module that typically implements a particular business function. Each service has its own code, data and resources, which can be deployed, extended and upgraded independently. The services interact and cooperate through a lightweight communication mechanism. To improve the request response efficiency of the micro service architecture system, one service may be divided into a plurality of service nodes, each of which may provide the same service. Each service node may be understood as a service instance.
In an actual production environment, service consumers and service providers are generally available in high availability and multiple instances, when the service provider goes online and offline, the current service provider instance cannot normally provide services, but a service provider IP address list cached by the service consumer may not be updated timely, which may cause the service consumer to request to the service provider instance being upgraded when calling the service, and the request fails, resulting in production problems. In order to avoid this situation, the existing solutions are generally upgraded or stopped at the low peak of service, which causes service discontinuity and affects the normal use of the clients. In order to solve the problem that in the micro-service architecture mode, service providers cannot achieve lossless online and offline of services, and call failures possibly occur when service consumers call the services. The embodiment of the invention provides a service node determining method, which aims to enable a service consumer to call a service node capable of normally providing service in the process of connecting the service node to the internet and ensure the continuity of the service.
As shown in fig. 1, the service node determining method includes:
S110, for at least one service with a mutual calling relationship, deploying at least one service node corresponding to each service under the same naming space of the Kubernetes cluster.
Where a Kubernetes cluster is a collection of physical or virtual machines that are organized into a single pool of computing resources and on which a Kubernetes platform runs. The main purpose of Kubernetes clusters is to provide high availability, scalability, and fault tolerance to ensure that applications can always function properly.
In the Kubernetes platform, a namespace is a logical partitioning mechanism used to partition resources in a cluster into different environments or teams to enable isolation and management of the resources. An independent namespace allows multiple users to work independently in the same Kubernetes cluster without resource conflicts.
In the present embodiment, a plurality of services for executing a certain actual service may be constructed in advance, each corresponding to a plurality of service units, which may be mutually invoked by a preset invocation rule. On this basis, a plurality of service nodes corresponding to the services can be deployed under the same naming space of the Kubernetes cluster. The purpose of the arrangement is to deploy the service nodes with the calling relationship under the same name space, so that the mutual calling among the service nodes of different types can be realized efficiently.
By way of example, 4 services having a correlation between calls are preconfigured for implementing a certain actual service. These services include class a services, class B services, class C services, and class D services. The service node A1, the service node A2, the service node A3 and the service node A4 corresponding to the class A service can provide the class A service function, the service node B1, the service node B2 and the service node B3 corresponding to the class B service can provide the class B service function, the service node C1, the service node C2 and the service node C3 corresponding to the class C service can provide the class C service function, and the service node D1 and the service node D2 corresponding to the class D service can provide the class D service function. Based on this, service nodes corresponding to these services can be deployed under the same namespace of the Kubernetes cluster.
S120, for each service, based on service name information and service port information of the service, a Kubernetes service object corresponding to each service is created.
Wherein the service name information may be text information or character information describing a certain type of service function. The service port information refers to a port number used by a certain service and data related to the port number in network communication.
The Kubernetes Service object may be understood as Service under the Kubernetes architecture. In the Kubernetes architecture, service is a logical abstraction for accessing one or more Pod. It provides a stable IP address and DNS name for a group of Pod so that other applications or users can access them. Service allows Pod to be added or deleted dynamically without affecting the availability of the Service. Service also supports load balancing, and requests can be distributed to multiple Pod to improve scalability and reliability.
In this embodiment, the Kubernetes service object includes a mapping relationship between service object name information and corresponding service node information. The object name information refers to a name of a Kubernetes service object corresponding to a certain service, and the service node information refers to identification information of at least one service node corresponding to the service, for example, the service node information may be an IP address and/or an access port corresponding to the service node.
In particular, a Kubernetes service object corresponding to each class of service may be created. In this embodiment, the creation manner of the Kubernetes service object corresponding to each type of service is the same, and here, the current service is taken as any type of service, and the current service is taken as an example for exemplary illustration.
In this embodiment, the specific implementation manner of creating the Kubernetes service object corresponding to each service based on the service name information and the service port information of the 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, constructing a mapping relationship between the object name information of the service and the corresponding service node information, and creating the 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 be set as a transmission control protocol, and the access mode of the Kubernetes service object corresponding to the current service can be set as an intra-cluster IP address access mode or a node port access mode.
In this embodiment, for the current service, the service name information and the 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 may be set as the object name information of the Kubernetes service object, and the service port information corresponding to the current service may be set as the object port information of the Kubernetes service object. According to each service node corresponding to the current service, a mapping relation between the object name information of the current service and the corresponding service node information can be constructed. After the setting is completed and the mapping relation is obtained, the Kubernetes service object corresponding to the current service can be obtained. Further, the port protocol and the access mode of the Kubernetes service object corresponding to the current service can be set. In this embodiment, the port protocol of the Kubernetes service object corresponding to the current service may be set as the transmission control protocol, and the access mode of the Kubernetes service object corresponding to the current service may be set as the intra-cluster IP address access mode or the node port access mode. Based on the same creation mode, the Kubernetes service object corresponding to each type of service can be obtained.
S130, accessing each service to the same registry based on the Kubernetes service object corresponding to each service.
The registry is a key component in the micro-service architecture, and provides functions of service registration, service discovery, service monitoring, configuration management and the like. In a distributed system, a registry makes communication and management between services easier and more efficient.
In this embodiment, various services may be accessed to the same registry, so that when various services are executed, relevant information corresponding to the service provider is determined according to information recorded in the registry. For a certain type of service, the object name information of the Kubernetes service object can be used as a registration IP, the object port information of the Kubernetes service object can be used as registration port information, and the service is accessed to a preconfigured registration center.
Specifically, the specific implementation manner of accessing each service to the same registry based on the Kubernetes service object corresponding to each service may include determining, for each service, registration configuration information corresponding to the current service based on object name information and object port information corresponding to the current Kubernetes service object, and accessing each service to the same registry based on the registration configuration information corresponding to each service.
In this embodiment, when a certain service is accessed to the registry, a configuration file corresponding to the certain service needs to be determined, where the registration IP and port information of the certain service need to be set. Based on this, for a certain class of service, the registration configuration information may be determined according to the service port information and the service port information of the Kubernetes service object, so that the class of service is accessed to the registration center according to the registration configuration file. In the same manner, each class of service may be accessed to the same registry.
And S140, when receiving a service call request sent by a service consumer, acquiring a service provider name corresponding to the service call request from a registry.
The service call request refers to call request information from a certain service node in the running process of the micro service architecture system, and aims to achieve a specific business target or requirement. The service consumer generates a service node of a service call request for the current moment. The service provider name refers to name information corresponding to a service class called by a service consumer.
In this embodiment, in the running process of the micro service architecture system, when a service node corresponding to a certain type of service generates a service call request, the service node is a service consumer, and the service call request carries a request method and request parameter information, so that it can be determined which type of service needs to be called by the service consumer. Since the registry includes registration information corresponding to various services, name information corresponding to such services (the name information is actually object name information of Kubernetes service objects of the services) can be obtained from the registry, that is, a service provider name.
For example, the A1 service node of the class a service issues a service call request, and at this time, the A1 service node is a service consumer, and according to a request method and request parameter information carried in the service call request, it can be determined what type of service needs to be invoked by the service consumer, for example, the service consumer is a class B service. At this time, the registration information of the service call B-class service, that is, the service provider name, may be acquired from the registry.
S150, determining a target service node for providing service for the service consumer based on the service provider name and each Kubernetes service object.
Wherein the target service node is the service node that is ultimately determined to provide service to the service consumer.
In this embodiment, the object name information corresponding to each Kubernetes service object is queried according to the service provider name, so that the target Kubernetes service object corresponding to the service provider can be obtained, and thus, the target service node for providing the service for the service consumer can be determined through a load balancing manner according to each service node recorded in the target Kubernetes service object.
Optionally, the specific implementation of determining the target service node for providing the service for the service consumer based on the service provider name and the Kubernetes service objects may include determining the target Kubernetes service object from the Kubernetes service objects based on the service provider name and the object name information corresponding to the Kubernetes service objects, and determining the target service node for providing the service for the service consumer from the service nodes corresponding to the target Kubernetes service object based on a load balancing policy of the target Kubernetes service object.
In this embodiment, the object name information corresponding to each Kubernetes service object may be queried by the service provider name, and 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 may be determined as the target Kubernetes service object. Further, according to the load balancing policy of the target Kubernetes service object, a target service node for providing services for the service consumer can be determined from the service nodes corresponding to the target Kubernetes service object.
According to the technical scheme of the embodiment of the invention, for at least one service with a calling relation, at least one service node corresponding to each service is deployed under the same naming space of the Kubernetes cluster, and then, for each service, based on 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 comprises a mapping relation between object name information of the service and corresponding service node information, and based on the Kubernetes service object corresponding to each service, each service is accessed into the same registry. Further, when a service call request issued by a service consumer is received, a service provider name corresponding to the service call request is acquired from the registry, so that a target service node for providing a service for the service consumer can be determined based on the service provider name and each Kubernetes service object. According to the technical scheme, through the method based on the service name registration, the registration address is designated as the corresponding Kubernetes service object name when the service is registered to the registration center, the problem that an IP address list is not updated timely in the process of online and offline of a service node, so that a service consumer requests to an upgrading service node when calling the service is solved, the service consumer can call the service node capable of normally providing the service, and the continuity of the service is ensured.
Example two
Fig. 2 is a schematic structural diagram of a service node determining apparatus according to an embodiment of the present invention, where the apparatus includes a service node deployment module 210, a service object determining module 220, a registry access module 230, a service request receiving module 240, and a service node determining module 250.
The service node deployment module 210 is configured to deploy, for at least one service having a mutual calling relationship, at least one service node corresponding to each service under the same namespace of the Kubernetes cluster;
A service object determining module 220, configured to create, for each of the services, a Kubernetes service object corresponding to each of the services based on service name information and service port information of the service, where the Kubernetes service object includes a mapping relationship between object name information of the service and corresponding service node information;
A registry access module 230, configured to access each service to the same registry based on the Kubernetes service object corresponding to each service;
A service request receiving module 240, configured to, when receiving a service call request sent by a service consumer, obtain a service provider name corresponding to the service call request from the registry;
A service node determining module 250 is configured to determine a target service node for providing a service for the service consumer based on the service provider name and each of the Kubernetes service objects.
On the basis of the above apparatus, optionally, the service object determining module 220 includes:
an object name determining unit configured to determine object name information based on the service name information of a current service;
an object port determining unit, configured to determine object port information based on the service port information of a current service;
A mapping relation determining unit, configured to construct a mapping relation between the object name information of the service and corresponding service node information;
and the service object construction unit is used for creating the Kubernetes service object corresponding to the current service based on the object name information, the object port information and the mapping relation.
On the basis of the above device, optionally, the service object determining module 220 is further configured to set a port protocol of the Kubernetes service object corresponding to the current service as a transmission control protocol, and set an access mode of the Kubernetes service object corresponding to the current service as an intra-cluster IP address access mode or a node port access mode.
Based on the above apparatus, optionally, the registry accessing module 230 includes:
a configuration information determining unit, configured to determine, for each service, 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;
And the registry access unit is used for accessing each service to the same registry based on the registration configuration information corresponding to each service.
On the basis of the above apparatus, optionally, the service node determining module 250 includes:
A target object determining unit, configured to determine a target Kubernetes service object from the Kubernetes service objects based on the service provider name and object name information corresponding to the Kubernetes service objects;
And the target node determining unit is used for determining a target service node for providing service for the service consumer from the service nodes corresponding to the target Kubernetes service object based on the load balancing policy of the target Kubernetes service object.
According to the technical scheme of the embodiment of the invention, for at least one service with a calling relation, at least one service node corresponding to each service is deployed under the same naming space of the Kubernetes cluster, and then, for each service, based on 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 comprises a mapping relation between object name information of the service and corresponding service node information, and based on the Kubernetes service object corresponding to each service, each service is accessed into the same registry. Further, when a service call request issued by a service consumer is received, a service provider name corresponding to the service call request is acquired from the registry, so that a target service node for providing a service for the service consumer can be determined based on the service provider name and each Kubernetes service object. According to the technical scheme, through the method based on the service name registration, the registration address is designated as the corresponding Kubernetes service object name when the service is registered to the registration center, the problem that an IP address list is not updated timely in the process of online and offline of a service node, so that a service consumer requests to an upgrading service node when calling the service is solved, the service consumer can call the service node capable of normally providing the service, and the continuity of the service is ensured.
The service node determining device provided by the embodiment of the invention can execute the service node determining method provided by any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the executing method.
It should be noted that the above system includes units and modules that are only divided according to the functional logic, but not limited to the above division, as long as the corresponding functions can be implemented, and specific names of the functional units are only used for distinguishing from each other, and are not used for limiting the protection scope of the embodiments of the present invention.
Example III
Fig. 3 is a schematic structural diagram of an electronic device according to an embodiment of the present invention. Fig. 3 shows a block diagram of an exemplary electronic device 30 suitable for use in implementing the embodiments of the present invention. The electronic device 30 shown in fig. 3 is only an example and should not be construed as limiting the functionality and scope of use of embodiments of the present invention.
As shown in fig. 3, the electronic device 30 is in the form of a general purpose computing device. The components of 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 that connects the different system components (including system memory 302 and processing units 301).
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 architectures. By way of example, and not limitation, such architectures include 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.
Electronic device 30 typically includes a variety of computer system readable media. Such media can be any available media that is accessible by electronic device 30 and includes both volatile and non-volatile media, removable and non-removable media.
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. Electronic device 30 may further include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, storage system 306 may be used to read from and write to non-removable, nonvolatile magnetic media (not shown in FIG. 3, commonly referred to as a "hard disk drive"). Although not shown in fig. 3, a magnetic disk drive for reading from and writing to a removable non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive for reading from or writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In such cases, each drive may be coupled to bus 303 through one or more data medium interfaces. Memory 302 may include at least one program product having a set (e.g., at least one) of program modules configured to carry out the functions of embodiments of the invention.
A program/utility 308 having a set (at least one) of program modules 307 may be stored, for example, in 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 or some combination of which may include an implementation of a network environment. Program modules 307 typically carry out the functions and/or methods of the described embodiments of the invention.
The electronic device 30 may also communicate with one or more external devices 309 (e.g., keyboard, pointing device, display 810, etc.), one or more devices that enable a user to interact with the electronic device 30, and/or any devices (e.g., network card, modem, etc.) that enable the electronic device 30 to communicate with one or more other computing devices. Such communication may occur through an input/output (I/O) interface 311. Also, electronic device 30 may communicate with one or more networks such as a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the Internet, through network adapter 312. As shown, network adapter 312 communicates with other modules of electronic device 30 over bus 303. It should be appreciated that although not shown in FIG. 3, other hardware and/or software modules may be used in connection with 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, among others.
The processing unit 301 executes various functional applications and page processing by running programs stored in the system memory 302, for example, implementing the service node determination method provided by the embodiment of the present invention.
Example IV
The embodiments of the present invention also provide a storage medium containing computer executable instructions which, when executed by a computer processor, are for performing a service node determining method comprising:
for at least one service with a calling relationship, deploying at least one service node corresponding to each service under the same naming space of the Kubernetes cluster;
For each service, based on service name information and service port information of the service, creating a Kubernetes service object corresponding to each service, wherein the Kubernetes service object comprises a mapping relation between the object name information of the service and corresponding service node information;
Accessing each service to the same registry based on the Kubernetes service object corresponding to each service;
when a service call request sent by a service consumer is received, acquiring a service provider name corresponding to the service call request from the registry;
a target service node for providing a service to the service consumer is determined based on the service provider name and each of the Kubernetes service objects.
The computer storage media of embodiments of the invention may take the form of any combination of one or more computer-readable media. The computer readable medium may 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 electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
The computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, either in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
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.
Computer program code for carrying out operations for embodiments of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).
Note that the above is only a preferred embodiment of the present invention and the technical principle applied. It will be understood by those skilled in the art that the present invention is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the invention. Therefore, while the invention has been described in connection with the above embodiments, the invention is not limited to the embodiments, but may be embodied in many other equivalent forms without departing from the spirit or scope of the invention, which is set forth in the following claims.
Claims (9)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202411622975.8A CN119576644A (en) | 2024-11-14 | 2024-11-14 | A method, device, equipment, medium and product for determining a service node |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202411622975.8A CN119576644A (en) | 2024-11-14 | 2024-11-14 | A method, device, equipment, medium and product for determining a service node |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN119576644A true CN119576644A (en) | 2025-03-07 |
Family
ID=94806526
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202411622975.8A Pending CN119576644A (en) | 2024-11-14 | 2024-11-14 | A method, device, equipment, medium and product for determining a service node |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN119576644A (en) |
-
2024
- 2024-11-14 CN CN202411622975.8A patent/CN119576644A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110198231B (en) | Container network management method and system for multiple tenants and middleware | |
| US8336047B2 (en) | Provisioning virtual resources using name resolution | |
| CN110262902B (en) | Information processing method and system, medium, and computing device | |
| CN106663033B (en) | System and method for supporting a wraparound domain and proxy model and updating service information for cross-domain messaging in a transactional middleware machine environment | |
| CN112395264B (en) | Processing method for mapping between logical targets and volumes in distributed storage system | |
| JP7369860B2 (en) | Access docking component, system, and method and apparatus using the access docking component | |
| CN116155978B (en) | Multi-registration center adaptation method, device, electronic device and storage medium | |
| CN107666493B (en) | Database configuration method and equipment thereof | |
| CN103118073B (en) | Virtual machine data persistence storage system and method in cloud environment | |
| CN112882726B (en) | Hadoop and Docker-based deployment method of environment system | |
| US9591079B2 (en) | Method and apparatus for managing sessions of different websites | |
| US7818390B2 (en) | Method for transferring data between terminal apparatuses in a transparent computation system | |
| WO2021232243A1 (en) | Cluster management method, cluster management apparatus, storage medium and electronic device | |
| CN104468150A (en) | Method for realizing fault migration through virtual host and virtual host service device | |
| US9390156B2 (en) | Distributed directory environment using clustered LDAP servers | |
| CN112398936B (en) | Kubernetes-based multi-network card container implementation method and system | |
| CN110633046A (en) | Storage method and device of distributed system, storage equipment and storage medium | |
| CN114371914A (en) | Container IP address configuration method, device, storage medium and electronic device | |
| CN115878269A (en) | Cluster migration method, related device and storage medium | |
| CN115480877A (en) | External exposure method and device of application service in multi-cluster environment | |
| CN106209933A (en) | source host, migration framework and data migration method | |
| CN116560578A (en) | Data storage method, device, equipment and storage medium | |
| CN119576644A (en) | A method, device, equipment, medium and product for determining a service node | |
| EP3387533B1 (en) | Disaster recovery of cloud resources | |
| CN116661686A (en) | A data storage method, device, device and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |