Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog A New Paradigm of Dubbo-go Communication Based on RocketMQ

A New Paradigm of Dubbo-go Communication Based on RocketMQ

This article discusses RPC and the communication capability of using RocketMQ alongside Dubbo-go.

By Hongfan Hao (Dubbo-go Committer + JD Senior R&D Engineer)

1. An Introduction to MQ Request Reply Characteristics

_1
What is RPC communication?

As shown in the preceding figure, similar to a local call, what do we need to do if service A responds to the helloworld method of service B? First, after the Client Sub of service A receives a function call, it serializes the calling method and parameters. Client Sub sends messages to the server through a socket. After receiving the request, Server B deserializes the request body based on the protocol and obtains the name and parameters of the function to be called. The server calls this function and obtains the returned result. The server stub serializes the result and sends it to the client sub through the socket. The client sub-deserializes the message based on the protocol to obtain the final result.

The RPC framework is more complex than the preceding process. Service retry, circuit breaking, backup, request, routing load balancing, etc., need to be considered.

_2
How can we use MQ for RPC communication? The principle is simple. It uses MQ as a communication pipeline to simulate full-duplex communication.

As shown in the figure, what does client A need to do to call the helloworld method of server B? First, the client serializes the function name and parameters and sends them to the MQ Broker. After the MQ consumer consumes the message, it calls the local function helloworld to obtain the result and then sends the result to the MQ broker. The MQ broker sends the response result to the previously requested client according to a certain agreement.

The preceding process is a fully simulated TCP communication process. The RocketMQ 4.6.0 also supports this feature - Request Reply.

_3

The preceding figure shows how Request Reply is implemented.

Producer creates RequestFutureTable and initializes a function call. And the producer sends the function call to the broker and sends the request record to the RequestFutureTable. After the consumer receives the message, it calls a local function to serialize the result and return it to the broker. At the same time, it returns a specific request reply topic to the broker, including the producer. After obtaining this information, the broker proactively sends a message to the producer that made the request. After receiving the message, the producer checks whether the request exists in the RequestFutureTable and then completes the entire RPC process.

_4
MQ can be used to simulate full-duplex communication of RPC, but it comes at a cost.

  • After MQ is used, one TCP is split four times, which increases the time consumption and reduces the RPC performance.
  • Messages are sent from the producer to the broker and then to the consumer, which increases the complexity of message delivery.
  • MQ drops the message to the disk, reducing the RPC throughput.
  • RPC communication relies heavily on the O&M capabilities of MQ. MQ can easily become a performance bottleneck.
  • The cost of maintaining MQ stability is far more complex than RPC.

On the whole, MQ for RPC communication is unsuitable for scenarios that are sensitive to the time consumption of interfaces. However, any technology has suitable application scenarios, and MQ for RPC communication has unique advantages.

_5
For example, you can make RPC run in a similar message bus so all messages can be audited in a unified ingress. The retry feature of MQ ensures that all requests are not lost. At the same time, all requests are run in RocketMQ, which improves the security of message requests.

The preceding features make MQ RPC communication particularly suitable for scenarios with strict message security auditing (such as financial and banking scenarios). Such scenarios do not require high interface latency but require high request security. For example, WeBank uses the request reply feature of RocketMQ to build an RPC framework for financial products.

2. An Introduction to Dubbo-go

_6
Dubbo-go is a high-performance go-language microservice RPC framework. The goal is to build a new generation of microservice infrastructure and implement bridging the gap between X and Go so Dubbo-go can communicate with any framework.

The advantages of the Dubbo-go framework are listed below:

  • Developers can easily build RPC services with Dubbo-go frameworks.
  • You can experience Dubbo-go's powerful service governance and O&M capabilities.
  • The ecosystem of Dubbo-go is being enriched. For example, the pixiu gateway can already be used in the production environment.
  • The popularity of the Dubbo-go community is high. As long as the issue is submitted, someone will follow up immediately.

_7

The Dubbo-go consists of four parts: registry, consumer (client), provider (server), and monitor (Dubbo-go control plane). When the client initiates a request, it obtains the service list of the server from the consumer and then obtains it to the provider through the corresponding SLB. The two establish a socket for communication.

_8

Dubbo-go ecology is developing rapidly. Dubbo-go can communicate with gRPC, Spring Cloud, Dubbo, and Java and has precipitated Dubbo-go gateway projects, which have been used in actual production.

_9

The RocketMQ community and the Dubbo-go community have jointly launched new features that allow Dubbo-go to use RocketMQ for RPC communication to expand Dubbo-go communication methods. The rich service governance capabilities of Dubbo-go and the stable RPC communication capabilities of RocketMQ are combined to create a new RPC communication paradigm.

_10

The process for Dubbo-go to communicate through RocketMQ is listed below:

The Dubbo-go client sends messages to the RocketMQ broker using the request reply feature. After the Dubboserver consumes a message from RocketMQ, the Dubboserver returns the message to the broker using the request reply feature of RocketMQ. The broker pushes the message to the Dubbo client that sends the message. The entire process is consistent with MQ for RPC communication.

_11
The Dubbo-go service registration process is listed below:

First, the RocketMQ broker registers the broker, topic, queue, and other information in the nameserver. The Dubbo-go client pulls the routing information from the nameserver. Dubbo-go server subscribes to the topic information.

_12
Dubbo-go communication protocols currently support Dubbo, Triple, gRPC, and Rest. To enable Dubbo-go to communicate with RocketMQ, we need to build a new communication protocol, which has been designed to make the integration of the entire serialization protocol of RocketMQ and Dubbo-go.

13
Dubbo-go supports Python2, JSON, Protobuf, and MsgPack. Dubbo-go using RocketMQ for communication can support the four serialization protocols. However, Protobuf is mainly used, and the other three protocols are used as extensions.

The communication capability of using RocketMQ alongside Dubbo-go has been developed and will be available soon.

Apache middleware RocketMQ Computing Message Queue cloud native Dubbo Dubbo-go messaging services
0 1 0
Share on

Read previous post:

Architecture Evolution of the Distributed Serverless Multi-Tenancy Task Processing System Based on MQ

Read next post:

RocketMQ in the Spring Ecosystem

Alibaba Cloud Native Community

480 posts | 48 followers

You may also like

Comments

Alibaba Cloud Native Community

480 posts | 48 followers

Related Products

More Posts by Alibaba Cloud Native Community

See All