+1
> 在 2019年9月6日，下午8:52，ShannonDing <[email protected]> 写道：
>
>
> +1
>
> On 09/6/2019 11:35，heng du<[email protected]>
> <mailto:[email protected]> wrote：
> 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] <mailto:[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] <mailto:[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] <mailto:[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
>
> Implement RPC feature in Producer
> Implement RPC feature in Consumer
> Implement RPC feature in Broker
