One. What is Dubbo?
Dubbo is a distributed, high-performance, transparent RPC service framework that provides efficient service governance solutions such as automatic service registration, automatic discovery, and seamless integration with the Spring framework.
In short, Dubbo is a service framework. If there is no need for a distributed service framework, there is no need for a distributed service framework like Dubbo. It’s essentially a service invocation thing, and it’s basically a framework for remote service invocation. RPC stands for Remote Service Invocation Protocol, which means that two servers interact with data.
Its core parts include:
1. Remote communication provides an abstract encapsulation of a variety of long-link based NIO frameworks, including multiple threading models, serialization, and “request-response” mode of information interaction.
2. Cluster fault tolerance Provides transparent remote procedure calls based on interface methods, including multi-protocol support, and cluster support such as soft load balancing, failure tolerance, address routing, and dynamic configuration.
3. Automatic discovery based on registry directory services, so that service consumers can dynamically find the service provider, make the address transparent, so that the service provision method can smooth increase or decrease the machine.
The origin of Dubbo?
With the rapid development of the Internet, Web applications continue to grow in size and typically go through the following four stages of development.
1. Single application architecture
When the traffic on your site is low, all you need is a single application that pulls everything together.
2. Vertical application architecture
As the number of visits increases, a single application is divided into multiple applications based on service lines to improve efficiency. To improve efficiency, separate a single application into multiple applications based on lines of business.
3. Distributed Service framework
With the increasing number of vertical applications, the interaction between applications is inevitable. Core businesses are extracted as independent services and a stable service center is gradually formed to enable front-end applications to respond to changing market demands more quickly. At this point, the distributed Service Framework (RPC) for improving business reuse and integration is key.
4. Stream computing architecture
When the number of services increases, problems such as capacity evaluation and waste of small service resources gradually appear. In this case, a scheduling center should be added to manage cluster capacity in real time based on access pressure to improve cluster utilization. At this point, a resource scheduling and governance center (SOA) to improve machine utilization is key.
Iii.Dubbo architecture and design ideas?
The Dubbo framework design is divided into 10 layers, with the top Service layer being the interface layer for the developers who actually use Dubbo to develop distributed services to implement the business logic. In the figure, the interfaces used by the service consumer are on the blue background on the left, the interfaces used by the service provider are on the green background on the right, and the interfaces used by both parties are on the central axis.
Description of each layer:
Config configuration layer: External configuration interface, centered on ServiceConfig and ReferenceConfig, can directly initialize configuration classes or generate configuration classes through Spring resolution configuration.
Proxy ServiceProxy layer: the service interface is transparent Proxy. The client Stub and server Skeleton of the service are generated. The ServiceProxy is used as the center and the extended interface is ProxyFactory.
Registry Registry layer: encapsulates the registration and discovery of service addresses. It centers on service urls and extends interfaces to RegistryFactory, Registry, and RegistryService.
Cluster routing layer: encapsulates routing and load balancing for multiple providers and Bridges the registry, centered on Invoker and extending interfaces to Cluster, Directory, Router, and LoadBalance.
Monitor: Monitors the number and time of RPC calls. Statistics is the center. The extended interfaces are MonitorFactory, Monitor, and MonitorService.
Protocol Remote Invocation layer: Encapsulates RPC Invocation, centered on Invocation and Result, and extends the interfaces to Protocol, Invoker, and Exporter.
Exchange information Exchange layer: Encapsulates Request and Response mode, transfers synchronization to asynchronous, centers on Request and Response, and extends interfaces such as ExchangeChannel, ExchangeClient, and ExchangeServer.
Transport Network Transport layer: Abstract MINA and Netty are unified interfaces. The MINA and Netty interfaces are messar-centric and extended interfaces include Channel, Transporter, Client, Server, and Codec.
Serialize Data Serialization layer: reusable tools. The extended interfaces are Serialization, ObjectInput, ObjectOutput, and ThreadPool.
Iv. What situations does Dubbo apply to?
1.RPC distributed service When a website grows in size, it is inevitable to split applications for servitization to improve development efficiency, optimize performance, and save key competitive resources. For example: in order to adapt to the changing market demand, as well as the convenience of data exchange between multiple vertical applications, we extracted the common business as independent module call, to provide services for other applications, the system gradually relied on and abstract, and RPC remote service call.
2. Configuration management When there are more and more services, the URL information of services will explode. Configuration management becomes very difficult, and the single point pressure of hardware load balancing becomes greater and greater.
**3. Service dependencies ** As we develop further, the dependencies between services become so complex that it is not even clear which application to start before.
** The volume of the service is increasing, and the capacity of the service is exposed. How many machines does this service require? When to add the machine and so on.
5.Dubbo’s best interview questions
1. The core features of Dubbo****?
There are three core features:
· Remoting** : ** network communication framework, provides the abstract encapsulation of various NIO frameworks, including “synchronous to asynchronous” and “request-response” mode of information exchange.
· Cluster** : A service framework ** that provides transparent remote procedure calls based on interface methods, including multi-protocol support, and Cluster support such as soft load balancing, failure tolerance, address routing, dynamic configuration, etc.
· Registry** : Service Registry**, based on the Registry directory service, so that service consumers can dynamically find the service provider, make the address transparent, so that the service provider can smoothly add or reduce machines.
2. Core components of Dubbo****?
3.Dubbo**** Service registration and discovery process?
Process description:
· Provider binds the specified port and starts the service
· Refers to the donor connecting to the registry and concurrently sending local IP, port, application information and service provision information to the registry storage
· Consumer: Connects to the registry and sends application information and requested service information to the registry
· The registry matches a list of providers to the Consumer application cache based on the service information requested by the Consumer.
· The Consumer chooses one of the cached consumers to make the call when making the remote call.
· Provider status changes are notified to the registry in real time and pushed to consumers from the registry in real time
Design reasons:
· When the Consumer and Provider are uncoupled, both parties can add or subtract nodes horizontally.
· The registry can act as a peer cluster for itself, dynamically add or subtract nodes, and automatically switch to another one when any one goes down
· Decentralization: both parties do not directly rely on the registry, and service invocation will not be affected even if all the registries are down for a short time
· The service provider is stateless, and the use will not be affected after any one of them goes down
4. Architecture design of Dubbo****?
The Dubbo**** framework design is divided into 10 layers:
Service interface Layer (Service) : This layer is related to the actual business logic, according to the Service provider and Service consumer business design corresponding interface and implementation.
Configuration layer (Config) : External configuration interface, centered around ServiceConfig and ReferenceConfig.
Proxy layer: transparent Proxy for service interfaces, and generate the client Stub and server Skeleton of services.
Service Registry: Encapsulates the registration and discovery of service addresses, centered on the service URL.
Cluster: Encapsulates routing and load balancing for multiple providers and Bridges registries, centered around Invoker.
Monitor: Monitors the number and time of RPC calls.
Protocol: Encapsulates RPC calls, centred on Invocation and Result, and extends the interfaces to Protocol, Invoker, and Exporter.
Information Exchange layer (Exchange) : Encapsulates the Request and Response mode, from synchronous to asynchronous, and centers on Request and Response.
Network Transport: Mina and Netty are abstracted as unified interfaces, centred on Message.
5. The service invocation process of Dubbo****?
6. What protocols does Dubbo**** support? What are the application scenarios of each protocol?
· DuBBo ** : ** Single long connection and NIO asynchronous communication, suitable for large concurrent service calls with small data volume, and consumers far more than providers. Transport protocol TCP, asynchronous, Hessian serialization;
· RMI ** : ** uses JDK standard RMI protocol implementation, transmission parameter and return parameter objects need to implement Serializable interface, use Java standard serialization mechanism, use blocking short connection, transmission packet size mixed, the number of consumers and providers are similar, can transfer files, transmission protocol TCP. Multiple short connections, TCP protocol transport, synchronous transport, for general remote service invocation and RMI interoperability. There is a security vulnerability in Java serialization that relies on a lower version of the Common-Collections package.
· WebService ** : ** remote call protocol based on WebService, integrated with CXF implementation, providing interoperability with native WebService. Multiple short connections, based on HTTP transmission, synchronous transmission, suitable for system integration and cross-language calls;
· HTTP ** : ** Remote call protocol based on HTTP form submission, implemented using Spring’s HttpInvoke. Multiple short connections, HTTP transport protocol, mixed parameter sizes, more providers than consumers, JS calls to the application and browser;
· Hessian ** : ** integrates hessian services, based on HTTP communication, using Servlet exposed services, implemented by default when Dubbo is embedded with Jetty as a server, and provides interoperability with Hession services. Multiple short connections, synchronous HTTP transmission, Hessian serialization, large incoming parameters, the provider is larger than the consumer, the provider pressure is large, can transmit files;
· MemCache ** : ** RPC protocol based on memcached
· Redis ** : ** RPC protocol based on Redis
7. What protocol does Dubbo **** recommend?
By default, the dubbo protocol is used
8. What registries are available at Dubbo****?
· Multicast**** Registry: The Multicast registry does not require any central node, just a broadcast address, to register and discover services. Based on the network multicast transmission;
· Zookeeper**** Registry: Implemented based on the distributed coordination system Zookeeper, using the Watch mechanism of Zookeeper to realize data change;
· Redis **** Registry: Based on Redis, it adopts key/Map storage, including the name and type of key storage service, the URL of key storage service in Map, and the expiration time of value service. Redis-based publish/subscribe model to notify data changes;
· Simple**** registry
9. Service governance for Dubbo****?
L Too many service urls are difficult to configure
L Load balancing Cluster deployment is required when the node pressure is too high
L Service dependencies are confused and startup sequence is unclear
L Too many services make it difficult to analyze performance indicators. You need to monitor performance indicators
10. The registry cluster for Dubbo**** is down. Can publishers and subscribers still communicate?
Yes, when dubbo is started, consumers will pull data such as the address and interface of the registered producer from ZooKeeper and cache it locally. Each time a call is made, the call is made at the locally stored address.
11. The relationship between Dubbo**** and Spring?
Dubbo adopts the full Spring configuration mode to access applications transparently without any API intrusion. You only need to use Spring to load Dubbo configuration. Dubbo is loaded based on Spring’s Schema extension.
12. What communication framework does Dubbo**** use?
The NIO Netty framework is used by default
13.Dubbo**** What load balancing policies does the cluster provide?
· Random LoadBalance: Random selection of provider policy is conducive to dynamic adjustment of provider weight. The higher the cross section collision rate, the more calls, the more uniform the distribution;
· RoundRobin LoadBalance: Round selection of providers, evenly distributed, but with the problem of request accumulation;
· LeastActive LoadBalance: Minimum active call policy, which solves the problem of slow providers receiving fewer requests;
· ConstantHash LoadBalance: Consistent Hash policy, so that the requests with the same parameters are always sent to the same provider. When a machine breaks down, it can be allocated to other providers based on virtual nodes to avoid drastic changes of providers;
The default value is Random
14. What are the cluster fault tolerant solutions of Dubbo****?
, a Failover Cluster
· Automatic switchover if failure occurs. When failure occurs, retry other servers. Usually used for read operations, but retries can cause longer delays.
· Failfast Cluster
· Fast failure, only one call is made, and an error will be reported immediately if the call fails. Usually used for nonidempotent write operations, such as adding a record.
Failsafe, Cluster
· Safe failure. When an exception occurs, it is directly ignored. It is used to write audit logs.
Failback, Cluster
· The failure is automatically recovered, the background records the failed request, and periodically resends it. Commonly used for message notification operations.
, Forking Cluster
· Call multiple servers in parallel and return as long as one is successful. It is usually used for read operations that require high real-time performance, but waste more service resources. You can set the maximum number of parallelisms by using Forks = “2”.
Broadcast, a Cluster
· Broadcast calls to all providers, one by one, and any error will be reported. It is typically used to notify all providers to update local resource information such as caches or logs.
15. The default cluster fault tolerant solution for Dubbo****?
Failover Cluster
16. What serialization methods does Dubbo**** support?
By default, Hessian serialization is used, and Duddo, FastJson, and Java come with serialization.
17. How can I set the Dubbo**** timeout period?
There are two ways to set the Dubbo timeout:
· Set timeouts on the service provider side. In Dubbo’s user documentation, it is recommended to configure as many as possible on the service side, because the service provider is more aware of the service features it provides than the consumer.
· The timeout period is set on the service consumer side. If the timeout period is set on the consumer side, the consumer side is the main one, that is, the priority is higher. Because the service caller is more flexible in setting the timeout. If the consumer times out, the server thread is not customized and a warning is generated.
**18.** Service call timeout problem How to solve?
By default, Dubbo will retry twice if it fails to invoke the service.
19. How does Dubbo**** solve the security mechanism?
Dubbo uses tokens to prevent users from bypassing the registry and then manages authorization on the registry. Dubbo also provides a service blacklist and whitelist to control the callers allowed by the service.
20. What’s the difference between dubbo and dubbox?
Dubbox builds on Dubbo by adding restful service calls and updating open source components.
**21.** What are the distributed frameworks other than Dubbo?
Spring Cloud is well known, of course, there are similar frameworks abroad.
22. What’s the relationship between Dubbo**** and Spring Cloud?
Dubbo is a product of the SOA era and focuses on service invocation, traffic distribution, traffic monitoring, and circuit breaker. Spring Cloud was born in the era of micro-service architecture, considering all aspects of micro-service governance. In addition, due to the advantages of Spirng and Spirng Boot, the two frameworks had inconsistent goals at the beginning. Dubbo positioned service governance and Spirng Cloud as an ecology.
23. What’s the difference between Dubbo **** and Spring Cloud?
The biggest difference: The bottom layer of Dubbo is using NIO framework like Netty, which is based on TCP protocol transmission, with Hession serialization to complete RPC communication. SpringCloud is based on Http protocol +Rest interface to call the communication of remote process, relatively speaking, Http request will have a larger packet, the bandwidth will be more. However, REST is more flexible than RPC. The service provider and caller only rely on a paper contract, and there is no strong dependency at the code level. This is more appropriate in the context of rapidly evolving microservice environment.
