On Thu, Dec 1, 2016 at 12:26 PM, killjason <[email protected]> wrote:
> In my case: > 1.The backend servers represent a same micro-service(may be contains 10 > machines) serving the same APIs. > 2.The proxy is based on pure Netty(no gRPC included). but clients and > backend servers are developed on gRPC. > I am not sure if one Netty channel can represents multiple connections to > multiple backends? > If you are using Netty as a layer-4 proxy, then it cannot. But if you use it as a layer-7 proxy, using the HTTP/2 protocol handlers, you can. When a client initiates a new stream, you pick a backend, find a channel to that backend, and create a new stream on that backend channel. You will effectively have a map of incoming channel & stream ID -> outgoing channel & stream ID and use that to proxy frames. This works for gRPC, but would probably be insufficient for general-purpose HTTP/2 where the servers initiate streams (since the proxy won't be able to know which client the server-initiated stream was intended). Admittedly, there will probably be some implementation complexity in properly managing HTTP/2 flow control windows on both sides while avoiding excessive resource usage/buffering. > > 在 2016年12月2日星期五 UTC+8上午1:11:03，Carl Mastrangelo写道： >> >> This depends on how homogeneous your backends are. For example, if your >> proxy going to the same logical set of backends each time, (even if they >> are distinct machines) then yes this is possible with gRPC. In gRPC, a >> channel represent a higher level concept than a single client. It >> represents multiple connections to multiple backends (a.k.a. Servers). >> >> In your case, it seems like you should build a map of hostname (a.k.a. >> "target") to Channel and pick the correct channel to serve requests to in >> your proxy. This works well if you are handling a small number >> hostnames. Each channel will have its own tcp connections, but there will >> be few total channels. >> >> You can do more advanced things too with your host name. If the backends >> that you send traffic to route requests based on the host name, but each >> backend can handle the requests of other host names, then you can reduce >> the number of connections even further. For example, if you know that >> foo.mydomain.com and bar.mydomain.com both physically point to the same >> set of servers, then they can both share the same channel. In your >> channel, you can override the "authority" field but still reuse the same >> connection. >> >> >> We can provide a better answer if you could share a little more detail >> about what you want to do. >> >> On Thursday, December 1, 2016 at 8:59:45 AM UTC-8, killjason wrote: >>> >>> (moved from: https://github.com/grpc/grpc-java/issues/2470) >>> >>> Imagine there are 10k grpc-clients, they established 10k http2 >>> connections(TCP-connections) with the http2 reverse proxy; then http2 >>> reverse proxy create 10k http2 connections(TCP-connections) to the >>> origin(backend) server. >>> Is it possible to reduce the 10k connections between proxy and >>> origin(backend) server? >>> for example, can a connection pool be used in reverse proxy to reduce >>> connections with backend server? >>> This picture can explain better: >>> [image: image] >>> this picture is in Nginx blog, Is it possible to do the same thing to >>> reduce connections with backend serevrs using http2-reverse proxy? >>> >>> -- > You received this message because you are subscribed to the Google Groups " > grpc.io" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/grpc-io. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/grpc-io/dd155eb2-c351-49a0-8687-dffa035c3f2b%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/dd155eb2-c351-49a0-8687-dffa035c3f2b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAO78j%2BK9yfsWuAjmZNHYRg1TZgHc3y7JBULJjz%3DJ-4dKwKPMog%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
