Add custom metadata about grpc-spring HOT 9 CLOSED

In order to help you, we need to understand your intentions/purpose better.

• Why the two different ClientInterceptors?
• Which purpose does the header have? Does it encode the proxy service instance? Or the processing service instance?

from grpc-spring.

As shown in the figure, 'biz-service' and 'servicefilter' are two applications on the same machine. biz-service is a business applicatoin. It provides external services through grpc & protobuf, and calls other services, db, cache, etc. through this protocol (convert the interface provided by sdk to protobuf), so that all external calls made by biz-service are converted For service calls, in order to simplify biz-service, the service discovery capability is implemented by servicefilter. Therefore, biz-service needs to tell servicefilter the service name to be called. Servicefilter obtains the service instance from the registration center according to the service name and then completes the call.

The servicefilter uses ‘x-servicefilter-target-service-name’ as the key for the service name. This key and service name need to be placed in the requested Metadata. In addition to the above three adding methods, are there any more friendly adding methods?

• Why the two different ClientInterceptors?
  • There is only one ClientInterceptors that adds Metadata
• Which purpose does the header have? Does it encode the proxy service instance? Or the processing service instance?
  • Implement service discovery in servicefilter

from grpc-spring.

Why don't you use the address for the service discovery similar to the DiscoveryClientNameResolver?

from grpc-spring.

I want the business application to focus more on the business itself, and move the non-business code to an external program (servicefilter) as much as possible for processing, so the business application needs to tell the servicefilter the name of the application I want to call, and the servicefilter can realize discovery and transfer. In this way, business applications become very simple, and the servicefilter capabilities are universal and can be managed using simple configuration files. The overall development, operation and maintenance of the system will be much simpler.
Use ‘DiscoveryClientNameResolver‘ to increase the transmission of metadata information? If so, please explain how to use it.

from grpc-spring.

so the business application needs to tell the servicefilter the name of the application I want to call

So basically it's effectively a service registry

In this way, business applications become very simple, and the servicefilter capabilities are universal and can be managed using simple configuration files.

So is setting the configuration:

grpc:
  client:
    counter-service:
      address: "service-filter:counter-service"

Dependending on your NameResolverProvider implementation you can also omit the actual address in the config and it will use the name of the client (annotation) itself.

Use ‘DiscoveryClientNameResolver‘ to increase the transmission of metadata information? If so, please explain how to use it.

It does not add additional metadata to the request it just resolves the address the service tries to use. Similar to DNS.
So instead of doing ask dns where the service-filter is and then call service-filter to forward the call to whatever service using the call metadata, you ask the service-filter where the whatever service is

Which service registry do you use? Eureka, Consul, Nacos, ...?

from grpc-spring.

I want to use servicefilter application proxy for all network requests of business application.
Take a request that requires a business application to call the database as an example.
1 The request first reaches servicefilter and is processed by servicefiter.
2 Forward to business application s1
3 s1 needs to call the db service db-001. At this time, s1 does not call db-001 directly, but calls it through the protobuf interface provided by servicefilter.
4 s1 tells servicefilter to call db-001
5 servicefilter goes to the registration center to query the instance of db-001, and then initiates a call
According to this process, servicefilter needs to know the service name db-001

• s1
  • config file https://github.com/servicefilter/example/blob/main/grpc-spring/examples/local-grpc-server/src/main/resources/application.yml

grpc:
  server:
    port: 9898
  client:
    GLOBAL:  # Specify that all services are called to this address, which is servicefilter
      address: 'static://[::1]:50052'    # servicefilter local listen
      enableKeepAlive: true
      keepAliveWithoutCalls: true
      negotiationType: plaintext

* call db config  https://github.com/servicefilter/example/blob/main/grpc-spring/examples/local-grpc-server/src/main/java/net/devh/boot/grpc/examples/local/server/GrpcServerService.java
* call db protobuf https://github.com/servicefilter/example/blob/main/grpc-spring/examples/grpc-lib/src/main/proto/redisoperate.proto

    @GrpcClient(value = "redis-servicefilter-proxy", interceptors = ServicefilterMetadataClientInterceptor.class)
    private RedisOperateServiceGrpc.RedisOperateServiceBlockingStub redisOperateServiceBlockingStub;

• servicefilter impl protobuf https://github.com/servicefilter/servicefilter-rust/blob/main/servicefilter-lib/servicefilter-lib-redis/src/redis_routing_filter.rs

from grpc-spring.

from grpc-spring.

For me this looks like a service registry/discovery client setup and I think an implementation using a name resolver would be straight forward.

For me, calling the "service-filter" as a proxy in every step sounds like a waste of performance, but you might have some requirements/idea/concept that I dont know of/understand.

The alternative using headers should work as well. You should enshure that external calls to your service filter ignore the header to avoid leaking access to your DB. If it is an internal only service it doesnt matter.

The following class might help you with it/should require less code.

https://grpc.github.io/grpc-java/javadoc/io/grpc/stub/MetadataUtils.html

Does this answer your question?

from grpc-spring.

Yes, thank you.

from grpc-spring.