Hello RocketMQ Community, This is the vote result for the kickoff of RIP-17 Apache RocketMQ HTTP proxy support, and it has been passed with [3] binding +1s, [1] non-binding:
*Binding votes +1s:* *heng du *(*duhengforever*) * liqipeng*(willqipeng) *Lei Ding*(*shannonDing*) *Non-binding votes +1s:* zongtanghu This RIP will be accepted and its status will be updated to RocketMQ Wiki soon. Thanks, The Apache RocketMQ Team ShannonDing <ding...@apache.org> 于2019年9月18日周三 下午4:18写道： > +1 > On 09/18/2019 11:15，heng du<duhengfore...@gmail.com> wrote： > +1 > > liqipeng <wlliqip...@163.com> 于2019年9月18日周三 上午11:15写道： > > +1 > > 在 2019年9月16日，下午6:57，heng du <duhengfore...@gmail.com> 写道： > > 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 <duhengfore...@gmail.com> 于2019年9月16日周一 下午6:55写道： > > @aliomaidi419 > > producer 跟 consumer端都可以使用http-proxy > > huzongt...@cmss.chinamobile.com <huzongt...@cmss.chinamobile.com> > 于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. > > > > huzongt...@cmss.chinamobile.com > > 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: dev@rocketmq.apache.org; > us...@rocketmq.apache.org > ● 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. > > > > > >
