The introduction

With the continuous increase of the volume of Internet applications, in order to correspond to the experience effect of a large number of users and provide the availability of applications, micro-services emerge at the right moment. Micro-services make the business of applications have higher cohesion, and decoupled the overall application as a service. In addition to the asynchronous MQ communication between microservices, there are commonly used RPC notification mechanisms based on synchronization, such as HTTP-based GRPC, BRPC and Dubbo, which is widely used in China. Congrue is using DUBOO and has a general understanding of its functional components. I planned to have a look at the source code, but Congrue did not spare time. Recently, he took a break from his busy schedule to have a look at Dubbo.

directory

  • Outline framework design
  • Source code analysis
    • Application protocol
      • Registrar protocol
        • Service Export
        • The service registry
        • A subscription service
        • The service Invoker
      • Dubbo agreement
    • Data Transport
      • The service side
      • The client
    • Message codec
      • Message encoder
      • Message decoder
  • conclusion
  • The attached

Outline framework design

The Dubbo framework consists of serialization, message layer, transport layer and protocol layer. Serialization is mainly the serialization of request messages and response messages, such as Javad-based ObjectOut/InputStream serialization and JSON-based serialization. The message layer provides the encoding and decoding of the service request message of the consumer and the response message of the service provider. The transport layer mainly establishes the communication channel between consumers and service providers and transmits service request and response data, such as Netty and Mina based data, which is Netty by default. The protocol layer first exposes service providers and consumers through export based on relevant protocols, that is, in Registry, consumers subscribe to service providers that respond through Registry. When they find a service provider, they establish a connection with the service provider. The registration protocol is based on Zookeeper. Redis et al., there is also a registry directory service in the registration protocol, which provides a list of consumers and servers, and selects servers based on load balancing policies. After receiving the service request from the consumer, the service provider invokes the corresponding Invoker service according to the relevant protocol. In fact, in DubboProtocol, the protocol first exports the service, and the consumer sends an RPC request to invoke the Invoker in the Exporter service container.

Source code analysis

Dubbo framework design source code interpretation first (service and reference bean initialization)

Dubbo framework consists of message layer, transport layer and protocol layer. The message layer provides the encoding and decoding of the service request message of the consumer and the response message of the service provider. The transmission layer mainly establishes the communication channel between consumers and service providers and transmits the service request and response data. The protocol layer first exposes service providers and consumers through export based on relevant protocols, that is, in the registered Registry, consumers subscribe to responsive service providers through Registry and establish connections with service providers when they find service providers. The service provider receives the service request from the consumer and invokes the Invoker service in response according to the relevant protocol.

ServiceAnnotationBeanPostProcessor main do is scan application Service first annotations bean, and construct ServiceBean, registered with the bean in the registry. The export service is actually delegated to the corresponding protocol RegistryProtocol

ReferenceBean post-processing mainly scans the bean of Reference annotation and constructs the ReferenceBean. The ReferenceBean invokes the service provider’s service through Invoker, which is the wrapper class of the service. It is actually created using the corresponding protocol.

Application protocol

Registrar protocol

Dubbo framework design source code interpretation two (registry, service registration, subscription)

Registration protocol, export services mainly include registration services and subscription services. Registration service, is actually based on the Dubbo protocol service URL to ZK, how in the process of registration, due to the Dubbo mechanism of its own registration failure, will join the failed registration set, and have a fixed clock, retry registration. Subscribe to the service, listening for the node path of the service provider. Consumers register with a subscription service node on ZK, and specific subscriptions are delegated to the directory service.

The registered directory service depends on the registry, from which the consumer obtains the service provider, actually obtains the service list from the registered directory service (ZK registry is the provider under the service node), and selects the available service provider Invoker according to the routing policy. The registry directory handles the routing of services and listens for changes to services. If the registry node information changes, the service is refreshed and the service Invoker index is created.

Dubbo agreement

Dubbo framework design source code interpretation three (Dubbo protocol, service export, reference)

The Dubbo protocol is the basis for communication between consumers and servers, including service invocation. The registry protocol has the following function to export services to the local device and delegate corresponding protocols, such as the Dubbo DubboProtocol export operation. The registry directory, currently listening for changes in the registry node, is re-indexing the service, converting the URL to Invoker, and actually delegating the refer operation to the corresponding protocol, such as Dubbo protocol DubboProtocol. Dubbo protocol export service, actually create a service Server, depending on the Dubbo protocol configuration, can be NettyServer, or MinaServer. The default is NettyServer.

Data Transport

Dubbo framework design source code interpretation four (Dubbo based on Netty Transport Transport)

Netty server is based on classic bootstrap, event, worker, codec, message handler implementation. The Netty processor is actually a shared SimpleChannelHandler that delegates all operations to the internal channel handler DecodeHandler. DecodeHandler after receiving a message, decodes the corresponding message, which is processed by the internal HeaderExchangeHandler. HeaderExchangeHandler, which delegates all operations to an internal ExchangeHander, which is actually an ExchangeHandleAdater in DubboProtocol.

The consumer invokes a Invocation message that is actually sent by the service provider. The server receives the Invocation from the Dubbo container based on the Invocation context, invokes the service, and returns the Invocation to the consumer.

Netty client also doesn’t have much fresh heart, codec, Netty client processor NettyClientHandler. NettyClientHandler is actually a shared ChannelDuplexHandler that delegates all operations to the internal channel processor DecodeHandler. DecodeHandler after receiving a message, decodes the corresponding message, which is processed by the internal HeaderExchangeHandler. HeanderExchangeHandler, HeanderExchangeHandler delegates all operations to an internal ExchangeHander, which is actually an ExchangeHandleAdater in DubboProtocol. A request that includes the request Id, version, and data and Invocation. The service response, which contains the message ID, message version, status, corresponding result, and error message, if any.

Message codec

Dubbo framework design source code interpretation five (message codec)

NettyCodecAdapter for codec adaptation, the internal encoder is actually ByteToMessageDecoder, the internal encoding operation is entrusted to the internal codec, according to the SPI mechanism, the actual DubboCodec; The internal decoder is actually ByteToMessageDecoder, and the decoding operation is entrusted to DubboCodec.

The encoder encoding is for Request and Response. The header is written first, the magic number, serialization flag, Request id, and Request data are generated for the Request. The RpcInvocation service URL, version information, service method, method parameter type. The method parameter type is encoded by ReflectUtils, and finally the method parameter. For the response, first write the header, magic number, request ID, and then the response data. Note that when encoding requests and responses, there is a section called Attament that can be extended. Serializer, FastJsonSerialization, JavaSerialization, default to JavaSerialization. JavaSerialization serialization and deserialization are actually based on ObjectOutput/InputStream.

The decoded message first decodes the header magic number, then the request ID. If it is a consumer invocation, the message body is decoded, including the aspect name, parameter and parameter value; If it is a request response, DecodeableRpcResult is DecodeableRpcResult, which contains service response data.

The attached

Dubbo class diagram

reference

dubbo offical site

dubbo github

dubbo github vt

incubator-dubbo-spring-boot-project github vt