1. What is dubbo
Dubbo is a high-performance, lightweight, open source RPC framework that provides automatic service registration, automatic discovery and other efficient service governance solutions. Dubbo can seamlessly integrate with the Spring framework, using Netty as the default communication framework.
2. What are the usage scenarios of Dubbo
Transparent remote method invocation: Remote methods are called just like local methods, with simple configuration and no API intrusion.
Soft load balancer and fault tolerance mechanism: It can replace hardware load balancers such as F5 on the Intranet to reduce costs and single points.
Automatic service registration and discovery: It is no longer necessary to write out 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 and remove service providers.
3. What are the core functions of Dubbo
Remoting: A network communication framework that abstracts various NIO frameworks, including synchronous to asynchronous and request-response information exchange modes.
Cluster: Service framework that provides 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.
Registry: service registration, based on the Registry directory service, so that service consumers can dynamically find service providers, so that addresses are transparent, so that service providers can smoothly add or subtract machines.
4. Dubbo core components
Provider: exposes the service Provider of the service
Consumer: Invokes the remote service Consumer
Registry: Service registration and discovery Registry
Monitor: Monitors center and access call statistics
Container: service running Container
5. Process of Dubbo service registration and discovery
The Service Container is responsible for starting, loading, and running the service provider.
When a service Provider starts up, it wants to register its services with the registry.
Service Consumer At startup, consumers subscribe to the registry for the services they need.
The Registry returns a list of service provider addresses to the consumer, and if there are changes, the Registry pushes the change data to the consumer based on the long connection.
The service COnsumer, from the provider address list, based on the soft load balancing algorithm, selects one provider to call, and then selects another one to call.
The service COnsumer and Provider accumulate call times and call events in memory, and regularly send statistical data to Monitor every minute.
6. The overall architectural design of Dubbo is layered
Interface Service layer: This layer is related to business logic and designs corresponding interfaces and implementations according to the services of Provider and Consumer.
Configuration layer (Config) : External configuration interface centered on ServiceConfig and ReferenceConfig.
Proxy layer: transparent Proxy of service interface. It generates the client Stub and server Skeleton of the service. It takes ServiceProxy as the center and ProxyFactory as the extended interface.
Service Registration layer (Registry) : encapsulates the registration and discovery of service addresses, centering on service URLS and extending interfaces as iRegistryFactory, Registry, RegistryService
Routing layer (Cluster) : encapsulates routing and load balancing of multiple providers and Bridges registries, with Invoker as the center, extending Cluster,Directory, Router, and LoadBlance.
Monitor layer: Monitors the number of RPC calls and call time. With Statistics as the center, Protocal, Invoker and Exporter are the extended interfaces
Information exchange layer (Exchane) : Encapsulates the request response pattern, synchronous to asynchronous. Based on Request and Response, the extension interfaces are Exchange, Exchange channel, ExchanngeClient and ExchangeServer
Network Transport Layer (Transport) : Abstract MINA and Netty share the same interface, with Message as the center and extended interfaces as Channel, Transporter,Client, Server and Codec.
Data Serialization layer (Serialize) : reusable tools, extension interface for Serialization, OBjectInput, ObjectOutput and ThreadPool.
7. Implementation principle of Dubbo Monitor
The Consumer goes through the Filter chain before making the call. When receiving a request, the provider goes through the Filter chain first and then performs actual business logic processing. By default, both Consumer and Provider filters have MonitorFilters.
(1) MonitorFilter sends data to the DubboMonitor
(2) DubboMonitor temporarily stores the aggregated data to ConcurrentMap<Statistics, AtomicReference> statisticsMap, and then use a thread with 3 threads (thread name: DubboMonitorSendTimer) every 1min,
Call SimpleMonitorService to iterate over Statistics sent from statisticsMap, resetting the AtomicReference of the current Statistics for each one sent.
SimpleMonitorService puts the aggregated data into BlockingQueue Queue (queue size: 100000)
(4) SimpleMonitorService using a background thread (thread called: DubboMonitorAsyncWriteLogThread) will be written to the file of data in the queue (this thread is dead cycle in the form of a written).
SimpleMonitorServer also uses a thread pool of 1 thread (thread name: DubboMonitorTimer) to graph the file statistics every 5 minutes.
8. Relationship between Dubbo and SpringCloud
Dubbo is a product of the SOA era, focusing on service invocation, traffic distribution, traffic monitoring, and fusing. Spring Cloud was born in the era of microservice architecture, considering all aspects of microservice governance. In addition, due to relying on Spring and Springboot, the two frameworks have different goals at the beginning.
Dubbo positioning service governance, Spring Cloud is to build an ecosystem.
Main differences:
The bottom layer of Dubbo uses NIO framework such as Netty and is transmitted based on TCP protocol. With the serialization of Hession, RPC communication is completed.
SpringCloud is based on the Http protocol Rest interface to invoke remote process communication, relatively speaking, Http requests will have larger packets, stack bandwidth will also be more. But Rest is more flexible than RPC in that the dependencies of service providers and callers rely on a single contract, with no strong dependencies at the code level.
Dubbox is an extension project based on Dubbo after Dubbo stopped maintenance.
9. What are the registration centers of Dubbo
Multicast registries: The Multicast registries can register and discover services based on Multicast transmission in the network without any central node but only the broadcast address.
Zookeeper registry: Based on the distributed coordination system Zookeeper, using the Watch mechanism of Zookeeper to change data in real time.
Redis registry: Based on Redis implementation, using key/Map storage, key storage service name and type, Map storage service URL, value service expiration time, based on Redis publish/scheduled pattern notification of data changes.
Simple Registry
You are advised to use Zookeeper as the registry.
If the registry cluster fails, it can communicate. When Dubbo is started, consumers will pull data such as the address interface of registered producers from Zookeeper and cache it locally. Each call is made according to the address of the local store.
What load balancing strategies does Dubbo provide
Random selection: conducive to dynamic adjustment of provider weight. The cross section collision rate is high, the more calls, the more uniform distribution. The default value is random.
Polling selection: Evenly distributed, but with the problem of request accumulation.
Least active: Slower providers accept fewer requests.
Consistent Hash: Requests for the same parameters are always sent to the same provider. When a machine goes down, it can be given to virtual nodes and spread to other providers to avoid drastic changes in providers
11. What are Dubbo’s cluster fault tolerance schemes
Failover Cluster: Automatically fails to switch over servers. If a Failover occurs, retry other servers. Typically used for read operations, but retries introduce longer delays.
Faifast Cluster: Fails quickly. Only one call is initiated and an error is reported immediately. Write operations are usually nonidempotent.
Faisafe Cluster: fail-safe. If an exception occurs, it is ignored. It is used to write audit logs.
Failback Cluster: Automatically recovers after a failure. Failed requests are recorded the day after tomorrow and resent periodically. Typically used for message notification operations.
Forking Cluster: Calls multiple servers in parallel and returns if one is successful. Usually used for real-time requirements of read operations, but need to waste more service resources.
Broaldcast Cluster: Broadcast calls to all providers, one by one, and an error is reported on any one. Typically used to notify all providers to update local resource information such as caches or logs.
12. Dubbo configuration
(1) How to load into Spring
When the Spring container is started, it reads Sprig’s default schema and Dubbo’s custom schema, each of which has its own NamespaceHandler.
NampespaceHandler uses BeanDefinitionParser to parse configuration information and convert it to Bean objects to be loaded.
(2) What are the Dubbo timeout Settings
Set the timeout on the service provider side. In the Dubbo documentation, it is recommended to configure as much as you can on the service side because the service provider is more aware of the service features it provides than the consumer.
Set the timeout period on the service consumer. If the timeout period is set on the service consumer, the service consumer takes precedence over the service consumer. Because the service caller has more flexibility to set timeout control.
Dubbo failed to agree on calling the service and will retry twice by default.
Timeout Settings vary depending on service scenarios, such as core applications and operation data volume.
13. Which design patterns Dubbo uses
Factory mode: Provider invokes the Export method of ServiceConfig when exporting the service. There is a field in ServiceConfig:
ExtensionLoader.getExtensionLoader(Protocol.class)
Decorator pattern: Dubbo makes heavy use of decorator pattern in both startup and invocation phases
Observer mode: When dubbo’s provider is started, it interacts with the registry to register its own service and subscribe to its own service. When subscribing, the Observer mode is used and a Listener is started.
Dynamic proxies: Dubbo’s Adabound implementation of extending the JDK’s SPI class ExtensionLoader is a classic dynamic proxy
14. Dubbo communication protocol
Dubbo uses Netty as its communication framework by default
Dubbo supports the protocol
Dubbo: Single long connection and NIO asynchronous communication, suitable for large concurrent and small number of service calls, and far more consumers than providers. TCP, asynchronous Hessian serialization. Dubbo The Dubbo protocol is recommended.
RMI: using JDK standard RMI protocol implementation, transmission parameters and return parameter objects need to implement Serializable interface, the use of Java standard serialization mechanism, the use of blocking short connection, transmission packet size mixed, the number of consumers and providers is about the same, can transfer files, transmission protocol TCP.
WebService: Remote call protocol based on WebService, integrated with CXF implementation, providing interoperability with native WebService.
HTTP: A remote invocation protocol based on HTTP form submission, implemented using Sprig’s HttpInvoke. Multiple short connections, transport protocol HTTP, mixed sizes of incoming parameters, more providers than consumers, need to give applications and browsers JS calls.
Hessian: Integrated Hessian service, based on HTTP communication, using Servlet to expose the service, Dubbo embedded Jetty as the default implementation of the server, providing interoperation with Hession service. Multiple short connections, synchronous HTTP transfers, Hessian serialization, large incoming parameters, more providers than consumers, provider stress, passable files.
Memcache: Implement RPC protocol based on Memcache.
Redis: RPC protocol based on Redis.
15. Dubbo SPI (Service Provider Interface)
JDK SPI: The STANDARD SPI in the JDK loads all extension implementations at once, if an extension is time-consuming, unused, and wasteful of resources.
Dubbo SPI: Extensions based on Dubbo, using lazy loading, load only what you need, and provide extension point support for IOC and AOP.
(1) To expand Dubbo, do not need to change the source of Dubbo. (2) lazy loading, you can load only the extension implementation you want to load at a time.
(3) Added support for extension points IOC and AOP, one extension point can directly Setter injection of other extension points. (4) Dubbo’s extension mechanism can well support the third-party IOC container, the default Spring Bean.
16, other
(1) Dubbo supports distributed transactions
It is not currently supported and can be implemented using the TCC-Transaction framework.
Tcc-transaction is an open source TCC compensating distributed transaction framework. Tcc-transaction avoids its own intrusion into business code through Dubbo’s implicit parameter passing capability.
(2) Can Dubbo be connected to cache
< Dubbo: Reference cache=true> < Dubbo: Reference cache=true> < Dubbo: Reference cache=true>
(3) Packages that Dubbo must rely on
JDK
(4) which serialization methods are supported
Default Hessian serialization, Fastjson, Java built-in serialization
(5) Dubbo’s safety measures
Dubbo prevents users from directly connecting by bypassing the registry through Token tokens, and then manages authorization on the registry.
Dubbo also provides a blacklist and whitelist of services to control which callers are allowed by the service.
(6) The service invocation is blocked
Dubbo is based on NIO’s non-blocking implementation of parallel calls. Clients can call multiple remote services in parallel without having to start multiple threads.
Less overhead than multithreading, asynchronous calls return a Future object.
(7) The service provider can realize the principle of failure elimination
Temporary node principle based on the registry (Zookeeper)
(8) The Dubbo service is degraded. Try again if the Dubbo service fails
Mock = “Return NULL” can be set in dubbo: Reference.
17, the RPC
(1) What is RPC
Remote Procedure Call Protocol (RPC) is a Protocol that requests services from Remote computer programs over the network without understanding the underlying network technology.
In short, RPC enables programs to access remote system resources just as they access local system resources. Some of the key aspects include: communication protocol, serialization, resource (interface) description, service framework, performance, language support, etc.
To put it simply: RPC is a call from one machine (client) to a function or method (collectively called a service) on another machine (server) with a passing argument.
(2) RPC architecture components
A basic RPC architecture should contain at least four components
Client: service caller (service consumer)
Client stub: stores the address information of the server, packages the request parameters of the client into network messages, and sends them to the server over the network.
The server stub accepts the request message sent by the client, unpacks it, and invokes the local service for processing
Server: The real provider of the service.
(3) The difference between RPC and SOA, SOAP, REST
REST is a direct application of HTTP. By default, IT uses JSON as the transmission format. It is easy to use, low cost to learn, high efficiency, and low security.
SOAP:SOAP is a tree exchange protocol specification, which is a lightweight, simple, XML-based protocol specification.
SOA: A service-oriented architecture that enables the distributed deployment, composition, and use of loosely coupled, coarse-grained application components over a network as required. The service layer is the foundation of SOA and can be invoked directly by applications to effectively control the artificial dependencies in the system that interact with software agents.
SOA is a coarse-grained, loosely coupled service architecture in which services communicate with each other through simple, precisely defined interfaces that do not involve underlying programming and communication models. SOA can be seen as an extension of the B/S model, XML (a subset of standard Common Markup Language) /Web Service technology.
18, a Zookeeper
1. What is Zookeeper
Zookeeper is an open source distributed coordination service. It is a software that provides consistency services for distributed applications. Distributed applications can implement such things as data publishing/subscription, load balancing, service naming, distributed coordination/notification based on Zookeeper.
Cluster management, Master election, distributed lock and distributed queue and other functions.
The goal of Zookeeper is to encapsulate key services that are complex and error-prone, providing users with easy-to-use interfaces and a stable system with high performance
Zookeeper ensures the following distributed consistency