CN114615320B

CN114615320B - Service management method, device, electronic equipment and computer readable storage medium

Info

Publication number: CN114615320B
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: 2023-12-19
Anticipated expiration: 2042-03-11
Also published as: CN114615320A

Abstract

The embodiment of the application provides a service management method, a device, electronic equipment and a computer readable storage medium, and relates to the technical field of cloud protogenesis. The method is applied to the cloud service framework CSF client and comprises the following steps: initiating service call of the target service through service coding; next, obtaining service information corresponding to the target service currently through a cloud primary registration center, 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; then, based on the service information, service management of the target service is completed by performing service call of the target service to the target service terminal. The embodiment of the application not only expands MDS (micro-system management) capable of realizing service management of a micro-service level based on xDS protocol, but also expands FDS (FDS) capable of realizing service management of a method level.

Description

Service management method, device, electronic equipment and computer readable storage medium

Technical Field

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

Background

In recent years, cloud technology has rapidly developed and is 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 format in a container orchestration platform. Under the micro-service architecture, the industry generally manages the traffic among the micro-services through an Istio platform to ensure the safety of micro-service application, wherein the Istio platform is an open platform suitable for service management of cloud primary scenes.

Istio is currently the most widely known service grid architecture, one of the most common implementations of service grids, and provides a complete solution to meet the diversified needs of micro-service applications by providing behavioral insights and operational control for the entire service grid. Kubernetes is currently the only supported container organization framework for Istio, which is based on the cloud native of Kubernetes, and the managed service is all of the individual container instances running on top of the cloud native of Kubernetes. The micro-service of the existing operator core system is not thoroughly split according to the principle of micro-service, more or centralized, an application system composed of a plurality of services runs in each container instance, correspondingly, the micro-service hosted by the registry of the Kubernetes is specifically information of the application instance, and essentially belongs to an application level, service information of a service interface level and a micro-service level cannot be obtained, so that service management of the interface level and service management of the micro-service level cannot be realized.

Disclosure of Invention

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

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

initiating service call of the target service through service coding;

acquiring service information corresponding to a target service currently through a cloud primary 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 corresponding to the target service currently according to the service information;

based on the service information, the service management of the target service is completed by carrying out service call of the target service to the target service end.

In one possible implementation manner, obtaining, by the cloud native registry, service information currently corresponding to the target service includes:

monitoring APIServer through a cloud primary registration center to acquire current service information of MDS and/or current service information of FDS;

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

In one possible implementation, 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 one possible implementation manner, determining, according to service information currently corresponding to the target service, a target server currently corresponding to the target service includes:

based on the routing policy information, obtaining a routing address corresponding to the target service through the cloud primary registration center, wherein the routing address corresponds to a group of POD IPs;

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

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 comes from the Kubernetes' own storage facility ETCD;

The cloud native registry provides services through discovery service xDS protocol and provides service discovery interface xDS API through xDS server; among these, xDS is at the top level of the cloud-native registry architecture, which directly exposes the capabilities of the cloud-native registry for service administration to CSF clients.

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

when the CSF client initiates service call 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 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 completing the service management of the target service by carrying out service call of the target service to the target service end based on the service information.

In one possible implementation manner, obtaining service information currently corresponding to the target service includes:

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

According to another aspect of an embodiment of the present application, there is provided a service governance device applied to a clouding service framework CSF client, the device including:

the first processing module is used for initiating service call 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 primary registration center, wherein the service information comprises at least one of service information of the micro service discovery service MDS or service information of the service interface discovery service FDS;

the third processing module is used for determining a target service end 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 carrying out service call of the target service to the target service terminal based on the service information.

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

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

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

The acquisition module is used for acquiring service information currently corresponding to the target service when the CSF client initiates service call of the target service through the service code, wherein the service information comprises at least one of service information of the micro service discovery service MDS or service information of the 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 the target service end corresponding to the target service currently according to the service information and finishes the service treatment of the target service by carrying out service calling of the target service to the target service end based on the service information.

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

According to another aspect of the embodiments of the present application, there is provided an electronic device 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 management method.

According to yet another aspect of the embodiments of the present application, there is provided a computer readable storage medium, which when executed by a processor, implements the steps of the service governance method described above.

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

The beneficial effects that technical scheme that this application embodiment provided brought are: MDS is realized based on the Pilot xDS protocol extension, so that the service management of a micro service level can be realized, FDS is realized based on the Pilot xDS protocol extension, and the service management of a method level can be realized, thereby solving the problem that the current cloud native registry only supports monitoring of EDS, CDS and LDS and cannot be combined with policy information of a micro service and an interface layer; in addition, the server does not need to keep long links with the cloud primary registry, in the kubernetes system, all instance information is stored in a storage facility ETCD of the k8s system, and the condition that the server is easy to be disconnected 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 that are required to be used in the description of the embodiments of the present application will be briefly described below.

FIG. 1 is a flow chart of a method for service remediation according to one embodiment of the present disclosure;

FIG. 2 is a schematic diagram of an overall process of service remediation according to one embodiment of the present application;

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

FIG. 4 is a flow chart of a method for service remediation according to another embodiment of the present disclosure;

FIG. 5 is a schematic diagram of a service management device according to another embodiment of the present disclosure;

FIG. 6 is a schematic flow chart of a service management device according to another embodiment of the present disclosure;

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

Detailed Description

Embodiments of the present application are described below with reference to the drawings in the present application. It should be understood that the embodiments described below with reference to the drawings are exemplary descriptions for explaining the technical solutions of the embodiments of the present application, and the technical solutions of the embodiments of the present application are not limited.

As used herein, the singular forms "a", "an", "the" and "the" are intended to include the plural forms as well, unless expressly stated otherwise, as understood by those skilled in the art. It will be further understood that the terms "comprises" and "comprising," when used in this 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, all of which may be included in the present application. 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 implementation as "a", or as "a and B".

For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

Several terms which may be involved in this application are first introduced and explained:

kubernetes: abbreviated as K8s, is an abbreviation in which 8 replaces the 8 characters "ubernete" in the middle of the name. Is an open source for managing containerized applications on multiple hosts in a cloud platform, and the goal of Kubernetes is to make deploying containerized applications simple and efficient (powerful), and Kubernetes provides a mechanism for application deployment, planning, updating, and maintenance that supports automated deployment, large scale scalability, and application containerization management. When an application is deployed in a production environment, multiple instances of the application are typically deployed to load balance application requests. In Kubernetes, multiple containers may be created, one application instance running in each container, and then management, discovery, and access to the set of application instances is implemented through a built-in load balancing policy, where no complex manual configuration and processing by operation and maintenance personnel is required for these details.

Micro-services: it means that different units or functions of the system run different containers, the number of containers per service being adjustable according to their own load. For example, a large system includes user login, goods display, goods interaction, etc., but parts of the system are not linearly increased at the same time, some parts may be busy, and some parts may have spare capacity.

Pod: an enhanced container. Pod is the most basic deployment schedule element of the Kubernetes cluster, i.e., the smallest element that a microservice application runs, and each Pod includes multiple containers, which can be considered as an extension or enhancement of a container. The Pod includes a main container and a plurality of auxiliary containers which together perform a specific function. A Pod is formed when multiple processes (containers are also an isolated process) are packed in a Name Space. The application packages of the different processes within the Pod are still independent (each container will have its own mirror image).

The meaning of Pod is that it can maintain both the affinity of the primary container and the secondary container and the independence of the primary container. Since the lifecycle of the primary and secondary containers are the same, they can be created and destroyed simultaneously, placing them in one Pod can make their interactions more efficient. On the other hand, the primary container needs to perform some primary tasks, while other tasks may be common and may be individually packaged for operation by the secondary container.

Service grid: is the controller for communication between services, including micro-services.

With the development and deployment of more and more container applications, an enterprise may have hundreds or thousands of containers running, how to manage communications between these containers or services, including inter-service load balancing, traffic management, routing, operation condition monitoring, security policies, and inter-service authentication, becomes a great challenge for cloud-based technology. A service grid represented by Istio has been developed. Architecturally, istio belongs to the infrastructure layer of cloud-native technology, and communication control between services is achieved by providing a series of network agents at the container side. Each of which is a gateway that manages requests or interactions between each service in a container or cluster of containers. Each network proxy also intercepts service requests and distributes them to the service grid, so that numerous connections made by numerous services are "woven" into a network, also having the concept of a "grid". The central controller of the service grid, with the help of the Kubernetes container platform, controls and adjusts the functions of the network proxy, including collecting performance metrics of the service, through the service policies.

In the classical service network schematic diagram, there are various configuration rules and flow management policies in the side car (Sidecar), which are called data plane, and the discovery and issuing of the configuration rules are performed by the control plane, which mainly includes service components such as Pilot, mixer, citadel. If Envoy of the data plane is also regarded as an Agent, pilot is similar to a service end Master in a traditional C/S architecture, and issues a command to control a client to complete a service function. In contrast to the traditional micro-service architecture, pilot at least covers the functions of the service registry and the management components such as the Config Server.

The Pilot directly extracts data from the operation platform and constructs and converts the data into a service discovery model of Istio, so that the Pilot has only a service discovery function and does not need to register services. The abstract model decouples different implementations of Pilot and underlying platforms and can support Kubernetes, consul and other platforms.

In addition to service discovery, one of the more important functions of Pilot is to issue rules to the data plane, including traffic management rules such as virtual service, destination rule, gateway, service entry, and security rules such as authentication and authorization. The Pilot is responsible for converting various rules into formats recognizable by Envoy, sending the rules to Envoy through standard xDS protocol, and guiding Envoy to complete actions. In communication, envoy subscribes to Pilot's configuration resources through gRPC streaming.

As can be seen, pilot is a core component of Istio control plane traffic management, managing and configuring all Envoy agent instances deployed in the Istio service grid, allowing users to create traffic forwarding routing rules between Envoy agents, and configuring failure recovery functions such as timeout, retry, and blow. In addition, pilot supports setting rules such as security (authentication, policy control), telemetry and reporting, maintains all service instance information in the grid, and allows 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, which can be used for an administrator to obtain the process cache state, the configuration issuing state and complete configuration for a certain agent. Currently, many subcommands of the command line tool istioctl get configuration and proxy state directly access this interface. In addition, the Pilot support performs service discovery and traffic rule discovery based on a plurality of different bottom platforms, and the abstract aggregation layer provides a uniform interface to the outside by aggregating services and configuration rules of the different platforms, so that the Pilot discovery service (xDS) does not need to care about the difference of the bottom platforms, and the aim of decoupling xDS and the bottom platforms is fulfilled.

Although the current service grid cloud native registry Pilot has a series of functions and advantages as described above, in a specific implementation, the inventor discovers that the existing service grid cloud native registry Pilot only supports EDS (Endpoint Discovery Service, cluster member discovery service), CDS (Cluster Discovery Service ), and LDS (Listener Discovery Service, listening discovery service) cannot be combined with policy information such as routing, loading, degradation, fusing, timeout and the like of the micro service and interface layers, and most of current micro service registries, such as zookeeper, nacos and the like, need to register with the registry when in use, and need to maintain long links with the registry and health checking mechanisms. In the case of poor network or complex network, the condition that the service end is disconnected easily occurs.

In view of the foregoing, the present application proposes a solution for service governance, and description will be made below of several exemplary 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, or combined with each other, and the description will not be repeated for the same terms, similar features, similar implementation steps, and the like in different embodiments.

Fig. 1 is a flow chart of a service administration method according to an embodiment of the present application, as shown in fig. 1, where the method is applied to a CSF client, and includes: step S110, initiating service call of the target service through service coding; step S120, obtaining service information corresponding to a target service currently through a cloud primary registration center, 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, completing the service governance of the target service by performing the service invocation of the target service to the target service end.

The CSF client has its own call mode, that is, initiates a service call through a service code, in one example, the CSF client may initiate a service call of a target service to a service interface through the service code, for example, if a service call for FDS (Function Discovery Sevice, service interface discovery service) is to be initiated, a service call of FDS may be initiated to the FDS service interface, and for example, if a service call for MDS (MicroService Discovery Sevice, micro service discovery service) is to be initiated, a service call of FDS may be initiated to the MDS service interface. The target service may be any service that has a certain association with the FDS and/or MDS. It should be noted that the foregoing examples are merely introduced for the sake of understanding service invocation, and the service invocation method in the embodiments of the present application is not limited to the case of the foregoing examples, and the foregoing examples should not be taken as limiting the implementation of the present application.

After the CSF client initiates the service invocation, service information currently corresponding to the target service can be acquired from the CSF-xDS (i.e., the cloud native registry) through a service code, wherein the service information is the service information updated recently in the cloud native registry. The service information may be service information of the MDS, or may be service information of the FDS, or may be service information of the MDS and service information of the FDS, or may be other service information required for completing the service call except for the service information of the MDS and/or the service information of the FDS, such as service information of the EDS, service information of the CDS, service information of the LDS, and the like.

After acquiring the required service information, the CSF client can determine, according to the service information, a target service end corresponding to the target service currently, and then based on the service information, complete service management of the target service by performing service call of the target service to the target service end.

According to the method, MDS is realized based on the Pilot xDS protocol extension, so that service management of a micro service level can be realized, FDS is realized based on the Pilot xDS protocol extension, and service management of a method level can be realized, so that the problem that the current cloud native registry only supports monitoring of EDS, CDS and LDS and cannot be combined with policy information of a micro service and an interface level is solved; in addition, the server does not need to keep long links with the cloud primary registry, in the kubernetes system, all instance information is stored in a storage facility ETCD of the k8s system, and the condition that the server is easy to be disconnected 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, the service information currently corresponding to the target service may be: monitoring APIServer through a cloud primary registration center to acquire current service information of MDS and/or current service information of FDS; the MDS current service information and the FDS current service information are pushed to the APIServer through the CSF control platform.

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

Wherein 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 fuse policy information. Equivalently, the CSF control platform pushes at least one of routing policy information, load policy information and operation mode switching policy information to the APIServer through a fabric8 java client; or, the CSF control platform pushes at least one of service degradation policy information, service timeout policy information and service fusing policy information to the APIServer through the fabric8 java client; or pushing at least one of routing policy information, load policy information and operation mode switching policy information and at least one of service degradation policy information, service timeout policy information and service fusing policy information to an APIServer by the CSF control platform through the fabric8 java client.

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

Wherein, APIServer (itself a stateless service) is used to store resource data to ETCD, and subsequent business logic is executed by replica controller and scheduler; the Kubernetes container management component runs a plurality of APIServer services simultaneously, and forwards traffic to different apiservers through agents to realize high availability of an access layer. Master node services play the role of a central control center. The Master node includes an APIServer, a replica controller, and a scheduler. When APIServer detects a change in resource, it is actively notified to Controller manager (using block transfer coding).

After pushing MDS current service information and/or FDS current service information to an APIServer through a fabric8 java client, a cloud primary registry monitors the APIServer to acquire the MDS current service information and/or the FDS current service information, namely, the CSF client monitors the APIServer through the cloud primary registry to acquire the MDS current service information and/or the FDS current service information, in other words, the CSF client monitors the APIServer through the cloud primary registry to dynamically acquire the changed MDS service information and the changed FDS service information in real time to acquire the latest service information. In one example, since the cloud native registry itself does not store any data, all of which originate from the K8s on-board storage facility ETCD, and ETCD is a highly available, strongly consistent key-value storage system, the cloud native registry may assemble the monitored MDS current service information and/or FDS current service information in a key-value manner and store it in the storage facility ETCD.

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, and provides functions of data TTL invalidation, data change monitoring, multi-value, catalog monitoring, distributed lock atom operation and the like, so that the states of the cluster nodes can be conveniently tracked and managed. The ETCD enables the service to be quickly and transparently accessed into the computing cluster, enables the shared configuration information to be quickly found by all machines in the cluster, and can be used for constructing a set of service clusters which are high in availability, safe, easy to deploy and quick in response. The ETCD ensures strong consistency through a shift 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 architecture working cooperatively with micro services.

According to the implementation mode of the embodiment of the application, the routing strategy, the load strategy and the service management mode of operation mode switching of MDS based on micro-service are realized based on xDS protocol expansion; the service management of the FDS based on the method level is realized based on xDS protocol extension.

In one possible implementation manner of the embodiment of the present application, the process of determining, according to the service information currently corresponding to the target service, the target server currently corresponding to the target service may be: based on the routing policy information, obtaining a routing address corresponding to the target service through the cloud primary registration center, wherein the routing address corresponds to a group of POD IPs; then, a target POD IP is selected from the group of POD IPs based on the load strategy information, and a service end corresponding to the target POD IP is determined as a target service end corresponding to the target service currently.

Here, POD IP refers to an IP (Internet Protocol ) address of the POD, i.e., an IP address of the Docker container, which is a virtual IP address. POD IP is an IP address of each POD, which is allocated by a Docker Engine according to an IP address field of a Docker bridge, and is typically a virtual two-layer network; in general, PODs under the same Service can directly communicate with each other according to POD IP; PODs under different services POD communication among clusters is realized by means of Cluster IP (i.e. the IP address of Service, which is a virtual IP address); the POD and the communication outside the cluster are to use Node IP (i.e. the IP address of the Node is the IP address of the physical network card).

The CSF client can obtain, through the cloud primary registry, a routing address corresponding to the target service based on the obtained routing policy information, where one routing address corresponds to one cluster, and the cluster can be considered as a set of POD IPs (i.e., a POD IP address list), which corresponds to one routing address corresponding to one set of POD IPs (i.e., a POD IP address list). Equivalently, the CSF client obtains an accessible POD IP address list including at least one POD IP address (such as 1, 2, 3 or more) through the cloud primary registry based on the obtained routing policy information. Typically, one POD IP corresponds to one server, so the above procedure corresponds to obtaining one or more servers accessible through the cloud native registry. In practical application, the service end corresponding to each POD IP in the acquired set of POD IPs may be regarded as a candidate service end corresponding to the target service.

After acquiring a group of POD IPs, the CSF client may select a designated POD IP from the group of POD IPs based on the load policy information acquired through the cloud primary 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 above process corresponds to selecting the target server from one or more candidate servers based on the load policy information acquired through the cloud primary registry. Then, the CSF client completes the service administration of the target service by performing service invocation of the target service to the target service based on the acquired service information.

In one possible implementation manner of the embodiment of the present application, the cloud native registry is a stateless registry, which does not store any data information itself, and all the data information required by the cloud native registry is derived from a Kubernetes self-contained storage facility ETCD; the cloud native registry provides services through discovery service xDS protocol and provides service discovery interface xDS API through xDS server; among these, xDS is at the top level of the cloud-native registry architecture, which directly exposes the capabilities of the cloud-native registry for service administration to CSF clients.

For ease of description, the cloud native registry in embodiments of the present application may be referred to as CSF-Xds, which is a cloud native registry of CSF based on kubernetes that manages and configures configuration information for all routing, loading, timeout, fusing, downgrade, mode switching, etc. policies of CSF services deployed in k8s containers, as well as Service, POD information, etc.

In the embodiment of the application, the CSF-Xds is a stateless registry, does not store any data, all data of the CSF-Xds are derived from a K8s self-contained storage facility ETCD, POD IP data of the CSF-Xds is obtained based on POD information obtained by APIServer monitoring, service data, load policy, degradation policy, timeout policy, fusing policy and the like of the CSF-Xds are obtained based on customized CSF service resources obtained by APIServer monitoring, routing policy information of the CSF-Xds is obtained based on CSF routing resources obtained by APIServer monitoring, and load policy of the CSF-Xds is obtained based on CSF load resources obtained by APIServer monitoring.

CSF-Xds provides services through xDS, xDS finds the services at the top layer of CSF-Xds architecture, exposing the capabilities of CSF-Xds service administration directly to clients. CSF-Xds provides a service discovery interface xDS API through xDS servers, and xDS servers receive and maintain connections for CSF applications and distribute corresponding xDS configurations based on resource names subscribed to by clients.

A long gppc connection is maintained between CSF-Xds and CSF applications, and distribution of all configurations is based on one Stream of this connection. The configuration is issued in an asynchronous manner, and is mainly based on the change of the underlying registry service or the update event of the configuration rule.

The method of the embodiment of the present application is specifically described below through the overall processing procedure of service governance of the embodiment of the present application shown in fig. 2:

(1) The CSF control platform performs policy pushing to the APIServer, namely, the CSF control platform pushes policy information such as user-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 a fabric8 java client.

(2) CSF-Xds monitors MDS and/or FDS by monitoring APIServer, that is, CSF-Xds monitors K8S custom resource information FDS and/or MDS to obtain current service information of MDS and/or current service information of FDS, where FDS and/or MDS is located in APIServer.

(3) CSF-Xds assembles the monitored custom resource information, service resource information, pod resource information, etc. in a key-value manner.

(4) CSF clients listen to CSF-Xds via the GRPC protocol.

(5) The CSF client initiates CSF service invocation through the service code, i.e., the CSF client initiates service invocation of the target service through the service code.

(6) The CSF client obtains corresponding service information, routing strategy information and the like from the cloud primary registration center CSF-Xds through the service code, namely the CSF client obtains the service information currently corresponding to the target service through the cloud primary registration center CSF-xDS based on the service code, wherein the service information comprises at least one of the service information of the micro service discovery service MDS or the service information of the service interface discovery service FDS; the service information of the MDS comprises at least one 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 obtains an accessible POD IP address list (i.e., a set of POD IPs) through the routing information, where the POD IP address list includes one or more POD IPs, and is equivalent to obtaining, by the CSF client, a routing address corresponding to the target service through the cloud primary registry CSF-xDS based on the routing policy information, where the routing address corresponds to the set of POD IPs.

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

(9) The CSF client selects a designated POD IP from the group of POD IPs to perform service call through the load policy information, and the service end corresponding to the designated POD IP is the target service end, which is equivalent to the CSF client performing service call to the target service end to complete service management.

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

According to the embodiment of the invention, a stateless telescopic micro-service architecture registry is realized based on a cloud primary architecture, and FDS and MDS are realized based on xDS, wherein the FDS can realize service management of a method level in a cloud primary mode, micro-service routing information, a service load strategy, operation mode switching information and the like are recorded on the MDS, and furthermore, a CSF (packet switched service) self-operation mode and grid mode dual-stack switching function can be realized based on the xDS registry.

Fig. 4 is a flow chart of a service governance method provided in an embodiment of the present application, as shown in fig. 4, where the method is applied to a cloud native registry, and includes: step S410, when the CSF client initiates service call 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 of service information of the micro service discovery service MDS or service information of the service interface discovery service FDS; step S420, the service information is sent 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 service management of the target service is completed by performing service call of the target service to the target service end based on the service information.

The service governance method at the cloud native registry side provided in the embodiment of the present application corresponds to the service governance method at the CSF client side provided in the embodiment of the present application, so it can be understood that the processing steps of the service governance at the cloud native registry side correspond to the steps of the service governance at the CSF client side, that is, the relevant content of the steps of the service governance at the CSF client side is also adapted to the processing steps of the service governance at the cloud native registry side, and detailed descriptions of the steps of the service governance at the cloud native registry side are not repeated herein, wherein specific descriptions of the corresponding steps of the service governance at the CSF client side can be referred to the corresponding descriptions in the foregoing.

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

In one possible implementation manner of the embodiments 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 one possible implementation manner of the embodiment of the present application, the cloud native registry is a stateless registry, which does not store any data information itself, and all the data information required by the cloud native registry is derived from a Kubernetes self-contained storage facility ETCD;

According to the method, MDS is realized based on the Pilot xDS protocol extension, so that service management of a micro service level can be realized, FDS is realized based on the Pilot xDS protocol extension, service management of a method level can be realized, and the problem that the current cloud native registry only supports monitoring of EDS, CDS and LDS and cannot be combined with policy information of a micro service and an interface level is solved; in addition, the server does not need to keep long links with the cloud primary registry, in the kubernetes system, all instance information is stored in a storage facility ETCD of the k8s system, and the condition that the server is easy to be disconnected under the condition of poor network or complex network is avoided.

The embodiment of the application provides a service management device, which is applied to a CSF client of a clouding service framework, as shown in fig. 5, and 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, through the cloud native registry, service information currently corresponding to the target service, where the service information includes at least one of service information of the micro service discovery service MDS or service information of the service interface discovery service FDS;

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

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

The device realizes MDS based on the Pilot xDS protocol extension, so that the service management of a micro service level can be realized, and FDS based on the Pilot xDS protocol extension can realize the service management of a method level, thereby solving the problem that the current cloud native registry only supports monitoring of EDS, CDS and LDS and cannot be combined with the policy information of a micro service and an interface layer; in addition, the server does not need to keep long links with the cloud primary registry, in the kubernetes system, all instance information is stored in a storage facility ETCD of the k8s system, and the condition that the server is easy to be disconnected under the condition of poor network or complex network is avoided.

The service administration device of the embodiment of the present application may execute the service administration method shown in the embodiment of the CSF client side of the present application, and its implementation principle is similar, and the actions executed by the modules 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 details of the functions of each module of the device, reference may be specifically made to the description in the corresponding method shown in the foregoing, and will not be repeated herein.

The embodiment of the application provides a service management device, which is applied to a cloud native registry, as shown in fig. 6, the device 600 comprises: an acquisition module 601, and a transmission module 602, wherein,

the acquiring module 601 is configured to acquire service information currently corresponding to a target service when the 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;

the sending module 602 is configured to send the service information to the CSF client, so that the CSF client determines a target service end currently corresponding to the target service according to the service information, and completes service administration of the target service by performing service invocation of the target service to the target service end based on the service information.

The service governance device of the embodiment of the present application may execute the service governance method shown in the foregoing cloud native registry side embodiment of the present application, and its implementation principle is similar, and actions executed by each module in the device of each embodiment of the present application correspond to steps in the method of each embodiment of the cloud native registry side of the present application, and detailed functional descriptions of each module of the device may be referred to in the foregoing description of the corresponding method, which is not repeated herein.

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 a method for service management, 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 the service management of a micro service level can be realized, FDS is realized based on the Pilot xDS protocol extension, and the service management of a method level can be realized, thereby solving the problem that the current cloud native registry only supports monitoring of EDS, CDS and LDS and cannot be combined with policy information of a micro service and an interface layer; in addition, the server does not need to keep long links with the cloud primary registry, in the kubernetes system, all instance information is stored in a storage facility ETCD of the k8s system, and the condition that the server is easy to be disconnected 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 includes: a processor 4001 and a memory 4003. Wherein the processor 4001 is coupled to the memory 4003, such as via a bus 4002. Optionally, the electronic device 4000 may further comprise a transceiver 4004, 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, etc. It should be noted that, in practical applications, the transceiver 4004 is not limited to one, 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 ), general purpose processor, DSP (Digital Signal Processor, data signal processor), ASIC (Application Specific Integrated Circuit ), FPGA (Field Programmable Gate Array, field programmable gate array) or other programmable logic device, transistor logic device, hardware components, or any combination thereof. Which may implement or perform the various exemplary logic blocks, modules, and circuits described in connection with this disclosure. The processor 4001 may also be a combination that implements computing functionality, e.g., comprising one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

Bus 4002 may include a path to transfer information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect, peripheral component interconnect standard) bus or an EISA (Extended Industry Standard Architecture ) bus, or the like. The bus 4002 can 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 not only one bus or one type of bus.

Memory 4003 may be, but is not limited to, ROM (Read Only Memory) or other type of static storage device that can store static information and instructions, RAM (Random Access Memory ) or other type of dynamic storage device that can store information and instructions, EEPROM (Electrically Erasable Programmable Read Only Memory ), CD-ROM (Compact Disc Read Only Memory, compact disc Read Only Memory) or other optical disk storage, optical disk storage (including compact discs, laser discs, optical discs, digital versatile discs, blu-ray discs, etc.), magnetic disk storage media, 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.

The memory 4003 is used for storing a computer program that executes an embodiment of the present application, and is controlled to be executed by the processor 4001. The processor 4001 is configured to execute a computer program stored in the memory 4003 to realize the steps shown in the foregoing method embodiment.

Embodiments of the present application provide a computer readable storage medium having a computer program stored thereon, where the computer program, when executed by a processor, may implement the steps and corresponding content of the foregoing method embodiments.

The embodiments of the present application also provide a computer program product, which includes a computer program, where the computer program can implement the steps of the foregoing method embodiments and corresponding content when executed by a processor.

It should be understood that, although the flowcharts of the embodiments of the present application indicate the respective operation steps by arrows, the order of implementation of these steps is not limited to the order indicated by the arrows. In some implementations of embodiments of the present application, the implementation steps in the flowcharts may be performed in other orders as desired, unless explicitly stated herein. Furthermore, some or all of the steps in the flowcharts may include multiple sub-steps or multiple stages based on the actual implementation scenario. Some or all of these sub-steps or phases may be performed at the same time, or each of these sub-steps or phases may be performed at different times, respectively. In the case of different execution time, the execution sequence of the sub-steps or stages may be flexibly configured according to the requirement, which is not limited in the embodiment of the present application.

The foregoing is merely an optional implementation manner of the implementation scenario of the application, and it should be noted that, for those skilled in the art, other similar implementation manners based on the technical ideas of the application are adopted without departing from the technical ideas of the application, and also belong to the protection scope of the embodiments of the application.

Claims

1. A service governance method, applied to a clouding service framework CSF client, comprising:

initiating service call of the target service through service coding;

acquiring service information currently corresponding to the target service through the cloud primary registration center, 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 service end corresponding to the target service currently according to the service information;

based on the service information, completing service management of the target service by performing service call of the target service to the target service end;

the cloud native registry is a stateless registry, does not store any data information, and all data information required by the cloud native registry is derived from a storage facility ETCD of the cloud native registry; the cloud primary registry may assemble the monitored MDS current service information and/or FDS current service information in a key-value manner, and store the information in the storage facility ETCD.

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

Monitoring APIServer through the cloud primary registration center to acquire current service information of the MDS and/or current service information of the FDS;

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

3. A method according to claim 1 or 2, characterized in that,

the service information of the MDS comprises at least one 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 policy information, service timeout policy information and service fusing policy information.

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

based on the routing policy information, obtaining a routing address corresponding to the target service through the cloud primary 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 service end corresponding to the target POD IP as a target service end currently corresponding to the target service.

5. A method according to claim 1 or 2, characterized in that,

the cloud native registry provides services through a discovery service xDS protocol and provides a service discovery interface xDS API through a xDS server; wherein the xDS is at the top level of the cloud native registry architecture, which directly exposes the capabilities of the cloud native registry for service administration to the CSF client.

6. The service governance method is characterized by being applied to a cloud native registry and comprising the following steps of:

when a CSF client initiates service call of a target service through a service code, acquiring service information currently corresponding to the target service, 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);

sending the service information to the CSF client to enable the CSF client to determine a target service end corresponding to the target service currently according to the service information, and completing service management of the target service by carrying out service call of the target service to the target service end based on the service information;

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

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

8. The method according to claim 6 or 7, wherein,

9. The method according to claim 6 or 7, wherein,

10. A service administration device, applied to a clouding service framework CSF client, comprising:

the second processing module is used for acquiring service information corresponding to the target service currently through the cloud primary 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 corresponding to the target service currently according to the service information;

the fourth processing module is used for completing service management of the target service by carrying out service call of the target service to the target service end based on the service information;

11. A service administration device, characterized in that it is applied to a cloud native registry, comprising:

a sending module, configured to send the service information to the CSF client, so that the CSF client determines, according to the service information, a target service end currently corresponding to the target service, and performs service invocation of the target service to the target service end based on the service information, so as to complete service administration 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 one of claims 1-5 or the processor executes the computer program to implement the steps of the method of any one of claims 6-9.

13. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program when executed by a processor implements the steps of the method according to any of claims 1-5 or the computer program when executed by a processor implements the steps of the method according to any of claims 6-9.