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 <[email protected]> 于2019年9月9日周一 下午2:41写道： > +1 > > liqipeng <[email protected]> 于2019年9月9日周一 下午2:28写道： > >> +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 >> >>>> >> >>>> >> >> >>
