CN115701077A - Method and device for docking micro-service grids - Google Patents

Abstract

A method and apparatus for interfacing to a microservice grid. In the method, a proxy component intercepts a service discovery request sent by a first application instance, wherein the service discovery request is used for acquiring an IP address set corresponding to one or more second application instances, the second application instances are used for providing target services, and the proxy component sends a service discovery response to the first application instance, wherein the service discovery response comprises a domain name corresponding to the IP address set. By the method and the device, the application can be in non-invasive butt joint with the micro service grid, a software development kit of the application does not need to be changed, components in the micro service grid do not need to be changed, workload is effectively reduced, and management efficiency of the application is improved.

Description

Method and device for docking micro-service grids

Technical Field

The present application relates to the field of cloud computing technologies, and in particular, to a method and an apparatus for docking a micro service grid.

Background

In the gradual evolution of the microservice architecture, a service mesh (service mesh) technology is receiving wide attention as a new microservice form in the industry. At present, one of the most mainstream product open source projects of the service grid technology is: ister is in hundred million ohms (Istio). In order to enjoy the fine micro-service governance capability of the isto, most of the newly developed services are currently in contact with the isto. Applications developed by existing open-source distributed service frameworks such as dabbo (Dubbo) or distributed Cloud service frameworks such as Spring Cloud (Spring Cloud) can also interface with the isio to enjoy the micro-service governance capability of the isio.

The application developed based on the distributed application development framework such as Dubbo or Spring Cloud already has a set of complete logics such as service registration, service discovery, load balancing and the like, and the isio also has a set of complete logics such as service registration, service discovery, load balancing and the like, which leads to the conflict between the logics such as service registration, service discovery, load balancing and the like of the application developed based on the distributed application development framework such as Dubbo or Spring Cloud and the like and the isio. How to interface applications developed based on distributed application development frameworks such as Dubbo, spring Cloud, etc. to the Istio is a matter of consideration.

Disclosure of Invention

The application aims to provide a method for docking a micro service grid and a proxy component, wherein the micro service grid can be an Istio service grid, and the method is used for realizing non-intrusive docking of the Istio by Dubbo application or Spring Cloud application.

In a first aspect, embodiments of the present application provide a method for interfacing a microservice grid, which may be performed by an agent component of a microservice system. In the method, an agent component intercepts a service discovery request sent by a first application instance in the micro service system, wherein the service discovery request is used for acquiring an IP address set corresponding to one or more second application instances in the micro service system, and the second application instances are used for providing target services; and the agent component sends a service discovery response to the first application instance, wherein the service discovery response comprises a domain name corresponding to the IP address set. The domain name corresponding to the IP address set may be a kubernets domain name.

The agent component and the first application instance run in the same process, and the agent component is not integrated in the first application instance.

Optionally, the first application example is an application developed based on a Dubbo architecture, or an application developed based on a Spring Cloud architecture. The first application instance may be one of the one or more application instances of the first application program. The one or more second application instances may be application instances of a second application program. The service discovery request may be used to obtain a set of IP addresses corresponding to one or more second application instances of the second application program. For example, if the second application is running in only one runtime environment, then the second application comprises a second application instance. For another example, if the second application is running in multiple runtime environments, the second application includes multiple second application instances.

In the above embodiment, the agent component intercepts the service discovery request sent by the original service discovery logic of the first application instance, and sends the service discovery response including the kubernets domain name to the first application instance, so that the service discovery request cannot be sent to the registry corresponding to the first application instance, thereby shielding the service discovery logic of the first application instance itself, and avoiding the conflict between the service discovery logic of the first application instance itself and the service discovery logic of the isio. The service discovery response received by the first application instance comprises the Kubernets domain name instead of the IP address set, and the first application instance does not need to execute routing, load balancing and the like on the Kubernets domain name, so that the flows of routing, load balancing and the like of the first application instance can be omitted, the calculation amount of the first application instance is reduced, and the performance consumption is reduced. Moreover, the agent component is upgraded or modified without changing the SDK of the first application instance and changing the service discovery logic of the Istio, so that the non-intrusive butting of the Istio of the first application instance is realized, and the workload can be reduced.

In one possible design, the first service discovery request includes identification information of the second application instance, and the method may further include: the agent component constructs the domain name according to the identification information of the second application instance and the environment variable of the first application instance; and the agent component generates the service discovery response according to the domain name.

The identification information includes an application name of the second application instance (which may also be referred to as an application name of the second application program), or includes a service name of the target service, or includes the application name of the second application instance and the service name of the target service.

For example, if the identification information includes an application name of the second application instance, the agent component may construct the domain name according to the identification information of the second application instance and the environment variable of the first application instance by: and the agent component constructs the domain name according to the application name of the second application instance and the environment variable of the first application instance.

For another example, if the identification information includes a service name of the target service, the agent component may construct the domain name according to the identification information of the second application instance and the environment variable of the first application instance, by: the agent component acquires the application name of the second application instance according to the configuration file and the service name of the target service, and constructs the domain name according to the application name of the second application instance and the environment variable of the first application instance; the configuration file comprises a corresponding relation between a service name of the target service and an application name of an application instance providing the target service.

Through the design, after the agent component intercepts the service discovery request sent by the first application instance, a Kubernets domain name can be constructed according to the identification information of the second application instance and the environment variable of the agent component, the Kubernets domain name is sent to the first application instance, the Kubernets domain name is equivalent to that the agent component constructs a service discovery result for the first application instance, the service discovery process of the first application instance is terminated, and therefore the conflict between the service discovery process of the first application instance and the service discovery process of the Istio can be avoided.

In one possible design, the microservice system further includes an interface server component, and before the agent component intercepts the service discovery request issued by the first application instance, the method may further include: the agent component intercepts a first service registration request sent by the first application instance; generating a second service registration request by the agent component according to the first service registration request, wherein the second service registration request comprises the application name of the first application instance; and the agent component sends the second service registration request to the interface server component. Wherein, the interface Server component can be an application program interface Server (API Server) component.

In the above embodiment, the agent component intercepts the first service registration request sent by the first application instance according to the service registration logic of the agent component, and initiates the service registration flow to the API Server component by using the application name of the first application instance, so as to shield the service registration logic of the first application instance. That is, the developer may avoid conflicts between the first application instance's own service registration logic and the Istio's service registration logic by modifying or upgrading the agent component of the first application instance. Moreover, the agent component is upgraded or modified without changing the SDK of the first application instance and without changing the service registration logic of the Istio, so that the Dubbo application (or Spring Cloud application) is non-intrusively connected with the Istio, and the workload can be reduced.

In one possible design, after the agent component sends the second service registration request to the interface server component, the agent component may further receive a second service registration response sent from the interface server component, where the second service registration response may be used to indicate that the first application instance registration succeeded or failed. Further, the agent component can generate a first service registration response from the second service registration response and send the first service registration response to the first application instance, the first service registration response indicating a success or failure of the first application instance registration. And if the second service registration response is used for indicating that the first application instance is successfully registered, the first service registration response is also used for indicating that the first application instance is successfully registered. If the second service registration response is used to indicate that the first application instance registration failed, the first service registration response is also used to indicate that the first application instance registration failed.

Through the above design, the first application instance can realize the registration in the API Server component.

In a second aspect, an embodiment of the present application provides a broker component, which may be deployed in an electronic device (e.g., a server, etc.), and is configured to implement the method described in the first aspect or any possible design of the first aspect. The functions realized by the agent component can be realized by hardware, and can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules (or units) corresponding to the above functions, such as a processing module and a communication module. Wherein, the agent component can be an agent component.

Illustratively, the processing module is configured to intercept a service discovery request sent by a first application instance in a micro service system, where the service discovery request is used to obtain an IP address set corresponding to one or more second application instances in the micro service system, where the second application instances are used to provide a target service.

A communication module, configured to send a service discovery response to the first application instance, where the service discovery response includes a domain name corresponding to the IP address set. The domain name corresponding to the IP address set may be a kubernets domain name.

The agent component and the first application instance run in the same process, and the agent component is not integrated in the first application instance.

Optionally, the first application example is an application developed based on a Dubbo architecture, or an application developed based on a Spring Cloud architecture.

In one possible design, the first service discovery request includes identification information of the second application instance; the processing module is further configured to construct the domain name according to the identification information of the second application instance and the environment variable of the first application instance; and generating the service discovery response according to the domain name.

The identification information comprises an application name of the second application instance, or comprises a service name of the target service, or comprises the application name of the second application instance and the service name of the target service.

In a possible design, the identification information includes an application name of the second application instance, and the processing module is specifically configured to: and constructing the domain name according to the application name of the second application instance and the environment variable of the first application instance.

In one possible design, the identification information includes a service name of the target service, and the processing module is specifically configured to: according to the identification information of the second application instance and the environment variable of the first application instance, constructing the domain name may be: the agent component acquires the application name of the second application instance according to the configuration file and the service name of the target service, and constructs the domain name according to the application name of the second application instance and the environment variable of the first application instance; the configuration file comprises a corresponding relation between a service name of a target service and an application name of an application instance providing the target service.

In one possible design, the microservice system further includes an interface server component; the processing module is further used for intercepting a first service registration request sent by the first application instance; generating a second service registration request according to the first service registration request, wherein the second service registration request comprises the application name of the first application instance; the communication module is further configured to send the second service registration request to the interface server component.

In one possible design, the communication module is further to: receiving a second service registration response sent from the interface server component, the second service registration response being operable to indicate a success or failure of the first application instance registration. The processing module is further to: generating a first service registration response according to the second service registration response; the communication module is further to send a first service registration response to the first application instance, the first service registration response to indicate a success or failure of registration of the first application instance. And if the second service registration response is used for indicating that the first application instance is successfully registered, the first service registration response is also used for indicating that the first application instance is successfully registered. If the second service registration response is used to indicate that the first application instance registration failed, the first service registration response is also used to indicate that the first application instance registration failed.

In a third aspect, an embodiment of the present application provides an electronic device, which may be a server or the like. The electronic device may include one or more processors, memory, and a communication interface. Wherein the memory is used for storing computer programs and data. The memory is coupled to the one or more processors, which may execute the computer program stored in the memory for implementing the method as described in the first aspect or any of the possible designs of the first aspect.

In a fourth aspect, embodiments of the present application provide a computing device cluster comprising one or more computing devices, the computing devices comprising memory and one or more processors; the one or more processors are coupled with the memory for storing a computer program or instructions which, when executed by the one or more processors, cause the computing device to perform the method as set forth in the first aspect or any one of the possible designs of the first aspect above.

In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium for storing a computer program, which, when run on an electronic device, causes the electronic device to perform the method described in the first aspect or any possible design of the first aspect.

In a sixth aspect, an embodiment of the present application provides a computer program product, which includes instructions that, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect or any one of the possible designs of the first aspect.

In a seventh aspect, an embodiment of the present application further provides a chip system, where the chip system includes one or more processors and an interface circuit, and the processors are configured to execute interaction of instructions and/or data through the interface circuit, so that an apparatus in which the chip system is located implements the method described in the first aspect or any possible design of the first aspect. The chip system may be formed by a chip, and may also include a chip and other discrete devices.

For the beneficial effects of the second to seventh aspects and the implementation manner thereof, please refer to the technical effects that can be achieved by the first aspect and any one of the possible designs thereof, which will not be repeated herein.

Drawings

Fig. 1 is a schematic structural diagram of an isio microservice system according to an embodiment of the present application;

FIG. 2 is a schematic flow chart illustrating docking of a microservice grid according to an embodiment of the present application;

fig. 3 is a schematic structural diagram of an isto microservice system according to an embodiment of the present application;

FIG. 4 is a schematic flow chart of docking a microservice grid as provided by an embodiment of the present application;

FIG. 5 is a schematic flow chart of docking a microservice grid according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of a communication device according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

First, some terms referred to in the embodiments of the present application are explained so as to be easily understood by those skilled in the art.

(1) Microservices, also known as microservices systems, are a software architecture style that combines complex large-scale applications in a modular fashion based on small functional blocks (small building blocks) that focus on single responsibilities and functions. Each functional block of the microservice communicates using an Application Programming Interface (API) set independent of language (language-independent/language-aware).

(2) A service mesh (service mesh) is a novel micro-service form, which accesses the existing service to a micro-service administration system by a sidecar (sidecar) mode to enjoy the capabilities of micro-service such as service registration, service discovery, and service administration. The embodiment of the application relates to a service grid Istioo service grid.

(3) Kubernetes, an open source container orchestration engine for managing containerized Applications (APPs) on multiple hosts in a cloud platform. When an application is deployed, multiple application instances of the application are typically deployed, and in kubernets, multiple containers may be created for an application, and each container runs an application instance of the application inside.

(4) An application instance may also be referred to as an instance of an application, instance, application instance, and the like. An application program may include one or more application instances. An application instance may be understood as a process of an application program in a runtime environment. An application runs in N different execution environments, and the application includes N application instances, where N is an integer greater than 0.

(5) The container is a way to implement virtualization of the operating system, and can enable a user to run an application program and the dependency relationship thereof in a process in which resources are isolated. (6) In the description of the embodiment of the present application, "and/or" describes an association relationship of associated objects, which means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. At least one referred to in this application means one or more; plural means two or more.

And, unless stated to the contrary, the embodiments of the present application refer to the ordinal numbers "first", "second", "third", etc., for distinguishing a plurality of objects, and do not limit the size, content, sequence, timing, priority, importance, etc., of the plurality of objects. For example, the first information, the second information, the third information, and the like are only for distinguishing different information, and do not indicate differences in the size, content, transmission order, priority, importance, and the like of the three pieces of information. Moreover, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

For understanding the embodiment of the present application, an application scenario of the present application is introduced next, and a network architecture and a service scenario described in the embodiment of the present application are for more clearly explaining the technical solution of the embodiment of the present application, and do not form a limitation on the technical solution provided in the embodiment of the present application.

As described in the foregoing background, applications developed based on distributed application development frameworks such as Dubbo or Spring Cloud may interface with the Istio to enjoy the full micro-service governance capabilities of the Istio. For the convenience of understanding the embodiments of the present application, an application developed based on the Dubbo distributed application development framework may be simply referred to as a Dubbo application hereinafter. Similarly, an application developed based on the Spring Cloud distributed application development framework may be referred to as a Spring Cloud application for short.

Taking a Dubbo application as an example, an application instance of the Dubbo application (hereinafter, abbreviated as a Dubbo application instance) sends a registration request to a registration center corresponding to the Dubbo application, and after receiving the registration request, the registration center corresponding to the Dubbo application records an Internet Protocol (IP) address of the Dubbo application instance and completes registration of the Dubbo application instance. The registry corresponding to the Dubbo application may be an administrator (Zookeeper) which is used to provide a consistency service, such as service registration, IP address query, and the like. After registration of the Dubbo application instance is completed, the Dubbo application instance may send a discovery request to a registration center corresponding to the Dubbo application to obtain IP addresses of one or more application instances serving the Dubbo application instance. Further, the Dubbo application instance determines one of the one or more application instances to be a target application instance (IP address) through a load balancing algorithm or the like, and sends a service invocation request to the target application instance to request the target application instance to provide a service for the target application instance.

The logic of service registration, service discovery, load balancing, and the like of the Dubbo application itself is two sets of logic independent from the logic of service registration, service discovery, load balancing, and the like in the isio, which causes conflicts with the logic of service registration, service discovery, load balancing, and the like of the Dubbo application itself.

It can be understood that the flows of service registration, service discovery, and load balancing of the Spring Cloud application itself are similar to the flows of service registration, service discovery, and load balancing of the Dubbo application itself. That is, the flows of the Spring Cloud application, such as service registration, service discovery, and load balancing, also conflict with the isio.

At present, if the Dubbo application or the Spring Cloud application is to interface with the issue, the flows of service registration, service discovery, load balancing, and the like of the Dubbo application or the Spring Cloud application itself may be changed, or the capability of the Envoy component of the issue may be changed. These two ways are briefly described below.

Mode 1: and changing the processes of service registration, service discovery, load balancing and the like of the Dubbo application or Spring Cloud application.

Taking the Dubbo application as an example, by modifying a Software Development Kit (SDK) of the Dubbo application, mechanisms such as a service registration logic of the Software Development Kit (SDK), a service discovery logic of the Software Development Kit (SDK), and a routing, fault tolerance, and load balancing of the Software Development Kit (SDK) of the Dubbo application are removed. For example, the Service registration logic changes to manually creating a kubernets Service object at deployment time by itself by sending a registration request to the registry. For example, the service discovery logic sends a service discovery request to the Zookeeper and then performs service invocation by itself, and changes the service discovery logic into a method of directly constructing an access domain name of a target service and then sending a service invocation request to an Envoy (Envoy) of the isio, and an Envoy component of the isio performs a service discovery process according to the access domain name of the target service.

By means of the method 1, the processes of service registration, service discovery, load balancing and the like of the Dubbo application or the Spring Cloud application can be eliminated. However, the method 1 needs to recompile the SDK of the Dubbo application or the Spring Cloud application, and has a large compilation workload and is easy to make errors.

Mode 2: the capabilities of the Envoy component of Istio are changed.

By modifying the Envoy component, the Envoy component supports the service registration and service discovery capability of the Dubbo or Spring Cloud application registry. For example, the Envoy component is modified, so that the modified Envoy component can realize the function of a registry interface of the Dubbo application or the Spring Cloud application, and thus, the service registration is completed instead of the registry corresponding to the Dubbo application or the Spring Cloud application. For another example, the Envoy component is modified so that the modified Envoy component can receive a service discovery request of the Dubbo application or the Spring Cloud application, modify the IP address of the target service in the service discovery response to the access domain name of the target service in kubernets, and return the access domain name to the Dubbo application or the Spring Cloud application; the Dubbo application or Spring Cloud application executes mechanisms such as routing, fault tolerance and load balancing, and sends a service calling request by taking the access domain name as a target address; the modified Envoy component can receive the service calling request and perform a service discovery process according to the access domain name.

By means of the method 2, the Envoy component can support the service registration and service discovery capability of the registration center corresponding to the Dubbo application or the Spring Cloud application, but the mechanisms of routing, fault tolerance, load balancing and the like of the Dubbo application or the Spring Cloud application are not removed, so that the computing capability is wasted, and extra performance consumption is caused. In addition, the mode 2 needs to recompile the Envoy component, which not only has a large compiling workload and is easy to make mistakes, but also deviates from the development direction of the isio (namely, enjoying the perfect micro-service management capability of the isio through the capabilities of service discovery, load balancing and the like of the Envoy component), and is not easy to maintain.

In view of the above, the present application provides a method for interfacing a microservice grid and a proxy component. By the method provided by the embodiment of the application, the Dubbo application or the Spring Cloud application can interface the Istio in a non-invasive manner, the SDK of the Dubbo application or the Spring Cloud application does not need to be changed, the capacity of the Envoy component of the Istio does not need to be changed, the butt joint workload is reduced, and the development direction of the Istio is met.

The method for interfacing the isto service grid provided by the embodiment of the present application is described in detail below with reference to the drawings in the embodiment of the present application.

The method for interfacing the service grid of the indication service provided by the embodiment of the application can be divided into three flows, namely a service registration flow, a service discovery flow and a service invocation flow.

The method for interfacing to the otio service grid may be applied to an otio micro service system, and specifically may be applied to the otio micro service system 100 shown in fig. 1 below, or applied to the otio micro service system 300 shown in fig. 3 below. The following describes three flows included in the issue service grid method.

1. Service registration flow

Fig. 1 is a schematic structural diagram of an isio microservice system according to an embodiment of the present application. As shown in FIG. 1, the Istio microservice system 100 includes an API Server (Server) component, and one or more Kubernets pods (Pod) (FIG. 1 illustrates two Kubernets pods). Wherein, the application example 1 and the Envoy component 1 are deployed in Kubernets Pod 1, and the application example 2 and the Envoy component 2 are deployed in Kubernets Pod 2. Application example 1 is an application example of application program 1. Application example 2 is an application example of application program 2.

The API Server component provides a Server component of a management presentation layer state transfer (REST) interface for Kubernets to the outside. The API Server component can be used for creating and querying Kubernets Service objects and can also be used for querying Kubernets Endpoint objects. For example, the API Server component may create a Kubernets Service object for an application in response to a Service registration request by the application. As another example, the API Server component may query the IP addresses of one or more application instances of an application providing a target service based on the access domain name (i.e., kubernets domain name) of the application providing the target service.

The application instance 1, which may be a Dubbo application or a Spring Cloud application, is used to initiate a service registration procedure. The application example 1 may be a service consumer or a service provider. When the application example 1 is a service consumer, the application example 1 may also be used to initiate a service discovery process and a service invocation process; when the application example 1 is a service provider, the application example 1 may provide services for other applications. Similarly, the application example 2 may be a Dubbo application or a Spring Cloud application. The application instance 2 may also be a service consumer or a service provider. The embodiment of the present application does not limit the specific implementation manners of application example 1 and application example 2.

An agent component of the application instance, such as a java agent component, runs in the same process as the application instance. The agent component can be used to non-invasively modify the logic of service registration, service discovery, etc. of an application instance.

And the Envoy component is an Istio data plane proxy component. The Envoy component is used for being responsible for the flows of Service discovery, load balancing, micro-Service administration and the like of Kubernets Service.

Kubernetes Pod, the basic unit of operation of Kubernetes. Kubernets Pod may provide the same operating environment for the Envoy component and the Dubbo application, or for the Envoy component and the Spring Cloud application. A Kubernetes Pod can run one container, or multiple containers that need to work together.

It should be noted that the otio microservice system 100 shown in fig. 1 is only an example, and is not limited to the otio microservice system. For example, the Istio microservice system 100 may also include an Istio control plane proxy component, i.e., a Pilot (Pilot) component, and/or include an application deployment listening component for listening.

Fig. 2 is a flowchart illustrating a method for interfacing an isition service grid according to an embodiment of the present application. As shown in FIG. 2, the method is a service registration process of the Dubbo application or Spring Cloud application to the Istio. The method may be applied to the Istio microservice system 100 shown in FIG. 1. In order to facilitate understanding of the embodiment of the present application, the method flow shown in fig. 2 is described by taking the first application example as application example 1 in the otion micro service system 100.

S201: application instance 1 sends a first service registration request.

When the application instance 1 is started, a service registration process can be initiated according to the service registration logic of the application instance 1. For example, the application instance 1 may generate a first service registration request according to its service registration logic, and attempt to send the first service registration request to a registry corresponding to the application instance 1. The application example 1 may be a Dubbo application or a Spring Cloud application.

The service registration logic of application example 1 itself will be briefly described below by taking the Dubbo application and the Spring Cloud application as examples.

1. Taking application example 1 as the Dubbo application as an example, a single Dubbo application may include one or more Remote Procedure Call (RPC) services. The Dubbo application may register for services at RPC service granularity. In this case, the first service registration request is used to create registration information for each RPC service of the Dubbo application. Correspondingly, after the registration center corresponding to the Dubbo application receives the first service registration request, the registration center stores the registration information of the RPC service for use in subsequent service discovery. The first service registration request includes a service name of each RPC service of the Dubbo application. Wherein, the service name of the RPC service may be predefined for distinguishing from other RPC services of the Dubbo application. Taking application example 1 as the Dubbo application as an example, table 1 shows the application name of the Dubbo application and the service name of each RPC service of the Dubbo application. As shown in table 1, the application name of the Dubbo application is appcommand service, and the Dubbo application includes three RPC services, and the service names are com. It is understood that the items of data in table 1 are only an example, and the application name of the Dubbo application and the service name of the RPC service are not limited.

TABLE 1

Alternatively, the Dubbo application may also perform service registration at application granularity. In this case, the first service registration request is used to create registration information for the Dubbo application. Correspondingly, after the registration center corresponding to the Dubbo application receives the first service registration request, the registration information of the Dubbo application is stored in the registration center for use in subsequent service discovery. The first service registration request includes an application name of the Dubbo application. Among them, the application name of the Dubbo application may be predefined for distinguishing from other Dubbo applications. The application names of the Dubbo application can be shown in table 1, and are not described herein.

2. Taking the application example 1 as the Spring Cloud application as an example, the Spring Cloud application performs service registration with the application program as the granularity. In this case, the first service registration request is used to create registration information for the Spring Cloud application. Accordingly, after receiving the first service registration request, the registry (e.g., eureka) corresponding to the Spring Cloud application stores the registration information of the Spring Cloud application in the registry for use in subsequent service discovery. The first service registration request includes an application name of the Spring Cloud application. Among them, the application name of the Spring Cloud application may be predefined for distinguishing from other Spring Cloud applications, such as appmbservice, appnservice, etc.

S202: the agent component of application instance 1 intercepts a first service registration request.

After the application instance 1 generates the first service registration request according to its service registration logic, the agent component running in the same process as the application instance 1 detects the first service registration request, and intercepts the first service registration request, so that the application instance 1 cannot send the first service registration request. That is to say, before the application instance 1 sends out the first service registration request, the agent component running in the same process as the application instance 1 intercepts the first service registration request, so that the first service registration request is not sent to the registry corresponding to the application instance 1, in other words, the application instance 1 does not register according to its service registration logic, and thus the service registration logic of the application instance 1 itself can be shielded.

S203: and the agent component of the application example 1 generates a second service registration request according to the identification information of the application example 1.

And after the agent component of the application example 1 intercepts the first service registration request, initiating service registration to the API Server component by using the application name of the application example 1. Specifically, after intercepting the first service registration request, the agent component of the application instance 1 may obtain an application name of the application instance 1, and generate a second service registration request according to the application name of the application instance 1. For example, the agent component of the application instance 1 may obtain the application name of the application instance 1 by reading the attribute information, the configuration information, or the environment variable name of the application instance 1. The second service registration request includes the application name of application instance 1.

S204: the agent component of application instance 1 sends a second service registration request to the API Server component. Accordingly, the API Server component receives the second service registration request.

The agent component of the application example 1 can obtain the access address of the API Server component through the environment variable configured when the application example 1 is deployed, and send the second service registration request to the API Server component according to the access address of the API Server component.

Taking application example 1 as the Dubbo application as an example, table 2 shows an illustration of environment variables configured when the Dubbo application is deployed. As shown in Table 2, the environment variable is named KUBE _ API _ SERVER, and is used for representing the access address of the API Server component, such as http:// 192.168.0.2; the environment variable name is KUBE _ NAMESPACE, which is used for representing name space (NAMESPACE), such as mynamespace; the environment variable NAME is KUBE _ APP _ NAME, and is used to represent the application NAME of the Dubbo application, such as myapp. The agent component of the Dubbo application can obtain the IP address, namespace, and its own application name of the API Server component through table 2. It should be understood that, the implementation process of the agent component of the Spring Cloud application acquiring the access address, namespace, and the application name of the API Server component is similar to that of the Dubbo application, and specifically, reference may be made to the related description of the Dubbo application, and details are not repeated here.

TABLE 2

Name of environment variable	Means of	Parameter value
			KUBE_API_SERVER	Access address of API Server component	http://192.168.0.2:8080
KUBE_NAMESPACE	namespace	mynamespace
			KUBE_APP_NAME	Application name of Dubbo application	myapp

S205: the API Server component creates a Kubernets Service object according to the application name of the application instance 1.

The API Server component may create a kubernets Service object for the application example 1 by using a format of "application name + Service", where if the application name of the application example 1 is myapp, the name of the kubernets Service object corresponding to the application example 1 may be myappservice. For example, the API Server component may call POST http:// 192.168.0.2. Wherein, the value of { NAMESPACE } is the parameter value corresponding to KUBE _ NAMESPACE.

Taking an application example 1 as a Dubbo application as an example, the type of a Kubernetes Service object corresponding to the application example 1 is Service, and the interface version is v1; the name of the Kubernets Service object is myappservice, and the application name of the application example 1 is myapp; the access protocol of the kuberenetes Service object corresponding to the application example 1 is a Transmission Control Protocol (TCP), the access port is 9376, and the target port is 9376. Specifically, the kubernets Service object created by the API Server component for application instance 1 may be as follows.

It should be understood that, the implementation process of the API Server component creating the kubernets Service object for the Spring Cloud application is similar to that of the Dubbo application, and specific reference may be made to the related description of the Dubbo application, and details are not described here.

In one possible implementation, the API Server component may record the IP address of application instance 1 after receiving the second service registration request. For example, the API Server component may record the IP address of application instance 1 according to the kubernets domain name corresponding to application 1. As shown in table 3, the kubernets domain name corresponding to appservce is kubernets domain name 1, appservce includes three application examples, that is, application example 1, application example 2, and application example 3, and the IP addresses are IP address 1, IP address 2, and IP address 3, respectively; the Kubernets domain name corresponding to the appservice is Kubernets domain name 2, the appservice comprises an application example, namely, application example 4, and the IP address is IP address 4. It is understood that each item of data in table 3 is only an example, and the embodiment of the present application is not limited thereto.

TABLE 3

Optionally, after step S205, the API Server component may send a service registration response to the agent component of application instance 1 to indicate whether application instance 1 is successfully registered. For example, if the API Server component successfully creates a kubernets Service object for application instance 1, then the Service registration response is used to indicate that the Service registration for application instance 1 was successful. For another example, if the API Server component fails to create a kubernets Service object for application instance 1, then the Service registration response is used to indicate that the Service registration for application instance 1 failed. The specific flow of the API Server component sending the service registration response to the agnet component of the application instance 1 may be as shown in step S206.

S206: the API Server component sends a second service registration response to the agent component of application instance 1. Accordingly, the agent component of application instance 1 receives the second service registration response.

After completing the creation of the kubernets Service object for application instance 1, the API Server component may send a second Service registration response to the agent component of application instance 1 indicating success or failure of the Service registration of application instance 1.

S207: the agent component of application instance 1 sends a first service registration response to application instance 1. Accordingly, application instance 1 receives the first service registration response.

After receiving the second service registration response, the agent component of the application instance 1 may send a first service registration response to the application instance 1, where the first service registration response is used to indicate that the service registration of the application instance 1 is successful or failed. For example, after receiving the second service registration response, the agent component of the application instance 1 performs processing such as parsing on the second service registration response, generates a first service registration response, and then sends the first service registration response to the application instance 1. When the second service registration response is used for indicating that the service registration of the application instance 1 is successful, the first service registration response is also used for indicating that the service registration of the application instance 1 is successful; when the second service registration response is used to indicate that the service registration of the application instance 1 failed, the first service registration response is also used to indicate that the service registration of the application instance 1 failed.

Through the embodiment, after the application instance 1 generates the first service registration request according to the original service registration logic, the agent component of the application instance 1 intercepts the first service registration request, so that the application instance 1 cannot send the first service registration request to the registry corresponding to the application instance 1. After the first service registration request is intercepted, the agent component of the application instance 1 initiates a service registration process to the API Server component by using the application name of the application instance 1, so that the API Server component replaces the registration center corresponding to the application instance 1 to complete the service registration of the application instance 1, and the process that the application instance 1 performs service registration in the corresponding registration center can be shielded. That is, the developer can avoid conflicts between the application instance 1's own service registration logic and the Istio's service registration logic by modifying the agent component of the application instance 1. Moreover, the SDK of the application example 1 does not need to be changed and the service registration logic of the Istio does not need to be changed for upgrading or modifying the agent component of the application example 1, so that the application example 1 can be used for carrying out non-invasive connection on the Istio, and the workload can be reduced.

The service registration process of the Dubbo application or the Spring Cloud application is described above, and the service discovery process of the Dubbo application or the Spring Cloud application is described next.

2. Service discovery process

Fig. 3 is a schematic structural diagram of an otio microservice system provided in the embodiment of the present application. As shown in FIG. 3, the Istio microservice system 300 includes an API Server component, a Pilot component, and one or more Kubernets Pod (FIG. 3 illustrates Kubernets Pod 1 and Kubernets Pod 2). Wherein, the application example 1 and the Envoy component 1 are deployed in Kubernets Pod 1, and the application example 2 and the Envoy component 2 are deployed in Kubernets Pod 2. In addition, the descriptions of the API Server component, the Envoy component, the agent component, and the kubernets Pod can refer to the related contents mentioned above, and are not repeated herein.

The application example 1 may be a service consumer or a service provider. When the application example 1 is a service consumer, the application example 2 may be a service provider providing a service for the application example 1; when the application instance 2 is a service consumer, the application instance 1 may be a service provider providing a service for the application instance 2. Application example 1 may be a Dubbo application, or a Spring Cloud application. Further, if application example 1 is a Dubbo application, application example 2 is also a Dubbo application; if application example 1 is a Spring Cloud application, application example 2 is also a Spring Cloud application.

For the convenience of understanding the embodiment of the present application, the following description takes application example 1 as a service consumer, and application example 2 is a service provider providing services for application example 1.

And the Pilot component is an Istio control plane proxy component. The Pilot component can be used for receiving the service discovery request from the Envoy component, interacting with the API Server component to obtain the service discovery result, and sending the service discovery result to the Envoy component. The Pilot component can also be used for configuring and issuing service governance strategies such as a current limiting strategy and the like to the Envoy component, so that the Envoy component realizes micro-service governance according to the service governance strategies.

It should be noted that the isto microservice system 300 shown in fig. 3 is only an example, and is not limited to the isto microservice system. For example, the microservice system 300 may also include an application deployment listening component for listening, and the like.

Fig. 4 is a flowchart illustrating a method for interfacing to an isition service grid according to an embodiment of the present application. As shown in FIG. 4, the method is a service discovery process of the Dubbo application or Spring Cloud application to the Istio. The method may be applied to the Istio microservice system 300 shown in FIG. 3. Taking the first application instance as application instance 1 in the Istio microservice system 300 and the second application instance as application instance 2 in the Istio microservice system 300 as an example, the method may include the following steps.

S401: application instance 1 sends a first service discovery request.

Application instance 1 may initiate a service discovery process according to its own service discovery logic. For example, the application instance 1 may generate the first service discovery request according to its service discovery logic, and attempt to send the first service discovery request to the registry corresponding to the application instance 1. The first service discovery request is used to obtain a set of IP addresses comprising IP addresses of one or more application instances of the application program 2. Wherein the application 2 is used to provide the target service. The one or more application instances comprise application instance 2.

In a possible embodiment, the first service discovery request may include identification information of the application 2. The identification information of the application 2 includes an application name of the application 2 (also referred to as an application name of the application instance 2), or includes a service name of the target service, or includes the application name of the application 2 and the service name of the target service. For example, when the application 2 is a Dubbo application, the identification information of the application 2 may include an application name of the application 2, for example, the application instance of the application 2 performs service registration with the application name as granularity according to its service registration logic, and the application instance 1 performs service discovery with the application name of the application 2 as granularity in step S401; or, the service name of the target service is included, the target service is an RPC service, for example, the application instance of the application program 2 performs service registration with the service name as granularity according to its service registration logic, and the application instance 1 performs service discovery with the service name of the RPC service as granularity in step S401; or, the application name of the application 2 and the service name of the target service. For another example, when the application 2 is a Spring Cloud application, the identification information of the application 2 may include an application name of the application 2.

The application instance 1 may initiate a service discovery process to an application program (i.e., the application program 2) providing the target service through locally stored configuration information and the like, and obtain identification information of the application program 2. For example, at initial deployment of the network, application instance 1 may obtain identification information for one or more application programs for which the service is provided. It is understood that one or more of the application programs providing services to application instance 1 may be provided, and that application instance 1 may also provide services to one or more other application programs.

S402: the agent component of application instance 1 intercepts a first service discovery request.

After the application instance 1 generates the first service discovery request according to the service discovery logic of the application instance 1, the agent component running in the same process as the application instance 1 detects the first service discovery request and intercepts the first service discovery request, so that the application instance 1 cannot send the first service discovery request. That is to say, before the application instance 1 sends the first service discovery request, the agent component running in the same process as the application instance 1 intercepts the first service discovery request, so that the first service discovery request is not sent to the registry corresponding to the application instance 1, in other words, the application instance 1 does not perform service discovery according to its service discovery logic, thereby shielding the service discovery logic of the application instance 1 itself.

S403: the agent component of application instance 1 generates a first service discovery response.

After the agent component of application instance 1 intercepts the first service discovery request, a first service discovery response may be generated. Specifically, the agent component of the application example 1 may generate a first service discovery response according to the identification information of the application program 2, and an IP address set in the first service discovery response is filled as a kubernets domain name corresponding to the application program 2. The one kubernets domain name is associated with a kubernets Service object corresponding to one or more application instances of the application program 2. Wherein the set of IP addresses comprises a set of IP addresses of one or more application instances that provide the target service.

As an example, when the application instance 1 initiates the service discovery process with the application name, that is, the first service discovery request includes the application name providing the application program 2, the agent component of the application instance 1 may construct a kubernets domain name with the application name of the application program 2 and an environment variable (e.g., namespace environment variable) of the application instance 1, and generate the first service discovery response according to the constructed kubernets domain name. The environment variable of application example 1 may be KUBE _ NAMESPACE in table 2.

Illustratively, the agent component of application instance 1 may construct the kubernets domain name in the format of "application name of application providing target service. For example, the application name of the application providing the target service is appbservice, KUBE _ NAMESPACE is mynamespace, and the agent component of application example 1 constructs the kubernets domain name according to the application name of the application providing the target service and the environment variable of application example 1, which may be appbservice.

As another example, when the application instance 1 initiates the service discovery process with the service name of the target service, that is, the first service discovery request includes the service name of the target service, the agent component of the application instance 1 may obtain the application name of the application program providing the target service according to the configuration file, and construct the kubernets domain name according to the application name of the application program providing the target service and the environment variable of the application instance 1, thereby generating the first service discovery response. The configuration file comprises the corresponding relation between the service name and the application name.

Taking application example 1 as a Dubbo application as an example, table 4 shows an illustration of a configuration file of application example 1. As shown in table 4, the RPC service is com.company.dubbo.demo.service, and the application program providing the RPC service is appbservice; the RPC service is com.company.dubbo.demo.servicec1, and the application program providing the RPC service is appservice; the RPC service is com.company.dubbo.demo.servicec2, and the application program providing the RPC service is appservice. It should be understood that one application may provide one or more RPC services, and the same RPC service may also be provided by one or more applications. Table 4 is an example, and does not limit the data of the configuration file.

TABLE 4

The first service discovery response generated by the agent component of the application example 1 includes the kubernets domain name, which is not the IP address set, so that after the application example 1 receives the first service discovery response, the service invocation request can be initiated according to the kubernets domain name without performing routing, load balancing and the like on the kubernets domain name, thereby saving the flows of routing, load balancing and the like of the application example 1, reducing the calculation amount of the application example 1 and reducing the performance consumption.

S404: the agent component of application instance 1 sends a first service discovery response to application instance 1. Accordingly, application instance 1 receives the first service discovery response.

After the agent component of the application instance 1 constructs a kubernets domain name corresponding to the application program 2, a first service discovery response may be sent to the application instance 1, where the first service discovery response includes the kubernets domain name.

S405: application instance 1 sends a first service invocation request.

The application example 1 initiates a service calling process according to the service calling logic of the application example. Specifically, after receiving the first service discovery response, the application instance 1 generates a first service invocation request, and attempts to send the first service invocation request to the target application instance. Wherein the first service invocation request includes a kubernets domain name.

S406: the Envoy component 1 intercepts the first service invocation request.

The application instance 1 sends a first service invocation request according to the service invocation logic of the application instance 1, the Envoy component 1 deployed in the same Kubernets Pod as the application instance 1 detects the first service invocation request, and the first service invocation request is intercepted, so that the logic error caused by sending the first service invocation request when the application instance 1 does not acquire the IP address of the target application instance is avoided. Further, after intercepting the first service invocation request, the Envoy component 1 initiates a service discovery process according to the kubernets domain name included in the first service invocation request to obtain an IP address set corresponding to the kubernets domain name, that is, IP addresses of one or more application instances of the application program 2 providing the target service, and a target application instance providing the target service, such as the application instance 2. The service discovery process initiated by the Envoy component 1 may be as shown in step S407 to step S410.

S407: envoy component 1 sends a second service discovery request to the Pilot component. Accordingly, the Pilot component receives a second service discovery.

The Envoy component 1 generates a second service discovery request according to the kubernets domain name included in the first service invocation request, and sends the second service discovery request to the Pilot component. Wherein the kubernets domain name is included in the second service discovery request. The second service discovery request may also be referred to as a service query request, and the like, and the embodiment of the present application is not limited thereto.

S408: the Pilot component sends a second service discovery request to the API Server component. Accordingly, the API Server component receives a second service discovery request.

And after receiving the second service discovery request, the Pilot component forwards the second service discovery request to the API Server component.

S409: the API Server component sends a second service discovery response to the Pilot component. Accordingly, the Pilot component receives a second service discovery response.

And after receiving the second service discovery request, the API Server component queries an IP address set corresponding to the Kubernets domain name according to the Kubernets domain name included in the second service discovery request. For example, the API Server component may determine, according to the kubernets domain name, the application name of the application 2 corresponding to the kubernets domain name, and determine, according to the application name of the application 2, the IP address set of one or more application instances of the application 2, as shown in table 3. And after the API Server component acquires the IP address set, generating a second service discovery response according to the IP address set, and sending the second service discovery response to the Pilot component. Wherein the second service discovery response includes a set of IP addresses. The set of IP addresses includes the IP address of application instance 2.

S410: the Pilot component sends a second service discovery response to the Envoy component 1. Accordingly, the Envoy component 1 receives the second service discovery response.

After receiving the second service discovery response, the Pilot component forwards the second service discovery response to the Envoy component 1, so that the Envoy component 1 obtains the set of IP addresses of the one or more application instances of the application program 2 providing the target service.

Through the embodiment, the agent component of the application instance 1 intercepts the first service discovery request sent by the original service discovery logic of the application instance 1, constructs a kubernets domain name according to the identification information of the application program providing the target service, and sends the kubernets domain name to the application instance 1, so that the service discovery logic of the application instance 1 can be shielded, and the conflict between the service discovery logic of the application instance 1 and the service discovery logic of the Istio can be avoided. In addition, the service discovery response received by the application example 1 includes the kubernets domain name instead of the IP address set, and the application example 1 can initiate the service invocation request according to the kubernets domain name without performing routing, load balancing, and the like on the kubernets domain name, so that the flows of routing, load balancing, and the like of the application example 1 can be omitted, the calculation amount of the application example 1 can be reduced, and the performance consumption can be reduced.

Moreover, the SDK of the application example 1 does not need to be changed or the service discovery logic of the Istio does not need to be changed when the agent component of the application example 1 is upgraded or modified, so that the application example 1 can be used for carrying out non-invasive butt joint on the Istio, and the workload can be reduced.

Further, the Envoy component intercepts a first service call request sent by an original service call logic of the application instance 1, and initiates a service discovery process according to a kubernets domain name included in the first service call request to acquire IP addresses of one or more application instances providing a target service, so that service discovery when the application instance 1 is connected to an issue can be realized.

In step S410, the Envoy component 1 deployed in the same kubernets Pod as the application instance 1 acquires an IP address set, that is, an IP address set of one or more application instances of the application program 2 providing the target service, and then the Envoy component 1 may initiate a service invocation process according to the IP address set. The service call flow when the Dubbo application (or Spring Cloud application) interfaces the Istio is described below with reference to FIG. 5.

3. Service invocation flow

Fig. 5 is a flowchart illustrating a method for interfacing to an isition service grid according to an embodiment of the present application. As shown in FIG. 5, the method is a service call flow of Dubbo application or Spring Cloud application to the Istio. The method may be applied to the Istio microservice system 300 shown in FIG. 3. In fig. 4 the Envoy component 1 receives a second service discovery response comprising a set of IP addresses, and the Envoy component 1 then executes service invocation logic, as described in detail below.

S411: the Envoy component 1 determines to initiate a service call according to the governing rule of the application instance 1.

The Envoy component 1 may determine whether to initiate a service call according to the governance rules of this application instance 1. For example, the Envoy component 1 executes a consumer-side governance policy, such as a fusing mechanism, call chain analysis, and the like, according to the governance rule of the application instance 1, and determines whether to initiate a service call. If the Envoy component 1 determines to initiate the service call, executing the contents of the steps S412 and S413; otherwise, the Envoy component 1 sends a service invocation result to the application instance 1, the service invocation result indicating that the service invocation failed. In the embodiment of the present application, description is given by taking the example that the Envoy component 1 determines to initiate a service call. The Envoy component 1 can acquire the governance rule of the application instance 1 by interacting with the Pilot component, for example, when kubernets Pod 1 is deployed, the Envoy component 1 acquires the governance rule of the application instance 1.

S412: the Envoy component 1 selects an IP address from the set of IP addresses according to a load balancing algorithm.

For example, the Envoy component 1 may select one of the IP addresses from the IP address set by a round robin, or random, etc. load balancing algorithm. In the embodiment of the present application, a description is given by taking an IP address selected by the Envoy component 1 as an IP address of the application instance 2, that is, taking the target application instance as the application instance 2 as an example.

S413: envoy component 1 sends a second service invocation request to Envoy component 2. Accordingly, the Envoy component 2 receives the second service invocation request.

And the Envoy component 1 sends a second service calling request to the Envoy component 2 deployed in the same Kubernets Pod as the application instance 2 according to the IP address of the application instance 2.

S414: the Envoy component 2 determines to forward the second service invocation request according to the governance rules of the application instance 2.

The Envoy component 2 may determine whether to forward the second service invocation request to application instance 2 according to the governance rules of application instance 2. For example, the Envoy component 2 may determine whether to forward the second service call to application instance 2 based on the restriction, authentication, etc. information of application instance 2. For example, the current flow of the application instance 2 does not exceed the limit, and the second service invocation request is determined to be a legal request through authentication and authentication, the Envoy component 2 determines to forward the second service invocation request, i.e. executes the content of step S415; otherwise, the Envoy component 2 determines not to forward the second service invocation request and sends a service invocation result to the application instance 1, the service invocation result being used to indicate that the service invocation failed. In the embodiment of the present application, the Envoy component 2 determines to forward the second service invocation request. The Envoy component 2 can acquire the governance rule of the application instance 2 by interacting with the Pilot component, for example, when the kubernets Pod 2 is deployed, the Envoy component 2 acquires the governance rule of the application instance 2.

S415: the Envoy component 2 sends a second service invocation request to application instance 2. Accordingly, application instance 2 receives the second service invocation request.

S416: application instance 2 sends the target service execution result to the Envoy component 2. Accordingly, the Envoy component 2 receives the target service execution result.

And after receiving the second service calling request, the application example 2 analyzes the second service calling request, provides the target service for the application example 1, obtains a target service execution result, and sends the target service execution result to the invoy component 2.

S417: the Envoy component 2 sends the target service execution result to the Envoy component 1. Accordingly, the Envoy component 1 receives the target service execution result.

S418: the Envoy component 1 sends the target service execution result to the application instance 1. Accordingly, the application instance 1 receives the target service execution result.

In the embodiments provided in the present application, the method provided in the embodiments of the present application is introduced from the perspective of interaction between the components, respectively. The method for interfacing the Istio service grid provided by the embodiment of the application can be applied to agent components, and the agent components can run in electronic equipment. The electronic device may be a Computer cluster, a server (e.g., a cloud-end server, a server cluster, or the like), a car machine, a car speaker, a car microphone, a mobile phone, a tablet Computer, a desktop Computer, a laptop Computer, a notebook Computer, an Ultra-mobile Personal Computer (UMPC), a handheld Computer, a netbook, a Personal Digital Assistant (PDA), a wearable electronic device, or an electronic device such as a virtual reality device. Alternatively, the electronic device according to the embodiment of the present application may be a functional module, such as a chip or a system of chips, provided in any of the electronic devices.

In order to implement the functions in the method provided by the embodiment of the present application, the agent component may include a hardware structure and/or a software module, and implement the functions in the form of a hardware structure, a software module, or a hardware structure plus a software module. Whether any of the above-described functions is implemented as a hardware structure, a software module, or a hardware structure plus a software module depends upon the particular application and design constraints imposed on the technical solution.

Fig. 6 shows a schematic structural diagram of a communication apparatus 600, which may be deployed in an electronic device and is capable of implementing functions implemented by an agent component of application example 1 in the method provided in the embodiment of the present application. The communication device 600 may be a hardware structure, a software module, or a hardware structure plus a software module. The communication apparatus 600 may be implemented by a system-on-chip. In the embodiment of the present application, the chip system may be composed of a chip, and may also include a chip and other discrete devices.

The communication device 600 may include a processing module 601 and a communication module 602.

Illustratively, the processing module 601 is configured to intercept a service discovery request sent by a first application instance in the microservice system, where the service discovery request is used to obtain an IP address set corresponding to one or more second application instances in the microservice system, where the second application instances are used to provide a target service.

A communication module 602, configured to send a service discovery response to the first application instance, where the service discovery response includes a domain name corresponding to the IP address set. The domain name corresponding to the IP address set may be a kubernets domain name.

Wherein the agent component runs in the same process as the first application instance, and the agent component is not integrated in the first application instance.

Optionally, the first application example is an application developed based on a Dubbo architecture, or an application developed based on a Spring Cloud architecture.

In one possible embodiment, the first service discovery request includes identification information of the second application instance; the processing module 601 is further configured to construct the domain name according to the identification information of the second application instance and the environment variable of the first application instance; and generating the service discovery response according to the domain name.

The identification information comprises an application name of the second application instance, or comprises a service name of the target service, or comprises the application name of the second application instance and the service name of the target service.

In a possible implementation manner, the identification information includes an application name of the second application instance, and the processing module 601 is specifically configured to: and constructing the domain name according to the application name of the second application instance and the environment variable of the first application instance.

In a possible implementation manner, the identification information includes a service name of the target service, and the processing module 601 is specifically configured to: according to the identification information of the second application instance and the environment variable of the first application instance, constructing the domain name may be: the agent component acquires the application name of the second application instance according to the configuration file and the service name of the target service, and constructs the domain name according to the application name of the second application instance and the environment variable of the first application instance; the configuration file comprises a corresponding relation between a service name of a target service and an application name of an application instance providing the target service.

In one possible embodiment, the microservice system further comprises an interface server component; the processing module 601 is further configured to intercept a first service registration request sent by the first application instance; generating a second service registration request according to the first service registration request, wherein the second service registration request comprises the application name of the first application instance; the communication module 602 is further configured to send the second service registration request to the interface server component.

In one possible implementation, the communication module 602 is further configured to: receiving a second service registration response sent from the interface server component, the second service registration response being operable to indicate a success or failure of the first application instance registration. The processing module 601 is further configured to: generating a first service registration response according to the second service registration response; the communication module 602 is further configured to send a first service registration response to the first application instance, the first service registration response indicating a success or failure of the first application instance registration. And if the second service registration response is used for indicating that the first application instance is successfully registered, the first service registration response is also used for indicating that the first application instance is successfully registered. If the second service registration response is used to indicate that the first application instance registration failed, the first service registration response is also used to indicate that the first application instance registration failed.

The communication module 602 is used for the communication device 600 to communicate with other modules, and may be a circuit, a device, an interface, a bus, a software module, a transceiver, or any other device capable of implementing communication.

All relevant contents of each step related to the above method embodiment may be referred to the functional description of the corresponding functional module, and are not described herein again.

The division of the modules in the embodiments of the present application is schematic, and is only a logical function division, and in actual implementation, there may be another division manner, and in addition, each functional module in each embodiment of the present application may be integrated in one processor, or may exist alone physically, or two or more modules are integrated in one module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode.

Fig. 7 is an electronic device 700 provided in the embodiment of the present application, where the electronic device 700 is capable of implementing the functions implemented by the agent component of application example 1 in the method provided in the embodiment of the present application. The electronic device 700 may also be the electronic device itself or a component of the electronic device (e.g., a chip or system of chips). In the embodiment of the present application, the chip system may be composed of a chip, and may also include a chip and other discrete devices.

In a hardware implementation, the communication module 602 may be a transceiver, and the transceiver is integrated in the electronic device 700 to form the communication interface 710.

The electronic device 700 may comprise at least one processor 720 for implementing or for enabling the electronic device 700 to implement the functions implemented by the agent component of the application instance 1 in the methods provided by the embodiments of the present application. For example, the processor 720 may intercept a first service discovery request sent by the application instance 1, and generate a first service discovery response, which is specifically described in the detailed description of the method example and is not described herein again. For another example, the processor 720 may intercept the first service invocation request sent by the application example 1, which is specifically described in detail in the method example and is not described herein again.

The electronic device 700 may also include at least one memory 730 for storing program instructions and/or data. Memory 730 is coupled to processor 720. The coupling in the embodiments of the present application is an indirect coupling or a communication connection between devices, units or modules, and may be an electrical, mechanical or other form for information interaction between the devices, units or modules. Processor 720 may cooperate with memory 730. Processor 720 may execute program instructions stored in memory 730. At least one of the at least one memory may be included in the processor.

The electronic device 700 may also comprise a communication interface 710 for communicating with other devices over transmission media such that the apparatus used in the electronic device 700 may communicate with other devices. Illustratively, the other device may be an electronic device running the application instance 2. Processor 720 may send and receive data using communication interface 710. The communication interface 710 may specifically be a transceiver.

The specific connection medium among the communication interface 710, the processor 720 and the memory 730 is not limited in the embodiments of the present application. In the embodiment of the present application, the memory 730, the processor 720 and the communication interface 710 are connected by a bus 740 in fig. 7, the bus is represented by a thick line in fig. 7, and the connection manner between other components is merely illustrative and not limited. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 7, but that does not indicate only one bus or one type of bus.

In the embodiments of the present application, the processor 720 may be a general-purpose processor, a digital signal processor, an application specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, and may implement or execute the methods, steps, and logic blocks disclosed in the embodiments of the present application. A general purpose processor may be a microprocessor or any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware processor, or may be implemented by a combination of hardware and software modules in a processor.

In the embodiment of the present application, the memory 730 may be a nonvolatile memory, such as a Hard Disk Drive (HDD) or a solid-state drive (SSD), and may also be a volatile memory (RAM), for example. The memory is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to such. The memory in the embodiments of the present application may also be circuitry or any other device capable of performing a storage function for storing program instructions and/or data.

The methods provided in the embodiments of the present application may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the invention to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, a network appliance, a user device, or other programmable apparatus. The computer instructions may be stored in or transmitted from a computer-readable storage medium to another computer-readable storage medium, e.g., from one website, computer, server, or data center, over a wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL), or wireless (e.g., infrared, wireless, microwave, etc.) network, the computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device including one or more integrated servers, data centers, etc. the available medium may be magnetic (e.g., floppy disks, hard disks, tapes), optical (e.g., digital Video Disks (DVDs)), or semiconductor media (e.g., SSDs), etc.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

Claims (13)

1. A method of interfacing a microservice grid, the method performed by a proxy component of a microservice system, the method comprising:

the agent component intercepts a service discovery request sent by a first application instance in the micro service system, wherein the service discovery request is used for acquiring an IP address set corresponding to one or more second application instances in the micro service system, and the second application instances are used for providing target services;

the proxy component sends a service discovery response to the first application instance, wherein the service discovery response comprises a domain name corresponding to the set of IP addresses.

2. The method of claim 1, wherein the first service discovery request includes identification information of the second application instance, the method further comprising:

the agent component constructs the domain name according to the identification information of the second application instance and the environment variable of the first application instance;

the proxy component generates the service discovery response according to the domain name.

3. The method of claim 2, wherein the identification information comprises a service name of the target service, and wherein constructing the domain name according to the identification information of the second application instance and the environment variable of the first application instance comprises:

the proxy component acquires the application name of the second application instance according to a configuration file and the service name of the target service, wherein the configuration file comprises the corresponding relation between the service name of the target service and the application name of the application instance providing the target service;

and the proxy component constructs the domain name according to the application name of the second application instance and the environment variable of the first application instance.

4. The method of any of claims 1 to 3, wherein the microservice system further comprises an interface server component, and wherein prior to the proxy component intercepting the service discovery request issued by the first application instance, the method further comprises:

the agent component intercepts a first service registration request sent by the first application instance;

the agent component generates a second service registration request according to the first service registration request, wherein the second service registration request comprises the application name of the first application instance;

the proxy component sends the second service registration request to the interface server component.

5. The method according to any one of claims 1 to 4, wherein the first application instance is an application developed based on an open source distributed service framework or an application developed based on a distributed cloud service framework.

6. A proxy component, comprising a processing module and a communication module;

the processing module is used for intercepting a service discovery request sent by a first application instance in a micro service system, wherein the service discovery request is used for acquiring an IP address set corresponding to one or more second application instances in the micro service system, and the second application instances are used for providing target services;

the communication module is configured to send a service discovery response to the first application instance, where the service discovery response includes a domain name corresponding to the IP address set.

7. The component of claim 6, wherein the first service discovery request includes identification information of the second application instance;

the processing module is further configured to construct the domain name according to the identification information of the second application instance and the environment variable of the first application instance; and generating the service discovery response according to the domain name.

8. The component of claim 7, wherein the identification information comprises a service name of the target service;

the processing module is configured to obtain an application name of the second application instance according to a configuration file and the service name of the target service, where the configuration file includes a correspondence between the service name of the target service and the application name of the application instance providing the target service; and constructing the domain name according to the application name of the second application instance and the environment variable of the first application instance.

9. The assembly of any of claims 6 to 8, wherein the microservice system further comprises an interface server assembly;

the processing module is further configured to intercept a first service registration request sent by the first application instance; generating a second service registration request according to the first service registration request, wherein the second service registration request comprises the application name of the first application instance;

the communication module is further configured to send the second service registration request to the interface server component.

10. The component of any of claims 6 to 9, wherein the first application instance is an application developed based on a distributed service framework or an application developed based on a distributed cloud service framework.

11. A cluster of computing devices comprising one or more computing devices, the computing devices comprising memory and one or more processors;

the one or more processors are coupled with the memory for storing a computer program or instructions that, when executed by the one or more processors, cause the computing device to perform the method of any of claims 1-5.

12. A computer-readable storage medium, characterized in that the computer-readable storage medium is for storing a computer program which, when run on an electronic device, causes the electronic device to perform the method of any of claims 1 to 5.

13. A computer program product comprising instructions which, when run on an electronic device, cause the electronic device to perform the method of any of claims 1 to 5.

Images