当前位置:首页 >专题 >Go gRPC 与 Protobuf 微服务工程实践
Go gRPC 与 Protobuf 微服务工程实践
官方入口与开发资料
先用 gRPC、Protobuf 和 Go 官方资料校准概念与 API
gRPC 官方网站
gRPC 官方项目入口,汇总概念、语言实现、教程、指南和生态资源。
gRPC Go Quick Start
官方 Go 快速开始,使用 proto 文件生成代码并运行 Greeter 客户端与服务端。
gRPC 核心概念
官方解释服务定义、四类 RPC、metadata、状态码、channel 与生命周期。
Protocol Buffers Go 教程
官方 Go 教程,覆盖 proto3 消息定义、protoc、Go 代码生成和序列化。
gRPC Go API 文档
Go gRPC 包 API 参考,覆盖 Server、ClientConn、status、metadata、codes 和 credentials。
gRPC Interceptors 指南
官方拦截器指南,说明客户端和服务端拦截器适合承载的横切逻辑。
gRPC Deadlines 指南
官方 deadline 指南,说明超时传播、取消和避免无限等待的实践。
grpc-go 官方仓库
Go gRPC 实现的源码、示例、发布版本和问题追踪入口。
grpc-gateway 官方仓库
官方维护的 gRPC to JSON/HTTP reverse proxy 与代码生成工具。
gRPC 与 Protobuf 常见问题
围绕协议演进、流式调用、超时和 HTTP 兼容的实用答案
gRPC 和 REST API 应该如何选择?
gRPC 适合内部服务间的强类型、高性能调用和流式通信;REST/JSON 更适合浏览器、开放平台和跨团队低门槛接入。常见做法是内部以 gRPC 为主,再通过 grpc-gateway 或 BFF 暴露 HTTP API。
修改 proto 字段时怎样保持兼容?
不要复用已删除字段的编号,新增字段使用新的 field number 并考虑默认值;对外契约要评估旧客户端、未知字段、枚举扩展和滚动发布顺序,必要时用 Buf breaking checks 做自动化检查。
四种 gRPC RPC 模式分别适合什么场景?
Unary 适合一次请求一次响应;服务端流适合持续推送;客户端流适合批量上传或聚合;双向流适合实时会话。选择时要同时考虑背压、取消、消息顺序、重连和流结束语义。
gRPC 服务为什么必须设置 deadline?
没有 deadline 的 RPC 可能在网络、依赖或连接异常时无限等待,持续占用 goroutine、连接和业务资源。客户端应设置合理 deadline,服务端检查 context,并让取消信号沿调用链传播。
相关专题
继续查看相近方向内容
-
- Go runtime.KeepAlive 为什么能保护底层句柄生命周期
- 2分钟前 393浏览
-
- Python 3.15 RISC-V 支持落地后扩展构建要检查哪些假设
- 3分钟前 493浏览
-
- Go module replace 指向本地目录后发布构建为什么失败
- 4分钟前 499浏览
-
- Java LongAdder 计数高并发时为什么比 AtomicLong 更适合
- 11分钟前 243浏览
-
- Go runtime.GC 手动触发后为什么不能当成内存释放按钮
- 14分钟前 187浏览
-
- PHP ReflectionProperty 读取 readonly 属性时有哪些限制
- 17分钟前 194浏览
-
- Go module 版本号带 pseudo-version 时怎么读提交时间
- 21分钟前 240浏览
-
- GitHub Copilot coding agent 的代码审查环节为什么不能省
- 23分钟前 309浏览

