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 <[email protected]> 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 <[email protected]> 于2019年9月18日周三 下午4:18写道： > > > +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. > > > > > > > > > > > > >
