You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rocketmq.apache.org by heng du <du...@gmail.com> on 2019/09/19 01:13:11 UTC
[RESULT][VOTE][DISCUSS][RIP-17]RocketMQ HTTP Proxy Support
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 <di...@apache.org> 于2019年9月18日周三 下午4:18写道：
> +1
> On 09/18/2019 11:15，heng du<du...@gmail.com> wrote：
> +1
>
> liqipeng <wl...@163.com> 于2019年9月18日周三 上午11:15写道：
>
> +1
>
> 在 2019年9月16日，下午6:57，heng du <du...@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 <du...@gmail.com> 于2019年9月16日周一 下午6:55写道：
>
> @aliomaidi419
>
> producer 跟 consumer端都可以使用http-proxy
>
> huzongtang@cmss.chinamobile.com <hu...@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.
>
>
>
> huzongtang@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;
> users@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.
>
>
>
>
>
>
Re: [RESULT][VOTE][DISCUSS][RIP-17]RocketMQ HTTP Proxy Support
Posted by Xu Jianhai <sn...@gmail.com>.
sorry for later response. http proxy is proposed here, but can we use grpc
or thrift ?
On Thu, Sep 19, 2019 at 9:13 AM heng du <du...@gmail.com> wrote:
> 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 <di...@apache.org> 于2019年9月18日周三 下午4:18写道：
>
> > +1
> > On 09/18/2019 11:15，heng du<du...@gmail.com> wrote：
> > +1
> >
> > liqipeng <wl...@163.com> 于2019年9月18日周三 上午11:15写道：
> >
> > +1
> >
> > 在 2019年9月16日，下午6:57，heng du <du...@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 <du...@gmail.com> 于2019年9月16日周一 下午6:55写道：
> >
> > @aliomaidi419
> >
> > producer 跟 consumer端都可以使用http-proxy
> >
> > huzongtang@cmss.chinamobile.com <hu...@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.
> >
> >
> >
> > huzongtang@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;
> > users@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.
> >
> >
> >
> >
> >
> >
>