云原生微服务通信必须依赖服务发现与网络抽象，Golang需集成gRPC/protobuf、合理配置超时重试、避免硬编码IP、复用连接并补全可观测性。
云原生微服务间通信不能靠“硬写 IP + 端口”打通，必须依赖服务发现、动态寻址和网络抽象层——Golang 本身不内置这些能力，但能高效集成并驱动整个通信链路。
用 gRPC + Protocol Buffers 做服务间调用的底层协议
REST 在调试上友好，但内部服务通信选 gRPC 是更实际的选择：二进制序列化（protobuf）、HTTP/2 多路复用、天然支持流式、强类型契约。关键不是“能不能用”，而是“怎么避免掉坑”：
-
protoc生成代码时务必加--go_opt=paths=source_relative，否则导入路径错乱，go build报cannot find package - 服务端启动前，用
net.Listen("tcp", ":50051")检查端口是否被占用；K8s 中建议用port: 50051+targetPort显式对齐，避免 Service 和 Pod 端口不一致 - 客户端连接要设超时和重试：
grpc.WithTimeout(5 * time.Second)+grpc.WithConnectParams(grpc.ConnectParams{MinConnectTimeout: 3 * time.Second})，否则网络抖动时卡死在conn, err := grpc.Dial(...) - 别在
.proto里直接用time.Time或map[string]interface{}，改用google.protobuf.Timestamp和明确结构体，否则生成代码会出错或丢失类型安全
通过 Consul 或 Kubernetes Service 实现服务发现
硬编码地址在云原生环境等于自废武功。Golang 不需要自己实现注册中心，而是作为客户端接入现有体系：
- K8s 场景下，优先用 DNS 名称访问，比如
user-service.default.svc.cluster.local:50051，而不是查EndpointsAPI 再拼 IP —— K8s DNS 已自动做负载均衡和故障剔除 - 若用 Consul，用
github.com/hashicorp/consul/api注册服务时，必须设置Check.TCP或Check.HTTP，否则健康检查失败，服务上线后立刻被踢出列表 - 客户端侧做服务发现时，不要每次调用都查 Consul；应缓存结果 + 启动 goroutine 定期刷新（如 30s 一次），避免 DNS 查询成为性能瓶颈
- 注意 gRPC 的
resolver插件机制：可自定义Resolver实现从 Consul 动态拉取 endpoints，但生产环境更推荐用grpc-go官方支持的dnsresolver（配合 K8s）或etcdresolver（需额外引入）
容器网络打通：别碰 netns/veth，除非你真在写 CNI
有人想用 Golang 直接操作 veth、bridge、iptables 来连通容器——这属于造轮子行为。真实项目中：
立即学习“go语言免费学习笔记（深入）”；
- 宿主机上用
docker network create --driver bridge mynet创建自定义网络，启动容器时指定--network mynet，Docker 自动完成 veth 配对、IP 分配、DNS 解析 - 若用 Kubernetes，直接写
Service资源对象，ClusterIP 模式下所有 Pod 默认可通过 service 名互通，无需 Golang 代码参与网络配置 - 真要控制底层（如写网络策略控制器），才用
github.com/vishvananda/netlink，但要注意：调用netlink.LinkAdd()前必须sudo权限，且容器内默认无权限操作 netns，只能在宿主机进程里跑 - 别在容器里执行
ip link add或iptables -t nat -A POSTROUTING—— 大部分容器镜像没装iproute2或iptables，且违反不可变基础设施原则
可观测性补位：日志、指标、链路缺一不可
通信链路一旦变长（服务 A → B → C），出问题时单看 Golang 代码毫无意义。必须让每条请求自带上下文：
- 用
opentelemetry-go在 gRPC server middleware 中注入 trace ID，客户端调用时透传metadata.MD，否则 Jaeger / Tempo 查不到跨服务链路 - HTTP/gRPC 错误码要映射成语义明确的 status code：比如数据库查不到用户，返回
status.Error(codes.NotFound, "user not found")，而不是裸抛fmt.Errorf - 日志用
zap并结构化输出，至少带上service_name、trace_id、rpc_method、duration_ms字段，否则 Prometheus 无法聚合grpc_server_handled_total - 别在 handler 里写
log.Printf打印完整 request body——可能含敏感字段，且 JSON 序列化易 panic；用zap.Stringer包装或显式过滤字段
最常被忽略的一点：gRPC 连接复用不是默认“开箱即用”的。一个服务实例如果每处理一个请求就新建 grpc.Dial，不出三天就会遇到 too many open files。必须全局复用 *grpc.ClientConn，并配合 WithBlock() 和 WithTransportCredentials(insecure.NewCredentials())（开发环境）或 TLS（生产环境）来初始化。
