Shulou(Shulou.com)05/31 Report--

This article mainly explains "what the Dubbo application-level service is like". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what the Dubbo application-level service is like".

Kubernetes is the most popular container service platform in the world. In the Kubernetes cluster, the deployment of Dubbo applications often requires the help of a third-party registry to achieve service discovery. The combination of Dubbo and Kubernetes scheduling system can greatly reduce the operation and maintenance costs that originally need to manage the two platforms, and Dubbo adapting to Kubernetes native services can also make the framework itself more integrated into the cloud native system. The new application-level service discovery model based on Dubbo 3.0 makes it easier to align the service model of Kubernetes.

Kubernetes Native Service

In Kubernetes, Pod is the smallest deployable cell that can be created and managed in Kubernetes. Usually an Pod consists of one or more containers, and applications are deployed in containers.

For a group of Pod,Kubernetes with the same function, the abstraction of such a set of Pod policies is defined through the concept of Service, that is, Kubernetes Service. These Pod tagged by Kubernetes Service are generally determined by Label Selector.

In Kubernetes Service, the service node is called Endpoint, and these Endpoint are the corresponding application units that provide services, usually one-to-one corresponding to Pod.

Therefore, we can schedule the applications in micro-services using Service, and the calls between micro-services realize service discovery through a series of mechanisms of Service, and then integrate micro-services into the Kubernetes Service system.

Dubbo Application level Service Discovery

Within the Dubbo architecture, in order to better conform to the programming habits of Java developers, the underlying Dubbo uses interface granularity as the registered object. But this model is very different from the mainstream Spring Cloud registration model and Kubernetes Service registration model.

At present, the registration model outside the non-Dubbo system mainly takes the service granularity as the registration object. In order to break through the registration discovery barrier between Dubbo and other systems, Dubbo introduced the architecture of service introspection after version 2.7.5, mainly through metadata services to achieve the transition from service granularity to interface granularity. From version 2.7.5 to version 3.0, the service introspection model has been optimized in many aspects and verified in a production environment.

1. Metadata service

Metadata service mainly stores the mapping relationship between service (Instance) and interface (Interface). By abstracting the interface information originally written to the registry to metadata for storage, on the one hand, it can greatly reduce the amount of data stored in the registry and reduce the network communication pressure of the cluster when the service is updated, on the other hand, it realizes the goal of storing only application granularity information at the registry level, and aligns other registration models.

In the service introspection model, the service provider not only writes information about the current instance to the registry, but also writes exposed service URL information to (local or remote) metadata services. For the service consumer, after obtaining the instance information from the registry, the metadata service needs to obtain the service URL information of the service provider (through the RPC request built-in or centralized configuration center) to generate the interface information under the interface granularity architecture.

2. Revision information

Revision information is a data caching mechanism introduced by metadata service. For the same group of applications, the exposed interface is actually the same in many cases, and there will be a lot of redundant data when mapping between service (Instance) and interface (Interface), so you can add the version number to the instance itself in a way similar to MD5 calculation of metadata information. If the version numbers of multiple instances are the same, it can be considered that their metadata information is also the same, then only one instance needs to be randomly selected to obtain the metadata information. It is possible to compress the traffic from a group of instances that need to communicate with only one instance.

As shown in the figure above, the working mechanism of the service consumer registry can be summarized as follows:

The service consumer obtains a list of service instances from the registry.

The registry returns service instance information to the service consumer, including the Revision parameters written by the service provider to the registry in the instance list.

Service consumers are grouped according to the Revision parameters of the instance information, and randomly select one of each group of instances to obtain metadata services.

The service consumer initiates the call through RPC or obtains the metadata information of the specified instance through the configuration center.

The service consumer constructs the service information of the interface granularity according to the acquired metadata information.

For more information on application-level service discovery, please refer to: "Dubbo takes an important step in Cloud Native-Application-level Service Discovery Resolution"

Docking implementation mode

There are two ways to connect with Kubernetes this time, one is to obtain information in the form of Kubernetes API Client, and the other is to obtain information in the form of DNS Client.

1. Kubernetes API Client

The core of the Kubernetes control plane is that API Server,API Server provides HTTP API for users, different parts of the cluster, and external components of the cluster to communicate with each other. For Dubbo, it is possible to communicate with the Kubernetes control plane by using Kubernetes API Client.

1) Provider side details

According to the Dubbo application-level service discovery model mentioned earlier, the Provider side needs to write Revision information to the registry when the application is started and the interface is updated, so the general logic is shown in the figure above.

Label tags match Service as Selector, while Revision and other information are mainly stored in Annotation, in which Revision information needs to be actively written to Kubernetes API Server by the Dubbo application, which also corresponds to the process of service registration.

In the current version of the implementation, the creation of Kubernetes Service is left to the operation and maintenance side, that is, Label Selector is managed by the operation and maintenance side, which is configured before the Dubbo application is launched, and the name of Service is the Services field in the corresponding API notes (this field is manually configured at the interface level if it does not depend on any third-party configuration center).

2) Consumer side details

The logic of the Consumer side is roughly the same as that of the application-level service discovery model. After obtaining the service information through API, the ServiceInstance information is made up by obtaining the Annotation information of the corresponding Pod, and the subsequent logic is consistent with the service introspection.

3) advantages and disadvantages

It should be pointed out that there are certain security risks in allowing the application itself to interact directly with the API of the Kubernetes management platform, and it is possible to bring down the entire Kubernetes cluster if it is not configured properly.

When you apply a large number of updates, it will put some pressure on Kubernetes API Server.

This scheme directly connects the service discovery process of Dubbo to the management of Kubernetes cluster, which can further simplify the complexity of management in Kubernetes environment.

2. DNS Client

Kubernetes DNS is a mechanism provided by Kubernetes to obtain Kubernetes Service information through DNS query, and the node information of the service can be obtained through ordinary DNS requests.

1) fully decentralized metadata service

Due to the limitation of DNS protocol, there is not a unified and simple way to attach more information to DNS for writing Revision information. For the implementation of DNS, we have modified the metadata service so that it is no longer strongly dependent on writing Revision information to the registry, and we only need to know the IP of the Dubbo application to achieve the normal service discovery function.

The modified metadata service can be divided into two functions, one is the ability to obtain URL information based on revision, and the other is the ability to obtain corresponding revision. After obtaining the instance IP through the registry, the Dubbo service consumer will take the initiative to connect with the metadata service of each instance. After obtaining the revision information, the instance with the same revision information will randomly select one to obtain the complete metadata information. As the Revision information is obtained in a peer-to-peer way, when this information is updated, it should be notified to the consumer side to update. In the current version of the implementation, we rely on the parameter callback mechanism to enable the server to actively push to the consumer. In the future, streaming will be implemented based on the new 3. 0 Triple protocol.

2) Provider side details

Similar to the Kubernetes API Client implementation, the process of building the service needs to be carried out by the operation and maintenance side. When the service provider starts, it will cache the metadata information locally and expose the mechanism of the metadata service interface.

It should be noted that in order to decouple the service discovery process from the business service itself, the corresponding ports of the metadata service interface and the business interface may be inconsistent. When using the DNS implementation scheme, the metadata service ports of all applications in the full cluster need to be unified and configured through metadataServicePort parameters. This can also be adapted to DNS that does not support access to ports through SRV.

3) Consumer side details

For the DNS registry, the process of obtaining instances is mainly obtained by issuing A (or AAAA) query requests to DNS, and Kubernetes DNS also provides SRV record requests to obtain service information.

Combined with the fully decentralized metadata service mechanism mentioned earlier, Consumer will actively connect to the metadata service of each instance to obtain the corresponding Revision information, and submit a callback function to the provider in the form of parameter callback to update local information.

After obtaining the Revision information, for the instances with the same Revision information, Dubbo will randomly select one of them to obtain the complete metadata information, and thus complete the whole process of service discovery.

4) advantages and disadvantages

Compared with the former scheme, this scheme avoids the direct interaction of Kubernetes API and the security problem of interaction.

Because DNS does not have the notification mechanism like API Watch, it can only use polling to determine the change of the service. When the change is not applied, there is still a certain amount of DNS network query pressure in the cluster.

The design goal of this scheme is to adapt to any DNS that can obtain the IP of the Dubbo application itself through A (or AAAA) query, and is not strongly dependent on Kubernetes DNS.

Thank you for your reading, the above is the content of "what is the Dubbo application-level service?" after the study of this article, I believe you have a deeper understanding of how the Dubbo application-level service is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.