|
|
|
Service Config in gRPC
|
|
|
|
======================
|
|
|
|
|
|
|
|
# Objective
|
|
|
|
|
|
|
|
The service config is a mechanism that allows service owners to publish
|
|
|
|
parameters to be automatically used by all clients of their service.
|
|
|
|
|
|
|
|
# Format
|
|
|
|
|
|
|
|
The service config is a JSON string of the following form:
|
|
|
|
|
|
|
|
```
|
|
|
|
{
|
|
|
|
# Load balancing policy name.
|
|
|
|
# Supported values are 'round_robin' and 'grpclb'.
|
|
|
|
# Optional; if unset, the default behavior is pick the first available
|
|
|
|
# backend.
|
|
|
|
# Note that if the resolver returns only balancer addresses and no
|
|
|
|
# backend addresses, gRPC will always use the 'grpclb' policy,
|
|
|
|
# regardless of what this field is set to.
|
|
|
|
'loadBalancingPolicy': string,
|
|
|
|
|
|
|
|
# Per-method configuration. Optional.
|
|
|
|
'methodConfig': [
|
|
|
|
{
|
|
|
|
# The names of the methods to which this method config applies. There
|
|
|
|
# must be at least one name. Each name entry must be unique across the
|
|
|
|
# entire service config. If the 'method' field is empty, then this
|
|
|
|
# method config specifies the defaults for all methods for the specified
|
|
|
|
# service.
|
|
|
|
#
|
|
|
|
# For example, let's say that the service config contains the following
|
|
|
|
# method config entries:
|
|
|
|
#
|
|
|
|
# 'methodConfig': [
|
|
|
|
# { 'name': [ { 'service': 'MyService' } ] ... },
|
|
|
|
# { 'name': [ { 'service': 'MyService', 'method': 'Foo' } ] ... }
|
|
|
|
# ]
|
|
|
|
#
|
|
|
|
# For a request for MyService/Foo, we will use the second entry, because
|
|
|
|
# it exactly matches the service and method name.
|
|
|
|
# For a request for MyService/Bar, we will use the first entry, because
|
|
|
|
# it provides the default for all methods of MyService.
|
|
|
|
'name': [
|
|
|
|
{
|
|
|
|
# RPC service name. Required.
|
|
|
|
# If using gRPC with protobuf as the IDL, then this will be of
|
|
|
|
# the form "pkg.service_name", where "pkg" is the package name
|
|
|
|
# defined in the proto file.
|
|
|
|
'service': string,
|
|
|
|
|
|
|
|
# RPC method name. Optional (see above).
|
|
|
|
'method': string,
|
|
|
|
}
|
|
|
|
],
|
|
|
|
|
|
|
|
# Whether RPCs sent to this method should wait until the connection is
|
|
|
|
# ready by default. If false, the RPC will abort immediately if there
|
|
|
|
# is a transient failure connecting to the server. Otherwise, gRPC will
|
|
|
|
# attempt to connect until the deadline is exceeded.
|
|
|
|
#
|
|
|
|
# The value specified via the gRPC client API will override the value
|
|
|
|
# set here. However, note that setting the value in the client API will
|
|
|
|
# also affect transient errors encountered during name resolution,
|
|
|
|
# which cannot be caught by the value here, since the service config
|
|
|
|
# is obtained by the gRPC client via name resolution.
|
|
|
|
'waitForReady': bool,
|
|
|
|
|
|
|
|
# The default timeout in seconds for RPCs sent to this method. This can
|
|
|
|
# be overridden in code. If no reply is received in the specified amount
|
|
|
|
# of time, the request is aborted and a deadline-exceeded error status
|
|
|
|
# is returned to the caller.
|
|
|
|
#
|
|
|
|
# The actual deadline used will be the minimum of the value specified
|
|
|
|
# here and the value set by the application via the gRPC client API.
|
|
|
|
# If either one is not set, then the other will be used.
|
|
|
|
# If neither is set, then the request has no deadline.
|
|
|
|
#
|
|
|
|
# The format of the value is that of the 'Duration' type defined here:
|
|
|
|
# https://developers.google.com/protocol-buffers/docs/proto3#json
|
|
|
|
'timeout': string,
|
|
|
|
|
|
|
|
# The maximum allowed payload size for an individual request or object
|
|
|
|
# in a stream (client->server) in bytes. The size which is measured is
|
|
|
|
# the serialized, uncompressed payload in bytes. This applies both
|
|
|
|
# to streaming and non-streaming requests.
|
|
|
|
#
|
|
|
|
# The actual value used is the minimum of the value specified here and
|
|
|
|
# the value set by the application via the gRPC client API.
|
|
|
|
# If either one is not set, then the other will be used.
|
|
|
|
# If neither is set, then the built-in default is used.
|
|
|
|
#
|
|
|
|
# If a client attempts to send an object larger than this value, it
|
|
|
|
# will not be sent and the client will see an error.
|
|
|
|
# Note that 0 is a valid value, meaning that the request message must
|
|
|
|
# be empty.
|
|
|
|
#
|
|
|
|
# The format of the value is that of the 'uint64' type defined here:
|
|
|
|
# https://developers.google.com/protocol-buffers/docs/proto3#json
|
|
|
|
'maxRequestMessageBytes': string,
|
|
|
|
|
|
|
|
# The maximum allowed payload size for an individual response or object
|
|
|
|
# in a stream (server->client) in bytes. The size which is measured is
|
|
|
|
# the serialized, uncompressed payload in bytes. This applies both
|
|
|
|
# to streaming and non-streaming requests.
|
|
|
|
#
|
|
|
|
# The actual value used is the minimum of the value specified here and
|
|
|
|
# the value set by the application via the gRPC client API.
|
|
|
|
# If either one is not set, then the other will be used.
|
|
|
|
# If neither is set, then the built-in default is used.
|
|
|
|
#
|
|
|
|
# If a server attempts to send an object larger than this value, it
|
|
|
|
# will not be sent, and the client will see an error.
|
|
|
|
# Note that 0 is a valid value, meaning that the response message must
|
|
|
|
# be empty.
|
|
|
|
#
|
|
|
|
# The format of the value is that of the 'uint64' type defined here:
|
|
|
|
# https://developers.google.com/protocol-buffers/docs/proto3#json
|
|
|
|
'maxResponseMessageBytes': string
|
|
|
|
}
|
|
|
|
]
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
Note that new per-method parameters may be added in the future as new
|
|
|
|
functionality is introduced.
|
|
|
|
|
|
|
|
# Architecture
|
|
|
|
|
|
|
|
A service config is associated with a server name. The [name
|
|
|
|
resolver](naming.md) plugin, when asked to resolve a particular server
|
|
|
|
name, will return both the resolved addresses and the service config.
|
|
|
|
|
|
|
|
TODO(roth): Design how the service config will be encoded in DNS.
|
|
|
|
|
|
|
|
# APIs
|
|
|
|
|
|
|
|
The service config is used in the following APIs:
|
|
|
|
|
|
|
|
- In the resolver API, used by resolver plugins to return the service
|
|
|
|
config to the gRPC client.
|
|
|
|
- In the gRPC client API, where users can query the channel to obtain
|
|
|
|
the service config associated with the channel (for debugging
|
|
|
|
purposes).
|
|
|
|
- In the gRPC client API, where users can set the service config
|
|
|
|
explicitly. This is intended for use in unit tests.
|