CN114615320A

CN114615320A - Service governance method, service governance device, electronic equipment and computer-readable storage medium

Info

Publication number: CN114615320A
Application number: CN202210239258.1A
Authority: CN
Inventors: 廖雪峰; 于晓光
Original assignee: Asiainfo Technology Nanjing Co ltd
Current assignee: Asiainfo Technology Nanjing Co ltd
Priority date: 2022-03-11
Filing date: 2022-03-11
Publication date: 2022-06-10
Anticipated expiration: 2042-03-11
Also published as: CN114615320B

Abstract

The embodiment of the application provides a service management method and device, electronic equipment and a computer-readable storage medium, and relates to the technical field of cloud and native technology. The method is applied to a CSF client of a cloud service framework and comprises the following steps: initiating service call of the target service through the service code; then, acquiring service information corresponding to the target service currently through a cloud native registry, wherein the service information comprises at least one of service information of a micro service discovery service (MDS) or service information of a service interface discovery service (FDS); then, according to the service information, determining a target service end corresponding to the target service currently; and then, based on the service information, the service management of the target service is completed by calling the target service to the target service terminal. The embodiment of the application not only expands the MDS for realizing micro-service-level service management, but also expands the FDS for realizing method-level service management based on the xDS protocol.

Description

Service governance method, service governance device, electronic equipment and computer-readable storage medium

Technical Field

The application relates to the technical field of cloud and native, in particular to a service governance method, a service governance device, electronic equipment and a computer-readable storage medium.

Background

In recent years, cloud-based technologies have been rapidly developed and widely used in various industries. The application design of the cloud native technology is oriented to a micro-service architecture, a single application is split into a plurality of micro-services, and each micro-service is deployed in a container arrangement platform in a container mode. Under the micro-service architecture, the industry generally governs the traffic between micro-services through an Istio platform to ensure the safety of micro-service application, and the Istio platform is an open platform suitable for service governance of cloud native scenes.

The Istio is the most widely known service grid architecture at present, is one of the most common implementations of service grids, provides a complete solution, and meets the diversified requirements of micro-service application programs by providing behavior insight and operation control for the whole service grid. Kubernets is currently the only container organizational framework supported by Istio, which is based on Kubernets 'cloud-native, and the managed services are all individual container instances that run on top of Kubernets' cloud-native. The micro-service of the existing operator core system is not completely split according to the principle of the micro-service, and more is a concept of centralization, one application system consisting of a plurality of services is operated in each container instance, correspondingly, the micro-service hosted by the registration center of Kubernetes is specifically information of the application instance, essentially belongs to the application level, and cannot acquire service information of a service interface level and a micro-service level, so that the service administration of the interface level and the service administration of the micro-service level cannot be realized.

Disclosure of Invention

The embodiment of the application provides a service management method, a service management device, electronic equipment and a computer-readable storage medium, which can realize interface-level service management and micro-service-level service management. The technical scheme is as follows:

according to an aspect of the embodiments of the present application, there is provided a service administration method applied to a cloud service framework CSF client, the method including:

initiating service call of the target service through the service code;

acquiring service information currently corresponding to a target service through a cloud native registry, wherein the service information comprises at least one of service information of a micro service discovery service (MDS) or service information of a service interface discovery service (FDS);

determining a target server side corresponding to the target service currently according to the service information;

and based on the service information, the service management of the target service is completed by calling the target service to the target service terminal.

In a possible implementation manner, acquiring, by a cloud native registry, service information currently corresponding to a target service includes:

the method comprises the steps that APIServer is monitored through a cloud native registry to obtain current service information of MDS and/or current service information of FDS;

the current service information of the MDS and the current service information of the FDS are both pushed to the APIServer through the CSF control platform.

In a possible implementation manner, the service information of the MDS includes at least one of routing policy information, load policy information, and operation mode switching policy information;

the service information of the FDS includes at least one of service degradation policy information, service timeout policy information, and service fusing policy information.

In a possible implementation manner, determining a target service end currently corresponding to a target service according to service information currently corresponding to the target service includes:

based on routing strategy information, a routing address corresponding to a target service is obtained through a cloud native registry, wherein the routing address corresponds to a group of POD IPs;

based on the load strategy information, selecting a target POD IP from a group of POD IPs, and determining a server corresponding to the target POD IP as a target server currently corresponding to the target service.

In one possible implementation, the cloud native registry is a stateless registry that does not itself hold any data information and all the data information it needs originates from its own storage facility, etc d;

the cloud native registry provides services through a discovery service xDS protocol and provides a service discovery interface xDS API through a xDS server; xDS is located at the top of the cloud native registry architecture, which directly exposes the service governance capabilities of the cloud native registry to CSF clients.

According to an aspect of an embodiment of the present application, there is provided a service governance method applied to a cloud native registry, the method including:

when a CSF client initiates service calling of a target service through a service code, acquiring service information corresponding to the target service currently, wherein the service information comprises at least one item of service information of a micro service discovery service (MDS) or service information of a service interface discovery service (FDS);

and sending the service information to the CSF client, so that the CSF client determines a target service end corresponding to the target service currently according to the service information, and completes service management of the target service by calling the target service to the target service end based on the service information.

In a possible implementation manner, acquiring service information currently corresponding to a target service includes:

acquiring current service information of MDS and/or current service information of FDS by monitoring APIServer;

According to another aspect of the embodiments of the present application, there is provided a service administration device applied to a cloud service framework CSF client, the device including:

the first processing module is used for initiating service calling of the target service through the service code;

the second processing module is used for acquiring service information corresponding to the target service currently through the cloud native registry, wherein the service information comprises at least one of service information of a micro service discovery service (MDS) or service information of a service interface discovery service (FDS);

the third processing module is used for determining a target server side corresponding to the target service currently according to the service information;

and the fourth processing module is used for completing service management of the target service by calling the target service to the target service terminal based on the service information.

In a possible implementation manner, when the second processing module obtains service information currently corresponding to the target service through the cloud native registry, the second processing module is specifically configured to:

In a possible implementation manner, when determining a target service end currently corresponding to a target service according to service information currently corresponding to the target service, the third processing module is specifically configured to:

According to another aspect of the embodiments of the present application, there is provided a service administration device applied to a cloud native registry, the device including:

the acquisition module is used for acquiring service information corresponding to the target service currently when the CSF client initiates service calling of the target service through the service code, wherein the service information comprises at least one of service information of a micro service discovery service (MDS) or service information of a service interface discovery service (FDS);

and the sending module is used for sending the service information to the CSF client so that the CSF client determines a target service end corresponding to the target service currently according to the service information, and calling the target service through the target service end based on the service information so as to complete service management of the target service.

In a possible implementation manner, when acquiring the service information currently corresponding to the target service, the acquiring module is specifically configured to:

the cloud native registry provides services through a discovery service xDS protocol and provides a service discovery interface xDS API through a xDS server; xDS is located on the uppermost layer of the cloud native registry architecture, which directly exposes the service governance capabilities of the cloud native registry to CSF clients.

According to another aspect of an embodiment of the present application, there is provided an electronic apparatus including: the system comprises a memory, a processor and a computer program stored on the memory, wherein the processor executes the computer program to realize the steps of the service governance method.

According to still another aspect of the embodiments of the present application, there is provided a computer-readable storage medium, and a computer program is executed by a processor to implement the steps of the service administration method described above.

According to an aspect of an embodiment of the present application, there is provided a computer program product, which when executed by a processor implements the steps of the service administration method described above.

The technical scheme provided by the embodiment of the application has the following beneficial effects: MDS is realized based on the Pilot xDS protocol extension, so that micro-service-level service management can be realized, FDS is realized based on the Pilot xDS protocol extension, so that method-level service management can be realized, and the problem that the current cloud native registration center only supports monitoring of EDS, CDS and LDS but cannot be combined with micro-service and interface-level strategy information is solved; in addition, the server does not need to maintain long-chain connection with a cloud native registration center, and in a kubernets system, all instance information is stored in a native storage facility ETCD of a k8s system, so that the phenomenon that the server is disconnected easily under the condition of poor network or complex network is avoided.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings used in the description of the embodiments of the present application will be briefly described below.

FIG. 1 is a schematic flow chart of a service governance method according to an embodiment of the present disclosure;

FIG. 2 is a schematic view of an overall treatment process for service governance provided by an embodiment of the present application;

fig. 3 is a schematic diagram of an improvement on an existing cloud native registry according to an embodiment of the present application;

FIG. 4 is a schematic flow chart of a service governance method according to yet another embodiment of the present application;

FIG. 5 is a schematic structural diagram of a service administration device according to yet another embodiment of the present application;

FIG. 6 is a schematic flow diagram of a service administration apparatus according to another embodiment of the present application;

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

Detailed Description

Embodiments of the present application are described below in conjunction with the drawings in the present application. It should be understood that the embodiments set forth below in connection with the drawings are exemplary descriptions for explaining technical solutions of the embodiments of the present application, and do not limit the technical solutions of the embodiments of the present application.

As used herein, the singular forms "a", "an", "the" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should be further understood that the terms "comprises" and/or "comprising," when used in this specification in connection with embodiments of the present application, specify the presence of stated features, information, data, steps, operations, elements, and/or components, but do not preclude the presence or addition of other features, information, data, steps, operations, elements, components, and/or groups thereof, as embodied in the art. It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may be present. Further, "connected" or "coupled" as used herein may include wirelessly connected or wirelessly coupled. The term "and/or" as used herein indicates at least one of the items defined by the term, e.g., "a and/or B" indicates either an implementation as "a", or an implementation as "a and B".

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

Several terms that may be referred to in this application are introduced and explained below:

kubernetes: abbreviation K8s is an abbreviation resulting from 8 replacing the 8 characters "ubernet" in the middle of the name. The Kubernetes aims to make the application of container deployment simple and efficient (powerfull), provides a mechanism for application deployment, planning, updating and maintenance, and supports automatic deployment, large-scale scalable and application container management. When an application is deployed in a production environment, multiple instances of the application are typically deployed to load balance application requests. In kubernets, a plurality of containers can be created, each container runs an application instance, and then management, discovery and access of the group of application instances are realized through a built-in load balancing strategy, and the details do not need operation and maintenance personnel to perform complicated manual configuration and processing.

Micro-service: different units or functions of the system run different containers, and the number of containers served by each unit can be adjusted according to the load of the unit. For example, a large system includes functions of user login, item display, item interaction and the like, but various parts of the system are not simultaneously and linearly increased, some parts may be busy, and some parts may have surplus capacity.

Pod: an enhanced container. The Pod is the most basic deployment scheduling unit of the kubernets cluster, that is, the minimum unit for the micro-service application to run, and each Pod includes multiple containers, which can be regarded as an extension or enhanced container of a container. The Pod includes a main container and a plurality of auxiliary containers, which together perform a specific function. When multiple processes (containers are also an isolated process) are packed in a Name Space, a Pod is formed. The application wrappers for the different processes within the Pod remain separate (each container will have its own mirror image).

The significance of Pod is that it can maintain both the affinity of the primary and secondary containers and the independence of the primary container. Since the life cycle of the primary and secondary containers are the same and can be created and destroyed at the same time, placing them in a Pod makes their interaction more efficient. On the other hand, the main container needs to complete some main works, while other works may be common, and can be packed separately and operated by the auxiliary container.

Serving the grid: is a controller of communication between services, including microservices.

With the development and deployment of more and more container applications, an enterprise may have hundreds of thousands or tens of thousands of containers running, and how to manage communication between these containers or services, including load balancing between services, traffic management, routing, monitoring of operating conditions, security policies, and authentication between services, becomes a huge challenge for cloud native technologies. Service grids represented by Istio have been produced. Architecturally, the Istio belongs to an infrastructure layer of cloud native technology, and communication control among services is realized by providing a series of network agents beside a container. Each of which is a gateway that manages requests or interactions between each service in a container or container cluster. Each network proxy also intercepts and distributes service requests onto the service grid, and thus the myriad connections made up of numerous services are "woven" into a mesh, also known as a "grid". The central controller of the service grid, with the help of the kubernets container platform, controls and adjusts the functions of the network proxy through service policies, including collecting performance metrics of the service.

In a schematic diagram of a classical service network, there are various configuration rules and traffic governance policies in a Sidecar (Sidecar), which are called data plane, and discovery and issuing of the configuration rules are performed through a control plane, which mainly includes service components such as Pilot, Mixer, and sitadel. If the Envoy of the data plane is also regarded as an Agent, the Pilot is similar to a server Master in the traditional C/S architecture, and issues an instruction to control the client to complete the service function. Compared with the traditional micro service architecture, the Pilot at least covers the functions of management components such as a service registry and a Config Server.

The Pilot directly extracts data from the running platform and constructs and converts the data into the service discovery model of the Istio, so the Pilot only has a service discovery function and does not need to register the service. The abstract model decouples different implementations of Pilot and a bottom platform, and can support Kubernets, Consul and other platforms.

In addition to service discovery, a more important function of Pilot is to issue rules to the data plane, including traffic governance rules such as VirtualService, destination rule, Gateway, and service entry, and also including security rules such as authentication and authorization. Pilot is responsible for converting various rules into a format recognizable by Envoy, and sends Envoy through a standard xDS protocol to instruct Envoy to complete actions. On communication, Envoy subscribes to Pilot's configuration resources through the gRPC in a streaming manner.

As can be seen, Pilot is a core component of the traffic management of the otio control plane, manages and configures all Envoy agent instances deployed in the otio service grid, allows users to create traffic forwarding routing rules between Envoy agents, and configures fault recovery functions such as timeout, retry, and blowing. In addition, Pilot supports setting rules such as security (authentication, policy control), telemetry reporting and the like, maintains all service instance information in the grid, and enables each Envoy to know the instance information of the upstream service based on xDS service discovery.

In addition, the Pilot also provides a REST interface for Debug, so that an administrator can acquire the process cache state, configure the issuing state and perform complete configuration for a certain agent. Currently, many subcommands of the command line tool istioctl to obtain configuration and agent state all directly access this interface. In addition, the Pilot supports service discovery and traffic rule discovery based on a plurality of different bottom-layer platforms, the abstract aggregation layer provides a uniform interface to the outside by aggregating the services and configuration rules of different platforms, so that the Pilot discovery service (xDS) does not need to care about the difference of the bottom-layer platforms, and the purpose of decoupling xDS from the bottom-layer platforms is achieved.

Although the cloud native registry Pilot of the current Service grid has a series of functions and advantages as described above, in a specific implementation, the present inventors found that the cloud native registry Pilot of the current Service grid only supports monitoring of EDS (edge Discovery Service), CDS (Cluster Discovery Service), and LDS (Listener Discovery Service), which cannot be combined with policy information such as routing, load, degradation, fusing, timeout, and the like at the micro Service and interface level, and the current micro Service registry such as zokeeper, nacos, and the like is mostly a stateful registry. Under the condition of poor network or complex network, the condition of disconnection of a server side is easy to occur.

In view of the above situation, the present application provides a solution for service management, and the following describes several exemplary embodiments to explain technical solutions of embodiments of the present application and technical effects produced by the technical solutions of the present application. It should be noted that the following embodiments may be referred to, referred to or combined with each other, and the description of the same terms, similar features, similar implementation steps and the like in different embodiments is not repeated.

Fig. 1 is a schematic flow diagram of a service management method provided in an embodiment of the present application, and as shown in fig. 1, the method is applied to a CSF client, and includes: step S110, initiating service call of target service through service code; step S120, acquiring service information corresponding to the target service currently through a cloud native registry, wherein the service information comprises at least one of service information of a micro service discovery service (MDS) or service information of a service interface discovery service (FDS); step S130, determining a target server corresponding to the target service currently according to the service information; step S140, based on the service information, the service management of the target service is completed by calling the target service to the target service terminal.

The CSF client has its own calling mode, that is, initiates a service call through the service code, and in one example, the CSF client may initiate a service call of a target service to the service interface through the service code, for example, if a service call for FDS (Function Discovery service) is to be initiated, the CSF client may initiate a service call of FDS to the FDS service interface, or for example, if a service call for MDS (micro service Discovery service) is to be initiated, the CSF client may initiate a service call of FDS to the MDS service interface. The target service mentioned above may be any service that has a certain association with the FDS and/or MDS. It should be noted that the foregoing example is introduced only for the convenience of understanding service invocation, and the service invocation method in the embodiment of the present application is not limited to the case in the foregoing example, and the foregoing example cannot be taken as a limitation on implementation of the present application.

After the CSF client initiates a service call, service information currently corresponding to the target service may be obtained from CSF-xDS (i.e., the cloud native registry) through the service code, where the service information is the latest updated service information in the cloud native registry. The service information may be service information of the MDS, service information of the FDS, service information of the MDS and service information of the FDS, or other service information required for completing the service call besides the service information of the MDS and/or the service information of the FDS, for example, service information of the EDS, service information of the CDS, service information of the LDS, and the like, which is not limited in the embodiment of the present application.

After the CSF client acquires the required service information, it may determine, according to the service information, a target server corresponding to the target service currently, and then, based on the service information, complete service management of the target service by making a service call of the target service to the target server.

The method provided by the application realizes MDS based on the Pilot xDS protocol extension, so that micro-service-level service management can be realized, and also realizes FDS based on the Pilot xDS protocol extension, so that method-level service management can be realized, thereby solving the problem that the current cloud native registration center only supports monitoring of EDS, CDS and LDS, but cannot be combined with micro-service and strategy information of an interface level; in addition, the server does not need to maintain long-chain connection with a cloud native registration center, and in a kubernets system, all instance information is stored in a native storage facility ETCD of a k8s system, so that the phenomenon that the server is disconnected easily under the condition of poor network or complex network is avoided.

In a possible implementation manner of the embodiment of the present application, the obtaining, by the cloud native registry, service information currently corresponding to a target service may be: the method comprises the steps that APIServer is monitored through a cloud native registry to obtain current service information of MDS and/or current service information of FDS; the current service information of the MDS and the current service information of the FDS are both pushed to the APIServer through the CSF control platform.

The CSF control platform pushes the current service information of the MDS and/or the current service information of the FDS to the APIServer through the fabric8 java client, which is equivalent to issuing a configuration rule to the APIServer, and the service information is equivalent to the configuration rule. The APIServer receives the current service information of the MDS pushed by the CSF control platform, replaces the original service information of the MDS in the APIServer with the current service information of the MDS, and similarly, the APIServer receives the current service information of the FDS pushed by the CSF control platform, replaces the original service information of the FDS in the APIServer with the current service information of the FDS, namely the current service information of the MDS is the latest service information of the MDS in the APIServer, and the current service information of the FDS is the latest service information of the FDS in the APIServer.

The service information of the MDS may include at least one of routing policy information, load policy information, and operation mode switching policy information; the service information of the FDS may include at least one of service degradation policy information, service timeout policy information, and service fusing policy information. Equivalently, the CSF control platform pushes at least one of the routing strategy information, the load strategy information and the operation mode switching strategy information to the APIServer through the fabric8 java client; or the CSF control platform pushes at least one of the service degradation strategy information, the service overtime strategy information and the service fusing strategy information to the APIServer through the fabric8 java client; or, the CSF control platform pushes at least one of the routing policy information, the load policy information, and the operation mode switching policy information, and at least one of the service degradation policy information, the service timeout policy information, and the service fusing policy information to the APIServer through the fabric8 java client.

Similarly, the APIServer receives at least one of the routing policy information, the load policy information and the operation mode switching policy information pushed by the CSF control platform; or the APIServer receives at least one of service degradation strategy information, service overtime strategy information and service fusing strategy information pushed by the CSF control platform; or, the APIServer receives at least one of the routing policy information, the load policy information and the operation mode switching policy information pushed by the CSF control platform, and at least one of the service degradation policy information, the service timeout policy information and the service fusing policy information.

Wherein, the APIServer (the self is stateless service) is used for storing the resource data to the ETCD, and the subsequent business logic is executed by the copy controller and the dispatcher; the Kubernetes container management component runs a plurality of APIServer services simultaneously, and the high availability of an access layer is realized by forwarding the flow to different APIServers through the proxy. Master node services play the role of the Master control center. The Master node comprises an APIServer, a copy controller and a scheduler. When APIServer detects that the resource is changed, the APIServer actively informs a Controller manager (by using a block transmission code).

After the CSF control platform pushes the current service information of the MDS and/or the current service information of the FDS to the APIServer through the fabric8 java client, the cloud native registry monitors the APIServer to obtain the current service information of the MDS and/or the current service information of the FDS, that is, the CSF client monitors the APIServer through the cloud native registry to obtain the current service information of the MDS and/or the current service information of the FDS, in other words, the CSF client monitors the APIServer through the cloud native registry to dynamically obtain the changed service information of the MDS and the changed service information of the FDS in real time to obtain the latest service information. In one example, since the cloud native registry does not store any data itself, all data of the cloud native registry is derived from the K8s own storage facility, etc d, and the etc d is a highly available and strongly consistent key-value storage system, the cloud native registry can assemble the monitored current service information of the MDS and/or the current service information of the FDS in a key-value manner and store the assembled information into the storage facility, etc d.

The ETCD is a key-value storage system with high availability and strong consistency, and is mainly used for shared configuration and service discovery. The ETCD is specially designed for managing node states in a distributed system and service discovery and registration of a cluster environment, provides functions of data TTL invalidation, data change monitoring, multi-value, directory monitoring, distributed lock atom operation and the like, and can conveniently track and manage the states of cluster nodes. The ETCD enables services to be accessed into the computing cluster quickly and transparently, enables shared configuration information to be discovered by all machines in the cluster quickly, and can construct a set of service cluster which is high in availability, safe, easy to deploy and quick in response. The ETCD ensures strong consistency through a Raft consistency algorithm, solves the most common consistency problem in a distributed scene, provides a stable and high-availability message registration warehouse for service discovery, and provides infinite possibility for a framework working in cooperation with micro-services.

The implementation manner of the embodiment of the application realizes a service management manner of MDS based on routing strategy, load strategy and operation mode switching of micro service based on xDS protocol extension; and the service management of the FDS based on the method level is realized based on the xDS protocol extension.

In a possible implementation manner of the embodiment of the present application, the process of determining the target server currently corresponding to the target service according to the service information currently corresponding to the target service may be: based on routing strategy information, a routing address corresponding to a target service is obtained through a cloud native registry, wherein the routing address corresponds to a group of POD IPs; and then, based on the load strategy information, selecting a target POD IP from the group of POD IPs, and determining a service end corresponding to the target POD IP as a target service end corresponding to the target service currently.

The POD IP refers to an IP (Internet Protocol) address of the POD, that is, an IP address of the Docker container, and is a virtual IP address. The POD IP is an IP address of each POD, which is allocated by the Docker Engine according to the IP address field of the Docker bridge, and is usually a virtual two-layer network; generally, PODs under the same Service can communicate with each other directly according to POD IPs; PODs under different services have to communicate with PODs between clusters by means of Cluster IP (i.e. IP address of Service, which is virtual IP address); the POD and the outside of the cluster are communicated by means of Node IP (namely the IP address of the Node is the IP address of the physical network card).

The CSF client may obtain, based on the obtained routing policy information, a routing address corresponding to the target service through the cloud native registry, where one routing address corresponds to one cluster, and the cluster may be regarded as a set of POD IPs (i.e., a POD IP address list), and is equivalent to one routing address corresponding to one set of POD IPs (i.e., a POD IP address list). Equivalently, the CSF client acquires, through the cloud native registry, an accessible POD IP address list including at least one POD IP address (e.g., 1, 2, 3, or more) based on the acquired routing policy information. Usually, one POD IP corresponds to one server, so the above process is equivalent to acquiring one or more servers accessible through the cloud native registry. In practical application, a server corresponding to each POD IP in the acquired group of POD IPs may be regarded as a candidate server corresponding to the target service.

After the CSF client acquires the group of POD IPs, a designated POD IP may be selected from the group of POD IPs based on the load policy information acquired through the cloud native registry, where the designated POD IP is a target POD IP, and a server corresponding to the designated POD IP is a target server. The process is equivalent to selecting a target server from one or more candidate servers based on the load policy information acquired through the cloud native registry. Then, the CSF client completes service administration of the target service by making a service call of the target service to the target server based on the acquired service information.

In a possible implementation manner of the embodiment of the application, the cloud native registry is a stateless registry, which does not store any data information and all data information required by the cloud native registry is sourced from a storage facility, etc, of the kubernets; the cloud native registry provides services through a discovery service xDS protocol and provides a service discovery interface xDS API through a xDS server; xDS is located at the top of the cloud native registry architecture, which directly exposes the service governance capabilities of the cloud native registry to CSF clients.

For convenience of description, the cloud native registry in the embodiment of the present application may be referred to as CSF-Xds, and the CSF-Xds is a kubernets-based cloud native registry which manages and configures configuration information of all policies such as routing, loading, timeout, fusing, downgrading, mode switching, and the like of CSF services deployed in a k8s container, and Service, POD information, and the like.

The CSF-Xds in the embodiment of the present application is a stateless registry, which does not store any data, and all data of the CSF-Xds is derived from the K8s self-contained storage facility, etc., and POD IP data of the CSF-Xds is obtained based on api server monitoring, service data, load policy, degradation policy, timeout policy, fusing policy and the like of the CSF-Xds are obtained based on a custom CSF service resource monitored by the api server, routing policy information of the CSF-Xds is obtained based on a CSF routing resource monitored and obtained by the api server, and load policy of the CSF-Xds is obtained based on a CSF load resource monitored and obtained by the api server.

CSF-Xds provides services through xDS, xDS finds that the services are located at the uppermost layer of the CSF-Xds architecture, directly exposing the capacity of CSF-Xds service governance to clients. CSF-Xds provides a service discovery interface xDS API through xDS server, xDS server receives and maintains connectivity for CSF applications and distributes the corresponding xDS configuration based on the resource name to which the client subscribes.

A long connection of grpcs is maintained between CSF-Xds and CSF applications, and the distribution of all configurations is based on a Stream of this connection. The configuration is issued in an asynchronous manner, mainly based on changes of the underlying registry service or update events of configuration rules.

The method according to the embodiment of the present application is specifically described below by the overall process of service management according to the embodiment of the present application shown in fig. 2:

(1) the CSF control platform pushes the strategy to the APIServer, namely the CSF control platform pushes the strategy information such as self-defined resource service information, service routing information, service load information, service fusing information, service degradation information, service timeout information and the like to the APIServer through the fabric8 java client.

(2) The CSF-Xds listens to the MDS and/or FDS by listening to the APIServer, that is, the CSF-Xds listens to the K8S custom resource information FDS and/or MDS to obtain the current service information of the MDS and/or the current service information of the FDS, and the FDS and/or the MDS are located in the APIServer.

(3) The CSF-Xds assembles the monitored self-defined resource information, Service resource information, Pod resource information and the like according to a key-value mode.

(4) The CSF client listens to CSF-Xds via the GRPC protocol.

(5) The CSF client initiates a CSF service call through the service code, that is, the CSF client initiates a service call of the target service through the service code.

(6) The CSF client acquires corresponding service information, routing strategy information and the like from the cloud native registry CSF-Xds through the service code, namely the CSF client acquires the current corresponding service information of the target service through the cloud native registry CSF-xDS based on the service code, wherein the service information comprises at least one of service information of a micro service discovery service (MDS) or service information of a service interface discovery service (FDS); the service information of the MDS comprises at least one item of routing strategy information, load strategy information and operation mode switching strategy information; the service information of the FDS includes at least one of service degradation policy information, service timeout policy information, and service fusing policy information.

(7) The CSF client acquires an accessible POD IP address list (i.e., a set of POD IPs) including one or more POD IPs through the routing information, which is equivalent to the CSF client acquiring a routing address corresponding to the target service through the cloud native registry CSF-xDS based on the routing policy information, wherein the routing address corresponds to the set of POD IPs.

(8) The CSF client obtains the load policy configuration information through CSF-Xds, that is, the CSF client obtains the load policy information through cloud native registry CSF-xDS.

(9) The CSF client selects a specified POD IP from the group of POD IPs to perform service invocation through the load policy information, the service side corresponding to the specified POD IP is the target service side, and equivalently, the CSF client performs service invocation to the target service side to complete service administration.

Fig. 3 shows an improvement of the original cloud native registry according to the embodiment of the present application, where the original cloud native registry xDS API includes only LDA, CDS, EDS, etc., but does not include FDS, MDS (i.e., dotted filling part in the figure), and the embodiment of the present application extends based on the xDS protocol to implement FDS and MDS, so that the existing cloud native registry xDS API not only supports LDA, CDS, EDS, etc., but also supports FDS, MDS (i.e., dotted filling part in the figure).

The embodiment of the application is based on a cloud native architecture, a stateless retractable micro-service architecture registry is realized, and based on xDS, an FDS and an MDS are realized, wherein the FDS can realize method-level service management in a cloud native mode, micro-service routing information, a service load strategy, operation mode switching information and the like are recorded on the MDS, and in addition, based on xDS, a CSF (CSF service provider) self-owned operation mode and a grid mode dual-stack switching function can be realized.

Fig. 4 is a schematic flow chart of the service governance method provided in the embodiment of the present application, and as shown in fig. 4, the method is applied to a cloud native registry, and includes: step S410, when the CSF client initiates service calling of the target service through the service code, acquiring service information corresponding to the target service currently, wherein the service information comprises at least one item of service information of the MDS or service information of the FDS; step S420, sending the service information to the CSF client, so that the CSF client determines a target server corresponding to the target service currently according to the service information, and performs service invocation of the target service to the target server based on the service information, so as to complete service administration of the target service.

The method for treating the service at the cloud native registry side provided in the embodiment of the present application corresponds to the method for treating the service at the CSF client side provided in the embodiment of the present application, and therefore, it can be understood that the processing steps of the service treatment at the cloud native registry side correspond to the steps of the service treatment at the CSF client side, that is, the relevant contents of the steps of the service treatment at the CSF client side are also applicable to the processing steps of the service treatment at the cloud native registry side, and the steps of the service treatment at the cloud native registry side are not described herein again, wherein the specific description of the corresponding steps of the service treatment at the CSF client side can refer to the corresponding description in the foregoing text.

In a possible implementation manner of the embodiment of the present application, acquiring service information currently corresponding to a target service includes:

In a possible implementation manner of the embodiment of the present application, the service information of the MDS includes at least one of routing policy information, load policy information, and operation mode switching policy information;

In a possible implementation manner of the embodiment of the application, the cloud native registry is a stateless registry, which does not store any data information and all data information required by the cloud native registry is sourced from a storage facility, etc, of the kubernets;

According to the method, MDS is realized based on the Pilot xDS protocol extension, so that micro-service-level service management can be realized, FDS is realized based on the Pilot xDS protocol extension, so that method-level service management can be realized, and the problem that the conventional cloud native registration center only supports monitoring of EDS, CDS and LDS but cannot be combined with micro-service and strategy information of an interface level is solved; in addition, the service end does not need to maintain long-chain connection with a cloud native registration center, and in a kubernets system, all instance information is stored in a native storage facility ETCD of a k8s system, so that the condition that the service end is disconnected easily under the condition of poor network or complex network is avoided.

The embodiment of the present application provides a service administration device, where the device is applied to a cloud service framework CSF client, as shown in fig. 5, the device may include: a first processing module 501, a second processing module 502, a third processing module 503, and a fourth processing module 504, wherein,

a first processing module 501, configured to initiate a service call of a target service through a service code;

the second processing module 502 is configured to obtain service information currently corresponding to a target service through a cloud native registry, where the service information includes at least one of service information of a micro service discovery service MDS or service information of a service interface discovery service FDS;

a third processing module 503, configured to determine, according to the service information, a target server corresponding to the target service currently;

the fourth processing module 504 is configured to complete service administration of the target service by performing service invocation of the target service to the target service end based on the service information.

In a possible implementation manner, when the second processing module obtains service information currently corresponding to a target service through a cloud native registry, the second processing module is specifically configured to:

The device of the embodiment of the application realizes MDS based on the Pilot xDS protocol extension, so that micro-service-level service management can be realized, and also realizes FDS based on the Pilot xDS protocol extension, so that method-level service management can be realized, thereby solving the problem that the current cloud native registration center only supports monitoring of EDS, CDS and LDS, but cannot be combined with micro-service and strategy information of an interface level; in addition, the server does not need to maintain long-chain connection with a cloud native registration center, and in a kubernets system, all instance information is stored in a native storage facility ETCD of a k8s system, so that the phenomenon that the server is disconnected easily under the condition of poor network or complex network is avoided.

The service administration device of the embodiment of the present application can execute the service administration method shown in the above-mentioned CSF client side embodiment of the present application, and the implementation principle is similar, the actions executed by each module in the device of each embodiment of the present application correspond to the steps in the service administration method of each embodiment of the CSF client side of the present application, and for the detailed functional description of each module of the device, reference may be specifically made to the description in the corresponding method shown in the foregoing, and details are not repeated here.

The embodiment of the present application provides a service governance device, which is applied to a cloud native registry, as shown in fig. 6, the device 600 includes: an obtaining module 601 and a sending module 602, wherein,

an obtaining module 601, configured to obtain service information currently corresponding to a target service when a CSF client initiates service invocation of the target service through a service code, where the service information includes at least one of service information of a micro service discovery service MDS or service information of a service interface discovery service FDS;

a sending module 602, configured to send the service information to the CSF client, so that the CSF client determines a target server corresponding to the target service currently according to the service information, and performs service invocation of the target service to the target server based on the service information, to complete service administration of the target service.

The service administration device according to the embodiment of the present application may execute the service administration method according to the embodiment of the cloud native registry side described above, and the implementation principle is similar, the actions executed by the modules in the device according to the embodiments of the present application correspond to the steps in the method according to the embodiments of the cloud native registry side described above, and for the detailed functional description of the modules in the device, reference may be specifically made to the description in the corresponding method described above, and details are not repeated here.

The embodiment of the application provides an electronic device, which comprises a memory, a processor and a computer program stored on the memory, wherein the processor executes the computer program to realize the steps of the service governance method, and compared with the prior art, the method can realize the following steps: MDS is realized based on the Pilot xDS protocol extension, so that micro-service-level service management can be realized, FDS is realized based on the Pilot xDS protocol extension, so that method-level service management can be realized, and the problem that the current cloud native registration center only supports monitoring of EDS, CDS and LDS but cannot be combined with micro-service and interface-level policy information is solved; in addition, the server does not need to maintain long-chain connection with a cloud native registration center, and in a kubernets system, all instance information is stored in a native storage facility ETCD of a k8s system, so that the phenomenon that the server is disconnected easily under the condition of poor network or complex network is avoided.

In an alternative embodiment, an electronic device is provided, as shown in fig. 7, the electronic device 4000 shown in fig. 7 comprising: a processor 4001 and a memory 4003. Processor 4001 is coupled to memory 4003, such as via bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, and the transceiver 4004 may be used for data interaction between the electronic device and other electronic devices, such as transmission of data and/or reception of data. In addition, the transceiver 4004 is not limited to one in practical applications, and the structure of the electronic device 4000 is not limited to the embodiment of the present application.

The Processor 4001 may be a CPU (Central Processing Unit), a general-purpose Processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array) or other Programmable logic device, a transistor logic device, a hardware component, or any combination thereof. Which may implement or perform the various illustrative logical blocks, modules, and circuits described in connection with the disclosure. The processor 4001 may also be a combination that performs a computational function, including, for example, a combination of one or more microprocessors, a combination of a DSP and a microprocessor, or the like.

Bus 4002 may include a path that carries information between the aforementioned components. The bus 4002 may be a PCI (Peripheral Component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, or the like. The bus 4002 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in FIG. 7, but this is not intended to represent only one bus or type of bus.

The Memory 4003 may be a ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory) or other optical Disc storage, optical Disc storage (including Compact Disc, laser Disc, optical Disc, digital versatile Disc, blu-ray Disc, etc.), a magnetic Disc storage medium, other magnetic storage devices, or any other medium that can be used to carry or store a computer program and that can be Read by a computer, without limitation.

The memory 4003 is used for storing computer programs for executing the embodiments of the present application, and is controlled by the processor 4001 to execute. The processor 4001 is used to execute computer programs stored in the memory 4003 to implement the steps shown in the foregoing method embodiments.

The embodiments of the present application provide a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, can implement the steps of the foregoing method embodiments and corresponding content.

Embodiments of the present application further provide a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps and corresponding contents of the foregoing method embodiments can be implemented.

It should be understood that, although each operation step is indicated by an arrow in the flowchart of the embodiment of the present application, the implementation order of the steps is not limited to the order indicated by the arrow. In some implementation scenarios of the embodiments of the present application, the implementation steps in the flowcharts may be performed in other sequences as desired, unless explicitly stated otherwise herein. In addition, some or all of the steps in each flowchart may include multiple sub-steps or multiple stages based on an actual implementation scenario. Some or all of these sub-steps or stages may be performed at the same time, or each of these sub-steps or stages may be performed at different times, respectively. In a scenario where execution times are different, an execution sequence of the sub-steps or the phases may be flexibly configured according to requirements, which is not limited in the embodiment of the present application.

The foregoing is only an optional implementation manner of a part of implementation scenarios in this application, and it should be noted that, for those skilled in the art, other similar implementation means based on the technical idea of this application are also within the protection scope of the embodiments of this application without departing from the technical idea of this application.

Claims

1. A service governance method is applied to a Cloud Service Framework (CSF) client, and comprises the following steps:

initiating service call of the target service through the service code;

acquiring service information corresponding to the target service currently through the cloud native registry, wherein the service information comprises at least one of service information of a micro service discovery service (MDS) or service information of a service interface discovery service (FDS);

and based on the service information, completing service governance of the target service by calling the target service to the target service terminal.

2. The method according to claim 1, wherein the obtaining, by the cloud native registry, service information currently corresponding to the target service includes:

monitoring APIServer through the cloud native registry to acquire current service information of the MDS and/or current service information of the FDS;

and the current service information of the MDS and the current service information of the FDS are both pushed to the APIServer through a CSF control platform.

3. The method according to claim 1 or 2,

the service information of the MDS comprises at least one item of routing strategy information, load strategy information and operation mode switching strategy information;

the service information of the FDS comprises at least one of service degradation strategy information, service overtime strategy information and service fusing strategy information.

4. The method according to claim 3, wherein the determining the target server currently corresponding to the target service according to the service information currently corresponding to the target service comprises:

based on the routing policy information, acquiring a routing address corresponding to the target service through the cloud native registry, wherein the routing address corresponds to a group of PODIPs;

and selecting a target PODIP from the group of PODIPs based on the load strategy information, and determining a server corresponding to the target PODIP as a target server currently corresponding to the target service.

5. The method according to claim 1 or 2, characterized in that the cloud native registry is a stateless registry which does not itself hold any data information and all data information it needs originates from its own storage facility, ETCD;

the cloud native registry provides services through a discovery services xDS protocol and provides a service discovery interface xDS API through a xDS server; wherein the xDS is located on the uppermost layer of the cloud native registry architecture, which directly exposes the service governance capabilities of the cloud native registry to the CSF clients.

6. A service governance method is applied to a cloud native registry and comprises the following steps:

and sending the service information to the CSF client, so that the CSF client determines a target service end corresponding to the target service currently according to the service information, and calling the target service through the CSF client based on the service information so as to complete service management of the target service.

7. The method according to claim 6, wherein the obtaining the service information corresponding to the target service currently comprises:

acquiring the current service information of the MDS and/or the current service information of the FDS by monitoring APIServer;

8. The method according to claim 6 or 7,

9. The method according to claim 6 or 7, characterized in that the cloud native registry is a stateless registry which does not itself hold any data information and all data information it needs originates from its own storage facility ETCD;

10. The utility model provides a service is administered device, characterized in that is applied to cloud service framework CSF client, includes:

the third processing module is used for determining a target server corresponding to the target service currently according to the service information;

and the fourth processing module is used for completing the service management of the target service by calling the service of the target service to the target service terminal based on the service information.

11. The utility model provides a service governance device which characterized in that is applied to cloud primary registry, includes:

the acquisition module is used for acquiring current corresponding service information of a target service when a CSF client initiates service calling of the target service through a service code, wherein the service information comprises at least one of service information of a micro service discovery service (MDS) or service information of a service interface discovery service (FDS);

and the sending module is used for sending the service information to the CSF client so that the CSF client determines a target service end corresponding to the target service currently according to the service information, and calling the target service to the target service end based on the service information so as to complete service management of the target service.

12. An electronic device comprising a memory, a processor and a computer program stored on the memory, characterized in that the processor executes the computer program to implement the steps of the method of any of claims 1-5 or the processor executes the computer program to implement the steps of the method of any of claims 6-9.

13. A computer-readable storage medium, on which a computer program is stored, which computer program, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 5, or which computer program, when being executed by a processor, carries out the steps of the method of any one of claims 6 to 9.

14. A computer program product comprising a computer program, wherein the computer program when executed by a processor implements the steps of the method of any one of claims 1 to 5 or wherein the computer program when executed by a processor implements the steps of the method of any one of claims 6 to 9.