Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog Dubbo3 and the Triple Protocol: Why It Is the Logical Choice

Dubbo3 and the Triple Protocol: Why It Is the Logical Choice

In this blog, we introduce the Triple protocol and discuss why it's the perfect choice for Dubbo3.

Dubbo3 provides Triple (Dubbo3) and Dubbo2 protocols, which are native protocols of the Dubbo framework. In addition, Dubbo3 also integrates many third-party protocols and incorporates them into Dubbo programming and service governance system, including gRPC, Thrift, JSON-RPC, Hessian2, and REST. The following part highlights the Triple and Dubbo2 protocols.

Next Generation RPC Protocol - Triple

The Triple protocol is the main protocol launched by Dubbo3. Triple means the third generation. Thanks to the evolution of Dubbo1.0 and Dubbo2.0 protocols and the trend of technological standardization brought by cloud native, Triple, a new Dubbo3 protocol, comes into being.

Introduction to the RPC Protocol

Protocols are the core of RPC, which standardizes the content and format of data transmitted on the network. On top of the required request and response data, the RPC protocol usually contains additional control data, such as the serialization mode, timeout period, compression mode, and authentication information of a single request.

The content of the protocol consists of three parts:

  • Data exchange format: It defines the byte stream content of RPC request and response objects in network transmission, also known as serialization mode.
  • Protocol structure: It defines the list of fields, the semantics of each field and the arrangement of different fields.
  • Data transmission process: The protocol stipulates how data is transmitted between networks by defining rules, formats, and semantics. A successful RPC requires both ends of the communication to be able to read/write network byte streams and convert objects as agreed in the protocol. If the two ends cannot reach an agreement on the use of the protocol, they will not understand each other and the needs of remote communication cannot be satisfied.

1

The following contents need to be considered for designing the RPC protocol:

  • Universality: The RPC protocol provides unified binary format, and supports cross-language, cross-platform, and multi-transport layer protocols.
  • Extensibility: How to add fields to the protocol, upgrade the protocol, support user extensions, and add business metadata.
  • Performance: Typically, we would like the performance to be as fast as it can be.
  • Penetration: The RPC protocol can be identified and forwarded by various terminals, such as gateways and proxy servers. Universality and high performance usually cannot be achieved at the same time, so protocol designers are required to make certain choices.

HTTP/1.1

Compared with private RPC protocols built directly on the TCP transport layer, the remote call solution built on HTTP will have better universality, such as Web Services or REST architecture. In addition, using HTTP and JSON can be regarded as a de facto standard solution.

Two biggest advantages of choosing to build on top of HTTP include:

  • The semantics and scalability of HTTP can meet requirements for RPC.
  • Thanks to good protocol penetration, HTTP is supported by almost all devices on the network.

However, HTTP is also faced with several obvious problems:

  • With the typical Request-Response model, only one waiting Request can exist on a link at a time, and HOL is generated.
  • With Human Readable Headers, HTTP uses a more general and human-readable head transfer format, but the performance is poor.
  • Without direct Server Push support, HTTP is required to use Polling, Long-Polling, and other workarounds.

gRPC

The preceding part discusses advantages and disadvantages of building RPC protocols based on HTTP and TCP. Compared with Dubbo built on TCP transport layer, Google chooses to define gRPC directly on top of HTTP/2.

The benefits of gRPC are inherited from HTTP/2 and Protobuf, including:

  • A HTTP/2-based protocols is simple enough, and the user learning cost is low. Also, it naturally has capabilities for server push, multiplexing, and traffic control.
  • Based on Protobuf, the gRPC protocol boasts multi-language cross-platform binary compatibility and provides unified cross-language capabilities.
  • The ecosystem based on the protocol itself is rich, including natural support protocols of K8s or etcd and other components as well as the fact protocol standard of cloud native.

But problems also exist:

  • The support for service governance is relatively basic, and it is more inclined to the basic RPC function. The protocol layer lacks the necessary unified definition, which is not easy for users to operate directly.
  • The serialization method of strong binding Protobuf requires high learning and transformation costs. For existing monolingual-oriented users, the migration costs cannot be ignored.

Our Thought Process behind the Triple Protocol

Finally, we chose compatible gRPC and built a new protocol, Triple, with HTTP2 as the transport layer. The rise of containerized applications and micro-services has facilitated the development for load content optimization technologies. The traditional communication protocols used by clients, such as RESTFUL or other HTTP-based customized protocols, are difficult to meet the requirements of applications in terms of performance, maintainability, extensibility, security, and other convenience. A cross-language, modular protocol will gradually become a new protocol standard of application development. Since the gRPC protocol became a CNCF project in 2017, more infrastructure and business including K8s and etcd have begun to use the gRPC ecosystem. As a micro-service framework of Cloud native, a new protocol of Dubbo is also perfectly compatible with gRPC. Moreover, Triple will also enhance and supplement some imperfect parts of the gRPC protocol.

So, does the Triple protocol solve the problems mentioned above? In short, yes. Let's evaluate the suitability of this protocol in terms of several aspects:

  • Performance: The Triple protocol adopts the policy of separating metadata and payload, so intermediate devices, such as gateways, can be prevented from parsing and de-serializing the payload, thus reducing the response time.
  • Routing support: Metadata supports users to add customized headers, so users can more easily divide clusters or perform routing according to headers. Therefore, it has higher flexibility to cut traffic in canary or disaster recovery during release.
  • Security: The Triple protocol has encrypted transmission capabilities such as two-way TLS authentication (mTLS).
  • Usability: In addition to supporting Protobuf serialization recommended by native gRPC, the Triple protocol supports other serialization such as Hessian and JSON in a common way, allowing users to upgrade to the Triple protocol more conveniently. For the original Dubbo service, users only need to add a line of protocol configuration to the code block of the claim service to modify or add the Triple protocol. The transformation cost is almost zero.

2

Current Situation

  1. The Triple protocol is fully compatible with gRPC. Therefore, the client or server can be connected with the native gRPC client.
  2. At present, the Triple protocol has been verified by large-scale production practice and reached the production level.

Features and Advantages of the Triple Protocol

  1. The Triple protocol has the ability of cross-language communication. Both traditional multi-language, multi-SDK modes and Mesh-based cross-language modes require a more general and easy-to-extend format of data transmission.
  2. The Triple protocol provides a more complete request model. In addition to the Request-Response model, Streaming and Bidirectional models are also supported.
  3. The Triple protocol is easy to expand and has high penetration, including but not limited to the support of Tracing or Monitoring. It is also supposed to be identified by devices at all layers. Gateway facilities can identify data messages, which is friendly to Service Mesh deployment and makes it easier for users to understand.
  4. The Triple protocol is supported by multiple serialization methods and is able to upgrade smoothly.
  5. The Triple protocol supports upgrades without affecting the services of Java users. Without requirements to define complicated IDL files, users only need to modify the protocol name to upgrade to the Triple protocol.

Details of the Triple Protocol

Further extension based on the gRPC protocol

  • Service-Version →tri-service-version {Dubbo service version}
  • Service-Group → tri-service-group {Dubbo service group}
  • Tracing-ID → tri-trace-traceid {tracing id}
  • Tracing-RPC-ID → tri-trace-rpcid {_span id _}
  • Cluster-Info → tri-unit-info {cluster infomation}

Service-Version and Service-Group respectively identify the version and group information of Dubbo service. Because the path of gRPC declares service name and method name, version and group information of gRPC are missing when compared with Dubbo protocol. Tracing-ID and Tracing-RPC-ID are used for the ability to end-to-end tracing, respectively indicating the information of tracing ID and span ID. Cluster-Info indicates cluster information, which can be used to build some flexible service governance capabilities related to routing such as cluster division.

Triple Streaming

Compared with the traditional unary mode, the Triple protocol provides Streaming RPC capabilities.

Which Scenarios Is Streaming Suitable for?

In some application scenarios such as large file transmission and live broadcasting, consumers or providers need to transmit a great deal of data with opposite ends. In these cases, the amount of data is very large, which cannot be transmitted in an RPC data packet. Therefore, after sharding data packets, we need to transmit those data packets through multiple RPCs. If we transmit these split RPC data packets in parallel, the relevant data packets are unordered after arriving at the opposite end, and the received data needs to be sorted and spliced. The relevant logic will be complicated. However, if we carry out serial transmission of split RPC data packets, the corresponding RTT of network transmission and latency of data processing will be long.

In order to solve the above problems and to transfer a large amount of data between consumers and providers in a pipelined manner, the Streaming RPC model comes into being.

By using the Streaming RPC mode of the Triple protocol, data streaming is implemented based on multiple long connections in the user state that are established between consumers and providers. Multiple Streams can exist on the same TCP connection at the same time, and each Stream is identified by Stream ID. Packets on a Stream are read and written in sequence.

Summary

In the field of API, the most important trend is the rise of the standardization technology. The Triple protocol is the main protocol launched by Dubbo3. It adopts a hierarchical design, and its data exchange format is developed on the basis of Protobuf (Protocol Buffers) protocol. It has excellent serialization and deserialization efficiency. Also, it supports multiple serialization methods and many development languages. In the protocol at the transport layer, Triple selects HTTP/2 that improves the transmission efficiency, compared with HTTP/1.1. In addition, as a mature open standard, HTTP/2 has rich security, flow control and other capabilities, as well as good interoperability. Triple can be used not only for server-side service calls, but also for browsers, mobile apps, and IoT devices to interact with backend services. At the same time, the Triple protocol seamlessly supports the all service governance capabilities of Dubbo3.

In the trend of cloud native, the demands for interoperability among cross-platform, cross-vendor, and cross-environment systems will inevitably bring RPC technologies based on open standards. The gRPC conforms to the trend of development and has been more widely used. In the field of micro-services, the proposal and implementation of the Triple protocol represent a big step for Dubbo3 towards micro-services of cloud native.

Appendix: Dubbo2 Protocol SPEC

Protocol SPEC

  • Magic - Magic High & Magic Low (16 bits)Identifies dubbo protocol with value: 0xdabb
  • Req/Res (1 bit)Identifies this is a request or response. Request - 1; Response - 0.
  • 2 Way (1 bit)Only useful when Req/Res is 1 (Request), expect for a return value from server or not. Set to 1 if need a return value from server.
  • Event (1 bit)Identifies an event message or not, for example, heartbeat event. Set to 1 if this is an event.
  • Serialization ID (5 bit)Identifies serialization type: the value for fastjson is 6.

  • Status (8 bits)Only useful when Req/Res is 0 (Response), identifies the status of response

    • 20 - OK
    • 30 - CLIENT_TIMEOUT
    • 31 - SERVER_TIMEOUT
    • 40 - BAD_REQUEST
    • 50 - BAD_RESPONSE
    • 60 - SERVICE_NOT_FOUND
    • 70 - SERVICE_ERROR
    • 80 - SERVER_ERROR
    • 90 - CLIENT_ERROR
    • 100 - SERVER_THREADPOOL_EXHAUSTED_ERROR
  • Request ID (64 bits)Identifies an unique request. Numeric (long).
  • Data Length (32)Length of the content (the variable part) after serialization, counted by bytes. Numeric (integer).
  • Variable PartEach part is a byte[] after serialization with specific serialization type, identifies by Serialization ID.

Every part is a byte[] after serialization with specific serialization type, identifies by Serialization ID

1.  If the content is a Request (Req/Res = 1), each part consists of the content, in turn is:

  • Dubbo version
  • Service name
  • Service version
  • Method name
  • Method parameter types
  • Method arguments
  • Attachments

2.  If the content is a Response (Req/Res = 0), each part consists of the content, in turn is:

  • Return value type, identifies what kind of value returns from server side: RESPONSE_NULL_VALUE - 2, RESPONSE_VALUE - 1, RESPONSE_WITH_EXCEPTION - 0.
  • Return value, the real value returns from server.

Note: For the Variable Part, when the current Dubbo framework uses JSON serialization, additional line feeds are added as separators between each part of the content. Add additional line feeds after each part of the Variable Part, such as:

Dubbo version bytes (line feed)
Service name bytes  (line feed)
...
http Developers RPC cloud native Dubbo gRPC Dubbo3 Dubbo Triple Protocol
0 0 0
Share on

Read previous post:

A Practical Guide on Dubbo-Admin Function Display and Operations

Read next post:

Sealer Becomes CNCF Sandbox Project to Build New Standards for Distributed Application Delivery

Alibaba Cloud Native Community

506 posts | 48 followers

You may also like

Comments

Alibaba Cloud Native Community

506 posts | 48 followers

Related Products

  • Cloud-Native Applications Management Solution

    Accelerate and secure the development, deployment, and management of containerized applications cost-effectively.

    Learn More

  • HTTPDNS

    HTTPDNS is a domain name resolution service for mobile clients. It features anti-hijacking, high accuracy, and low latency.

    Learn More

  • EMAS HTTPDNS

    EMAS HTTPDNS is a domain name resolution service for mobile clients. It features anti-hijacking, high accuracy, and low latency.

    Learn More

  • Function Compute

    Alibaba 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 More

More Posts by Alibaba Cloud Native Community

See All