+1 On 09/18/2019 11:15，heng du<[email protected]> wrote： +1
liqipeng <[email protected]> 于2019年9月18日周三 上午11:15写道： +1 在 2019年9月16日，下午6:57，heng du <[email protected]> 写道： Hello RocketMQ Community, This is the vote for the kickoff of RIP-17 RocketMQ HTTP Proxy Support RocketMQ has different clients written in different languages. In order to meet the needs of heterogeneous systems to access RocketMQ, this proposal solves this problem by adding an HTTP proxy module. At the same time, some logic such as flow control/ACL on the broker and some processing logic on the client can be moved to the proxy, which makes the broker and client lighter. 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月16日周一 下午6:55写道： @aliomaidi419 producer 跟 consumer端都可以使用http-proxy [email protected] <[email protected]> 于2019年9月12日周四 上午10:47写道： This rip sounds very wonderful.It make RocketMQ may access clients written in different languages.We can join in this rip together. [email protected] From: heng du Date: 2019-09-12 09:41 To: dev; users Subject: [DISCUSS][RIP-17]RocketMQ HTTP Proxy Support Dear Apache RocketMQ Community: We would like to propose a RIP-17 about RocketMQ HTTP Proxy. RocketMQ may access clients written in different languages. In order to meet the needs of heterogeneous systems to access RocketMQ, this proposal solves this problem by adding an HTTP proxy module. At the same time, some logic such as flow control/ACL on the broker and some process logic on the client can be moved to the proxy, which makes the broker and client lighter. So we would like to provide an HTTP proxy to provide a proxy for HTTP so that users can quickly access the RocketMQ with a lightweight HTTP client. The following is the relevant information about this RIP and we are listed directly below for your convenience, hope everyone can give more suggestions. Thanks, The Apache RocketMQ Team Status ● Current State: Proposed ● Authors: qqeasonchen ● Shepherds: duhengforever ● Mailing List discussion: [email protected]; [email protected] ● Pull Request: RIP-17 ● Released: 4.7.0（rocketmq-external first） Background & Motivation What do we need to do RocketMQ may access clients written in different languages. In order to meet the needs of heterogeneous systems to access RocketMQ, this proposal solve this problem by adding HTTP proxy module. At the same time, some logic such as flow control/ACL on broker and some process logic on client can be moved to proxy, which makes the broker and client lighter. Goals ● What problem is this proposal designed to solve? In the future, RocketMQ may access clients written in different languages. At present, due to the complexity of the client logic, it takes a lot of effort to rewrite the client in different languages. And the persistent connection in RocketMQ is based on TCP, and the ability to resist network jitter is bad. HTTP connection can better resist network jitter. In order to write and access clients in different languages better, this proposal provides an HTTP sending proxy, which simplifies the processing logic of the client and implements a more lightweight client. Non-Goals ● What problem is this proposal NOT designed to solve? Nothing specific ● Are there any limits of this proposal? User need deploy proxy before use it. It will add a little complexity for operation and maintenance. Changes Adding a proxy module to achieve message proxy. This RIP will be divided into two phases. The first phase will not have any impact on the existing architecture, including the nameserver, depending on the service discovery configured to do the proxy. The second phase will decide whether to do proxy service discovery based on community feedback or provide a lightweight http client. Architecture In our proposal, there are 3 features in the proxy: (1) We realize group proxy in producer group/consumer group level (2) The proxy receives HTTP packets sent by HTTP producer, which realizes HTTP proxy and reduces the impact of network jitter. (3) The proxy simplify processing logic in client and achieve lighter client.
