Java interview summary summary, including Java key knowledge, as well as common open source framework, welcome to read. The article may have wrong place, because individual knowledge is limited, welcome everybody big guy to point out! The article continues to be updated at……

ID The title address
1 Design Mode Interview Questions (Most comprehensive summary of interview questions) Juejin. Cn/post / 684490…
2 Java Basics (most comprehensive interview questions) Juejin. Cn/post / 684490…
3 Java Set interview Questions (the most comprehensive interview questions) Juejin. Cn/post / 684490…
4 JavaIO, BIO, NIO, AIO, Netty Interview Questions (Most comprehensive summary of interview questions) Juejin. Cn/post / 684490…
5 Java Concurrent Programming Interview questions (most comprehensive interview questions) Juejin. Cn/post / 684490…
6 Java Exception Interview Questions (The most comprehensive interview Questions) Juejin. Cn/post / 684490…
7 Java Virtual Machine (JVM) Interview Questions Juejin. Cn/post / 684490…
8 Spring Interview Questions (the most comprehensive interview questions) Juejin. Cn/post / 684490…
9 Spring MVC Interview Questions (The most comprehensive interview Questions) Juejin. Cn/post / 684490…
10 Spring Boot Interview Questions (Most comprehensive summary of interview questions) Juejin. Cn/post / 684490…
11 Spring Cloud Interview Questions (The most comprehensive interview questions) Juejin. Cn/post / 684490…
12 Redis Interview Questions (most comprehensive summary of interview questions) Juejin. Cn/post / 684490…
13 MyBatis Interview Questions (most comprehensive interview questions) Juejin. Cn/post / 684490…
14 MySQL Interview Questions (most comprehensive interview questions) Juejin. Cn/post / 684490…
15 TCP, UDP, Socket, HTTP interview questions Juejin. Cn/post / 684490…
16 Nginx Interview Questions (The most comprehensive interview Questions) Juejin. Cn/post / 684490…
17 ElasticSearch interview questions
18 Kafka interview questions
19 RabbitMQ interview questions (most comprehensive summary of interview questions) Juejin. Cn/post / 684490…
20 Dubbo Interview Questions (the most comprehensive interview questions) Juejin. Cn/post / 684490…
21 ZooKeeper Interview Questions Juejin. Cn/post / 684490…
22 Netty Interview Questions (Most comprehensive summary of interview questions)
23 Tomcat Interview Questions (The most comprehensive interview questions) Juejin. Cn/post / 684490…
24 Linux Interview Questions (Most comprehensive Summary of interview questions) Juejin. Cn/post / 684490…
25 Internet Related interview Questions (the most comprehensive summary of interview questions)
26 Internet Security Questions (Summary of the most comprehensive interview questions)

Basic knowledge of

Why Dubbo?

  • With the further development of servitization, there are more and more services, and the invocation and dependency between services are more and more complex. Service-oriented Architecture (SOA) has been born, and a series of corresponding technologies have been derived. A service framework that encapsulates behavior such as service provision, service invocation, connection processing, communication protocol, serialization, service discovery, service routing, and log output. Thus a service governance framework for distributed systems emerged, and Dubbo was born.

What’s a Dubbo?

  • Dubbo is a high-performance, lightweight, open source RPC framework that provides efficient service governance solutions such as automatic service registration and automatic discovery. It can be seamlessly integrated with the Spring framework.

What are the usage scenarios for 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: No longer need 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 or remove service providers.

What are the core features 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.

What are the 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

Dubbo server registration and discovery process?

  • The Service Container is responsible for starting, loading, and running the service provider.
  • The service Provider registers its services with the registry at startup.
  • At startup, a service Consumer subscribes to the registry for the services it needs.
  • 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 selects one provider from the provider address list to call based on the soft load balancing algorithm. If the call fails, it selects another one to call.
  • The service Consumer and Provider accumulate call times and call time in memory, and regularly send statistical data to Monitor every minute.

Architecture design

What are the layers of Dubbo’s overall architectural design?

  • 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 to RegistryFactory, Registry and RegistryService
  • Routing layer (Cluster) : encapsulates routing and load balancing for multiple providers and Bridges registries, centered on Invoker, with extended interfaces for Cluster, Directory, Router, and LoadBlancce
  • Monitoring layer (Monitor) : Monitors the number and time of RPC calls. It centers on Statistics and extends interfaces to MonitorFactory, Monitor, and MonitorService
  • Protocal (Protocal) : Encapsulates RPC calls with Invocation and Result centered and extends interfaces to Protocal, Invoker, and Exporter
  • Information Exchange layer (Exchange) : encapsulates the request response pattern, synchronous to asynchronous. Based on Request and Response, the expansion interfaces are Exchanger, ExchangeChannel, ExchangeClient and ExchangeServer
  • Network Transport Layer (Transport) : Abstract MINA and Netty as the unified interface, Message as the center, extended interfaces are Channel, Transporter, Client, Server and Codec
  • Serialize: Reusable tools with Serialization, ObjectInput, ObjectOutput, and ThreadPool extensions

How does Dubbo Monitor work?

  • 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 filter chains have MonitorFilters.

  1. MonitorFilter sends data to the DubboMonitor

  2. DubboMonitor temporarily stores aggregated data (within 1min by default) to ConcurrentMap<Statistics, AtomicReference> statisticsMap, and then uses a single thread with 3 threads (thread name: The thread pool of DubboMonitorSendTimer calls SimpleMonitorService every 1min to iterate over statisticsMap data. Reset the AtomicReference of the current Statistics

  3. SimpleMonitorService loads the aggregated data into BlockingQueue Queue (queue uppercase 100000)

  4. SimpleMonitorService using a background thread (thread called: DubboMonitorAsyncWriteLogThread) will be written to the file of data in the queue (this thread to write in the form of infinite loop)

  5. SimpleMonitorService also uses a thread pool of one thread (thread name: DubboMonitorTimer) to graph the statistics in the file every 5 minutes

Distributed framework

What other distributed frameworks are similar to Dubbo?

  • One of the best known is Spring Cloud.

What does Dubbo have to do with Spring Cloud?

  • Dubbo is a product of the SOA era, which focuses 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, relying on the advantages of Spring and Spring Boot, the two frameworks had different goals at the beginning. Dubbo positioning services governance, Spring Cloud is to build an ecosystem.

What are the differences between Dubbo and Spring Cloud?

  • 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.

  • Spring Cloud is based on the Http protocol Rest interface to invoke remote process communication, relatively speaking, Http requests will have larger packets, and occupy more bandwidth. However, REST is more flexible than RPC. The dependence of service providers and callers only depends on a contract, and there is no strong dependence at the code level. This is more appropriate in a microservice environment that emphasizes rapid evolution.

The difference between a Dubbo and a Dubbox?

  • Dubbox is an extension project made by Dangdang based on Dubbo after Dubbo stopped maintenance, such as adding Restful service calls and updating open source components.

The registry

What registries does Dubbo have?

  • 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, the Watch mechanism of Zookeeper is used to change data.
  • Redis registry: Based on Redis, it uses key/ Map storage, key storage service name and type, key storage service URL in map, and value service expiration time. Redis-based publish/subscribe model notifies data changes.
  • Simple registry.
  • You are advised to use Zookeeper as the registry

Can publishers and subscribers still communicate when Dubbo’s registry cluster is down?

  • 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 invocation is made according to the address of the local store.

The cluster

What load balancing strategies does the Dubbo cluster provide?

  • Random LoadBalance: Provider policies are randomly selected to dynamically adjust provider weights. The cross section collision rate is high, the more calls, the more uniform distribution.

  • RoundRobin LoadBalance: Indicates that provider policies are evenly distributed, but requests are accumulated.

  • LeastActive LoadBalance: LeastActive LoadBalance: the LeastActive call policy, the slower provider receives fewer requests.

  • ConstantHash LoadBalance: a consistent Hash policy that ensures that requests with the same parameters are always sent to the same provider. If a machine is down, it can be allocated to other providers based on virtual nodes to avoid drastic changes in providers.

The default is Random Random call.

What are Dubbo’s cluster fault tolerance schemes?

  • Failover Cluster: Automatically switches servers when a failure occurs. If a failure occurs, retry other servers. Typically used for read operations, but retries introduce longer delays.
  • Failfast Cluster: fails quickly. An error is reported immediately after the Failfast Cluster is invoked only once. Typically used for non-idempotent writes, such as new records.
  • Failsafe Cluster: indicates failure security. If an exception occurs, it is ignored. It is used to write audit logs.
  • Failback Cluster: Automatically recovers when a failure occurs. Failed requests are recorded in the background and resent periodically. Typically used for message notification operations.
  • Forking Cluster: Calls multiple servers in parallel and returns if one is successful. It is usually used for read operations that require high real-time performance but waste more service resources. The maximum parallelism can be set by forks= “2”.
  • Broadcast Cluster: Broadcasts calls to all providers one by one. An error is reported on any provider. Typically used to notify all providers to update local resource information such as caches or logs.

The default fault tolerant scheme is Failover Cluster.

configuration

How is the Dubbo configuration file loaded into Spring?

  • When the Spring container is started, it reads some of Spring’s default schemas as well as Dubbo’s custom schemas. Each schema has its own NamespaceHandler. NamespaceHandler uses BeanDefinitionParser to parse configuration information and convert it to loaded bean objects!

What are the core configurations?

The label use explain
<dubbo:service/> Service configuration Used to expose a service, define the meta information of a service, a service can be exposed with multiple protocols, and a service can be registered with multiple registries
<dubbo:reference/> The reference configuration To create a remote service proxy, a reference can point to multiple registries
<dubbo:protocol/> Protocol configuration It is used to configure the protocol information for providing services. The protocol is specified by the provider and passively accepted by the consumer
<dubbo:application/> Application configuration Used to configure the current application information, whether the application is a provider or a consumer
<dubbo:module/> The module configuration This parameter is optional
<dubbo:registry/> Registry Configuration Used to configure connection registry information
<dubbo:monitor/> Monitoring Center Configuration This parameter is optional for configuring the connection monitoring center
<dubbo:provider/> Provider Configuration If a ProtocolConfig or ServiceConfig attribute is not configured, the default value is used. It is optional
<dubbo:consumer/> Consumer allocation If the ReferenceConfig attribute is not configured, the default value is used, which is optional
<dubbo:method/> A method configuration For ServiceConfig and ReferenceConfig specify method-level configuration information
<dubbo:argument> Parameter configuration Used to specify method parameter configuration

If it is a SpringBoot project, you only need to annotate or open the Application configuration file!!

How to set Dubbo timeout?

Dubbo timeout can be set in two ways:

  • Set the timeout on the service provider side. In Dubbo’s user documentation, it is recommended to configure as much as you can on the service side, since 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 has the highest priority. Because the service caller has more flexibility to set timeout control. If the consumer times out, the server thread does not customize and generates a warning.

What happens if the service invocation times out?

  • Dubbo will retry twice by default if the service invocation is unsuccessful.

Communication protocol

What communication framework does Dubbo use?

  • Netty is used as the communication framework by default.

What protocols does Dubbo support, and what are their strengths and weaknesses?

  • Dubbo: Single long connection and NIO asynchronous communication, suitable for large concurrent and small data volume 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. Multiple short connection TCP transport, synchronous transport, suitable for general remote service calls and RMI interoperation. Java serialization suffers from security vulnerabilities when relying on earlier versions of the Common-Collections package.

  • WebService: Remote call protocol based on WebService, integrated with CXF implementation, providing interoperability with native WebService. Multiple short connections, HTTP based transmission, synchronous transmission, suitable for system integration and cross-language invocation.

  • HTTP: A remote invocation protocol based on HTTP form submission, implemented using Spring’s HttpInvoke. Multiple short connections, transport protocol HTTP, mixed sizes of incoming parameters, more providers than consumers, JS calls to applications and browsers.

  • 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, more provider pressure, passable files.

  • Memcache: RPC protocol based on Memcache implementation.

  • Redis: RPC protocol based on Redis.

Design patterns

What design patterns does Dubbo use?

Dubbo framework uses a variety of design patterns during initialization and communication, which can flexibly control functions such as class loading and permission control.

  • The factory pattern

    Provider invokes the Export method of ServiceConfig when exporting the service. There is a field in ServiceConfig:

private static final Protocol protocol =
ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtensi
on(a);
Copy the code

  • The factory pattern

    Provider invokes the Export method of ServiceConfig when exporting the service. There is a field in ServiceConfig:

private static final Protocol protocol =
ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtensi
on(a);
Copy the code

There’s a lot of this code in Dubbo. This is also a factory pattern, except that the implementation class is fetched using the JDKSPI mechanism. The advantage of this implementation is that it is extensible, and to extend the implementation, you can simply add a file to the classpath, with zero code intrusion. In addition, Adaptive implementation, like the one above, can dynamically decide which implementation to call when calling, but because this implementation uses dynamic proxy, it will cause trouble in code debugging, and the implementation class actually called needs to be analyzed.

  • Decorator mode

    Dubbo makes heavy use of the decorator pattern in both startup and invocation phases. In the case of a Provider, this is done in the ProtocolFilterWrapper buildInvokerChain, which implements a Filter that has group= Provider in its annotations. In order, the last call order is:

EchoFilter -> ClassLoaderFilter -> GenericFilter -> ContextFilter ->
ExecuteLimitFilter -> TraceFilter -> TimeoutFilter -> MonitorFilter ->
ExceptionFilter
Copy the code

More specifically, it’s a mix of decorator and chain of responsibility patterns. For example, EchoFilter is used to determine if it is an echo test request, and if it is, it returns the content directly, which is a chain of responsibility. Something like ClassLoaderFilter simply adds functionality to the main function, changing the ClassLoader of the current thread, which is a typical decorator pattern.

  • Observer model

    When Dubbo’s Provider is started, it interacts with the registry to register its own service and then subscribe to its own service. When subscribing, the Provider adopts observer mode and starts a Listener. The registry periodically checks for service updates every five seconds. If there are updates, the provider sends a Notify message to the service provider. After receiving the notify message, the provider runs the notify method of NotifyListener and executes the listener method.

  • Dynamic proxy mode

    The Adaptive implementation of The Dubbo class ExtensionLoader that extends the JDK SPI is a typical dynamic proxy implementation. Dubbo needs flexible control of the implementation class, that is, at the call stage, it dynamically decides which implementation class to call according to the parameters, so the method of using the proxy class can achieve flexible call. Generated proxy class code is ExtensionLoader createAdaptiveExtensionClassCode method. The main logic of the proxy class is to get the value of the specified parameter in the URL parameter as the key to get the implementation class.

Operations management

How can the service be compatible with the old version?

  • You can transition to version, where multiple services of different versions are registered in the registry and services of different version numbers do not refer to each other. This is somewhat similar to the concept of service grouping.

What does the Dubbo Telnet command do?

  • After dubbo service is released, we can use Telnet command to debug and manage. Dubbo2.0.5 or later services provide ports that support Telnet commands

Is Dubbo support service degraded?

  • Set mock= “return NULL” via Dubbo: Reference. You can also change the mock value to true and implement a mock class in the same path as the interface, using the “interface name + mock” suffix. Then implement your own degradation logic in the Mock class

How does Dubbo stop gracefully?

  • Dubbo is implemented with JDK ShutdownHook for graceful shutdown, so if you use kill -9 PID or other forced shutdown commands, graceful shutdown will not be performed, only if you pass kill PID.

SPI

What is the difference between Dubbo SPI and Java SPI?

  • The JDK SPI:

    The STANDARD SPI in the JDK loads all extension implementations at once, and if an extension is time-consuming but not used, it can be a waste of resources. So it’s not realistic to just want to load one implementation

  • DUBBO SPI:

    1, to extend Dubbo, do not need to change the source of Dubbo

    Lazy loading allows you to load only as many extensions as you want at a time.

    3. Added support for extension points IOC and AOP, where one extension point can directly setter to inject other extension points.

    4. Dubbo’s extension mechanism supports third-party IoC containers well, and Spring beans are supported by default.

other

Does Dubbo support distributed transactions?

  • Currently not supported and can be implemented with the TCC-Transaction framework

  • Tcc-transaction is an open source TCC compensatory distributed transaction framework

  • Tcc-transaction avoids its own intrusion into business code through Dubbo’s implicit parameter passing capability.

Can Dubbo cache the results?

  • To improve the speed of data access. < Dubbo: Reference cache= “true” />
  • Cache = “true” cache= “true”

What packages must Dubbo rely on?

  • Dubbo must rely on JDK, otherwise optional.

What serialization methods does Dubbo support?

  • Hessian serialization is used by default. There are also Duddo, FastJson, and Java serialization.

What does Dubbo do for security?

  • 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.

Is the service invocation blocking?

  • It blocks by default and can be called asynchronously, if there is no return value. Dubbo is a non-blocking parallel invocation based on NIO. The client can complete the parallel invocation of multiple remote services without starting multithreading. Compared with multithreading, the overhead is relatively small.

What is the mechanism by which service providers can implement fail-kick?

  • Service failure Kicks out temporary zooKeeper-based nodes.

Can a service be directly connected to multiple registrations of the same service?

  • You can directly connect to a service point-to-point by modifying the configuration, or directly connect to a service through Telnet.

Dubbo service degraded, failed to retry what to do?

  • Mock = “Return NULL” can be set in dubbo: Reference. You can also change the mock value to true and implement a mock class in the same path as the interface, using the “interface name + mock” suffix. Then implement your own degradation logic in the Mock class

What are some of the problems with Dubbo?

  • The corresponding service cannot be found in the registry. Check if the service implementation class has added the @service annotation and cannot connect to the registry. Check if the corresponding test IP in the configuration file is correct

RPC

Why RPC

  • HTTP interface is a communication means often used in the early stage of information island in the case of few interfaces and less interaction between systems. The advantages are simplicity, directness and ease of development. Use the existing HTTP protocol for transport. However, if it is a large website with many internal subsystems and interfaces, the benefits of RPC framework will be shown. The first is the long link, which does not require three handshakes like HTTP for each communication, which reduces the network overhead. Secondly, RPC frameworks generally have registries and rich monitoring management. Publishing, offline interfaces, dynamic extensions, etc., are unaware and unified operations for callers. The third one is security. Finally, the recently popular servitization architecture, servitization governance, RPC framework is a strong support.

  • Socket is a simple way of network communication, only to create the communication channel between the two sides of the communication, and to achieve the function of RPC, it needs to be encapsulated to achieve more functions.

  • RPC is usually written with netty framework and Spring custom annotations to write a lightweight framework. In fact, Netty encapsulates sockets internally. The IO of newer JDK is generally NIO, that is, non-blocking IO

What is the 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.

  • Simply put, RPC is a call from one machine (client) to a function or method (collectively called a service) on another machine (server) with passing arguments and getting the result returned.

PRC architecture Component

  • A basic RPC architecture should contain at least four components:

    1. Client: service caller (service consumer)

    2. Client Stub: Stores the address information of the service end, packages the request parameter information of the Client into network messages, and sends them to the service end through network transmission

    3. The Server Stub receives the request message sent by the client, unpacks it, and then invokes the local service for processing. 4

  • Specific call process:

    1. The service consumer invokes the service to be consumed by invoking the local service.

    2. After receiving the call request, the client stub is responsible for serializing (assembling) information such as methods and input parameters into a message body that can be transmitted through the network.

    3. The client stub finds the remote service address and sends the message to the server over the network.

    4. The server stub decodes the message after receiving it (deserialization operation);

    5. The server stub invokes the local service for relevant processing according to the decoding result;

    6. The local service executes the specific business logic and returns the processing result to the server stub.

    7. The server stub repackages the returned result into a message (serialized) and sends it to the consumer over the network;

    8. The client stub receives the message and decodes (deserializes) it.

    9. The service consumer gets the final result;

The implementation goal of RPC framework is to fully encapsulate steps 2-10 above, that is, to encapsulate the process of calling, encoding/decoding, so that users feel like calling a remote service just like calling a local service.

The difference between RPC and SOA, SOAP, and REST

  • 1, the REST

    It can be seen as a direct application of HTTP protocol. By default, it is based on JSON as the transmission format. It is simple to use, low cost to learn, high efficiency, but low security.

  • 2, the SOAP

    SOAP is a data exchange protocol specification that is a lightweight, simple, XML-based protocol specification. SOAP can be seen as a heavyweight protocol, based on XML, SOAP Security is through the use of XML-Security and XML-signature two specifications formed ws-Security to achieve Security control, has been supported by various manufacturers.

    What are its advantages? Simple summary: easy to use, flexible, cross-language, cross-platform.

  • 3, SOA

    A service-oriented architecture that enables 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 interfaces and communication models. SOA can be seen as a natural extension of the B/S model, XML (a subset of standard Common Markup Language) /Web Services technology.

  • What is the difference between REST and SOAP and RPC?

    There is not much difference between them. Their essence is to provide basic services that can support distribution. The biggest difference lies in the different application scenarios brought by their respective characteristics.

What RPC framework needs to solve?

  • 1. How to determine the communication protocol between the client and the server?
  • 2. How to make network communication more efficient?
  • 3. How are the services provided by the server exposed to the client?
  • 4. How does the client discover these exposed services?
  • 5. How to serialize and deserialize request objects and response results more efficiently?

The implementation basis of RPC?

  • 1. Highly efficient network communication is required. For example, Netty is generally selected as the network communication framework.
  • 2. Need a more efficient serialization framework, such as Google’s Protobuf serialization framework;
  • 3. Reliable addressing (mainly for service discovery), such as using Zookeeper to register services, etc.
  • 4, if it is RPC call with session (state), also need to have session and state hold function;

What are the key technologies used by RPC?

  • 1. Dynamic proxy

    The Java dynamic proxy technology is used when generating Client stubs and Server stubs. You can use either the native dynamic proxy mechanism provided by JDK or the open source CGLib proxy or Javassist bytecode generation technology.

  • Serialization and deserialization

    On a network, all data will be converted to bytes for transmission, so parameters need to be serialized and deserialized in order to be able to be transmitted over the network.

    • Serialization: The process of converting an object into a sequence of bytes is called object serialization, which is the process of encoding. Deserialization: The process of restoring a sequence of bytes to an object is called deserialization of an object, which is the process of decoding. Current efficient open source serialization frameworks: Kryo, FastJson, Protobuf, etc.
    • Deserialization: The process of restoring a sequence of bytes to an object is called deserialization of an object, which is the process of decoding. Current efficient open source serialization frameworks: Kryo, FastJson, Protobuf, etc.

  • 3. NIO communication

    Traditional blocking IO is not suitable for concurrency performance, so we need asynchronous IO, or NIO. Java provides a solution to NIO, and Java 7 provides better NIO.2 support. You can choose Netty or MINA to solve NIO data transfer problems.

  • 4. Service registry

    Optional: Redis, Zookeeper, Consul, Etcd. ZooKeeper is generally used to register and discover services and solve single point of failure and distributed deployment problems (registries).

What are the mainstream RPC frameworks

  • 1, the RMI

    Using java.rmI package implementation, based on Java Remote Method Protocol (Java) and Java native serialization.

  • 2, Hessian

    Remoting OnHTTP is a lightweight remoting onHTTP tool that provides RMI functionality in a simple way. Based on HTTP protocol, using binary codec.

  • 3, protobuf xml-rpc – pro

    Buffers is a Java class library that provides a framework for remote method calls based on Google’s Protocol Buffers Protocol. NIO technology based on Netty. Supports TCP reuse/keep-alive, SSL encryption, RPC call cancellation, and embedded logging.

  • 4, Thrift

    Is a scalable software framework for cross-language services. It has a powerful code generation engine that seamlessly supports C + +, C#, Java, Python and PHP and Ruby. Thrift allows you to define a description file that describes data types and service interfaces. From this file, the compiler easily generates RPC client and server communication code.

    Originally developed by Facebook for RPC communication between languages in the system, facebook contributed to the Apache Foundation in 2007, and it is now one of the OpenSource under Apache. Support RPC communication between multiple languages: THE PHP language client can construct an object and call the corresponding service method to call the Java language service, across the language C/S RPC calls. The underlying communication is based on SOCKET.

  • 5, Avro

    Created by Doug Cutting, the father of Hadoop, Avro aims not only to provide a Thrift like communication middleware, but also to establish a new, standardized Protocol for data exchange and storage in cloud computing. Supports HTTP and TCP.

  • 6, Dubbo

    Dubbo is an open source high-performance service framework of Alibaba, which enables applications to realize the output and input functions of services through high-performance RPC, and can be seamlessly integrated with the Spring framework.

Implementation principle architecture diagram of RPC

That is to say, two servers A and B have one application deployed on server A. If they want to call the function/method provided by the application on server B, they cannot call it directly because they do not have the same memory space. Therefore, they need to express the call semantics and transfer the call data over the network.

For example, server A wants to call A method on server B:

  • 1. Establish communication

    The problem of communication needs to be solved first: that is, if machine A wants to call machine B, it must establish A communication connection.

    This is done primarily by establishing a TCP connection between the client and the server, where all data exchanged by a remote procedure call is transmitted. A connection can be an on-demand connection that breaks after the call, or a long connection that is shared by multiple remote procedure calls.

    Usually this connection can be on-demand connection (you need to call when they first establish a connection, immediately after the call breaking), can also be a long connection (client and server to establish connection to maintain long-term holding, or when any packets to send, can cooperate with heartbeat detection mechanism regularly check whether the connection of the established effective survival). Multiple remote procedure calls share the same connection.

  • 2. Service addressing

    To solve the problem of addressing, that is, how the application on server A tells the underlying RPC framework how to connect to server B (such as A host or IP address) and the specific port, what the name of the method is.

    Usually we need to provide the B machine (hostname or IP address) and a specific port, and then specify the name of the method or function to be called and the input and output parameters to complete a call to the service.

    Reliable addressing (primarily for the discovery of services) is a cornerstone of RPC’s implementation, such as registering services using Redis or Zookeeper.

    • 2.1 From the perspective of service providers:

      When a service provider is started, it needs to register its services with the specified registry so that service consumers can search through the service registry.

      When the service provider stops providing the service for various reasons, it needs to unregister the stopped service to the registry.

      The service provider needs to send heartbeat detection to the service registry periodically. If the service registry considers that the service provider has stopped the service after not receiving heartbeat from the service provider for a period of time, the service registry will remove the service from the registry.

    • 2.2 From the perspective of the caller:

      When the service is started, the caller looks up the address of the service provider to the service registry according to the service he subscribes to.

      When a service consumed by a service caller goes online or offline, the registry notifies the service caller;

      When the service caller goes offline, the subscription is unsubscribed.

  • 3. Network transmission

    • 3.1 serialization

      When the application on machine A initiates an RPC call, the information about the calling method and its input parameters needs to be transmitted to machine B through the underlying network protocol, such as TCP. As the network protocol is based on binary, All the data we transmit needs to be serialized or marshaled into binary before it can be transmitted over the network. The serialized or marshalled binary data is then sent to machine B through addressing operations and network transport.

    • 3.2 deserialization

      When machine B receives the request from the application of machine A, it needs to deserialize the received parameters and other information (the reverse operation of serialization), that is, restore the binary information to the expression in memory. Then find the corresponding method (part of the address) to make the local call (usually through Proxy generation, usually including JDK dynamic Proxy, CGLIB dynamic Proxy, Javassist bytecode generation technology, etc.), and get the return value of the call.

  • 4. Service invocation

    B machine for local calls (through the Proxy agent and reflection calls) after received the return value, at this time also need to be sent back to the return value is A machine, also need the serialized operation, and then through the network to send binary data back to A machine, and when A machine to receive these return values, deserialize operation again, It is restored to an in-memory representation and finally handed over to the application on machine A for relevant processing (generally business logic processing operations).

Usually, a complete RPC call is completed after the above four steps. In addition, the call may need to be retried due to network jitter.