CN115190103A - Service grid-based service domain name resolution method, device and equipment - Google Patents
Service grid-based service domain name resolution method, device and equipment Download PDFInfo
- Publication number
- CN115190103A CN115190103A CN202110367382.1A CN202110367382A CN115190103A CN 115190103 A CN115190103 A CN 115190103A CN 202110367382 A CN202110367382 A CN 202110367382A CN 115190103 A CN115190103 A CN 115190103A
- Authority
- CN
- China
- Prior art keywords
- service
- domain name
- address
- grid
- name resolution
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
The application provides a service domain name resolution method, a device, equipment and a computer readable storage medium based on a service grid; wherein, the method comprises the following steps: the service name resolution service receives a service name resolution request sent by the first micro service; the service name resolution request comprises a service domain name registered in the service grid by the second micro service; analyzing the service domain name based on the service list in the local cache to obtain the IP address of the second micro service; the service list is synchronously obtained from a control plane of the service grid; the IP address is returned to the first microservice such that the first microservice accesses the second microservice in the service grid based on the IP address. By the method and the device, flexible expansion of various registration centers can be supported when the service domain name in the service grid is analyzed, and decoupling with a PaaS deployment platform is realized.
Description
Technical Field
The present application relates to, but not limited to, the field of computer technologies, and in particular, to a service domain name resolution method, apparatus, device, and computer-readable storage medium based on a service grid.
Background
A Service Mesh is an infrastructure layer that handles inter-Service communications. It is responsible for composing the complex service topology of modern cloud-native applications to deliver requests reliably. In practice, service Mesh is usually implemented in the form of a lightweight network proxy array, where the proxy is deployed with application code, and there is no need for the application to be aware of the presence of the proxy. In the related art, the Service Mesh scheme does not provide a Domain Name resolution Service based on a Service Name, but relies on Domain Name System (DNS) components (e.g., kubeDNS components of kubernets, etc.) in a Platform as a Service registration and discovery framework of a Platform as a Service (PaaS), and is coupled with a registry adopted by a PaaS Platform tightly, so that the Domain Name resolution Service is difficult to extend to a PaaS Platform based on other registries.
Disclosure of Invention
The embodiment of the application provides a service domain name resolution method and device based on a service grid and a computer readable storage medium, which can support flexible expansion of various registration centers when a service domain name in the service grid is resolved, and realize decoupling with a PaaS deployment platform.
The technical scheme of the embodiment of the application is realized as follows:
the embodiment of the application provides a service domain name resolution method based on a service grid, which comprises the following steps:
the service name resolution service receives a service name resolution request sent by the first micro service; the service name resolution request comprises a service domain name registered in a service grid by the second micro service;
analyzing the service domain name based on a service list in a local cache to obtain an IP address of the second micro service; wherein the service list is obtained from a control plane of the service grid in synchronization;
returning the IP address to the first microservice to cause the first microservice to access the second microservice in the service grid based on the IP address.
In some embodiments, the service name resolution service is deployed in a data plane of the service grid in a distributed deployment manner, and the service name resolution service receives a service name resolution request sent by a first microservice, including: the service name resolution service receives a service name resolution request sent by a first micro service deployed in the local.
In some embodiments, the first microservice is deployed in an application container, the service name resolution service and a data plane component of the service grid are deployed in a proxy container, the proxy container and the application container share a same local network; or the first micro-service, the service name resolution service and the data plane component of the service grid are deployed in the same host together.
In some embodiments, the method further comprises: under the condition that the corresponding relation between the service domain name and the IP address registered in the service grid is determined to be changed, acquiring a pair of the changed service domain name and the IP address; and updating the service list based on the changed service domain name and IP address pair.
In some embodiments, in the case that it is determined that the correspondence between the service domain name and the IP address registered in the service grid occurs, acquiring the pair of the service domain name and the IP address that has undergone the change includes at least one of: acquiring a service domain name and IP address pair which is changed from the control surface under the condition that the corresponding relation between the service domain name and the IP address which is discovered by the control surface is monitored to be changed; and acquiring at least one group of service domain name and IP address configured by a user from an external service name configuration system, and determining a service domain name and IP address pair changed in the service list based on the at least one group of service domain name and IP address configured by the user.
In some embodiments, the resolving the service domain name based on the service list in the local cache to obtain the IP address of the second micro service includes: based on the service domain name, inquiring a service list in a local cache; under the condition that the IP address corresponding to the service domain name is not inquired in the service list, forwarding the service name resolution request to a set external service name resolution service; and receiving the IP address of the second micro service returned by the external service name resolution service.
In some embodiments, the method further comprises: when the service name resolution service is started, acquiring the currently found full service domain name and IP address pairs from the control plane; and adding the full service domain name and IP address pair to the service list, and caching the service list into a local cache.
The embodiment of the application provides a service domain name resolution device based on a service grid, which comprises:
the receiving module is used for receiving a service name analysis request sent by the first micro service by the service name analysis service; the service name resolution request comprises a service domain name registered in a service grid by the second micro service;
the resolution module is used for resolving the service domain name based on a service list in a local cache to obtain an IP address of the second micro service; wherein the service list is obtained synchronously from a control plane of the service grid;
a return module for returning the IP address to the first microservice so that the first microservice accesses the second microservice in the service grid based on the IP address.
In some embodiments, the service name resolution service is deployed in a data plane of the service grid in a distributed deployment manner, and the receiving module is further configured to: the service name resolution service receives a service name resolution request sent by a first micro service deployed in the local.
In some embodiments, the first microservice is deployed in an application container, the service name resolution service and a data plane component of the service grid are deployed in a proxy container, and the proxy container and the application container share the same local network; or the first micro-service, the service name resolution service and the data plane component of the service grid are deployed in the same host together.
In some embodiments, the apparatus further comprises: a first obtaining module, configured to obtain a pair of a service domain name and an IP address that are changed when it is determined that a correspondence between the service domain name and the IP address registered in the service grid is changed; and the updating module is used for updating the service list based on the changed service domain name and IP address pair.
In some embodiments, the first obtaining module is further configured to at least one of: acquiring a service domain name and IP address pair which is changed from the control surface under the condition that the corresponding relation between the service domain name and the IP address which is discovered by the control surface is monitored to be changed; and acquiring at least one group of service domain name and IP address configured by a user from an external service name configuration system, and determining a service domain name and IP address pair changed in the service list based on the at least one group of service domain name and IP address configured by the user.
In some embodiments, the parsing module is further to: based on the service domain name, inquiring a service list in a local cache; under the condition that the IP address corresponding to the service domain name is not inquired in the service list, forwarding the service name resolution request to a set external service name resolution service; and receiving the IP address of the second micro service returned by the external service name resolution service.
In some embodiments, the apparatus further comprises: a second obtaining module, configured to obtain, from the control plane, a total number of currently-discovered service domain name and IP address pairs when the service name resolution service is started; and the cache module is used for adding the total service domain name and IP address pairs to the service list and caching the service list into a local cache.
The embodiment of the application provides a service domain name resolution device based on a service grid, which comprises: a memory for storing executable instructions; and the processor is used for realizing the method provided by the embodiment of the application when executing the executable instructions stored in the memory.
Embodiments of the present application provide a computer-readable storage medium, which stores executable instructions for causing a processor to implement the method provided by the embodiments of the present application when the processor executes the executable instructions.
The embodiment of the application has the following beneficial effects:
receiving a service name resolution request sent by a first micro service through a service name resolution service, wherein the service name resolution request comprises a service domain name registered in a service grid by a second micro service, resolving the service domain name based on a service list in a local cache to obtain an IP address of the second micro service, the service list is synchronously obtained from a control surface of the service grid, and finally returning the IP address to the first micro service so that the first micro service accesses the second micro service in the service grid based on the IP address. In this way, since the control plane of the service grid can be adapted to different registration centers, the service list synchronously obtained from the control plane of the service grid can include the corresponding relationship between the service domain name and the IP address of the micro-service registered by the different registration centers, so that flexible expansion of various registration centers can be supported when the service domain name in the service grid is analyzed, and decoupling with the PaaS deployment platform is realized.
Drawings
FIG. 1 is an alternative schematic diagram of a microservice architecture based on a service grid provided by an embodiment of the present application;
fig. 2 is an alternative structural diagram of a service domain name resolution device based on a service grid according to an embodiment of the present application;
fig. 3 is an alternative flowchart of a service domain name resolution method based on a service grid according to an embodiment of the present application;
fig. 4 is an alternative flowchart of a service domain name resolution method based on a service grid according to an embodiment of the present application;
fig. 5 is an alternative flowchart of a service domain name resolution method based on a service grid according to an embodiment of the present application;
fig. 6 is an alternative flowchart of a service domain name resolution method based on a service grid according to an embodiment of the present application;
fig. 7 is an alternative flowchart of a service grid-based service domain name resolution method according to an embodiment of the present application;
FIG. 8 is a schematic diagram of an overall architecture of a distributed DNS service applied in a service grid according to an embodiment of the present application;
fig. 9 is a schematic flow chart of an implementation of a service domain name resolution method based on a service grid according to an embodiment of the present application.
Detailed Description
In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be described in further detail with reference to the attached drawings, the described embodiments should not be considered as limiting the present application, and all other embodiments obtained by a person of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.
In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.
Where similar language of "first/second" appears in the specification, the following description is added, and where reference is made to the term "first \ second \ third" merely to distinguish between similar items and not to imply a particular ordering with respect to the items, it is to be understood that "first \ second \ third" may be interchanged with a particular sequence or order as permitted, to enable the embodiments of the application described herein to be performed in an order other than that illustrated or described herein.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the present application only and is not intended to be limiting of the application.
Before further detailed description of the embodiments of the present application, terms and expressions referred to in the embodiments of the present application will be described, and the terms and expressions referred to in the embodiments of the present application will be used for the following explanation.
1) The pilot-discovery is a control plane component of the Service Mesh, serves as a scheduling control center, and can provide Service registration information and Service configuration issue to control the function of the data plane component.
2) The pilot-agent is a data plane component of the Service Mesh and is responsible for initialization and cleaning of the environment and life cycle management of other data plane components (such as envoy components).
3) Kubernetes, an open source container orchestration engine, is used to automate deployment, scaling, and management of containerized applications.
In order to better understand the service domain name resolution method based on the service grid provided in the embodiment of the present application, a service domain name resolution scheme adopted in the service grid in the related art is first described below.
In the related art, the Service Mesh scheme does not provide a domain name resolution Service based on a Service domain name, but depends on a DNS component in a container arrangement platform, such as a kubeDNS component of a kubernet platform, and the like, and the kubeDNS component is a centrally deployed DNS Service cluster. Taking a Service Mesh scheme based on kubernets as an example, kubernets includes a kubbedns component and a SkyDNS component, and the basic working principle of performing Service domain name resolution in the scheme includes: the kubbedns component is responsible for monitoring the change situation of a Service (Service) and a terminal (Endpoint) in kubernets, and updating related information into the SkyDNS component to synchronize to a Service list; the SkyDNS component is responsible for receiving a service domain name resolution request, inquiring a synchronized service list and returning a resolution result.
In the related art, the Service Mesh addresses the Service domain name through the centralized DNS Service, which has the following problems: 1) The Service domain name addressing depends on a kubbedns component, the kubbedns component updates a Service list through changes of a kubernets platform Service and an Endpoint, and the kubernets platform is coupled tightly and is difficult to extend to other registration centers; 2) An additional set of centralized DNS cluster needs to be deployed during Service Mesh networking, so that not only is the physical resource cost increased, but also the later-stage operation and maintenance cost is increased due to the consideration of high availability and even disaster tolerance of the DNS cluster; 3) The centralized DNS Service deployment mode means that once the cluster is unavailable, the Service Mesh data plane node cannot work normally after the DNS cache fails; 4) The centralized DNS service is generally deployed at a far end, even in a cross-network environment, so that certain response delay exists in domain name resolution, and even a timeout condition may occur in a heterogeneous network environment; 5) The centralized DNS Service processes Service name resolution requests of all nodes of a Service Mesh data surface, when the number of the nodes of the data surface is increased, the DNS Service is forced to have a large pressure influence on performance, the DNS Service is inevitably required to be expanded, and resource cost and operation and maintenance cost are additionally increased.
The embodiment of the application provides a service domain name resolution method, a service domain name resolution device, service domain name resolution equipment and a computer readable storage medium based on a service grid, which can support flexible expansion of various registration centers when a service domain name in the service grid is resolved, and realize decoupling with a PaaS deployment platform. An exemplary application of the service domain name resolution device based on the service grid according to the embodiment of the present application is described below, and the service domain name resolution device based on the service grid according to the embodiment of the present application may be implemented as a service name resolution service, and the service name resolution service may be implemented as various types of user terminals such as a laptop computer, a tablet computer, a desktop computer, a set-top box, a mobile device (e.g., a mobile phone, a portable music player, a personal digital assistant, a dedicated messaging device, and a portable game device), and may also be implemented as a server. In the following, an exemplary application will be explained when the device is implemented as a server.
Referring to fig. 1, fig. 1 is an alternative schematic diagram of a micro-service architecture 100 based on a service grid according to an embodiment of the present application, which can implement service grid-based communication between multiple micro-services, where multiple micro-services (illustratively, a first micro-service 400-1 and a second micro-service 400-2) deployed on the service grid are connected to a server 200 through a network 300, and the network 300 may be a wide area network or a local area network, or a combination of the two. The service grid includes a control plane 510 and a data plane (data plane nodes 520-1 and 520-2 are shown as examples), each microservice is deployed with an associated data plane node, the data plane is responsible for converting, forwarding, and monitoring each network packet or request coming in and going out of the associated microservice, and the control plane 510 is used to provide service registration information and service configuration delivery in the service grid to control the functionality of the data plane components.
The first microservice 400-1 is used to: sending a service name resolution request to the server 200, wherein the service name resolution request comprises a service domain name registered in the service grid by the second microservice 400-2; receiving an IP address returned by the server 200, and accessing the second microservice 400-2 in the service grid based on the IP address.
The server 200 is configured to: receiving a service name resolution request sent by a first microservice 400-1; wherein, the service name resolution request includes a service domain name registered in the service grid by the second microservice 400-2; analyzing the service domain name based on a service list in a local cache to obtain an IP address of the second micro service 400-2; wherein the service list is obtained from a control plane 510 of the service grid in synchronization; returning the IP address to the first microservice 400-1 to cause the first microservice 400-1 to access the second microservice 400-2 in the service grid based on the IP address.
In some embodiments, the server 200 may be a standalone physical server, or may be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, web services, cloud communications, middleware services, domain name services, security services, CDNs, and big data and artificial intelligence platforms. The server 200 may be deployed in a centralized manner or in a distributed manner in the data plane of the service grid, which is not limited herein. The terminal may be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, a smart car coupler, etc., but is not limited thereto. The first micro-service and the server may be directly or indirectly connected through wired or wireless communication, which is not limited in the embodiment of the present invention.
The micro service architecture 100 related To the embodiment of the present application may also be a distributed system of a block chain system, where the distributed system may be a distributed node formed by multiple nodes (any form of computing device in an access network, such as a server and a user terminal) and a client, a point-To-point (P2P, peer To Peer) network is formed between the nodes, and the P2P Protocol is an application layer Protocol operating on a Transmission Control Protocol (TCP). The server 200 may act as a node of the distributed system. In a distributed system, any machine, such as a server or a terminal, can join to become a node, which includes a hardware layer, an intermediate layer, an operating system layer, and an application layer.
Referring to fig. 2, fig. 2 is a schematic structural diagram of a service domain name resolution device 200 based on a service grid according to an embodiment of the present application, where the service domain name resolution device 200 based on a service grid shown in fig. 2 includes: at least one processor 210, memory 250, at least one network interface 220, and a user interface 230. The various components in the service grid-based service domain name resolution device 200 are coupled together by a bus system 240. It is understood that the bus system 240 is used to enable communications among the components. The bus system 240 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are labeled as bus system 240 in fig. 2.
The Processor 210 may be an integrated circuit chip having Signal processing capabilities, such as a general purpose Processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like, wherein the general purpose Processor may be a microprocessor or any conventional Processor, or the like.
The user interface 230 includes one or more output devices 231, including one or more speakers and/or one or more visual display screens, that enable the presentation of media content. The user interface 230 also includes one or more input devices 232, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.
The memory 250 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid state memory, hard disk drives, optical disk drives, and the like. Memory 250 optionally includes one or more storage devices physically located remote from processor 210.
The memory 250 includes volatile memory or nonvolatile memory, and may include both volatile and nonvolatile memory. The nonvolatile memory may be a Read Only Me (ROM) memory, and the volatile memory may be a Random Access Memory (RAM). The memory 250 described in embodiments herein is intended to comprise any suitable type of memory.
In some embodiments, memory 250 is capable of storing data, examples of which include programs, modules, and data structures, or a subset or superset thereof, to support various operations, as exemplified below.
An operating system 251 including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;
a network communication module 252 for communicating to other computing devices via one or more (wired or wireless) network interfaces 220, exemplary network interfaces 220 including: bluetooth, wireless compatibility authentication (WiFi), and Universal Serial Bus (USB), and the like;
a presentation module 253 to enable presentation of information (e.g., a user interface for operating peripherals and displaying content and information) via one or more output devices 231 (e.g., a display screen, speakers, etc.) associated with the user interface 230;
an input processing module 254 for detecting one or more user inputs or interactions from one of the one or more input devices 232 and translating the detected inputs or interactions.
In some embodiments, the service domain name resolution device based on the service grid provided in the embodiment of the present application may be implemented in a software manner, and fig. 2 shows a service domain name resolution device 255 based on the service grid stored in the storage 250, which may be software in the form of programs and plug-ins, and includes the following software modules: a receiving module 2551, a parsing module 2552 and a returning module 2553, which are logical and thus may be arbitrarily combined or further split depending on the functionality implemented.
The functions of the respective modules will be explained below.
In other embodiments, the service domain name resolution Device based on the service grid provided in the embodiments of the present Application may be implemented in hardware, for example, the service domain name resolution Device based on the service grid provided in the embodiments of the present Application may be a processor in the form of a hardware decoding processor, which is programmed to execute the service domain name resolution method based on the service grid provided in the embodiments of the present Application, for example, the processor in the form of the hardware decoding processor may employ one or more Application Specific Integrated Circuits (ASICs), DSPs, programmable Logic Devices (PLDs), complex Programmable Logic Devices (CPLDs), field Programmable Gate Arrays (FPGAs), or other electronic elements.
The service grid-based service domain name resolution method provided by the embodiment of the present application will be described below with reference to exemplary applications and implementations of a terminal or a server provided by the embodiment of the present application.
Referring to fig. 3, fig. 3 is an optional flowchart of the service domain name resolution method based on the service grid according to the embodiment of the present application, and the following steps will be described with reference to the steps shown in fig. 3, where the execution subject of the following steps may be the foregoing service name resolution service.
In step S101, the service name resolution service receives a service name resolution request sent by a first microservice; and the service name resolution request comprises a service domain name registered in the service grid by the second micro service.
Here, the service name resolution service is used to implement service domain name resolution in the service grid, and may be a service deployed in a distributed manner or a service deployed in a centralized manner, and may be deployed in the service grid or separately from the service grid, which is not limited herein.
A plurality of micro services may be deployed in the service grid, and each micro service may be deployed and managed through the PaaS platform. In implementation, any suitable PaaS platform may be used to deploy and manage microservices in the service grid.
The first micro service and the second micro service are respectively different micro services which are connected based on a service grid, and the first micro service and the second micro service are respectively associated with one data plane node in the service grid and are respectively deployed together with the associated data plane node. The first microservice and the second microservice may communicate based on data plane nodes of a service grid. In practice, the first micro-service and the second micro-service may be any suitable services in a services grid, and are not limited herein. In some embodiments, the first microservice may be an upstream service or upstream application and the second microservice may be a downstream service or downstream application that the first microservice needs to invoke.
Each micro service deployed in the service grid needs to register a service domain name in the registry, and the service domain name of the micro service is a domain name for accessing the micro service in the service grid, and may be any suitable character string or number that can uniquely identify the micro service, and the like, which is not limited herein. For example, the service domain name of the microservice may be the microservice's service name, service ID, and the like.
In step S102, the service domain name is resolved based on the service list in the local cache, so as to obtain the IP address of the second microservice; wherein the service list is obtained from a control plane of the service grid in synchronization.
Here, the service list may include a correspondence between the service domain name of the micro service and the IP address of the micro service, and based on the correspondence, the service domain name may be resolved to obtain the IP address of the second micro service. In practice, the service list may be cached in any suitable manner, for example, the service list may be cached to a local memory, a local disk, a local database, or the like.
The control plane of the service grid can provide service registration information in the service grid, so that the service domain name and the corresponding IP address of the micro service registered in the service grid can be obtained from the control plane of the service grid, and the service domain name and the corresponding IP address are synchronized or updated to a service list cached locally. Because the IP address of the same micro service may be dynamically changed, the control plane of the service grid may obtain the latest IP address of the micro service through service discovery, and thus the correspondence between the service domain name and the IP address in the service list obtained synchronously from the control plane of the service grid may be always kept valid.
In step S103, the IP address is returned to the first microservice, so that the first microservice accesses the second microservice in the service grid based on the IP address.
After the IP address of the second micro service is obtained through analysis, the IP address is returned to the first micro service, and the first micro service can access the second micro service in the service grid based on the IP address.
In some embodiments, the service name resolution service is deployed in a data plane of the service grid in a distributed deployment manner, where the step S101 may include: step S111, the service name resolution service receives a service name resolution request sent by a first micro service deployed in the local. Here, the service name resolution service is deployed in a distributed deployment manner, each service name resolution service node in the distributed service name resolution service is deployed together with one data plane node of the service grid, and as the data plane node in the service grid is deployed together with the micro-service, each micro-service can correspond to one local service name resolution service node. The service name resolution service can receive a service name resolution request sent by a first micro service deployed in the local, process the service name resolution request and return a corresponding IP address. Therefore, each micro service can directly analyze the IP address of the micro service to be accessed through local communication, the service name analysis delay is greatly reduced, each service name analysis service only needs to process the service name analysis request of the local micro service, the request pressure is low, the performance is high, and the performance bottleneck is not easy to appear. In addition, the unavailable service name analysis service node of a single service name can not influence the service name analysis of other data plane nodes, and the stability of the whole service is better.
In some embodiments, the first microservice is deployed in an application container, the service name resolution service and a data plane component of the service grid are deployed in a proxy container, and the proxy container and the application container share the same local network. Here, the data plane of the services grid may include at least one data plane component, such as a pilot-agent, envoy, or the like. The first microservice may be deployed in an application container, the service name resolution service is deployed together with the data plane components of the service grid, may be deployed in a sidecar manner in a proxy container where the application container is in the same container POD, a POD being the smallest basic unit to create or deploy a container, one POD representing a process running on a cluster, any container in the same POD will share the same namespace and local network, and a container may easily communicate with other containers in the same container POD. In practice, the application container and the proxy container may be any suitable container, and are not limited herein.
In some embodiments, the first microservice, the service name resolution service, and the data plane component of the service grid are co-deployed in the same host. Here, the host co-deployed with the first microservice, the service name resolution service, and the data plane component of the service grid may be any suitable server host, including but not limited to one or more of a virtual machine, a bare metal server, and the like.
In the embodiment of the application, a service name resolution request sent by a first micro service is received through a service name resolution service, the service name resolution request comprises a service domain name registered in a service grid by a second micro service, the service domain name is resolved based on a service list in a local cache to obtain an IP address of the second micro service, the service list is synchronously obtained from a control plane of the service grid, and finally the IP address is returned to the first micro service so that the first micro service accesses the second micro service in the service grid based on the IP address. In this way, since the control plane of the service grid can be adapted to different registration centers, the service list synchronously obtained from the control plane of the service grid can include the corresponding relationship between the service domain name and the IP address of the micro-service registered by the different registration centers, so that flexible expansion of various registration centers can be supported when the service domain name in the service grid is analyzed, and decoupling with the PaaS deployment platform is realized.
In some embodiments, referring to fig. 4, fig. 4 is an optional flowchart of the service domain name resolution method based on the service grid provided in the embodiment of the present application, and based on fig. 3, the method may further perform the following steps S401 to S402, where an execution subject of the following steps may be the foregoing service name resolution service.
In step S101, the service name resolution service receives a service name resolution request sent by a first microservice; and the service name resolution request comprises a service domain name registered in the service grid by the second micro service.
In step S102, the service domain name is resolved based on the service list in the local cache, so as to obtain the IP address of the second microservice; wherein the service list is obtained from a control plane of the service grid in synchronization.
In step S103, the IP address is returned to the first microservice, so that the first microservice accesses the second microservice in the service grid based on the IP address.
In step S401, when it is determined that the correspondence relationship between the service domain name and the IP address registered in the service grid is changed, a pair of the changed service domain name and IP address is acquired.
Here, the IP addresses of the micro-services and the micro-services registered in the grid service are dynamically changed, and the correspondence between the registered service domain name and the IP address is also changed accordingly. The change of the correspondence between the service domain name and the IP address registered in the service grid may include, but is not limited to, one or more of addition, deletion, modification of the service domain name, addition, deletion, modification of the IP address, and the like. Whether the corresponding relation between the service domain name and the IP address registered in the service grid is changed or not can be determined in a monitoring or polling mode.
In step S402, the service list is updated based on the pair of the changed service domain name and IP address.
Here, the service list may include at least one group of service domain name and IP address pairs, and the service domain name and IP address pairs in the service list may be updated, such as added, deleted, and modified, based on the changed service domain name and IP address pairs.
It should be noted that the above step S401 is not limited to the execution sequence shown in fig. 4, and for example, the steps S401 to S402 may be executed before the step S101.
In the embodiment of the application, under the condition that the corresponding relation between the service domain name and the IP address registered in the service grid is determined to be changed, the changed service domain name and IP address pair is obtained, and the service list is updated based on the changed service domain name and IP address pair. Therefore, the validity of the corresponding relation between the service domain name and the IP address in the service list during service domain name resolution can be ensured, and the normal access between the micro services can be ensured.
In some embodiments, referring to fig. 5, fig. 5 is an optional flowchart of the service domain name resolution method based on the service grid according to the embodiment of the present application, and based on fig. 4, step S401 may include at least one of the following steps S501 and S502. As will be described below in conjunction with various steps, the execution subject of the following steps may be the foregoing service name resolution service.
In step S101, the service name resolution service receives a service name resolution request sent by a first microservice; and the service name resolution request comprises a service domain name registered in the service grid by the second micro service.
In step S102, the service domain name is resolved based on the service list in the local cache, so as to obtain the IP address of the second microservice; wherein the service list is obtained from a control plane of the service grid in synchronization.
In step S103, the IP address is returned to the first microservice, so that the first microservice accesses the second microservice in the service grid based on the IP address.
In step S501, when it is monitored that the correspondence between the service domain name and the IP address found by the control plane is changed, a pair of the service domain name and the IP address that are changed is obtained from the control plane.
Here, the control plane may perform service discovery on the micro-service deployed in the service grid, obtain a service domain name and an IP address of the discovered micro-service, and update a correspondence between the discovered service domain name and the IP address based on a result of the service discovery. The service name resolution service can monitor whether the corresponding relation between the service domain name and the IP address found by the control surface is changed, and when the change is monitored, the service domain name and the IP address pair which are changed are obtained from the control surface, and the service list is updated based on the obtained service domain name and IP address pair.
In step S502, at least one set of service domain name and IP address configured by the user is obtained from the external service name configuration system, and based on the at least one set of service domain name and IP address configured by the user, a pair of the service domain name and IP address that is changed in the service list is determined.
Here, the external service name configuration system is an application or system that is external to the service grid and provides a configuration service for a service domain name and an IP address of a microservice registered in the service grid. The user may configure the service domain name and IP address of the microservices registered in the service grid at an external service name configuration system. In implementation, the service name resolution service may obtain at least one set of service domain name and IP address configured by the user from an external service name configuration system, and may determine a service domain name and IP address pair changed in the service list by comparing a service domain name and IP address pair in the service list with the at least one set of service domain name and IP address configured by the user.
In step S402, the service list is updated based on the pair of the changed service domain name and IP address.
In the embodiment of the application, whether the corresponding relationship between the service domain name and the IP address found by the control plane is changed or not can be monitored to acquire the changed service domain name and IP address pair from the control plane, and the changed service domain name and IP address pair in the service list can be determined by acquiring the corresponding relationship between the service domain name and the IP address configured by the user from an external service name configuration system. Therefore, the changed service domain name and IP address pair can be simply and effectively obtained, and the validity of the corresponding relation between the service domain name and the IP address in the service list during service domain name resolution is ensured.
In some embodiments, referring to fig. 6, fig. 6 is an optional flowchart of the service domain name resolution method based on the service grid according to the embodiment of the present application, and based on fig. 3, step S102 may be implemented by steps S601 to S603 as follows. As will be described below in conjunction with the steps, the execution subject of the steps described below may be the foregoing service name resolution service.
In step S101, the service name resolution service receives a service name resolution request sent by a first microservice; and the service name resolution request comprises a service domain name registered in the service grid by the second micro service.
In step S601, based on the service domain name, a service list in a local cache is queried.
In step S602, if the IP address corresponding to the service domain name is not found in the service list, the service name resolution request is forwarded to a set external service name resolution service.
Here, the external service name resolution service may be another service name resolution service different from the current service name resolution service, may be configured by a user, may be default, and is not limited herein. The external service name resolution service may be a standby service name resolution service, and when the IP address corresponding to the service domain name is not queried in the service list of the current service name resolution service, the external service name resolution service may forward the service name resolution request to the external service name resolution service.
In step S603, an IP address of the second microservice returned by the external service name resolution service is received.
Here, after the external service name resolution service resolves the service domain name of the second micro service in the service name resolution request, the IP address of the second micro service may be obtained and returned.
In step S103, the IP address is returned to the first microservice, so that the first microservice accesses the second microservice in the service grid based on the IP address.
In the embodiment of the application, when the IP address corresponding to the service domain name is not queried in the service list of the current service name resolution service, the service name resolution request can be forwarded to the external service name resolution service, and the IP address of the second micro service returned by the external service name resolution service is obtained. Therefore, the external service name resolution service can be used as a standby service name resolution service, the success rate of service domain name resolution is improved, and normal access among micro services is further ensured.
In some embodiments, referring to fig. 7, fig. 7 is an optional flowchart of the service domain name resolution method based on the service grid according to the embodiment of the present application, based on fig. 3, the method may further perform the following steps S701 to S702, which will be described below with reference to the steps, and an execution subject of the following steps may be the foregoing service name resolution service.
In step S102, the service domain name is resolved based on the service list in the local cache, so as to obtain the IP address of the second microservice; wherein the service list is obtained synchronously from a control plane of the service grid.
In step S103, the IP address is returned to the first microservice, so that the first microservice accesses the second microservice in the service grid based on the IP address.
In step S701, when the service name resolution service is started, the currently found full number of pairs of service domain names and IP addresses are obtained from the control plane.
In step S702, the full number of pairs of service domain names and IP addresses are added to the service list, and the service list is cached in a local cache.
In the embodiment of the application, when the service name resolution service is started, the currently found full service domain name and IP address pairs are obtained from the control plane, and after the full service domain name and IP address pairs are added to the service list, the service list is cached in the local cache. Thus, the initialization of the service list at the start of the service name resolution service can be simply and quickly realized.
Next, an exemplary application of the embodiment of the present application in a practical application scenario will be described. The embodiment of the application provides a distributed DNS architecture based on service discovery, which improves and optimizes the architecture of a service domain name resolution scheme adopted in a service grid in the related technology, and can realize service domain name resolution based on the service grid on the basis of not influencing the original core resolution capability. The application of the distributed DNS architecture is as follows: in a service grid, when an upstream service accesses a downstream service through a service domain name, the service domain name needs to be addressed (namely domain name resolution), the domain name resolution of the downstream service name is completed through a distributed DNS service based on service discovery, the DNS service is a stateless distributed service deployed together with the upstream service, a downstream service list is automatically synchronized through linkage with a registry of a PaaS platform, the downstream service name in the registry is resolved into a specific IP address and returned to the upstream service, and the upstream service accesses the downstream service according to the specific IP address. For downstream service names that are not at the registry, the domain name resolution request is forwarded to the system-configured DNS service.
The distributed DNS service provided by the embodiment of the application is irrelevant to a PaaS platform deployed by each service in a service grid, is suitable for deployment scenes of bare metal servers, virtual machines and containers, can be used as a supplementary component of a data plane of the service grid, is deployed together with other data plane components, and can be managed by a pilot-agent component of the data plane in a life cycle. Referring to fig. 8, fig. 8 is a schematic diagram of an overall architecture of a distributed DNS service applied in a service grid according to an embodiment of the present application, where the service grid includes a control plane 810 and a data plane 820, the control plane 810 may be adapted to a plurality of different registration centers 830 such as kubenets, consul, etcd, and the like through a control plane component (e.g., a pilot-discovery component), the data plane 820 may include a data plane node 821 and a data plane node 822, the data plane node 821 includes a pilot-agent component 821-1 and an envoy component 821-2, where the pilot-agent component 821-1 and the envoy component 821-2 may be disposed in a container 831, a DNS service node (sidecar-DNS) 841) of the distributed DNS service may also be disposed in a container 831, an application (i.e., service) 851 associated with the data plane node 821 is disposed in a container 832, and the container 831 and the container 832 may be collectively disposed in the container 830; the data plane node 822 includes a pilot-agent component 822-1, an envoy component 822-2, a DNS service node (sidecar-DNS) 842 for distributed DNS services, and a deployment of applications 852 associated with the data plane node 822 may be deployed in a virtual machine or bare metal server 860.
Referring to fig. 9, fig. 9 is a schematic diagram illustrating an implementation process of a service domain name resolution method based on a service grid according to an embodiment of the present application, as shown in fig. 9, a distributed DNS service sidecar-DNS 910 in the process includes three components, that is, a DNS-controller 911, a service-cache 912, and a DNS-server 913, and based on the three components, the method may implement the following processes:
1) The dns-controller component 911 module in the sidecar-dns 910 is responsible for interacting with the pilot-discovery component 920 of the service grid control plane, monitoring and synchronizing changes of the service list in the pilot-discovery component 920; here, the change of the service list is mainly the addition and deletion of the service, the pilot-discovery component 920 is a control plane component of the service grid, and can adapt to various different registration centers, such as kubenets, consul, zookeeper, and the like, and synchronize the service list from the registration centers;
2) The dns-controller component 911 receives the service list change of the pilot-discovery component 920, updates the changed service list into the service-cache component 912, the service-cache component 912 caches and records all the service lists, and the sidecar-dns 910 automatically synchronizes the full service list from the pilot-discovery component 920 and caches the full service list into the service-cache when starting.
3) The DNS-server component 913 provides DNS service to the outside, receives a DNS resolution request of the local application 930, and the DNS-server component 913 searches whether a service name to be resolved exists from the service-cache component 912, and returns a specific IP to the application 930 if the service name exists; if not, the DNS resolution request is forwarded to an external DNS service 940, and the result of the resolution is returned to the application 930.
In the embodiment of the application, the service domain name resolution based on the service grid can be realized, and the following effects can be achieved:
1) Each DNS service node in the distributed DNS architecture is in butt joint with a control surface component pilot-discovery of the service grid, a service list is synchronized from the pilot-discovery component, and the pilot-discovery component realizes adaptation to various registration centers and supports flexible extension;
2) Each DNS service node in the distributed DNS architecture is deployed together with a service grid data surface node, and a set of DNS cluster does not need to be additionally deployed and maintained, so that the resource cost and the operation and maintenance cost brought by independent management of the DNS cluster are saved for a user;
3) Each data plane node is provided with one DNS service node, so that the local application is only influenced when a single DNS service node is unavailable, the service name analysis of other data plane nodes is not influenced, the fault influence range can be greatly reduced when a fault occurs, and the availability of the whole DNS service is improved;
4) The data plane node and the DNS service run in the same host or POD, and the service name resolution delay is greatly reduced based on local network communication;
5) The DNS service node on each data plane node only processes local service name resolution requests, and the pressure is much lower than that of centralized DNS service, so the performance is much higher, and a performance bottleneck is not likely to occur.
In some embodiments, a centralized cluster deployment mode may be further adopted to deploy the DNS service, and the pilot-discovery component is docked by the DNS service, so that decoupling from the PaaS deployment platform is achieved. In other embodiments, a local DNS service may be further customized, resolution of a domain name of the service is achieved, and mapping between the domain name and a corresponding IP address may be achieved by interfacing an external control center (e.g., an external DNS configuration system, a database, etc.), and the external control center may dynamically configure mapping between a domain name list and a corresponding IP address.
Continuing with the exemplary structure of the service grid-based service domain name resolution device 255 provided by the embodiment of the present application implemented as software modules, in some embodiments, as shown in fig. 2, the software modules stored in the service grid-based service domain name resolution device 255 of the memory 250 may include:
a receiving module 2551, configured to receive, by the service name resolution service, a service name resolution request sent by the first microservice; the service name resolution request comprises a service domain name registered in a service grid by the second micro service;
the resolving module 2552 is configured to resolve the service domain name based on a service list in a local cache, so as to obtain an IP address of the second micro service; wherein the service list is obtained from a control plane of the service grid in synchronization;
a returning module 2553, configured to return the IP address to the first microservice, so that the first microservice accesses the second microservice in the service grid based on the IP address.
In some embodiments, the service name resolution service is deployed in a data plane of the service grid in a distributed deployment manner, and the receiving module is further configured to: the service name resolution service receives a service name resolution request sent by a first micro service deployed in the local.
In some embodiments, the first microservice is deployed in an application container, the service name resolution service and a data plane component of the service grid are deployed in a proxy container, the proxy container and the application container share a same local network; or the first micro-service, the service name resolution service and the data plane component of the service grid are deployed in the same host together.
In some embodiments, the apparatus further comprises: a first obtaining module, configured to obtain a pair of a service domain name and an IP address that are changed when it is determined that a correspondence between the service domain name and the IP address registered in the service grid is changed; and the updating module is used for updating the service list based on the changed service domain name and IP address pair.
In some embodiments, the first obtaining module is further configured to at least one of: acquiring a service domain name and IP address pair which is changed from the control surface under the condition that the corresponding relation between the service domain name and the IP address which is discovered by the control surface is monitored to be changed; and acquiring at least one group of service domain name and IP address configured by a user from an external service name configuration system, and determining a service domain name and IP address pair which is changed in the service list based on the at least one group of service domain name and IP address configured by the user.
In some embodiments, the parsing module is further to: based on the service domain name, inquiring a service list in a local cache; under the condition that the IP address corresponding to the service domain name is not inquired in the service list, forwarding the service name resolution request to a set external service name resolution service; and receiving the IP address of the second micro service returned by the external service name resolution service.
In some embodiments, the apparatus further comprises: a second obtaining module, configured to obtain, from the control plane, a total number of currently-discovered service domain name and IP address pairs when the service name resolution service is started; and the cache module is used for adding the total service domain name and IP address pairs to the service list and caching the service list into a local cache.
Embodiments of the present application provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions, so that the computer device executes the service domain name resolution method based on the service grid according to the embodiment of the present application.
Embodiments of the present application provide a computer-readable storage medium storing executable instructions, which when executed by a processor, will cause the processor to perform a service grid-based service domain name resolution method provided by embodiments of the present application, for example, the method shown in fig. 3.
In some embodiments, the computer-readable storage medium may be memory such as FRAM, ROM, PROM, EP-ROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories.
In some embodiments, the executable instructions may be in the form of a program, software module, script, or code written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
By way of example, executable instructions may, but need not, correspond to files in a file system, and may be stored in a portion of a file that holds other programs or data, such as in one or more scripts in a hypertext Markup Language (H-TML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code).
By way of example, executable instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network.
In summary, according to the embodiments of the present application, flexible extension of various registration centers can be supported when a service domain name in a service grid is analyzed, so as to implement decoupling from a PaaS deployment platform.
The above description is only an example of the present application, and is not intended to limit the scope of the present application. Any modification, equivalent replacement, and improvement made within the spirit and scope of the present application are included in the protection scope of the present application.
Claims (10)
1. A service domain name resolution method based on a service grid is characterized by comprising the following steps:
the service name resolution service receives a service name resolution request sent by the first micro service; the service name resolution request comprises a service domain name registered in a service grid by the second micro service;
analyzing the service domain name based on a service list in a local cache to obtain an IP address of the second micro service; wherein the service list is obtained from a control plane of the service grid in synchronization;
returning the IP address to the first microservice to cause the first microservice to access the second microservice in the service grid based on the IP address.
2. The method according to claim 1, wherein the service name resolution service is deployed in a data plane of the service grid in a distributed deployment manner, and the service name resolution service receives a service name resolution request sent by a first microservice, and includes:
the service name analysis service receives a service name analysis request sent by a first micro service deployed in the local.
3. The method of claim 2,
the first micro-service is deployed in an application container, the service name resolution service and a data plane component of the service grid are deployed in a proxy container, and the proxy container and the application container share the same local network;
or the first micro-service, the service name resolution service and the data plane component of the service grid are deployed in the same host together.
4. The method of any of claims 1 to 3, further comprising:
under the condition that the corresponding relation between the service domain name and the IP address registered in the service grid is determined to be changed, acquiring a changed service domain name and IP address pair;
and updating the service list based on the changed service domain name and IP address pair.
5. The method according to claim 4, wherein, in a case that it is determined that the correspondence relationship between the service domain name and the IP address registered in the service grid occurs, acquiring the changed service domain name and IP address pair includes at least one of:
acquiring a service domain name and IP address pair which is changed from the control surface under the condition that the corresponding relation between the service domain name and the IP address which is discovered by the control surface is monitored to be changed;
and acquiring at least one group of service domain name and IP address configured by a user from an external service name configuration system, and determining a service domain name and IP address pair which is changed in the service list based on the at least one group of service domain name and IP address configured by the user.
6. The method according to any one of claims 1 to 3, wherein the resolving the service domain name based on the service list in the local cache to obtain the IP address of the second microservice comprises:
based on the service domain name, inquiring a service list in a local cache;
under the condition that the IP address corresponding to the service domain name is not inquired in the service list, forwarding the service name resolution request to a set external service name resolution service;
and receiving the IP address of the second micro service returned by the external service name resolution service.
7. The method of any of claims 1 to 3, further comprising:
when the service name resolution service is started, acquiring the currently found full service domain name and IP address pairs from the control plane;
and adding the full service domain name and IP address pair to the service list, and caching the service list into a local cache.
8. A service domain name resolution device based on a service grid, comprising:
the receiving module is used for receiving a service name analysis request sent by the first micro service by the service name analysis service; the service name resolution request comprises a service domain name registered in a service grid by the second micro service;
the resolution module is used for resolving the service domain name based on a service list in a local cache to obtain an IP address of the second micro service; wherein the service list is obtained from a control plane of the service grid in synchronization;
a return module for returning the IP address to the first micro-service to enable the first micro-service to access the second micro-service in the service grid based on the IP address.
9. A service domain name resolution device based on a service grid, comprising:
a memory for storing executable instructions;
a processor for implementing the method of any one of claims 1 to 7 when executing executable instructions stored in the memory.
10. A computer-readable storage medium having stored thereon executable instructions for, when executed by a processor, implementing the method of any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110367382.1A CN115190103A (en) | 2021-04-06 | 2021-04-06 | Service grid-based service domain name resolution method, device and equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110367382.1A CN115190103A (en) | 2021-04-06 | 2021-04-06 | Service grid-based service domain name resolution method, device and equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115190103A true CN115190103A (en) | 2022-10-14 |
Family
ID=83511359
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110367382.1A Pending CN115190103A (en) | 2021-04-06 | 2021-04-06 | Service grid-based service domain name resolution method, device and equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115190103A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117221276A (en) * | 2023-09-26 | 2023-12-12 | 福州大学 | Network architecture and server layer structure of geospatial grid domain name |
| CN117289877A (en) * | 2023-11-23 | 2023-12-26 | 云筑信息科技(成都)有限公司 | Universal file storage dynamic proxy method based on service grid |
-
2021
- 2021-04-06 CN CN202110367382.1A patent/CN115190103A/en active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117221276A (en) * | 2023-09-26 | 2023-12-12 | 福州大学 | Network architecture and server layer structure of geospatial grid domain name |
| CN117289877A (en) * | 2023-11-23 | 2023-12-26 | 云筑信息科技(成都)有限公司 | Universal file storage dynamic proxy method based on service grid |
| CN117289877B (en) * | 2023-11-23 | 2024-03-19 | 云筑信息科技(成都)有限公司 | Universal file storage dynamic proxy method based on service grid |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106790595B (en) | Docker container active load balancing device and method | |
| US11765110B2 (en) | Method and system for providing resiliency in interaction servicing across data centers | |
| EP3886399A1 (en) | Method for invoking server and proxy server | |
| CN107667517B (en) | Implanted agent within a first service container for enabling reverse proxy on a second container | |
| EP2901308B1 (en) | Load distribution in data networks | |
| US7987266B2 (en) | Failover in proxy server networks | |
| CN113572831B (en) | Communication method, computer equipment and medium between Kubernetes clusters | |
| WO2009098909A1 (en) | Virtual appliance assignment system | |
| CN113746887A (en) | Cross-cluster data request processing method, device and storage medium | |
| JP2010518490A (en) | Synchronization framework for irregularly connected applications | |
| US10069941B2 (en) | Scalable event-based notifications | |
| CN107210924B (en) | Method and apparatus for configuring a communication system | |
| JP4637366B2 (en) | Data network load management | |
| CN107172214B (en) | Service node discovery method and device with load balancing function | |
| CN115190103A (en) | Service grid-based service domain name resolution method, device and equipment | |
| CN111404628B (en) | Time synchronization method and device | |
| CN112565406B (en) | Gray release method, gray release system and electronic equipment | |
| CN115086312A (en) | Method and system for realizing kubernets service cross-cluster communication | |
| CN113079098B (en) | Method, device, equipment and computer readable medium for updating route | |
| CN116016667A (en) | Unified management method and system for multiple types of registries of cloud native platform | |
| CN115242882B (en) | Method and device for accessing k8s container environment based on transport layer route | |
| CN112351114B (en) | Information processing method and device and storage medium | |
| CN112702441B (en) | Container-based access data processing method, device, system and storage medium | |
| US10348673B2 (en) | Management server system, system, method of system, and storage medium | |
| CN116506404A (en) | Domain name resolution method, device, computer equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |