Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog High-Performance and User-Friendly HTTP Access with Dubbo3

High-Performance and User-Friendly HTTP Access with Dubbo3

This article explains how Dubbo3's Triple protocol simplifies development, testing, and ingress traffic access with efficient communication and an easy-to-use interface.

By Jun Liu

As an RPC framework, Dubbo is renowned for its efficient communication between backend services and ease of use with well-defined interfaces. However, it required specialized tools or protocol conversions to call backend services, resulting in costly RPC interface testing and frontend traffic integration.

Dubbo 3.3 resolves this issue with the Triple protocol. While maintaining efficient communication and interface usability, it also supports direct HTTP API access with application/json messages, greatly simplifying development testing and reducing the cost of traffic integration.

curl \
    --header "Content-Type: application/json" \
    --data '["Dubbo"]' \
    http://localhost:50051/com.example.demo.dubbo.api.DemoService/sayHello/

This article introduces this new feature using gateway HTTP traffic access as an example.

Implementing HTTP Access for Backend Dubbo Microservices

Regardless of the type of product you're developing, such as e-commerce platforms, management systems, or mobile apps, most products interact with users via HTTP. Users access products using browsers, mobile devices, or desktop software. Therefore, integrating backend Dubbo microservices with frontend access devices by converting HTTP requests to RPC and ensuring seamless connectivity is crucial.

There are two main architecture models: centralized and decentralized. A centralized architecture is more general and doesn't impose many special requirements on backend RPC protocols or frontend gateways. However, ensuring the performance and stability of centralized applications can be challenging. On the other hand, a decentralized architecture doesn't require maintenance of ingress applications, making it suitable for handling higher traffic and larger clusters.

Centralized Access

The architecture for centralized access is as follows:

• A gateway sits between backend services and frontend devices, handling tasks such as filtering, routing, and traffic throttling.

• In the backend cluster, there is a "unified microservice entry application" (often called BFF, or Backend for Frontend) that connects HTTP and Dubbo services.

1

BFF is typically developed with popular frameworks such as Spring Web. The application publishes a series of HTTP services, receives traffic from the gateway or frontend devices, and makes Dubbo calls as needed.

Both Dubbo and Triple protocols support this access architecture. When configuring BFF to call Dubbo services, you can use the standard Dubbo configuration or generic calls:

• When the Dubbo protocol is used, generic calls can avoid dependency on binary packages, and allow dynamic configuration changes.

• When the Triple protocol is used, HTTP calls can also avoid dependency on binary packages and allow dynamic configuration changes.

Decentralized Access

This architecture is similar to the centralized architecture but does not require an additional BFF application. Instead, the gateway directly calls backend Dubbo services.

2

This architecture has specific requirements for the gateway: When the Dubbo protocol is used, the gateway must convert HTTP to Dubbo. However, this conversion can be bypassed by multi-protocol publishing, allowing the gateway to access backend services via HTTP. When the Triple protocol is used, accessing backend services is simpler because the Triple protocol supports HTTP requests in the application/json format.

The choice of RPC protocol affects the architecture. With native support for HTTP access, the Triple protocol supports both centralized and decentralized architectures, and simplifies service access. However, promoted during the Dubbo2 era, the Dubbo protocol is based on a binary TCP protocol, and therefore uses a different access method.

Next, let's move onto the frontend traffic access methods for both Dubbo and Triple protocols. These methods apply to both centralized and decentralized architectures.

Access Methods for Different RPC Protocols

Dubbo Protocol Access Method

The Dubbo protocol is a TCP-based binary protocol; therefore, it is highly efficient for RPC communication between backend microservices. However, this protocol is not frontend-friendly. In the Dubbo framework, there are two solutions to this problem:

• Multi-protocol publishing (recommended): Provide access to Dubbo services over a RESTful HTTP protocol. This method simplifies the architecture and allows the use of standard gateway products.

• HTTP-to-Dubbo conversion: Use a gateway to convert the HTTP protocol to the Dubbo protocol that backend services can understand. This method requires the gateway to support the Dubbo protocol.

Support for both HTTP and Dubbo protocols

If a service supports both Dubbo and HTTP protocols, backend service calls can use the efficient Dubbo binary protocol while frontend components such as browsers and web services can access the same service via HTTP. Fortunately, the Dubbo framework supports multi-protocol publishing, and allows clients to access the service using different protocols on the same port, as shown in the following image:

3

To publish a service that supports both Dubbo and HTTP protocols, add the following code to the configuration file:

dubbo:
  protocol:
    dubbo: dubbo
    port: 20880
    ext-protocol: tri

After ext-protocol: tri is added, the process can provide HTTP services on port 20880. As explained earlier in the content about the Triple protocol, once the application is running, you can access the application on port 20880 using the following code:

curl \
    --header "Content-Type: application/json" \
    --data '["Dubbo"]' \
    http://localhost:20880/org.apache.dubbo.protocol.multiple.demo.DemoService/sayHello

At this point, any HTTP gateway can directly connect to the backend Dubbo service.

For complete sample codes and detailed explanations of multi-protocol publishing with Dubbo and Triple protocols, see the apache/dubbo-samples repository.

If you prefer a RESTful HTTP interface instead of the /org.apache.dubbo.protocol.multiple.demo.DemoService/sayHello path, you can add annotations (supporting Spring Web and JAX-RS) to the interface. For example, if you have a Dubbo service named DemoService, add the following annotation:

@RestController
@RequestMapping("/triple")
public interface DemoService {
    @GetMapping(value = "/demo")
    String sayHello();
}

This approach allows you to publish a service that supports both Dubbo and REST protocols. The service can be easily accessed via HTTP gateways. The only additional effort is adding annotations to the interface.

Once HTTP access is added to a Dubbo service, Dubbo services can be easily integrated with gateways.

HTTP-to-Dubbo Conversion

If you are using Dubbo 3.3.x, we strongly recommend evaluating the multi-protocol publishing solution described in the previous section before considering this option. Unless you cannot accept the modification (which involves just changing one configuration line) required by multi-protocol publishing due to specific reasons, this option should be your second choice.

To access backend Dubbo services via a gateway, HTTP requests from the frontend must be converted to Dubbo requests so that they can be properly processed.

4

As shown in the figure above, HTTP requests sent from browsers, mobile devices, or web servers are converted from Dubbo requests by the gateway. The gateway then forwards the Dubbo protocol to the backend microservice cluster. Therefore, we need a gateway that supports HTTP-to-Dubbo protocol conversion. Here are the key features the gateway must have:

• Protocol conversion: Converts the HTTP protocol to the Dubbo protocol, including parameter mapping.

• Automatic address discovery: Supports mainstream registries such as Nacos, Zookeeper, and Kubernetes to dynamically detect changes in backend Dubbo instances.

• Routing with Dubbo protocol: Supports selecting backend service instances based on specific rules and passing additional parameters to Dubbo backend services when initiating a Dubbo call.

Currently, many open-source gateway products, including Higress, Apache APISIX, and Apache Shenyu, support the Dubbo protocol and provide the above features. Next, let's look at some examples of how to use these gateway products with Dubbo.

• Higress
• Apache APISIX
• Apache Shenyu

Access Methods for Triple Protocol

The Triple protocol specification on the official website outlines its design for compatibility with browsers and gateways. A key feature is Triple's support for both HTTP/1 and HTTP/2:

• Backend services use the efficient Triple binary protocol.

• Then frontend access layer can use standard HTTP tools such as cURL to request backend services in standard application/json format.

Next, we will explore how to quickly connect frontend HTTP traffic with the backend Triple microservice system using common gateway products. Unlike the Dubbo protocol, the Triple protocol eliminates the need for generic calls and HTTP-to-Dubbo protocol conversion. Mainstream gateway devices can directly access backend Triple protocol services over HTTP.

Native HTTP Access

5

As shown in the figure above, HTTP requests from browsers, mobile devices, or web servers can be directly forwarded by the gateway in application/json format to the backend Dubbo services. The backend services use the Triple binary protocol. Since the traffic entering and exiting the gateway is standard HTTP, the gateway does not need to perform any private protocol conversions or custom logic. It only needs to focus on traffic routing.

In a production environment, the only task for the gateway is address discovery, namely, to dynamically detect changes in backend Triple service instances. Fortunately, several mainstream open-source gateway products, such as Apache APISIX and Higress, support upstream data sources such as Nacos, Zookeeper, and Kubernetes.

Below, we use the typical combination of Higress, Nacos, and Dubbo to explain the workflow in detail.

6

Starting the Example Application

For the complete source code for this example, see the dubbo-samples-gateway-higress-triple example in the apache/dubbo-samples repository.

This example defines and publishes a Triple service as org.apache.dubbo.samples.gateway.api.DemoService:

public interface DemoService {
    String sayHello(String name);
}

Next, we will demonstrate how to start the Dubbo service and use the Higress gateway to forward requests to the backend service.

Integrating with the Higress Gateway

We will demonstrate the steps to integrate an application with the Higress gateway, including deploying the Dubbo application, the Nacos registry, and the Higress gateway.

Installing Higress and Nacos

The following example is deployed in a Kubernetes environment, so ensure you are connected to an available Kubernetes cluster.

  1. Install Higress by following the Higress installation guide.
  2. Install Nacos by running the following command:
kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/2-advanced/dubbo-samples-gateway/dubbo-samples-gateway-higress/dubbo-samples-gateway-higress-triple/deploy/nacos/Nacos.yaml

Starting the Dubbo Application

After packaging the example application as a Docker image (we use the pre-packaged official image), start the application as a standard Kubernetes Deployment:

kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/2-advanced/dubbo-samples-gateway/dubbo-samples-gateway-higress/dubbo-samples-gateway-higress-triple/deploy/provider/Deployment.yaml

The deployment file is defined as follows:

apiVersion: apps/v1
kind: Deployment
metadata:
    name: gateway-higress-triple-provider
    namespace: default
    labels:
        app: gateway-higress-triple-provider
spec:
    replicas: 1
    selector:
        matchLabels:
            app: gateway-higress-triple-provider
    template:
        metadata:
            labels:
                app: gateway-higress-triple-provider
        spec:
            containers:
                -   name: gateway-higress-triple-provider
                    image: docker.io/allenyi/higress-triple:2.0.0
                    imagePullPolicy: IfNotPresent
                    ports:
            # Consistent with the port exposed by the container
                        - containerPort: 50052
                    env:
            # Configure the address of the Nacos registry, which corresponds to ${nacos.address:127.0.0.1} in the Dubbo service configuration.
                        - name: NACOS_ADDRESS
                          value: nacos-server.default.svc.cluster.local

Forwarding Requests to the Dubbo Service via Higress

Higress can use McpBridge to connect to Nacos as a service source. Apply the following resource in the Kubernetes cluster to configure McpBridge:

kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/2-advanced/dubbo-samples-gateway/dubbo-samples-gateway-higress/dubbo-samples-gateway-higress-triple/deploy/mcp/mcpbridge.yaml

The McpBridge resource is defined as follows:

apiVersion: networking.higress.io/v1
kind: McpBridge
metadata:
  name: nacos-service-resource
  namespace: higress-system
spec:
  registries:
  - domain: nacos-server.default.svc.cluster.local
    nacosGroups:
    - DEFAULT_GROUP
    name: nacos-service-resource
    port: 8848
    type: nacos2

For more information, see the Higress McpBridge documentation.

Next, create an Ingress to route HTTP requests to the Dubbo service:

kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/2-advanced/dubbo-samples-gateway/dubbo-samples-gateway-higress/dubbo-samples-gateway-higress-triple/deploy/ingress/Ingress.yaml

In this way, requests whose path prefix is /org.apache.dubbo.samples.gateway.api.DemoService will be routed to the Dubbo service we just created.

The Ingress resource is defined as follows:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.io/destination: gateway-higress-triple-provider.DEFAULT-GROUP.public.nacos
  name: demo
  namespace: default # The namespace of the application.
spec:
    ingressClassName: higress
    rules:
        - http:
              paths:
                  - backend:
                        resource:
                            apiGroup: networking.higress.io
                            kind: McpBridge
                            name: default
                    path: /org.apache.dubbo.samples.gateway.api.DemoService
                    pathType: Prefix

The higress.io/destination annotation specifies the target service: gateway-higress-triple-provider, which is the application name of the Dubbo service. (This name relies on the default application-level address list registered by Dubbo3.)

For Nacos services, the target service format is service-name.service-group.namespace-id.nacos. Service group underscores _ are converted to hyphens -, in accordance with the DNS domain name format. The default namespace is public if not specified.

Request Verification

Access the Triple backend service via Higress using cURL:

$ curl "localhost/org.apache.dubbo.samples.gateway.api.DemoService/sayHello?name=HigressTriple"

"Hello HigressTriple"

Run the kubectl port-forward service/higress-gateway -n higress-system 80:80 443:443 command to expose Higress from the cluster.

The /org.apache.dubbo.samples.gateway.api.DemoService/sayHello path directly exposes the Java pathname and method. While it is easy to use, it is not friendly to the frontend. Next, we will demonstrate how to publish RESTful HTTP services.

RESTful Interface

In the previous example, a URL such as http://127.0.0.1:9080/triple/demo/hello is more friendly for frontend access. To achieve this, configure URI rewriting in gateways such as Higress to map frontend requests from /triple/demo/hello to the backend /org.apache.dubbo.samples.gateway.api.DemoService/sayHello.

Besides configuring gateway rewrite rules, the Dubbo framework provides built-in support for exposing RESTful HTTP paths for Triple services. The specific method depends on whether you use the "protobuf service definition model" or the "Java interface service definition model".

• Java interface model: Most Dubbo Java users choose this model. You can publish RESTful services by adding annotations to Java interfaces. It currently supports both Spring Web and JAX-RS annotation standards.

• Protobuf model: You can publish RESTful services using grpc-gateway.

Adding Annotations to Service Definitions

By adding any of the following annotations to a Java interface, you can publish both Triple binary and RESTful services. After configuring this, you can access the same service using either the standard binary Triple format or the REST HTTP format with JSON.

Spring Web annotation:

@RequestMapping("/triple/demo")
public interface DemoService {

    @RequestMapping(method = RequestMethod.GET, value = "/hello")
    String sayHello(@RequestParam("name") String name);

}

This has already been enabled in the previous example apache/dubbo-samples/tree/master/2-advanced/dubbo-samples-gateway/dubbo-samples-gateway-higress/dubbo-samples-gateway-higress-triple. Check the source code for practical usage.

Now, the route prefix configuration is as follows. The Nacos address configuration remains the same, but the path prefix is changed to a more user-friendly /triple/demo:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    higress.io/destination: gateway-higress-triple-provider.DEFAULT-GROUP.public.nacos
  name: demo
  namespace: default
spec:
    ingressClassName: higress
    rules:
        - http:
              paths:
                  - backend:
                        resource:
                            apiGroup: networking.higress.io
                            kind: McpBridge
                            name: default
                    path: /triple/demo
                    pathType: Prefix

You can access the service using /triple/demo/hello:

$ curl "localhost/triple/demo/hello?name=HigressTriple"

"Hello HigressTriple"

Summary

This article explains how the Dubbo3 Triple protocol simplifies development, testing, and ingress traffic access by providing efficient communication and an easy-to-use interface-based coding approach. Stay updated on the latest community news for the official release of Dubbo 3.3.0.

For more information, visit https://dubbo.apache.org

Microservices Computing Developers Open Source cloud native Dubbo RPC framework Dubbo3 RPC Protocol Triple protocol Http protocol Backend for Frontend
0 2 0
Share on

Read previous post:

Excel at Java AI Application Development within 5 Minutes

Read next post:

Learn Lock-Free Programming with iLogtail

Alibaba Cloud Native Community

506 posts | 48 followers

You may also like

Comments

Alibaba Cloud Native Community

506 posts | 48 followers

Related Products

More Posts by Alibaba Cloud Native Community

See All