What is Dubbo?
Dubbo is a distributed service framework dedicated to providing high-performance and transparent RPC remote service invocation scheme, as well as SOA Service governance scheme.
In short, Dubbo is a service framework. If there is no distributed demand, there is no need to use it. Only when it is distributed, there is a demand for such a distributed service framework as Dubbo. In essence, it is a service calling thing. In short, it is a distributed framework for far-range service calling (farewell to the web WSDL in the service pattern, registered on Dubbo as a service provider and consumer).
Its core part includes:
1. Remote communication:
It provides Abstract encapsulation for a variety of NiO framework based on long connection, including multiple thread models, serialization, and “request response” mode of information exchange.
2. Cluster fault tolerance:
Provide transparent remote procedure call based on interface method, including multi protocol support, soft load balancing, fault tolerance, address routing, dynamic configuration and other cluster support.
3. Auto discovery
Based on the directory service of the registration center, the service consumer can find the service provider dynamically, make the address transparent, and enable the service provider to smoothly increase or reduce the number of machines.
What can Dubbo do?
1. Transparent remote method call
Just like calling local methods, remote methods can be called with simple configuration without any API intrusion.
2. Soft load balancing and fault tolerance mechanism
It can replace hardware load balancer such as F5 in Intranet, reduce cost and single point.
3. Service automatic registration and discovery
It is no longer necessary to write the address of the service provider. The registry queries the IP address of the service provider based on the interface name, and can smoothly add or delete the service provider.
Dubbo adopts the full spring configuration mode and transparently accesses the application. There is no API intrusion to the application. Just use spring to load the configuration of Dubbo. Dubbo loads based on the Schema Extension of spring.
Architecture and design ideas of Dubbo
Dubbo framework has very high expansibility, mainly adopts the system of micronucleus + plug-in, and has complete documents, which is very convenient for secondary development and highly adaptable.
The overall architecture of Dubbo is shown as follows:
Dubbo framework design is divided into 10 layers, and the top service layer is the interface layer for developers who want to use Dubbo to develop distributed services to implement business logic. In the figure, the interface used by the service consumer is on the left light blue background, the interface used by the service provider is on the right light green background, and the interface used by both parties is on the central axis.
The Dubbo framework design is divided into 10 layers:
- Service interface layer:This layer is related to the actual business logic. It designs the corresponding interface and implementation according to the business of service provider and service consumer.
- Configuration layer (config):The external configuration interface is centered on serviceconfig and referenceconfig. You can configure the class directly by new or generate the configuration class by spring parsing configuration.
- Service proxy layer:The service interface is transparent proxy. The client stub and server skeleton of the service are generated. The service proxy is the center and the extension interface is proxyfactory.
- Service registry:Encapsulates the registration and discovery of service addresses. The service URL is the center, and the extension interfaces are registryfactory, registry and registryservice. There may not be a service registry, where the service provider directly exposes the service.
- Cluster layer:It encapsulates the routing and load balancing of multiple providers, bridges the registry, takes invoker as the center, and extends the interfaces to cluster, directory, router and loadbalance. The combination of multiple service providers into a single service provider makes it transparent to service consumers, and only needs to interact with one service provider.
- Monitor:RPC call times and call time monitoring are based on statistics, and the extended interfaces are monitorfactory, monitor and monitorservice.
- Remote call layer (Protocol):The RPC calls are centered on invocation and result, and the extension interfaces are protocol, invoker and exporter. Protocol is a service domain, which is the main function portal of invoker exposure and reference. It is responsible for the lifecycle management of invoker. Invoker is the entity domain, which is the core model of Dubbo. Other models rely on it or convert it to it. It represents an executable, which can be invoked by invoker. It may be a local implementation, a remote implementation, or a cluster implementation.
- Information exchange layer:Encapsulate the request response mode, synchronous to asynchronous, with request and response as the center, and the extension interfaces are exchange, exchangechannel, exchangeclient and exchange server.
- Transport:Abstract Mina and netty are unified interfaces, message is the center, and extended interfaces are channel, transporter, client, server and codec.
- Data serialization layer:Reusable tools with extension interfaces of serialization, objectinput, objectoutput and ThreadPool.
What are the characteristics of Dubbo compared with Taobao HSF?
1. Dubbo is lighter than HSF
HSF requires the use of specified JBoss and other containers, as well as the addition of SAR package extension in JBoss and other containers, which is highly invasive to the user’s running environment. If you want to run on other containers such as Weblogic or WebSphere, you need to expand the container to be compatible with the classloader load of HSF, while Dubbo has no requirements, and can run in any Java environment.
2. Dubbo has better expansibility than HSF and is convenient for secondary development
It is impossible for a framework to cover all requirements. Dubbo always treats the third party equally, that is, all functions can be expanded on the periphery without modifying Dubbo’s native code, including Dubbo’s own built-in functions. It is also implemented by extension, just like the third party, while HSF is very difficult if you want to add functions or replace some parts of the implementation, such as Alipay and Taobao use different HSF branches, because the core code is changed when adding functions, so it is difficult to reuse HSF at the present stage, unless it is rewritten.
3. HSF relies on multiple internal systems
For example, configuration center, notification center, monitoring center, single sign on, and so on. If we want to open source, we need to do a lot of splitting work. Dubbo has set aside expansion points for each system integration, and has sorted out all the dependencies. At the same time, it provides alternative solutions for the open source community, which users can use directly.
4. Dubbo has more functions than HSF
In addition to classloader isolation, Dubbo is basically a superset of HSF. Dubbo also supports more protocols and more registry integration to adapt to more website architectures.
What scenarios does Dubbo apply to?
1. RPC distributed service
When the website becomes larger, it is inevitable to split the application for service, so as to improve the development efficiency, optimize the performance and save key competitive resources.
For example, in order to adapt to the changing market demand and facilitate the data interaction between multiple vertical applications, we extract the common business as an independent module to provide services for other applications. The system gradually relies on abstraction and RPC remote service invocation.
2. Configuration management
When more and more services are provided, the URL information of services will explode, configuration management becomes very difficult, and the single point pressure of F5 hardware load balancer is also increasing.
3. Service dependence
When further development, the interdependency between services becomes complex, and it is even unclear which application needs to be started before which one, the architect can not completely describe the architectural relationship of the application.
4. Service expansion
Then, with the increasing number of service calls, the problem of service capacity will be exposed. How many machines are needed to support this service? When should I add the machine? Wait…
When these problems are encountered, Dubbo can be used to solve them.