Dubbo is an excellent high-performance service framework of Ali Open Source.
Its biggest characteristic is that the architecture is carried out in a hierarchical manner, which can make each layer decoupled or loose coupling to the maximum extent. The application realizes the output of the service provider and the input function of the service consumer through high-performance RPC.
By the end of this article, you will have gained the following knowledge:
- What is the Dubbo
- Dubbo’s core features
- Dubbo’s architectural design
- Difference between Dubbo and HSF
- Four usage scenarios for Dubbo
Only when we understand these, we can clearly know how to choose and use them in the subsequent development.
01 What is 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).
02 Dubbo’s core features
Dubbo’s core features 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. The cluster is fault tolerant
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.
03 Architectural design of Dubbo
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:
Overall architecture diagram of Dubbo
Dubbo architecture Diagram Notes:
- The interfaces used by service consumers are shown on the left with a light blue background;
- The interfaces used by service providers on the right with a light green background;
- Located on the central axis is the interface used by both sides;
- The top Service layer is the interface layer that is left to developers who actually want to develop distributed services using Dubbo to implement the business logic.
The Dubbo framework is divided into 10 layers:
1. Service Interface Layer
This layer is related to the actual business logic and designs the corresponding interfaces and implementations according to the business of the service provider and service consumer.
2. Configuration layer (Config)
External configuration interface, centering on ServiceConfig and ReferenceConfig, can directly new configuration class, or can generate configuration class through Spring configuration analysis.
3. Proxy
Service interface Transparent proxy, which generates the client Stub and server Skeleton of the service, takes ServiceProxy as the center, and extends the interface as ProxyFactory.
4. Service Registry layer
Encapsulate the registration and discovery of service addresses, centering on service urls, and extending interfaces to RegistryFactory, Registry and RegistryService. There may be no service registry, in which case the service provider directly exposes the service.
5. Cluster Layer
Encapsulates routing and load balancing for multiple providers and Bridges registries centered on Invoker and extending 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.
6. Monitor layer
Monitor the number of RPC calls and call time. With Statistics as the center, MonitorFactory, Monitor, and MonitorService are extended interfaces.
7. Remote Call Layer (Protocol)
Encapsulate RPC calls with Invocation and Result centered and extended interfaces to Protocol, Invoker, and Exporter. 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. The Invoker is the entity domain that is the core model of Dubbo, to which other models converge or transform, and which represents an executable to which invoke calls can be made. It may be a local implementation, a remote implementation, or a cluster implementation.
8. Information Exchange Layer
It encapsulates the Request and Response mode, and transfers from synchronous to asynchronous. The interface is Request and Response, and the expansion interface is ExchangeChannel, ExchangeClient and ExchangeServer.
9. Network Transport layer
Abstract Mina and NetTY are unified interfaces with Message as the center, and extended interfaces are Channel, Transporter, Client, Server and Codec.
10. Data Serialization Layer (Serialize)
Reusable tools extend interfaces to Serialization, ObjectInput, ObjectOutput, and ThreadPool.
04 Differences between Dubbo and HSF
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
Configuration centers, notification centers, monitoring centers, single sign-on (SSO), and so on. There’s a lot of stripping to be done to open source, but Dubbo has set aside extension points for each system integration, cleaned up all dependencies, and provided 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.
06 Application Scenarios of Dubbo
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 service dependencies 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.
-end-
If you think it’s good, please give it a thumbs up. Thank you.
Click “like” + “forward” + “private message” to get the following information immediately.
