[RESULT][VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support

[heng du <du...@gmail.com>]

Hello RocketMQ Community,

This is the vote result for the kickoff of RIP-16 Apache RocketMQ
Request-Response support, and it has been passed with [4] binding +1s,
[3] non-binding
+1s and no 0 or -1:

*Binding votes +1s:*

*heng du *(*duhengforever*)

* liqipeng*(willqipeng)

*Lei Ding*(*shannonDing*)

Gosling Von(vongosling)

*Non-binding votes +1s:*

王金

wenfeng wang

superheizai


This RIP will be accepted and its status will be updated to RocketMQ  Wiki
soon.

Thanks,
The Apache RocketMQ Team



heng du <du...@gmail.com> 于2019年9月9日周一 下午2:41写道：

> +1
>
> liqipeng <wl...@163.com> 于2019年9月9日周一 下午2:28写道：
>
>> +1
>> > 在 2019年9月6日，上午11:35，heng du <du...@gmail.com> 写道：
>> >
>> > Hello RocketMQ Community,
>> >
>> > This is the vote for the kickoff of RIP-16 RocketMQ Request-Response
>> model
>> > support
>> >
>> > RPC is a powerful technique for constructing distributed, client-server
>> > based applications. Many companies use the MQ system to constructing
>> their
>> > service bus, especially in the financial industry. We need to implement
>> an
>> > RPC client based on MQ system ourselves because the MQ system doesn’t
>> > support RPC naturally. In the current version of rocketmq project,
>> producer
>> > client only support to send a message to the broker and cannot wait a
>> > response message replied from the consumer. We wish RocketMQ can
>> provide an
>> > RPC client implement to help developers building their applications
>> > conveniently and effectively.
>> >
>> >
>> > The vote will be open for at least 72 hours or until a necessary number
>> of
>> > votes are reached.
>> >
>> > Please vote accordingly:
>> >
>> > [ ] +1 approve
>> > [ ] +0 no opinion
>> > [ ] -1 disapprove with the reason
>> >
>> >
>> > Thanks,
>> > The Apache RocketMQ Team
>> >
>> > heng du <du...@gmail.com> 于2019年9月6日周五 上午11:32写道：
>> >
>> >> @wenfeng
>> >>
>> >> Actually, Building RPC based on message queue is a very traditional
>> >> approach, especially in the previous ESB, SOA era. Of course, in
>> today's
>> >> micro-services, there are many benefits to building micro-services
>> based on
>> >> MQ.
>> >>
>> >> For example, at the transport layer level, MQ can provide true
>> >> asynchronous communication for RPC. In terms of visualization, MQ can
>> also
>> >> provide better visibility and make it easier to replay traffic to
>> locate or
>> >> fix issues, which is very important in event-driven architectures. Most
>> >> important of all, direct RPC will make the access relationship between
>> >> services become mesh, but based on MQ, the problem of network mesh
>> calls
>> >> are solved. In many industries, such as the financial industry, it is
>> >> difficult to provide all the network access.
>> >> Moreover, the request-response model can be used to make RocketMQ
>> >> integrate well into various infrastructures. In addition, many of the
>> same
>> >> types of message middleware also provide request-response access
>> methods.
>> >>
>> >> So I think that supporting the request-response model will increase the
>> >> competitiveness of RocketMQ and better expand the usage scenario.
>> >>
>> >>
>> >> wenfeng wang <sx...@gmail.com> 于2019年8月27日周二 下午6:15写道：
>> >>
>> >>> IMO, The most popular scenario of MQ System is that decouple complex
>> >>> distributed system and process message asynchronous. If a user wants
>> low
>> >>> latency or explicit response from downstream, he should use an RPC
>> >>> Framework instead of MQ, like Dubbo, gRPC, etc. so I vote for -1.
>> >>>
>> >>>
>> >>> heng du <du...@gmail.com> 于2019年8月27日周二 下午5:54写道：
>> >>>
>> >>>> Dear Apache RocketMQ Community:
>> >>>>
>> >>>> We would like to propose a RIP[16] about RocketMQ
>> RPC(Request-Response
>> >>>> model) Support. Many companies use the MQ system to constructing
>> their
>> >>>> service bus, especially in the financial industry. We wish RocketMQ
>> can
>> >>>> provide an RPC client implement to help developers building their
>> >>>> applications conveniently and effectively.
>> >>>>
>> >>>>
>> >>>> Status
>> >>>>
>> >>>> Current State: Proposed
>> >>>>
>> >>>> Authors: qqeasonchen
>> >>>>
>> >>>> Shepherds: duhengforever
>> >>>>
>> >>>> Mailing List discussion: dev, users
>> >>>>
>> >>>> Pull Request: none
>> >>>>
>> >>>> Released: 4.6.0
>> >>>>
>> >>>> Background & Motivation
>> >>>>
>> >>>> RPC is a powerful technique for constructing distributed,
>> client-server
>> >>>> based applications. Many companies use the MQ system to constructing
>> their
>> >>>> service bus, especially in the financial industry. We need to
>> implement an
>> >>>> RPC client based on MQ system ourselves because the MQ system doesn’t
>> >>>> support RPC naturally. In the current version of rocketmq project,
>> producer
>> >>>> client only support to send a message to the broker and cannot wait a
>> >>>> response message replied from the consumer. We wish RocketMQ can
>> provide an
>> >>>> RPC client implement to help developers building their applications
>> >>>> conveniently and effectively.
>> >>>>
>> >>>> Goals
>> >>>>
>> >>>>   - What problem is this proposal designed to solve?
>> >>>>
>> >>>> (1) Design and implement an RPC interface based on RocketMQ Producer,
>> >>>> which support send a message and then wait a response message
>> replied from
>> >>>> the consumer.
>> >>>>
>> >>>> (2) Design and Implement a consumer which can automatically or
>> manually
>> >>>> send a reply message.
>> >>>>
>> >>>> (3) Enable the broker to push a message to an explicit producer.
>> >>>>
>> >>>>
>> >>>>
>> >>>>   - To what degree should we solve the problem?
>> >>>>
>> >>>> We wish developers can use RocketMQ easily to constructing their
>> >>>> distributed applications which need RPC call.
>> >>>>
>> >>>> Non-Goals
>> >>>>
>> >>>>   - What problem is this proposal NOT designed to solve?
>> >>>>
>> >>>> In this phase, this rip only supports a usable RPC call in most
>> common
>> >>>> scenarios.
>> >>>>
>> >>>>   - Are there any limits to this proposal?
>> >>>>
>> >>>> Users may need to tune some client and broker’s configurations to
>> >>>> achieve better performance.
>> >>>>
>> >>>> Changes
>> >>>>
>> >>>> Architecture
>> >>>>
>> >>>> We plan to add RPC implement into client and broker modules. In
>> client
>> >>>> modules, we will add an RPC interface into DefaultMQProducer, and
>> add reply
>> >>>> logic into DefaultMQPushConsumer. In broker modules, we will add a
>> >>>> processor to push reply message from consumer to explicit producer.
>> >>>>
>> >>>> Interface Design/Change
>> >>>>
>> >>>>   - Method signature changes
>> >>>>
>> >>>> Plan to add interfaces as follow:
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final long timeout) throws
>> MQClientException, RemotingException, MQBrokerException,
>> InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final SendCallback sendCallback,
>> >>>> final long timeout) throws MQClientException, RemotingException,
>> >>>> InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final MessageQueueSelector
>> selector,
>> >>>> final Object arg, final long timeout) throws MQClientException,
>> >>>> RemotingException, MQBrokerException, InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final MessageQueueSelector
>> selector,
>> >>>> final Object arg, final SendCallback sendCallback, final long
>> timeout)
>> >>>> throws MQClientException, RemotingException, InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final MessageQueue MQ, final long
>> >>>> timeout) throws MQClientException, RemotingException,
>> MQBrokerException,
>> >>>> InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>> Message request(final Message msg, final MessageQueue mq, final
>> >>>> SendCallback sendCallback, long timeout) throws MQClientException,
>> >>>> RemotingException, InterruptedException;
>> >>>>
>> >>>>
>> >>>>
>> >>>>   - Method behavior changes
>> >>>>
>> >>>> No issue
>> >>>>
>> >>>>   - CLI command changes
>> >>>>
>> >>>> No issue
>> >>>>
>> >>>>   - Log format or content changes
>> >>>>
>> >>>> No issue
>> >>>>
>> >>>> Compatibility, Deprecation, and Migration Plan
>> >>>>
>> >>>>   - No issue
>> >>>>
>> >>>> Implementation Outline
>> >>>>
>> >>>> We will implement the proposed changes by *1* phase.
>> >>>>
>> >>>> Phase 1
>> >>>>
>> >>>>   1. Implement RPC feature in Producer
>> >>>>   2. Implement RPC feature in Consumer
>> >>>>   3. Implement RPC feature in Broker
>> >>>>
>> >>>>
>>
>>
>>