CN115378993B

CN115378993B - Method and system for supporting namespace-aware service registration and discovery

Info

Publication number: CN115378993B
Application number: CN202210895215.9A
Authority: CN
Inventors: 梅强; 刘齐均; 张红兵; 郭峰
Original assignee: Shanghai Daoke Network Technology Co ltd
Current assignee: Shanghai Daoke Network Technology Co ltd
Priority date: 2022-07-26
Filing date: 2022-07-26
Publication date: 2023-07-21
Anticipated expiration: 2042-07-26
Also published as: CN115378993A

Abstract

The invention relates to a method and a system for supporting service registration and discovery of name space perception, which are characterized in that when registering a service, service identification information of the service to be registered is generated by using characteristic information of the service to be registered, the service to be registered is registered to a service registration center by using the service identification information of the service to be registered, and meanwhile, the service identification information of the service to be registered and a virtual service address are stored in a form of triplet data; when the service is found, the feature information of the service to be called is used for obtaining the triplet data corresponding to the service to be called from the preset storage area, and the virtual service address in the triplet data is used for replacing the IP address of the container group where the service is located in the registration data as the access address of the service to be called. Therefore, when the traditional micro service is migrated to the container cloud platform, the code logic structure of service registration and service discovery is not required to be changed, the complexity of migrating the traditional micro service to the container cloud platform is effectively reduced, and smooth migration of a service system is realized.

Description

Method and system for supporting namespace-aware service registration and discovery

Technical Field

The present invention relates to the field of computers, and in particular, to a method and system for supporting namespace-aware service registration and discovery.

Background

In the evolution process of the service system of the micro-service architecture, the service system of the traditional micro-service architecture usually operates in a virtual machine or a bare metal server, and the bottom layer resource management of different virtual machines or bare metal servers is relatively independent, so that uniform scheduling, deployment and arrangement of the bottom layer resources cannot be performed, and the flexible scheduling of the bottom layer resources cannot be realized.

With the rapid development of cloud native technology, more and more enterprises choose to migrate the business system of the traditional micro-service architecture to the container cloud platform, and especially with the popularization of container arrangement technology represented by Kubernetes and service grid technology represented by Istio, the container cloud platform is more suitable for the deployment and operation of the business system of the micro-service architecture.

When an enterprise migrates a service system of a traditional micro-service architecture to a container cloud platform, due to certain technical architecture difference between the traditional micro-service architecture and a service grid architecture, certain suitability development and transformation are required for the migration of the service system, so that the migration difficulty of the service system is high and the workload is high.

Therefore, a technical solution for smoothly migrating the business system of the conventional micro-service architecture to the container cloud platform is needed.

Disclosure of Invention

In view of the above-mentioned drawbacks of the prior art, the method and system for supporting namespace-aware service registration and discovery provided by the embodiment of the present application implement smooth migration by improving a key technology for implementing migration of a conventional micro-service technology architecture to a service grid architecture, so that a service system of a conventional micro-service architecture is smoothly migrated to the service grid system without requiring a code logic structure for service registration and service discovery of the service system, and a service registry continues to maintain an original operation logic.

In a first aspect, an embodiment of the present application provides a service registration method supporting namespace awareness based on a service grid, where the method operates in a container cloud platform, and a service to be registered is deployed in a first container group in the container cloud platform, and the method includes the following steps:

responding to a first service registration request sent by the first container group, and analyzing the first service registration request;

Responding to the first service registration request containing the characteristic information of the service to be registered, and generating service identification information of the service to be registered by using the characteristic information of the service to be registered; the service identification information of the service to be registered is used for identifying the service to be registered, and the service identification information of the service to be registered contains the naming space information of the service to be registered;

registering the service to be registered with a service registration center by using the service identification information of the service to be registered; the service registration center is used for storing registration data of the service to be registered;

responding to successful registration of the service to be registered in the service registration center, generating triplet data corresponding to the service to be registered by using the characteristic information of the service to be registered, and storing the triplet data into a designated storage area; the triplet data comprises service identification information of the service to be registered and a virtual service address of the service to be registered.

Optionally, the first container group includes a service container and a sidecar container, the service to be registered is deployed in the service container,

before the parsing of the first service registration request in response to receiving the first service registration request issued by the first container group, the method further includes:

The side car container intercepts a second service registration request sent by the service container, and encapsulates the second service registration request into the first service registration request by using the characteristic information of the service to be registered.

Optionally, before the sidecar container intercepts the second service registration request sent by the service container, the method further includes:

the side car container acquires configuration information of the service to be registered from a service grid management platform; the configuration information comprises identification information and naming space information of the service to be registered, wherein the identification information is used for identifying the second service registration request from the requests sent by the service container.

Optionally, the triplet data corresponding to the registered service includes an operation state of the registered service, and the method further includes:

receiving a heartbeat packet from the registered service;

and responding to the timeout of the heartbeat data packet, and marking the running state of the registered service in the triplet data corresponding to the registered service as abnormal.

Optionally, the method further comprises:

monitoring the running state of the first container group through a unified access interface of the container cloud platform;

And deleting the triplet data corresponding to the service to be registered in response to the first container group being in an abnormal state.

In a second aspect, an embodiment of the present application further provides a service discovery method supporting namespace awareness based on a service grid, where the method runs in a container cloud platform, and a service that initiates a call is deployed in a second container group in the container cloud platform, and the method includes the following steps:

responding to a first service call request sent by the second container group, and analyzing the first service call request;

responding to the first service calling request containing the characteristic information of the service to be called, acquiring the registration data of all the services from a service registration center, and acquiring the triplet data corresponding to the service to be called from a preset storage area by using the characteristic information of the service to be called; in the registration data, the IP address of the container group where each service is located is the access address of each service, the triplet data corresponding to the service to be called is generated when the service to be called is registered, and the triplet data corresponding to the service to be called comprises the service identification information and the virtual service address of the service to be called;

Matching the service identification information of the service to be called with the registration data of all the services;

and responding to successful matching of the service identification information of the service to be called and the registration data, using the virtual service address of the service to be called to replace the IP address of the container group where the service to be called is located as the access address of the service to be called, and returning the access address of the service to be called to the service initiating the call.

In a third aspect, embodiments of the present application further provide a service grid-based service registration system that supports namespace awareness, where the service registration system is deployed in a container cloud platform, where the container cloud platform includes a first container group in which a service to be registered is deployed; the service registration system includes:

the first analyzing module is used for analyzing the first service registration request when receiving the first service registration request sent by the first container group;

the first generation module is used for generating service identification information of the service to be registered by using the characteristic information of the service to be registered when the first service registration request contains the characteristic information of the service to be registered; the service identification information of the service to be registered is used for identifying the service to be registered, and the service identification information of the service to be registered contains the naming space information of the service to be registered;

A registration module, configured to register the service to be registered with the service registration center using service identification information of the service to be registered; the service registration center is used for storing registration data of the service to be registered;

the second generation module is used for generating triplet data corresponding to the service to be registered by using the characteristic information of the service to be registered when the service to be registered is successfully registered in the service registration center; the triplet data comprises service identification information of the service to be registered and a virtual service address of the service to be registered;

and the storage module is used for storing the triplet data to a designated storage area.

Optionally, the first container group includes a service container and a side vehicle container, the service to be registered is deployed in the service container, the service registration system further includes an interception packaging module, the interception packaging module is deployed in the side vehicle container, and the interception packaging module is configured to intercept a second service registration request sent by the service container before the first analysis module receives a first service registration request sent by the first container group, analyzes the first service registration request, and packages the second service registration request into the first service registration request by using feature information of the service to be registered.

Optionally, the interception packaging module includes an obtaining unit, where the obtaining unit is configured to obtain, from a service grid management platform, configuration information of the service to be registered, before the interception packaging module intercepts the second service registration request sent by the service container; the configuration information comprises identification information and naming space information of the service to be registered, wherein the identification information is used for identifying the second service registration request from the requests sent by the service container.

Optionally, the triplet data corresponding to the registered service includes an operation state of the registered service, and the service registration system further includes a marking module, where the marking module is configured to receive a heartbeat data packet from the registered service; and marking the running state of the registered service in the triplet data corresponding to the registered service as abnormal when the heartbeat data packet is overtime.

Optionally, the service registration system further includes a deletion module, configured to monitor, through a unified access interface of the container cloud platform, an operation state of the first container group; and deleting the triplet data corresponding to the service to be registered when the first container group is in an abnormal state.

In a fourth aspect, embodiments of the present application further provide a service grid-based service discovery system supporting namespace awareness, where the service discovery system is deployed in a container cloud platform, and the container cloud platform includes a second container group; a service for initiating the call is arranged in the second container group; the service discovery system includes:

the second analyzing module is used for analyzing the first service call request when receiving the first service call request sent by the second container group;

the acquisition module is used for acquiring registration data of all services from a service registration center when the first service calling request contains the characteristic information of the service to be called, and acquiring the triplet data corresponding to the service to be called from a preset storage area by using the characteristic information of the service to be called; in the registration data, the IP address of the container group where each service is located is the access address of each service, the triplet data corresponding to the service to be called is generated when the service to be called is registered, and the triplet data corresponding to the service to be called comprises the service identification information and the virtual service address of the service to be called;

The matching module is used for matching the service identification information of the service to be called with the registration data of all the services;

the replacing module is used for replacing the IP address of the container group where the service to be called is located with the virtual service address of the service to be called as the access address of the service to be called when the service identification information of the service to be called is successfully matched with the registration data;

and the return module is used for returning the access address of the service to be called to the service initiating the call.

In a fifth aspect, embodiments of the present application also provide a computer-readable storage medium having stored thereon executable instructions that, when executed by a machine, cause the method provided in the first aspect or the second aspect to be implemented.

In a sixth aspect, embodiments of the present application further provide an electronic device, in which a computer program is stored, which when executed by a processor implements the method provided in the first or second aspect.

It can be seen that in the above technical solution, a method and a system for service registration and service discovery supporting namespace awareness implemented based on a service grid technology are provided, in service registration, service identification information of a service to be registered is generated by using feature information of the service to be registered, the service to be registered is registered with a service registration center by using the service identification information of the service to be registered, and simultaneously, the service identification information and a virtual service address of the service to be registered are stored in a form of triplet data; when the service is found, the feature information of the service to be called is used for obtaining the triplet data corresponding to the service to be called from the preset storage area, and the virtual service address in the triplet data is used for replacing the IP address of the container group where the service is located in the registration data as the access address of the service to be called. Therefore, when the traditional micro service is migrated to the container cloud platform, the code logic structure of service registration and service discovery of the service system is not required to be changed, the complexity of migrating the service system of the traditional micro service architecture to the container cloud platform is effectively reduced, the service system of the traditional micro service architecture can be smoothly migrated to the container cloud platform, and the research and development cost of migrating the service system of the traditional micro service architecture and the operation and maintenance difficulty of the service system are also reduced.

Drawings

The conception, specific structure, and technical effects of the present invention will be further described with reference to the accompanying drawings to fully understand the objects, features, and effects of the present invention.

FIG. 1 is a schematic diagram of a service grid;

FIG. 2 is a functional schematic diagram of one example of a conventional micro-service architecture system;

FIG. 3 is a functional schematic of one example of a container cloud platform based service grid;

FIG. 4 is a flowchart of a service registration method supporting namespace awareness based on a service grid according to an embodiment of the present application;

FIG. 5 is a flowchart of another service registration method supporting namespace awareness based on a service grid according to an embodiment of the present application;

FIG. 6 is a flowchart of another service registration method supporting namespace awareness based on a service grid according to an embodiment of the present application;

FIG. 7 is a logical schematic diagram of one example of a service grid-based namespace-aware supporting service registration method as proposed by an embodiment of the present application;

FIG. 8 is a flow diagram illustrating a source load controller obtaining configuration information from a service grid management platform according to an exemplary embodiment of the present application;

FIG. 9 is a screenshot of relevant code of a declarative API configuration shown in accordance with an exemplary embodiment of the present application;

FIG. 10 is a logic diagram of a service registration request hijacked by a service registration adaptation controller according to an exemplary embodiment of the present application;

FIG. 11 is a flow diagram illustrating service registration and triple data storage by a service registration adaptation controller according to an exemplary embodiment of the present application;

FIG. 12 is a logical schematic diagram illustrating a service data storage controller updating triplet data according to an exemplary embodiment of the present application;

FIG. 13 is a flow diagram illustrating an update of triplet data by a service data storage controller according to an exemplary embodiment of the present application;

FIG. 14 is a flowchart of a service discovery method supporting namespace awareness based on a service grid according to an embodiment of the present application;

FIG. 15 is a flowchart of another service discovery method supporting namespace awareness based on a service grid according to an embodiment of the present application;

FIG. 16 is a flowchart of another service discovery method supporting namespace awareness based on a service grid according to an embodiment of the present application;

FIG. 17 is a logical schematic diagram of an example of a service grid-based namespace-aware enabled service discovery method according to an embodiment of the present application;

FIG. 18 is a flow diagram illustrating service discovery by a service registration adaptation controller according to an exemplary embodiment of the present application;

FIG. 19 is a schematic diagram illustrating a structure of a service registry supporting namespace awareness based on a service grid according to an embodiment of the present application;

fig. 20 is a schematic structural diagram of a service discovery system supporting namespace awareness based on a service grid according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. It will be appreciated by those of ordinary skill in the art that the embodiments described are some, but not all, of the embodiments of the invention. Based on the embodiments herein, any suitable modifications or variations may be made by a person skilled in the art, thereby obtaining all other embodiments.

It should be understood that the structures, proportions, sizes, etc. shown in the drawings are for illustration purposes only and should not be construed as limiting the invention to the extent that it can be practiced, since modifications, changes in the proportions, or otherwise, used in the practice of the invention, are not intended to be critical to the essential characteristics of the invention, but are intended to fall within the spirit and scope of the invention.

With the development of enterprise business, the user quantity is increased, the business system of the traditional single architecture is gradually bloated, the maintenance cost is increased, the improvement of performance and maintainability reaches the bottleneck, and the traditional micro-service architecture is adopted to deploy the business system.

Under the traditional micro-service architecture, the service system is disassembled into a plurality of micro-service applications to form a distributed system, and the micro-service applications are mutually called. To ensure performance and availability of the service system, the micro service application typically deploys multiple instances, and a service registry is provided to register all the micro service applications in the service system, where the service registry records information such as all the micro service applications in the service system, all the instances of each micro service application, access addresses of each micro service application, and so on.

The business system of the traditional micro-service architecture usually operates in a virtual machine or a bare metal server, and the bottom layer resource management of different virtual machines or bare metal servers is relatively independent, so that uniform scheduling, deployment and arrangement of bottom layer resources cannot be performed, and the flexible scheduling of the bottom layer resources cannot be realized.

Specifically, the Kubernetes system is a container cluster management system taking the Kubernetes as a core engine, is a cloud native platform capable of providing deployment operation, resource scheduling, service discovery, dynamic expansion and contraction and the like for containerized applications and covering the whole life cycle operation and management of a distributed system, and can realize the elastic expansion and contraction management of the bottom layer resources for coping with high-availability and high-concurrency scenes, so that many enterprises begin to try to migrate the business system of the traditional micro-service architecture to the container cloud platform represented by the Kubernetes cluster.

In the cloud native scenario, a business system is made up of hundreds of micro-service applications, and micro-service services are constantly being invoked dynamically to each other. The dynamic property of the micro service application in the cloud primary scene also causes the state of each micro service instance to be continuously changed, so that finer management requirements are also provided for the management of the micro service application.

In order to meet the requirements of fine management on the management of micro-service application in a cloud primary scene, a novel micro-service architecture system based on a container cloud platform, namely a service grid technology, is started to appear. The service grid is an infrastructure layer specially processing communication between micro service application instances, and abstracts an infrastructure layer on the basis of a traditional micro service architecture so as to strip data plane control in a micro service system from a service system without developing related data plane control logic (such as limiting, fusing, monitoring, authenticating and the like of data) in the service system, thereby greatly improving the development and production efficiency of the service system.

The core idea of the service grid technology is to set a lightweight proxy module for each micro-service application instance, and the proxy module is responsible for data forwarding control (such as limiting, fusing, monitoring, authenticating, etc. of data) of the micro-service application instance and ensures end-to-end performance and reliability. Fig. 1 is a block diagram of a Service grid, as shown in fig. 1, blocks with darker colors near the left side in each large rectangular frame are micro Service application instances, blocks with lighter colors near the right side in each large rectangular frame are Sidecar Proxy modules (i.e., agent modules, in a similar Service grid architecture as if a Sidecar is connected with a motorcycle, the Sidecar modules are connected to the micro Service application instances and are extended or enhanced functions), communication is performed between the micro Service application instances through the Sidecar Proxy, internal communication of the whole Service system forms network connection lines in the diagram, and Service Mesh (i.e., service grid) is formed after the Sidecar modules and the network connection lines in fig. 1 are combined.

The service grid architecture is used for developing the service system, so that a developer can focus on the service level without paying attention to the realization of micro service application on the technical level, and the technical threshold for developing the service system is reduced.

Therefore, more and more enterprises begin to migrate the business system of the traditional micro-service architecture to the container cloud platform, and deploy micro-service applications by adopting the service grid architecture. However, due to a certain difference between the traditional micro-service architecture and the service grid architecture in technical architecture, when the service system is migrated to the container cloud platform represented by the Kubernetes cluster, a great amount of adaptation development and modification are required to be performed on the service system, which greatly increases the migration difficulty of the service system.

In short, according to the requirements of the container cloud platform for resource isolation, a namespace and an access control policy need to be configured for each micro-service application in the service system, while a service registry in a traditional micro-service architecture does not support the configuration of the namespace and the access control policy.

The naming space is an abstraction of the scope of the resource scope, acts in a container cloud platform represented by a Kubernetes cluster, is an organization mechanism for classifying, screening and managing the managed resource, and can be isolated and distinguished by the naming space when a plurality of resource objects with the same name exist in the container cloud platform.

Specifically, in the conventional micro service architecture, all micro service application instances address on a unified plane, there is no logical isolation mechanism based on a namespace, while the container cloud platform needs to isolate resources, and accordingly, an access control policy based on the namespace mechanism is set, so that to enable a service system to adapt to the namespace mechanism and the access control policy of the container cloud platform, the service system discards a service registry in the conventional micro service architecture, and instead uses a service discovery mechanism of the container cloud platform, which needs to make a great deal of modifications on the code logic structures of service registration and service discovery of the service system.

In addition, in a cloud primary scenario, it is generally required to deploy multiple environments in the same container cloud platform, for example, the container cloud platform may be divided into a development environment, a test environment, and a production environment, and the same service system is deployed in each environment. The naming space mechanism of the container cloud platform can logically isolate a plurality of environments, and distinguish micro service application instances with the same name in service systems in different environments, while the traditional micro service architecture needs to deploy a separate service registration center under different naming spaces of the container cloud platform due to the lack of the naming space-based logical isolation mechanism, so that service registration and service discovery functions are provided for the service systems under the naming spaces, and the resource consumption of the whole system is increased.

In order to solve the defects existing in the migration process of the service system in the existing production practice, the applicant carries out in-depth analysis on the traditional micro service architecture and the service grid architecture in the container cloud platform.

As shown in fig. 2, the conventional micro service architecture generally adopts a self-discovery mode, that is, a client mode, each micro service application instance is integrated with a client corresponding to a service registry, and a calling process between the whole micro service application instances is divided into three steps:

Step one, service registration. Each micro service application instance is connected with a service registry through a client, information (such as access address, instance state, provided service interface and the like) of the micro service application instance is registered in the service registry, and heartbeat maintenance is carried out between the micro service application instance and the service registry (so that the service registry judges the state of the micro service application instance).

And step two, service discovery. The micro service application instance initiating the call is connected with the registration service center, and related information of the called micro service application instance is queried and obtained.

And step three, calling the service. After the calling micro service application instance obtains the related information of the called micro service application instance, the called micro service application instance is connected according to the access address of the called micro service application instance, and calling communication of the micro service application instance is carried out.

As shown in fig. 3, in the container cloud platform, all micro-service application instances are deployed in a container group (Pod), running in the form of containers. Pod is the smallest unit of scheduling by a container cloud platform, and consists of one or more containers, all of which in the same Pod share storage, network and namespaces, and specifications of how to operate. All containers in the same Pod are arranged and scheduled together and run in a shared context. For a particular micro-service application instance, pod is their logical host, and Pod contains a plurality of business containers related to the business.

Under the service grid architecture, network data of all micro service application instances in the Pod are intercepted by the sidecar container, and operations such as encapsulation, decapsulation, forwarding and the like are performed by a data gateway in the sidecar container.

The data gateway is used as a necessary path for connecting the micro service application instance and the service registration center, can intercept network data sent by the micro service application instance and forward the network data, can communicate with a control plane under the service grid architecture, and can acquire the name space information of the Pod through the control plane.

Further, watch in fig. 3 indicates monitoring, RPC in gRPC is a short for Remote Procedure Call, called remote procedure call, gRPC is a high performance, general open source RPC framework developed by google, mainly developed for mobile applications and designed based on HTTP/2 protocol standards, while supporting most popular programming languages, gRPC is based on HTTP/2 protocol transport.

Based on the knowledge of the traditional micro service architecture and the service grid architecture in the container cloud platform, the embodiment of the application provides a service registration and discovery method and system supporting name space perception based on the service grid, which realizes smooth migration of a service system of the traditional micro service architecture into the container cloud platform and enables micro service application instances in the service system to adapt to the service grid architecture.

For convenience of explanation, the micro-service application instance will be hereinafter simply referred to as a service.

Based on the foregoing, the whole service invocation procedure is divided into three steps: service registration, service discovery, and service invocation. The service that initiates the call in the service call step may directly connect to the called service according to the access address of the called service, so that the key of the whole service call process is to let the calling service know the access address of the called service, which is the purpose to be achieved by the service registration and service discovery steps.

In order to clearly explain how the service registration and discovery method and system supporting namespace awareness based on the service grid provided in the embodiments of the present application enables the calling service to learn the access address of the called service, the following describes the steps of the service registration method and the service discovery method respectively.

Fig. 4 is a flowchart of a service registration method supporting namespace awareness based on a service grid according to an embodiment of the present application. As shown in fig. 4, a service registration method supporting namespace awareness based on a service grid, which is provided in an embodiment of the present application, operates in a container cloud platform, where the container cloud platform includes a first container group, and the first container group includes a service container and a side vehicle container, and a service to be registered is deployed in the service container, and the method includes the following steps:

In step S101, in response to receiving the first service registration request sent by the first container group, the first service registration request is parsed.

It can be understood that the service registration process is a process that the service to be registered registers its own information in the service registration center, and the service to be registered is deployed in the service container of the first container group, so that the service registration request sent by the service to be registered to the service registration center is the first service registration request sent by the first container group.

The embodiment of the application classifies all the services to be registered in the container cloud platform, wherein one class is the services to be registered which need to use a naming space mechanism, and the other class is the services to be registered which do not need to use the naming space mechanism. For the service to be registered without using a namespace mechanism, the first service registration request can be directly forwarded to the service registration center as in the traditional micro-service architecture, and the first service registration request does not contain any characteristic information. And for a service to be registered that requires the use of a namespace mechanism, the first service registration request contains feature information.

Specifically, in the embodiment of the application, for a service to be registered, which needs to use a namespace mechanism, the first service registration request includes feature information. And analyzing the first service registration request to judge whether the first service registration request contains the characteristic information of the service to be registered, and if so, further processing the first service registration request is needed. If no characteristic information is contained, the first service registration request is forwarded directly to the service registry.

Step S102, in response to the first service registration request containing the feature information of the service to be registered, the feature information of the service to be registered is used for generating service identification information of the service to be registered.

The service identification information of the service to be registered is used for identifying the service to be registered, and the service identification information of the service to be registered contains the name space information of the service to be registered.

In particular, the feature information of the service to be registered is used to identify whether further processing of the first service registration request is required, and the feature information may be in the form of Header information of the first service registration request. After the first service registration request is analyzed, whether the first service registration request needs to be further processed is judged according to whether the Header information of the first service registration request contains characteristic information.

For example, the feature information may be a specific string, such as dsmsp, and when the Header information of the first service registration request includes dsmsp, it is determined that further processing is required for the first service registration request.

The further processing of the first service registration request is specifically to use the feature information of the service to be registered to generate service identification information of the service to be registered.

Based on the foregoing, in the cloud primary scenario, it is generally required to deploy multiple environments in the same container cloud platform and deploy the same service system in each environment, which may cause multiple services with the same name in the same container cloud platform, which are difficult to distinguish and identify, and cannot be registered in the same service registration center. It is therefore necessary to generate service identification information of the service to be registered using the feature information of the service to be registered as a unique identification of the service to be registered in the entire container cloud platform.

It should be specifically noted that, in the embodiment of the present application, the feature information of the first service registration request further includes namespace information of the service to be registered, that is, a namespace to which the first container group belongs and related information. The first service registration request is analyzed, so that relevant information such as a name space of the service to be registered can be separated from the first service registration request, and further service identification information generated by the relevant information such as the name space can be used for re-identifying the service to be registered instead of a service name.

For example, the Service name of the Service to be registered is abc, the name space is ns01, the Workload is dep01, and the load agent is ser01, then the generated Service identification information is dsmsp:: ns01: depth 01:: abc according to a preset rule (i.e. Service identification information = dsmsp: [ NameSpace ]: [ workbench ]: [ Service ]: [ AppName ]). The name space and related information of the service to be registered are reserved in the service identification information of the service to be registered in the form of characteristic information parameters.

And step S103, registering the service to be registered with the service registration center by using the service identification information of the service to be registered.

The service registration center is used for storing registration data of the service to be registered.

It should be noted that, in the embodiment of the present application, the service system of the conventional micro service architecture is to be smoothly migrated to the container cloud platform, so that the service registry of the conventional micro service architecture is directly deployed in the container cloud platform, and the service to be registered is registered with the service registry by using the service identification information of the service to be registered generated in step S102, and the service registry uses the same service registration manner under the conventional micro service architecture to store the service identification information of the service to be registered and other data information in the first service registration request, that is, the registration information of the service to be registered, in the service registry, so as to complete the registration of the service to be registered.

It should be understood that after migrating the service system of the traditional micro-service architecture to the container cloud platform, for the service that does not need to use the namespace mechanism to perform logical isolation, the service registration request does not contain feature information, that is, the service registration request does not need to generate corresponding service identification information, and the service registration request is directly registered in the service registration center by using the service name.

Step S104, in response to successful registration of the service to be registered in the service registration center, generating triple data corresponding to the service to be registered by using the characteristic information of the service to be registered, and storing the triple data in a designated storage area.

The triple data refers to a data set with three types of data fields (such as a node name of a service to be registered, service identification information of the service to be registered, and a service name of the service to be registered) forming a unique index, and the triple data comprises the service identification information of the service to be registered and a virtual service address of the service to be registered.

Table 1 is an example of triplet data as set forth in embodiments of the present application.

TABLE 1

Table 1 notes:

HostName field: the cloud platform comprises a domain name, a name space and a service name of the container cloud platform;

IPAddr+Port field composed of Cluster IP+TargetPort Port information of micro-service application instance;

InstanceID field: the system consists of a name space, a node where the name space is located and a service name;

status field: and the state of the micro service application instance is represented, when the micro service application instance is abnormal or is offline, the micro service application instance is down, and when the micro service application instance is normal, the micro service application instance is up.

As shown in table 1, in the triple data structure, a unique index of the data set is formed with three types of data fields, and values of all types of data fields are used to store related data information of a service to be registered.

Based on the foregoing description, in the conventional micro service architecture, the service registration request sent by the service includes the access address of the service, and after the service system is migrated to the container cloud platform, the access address of the service included in the first service registration request is the access address of the first container set because the service is deployed in the container set.

The container orchestration engine represented by the Kubernetes system is capable of automated deployment and scaling of services, resulting in actual access addresses of the services not matching access addresses stored in the service registry. Specifically, when registering, the service to be registered registers with the service registration center by using the access address of the first container group, but after the service is rescheduled by the container cloud platform, the service is scheduled to other container groups, so that the actual access address of the service is changed.

To solve this problem, after the service to be registered is successfully registered, the embodiment of the application binds according to the service identification information of the service to be registered and the virtual service address (ClusterIP) of the service to be registered, and stores the binding in the form of triple data in the designated storage area.

It should be noted that, the ClusterIP is a virtual IP address, which is used for accessing different micro service application instances corresponding to different micro service applications, and all the micro service application instances corresponding to the same micro service application may share the same ClusterIP.

For example, whereas this section description refers to the concepts of both micro-service applications and micro-service application instances, to avoid confusion, services are not used instead of micro-service application instances to describe. The micro service application A is exemplified by A1 and A2, the micro service application B is exemplified by B1 and B2, the ClusterIP corresponding to the micro service application A is 192.168.1.1, the ClusterIP corresponding to the micro service application B is 192.168.1.2, if the micro service application B is to be called by the micro service application A1, a call request is sent to the ClusterIP (192.168.1.2) corresponding to the micro service application B, and the call request is forwarded to the micro service application B1 by a load balancing component of the micro service application B according to the load condition of the micro service application examples B1 and B2. That is, even if the micro service application instance A1 does not know the access address of the micro service application instance B1, the call request can be sent to the micro service application instance B1 through the ClusterIP corresponding to the micro service application B, and the micro service application instance A1 can meet the requirement as long as any instance of the micro service application B can be called.

Based on this, the embodiment of the present application stores the service identification information of the service to be registered and the access address of the first container group as registration data of the service to be registered in the service registration center, and stores the service identification information of the service to be registered and the ClusterIP of the service to be registered in the form of triplet data to the designated storage area, and when the service is found and invoked, provides the ClusterIP of the service to be invoked to the service that initiates the invocation, so that the service that initiates the invocation can smoothly access the service to be invoked through the ClusterIP. The method not only ensures the invasiveness to the registration service center, namely, the registration service center does not need to be added with a mechanism for dynamically sensing the change of the actual access address of the service and dynamically updating the registration data, reduces the coupling between the registration service center and the container cloud platform, but also solves the problem that the actual access address of the service in the container cloud platform is inconsistent with the access address stored in the service registration center.

In addition, if the service to be registered fails to be registered in the service registration center, the registration of the service to be registered is finished, and the service to be registered can reinitiate the service registration request.

In summary, in the service registration method supporting namespace awareness based on the service grid provided in the embodiment of the present application, when a first service registration request sent by a first container group is received, the first service registration request is parsed. When the first service registration request contains the feature information of the service to be registered, the feature information of the service to be registered is used for generating service identification information of the service to be registered, and the service to be registered is registered with the service registration center by using the service identification information of the service to be registered. When the service to be registered is successfully registered in the service registration center, generating triplet data corresponding to the service to be registered by using the characteristic information of the service to be registered, and storing the triplet data into a designated storage area. Therefore, when the service system of the traditional micro service architecture is migrated to the container cloud platform, the code logic structure of service registration and service discovery of the service system is not required to be changed, the service registration mechanism of the service registration center is not required to be modified, and smooth migration of the service system is realized.

Further, in order to enable the first service registration request in the embodiment of the present application to include feature information of the service to be registered, another service registration method supporting namespace awareness based on a service grid is provided in the embodiment of the present application, and fig. 5 is a schematic flow chart of another service registration method supporting namespace awareness based on a service grid provided in the embodiment of the present application. As shown in fig. 5, the method operates in a container cloud platform, a service to be registered is deployed in a first container group in the container cloud platform, the first container group includes a service container and a side car container, and the service to be registered is deployed in the service container, and the method includes:

in step S201, the sidecar container intercepts a second service registration request sent by the service container, and encapsulates the second service registration request into a first service registration request by using feature information of a service to be registered.

Based on the foregoing description of the service grid architecture, the service grid technology sets a lightweight proxy module for each service, and the proxy module is responsible for data forwarding control of the service. The side car container of the first container group in the embodiment of the application is provided with the proxy module, so that the second service registration request sent by the service to be registered in the service container of the first container group can be intercepted.

The second service registration request is a service registration request sent by the service to be registered under the traditional micro-service architecture, and after the service to be registered is migrated to the container cloud platform, the second service registration request does not contain feature information such as name space information of the service to be registered because the traditional micro-service architecture has no name space mechanism.

In order to generate service identification information of a service to be registered according to the feature information, and register the service in a service registration center by using the service identification information of the service to be registered, in the embodiment of the application, a side car container unpacks a second service registration request, and repackages data information in the second service registration request by combining the feature information of the service to be registered, so that the feature information of the service to be registered is added to the service registration request to obtain a first service registration request.

In step S202, in response to receiving the first service registration request sent by the first container group, the first service registration request is parsed.

In step S203, service identification information of the service to be registered is generated using the feature information of the service to be registered in response to the first service registration request including the feature information of the service to be registered.

Step S204, the service to be registered is registered with the service registration center by using the service identification information of the service to be registered.

In step S205, in response to successful registration of the service to be registered in the service registration center, the feature information of the service to be registered is used to generate triplet data corresponding to the service to be registered, and the triplet data is stored in the designated storage area.

It should be noted that the explanation of the steps S101 to S104 in the above embodiment is also applicable to the steps S202 to S205 in the embodiments of the present application, and will not be repeated here.

Therefore, according to the service grid-based service registration method supporting name space perception, a second service registration request sent by a service to be registered is intercepted by means of a side car container of a service grid framework, and feature information of the service to be registered is added to the service registration request in a form of unpacking and repackaging, so that the first service registration request contains name space information of the service to be registered.

Further, in order to enable the sidecar container to identify and intercept the second service registration request, the embodiment of the application proposes a service registration method supporting namespace awareness based on a service grid, and fig. 6 is a flow diagram of a service registration method supporting namespace awareness based on a service grid according to the embodiment of the application. As shown in fig. 6, the method operates in a container cloud platform, a service to be registered is deployed in a first container group in the container cloud platform, the first container group includes a service container and a side vehicle container, and the service to be registered is deployed in the service container, and the method includes:

In step S301, the sidecar container acquires configuration information of the service to be registered from the service grid management platform.

The configuration information comprises identification information and naming space information of the service to be registered, wherein the identification information is used for identifying a second service registration request from requests sent by the service container.

The identification information specifically includes access address information, protocol information and policy information, the access address information is used for identifying an access address, an access port, an interface name, a parameter and the like of the registration service center, the protocol information is used for defining a communication protocol type, such as http, dubbo-rpc, rmi, hessian and the like, used for a second service registration request to be intercepted by the side car container, and the policy information is used for defining a rule policy for processing the second service registration request after the side car container identifies the second service registration request.

It can be understood that the side car container can forward and control all requests sent by the service container, identify the second service registration request therefrom and intercept the second service registration request, and in order to improve the identification efficiency, in this embodiment of the present application, a policy for identifying the second service registration request is configured for the side car container in advance, specifically, according to an access address pointed by the request and a communication protocol type used by the request, identify that the request is the second service registration request sent by the service to be registered.

In addition, the sidecar container may further acquire a virtual service address of the service to be registered from the service grid management platform, and in step S302, the virtual service address of the service to be registered and feature information of the service to be registered are added to the first service registration request together. When the first service registration request is parsed in step S303, the virtual service address of the service to be registered is separated from the first service registration request, so that the virtual service address of the service to be registered is stored in the form of triplet data in the designated storage area in step S306.

It should be appreciated that the service grid management platform operates in a container cloud platform, which is a platform that provides relevant service grid governance capabilities under the service grid architecture. The service grid management platform can realize the management of the service in the container cloud platform in a code intrusion-free mode, and a container cloud platform manager can realize the configuration of functions such as the management of the service, the registration and discovery of the service, the management of the service, the monitoring of the service and the like through a control interface of the service grid management platform. Therefore, the sidecar container can acquire the access address of the registration service center, the name space information of the service to be registered, the communication protocol type set by the container cloud platform manager and the rule policy for processing the second service registration request from the service grid management platform.

In addition, if the namespace information of the service to be registered changes, the sidecar container may also acquire the changed namespace information from the service grid management platform.

In step S302, the sidecar container intercepts a second service registration request sent by the service container, and encapsulates the second service registration request into a first service registration request by using feature information of the service to be registered.

In step S303, in response to receiving the first service registration request sent by the first container group, the first service registration request is parsed.

In step S304, service identification information of the service to be registered is generated using the feature information of the service to be registered in response to the first service registration request including the feature information of the service to be registered.

And step S305, registering the service to be registered with the service registration center by using the service identification information of the service to be registered.

In step S306, in response to successful registration of the service to be registered in the service registration center, the feature information of the service to be registered is used to generate triplet data corresponding to the service to be registered, and the triplet data is stored in the designated storage area.

It should be noted that the explanation of step S201 to step S205 in the above embodiment is also applicable to step S302 to step S306 in the embodiment of the present application, and will not be repeated here.

Therefore, the method and the device realize that a container cloud platform administrator uses a service grid management platform to configure the identification and interception rules of the second service registration request and the rule strategy of processing the second service registration request, and the sidecar container obtains the configuration information of the service to be registered from the service grid management platform to identify, intercept and process the second service registration request.

Further, in order to monitor the running state of the registered service in real time, the unregistered service in all the foregoing embodiments becomes the registered service after the registration is successful, and the triplet data corresponding to the registered service includes the running state of the registered service, where the method proposed in all the foregoing embodiments further includes:

step S401, a heartbeat packet is received from a registered service.

And step S402, in response to the timeout of the heartbeat data packet, marking the running state of the registered service in the triplet data corresponding to the registered service as abnormal.

Based on the foregoing description of service registration under the conventional micro-service architecture, it is known that a heartbeat maintenance is required between a service and a service registry, so that the service registry can determine the running state of the service.

Therefore, the embodiment of the application also needs to receive the heartbeat data packet from the registered service, and once the heartbeat data packet is overtime, the running state of the registered service recorded in the triplet data needs to be updated, and the running state is marked as abnormal.

In addition, since in the container cloud platform, all the services are deployed in the container group, when the container group is abnormal, the services deployed therein cannot operate normally, so the method proposed by all the foregoing embodiments further includes:

step S501, monitoring the running state of the first container group through the unified access interface of the container cloud platform.

Step S502, deleting the triplet data corresponding to the service to be registered in response to the first container group being in an abnormal state.

Specifically, the running states of all container groups in the container cloud platform can be monitored through a unified access interface (such as an API-Server component of a Kubernetes cluster) of the container cloud platform, when the first container group is monitored to be in an abnormal state, the service to be registered in the first container group cannot be normally called, and the triplet data corresponding to the service to be registered can be deleted.

It should be noted that, when the heartbeat packet is overtime, the registered service may fail to operate normally, or the heartbeat packet is lost due to a network communication failure, so that the operation state of the registered service is marked as abnormal in the triplet data, and meanwhile, the operation state of the container group where the registered service is located is further verified through the unified access interface of the container cloud platform.

If the unified access interface of the container cloud platform monitors that the running state of the first container group is abnormal, it can be confirmed that the service to be registered in the first container group cannot be normally called, and the triplet data corresponding to the service to be registered can be deleted, so that storage resources are saved.

In order to more clearly illustrate the above-mentioned methods proposed in the embodiments of the present application, the following description is given by way of example. Fig. 7 is a logic schematic diagram of an example of a service grid-based service registration method supporting namespace awareness according to an embodiment of the present application, as shown in fig. 7, where a first container group, a service registration system, a service network controller, a service gateway configuration controller, and a service grid management platform are deployed in a container cloud platform, where the service registration system includes a service registration adaptation controller, a service registration center, and a service data storage controller, where the service registration adaptation controller further includes a service registration adaptation module and a service status adaptation module, and the steps of the method according to the embodiment of the present application are mainly performed by the service registration adaptation controller. The first container group includes a service container in which service a is deployed and a sidecar container in which the source load controller is deployed.

As shown in fig. 8, the container cloud platform administrator first sets a communication protocol type of a service registration request in the service grid management platform and a rule policy for processing the service registration request, and the service gateway configuration controller periodically queries an access address of the service registration center, a communication protocol type used by a request to be intercepted, namespace information of the service a, and ClusterIP of the service a from the service grid management platform, synthesizes a declarative API configuration of the adapted container cloud platform according to related parameters in the information, and invokes the service grid controller to execute the declarative API configuration, and issues related parameters to the source load controller through a management data channel, and related codes of the declarative API configuration are shown in fig. 9. When the source load controller is started, namely, initializing configuration is carried out according to the received related parameters, service registration requests sent by the service A are identified, intercepted and processed according to the configuration parameters in running, and state information of the source load controller is periodically synchronized to the service grid management platform through the management data channel.

It should be noted that, since the service grid management platform and the source load controller cannot directly communicate with each other and the operation mechanisms are different, the configuration management, issuing and controlling work of the source load controller needs to be undertaken by the service gateway configuration controller.

With continued reference to fig. 7, when the service a deployed in the service container of the first container group is started, a service registration request is actively sent to the service registration center, a source load controller deployed in the side container of the first container group recognizes that the type of the request is a service registration request according to information such as an access address and a communication protocol type of the service registration center, that is, intercepts the service registration request, and decapsulates and repackages the service registration request, so as to add feature information such as namespace information, node information and the like of the service a, and ClusterIP of the service a into the service registration request, and write a specific character string into Header information of the service registration request.

The source load controller sends the service registration request to the service registry after completing the repackaging of the service registration request. As shown in fig. 10, the service registration adaptation module in the service registration adaptation controller hives a service registration request sent to the service registration center, analyzes the service registration request, separates feature information such as name space information and node information of the service a from the service registration request, and ClusterIP of the service a, and determines whether to generate a new id for the service a according to the feature information such as name space of the service a according to Header information of the service registration request.

As shown in fig. 11, if Header information of a service registration request contains a specific character string, a new id of a service a is generated using feature information according to a preset rule, and a mapping relationship is established between feature information such as a namespace of the service a separated from the service registration request and a ClusterIP of the service a, and the new id of the service a, and registration is performed in a service registration center using the new id of the service a. If the Header information of the service registration request does not contain a specific character string, the service name of the service A is directly used for registration in the service registration center.

After the new id of the service A is successfully registered in the service registration center, the service registration adaptation controller forwards the characteristic information such as the name space of the service A and the mapping relation between the ClusterIP of the service A and the new id of the service A to the service data storage controller, and the service data storage controller caches the information in a memory in the form of triple data. It is considered that the information of the service a is often changed, and thus the data persistence processing may not be performed on the information.

As shown in fig. 12, after storing the triplet data corresponding to the service a in the form of a memory, the service data storage controller continuously monitors the running state of the first container group where the service a is located in real time through the unified interface of the container cloud platform, and immediately deletes the triplet data corresponding to the service a in the memory once the first container group is monitored to be in an abnormal state.

Further, considering that the container group in the container cloud platform is deployed by the depoyment and the number of objects deployed by the depoyment is huge, the embodiment of the present application updates the triplet data by adopting a timing polling (the default polling interval is 1 minute).

As shown in fig. 13, all objects deployed by the replyment are acquired through a unified interface of the container cloud platform, a replyment object list is generated, the triplet data is sequentially compared with the replyment object list, if the triplet data cannot be found in the replyment object list, it is indicated that the triplet data has expired, the triplet data is deleted, and if the triplet data can be found in the replyment object list, the triplet data is updated according to the running state of the container group.

With continued reference to fig. 7, after the service a deployed in the first container group is successfully registered in the service registry, periodically and continuously sending a heartbeat data packet to the service registry, performing hijacking and detection on the heartbeat data packet sent to the service registry by the service state adapting module in the service registration adapting controller, calling the service data storage controller to mark the state of the service a recorded in the triple data corresponding to the service a in the memory as abnormal once the heartbeat data packet is detected to be overtime, and actively inquiring whether the running state of the first container group in which the service a is located is abnormal or not through a unified interface of the container cloud platform, and immediately deleting the triple data corresponding to the service a in the memory if the first container group is in an abnormal state.

Fig. 14 is a flowchart of a service discovery method supporting namespace awareness based on a service grid according to an embodiment of the present application. As shown in fig. 14, a service discovery method supporting namespace awareness based on a service grid, the method running in a container cloud platform, and a service initiating a call being deployed in a second container group in the container cloud platform, the method comprising the steps of:

in step S601, in response to receiving the first service call request sent by the second container group, the first service call request is parsed.

Based on the foregoing description, the whole service calling process is divided into three steps of service registration, service discovery and service calling. The access address of the service to be registered can be stored in the service registration system through service registration, and the service initiating the call can acquire the access address of the service to be called from the service registration system through service discovery, so that call communication of the service to be called is realized when the service is called.

It should be understood that, in the service discovery phase, the service to be invoked deployed in the first container group has successfully completed registration in the service registry, so that the service deployed in the second container group can perform service discovery on the service to be invoked, and therefore, a service invocation request sent by the service initiating invocation to the service registry is the first service invocation request sent by the second container group.

Based on the foregoing description, if the service to be invoked does not use the namespace mechanism, the service to be invoked is directly registered in the service registry using the service name. Accordingly, when service discovery is performed on the service to be invoked, the first service invocation request does not contain any feature information. And if the service to be invoked uses a namespace mechanism, the service to be invoked uses the service identification information to register in the service registry. Accordingly, when service discovery is performed on the service to be invoked, the first service invocation request contains feature information.

Specifically, in the embodiment of the application, for a service to be invoked using a namespace mechanism, the first service invocation request includes feature information. And analyzing the first service call request to judge whether the first service call request contains the feature information of the service to be called, and if so, further processing the first service call request. If no characteristic information is contained, the first service invocation request is directly forwarded to the service registry.

Step S602, responding to the first service calling request containing the characteristic information of the service to be called, acquiring the registration data of all the services from the service registration center, and acquiring the triplet data corresponding to the service to be called from the preset storage area by using the characteristic information of the service to be called.

Similar to the service registration method, the feature information may exist in the form of Header information of the first service invocation request. After the first service call request is analyzed, whether feature information such as a name space of the service to be called is needed to be separated from the first service call request is judged according to whether the Header information of the first service call request contains the feature information.

It should be understood that in the service registration process, for the service to be invoked using the namespace mechanism, service identification information is registered in the service registration center, and the service identification information and the virtual service address of the service to be invoked are stored in the designated storage area in the form of triplet data. Correspondingly, the service registration center stores registration data of the service to be called, wherein the access address of the service to be called in the registration data is the IP address of the container group, and the triple data comprises service identification information and virtual service address of the service to be called.

That is, in the registration data, the IP address of the container group where each service is located is the access address of each service, and the triplet data corresponding to the service to be invoked is generated when the service to be invoked is registered, and includes the service identification information and the virtual service address of the service to be invoked.

The embodiment of the application can acquire the registration data of all the services through the access interface provided by the service registration center, and retrieve the registration data of the service to be called from the registration data.

Based on the foregoing description, the triplet data refers to a data set with three types of data fields (such as a node name of a service to be invoked, service identification information of the service to be invoked, and a service name) forming a unique index, where the service identification information of the service to be invoked is generated by using feature information when the service to be invoked is registered, and feature information of the service to be invoked is reserved in the service identification information in the form of feature information parameters. Therefore, the triple data corresponding to the service to be called can be searched out from all the triple data stored in the preset storage area by using the characteristic information such as the name space of the service to be called. And the triplet data corresponding to the service to be called comprises the service identification information of the service to be called, so that the service identification information of the service to be called is obtained.

Step S603, the service identification information of the service to be invoked is used to match with the registration data of all the services.

The service to be called uses the service identification information to register in the service registration center, and the registration data of the service to be called contains the corresponding service identification information, so that the service identification information of the service to be called can be directly matched with the registration data of all the services.

In step S604, in response to successful matching of the service identification information of the service to be invoked and the registration data, the virtual service address of the service to be invoked is used to replace the IP address of the container group where the service to be invoked is located, as the access address of the service to be invoked, and the access address of the service to be invoked is returned to the service initiating the invocation.

It should be understood that, the registration data of the service to be invoked includes other data information besides the access address, so that in the embodiment of the application, only the access address of the service to be invoked is replaced by the virtual service address from the IP address of the container group, and no change is made to other data information. After the replacement of the access address is completed, the registration data of the service to be invoked is returned to the service that initiated the invocation.

Based on the foregoing description, the virtual service address (ClusterIP) of the service to be invoked is provided to the service that initiates the invocation, so that the service that initiates the invocation can smoothly access the service to be invoked through ClusterIP. The method not only ensures the invasiveness to the registration service center, namely, the registration service center does not need to be added with a mechanism for dynamically sensing the change of the actual access address of the service and dynamically updating the registration data, reduces the coupling between the registration service center and the container cloud platform, but also solves the problem that the actual access address of the service in the container cloud platform is inconsistent with the access address stored in the service registration center.

In summary, according to the service discovery method supporting namespace awareness based on the service grid provided in the embodiments of the present application, when a first service call request sent by a second container group is received, the first service call request is parsed. When the first service calling request contains the characteristic information of the service to be called, acquiring the registration data of all the services from a service registration center, and acquiring the triplet data corresponding to the service to be called from a preset storage area by using the characteristic information of the service to be called. And the service identification information of the service to be called is matched with the registration data of all the services, when the service identification information of the service to be called is successfully matched with the registration data, the virtual service address of the service to be called is used for replacing the IP address of the container group where the service to be called is located and is used as the access address of the service to be called, and the access address of the service to be called is returned to the service initiating the call. Therefore, when the service system of the traditional micro service architecture is migrated to the container cloud platform, the code logic structure of service registration and service discovery of the service system is not required to be changed, the service discovery mechanism of the service registration center is not required to be modified, and smooth migration of the service system is realized.

Further, in order to enable the feature information of the service to be invoked to be included in the first service invocation request in the embodiment of the present application, another service discovery method supporting namespace awareness based on a service grid is provided in the embodiment of the present application, and fig. 15 is a schematic flow diagram of another service discovery method supporting namespace awareness based on a service grid provided in the embodiment of the present application. As shown in fig. 15, the method operates in a container cloud platform, a service initiating a call is deployed in a second container group in the container cloud platform, the second container group includes a business container and a side car container, the service initiating the call is deployed in the business container, the method includes:

in step S701, the sidecar container intercepts a second service call request sent by the service container, and encapsulates the second service call request into a first service call request by using feature information of a service to be invoked.

Similar to the service registration method, the side vehicle container of the second container set in the embodiment of the application is also provided with an agent module, which can intercept a second service call request sent by a service initiating call in the service container of the second container set.

The second service call request is a service call request sent by the calling service under the traditional micro-service architecture, and after the calling service is migrated to the container cloud platform, the second service call request does not contain feature information such as the name space information of the service to be called.

In order to use the feature information of the service to be invoked, the triplex data corresponding to the service to be invoked is obtained from a preset storage area, and in the embodiment of the application, the side car container unpacks the second service invoking request and repackages the data information in the second service invoking request by combining the feature information of the service to be invoked, so that the feature information of the service to be invoked is added into the service invoking request to obtain the first service invoking request.

In step S702, in response to receiving the first service call request sent by the second container group, the first service call request is parsed.

In step S703, in response to the first service invocation request including the feature information of the service to be invoked, the registration data of all the services are obtained from the service registration center, and the triplet data corresponding to the service to be invoked is obtained from the preset storage area by using the feature information of the service to be invoked.

Step S704, the service identification information of the service to be invoked is used to match the registration data of all the services.

Step S705, in response to successful matching of the service identification information of the service to be invoked and the registration data, using the virtual service address of the service to be invoked to replace the IP address of the container group where the service to be invoked is located as the access address of the service to be invoked, and returning the access address of the service to be invoked to the service initiating the invocation.

It should be noted that the explanation of the steps S601 to S604 in the above embodiment is also applicable to the steps S702 to S705 in the embodiments of the present application, and will not be repeated here.

Therefore, according to the service discovery method supporting name space perception based on the service grid, which is provided by the embodiment of the application, a second service call request sent by a service which initiates call is intercepted by means of a side car container of a service grid framework, and feature information of the service to be called is added to the service call request in a form of unpacking and repackaging, so that the name space information of the service to be called is contained in the first service call request.

Further, in order to enable the sidecar container to identify and intercept the second service call request, the embodiment of the present application proposes another service discovery method supporting namespace awareness based on the service grid, and fig. 16 is a flow chart of another service discovery method supporting namespace awareness based on the service grid according to the embodiment of the present application. As shown in fig. 16, the method operates in a container cloud platform, a service initiating a call is deployed in a second container group in the container cloud platform, the second container group includes a business container and a side car container, the service initiating the call is deployed in the business container, the method includes:

In step S801, the sidecar container acquires configuration information of all services from the service grid management platform.

The configuration information comprises identification information and naming space information of all services, wherein the identification information is used for identifying a second service calling request from requests sent by the service container.

It can be appreciated that, since the embodiments of the present application allow the service that initiates the call to call all other services in the container cloud platform, the sidecar container is required to acquire configuration information of all services from the service grid management platform in advance.

Based on the foregoing, it is known that there are some services that do not use a namespace mechanism, and that identification information and namespace information of these services cannot be obtained from the service grid management platform.

The identification information specifically includes access address information, protocol information and policy information, the access address information is used for identifying an access address, an access port, an interface name, parameters and the like of a registration service center, the protocol information is used for defining a communication protocol type, such as http, dubbo-rpc, rmi, hessian and the like, used for a second service call request to be intercepted by the sidecar container, and the policy information is used for defining a rule policy for processing the second service call request after the sidecar container identifies the second service call request.

It can be understood that the side car container can forward and control all requests sent by the service container, identify the second service call request therefrom and intercept the second service call request, and in order to improve the identification efficiency, in this embodiment of the present application, a policy for identifying the second service call request is configured for the side car container in advance, specifically, according to an access address pointed by the request and a communication protocol type used by the request, identify the second service call request sent by the request for a service that initiates the call.

In addition, the sidecar container may further acquire url address information of all services from the service grid management platform, and in step S802, determine that the second service call request points to the service to be called according to the url address information of the service in the second service call request, so as to determine feature information of the service to be called from feature information of all services, and add the feature information to the first service call request.

Step S802, the side car container intercepts a second service call request sent by the business container, and encapsulates the second service call request into a first service call request by using feature information of the service to be invoked.

In step S803, in response to receiving the first service call request sent by the second container group, the first service call request is parsed.

Step S804, responding to the first service calling request containing the characteristic information of the service to be called, acquiring the registration data of all the services from the service registration center, and acquiring the triplet data corresponding to the service to be called from the preset storage area by using the characteristic information of the service to be called.

Step S805, the service identification information of the service to be invoked is used to match with the registration data of all the services.

Step S806, in response to successful matching of the service identification information of the service to be invoked and the registration data, the virtual service address of the service to be invoked is used to replace the IP address of the container group where the service to be invoked is located as the access address of the service to be invoked, and the access address of the service to be invoked is returned to the service initiating the invocation.

It should be noted that the explanation of the steps S701 to S705 in the above embodiment is also applicable to the steps S802 to S806 in the embodiments of the present application, and will not be repeated here.

Therefore, the method and the device realize that a container cloud platform administrator uses a service grid management platform to configure the identification and interception rules of the second service call request and the rule strategy for processing the second service call request, and the sidecar container obtains the configuration information of all services from the service grid management platform to identify, intercept and process the second service call request.

In order to more clearly illustrate the above-mentioned methods proposed in the embodiments of the present application, the following description is given by way of example. Fig. 17 is a logic schematic diagram of an example of a service grid-based service discovery method supporting namespace awareness according to the embodiment of the present application, as shown in fig. 17, where a first container group, a second container group, a service registration system, a service network controller, a service gateway configuration controller, and a service grid management platform are disposed in a container cloud platform, where the service registration system includes a service registration adaptation controller, a service registration center, and a service data storage controller, and the service registration adaptation controller includes a service registration adaptation module and a service status adaptation module. The first container group and the second container group both comprise a service container and a sidecar container, the service a and the service B are respectively deployed in the service containers of the first container group and the second container group, and the source load controller is deployed in the sidecar containers of the first container group and the second container group.

The method comprises the steps that firstly, a container cloud platform manager sets a communication protocol type of a service call request in a service grid management platform and a rule strategy for processing the service call request, a service gateway configuration controller periodically inquires an access address of a service registration center, a communication protocol type used by a request to be intercepted and naming space information of all services from the service grid management platform, and according to related parameter combinations in the information, the declaration API configuration of the container cloud platform is assembled and adapted, and the service grid controller is called to execute the declaration API configuration, and related parameters are issued to a source load controller in a side vehicle container of a second container group through a management data channel. And when the source load controller in the side vehicle container of the second container group is started, initializing and configuring the source load controller according to the received related parameters, identifying, intercepting and processing a service call request sent by the service B according to the configuration parameters in operation, and periodically synchronizing the state information of the source load controller to the service grid management platform through the management data channel.

The service B deployed in the service container of the second container group sends a service call request to the service registry, the source load controller deployed in the side vehicle container of the second container group recognizes that the type of the request is a service call request according to the access address of the service registry and the communication protocol type and other information which are configured in advance, namely, intercepts the service call request, unpacks and repackages the service call request, determines that the service call request points to the service A according to the service url address information in the service call request, adds the characteristic information such as the name space information, the node information and the like of the service A into the service call request, and writes a specific character string into the Header information of the service call request.

After the source load controller completes the repackaging of the service call request, the service call request is sent to the service registry. The service registration adaptation module in the service registration adaptation controller hives the service call request sent to the service registration center and analyzes the service call request. Judging whether feature information such as name space information, node information and the like of the service A need to be separated from the service call request according to Header information of the service call request.

As shown in fig. 18, if the Header information of the service call request includes a specific string, the registration data of all the services are obtained through the access interface provided by the service registration center, and the triplet data corresponding to the service a is obtained by using the feature information such as the namespace information and the node information of the service a. Further, the id and ClusterIP of the service a can be obtained from the triplet data corresponding to the service a, the id of the service a is used to match with the registration data of all the services, the registration data of the service a can be obtained, the IP address of the first container group in the registration data of the service a is replaced by the ClusterIP of the service a, so that the ClusterIP of the service a is used as the access address of the service a to return to the service B, and the service B can initiate call communication to the service a by using the ClusterIP of the service a.

If the Header information of the service call request does not contain a specific character string, acquiring the registration data of all the services through an access interface provided by a service registration center, matching the service names of the service A with the registration data of all the services, and directly returning the acquired registration data of the service A to the service B.

The embodiment of the application also provides a service registration system supporting the name space sensing based on the service grid, so as to execute a service registration method supporting the name space sensing based on the service grid. As shown in fig. 19, the service grid-based service registration system supporting namespace awareness is deployed in a container cloud platform, where the container cloud platform includes a first container group in which a service to be registered is deployed; the service registration system supporting namespace awareness based on the service grid comprises: the system comprises a first parsing module 910, a first generating module 920, a registering module 930, a second generating module 940 and a storing module 950.

The first parsing module 910 is configured to parse the first service registration request when receiving the first service registration request sent by the first container group.

A first generating module 920, configured to generate, when the first service registration request includes feature information of a service to be registered, service identification information of the service to be registered using the feature information of the service to be registered; the service identification information of the service to be registered is used for identifying the service to be registered, and the service identification information of the service to be registered contains the name space information of the service to be registered.

A registration module 930, configured to register a service to be registered with a service registration center using service identification information of the service to be registered; the service registry is used for storing registration data of the service to be registered.

A second generating module 940, configured to generate, when the service to be registered is successfully registered in the service registry, triplet data corresponding to the service to be registered using feature information of the service to be registered; the triplet data includes service identification information of the service to be registered and a virtual service address of the service to be registered.

A storage module 950, configured to store the triplet data in a specified storage area.

Optionally, the first container group includes a service container and a side vehicle container, the service to be registered is deployed in the service container, and the service registration system further includes an interception packaging module deployed in the side vehicle container, where the side vehicle module is configured to intercept a second service registration request sent by the service container before the first analysis module 910 receives the first service registration request sent by the first container group and analyzes the first service registration request, and package the second service registration request into the first service registration request by using feature information of the service to be registered.

Optionally, the interception packaging module includes an obtaining unit, where the obtaining unit is configured to obtain, from the service grid management platform, configuration information of a service to be registered before the interception packaging module intercepts a second service registration request sent by the service container; the configuration information includes identification information for identifying a second service registration request from the requests issued by the service container and namespace information for the service to be registered.

Optionally, the triplet data corresponding to the service to be registered further includes an operation state of the service to be registered, and the service registration system further includes a marking module, where the marking module is configured to receive a heartbeat data packet from the service to be registered; and when the heartbeat data packet is overtime, marking the running state of the service to be registered in the triplet data corresponding to the service to be registered as abnormal.

Optionally, the service registration system further includes a deletion module, configured to monitor, through a unified access interface of the container cloud platform, an operation state of the first container group; and deleting the triple data corresponding to the service to be registered when the first container group is in an abnormal state.

The embodiment of the application also provides a service grid-based service discovery system supporting namespace awareness, so as to execute a service grid-based service discovery method supporting namespace awareness. As shown in fig. 20, the service grid-based service discovery system supporting namespace awareness is deployed in a container cloud platform, where the container cloud platform includes a second container group in which a service that initiates a call is deployed; the service grid-based service discovery system supporting namespace awareness comprises: the second parsing module 1010, the obtaining module 1020, the matching module 1030, the replacing module 1040, and the returning module 1050.

And a second parsing module 1010, configured to parse the first service call request when receiving the first service call request sent by the second container group.

The acquiring module 1020 is configured to acquire registration data of all services from the service registry when the first service call request includes feature information of the service to be called, and acquire triplet data corresponding to the service to be called from a preset storage area using the feature information of the service to be called; in the registration data, the IP address of the container group where each service is located is the access address of each service, the triplet data corresponding to the service to be called is generated when the service to be called is registered, and the triplet data corresponding to the service to be called comprises the service identification information and the virtual service address of the service to be called.

And a matching module 1030, configured to match the service identification information of the service to be invoked with the registration data of all the services.

And the replacing module 1040 is configured to replace an IP address of a container group where the service to be invoked is located with a virtual service address of the service to be invoked as an access address of the service to be invoked when the service identification information of the service to be invoked is successfully matched with the registration data.

The return module 1050 is configured to return the access address of the service to be invoked to the service that initiates the invocation.

The present application also provides a machine-readable storage medium having stored thereon executable instructions that when executed by a machine cause the machine to implement the specific procedures of the namespace-aware supporting service registration method based on a service grid in the above method embodiments.

The present application also provides a machine-readable storage medium having stored thereon executable instructions that when executed by a machine cause the machine to implement the specific procedures of the namespace-aware supporting service discovery method based on a service grid in the above method embodiments.

The present application also provides an electronic device in which a computer program is stored, which when executed by a processor, implements the specific procedure of the service grid-based service registration method supporting namespace awareness in the above method embodiment. The computer program may be downloaded and installed from a network via a communication means, or installed from a storage means, or installed from a ROM.

The present application also provides an electronic device in which a computer program is stored, which when executed by a processor, implements the specific procedure of the service grid-based namespace-aware service discovery method in the above method embodiment. The computer program may be downloaded and installed from a network via a communication means, or installed from a storage means, or installed from a ROM.

The computer readable storage medium described in the present application may be a single computer readable storage medium, a computer readable signal medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, a computer-readable signal medium may include a data signal that propagates in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, fiber optic cables, RF (radio frequency), and the like, or any suitable combination of the foregoing.

Furthermore, those of skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Those skilled in the art may implement the described functionality in varying ways for each particular application, but such implementation is not intended to be limiting.

The foregoing describes in detail preferred embodiments of the present invention. It should be understood that numerous modifications and variations can be made in accordance with the concepts of the invention without requiring creative effort by one of ordinary skill in the art. Therefore, all technical solutions which can be obtained by logic analysis, reasoning or limited experiments based on the prior art by the person skilled in the art according to the inventive concept shall be within the scope of protection defined by the claims.

Claims

1. A service grid-based service registration method supporting namespace awareness, the method operating in a container cloud platform, a service to be registered being deployed in a first container group in the container cloud platform, the method comprising the steps of:

responding to successful registration of the service to be registered in the service registration center, generating triplet data corresponding to the service to be registered by using the characteristic information of the service to be registered, and storing the triplet data into a designated storage area; the triplet data comprises service identification information of the service to be registered and a virtual service address of the service to be registered;

the first container group comprises a service container and a side car container, the service to be registered is deployed in the service container,

2. The service grid-based namespace-aware service registration method of claim 1, wherein prior to the intercepting the second service registration request by the business container by the sidecar container, the method further comprises:

3. The service grid-based namespace-aware-enabled service registration method of claim 1, wherein the triplet data corresponding to a registered service comprises an operational state of the registered service, the method further comprising:

Receiving a heartbeat packet from the registered service;

4. A service grid based namespace aware supporting service registration method according to any of claims 1-3, the method further comprising:

5. A service grid-based service discovery method supporting namespace awareness, the method operating in a container cloud platform, the invoking service deployed in a second set of containers in the container cloud platform, the method comprising the steps of:

responding to successful matching of the service identification information of the service to be called and the registration data, using the virtual service address of the service to be called to replace the IP address of the container group where the service to be called is located as the access address of the service to be called, and returning the access address of the service to be called to the service initiating the call;

the second container group comprises a service container and a side car container, the service for initiating the call is deployed in the service container,

before the parsing of the first service call request in response to receiving the first service call request issued by the second container group, the method further includes:

the side car container intercepts a second service call request sent by the service container, and encapsulates the second service call request into the first service call request by using the characteristic information of the service to be invoked.

6. A service registration system supporting namespace awareness based on a service grid, wherein the service registration system is deployed in a container cloud platform, the container cloud platform comprising a first container group in which a service to be registered is deployed; the service registration system includes:

The storage module is used for storing the triplet data to a designated storage area;

before the first service registration request sent by the first container group is received and analyzed, the side car container intercepts a second service registration request sent by the service container, and encapsulates the second service registration request into the first service registration request by using the characteristic information of the service to be registered.

7. A service grid-based service discovery system supporting namespace awareness, wherein the service discovery system is deployed in a container cloud platform, the container cloud platform comprising a second container group in which a call-initiating service is deployed; the service discovery system includes:

the replacing module is used for replacing the IP address of the container group where the service to be called is located with the virtual service address of the service to be called when the service identification information of the service to be called is successfully matched with the registration data, and the virtual service address is used as the access address of the service to be called;

the return module is used for returning the access address of the service to be called to the service initiating the call;

and before responding to the first service call request sent by the second container group and analyzing the first service call request, the side car container intercepts the second service call request sent by the service container and encapsulates the second service call request into the first service call request by using the characteristic information of the service to be called.

8. A computer readable storage medium having stored thereon executable instructions, which when executed by a machine, implement the method of any of claims 1-5.

9. An electronic device in which a computer program is stored which, when executed by a processor, implements the method of any one of claims 1-5.