Source Code Interpretation on Apache Dubbo

Network Protocol

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

For the Dubbogo microservice framework, the network protocol is the module responsible for network communication in remote procedure calls, handling functions such as data serialization, packaging, request initiation, and network port listening from the application layer to the network layer. Dubbogo abstracts a set of interfaces for protocols as follows:

type Protocol interface {
	// Export service for remote invocation
	Export(invoker Invoker) Exporter
	// Refer a remote service
	Refer(url *common.URL) Invoker
	// Destroy will destroy all invoker and exporter, so it only is called once.
	Destroy()
}

This interface includes three methods. The Export method is responsible for the service exposure process. The input parameter invoker is a concept of dubbo, encapsulating a callable instance. In the specific Export method implementation for a protocol (e.g., Triple), the callable instance Invoker with certain logic is exposed to external services in the form of network port listening. Requests targeting that network port will be captured by the listening coroutine initiated by the Export method, which will then deconstruct and deserialize the data according to the network protocol to retrieve the parsed request data.

Registry

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

Dubbogo abstracts a set of interfaces for the registry as follows:

// Registry Extension - Registry
type Registry interface {
	common.Node

	// Register is used for service provider calling, register services
	// to registry. And it is also used for service consumer calling, register
	// services cared about, for dubbo's admin monitoring.
	Register(url *common.URL) error

	// UnRegister is required to support the contract:
	// 1. If it is the persistent stored data of dynamic=false, the
	// registration data can not be found, then the IllegalStateException
	// is thrown, otherwise it is ignored.
	// 2. Unregister according to the full url match.
	// url Registration information, is not allowed to be empty, e.g:
	// dubbo://10.20.153.10/org.apache.dubbo.foo.BarService?version=1.0.0&application=kylin
	UnRegister(url *common.URL) error

	// Subscribe is required to support the contract:
	// When creating new registry extension, pls select one of the
	// following modes.
	// Will remove in dubbogo version v1.1.0
	// mode1: return Listener with Next function which can return
	// subscribe service event from registry
	// Deprecated!
	// subscribe(event.URL) (Listener, error)
	// Will replace mode1 in dubbogo version v1.1.0
	// mode2: callback mode, subscribe with notify(notify listener).
	Subscribe(*common.URL, NotifyListener) error

	// UnSubscribe is required to support the contract:
	// 1. If don't subscribe, ignore it directly.
	// 2. Unsubscribe by full URL match.
	// url Subscription condition, not allowed to be empty, e.g.
	// consumer://10.20.153.10/org.apache.dubbo.foo.BarService?version=1.0.0&application=kylin
	// listener A listener of the change event, not allowed to be empty
	UnSubscribe(*common.URL, NotifyListener) error
}

This interface mainly includes four methods: register, unregister, subscribe, and unsubscribe. As the names suggest, it summarizes the actions for client and server interactions with the registry. For general interface-level service registration scenarios, when the Provider service starts, it abstracts its service interface information into a URL, which contains all the information needed for the client to initiate a call (IP, port, protocol, etc.). The server’s registry component writes this URL to the registry (e.g., Zookeeper). After the client starts, it will subscribe to the required service information through the registry component during the service reference step, and the obtained service information will be written to the client cache in the form of asynchronous event updates. Thus, upon successful service discovery, it can initiate calls to the corresponding service provider based on the retrieved service URL parameters.

New features

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

1. Triple Protocol

1.1 Overview

Communication level

The Triple protocol, also known as the Dubbo3 protocol, is an extended protocol based on HTTP2 + gRPC, which adds specific fields and logical enhancements, ensuring interoperability with the native gRPC protocol. On this basis, the Triple new protocol will more natively support Dubbo service governance capabilities and support streaming RPC calls.

In simple terms, it can be understood as Triple = gRPC + Dubbo.

Generic Call

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

1. Dubbo-go Generic Call Java Server

Using Triple protocol + hessian2 serialization scheme

1.1 Java Server Startup

Transport Structure Definition

package org.apache.dubbo;

import java.io.Serializable;
import java.util.Date;

public class User implements Serializable {
	private String id;

 private String name;

 private int age;

 private Date time = new Date();
}

Interface Definition

package org.apache.dubbo;

import java.util.ArrayList;
import java.util.List;
import java.util.Map;
//import org.apache.dubbo.rpc.filter.GenericFilter;

public interface UserProvider {
	User GetUser1(String userId);
}

1.2 Go Client Generic Call

This section shows how to construct a generic interface reference in the form of an API

Generic Invocation

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

1. Dubbogo Generic Invocation to Java Server

Using Triple protocol + hessian2 serialization scheme

Refer to Dubbogo 3.0 Generic Invocation Documentation

1.1 Java Server Startup

Transmission structure definition

package org.apache.dubbo;

import java.io.Serializable;
import java.util.Date;

public class User implements Serializable {
	private String id;

 private String name;

 private int age;

 private Date time = new Date();
}

Interface definition

package org.apache.dubbo;

import java.util.ArrayList;
import java.util.List;
import java.util.Map;
//import org.apache.dubbo.rpc.filter.GenericFilter;

public interface UserProvider {
	User GetUser1(String userId);
}

1.2 Go-Client Generic Invocation

Here is the construction of the generic interface reference in the form of API

AOP and Extension Mechanism

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

1. Extension Module and Init Method

1.1 Interface and Implementation

In Golang, an interface is often accompanied by multiple implementation classes. Dubbo-go provides a pluggable and extensible mechanism for interface implementation classes, reducing coupling between modules and facilitating developers in introducing and customizing components.

1.2 Init Method in Golang

The init method, as a special method in Golang, executes first on program startup when a user imports a set of modules, performing loading logic. This method is an important way for dubbogo to register extension components.

Architecture

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

Architecture Description

Node Description

Registry : The registry center responsible for service registration and discovery in dubbo-go
Consumer : The service consumer that calls remote services
Provider : The service provider that exposes services

Process Description

0. register : When the service provider starts, it will automatically register its services with the registry center
1. subscribe : The service consumer will subscribe to the services it needs from the registry center upon starting
2. notify : The registry center returns service registration information to the service consumer. When the subscribed service changes, the change data will be pushed to the consumer
3. invoke : The service consumer selects a suitable service address based on the service addresses obtained from the registry center and initiates a request after applying the load balancing algorithm

The Application and Interface of Dubbo

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

Dubbogo Service Levels

Dubbogo service levels consist of two levels: Application Level and Interface Level, which are closely related to the framework configuration structure.

As shown in the diagram below, the components at the application level are marked in light red, while those at the interface level are marked in light blue:

1. Application Level Components

Characteristics of application level components: shared by all interface level components of the current application.