+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] <mailto:[email protected]>>
> 于2019年9月16日周一 下午6:55写道：
> @aliomaidi419
>
> producer 跟 consumer端都可以使用http-proxy
>
> [email protected] <mailto:[email protected]>
> <[email protected] <mailto:[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] <mailto:[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]
> <mailto:[email protected]>; [email protected]
> <mailto:[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.
>
>
>
