基于grpc-spring-boot-starter的gRPC客户端如何配置<服务名:端口>格式的服务端地址

两类scheme的适用边界 #

首先明确两个地址scheme的设计定位，避免配置选型偏差：

• static:// 方案：设计目标是跳过所有服务发现流程，直接使用配置项中硬编码的地址列表建立gRPC连接，本身支持IPv4地址、IPv6地址、可被DNS解析的主机名+对应端口，同时支持多地址以逗号分隔实现客户端负载均衡。
  之前配置static://service-name:port时报错，本质不是scheme不支持服务名写法，而是当前运行环境无法正常解析该服务名、或对应端口未开放连通性，而非static方案不适配该场景。
• discovery:// 方案：设计目标是对接Spring Cloud生态的服务发现体系，本身不要求配置端口信息——所有服务实例的IP、端口信息完全由所对接的注册中心（如Nacos、Eureka、Consul）提供，starter会自动从注册中心拉取实例元数据完成寻址。

正确配置选型 #

根据部署场景选择对应配置即可，不需要盲目替换scheme：

1. 当目标gRPC服务没有注册到当前应用依赖的服务发现组件（如仅通过集群DNS互通的服务），继续使用static scheme即可：
   • 配置格式：grpc.client.name.address=static://service-name:gRPC服务实际监听端口
   • 前置校验：在应用运行环境中执行服务名解析命令，确认service-name可以正常解析到目标服务的IP，同时确认对应端口已通过网络策略、安全组的连通性校验。
2. 当目标gRPC服务已注册到和当前应用同一套的注册中心，直接使用discovery scheme配置：
   • 配置格式：grpc.client.name.address=discovery://目标服务在注册中心的注册名称
   • 注意：该场景下无需在地址配置中填写端口，starter会自动读取注册实例元数据中存储的gRPC端口信息完成连接。

补充：UNAVAILABLE: io exception 属于底层网络连通性类报错，选型正确后仍出现该报错时，优先排查服务名解析结果、端口连通性、目标gRPC服务运行状态，而非反复调整scheme类型。

内容的提问来源于stack exchange，提问作者Nimrod