grpc / grpc-java

The Java gRPC implementation. HTTP/2 based RPC
https://grpc.io/docs/languages/java/
Apache License 2.0
11.36k stars 3.82k forks source link

How to change negotiation type dynamicly via eureka meta data. #9064

Closed EdAndrew closed 2 years ago

EdAndrew commented 2 years ago

The context

I want to make new feature about grpc channel, and it is :

Grpc server can write meta data in eureka about whether negotiation type client should use to communicate with server. And before requests grpc server, grpc client should read this meta data from eureka and change own negotiotion type in channel.

The question

I know grpc client can use NameResolver to change ips of grpc server dynamicly, and want to know how to rewrite code to impletaion dynamic negotation type. Negotiation type is configured in Spring Boot init stage, how to change it in communication state?

Thanks for you answer!

ejona86 commented 2 years ago

This looks completely fine within a NameResolver. NameResolvers can look up IPs from a source of their choosing, which means they can also do a level of indirection and look up results in Eureka and then use some secondary resolution type based on the results.

We can't answer from a Spring perspective.

ST-DDT commented 2 years ago

Let me rephrase the question. How can I use a NameResolverProvider to enable/disable TLS for some of the addresses.

Information resolved from whatever source:

IP:Port TLS
10.0.0.1:80 false
10.0.0.2:80 false
10.0.0.3:443 true

Is there some attribute, I can set?

new EquivalentAddressGroup(new InetSocketAddress(host, port), Attributes.newBuilder().set("TLS", true).build())

(only name resolver api and dependent components; not by creating a new ManagedChannel/Stub)

ejona86 commented 2 years ago

Oh, that negotiation type. You have to get fancy and use internal APIs. This is something that GoogleDefaultChannelCredentials do. But it requires making your own protocol negotiator which is very unstable and we'd really want such things to be in our repo so we can upgrade usages at the same time we break APIs.

ejona86 commented 2 years ago

Seems like this is "resolved," as in, "no, you can't really do want you want." It is possible, but not practical. If that doesn't quite sound right or I'm missing another part of this question (or you want to learn more about the shenanigans to get this to happen), comment, and it can be reopened.