+1
> 在 2019年9月6日，上午11:35，heng du <[email protected]> 写道：
>
> 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 <[email protected]> 于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 <[email protected]> 于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 <[email protected]> 于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
>>>>
>>>>
