In this article, we will introduce Apache Dubbo’s flexible multi-protocol design principles. Based on this design, any RPC communication protocol such as HTTP/2, HTTP/REST, TCP, gRPC, JsonRPC, Hessian2, etc. can be flexibly selected at the bottom of the Dubbo framework, while enjoying Unified API and peer-to-peer service governance capabilities. At the same time, we also introduced Dubbo’s single-port multi-protocol capability, that is, to monitor and process multiple protocols at the same time on a single port, which is very useful for simplifying the simultaneous release of multiple protocols.
The design principle of not binding the RPC protocol
Aliware
The Dubbo framework is not bound to any communication protocol. You can choose the HTTP/2 communication protocol according to the business scenario, or you can choose HTTP/REST, TCP (Dubbo2), gRPC, JsonRPC, Hessian2 and other officially supported communication protocols. If none of the above protocols can To meet the needs, it is also very convenient to access custom protocols through customization. If you want to use multiple protocols in an application, you can do it very easily, for example, one interface uses HTTP/2 communication, another interface uses TCP communication, and an application publishes or calls multiple services using different protocols.
With the multi-protocol support of the Dubbo framework, you can:
-
Seamlessly connect any communication protocol to the Dubbo service governance system. All communication protocols under the Dubbo system can enjoy the advantages of Dubbo’s programming model, service discovery, and traffic control. For example, in the gRPC over Dubbo model, service governance and programming APIs can all be connected to the Dubbo system at zero cost.
-
Compatible with different technology stacks, business systems use different service frameworks and RPC frameworks in combination. For example, some services are developed using gRPC or Spring Cloud, and some services are developed using the Dubbo framework. Dubbo’s multi-protocol support can achieve interoperability well.
-
Make protocol migration easier. Through the coordination of multi-protocols and registration centers, the needs of protocol migration within the company can be quickly met. For example, upgrade from self-developed protocol to Dubbo protocol, upgrade Dubbo protocol itself, migrate from Dubbo protocol to gRPC, migrate from HTTP to Dubbo protocol, etc.
Mainstream protocols for official access
Aliware
HTTP/2 (Triple)
The Triple protocol is a communication protocol for the cloud-native era released by Dubbo3. It is based on HTTP/2 and is fully compatible with the gRPC protocol. It natively supports Streaming communication semantics. Since the Triple protocol, Dubbo also supports Protobuf-based service definition and data transmission. Triple has better gateway and agent penetration, so it is very suitable for deployment architectures that communicate across gateways and agents, such as service grids.
The core features of the Triple protocol are as follows:
-
Support TLS encryption, Plaintext plaintext data transmission
-
Support back pressure and current limit
-
Support Streaming streaming communication
In terms of programming and communication models, the Triple protocol supports the following modes:
-
Consumer side asynchronous request (Client Side Asynchronous Request-Response)
-
Provider side asynchronous execution (Server Side Asynchronous Request-Response)
-
Consumer request stream (Request Streaming)
-
Provider Response Streaming
-
Bidirectional Streaming
TCP (Dubbo2)
The Dubbo2 protocol is a set of RPC communication protocols based on the TCP transport layer protocol. Due to its compactness, flexibility, and high performance, it has been widely used in the Dubbo2 era. key communication solutions. In the cloud-native era, we recommend using the more versatile and penetrable Triple protocol.
gRPC
You can use Dubbo to develop and manage microservices, and then set up the underlying communication using the gRPC protocol. But why do you want to do that, and what are the advantages over using the gRPC framework directly? The short answer is that this is a common pattern for microservices development using gRPC, see below for details.
gRPC is Google’s open-source HTTP/2-based communication protocol, as in our Product Comparison[1]1] strong>As mentioned in the document, gRPC is positioned as a communication protocol and implementation, and is a pure RPC framework, while Dubbo is positioned as a microservice framework that provides solutions for microservice practices. Therefore, compared with Dubbo, gRPC is relatively lacking in the abstraction of microservice programming model, service governance and other capabilities.
Using the gRPC protocol (gRPC over Dubbo Framework) under the Dubbo system is a very efficient and lightweight choice. It allows you to use the original gRPC protocol to communicate, and avoids the complexity of secondary customization and development based on gRPC ( Secondary development and customization of gRPC are inevitable links after large-scale practice in many enterprises. The Dubbo framework completes this step for developers, allowing developers to directly use gRPC in the simplest way).
REST
A commonly used communication mode in the field of microservices is HTTP + JSON, which is used by default by some mainstream microservice frameworks such as Spring Cloud and Microprofile. Dubbo also provides support for HTTP-based programming and communication modes.
Other communication protocols
In addition to the protocols introduced above, you can also run the following protocols on Dubbo. For Dubbo, it only needs to modify a simple line of configuration to switch the communication protocol of the underlying service, and other peripheral APIs and governance capabilities will not be affected.
-
Hessian2
-
Thrift
-
JsonRPC
Single port multi-protocol
Aliware
Since version 3.2 of Dubbo, Dubbo provides protocol multiplexing capability on a single port, which can be realized by adjusting the Protocol configuration.
For example, after enabling the HTTP/2 (Triple) protocol or the gRPC protocol, if we enable port multiplexing at the same time, we can also add support for the TCP (Dubbo2) protocol and Qos protocol to the service on the same port. The entry of all these traffics is on a unified port, and the Dubbo framework is responsible for identifying different RPC protocols on the port and distributing processors, thereby realizing protocol multiplexing on a single port.
For scenarios where multiple protocols need to be handled, port multiplexing is very valuable. It can be used for protocol migration of services, and can save ports and related resources, reduce the complexity of operation and maintenance, etc.
Implementation principle
The following is the schematic diagram of port multiplexing implementation
-
In the service creation phase, different Protocol objects are created for export by obtaining the protocol configuration exported by the service from the Config layer. During the export process, if it is not the first time to create a server with port multiplexing, the Exchanger will save the data passed by the Protocol layer to the Server for subsequent processing of messages of this protocol type.
-
When the client’s message is delivered, it will first be passed to the ProtocolDetector through the Server. If the identification is completed, the client will be marked as the corresponding protocol. And configure the corresponding processing logic through WireProtocol, and finally hand it over to ChannelOperator to complete the binding of the underlying IO framework and the processing logic of the corresponding Dubbo framework.
-
After the above protocol identification is completed, the Channel has determined how to process the remote client message, and it can be processed through the corresponding ServerPipeline (the processing thread of the message will also be determined according to the configuration information during the processing).
Scenario
Below are several common usage scenarios.
-
Most commonly used for service discovery. This allows applications to discover services over the network and then communicate with them using the same port, helping to reduce the complexity of network communication and make it easier to manage.
-
Can be used for load balancing. This allows applications to balance load across multiple remote services or clusters of services, helping to improve scalability, reliability, and availability of services.
-
Can be used for service monitoring. This allows applications to monitor the health of remote services and raise alerts when services fail or become unavailable, helping to ensure service availability and reduce downtime.
Reference use case:
https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-port-unification
How to use
Multiple services are deployed on the same host or need to be accessed through a load balancer.
About the configuration method supported by Dubbo Configuration instructions[2]
Service multi-protocol export
The ext-protocol parameter supports configuring multiple different protocols, and the protocols are separated by “,”.
xml configuration
<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"/>
API Configuration
ProtocolConfig config = new ProtocolConfig(CommonConstants.TRIPLE, -1); config.setExtProtocol(CommonConstants.DUBBO + ",");
yaml configuration
dubbo:
application:
name: dubbo-springboot-demo-provider
protocol:
name: tri
port: -1
ext-protocol: dubbo,
properties configuration
dubbo.protocol.name=tri dubbo.protocol.ext-protocol=dubbo, dubbo.protocol.port=20880
Qos access
Qos module import
<dependency>
<groupId>org.apache.dubbo</groupId>
<artifactId>dubbo-qos</artifactId>
</dependency>
After importing the Qos module, related configuration items can refer to Qos Operation Manual[3] to configure.
By default, the Qos service based on port multiplexing is started after the module is imported.
Qos usage
When the Qos protocol is connected to the port multiplexing scenario, after the connection is established, the client needs to send a message to the server first. Compared with the Qos protocol that provides services through a single port, the port multiplexing version of the Qos protocol handles the telnet connection. In some cases, the user needs to perform some operations to complete the protocol identification (choose one of the two).
-
call the command directly
The recognition can also be completed by calling the commands supported by telnet directly. If the user is not familiar with it, the help command can be called to complete the recognition
2. Send telnet command to identify
After establishing a connection via the telnet command, perform the following steps:
-
-
Use crtl + “]” to enter the telnet interactive interface (telnet default escape character)
-
Call “send ayt” to send a special identification field to the server (a special field of the telnet protocol)
-
Press Enter to complete the message sending and enter the interactive interface of dubbo
-
Service Reference
Take the example in dubbo-samples-port-unification[4] as an example Basically, the configuration of services that refer to different protocols is consistent with that of non-port multiplexing. Next, the URL information during the invocation process is output 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);
Summary
Aliware
For the multi-protocol communication scenarios that are often encountered in microservice practice, Dubbo’s unbound protocol design allows users to choose communication protocols flexibly. The entire protocol selection process is completely transparent to upper-layer API coding and operation and maintenance governance; Dubbo’s multi-protocol support can also handle the scenario of processing multiple protocols at the same time in a cluster, and the single-port multi-protocol multiplexing support further simplifies this process.
In the next article, we will introduce in detail how to develop gRPC protocol communication services in the Dubbo framework, which greatly simplifies the development cost of gRPC microservices, avoids secondary development, and provides unified programming for native gRPC API and out-of-the-box service governance capabilities.
Related links:
[1] Product comparison
https://cn.dubbo.apache.org/zh-cn/overview/what/xyz-difference/
[2] Configuration instructions
https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/reference-manual/config/
[3] Qos Operation Manual
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