+1 Thanks for your sincere explanation @duheng!
superheizai <[email protected]> 于2019年9月6日周五 下午1:49写道： > +1 > Service Bus model is very popular in enterprise. > > ------------------------------------------------------------------ > 发件人：heng du <[email protected]> > 发送时间：2019年9月6日(星期五) 11:36 > 收件人：dev <[email protected]> > 抄 送：users <[email protected]> > 主 题：[VOTE][RIP-16]RocketMQ RPC(Request-Response model) Support > > 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 > >
