Proxyless Mesh Practice in Dubbo

Related Tags：1.Alibaba Cloud Service Mesh
2. Simplified Management with Service Mesh

Background

With the release of Dubbo 3.1, Dubbo has taken another important step on the road of cloud native. In this version, a new feature of Proxyless Mesh is added. Dubbo Proxyless Mesh directly implements the xDS protocol resolution, realizes the direct communication between Dubbo and the Control Plane, thus realizing the unified control of traffic control, service governance, observability, security, etc., and avoiding the performance loss and deployment architecture complexity caused by the Sidecar mode.

What is a Service Mesh?

Service Mesh is also translated as "service grid", which is used as the infrastructure layer for inter service communication. In his article "WHAT'S A Service Mesh? AND WHY DO I NEED ONE?", William Morgan, CEO of Buoyant, explained what is a service mesh and why cloud native applications need a service mesh.

The following is William Morgan's explanation of Service Mesh:

A Service Mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the Service Mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

Translated into Chinese:

Service Grid is the infrastructure layer for handling communication between services. It is responsible for composing the complex service topology of modern cloud native applications to reliably deliver requests. In practice, the Service Mesh is usually implemented in the form of a lightweight network proxy array. These proxies are deployed together with the application code, and the application does not need to be aware of the existence of the proxy.

When it comes to service mesh, the classic architecture mode of Sidecar must be indispensable. It takes over the communication traffic of the business container by injecting the Sidecar container into the business pod. At the same time, the Sidecar container is connected with the control plane of the grid platform. Based on the policies issued by the control plane, it implements governance and control on the agent traffic, and lowers the governance capability of the original service framework to the Sidecar container, thus realizing the sinking of the basic framework capability and decoupling from the business system.

The classic Sidecar Mesh deployment architecture has many advantages, such as smooth upgrade, multilingualism, small business intrusion, etc., but it also brings some additional problems, such as:

• The performance loss caused by proxy will become especially obvious in network calls with complex topology

• Architecture complexity caused by traffic interception

• Sidecar lifecycle management

• The deployment environment is limited. Not all environments meet the Sidecar traffic interception conditions

With regard to the problem of Sidecar Mesh model, Dubbo community has long ago made Dubbo's assumption and thinking about direct access to the control plane, and has taken the lead in proposing the concept of Proxyless Mesh in the domestic open source community. Of course, as far as the concept of Proxyless is concerned, it was first proposed by Google.

Dubbo Proxyless Mesh

Dubbo Proxyless mode refers to Dubbo's ability to directly communicate with Istiod and realize service discovery and service governance through xDS protocol.

Proxyless mode makes microservices return to the deployment architecture of the 2. x era, which is very similar to Dubbo's classic service governance model. Therefore, this model is not new. Dubbo has been such a design model since the beginning. This can greatly improve application performance and reduce network latency. Some people say that this approach answers the original SDK based microservice model. In fact, it does not. It still uses the xDS API of Envoy, but because it no longer needs to inject a Sidecar proxy into the application, it can reduce the loss of application performance.

Tips: The corresponding discovery service and its corresponding API are called xDS

However, compared with the Mesh architecture, Dubbo's classic service governance model does not emphasize the unified control of the control surface, which is exactly what Service Mesh emphasizes. It emphasizes the standardized control and governance of traffic, observability, certificates, etc. It is also the place where the concept of Mesh is advanced.

In the Dubbo Proxyless architecture mode, Dubbo processes will directly communicate with the control surface, and Dubbo processes will continue to maintain the direct communication mode. We can see the advantages of the Proxyless architecture:

• No additional proxy transfer loss, so it is more suitable for performance sensitive applications

• More conducive to smooth migration of legacy systems

• Simple architecture, easy operation, maintenance and deployment

• Suitable for almost all deployment environments

Service Discovery

The XDS access is connected in the mode of the registry. The node finds that, like the service introspection model of other registries, the load balancing and routing configurations of the XDS are transferred out through the dynamic runtime configuration of the ServiceInstance, and the configuration parameters are transferred to the configuration address when building the Invoker.

Certificate Management

Under the zero trust architecture, it is necessary to strictly distinguish the identification and trust of workloads, and issuing X.509 certificates is a recommended authentication method. In the Kubernetes cluster, services access each other through DNS names, while network traffic may be hijacked by means of DNS spoofing, BGP/route hijacking, ARP spoofing, etc. In order to strongly associate the service name (DNS name) with the service identity, Istio uses the security naming mechanism placed in the X.509 certificate. SPIFFE is the security naming specification adopted by Istio. It is also a standardized and portable workload identity specification defined by the cloud native definition.

Secure Production Identity Framework For Everyone (SPIFFE) is a set of standards For mutual identification between services, mainly including the following:

• SPIFFE ID standard, SPIFFE ID is the unique identification of the service, and the specific implementation uses URI resource identifier

• SPIFFE Verifiable Identity Document (SVID) standard, encoding SPIFFE ID into an encrypted and verifiable data format

• API standards for issuing and revoking SVIDs (SVIDs are identification credentials for SPIFFE IDs)



SPIFFE ID specifies the URI format in the form of spife:///as the unique identifier of the workload. However, Istio only uses SPIFFE ID as the security name in its own ecology, and its data format is implemented by itself. The communication format adopts the xDS protocol specification supported by CNCF (certificate authentication communication is more specifically the SDS of xDS).

Istio uses the SPIFFE ID in a specific format as the security name and injects it into the subjectAltName extension of the X.509 certificate. Where the "trust_domain" parameter passes the Istiod environment variable TRUST_ DOMAIN injection is used to interact in a multi cluster environment.

Specific formats are as follows:

spiffe:///ns//sa/

The following is the process of issuing the Dubbo Proxyless Mesh certificate:

• Create an RSA private key

• Build CSR (Certificate signing request) template

• Self signed CSR generation certificate

• Create Kubernetes Secret resource to store CA certificate and private key (processed by CA Service)

Case Practice

Next, I will lead you to use an example to make existing projects run quickly in Proxyless Mesh mode.

Environmental preparation

• Install Docker

https://www.docker.com/

• Install minicube

Recommended wall crack:

https://kubernetes.io/zh-cn/docs/tutorials/hello-minikube/

• Install isio

https://istio.io/latest/docs/setup/getting-started/

Note: When installing Istio, you need to enable the first party jwt support (add -- set values. global. jwtPolicy=first party jwt parameter when installing with the istioctl tool), otherwise the client authentication will fail.

Build Image

1. Start Docker

2. Start minicube

Because minihub is a local K8S, it needs a virtual engine to start. Here we use Docker to manage it. We start by the following command

minikube start

We can see minicube in Docker

3. Check the status of isio

4. Build an image

Find the code location locally and execute the following commands in sequence:

#Find the path of the provider

cd ./ dubbo-samples-xds-provider/

#Build the image of the provider

docker build -t apache/dubbo-demo:dubbo-samples-xds-provider_ 0.0.1 .

#Find the path of the consumer

cd ../ dubbo-samples-xds-consumer/

#Build the image of the consumer

docker build -t apache/dubbo-demo:dubbo-samples-xds-consumer_ 0.0.1 .

5. Check the local image

6. Create a namespace

#Initialize namespace

kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/dubbo-samples-xds/deploy/Namespace.yml

#Switch Namespace

kubens dubbo-demo

If you do not create a namespace, you will see the following error:

Deployment Container

#Find the path of the provider

cd ./ dubbo-samples-xds-provider/src/main/resources/k8s

# dubbo-samples-xds/dubbo-samples-xds-provider/src/main/resources/k8s/Deployment.yml

# dubbo-samples-xds/dubbo-samples-xds-provider/src/main/resources/k8s/Service.yml

#Deploy the deployment and service of the provider

kubectl apply -f Deployment.yml

kubectl apply -f Service.yml

#Find the path of the consumer

cd ../../../../../ dubbo-samples-xds-consumer/src/main/resources/k8s

# dubbo-samples-xds/dubbo-samples-xds-consumer/src/main/resources/k8s/Deployment.yml

#Deploy the deployment of the consumer

kubectl apply -f Deployment.yml

We can see the deployed pod on the minicube dashboard

Observe the consumer effect

kubectl logs xxx

result: hello, xDS Consumer! from host: 172.17.0.5

result: hello, xDS Consumer! from host: 172.17.0.5

result: hello, xDS Consumer! from host: 172.17.0.6

result: hello, xDS Consumer! from host: 172.17.0.6

Summary&Outlook

This article mainly analyzes the architecture, service discovery, certificate management and other core processes of Dubbo Proxyless Mesh, and finally demonstrates how to use Dubbo Proxyless through examples.

With the release of Dubbo 3.1, Dubbo has taken another important step on the road of cloud native. At the end of this year, Dubbo Mesh will release a version with service discovery capabilities, which will provide all Dubbo users with the ability to smoothly migrate from a lower version to the Mesh architecture; The version with governance capability will be released in the early spring of next year; By the end of next year, we will release a version with the ability to update hot plug-ins. I hope students who are interested in witnessing Dubbo Cloud's original path can actively participate in community contributions!