What’s a Dubbo?

Dubbo is a distributed services framework dedicated to providing high-performance and transparent RPC remote service invocation solutions, as well as SOA service governance solutions.

To put it simply, Dubbo is a service framework. If there is no distributed requirement, there is no need to use a distributed service framework like Dubbo, and it is essentially a service invocation. In plain English, it is a distributed framework for remote Service invocation (moving away from WSdl in the Web Service schema and registering on Dubbo as a server and consumer).

Its core parts include:

1. Remote communication:

Provides abstract encapsulation of a variety of long-connection-based NIO frameworks, including multiple threading models, serialization, and request-response mode of information exchange.

2. Cluster fault tolerance:

Transparent remote procedure calls based on interface methods, including multi-protocol support, and cluster support for soft load balancing, failure tolerance, address routing, and dynamic configuration.

3. Automatic discovery

Based on registry directory services, service consumers can dynamically find service providers, address transparency, and service providers can smoothly add or subtract machines.

What can Dubbo do?

1. Transparent remote method calls

Remote methods are called just like local methods, with simple configuration and no API intrusion.

2. Soft load balancing and fault tolerance

Hardware load balancers such as F5 can be replaced on the Intranet to reduce costs and single points.

3. Automatic service registration and discovery

Instead of writing out the service provider address, the registry queries the IP address of the service provider based on the interface name and can smoothly add or remove service providers.

Dubbo uses a full Spring configuration mode to transparently access applications without any API intrusion. You only need to load Dubbo’s configuration with Spring. Dubbo is loaded based on Spring’s Schema extension.

Dubbo’s architecture and design ideas

Dubbo framework has high scalability, mainly using microcore + plug-in system, and complete documentation, very convenient secondary development, strong adaptability.

The overall architecture of Dubbo is shown below:

The Dubbo framework design is divided into 10 layers, with the Service layer at the top being the interface layer for implementing business logic for developers who actually want to develop distributed services using Dubbo. In the figure, the interfaces used by the service consumer on the left with a light blue background, the interfaces used by the service provider on the right with a light green background, and the interfaces used by both parties on the central axis.

The Dubbo framework is divided into 10 layers:

  • Service interface layer: This layer is related to the actual business logic and designs corresponding interfaces and implementations according to the business of Service providers and Service consumers.
  • Configuration layer (Config) : external configuration interface, centering on ServiceConfig and ReferenceConfig, can directly new configuration classes, or generate configuration classes through Spring configuration parsing.
  • Proxy layer: transparent Proxy of service interface, generating client Stub and server Skeleton of service, centered on ServiceProxy, and ProxyFactory as extension interface.
  • Service Registration layer (Registry) : encapsulates the registration and discovery of service addresses. It is centered on service URLS and extends the interfaces to RegistryFactory, Registry and RegistryService. There may be no service registry, in which case the service provider directly exposes the service.
  • Cluster layer (Cluster) : encapsulates routing and load balancing of multiple providers, Bridges registries, centers on Invoker, and extends interfaces to Cluster, Directory, Router, and LoadBalance. Multiple service providers are combined into a single service provider to achieve transparency to the service consumer and interact with only one service provider.
  • Monitoring layer (Monitor) : Monitors the number and time of RPC calls. It centers on Statistics and extends interfaces to MonitorFactory, Monitor, and MonitorService.
  • Remote Invocation layer (Protocol) : Dispatcher RPC calls with Protocol, Invoker and Exporter interfaces centered on Invocation and Result. Protocol is the service domain, which is the main functional entry for Invoker exposure and references, and is responsible for the lifecycle management of Invoker. Invoker is the entity domain that is the core model of Dubbo, to which all other models rely or turn. It represents an executable to which invoke calls can be made. It may be a local implementation, a remote implementation, or a cluster implementation.
  • Exchange: Encapsulates the Request and Response mode, and turns it into async. It uses Request and Response as the center and uses Exchange channel, ExchangeClient and ExchangeServer as the expansion interface.
  • Network Transport Layer (Transport) : Abstract MINA and Netty as the unified interface, Message as the center, extended interfaces are Channel, Transporter, Client, Server and Codec.
  • Serialize: Reusable tools with Serialization, ObjectInput, ObjectOutput, and ThreadPool extensions.

Compared with Taobao HSF, what are the characteristics of Dubbo?

1. Dubbo is a lighter deployment mode than HSF

HSF requires the use of specified containers such as JBoss, but also need to add SAR package extension in JBoss and other containers, which is very intrusive to the user’s operating environment. If you want to run on Other containers such as Weblogic or Websphere, you need to extend the container to load by hsF-compatible ClassLoader. Dubbo has no requirements and can run in any Java environment.

2. Dubbo has better scalability than HSF, which is very convenient for secondary development

One framework cannot cover all requirements. Dubbo maintains the concept of equal treatment of third parties, that is, all functions can be extended externally without modifying Dubbo’s native code, including Dubbo’s own built-in functions, as well as third parties, through extensions. However, it is difficult to implement HSF if you want to add functions or replace some parts. For example, Alipay and Taobao use different HSF branches, because the core code was changed when adding functions, so you have to copy a branch to develop separately. Even if HSF is open source at the present stage, it is difficult to reuse unless the architecture is rewritten.

3. HSF relies on many internal systems

For example, configuration center, notification center, monitoring center, single sign-on, etc., there is a lot of work to be done to open source, but Dubbo has set aside extension points for the integration of each system, and has sorted out all dependencies, while providing the open source community with alternatives that users can use directly.

4. Dubbo has more features than HSF

In addition to ClassLoader isolation, Dubbo is basically a superset of HSF, and Dubbo also supports more protocols, more registry integration to accommodate more site architectures.

What scenarios does Dubbo work in?

1.RPC distributed service

As the website grows larger, it is inevitable to split applications for servitization to improve development efficiency, tune performance, and save key competitive resources.

For example, in order to adapt to changing market demands and facilitate data interaction between multiple vertical applications, we extract common businesses as independent modules to provide services for other applications, and the system gradually relies on abstraction and RPC remote service invocation.

2. Configure management

As there are more and more services, the URL information of the service explodes, configuration management becomes very difficult, and the single point of pressure on the F5 hardware load balancer increases.

3. Service dependency

As the dependencies between services become so complex that it is not even clear which application should be launched before which, the architect cannot fully describe the application’s architectural relationships.

4. Expand services

Then, as more and more services are invoked, the capacity of the service is exposed. How much machine support does the service require? When should you add machines? And so on…

All of these problems can be solved with Dubbo.