跨集群gRPC通信必须通过Envoy+gRPC-Web代理或Shenyu网关等控制面统一处理服务发现与协议转换，禁用直连；需严格统一protobuf、gRPC及proto依赖版本，确保注册中心互通与proto元数据准确注册。
gRPC跨集群通信必须绕开直连，否则会卡在DNS和连接池上
直接用 grpc.Dial("cluster-b.example.com:9000") 调用另一个集群的服务，在云原生环境里基本走不通。Kubernetes Service DNS 在跨集群场景下不解析、grpc.ClientConn 默认复用连接但无法感知远端集群节点上下线、HTTP/2 连接一旦建立就长期持有，导致故障转移延迟高甚至永久失败。
- 真实场景中，
cluster-b的 Pod IP 和 Service ClusterIP 都不可路由，必须走 Ingress 或专用网关出口 -
grpc.Dial的WithBlock()会阻塞初始化，跨集群网络抖动时直接 hang 住服务启动 - 默认的
round_robin负载均衡器只对本地 DNS A 记录有效，对跨集群 VIP 或域名无效 - 正确做法是把目标集群抽象为「逻辑后端」，由统一控制面（如 Shenyu 网关或 Linkerd mTLS mesh）接管寻址与重试
用 gRPC-Web + Envoy 做透明代理是最稳的落地方式
别自己写反向代理转发 gRPC 流量——HTTP/2 帧、流控窗口、头部压缩、Trailers 处理极易出错。Envoy 是目前唯一被大规模验证能无损透传 gRPC 全特性的代理，配合 gRPC-Web 可让集群间通信走标准 HTTPS 端口，规避防火墙和 TLS 中间件干扰。
- 客户端用
grpcwebproxy或 Envoy 的envoy.filters.http.grpc_web过滤器，把 gRPC 调用转成 gRPC-Web 格式（POST + base64 payload） - 服务端保持原生 gRPC Server 不变，Envoy 在入口处解包还原为标准 gRPC 流，无需改业务代码
- 关键配置项：
http_filters中启用grpc_web，route_config设置auto_host_rewrite: true避免 Host 头污染 - 注意：gRPC-Web 不支持服务器流（server streaming），若业务依赖
rpc StreamData(Request) returns (stream Response)，得降级为客户端轮询或改用双向流（bidi streaming）
Shenyu 网关的 gRPC 插件不是开箱即用，要手动补注册中心适配
Shenyu 的 shenyu-plugin-rpc 模块虽支持 gRPC 协议转换，但它默认只认 ZooKeeper/Eureka/Nacos 上注册的「HTTP 服务」，gRPC 服务元数据（如 proto 文件路径、方法签名）不会自动同步。不补这一环，路由规则根本匹配不到真实后端。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须在
shenyu-client-grpc客户端启动时，显式调用GrpcRegisterService.register()，把serviceName、serviceVersion、protoMd5、methods四元组推到注册中心 - Shenyu Admin 后台需手动导入对应
.proto文件，并确保package和service名与客户端注册一致，否则插件解析请求体失败，返回UNIMPLEMENTED - 跨集群时，不同集群的注册中心必须互通（如 Nacos 跨地域集群模式），或通过 Shenyu 的「跨注册中心同步」能力桥接，否则路由永远查不到远端服务
- 测试时用
curl -X POST http://shenyu-gateway:9195/grpc -H 'Content-Type: application/json' -d '{"method":"/helloworld.Greeter/SayHello","data":{"name":"test"}}'可快速验证链路是否通
Proto 版本和包名不一致会导致 runtime panic，而不是编译报错
Go 里 protoc-gen-go 和 protoc-gen-go-grpc 对 syntax = "proto3" 的兼容性很敏感。如果集群 A 用 protobuf v3.21 编译，集群 B 用 v4.22，即使 .proto 文件一字未改，运行时也可能在 Unmarshal 阶段 panic： proto: can't skip unknown wire type 7 —— 这是因为新版 Protobuf 引入了 packed repeated 字段的 wire type 变更。
立即学习“go语言免费学习笔记（深入）”；
- 所有集群必须统一
protoc版本（建议锁定3.21.x），且生成代码时指定--go-grpc_opt=require_unimplemented_servers=false兼容旧服务端 -
package名必须全局唯一，比如package user.v1;和package user.v2;是两个完全隔离的命名空间，混用会找不到 service descriptor - Go 模块中
import "google.golang.org/grpc"的版本也要对齐，v1.58.0以上才完整支持 HTTP/2 ALPN 和 TLS 1.3，老版本在跨公网场景下容易 handshake timeout - 最隐蔽的坑：不同集群的
go.mod里google.golang.org/protobuf版本不一致，会导致proto.Equal()行为异常，日志里看不出错，但鉴权或灰度路由逻辑静默失效
