RPC Framework on Apache Dubbo

Streaming Communication

Mon, 01 Jan 0001 00:00:00 +0000

Streaming communication is a new RPC data transfer mode offered by Dubbo3, suitable for the following scenarios:

Interfaces that need to send large amounts of data that cannot be placed in a single RPC request or response, requiring batch sending. However, traditional multiple RPC calls cannot resolve issues of order and performance, and if order is to be guaranteed, they must be sent serially.
Streaming scenarios where data needs to be processed in the order sent, and the data itself has no definite boundaries.
Push scenarios where multiple messages are sent and processed within the same call context.

There are three types of Streaming communication:

Timeout Duration

Mon, 01 Jan 0001 00:00:00 +0000

1. Introduction

This example demonstrates how to set the request timeout duration when initiating a call from the Dubbo-go client. You can view the complete example source code here.

2. How to Set the Request Timeout Duration

When creating a client, you can set a global timeout using the client.WithRequestTimeout() method (shared by all service proxies using this client).

 cli, err := client.NewClient(
 client.WithClientURL("tri://127.0.0.1:20000"),
 client.WithClientRequestTimeout(3 * time.Second),
 )

You can also create service-level timeout using client.WithRequestTimeout() (all method calls initiated from the following service proxy svc will use this timeout).

Communication Protocol

Mon, 01 Jan 0001 00:00:00 +0000

The Dubbo-go framework provides two built-in protocols: triple and dubbo. In addition, the framework offers various ways to extend protocol access.

triple, a high-performance communication protocol based on HTTP/1 and HTTP/2, 100% compatible with gRPC, supports Unary, Streaming, and other communication modes; supports publishing REST-style HTTP services.
dubbo, a high-performance private communication protocol based on TCP, with the disadvantage of poor universality, more suitable for use between Dubbo SDKs;
Any protocol extension, by extending the protocol, it can support any RPC protocol. The official ecosystem provides support for JsonRPC, thrift, etc.

In this document, we will introduce the usage of the triple protocol, how to achieve mutual calls with existing dubbo2 systems, and extend support for more protocols. For more principled introductions, please refer to Protocol Specification or related documents in dubbo java .

Exception Type Return Values

Mon, 01 Jan 0001 00:00:00 +0000

1. Introduction

This document demonstrates how to handle error type responses during RPC calls. You can view the complete example source code here.

2. Example Details

2.1 Server

Server proto file

Source file path: dubbo-go-sample/error/proto/greet.proto

syntax = "proto3";

package greet;

option go_package = "github.com/apache/dubbo-go-samples/error/proto;greet";

message GreetRequest {
 string name = 1;
}

message GreetResponse {
 string greeting = 1;
}

service GreetService {
 rpc Greet(GreetRequest) returns (GreetResponse) {}
}

Server handler file

Note that in this program design, the Greet method will only consider the request valid if it receives name="right name"; otherwise, it will return an error.

Health Check

Mon, 01 Jan 0001 00:00:00 +0000

Background

Dubbo-go has a built-in health check service based on the triple protocol to help users manage and monitor the health status of services. You can view the complete example source code here.

Usage

The framework automatically registers the health check service grpc.health.v1.Health into the framework after starting via instance, which records and exposes the health status of each triple service.
The health check service can check the status of services in the framework by making an HTTP request or through client calls to the health check service. The interface called is grpc.health.v1.Health, and the method is check.

1. Call the health check service through the client

Start the service in dubbo-go-samples/healthcheck/go-server, and the status of greet.GreetService can be viewed through the client below.

Request Retry

Mon, 01 Jan 0001 00:00:00 +0000

When a service call fails, we can allow the framework to automatically retry a few times, which can improve the success rate of requests seen by users. In failover cluster mode, dubbo-go supports automatic retries.

1. Introduction

This example demonstrates how to configure the retry function when a client-side call fails. Full example source code

2. How to Use the Retry Feature

When creating a client using client.NewClient(), you can set the retry count using client.WithClientRetries() method.

Passing Additional Parameters

Mon, 01 Jan 0001 00:00:00 +0000

The most straightforward way to understand implicit parameter passing is through the HTTP header, which works exactly like an HTTP header, allowing any number of header parameters to be passed outside of the GET or POST request body. For RPC calls, the context provides the ability to pass additional parameters outside of the method signature’s parameters. The implementation varies slightly between different protocols:

For the triple protocol, the attachment is converted into standard HTTP headers for transmission.
For the Dubbo protocol, the attachment is encoded in a fixed location within the protocol body; please refer to the Dubbo protocol specification.

Startup check

Mon, 01 Jan 0001 00:00:00 +0000

The Dubbo framework, by default, checks the availability of dependent services at startup (whether the registry has available addresses). If not available, it throws an exception to prevent the application from completing initialization, allowing early detection of problems during deployment. The default is check=“true” and waits for 3 seconds.

You can disable the check with check=“false”. For example, during testing, some services may not be of concern, or there may be circular dependencies, requiring one party to start first.

Filter Interceptor

Mon, 01 Jan 0001 00:00:00 +0000

Filters dynamically intercept requests or responses to transform or utilize the information contained in the requests or responses. Filters do not typically create responses themselves but provide generic functions that can be “attached” to any RPC request. Dubbo Filters are pluggable, allowing us to insert any type and number of filters into a single RPC request.

The working principle of filters is illustrated in the diagram below:

Usage

1. Concept of Filter Interceptor

Filter is defined as follows: