Some checks failed
codecov / upload (push) Failing after 13m59s
CodeQL / Analyze (push) Failing after 1s
govulncheck / govulncheck (.) (push) Failing after 1s
govulncheck / govulncheck (./cmd/protoc-gen-go-grpc) (push) Failing after 1s
govulncheck / govulncheck (./gcp/observability) (push) Failing after 1s
govulncheck / govulncheck (./security/advancedtls) (push) Failing after 1s
govulncheck / govulncheck (./stats/opencensus) (push) Failing after 1s
Testing / vet-proto (push) Failing after 1s
Testing / tests (arm, latest) (push) Waiting to run
Testing / extras (latest) (push) Failing after 1s
Testing / static checks (latest-1) (push) Failing after 1s
Testing / tests (-race, latest) (push) Failing after 1s
Testing / tests (i386, latest) (push) Failing after 1s
Testing / tests (latest) (push) Failing after 1s
Testing / tests (latest-1) (push) Failing after 1s
Lock Threads / lock (push) Failing after 1s
Stale bot / stale (push) Failing after 1s
42 lines
1.3 KiB
Markdown
42 lines
1.3 KiB
Markdown
# Name resolving
|
|
|
|
This examples shows how `ClientConn` can pick different name resolvers.
|
|
|
|
## What is a name resolver
|
|
|
|
A name resolver can be seen as a `map[service-name][]backend-ip`. It takes a
|
|
service name, and returns a list of IPs of the backends. A common used name
|
|
resolver is DNS.
|
|
|
|
In this example, a resolver is created to resolve `resolver.example.grpc.io` to
|
|
`localhost:50051`.
|
|
|
|
## Try it
|
|
|
|
```
|
|
go run server/main.go
|
|
```
|
|
|
|
```
|
|
go run client/main.go
|
|
```
|
|
|
|
## Explanation
|
|
|
|
The echo server is serving on ":50051". Two clients are created, one is dialing
|
|
to `passthrough:///localhost:50051`, while the other is dialing to
|
|
`example:///resolver.example.grpc.io`. Both of them can connect the server.
|
|
|
|
Name resolver is picked based on the `scheme` in the target string. See
|
|
https://github.com/grpc/grpc/blob/master/doc/naming.md for the target syntax.
|
|
|
|
The first client picks the `passthrough` resolver, which takes the input, and
|
|
use it as the backend addresses.
|
|
|
|
The second is connecting to service name `resolver.example.grpc.io`. Without a
|
|
proper name resolver, this would fail. In the example it picks the `example`
|
|
resolver that we installed. The `example` resolver can handle
|
|
`resolver.example.grpc.io` correctly by returning the backend address. So even
|
|
though the backend IP is not set when ClientConn is created, the connection will
|
|
be created to the correct backend.
|