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.
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.
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.
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.
This architecture is similar to the centralized architecture but does not require an additional BFF application. Instead, the gateway directly calls backend Dubbo services.
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.
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.
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:
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.
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.
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
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.
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.
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.
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.
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"
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
494 posts | 48 followers
FollowAlibaba Cloud Native Community - January 26, 2024
Alibaba Cloud Native Community - May 31, 2022
Alibaba Cloud Native Community - August 23, 2023
Alibaba Cloud Native - September 8, 2022
Alibaba Cloud Native Community - December 1, 2023
Alibaba Cloud Native Community - November 22, 2023
494 posts | 48 followers
FollowMSE provides a fully managed registration and configuration center, and gateway and microservices governance capabilities.
Learn MoreAlibaba Cloud Function Compute is a fully-managed event-driven compute service. It allows you to focus on writing and uploading code without the need to manage infrastructure such as servers.
Learn MoreMulti-source metrics are aggregated to monitor the status of your business and services in real time.
Learn MoreHigh Performance Computing (HPC) and AI technology helps scientific research institutions to perform viral gene sequencing, conduct new drug research and development, and shorten the research and development cycle.
Learn MoreMore Posts by Alibaba Cloud Native Community