preface
Welcome to our GitHub repository Star: github.com/bin39232820… The best time to plant a tree was ten years ago, followed by now
Tips
The interview guide series, which in many cases does not delve into the details, is a way for students to review their knowledge in the role of the interviewee, so I assume that most of the things you, as the interviewer, know.
www.processon.com/view/link/6…
This is the brain map address
Where t
What about Dubbo’s framework? I think at least half of your company’s distributed technology stack is it, so today small six six for everyone to review it. Can ask a lot of actually, ha ha.
Then below is a summary of previous articles
- 2021-Java Backend Engineer Interview Guide (Introduction)
- 2021-Java Backend Engineer Interview Guide
- 2021-Java Backend Engineer Interview Guide -(Concurrency – Multithreading)
- 2021-Java Backend Engineer Interview Guide -(JVM)
- 2021-Java Backend Engineer Interview Guide -(MySQL)
- 2021-Java Backend Engineer Interview Guide -(Redis)
- Java Backend Engineer Interview Guide -(Elasticsearch)
- 2021-Java Backend Engineer Interview Guide -(Message Queue)
- 2021-Java Backend Engineer Interview Guide -(SSM)
- 2021-Java Backend Engineer Interview Guide (SpringBoot+SpringCloud)
- 2021-Java Backend Engineer Interview Guide -(Distributed Theory +Zookeeper)
- 2021-Java Backend Engineer Interview Guide -(Computer Networking)
- 2021-Java Backend Engineers must know -(Operating system)
Have you ever used Dubbo? Do you know what he does?
Apache Dubbo is a high-performance, lightweight, open source Java service framework
It provides six core capabilities: high-performance RPC calls for interface proxies, intelligent fault tolerance and load balancing, automatic service registration and discovery, highly scalable capabilities, run-time traffic scheduling, and visual service governance and operation. Dubbo is an RPC framework.
What is RPC
Remote Procedure Call (RPC) is a protocol that requests services from Remote computer programs over the network without understanding the underlying network technology. For example, two different services A and B are deployed on two different machines. What if service A wants to invoke A method in service B? Using HTTP requests is certainly possible, but can be cumbersome. RPC was invented to make calling remote methods as easy as calling local methods.
In fact, AS far as I’m concerned, THE scope of RPC is quite broad, such as a few simple production cases
- First of all, I think fegin used by few companies is actually a simple RPC, right? Because it also blocks the underlying calls, it makes calling remote methods as easy as calling local ones.
- The second one is called Dubbo. The biggest difference between Dubbo and Fegin, I think, is that it has a different way of network transmission. However, it is also an RPC framework with better performance, but it does not currently support cross-language calls.
- Third thrift, why does little Six mention it? When a company is relatively large, such as a big Internet company, certainly different departments use different language, then you have to go on him, we have such a service.
Young man: Yes, tell me the principle of RPC
- A service consumer (client) invocation invokes a service as a local invocation;
- After receiving the call, the Client stub is responsible for assembling methods and parameters into a message body that can be transmitted over the network.
- The Client stub finds the service address and sends the message to the server.
- The Server Stub decodes the message after receiving it.
- The Server stub invokes the local service based on the decoding result.
- The local service executes and returns the result to the Server stub;
- The Server Stub packages the returned result into a message and sends it to the consumer;
- The Client stub receives the message and decodes it.
- The service consumer gets the end result.
In fact, it is quite simple, you think clearly know what is, heh heh. You can understand memory, you have to understand it
Let’s talk about Dubbo again. Are you familiar with the various modules of Dubbo? Know what each module does
- Config configuration layer: external configuration interface, centering on ServiceConfig and ReferenceConfig, can directly initialize configuration classes, or generate configuration classes through Spring configuration parsing
- Proxy ServiceProxy layer: transparent proxy of service interfaces. The client Stub and server Skeleton of the service are generated. The extension interface is ProxyFactory
- Registry layer: encapsulates the registration and discovery of service addresses, centering on service URLS and extending interfaces as RegistryFactory, Registry, and RegistryService
- Cluster routing layer: encapsulates routing and load balancing of multiple providers, Bridges registries, centers on Invoker, and extends interfaces to Cluster, Directory, Router, and LoadBalance
- Monitor monitoring layer: Monitors the number and time of RPC calls. It centers on Statistics and extends interfaces to MonitorFactory, Monitor, and MonitorService
- Protocol Remote Invocation layer: Encapsulates RPC Invocation with Protocol, Invoker, and half interface, based on Invocation and Result
- Exchange information exchange layer: It encapsulates the Request and Response mode, turns synchronous to asynchronous, uses Request and Response as the center, and uses exchange channel, ExchangeClient and ExchangeServer as the expansion interface
- Transport Network transport layer: Abstract MINA and Netty as the unified interface, Message as the center, extended interfaces are Channel, Transporter, Client, Server, Codec
- Serialize data Serialization layer: reusable tools with Serialization, ObjectInput, ObjectOutput, and ThreadPool extensions
Talk about Dubbo’s architecture
Architecture diagram of Dubbo
- Provider: exposes the service Provider of the service
- Consumer: Service Consumer that invokes the remote service
- Registry: a Registry for service registration and discovery (zK in general)
- Monitor: monitors the number and duration of service invocation
- Container: service run Container (Spring’s Container)
Call relationship description:
- The service container is responsible for starting, loading, and running the service provider.
- At startup, service providers register their services with the registry.
- At startup, service 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, selects one provider to call based on the soft load balancing algorithm. If the call fails, selects another one to call.
- Service consumers and providers accumulate calls and call times in memory and regularly send statistics to the monitoring center every minute.
Talk about Dubbo’s architectural design approach SPI
For a middleware design principle, plug-in design, any function can be designed.
- Protocol extensions
- Call interception extension
- Reference listening extension
- Exposure monitor extension
- The cluster expansion
- Routing extension
- Load Balancing expansion
- Merge result extension
- Registry Expansion
- Monitoring Center Expansion
- Extension points load extensions
- Dynamic proxy extension
- Compiler extension
- Dubbo configuration center extension
- Message dispatch extension
- Thread pool extension
- Serialized extension
- Network transmission extension
- Information exchange extension
- Network extension
- Telnet Command Extension
- Status check extension
- Container extension
- Cache extension
- Verify the extension
- Log Adaptation Extension
In fact, small 66 think this is a code design principle, but in fact, many times, we do business can also be designed like this, high cohesion, low coupling.
Nice guy. Tell me about Dubbo’s protocol
Dubbo supports different communication protocols
- Dubbo agreement
The default is the DuBBo protocol, a single long connection, NIO asynchronous communication, based on hessian as the serialization protocol. The scenario is that the amount of data transferred is small (less than 100KB per request), but the concurrency is high.
In order to support high concurrency scenarios, service providers typically have only a few machines, but service consumers have hundreds of machines, which can reach hundreds of millions of calls per day! Long connections are the most appropriate, which is to maintain one long connection for each service consumer, maybe 100 connections in total. Based on our selector mode
- The rmi protocol
Go Java binary serialization, multiple short connections, suitable for consumers and providers of the same number of cases, suitable for file transfer, generally less use.
- Hessian protocol
Hessian serialization protocol, multiple short connections, suitable for the number of providers than the number of consumers, suitable for file transfer, generally used less.
Tell me what the serialization protocols are
Dubbo supports hession, Java binary serialization, JSON, SOAP text serialization multiple serialization protocols, ProBuffer. But Hessian is its default serialization protocol, and ProBuffer is the fastest.
Why probuffer is the fastest
- It uses the Proto compiler to automatically serialize and deserialize and is very fast, which should be 20-100 times faster than XML and JSON.
- Its data compression is good, that is, it serialized data volume is small. Because of its small size, the bandwidth and speed of transmission will be optimized.
Talk about the load balancing strategy Dubbo provides
- Random LoadBalance(default, weighted Random load balancing mechanism)-> Random, set Random probability according to the weight. The probability of collision on a section is high, but the distribution is more uniform with the increase of adjustment dosage, and the distribution is more uniform after using weight according to the probability, which is conducive to dynamic adjustment of provider weight.
- RoundRobin LoadBalance->(not recommended, load balancing based on weights)
- LeastActive LoadBalance-> Minimum number of active calls, random for the same number of active calls. Make slower providers receive fewer requests, because slower providers have a larger difference in the count before and after the invocation.
- ConsistentHash LoadBalance-> ConsistentHash, where requests with the same parameters are always sent to the same provider. (If you don’t want random load balancing and you want all of your requests to go to the same node, use this consistent hash strategy.) When a provider hangs, the requests originally sent to that provider are spread to other providers based on the virtual nodes without causing drastic changes.
What are the considerations for designing your own RPC framework
Haha, in fact, this is also considering a big picture, ask is still very big, before small six six write a simple RPC wheel, you can have a look, basically is the duboo package of each module in their own simple implementation. The wheels of a Web backend framework roll themselves (easy) from handling Http requests [Netty request-level Web servers] to MVC [interface encapsulating and forwarding], to IOC [dependency injection], to AOP [aspect], to RPC [remote procedure calls] and finally to ORM [database operations].
Github.com/bin39232820…
The end of the
In fact, Dubbo a lot of things, but to go into depth, every point can go with the source code, there is a chance to follow small 66. In fact, I think the official document of Dubbo is very good, you don’t need to use Dubbo, I suggest you to read it, for our development can have a lot of inspiration, I have the opportunity to tell you.
Daily for praise
Ok, everybody, that’s all for this article, you can see people here, they are real fans.
Creation is not easy, your support and recognition, is the biggest motivation for my creation, we will see in the next article
Wechat search “six pulse Excalibur program life” reply 888 I find a lot of information to you