+1 Glad to see the strong desire for microservice/servicemesh in community. Let it be native in RocketMQ :-)
Best Regards, Von Gosling > On Sep 6, 2019, at 11:35 AM, heng du <duhengfore...@gmail.com> 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 <duhengfore...@gmail.com <mailto:duhengfore...@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 <sxian.w...@gmail.com <mailto:sxian.w...@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 <duhengfore...@gmail.com <mailto:duhengfore...@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 > > Implement RPC feature in Producer > Implement RPC feature in Consumer > Implement RPC feature in Broker
