+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. >>> >>> >>> >>> >
