By Zhongming Hua
This article introduces the flexible multi-protocol design principles of Apache Dubbo. Based on this design, you can use any RPC communication protocol (such as HTTP/2, HTTP/REST, TCP, gRPC, JsonRPC, and Hessian2) at the bottom of the Dubbo framework while enjoying unified API and peer-to-peer service governance capabilities. At the same time, we will introduce the single-port multi-protocol capability of Dubbo, listening for and processing multiple protocols at the same time on a single port, which is very useful for simplifying the scenario of multi-protocol simultaneous release.
The Dubbo framework does not bind any communication protocol. You can use HTTP/2 communication protocol according to the business scenario or use officially supported communication protocols (such as HTTP/REST, TCP (Dubbo2), gRPC, JsonRPC, and Hessian2). If none of the protocols above meet the requirements, you can easily access custom protocols through customization. You can also use multiple protocols within an application. For example, one interface uses the HTTP/2 communication protocol, another interface uses the TCP communication protocol, and an application publishes or invokes multiple services using different protocols.
With the multi-protocol support of the Dubbo framework, you can:
The Triple protocol is a cloud-native-oriented communication protocol released by Dubbo 3. It is based on HTTP/2 and is fully compatible with the gRPC protocol. It natively supports Streaming communication semantics. Since the release of the Triple protocol, Dubbo supports Protobuf-based service definition and data transfer. Triple has a better gateway and proxy penetration, so it is very suitable for the deployment architecture of cross-gateway and proxy communication, such as service mesh. The core features of the Triple protocol are listed below:
In terms of programming and communication models, the Triple protocol supports the following modes:
The Dubbo2 protocol is a set of RPC communication protocols based on TCP at the transport layer. Due to its compact, flexible, and high-performance characteristics, the Dubbo2 protocol has been widely used in the Dubbo2 era, which is a key communication solution for enterprises to build high-performance and large-scale microservice clusters. In the cloud-native era, we prefer to use the Triple protocol with better versatility and penetration.
You can use Dubbo to develop and manage microservices and use the gRPC protocol for underlying communication. What is the reason for doing this? What are the advantages compared to using the gRPC framework directly? This is a common pattern for microservice development using gRPC. Please read the following section for more details.
gRPC is Google's open-source HTTP/2-based communication protocol. As we mentioned in Product Comparison[1], gRPC is defined as a communication protocol and an implementation scheme, which is an RPC framework. Dubbo is a microservice framework providing solutions for microservice practices. Therefore, compared with Dubbo, gRPC relatively lacks the abstraction of microservice programming models and service governance, and other capabilities.
Using gRPC over Dubbo Framework is a very efficient and lightweight choice. It allows you to use the native gRPC protocol to communicate and avoid the complexity of secondary customization and development based on gRPC (secondary development and customization of gRPC are inevitable after being implemented by many enterprises on a large scale. The Dubbo framework has completed this step for developers. This allows developers to use gRPC directly in the simplest way).
A common communication mode in the microservice field is HTTP + JSON, which is used by some mainstream microservice frameworks (such as Spring Cloud and Microprofile) by default. Dubbo also provides support for HTTP-based programming and communication modes.
In addition to the protocols described above, you can run the following protocols on Dubbo. For Dubbo, you only need to modify a single line of configuration to switch the communication protocol of the underlying service. Peripheral APIs and governance capabilities are unaffected.
Since the release of Dubbo 3.2, Dubbo has provided the protocol multiplexing capability on a single port, which can be implemented by adjusting the protocol configuration.
For example, after the HTTP/2 (Triple) protocol or gRPC protocol is enabled, if we enable port multiplexing at the same time, we can add TCP (Dubbo2) protocol and QoS protocol support for services on the same port. The ingress of all this traffic is on a unified port. The Dubbo framework is responsible for identifying different RPC protocols on the port and distributing the processors to implement protocol multiplexing on a single port.
Port multiplexing is valuable for scenarios where multiple protocols need to be handled. It can be used to migrate service protocols, save ports and related resources, and reduce the complexity of O&M.
The following is a schematic of the port multiplexing implementation:
The following are some common scenarios:
Sample: https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-port-unification
Deploy multiple services on the same host or access multiple services through Server Load Balancer.
Please see Configuration Description[2] for information about configurations supported by Dubbo.
The ext-protocol parameter supports multiple different protocols separated by commas (,).
<dubbo:protocol name="dubbo" port="-1" ext-protocol="tri,"/>
<bean id="greetingService" class="org.apache.dubbo.demo.provider.GreetingServiceImpl"/>
<dubbo:service delay="5000" version="1.0.0" group="greeting" timeout="5000" interface="org.apache.dubbo.demo.GreetingService" ref="greetingService" protocol="dubbo"/>
ProtocolConfig config = new ProtocolConfig(CommonConstants.TRIPLE, -1);
config.setExtProtocol(CommonConstants.DUBBO+",");
dubbo:
application:
name: dubbo-springboot-demo-provider
protocol:
name: tri
port: -1
ext-protocol: dubbo,
dubbo.protocol.name=tri
dubbo.protocol.ext-protocol=dubbo,
dubbo.protocol.port=20880
<dependency>
<groupId>org.apache.dubbo</groupId>
<artifactId>dubbo-qos</artifactId>
</dependency>
After the QoS module is imported, the relevant configuration items can be configured by referring to QoS Operation Manual[3].
By default, the QoS service based on port multiplexing is started after the module is imported.
In the scenario where the QoS protocol is connected to port multiplexing, the client needs to send a message to the server after the connection is established. In contrast, when the Qos protocol is used to provide services through a single port, the QoS protocol of the port multiplexing version requires the user to perform some operations to complete protocol identification (choose one of two) when processing telnet connections.
1. Invoke Commands Directly
The identification can also be done by invoking the commands supported by telnet directly. In cases where the user is unfamiliar with this method, the help command can be invoked for identification.
2. Send the Telnet Command for Identification
After the connection is established through the telnet command, perform the following steps:
Based on the example in the dubbo-samples-port-unification[4], the configurations of services that reference different protocols and non-port multiplexing are the same. The following shows how to output the URL information in the invoking process through the InvokerListener on the Consumer side.
ReferenceConfig<GreetingService> reference = new ReferenceConfig<>();
reference.setInterface(GreetingService.class);
reference.setListener("consumer");
reference.setProtocol(this.protocol);
// reference.setProtocol(CommonConstants.DUBBO);
// reference.setProtocol(CommonConstants.TRIPLE);
For multi-protocol communication scenarios in microservice practice, Dubbo's unbound protocol design allows users to flexibly select communication protocols. The entire protocol selection process is completely transparent to upper-layer API coding and O&M governance. Dubbo's multi-protocol support can easily handle scenarios where multiple protocols need to be processed simultaneously in a cluster. The multi-protocol multiplexing on a single port simplifies this process.
[1] Product Comparison (In Chinese)
https://cn.dubbo.apache.org/zh-cn/overview/what/xyz-difference/
[2] Configuration Description (In Chinese)
https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/reference-manual/config/
[3] QoS Operation Manual (In Chinese)
https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/reference-manual/qos/overview/
[4]dubbo-samples-port-unification
https://github.com/apache/dubbo-samples/tree/master/3-extensions/protocol/dubbo-samples-port-unification
Learn Java & Netty Performance Tuning with the HTTP/2 Protocol Case: Tools, Tips, and Methodology
495 posts | 48 followers
FollowAliware - April 10, 2020
Alibaba Cloud Native Community - January 26, 2024
Alibaba Cloud Native Community - September 12, 2023
Alibaba Cloud Native Community - December 30, 2021
Alibaba Cloud Native Community - August 1, 2024
Alibaba Cloud Native Community - December 19, 2023
495 posts | 48 followers
FollowAccelerate and secure the development, deployment, and management of containerized applications cost-effectively.
Learn MoreHTTPDNS is a domain name resolution service for mobile clients. It features anti-hijacking, high accuracy, and low latency.
Learn MoreEMAS HTTPDNS is a domain name resolution service for mobile clients. It features anti-hijacking, high accuracy, and low latency.
Learn MoreAn end-to-end solution to efficiently build a secure data lake
Learn MoreMore Posts by Alibaba Cloud Native Community