+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 > >>>> > >>>> > > >
