@Josh Humphries, your plan is nice, gRPC currently not support init stream in server side, so this limit can be ignored.
在 2016年12月2日星期五 UTC+8上午2:18:54，Josh Humphries写道： > > On Thu, Dec 1, 2016 at 12:26 PM, killjason <[email protected] > <javascript:>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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/4234545b-e25f-4e0c-9994-667a8ab21fe1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
