Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog How Do We Use One Port to Expose the HTTP1/2, gRPC, and Dubbo Protocols at the Same Time?

How Do We Use One Port to Expose the HTTP1/2, gRPC, and Dubbo Protocols at the Same Time?

This article introduces the flexible multi-protocol design principles of Apache Dubbo.

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.

Design Principles without Unbinding the RPC Protocol

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.

1

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 in the Dubbo system can enjoy the advantages of the Dubbo programming model, service discovery, and traffic control. For example, in the gRPC over Dubbo mode, the service governance and programming API can be accessed to the Dubbo system with zero cost.
  • The multi-protocol support is compatible with different technology stacks. Business systems use different service frameworks and RPC frameworks. For example, some services are developed using gRPC or Spring Cloud, and some services are developed using the Dubbo framework. The multi-protocol support of Dubbo can achieve good interoperability.
  • The multi-protocol support makes protocol migration easier. Through the coordination of multi-protocol and registration centers, it can quickly meet the needs of protocol migration within the company. For example, the self-developed protocol is upgraded to the Dubbo protocol, the Dubbo protocol is upgraded, the Dubbo protocol is migrated to gRPC, and the HTTP protocol is migrated to Dubbo.

Official Mainstream Protocols

HTTP/2 (Triple)

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:

  • It supports TLS encryption and plaintext data transfer.
  • It supports backpressure and throttling.
  • It supports streaming communication.

In terms of programming and communication models, the Triple protocol supports the following modes:

  • Client Side Asynchronous Request-Response
  • Server Side Asynchronous Request-Response
  • Client Side Request Streaming
  • Server Side Response Streaming
  • Bidirectional Streaming Communication

TCP (Dubbo2)

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.

gRPC

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).

REST

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.

Other Communication Protocols

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.

  • Hessian2
  • Thrift
  • JsonRPC

Multi-Protocol Multiplexing on a Single Port

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.

Principles

The following is a schematic of the port multiplexing implementation:

2

  • In the service creation phase, you can obtain the service-exported protocol configurations from the Config layer to create different Protocol objects for export. In the export process, if it is not the first time to create a Server with port multiplexing, Exchanger will save the data passed by the Protocol layer to the Server for subsequent processing of messages of the protocol type.
  • After the client's message is delivered, it will be delivered to the ProtocolDetector through the Server. If the identification is completed, the client will be marked as the corresponding protocol. The corresponding processing logic will be configured through WireProtocol, and the ChannelOperator will complete the binding of the underlying I/O framework and the corresponding Dubbo framework processing logic.
  • After the protocol identification above is completed, the Channel has determined how to process the remote client message. The message can be easily processed through the corresponding ServerPipeline (the message processing thread will also be determined according to the configuration information during the processing).

Scenarios

The following are some common scenarios:

  • The most common is for service discovery. This allows applications to discover services over the network and then communicate with them using the same port. In this case, it helps reduce the complexity of network communication and makes it easier to manage.
  • Load Balancing: This allows applications to balance the load across multiple remote services or service clusters, helping improve the scalability, reliability, and availability of services.
  • Service Monitoring: This allows applications to watch the health of remote services and alert when a service fails or becomes unavailable, helping ensure service availability and reduce downtime.

Sample: https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-port-unification

Methods

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.

Service Multi-Protocol Export

The ext-protocol parameter supports multiple different protocols separated by commas (,).

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 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.

QoS Usage

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.

3

2.  Send the Telnet Command for Identification

After the connection is established through the telnet command, perform the following steps:

  1. Use Ctrl + "]" to enter the telnet interactive interface (scape character defaulted by telnet)
  2. Invoke send ayt to send a special identification field to the server (a special field of the telnet protocol).=
  3. Press Enter to send the message and enter the Dubbo interactive interface

4

Service Reference

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);

5

Summary

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.

Related Links

[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

http TCP Developers RPC cloud native Dubbo Framework Protocol HTTP1/2g REST
0 1 0
Share on

Read previous post:

Design and Implementation of Seata-go TCC

Read next post:

Learn Java & Netty Performance Tuning with the HTTP/2 Protocol Case: Tools, Tips, and Methodology

Alibaba Cloud Native Community

482 posts | 48 followers

You may also like

Comments

Alibaba Cloud Native Community

482 posts | 48 followers

Related Products

More Posts by Alibaba Cloud Native Community

See All