From its design, Dubbo is highly extendable. Through these extension points, you can:
Dubbo’s extensibility allows the project to be conveniently divided into various sub-modules, enabling hot plugging. Users can replace Dubbo’s native implementation based on their needs to meet specific business requirements.
Numerous extension points and abstractions form the foundation for Dubbo’s integration with various microservices ecosystem components and the realization of microservices governance capabilities.
Dubbo’s SDKs for various languages adopt the “microkernel + plugin” design pattern. Almost all core nodes in every process are defined as extension points. Officially released components are also released in the form of extension point implementations, so Dubbo can treat all official and third-party component extensions equally.
The above are some core extension points within Dubbo, categorized by architectural levels:
As emphasized in the communication protocol section, Dubbo is not bound to any specific protocol. Users can select any combination of RPC and serialization protocols, such as Triple, gRPC, Dubbo2, REST, custom protocols, etc.
The Protocol extension point defines the corresponding RPC protocol. By utilizing this extension point, Dubbo can act as a unified microservices development and governance framework, allowing for flexibility in the underlying communication protocol. Officially supported are the most popular RPC communication protocols, and if you wish to use a company-specific RPC communication protocol, provide a custom extension implementation via Protocol.
The Serialization extension point defines serialization protocol extensions. Officially, Dubbo offers serialization protocols like Fastjson, Protobuf, Hessian2, Kryo, and FST.
Dubbo pre-embeds a significant number of extension points in the service call link, allowing users to control the flow of runtime traffic and change the behavior of runtime calls.
Filters, traffic interceptors in Dubbo, are based on the AOP design pattern. They preprocess and postprocess each service call, handling tasks like access logs, encryption/decryption, traffic statistics, parameter verification, etc.
The Router is a key component for traffic control in Dubbo. It directs traffic that meets certain conditions to a specific group of address subsets, enabling various traffic control modes.
In Dubbo, Load Balance works after the router. It ensures that calls are evenly distributed across all machines in the address subset over a period of time.
The classic Dubbo deployment architecture consists of a registry (service discovery), configuration center, and metadata center.
This section primarily discusses Dubbo’s service governance from an architectural and implementation perspective.
The registry is the foundation for Dubbo’s service discovery capability, with official support for registries like Zookeeper, Nacos, Etcd, Consul, and Eureka.
The configuration center is a key component for dynamically controlling Dubbo’s behavior. All rules dispatched in Traffic Management are first saved in the configuration center.
In contrast to the configuration center, from a user’s perspective, the metadata center is read-only.
The following examples demonstrate how to extend Dubbo to address practical problems.
This article lists some of the commonly used extension points in Dubbo. However, there are many more extension points available for flexible customization. Each SDK for different languages may have variations in extension definitions and configuration methods.