微服务 API 技术栈

Q: 微服务 API 技术栈 的最佳实践有哪些？

微服务 API 技术栈 的最佳实践包括：用 buf 管理 protobuf — 代码检查、破坏性变更检测、代码生成；实现断路器 — sony/gobreaker 防止级联故障；使用 context 超时 — 所有外部调用用 ctx.WithTimeout，永不永久阻塞。其中首条「用 buf 管理 protobuf — 代码检查、破坏性变更检测、代码生成」应在项目初始化时就落地，避免后期返工。

Go + gRPC + PostgreSQL + Redis + NATS + OpenTelemetry，用于高吞吐微服务架构。

API 服务复杂

技术栈组成

LanguageGo 1.23

RPCgRPC + Protobuf

DatabasePostgreSQL 16

CacheRedis 7

Message QueueNATS JetStream

ObservabilityOpenTelemetry + Jaeger

DeployKubernetes + Helm

为什么

Go 编译为单二进制，内存比 Node.js 少 10 倍。gRPC 比 REST 快 3 倍且内置流式。

NATS 处理 100 万+ 消息/秒。此栈服务 10 万 RPS，p99 延迟 <10ms。

何时使用

选择此栈用于高吞吐 API（>1 万 RPS）、5+ 服务的微服务架构和延迟敏感系统（支付、实时竞价）。简单 CRUD 应用杀鸡用牛刀。

如何做

1. 定义 proto — api/proto/user.proto 含 service + message 定义 2. 生成 Go 代码 — protoc --go_out=. --go-grpc_out=. api/proto/*.proto 3. 实现服务 — internal/service/user.go 含 gRPC 服务端方法 4. 添加 PostgreSQL — sqlc 类型安全 SQL 查询，运行迁移 5. 添加 Redis — go-redis 缓存层，基于 TTL 失效 6. 添加 NATS — 写入时发布事件，订阅用于投影 7. 链路追踪 — OpenTelemetry SDK，DB + 缓存 + 队列调用 span 8. Docker + K8s — 多阶段 Dockerfile，Helm chart 部署

示例

// api/proto/user.proto syntax = "proto3"; service UserService { rpc GetUser(GetUserRequest) returns (User); rpc CreateUser(CreateUserRequest) returns (User); } message User { string id = 1; string email = 2; string name = 3; } message GetUserRequest { string id = 1; } message CreateUserRequest { string email = 1; string name = 2; } // internal/service/user.go — gRPC 实现 func (s *UserServer) GetUser(ctx context.Context, req *pb.GetUserRequest) (*pb.User, error) { ctx, span := tracer.Start(ctx, "GetUser") defer span.End() // 先查缓存 if cached, err := s.redis.Get(ctx, "user:"+req.Id).Bytes(); err == nil { var user pb.User proto.Unmarshal(cached, &user) return &user, nil } // 查询数据库 user, err := s.db.GetUserByID(ctx, req.Id) if err != nil { return nil, status.Errorf(codes.NotFound, "用户未找到") } // 缓存 5 分钟 data, _ := proto.Marshal(user) s.redis.Set(ctx, "user:"+req.Id, data, 5*time.Minute) return user, nil }

常见问题

⚠gRPC 调试困难 — 无 curl，用 grpcurl 或 Postman gRPC，添加反射服务
⚠Protobuf 破坏性变更 — 添加必填字段破坏旧客户端，用 optional
⚠分布式追踪断裂 — NATS handler 缺少上下文传播破坏链路
⚠连接池耗尽 — PostgreSQL max_connections 达上限，用 pgxpool 限制

最佳实践

✓用 buf 管理 protobuf — 代码检查、破坏性变更检测、代码生成
✓实现断路器 — sony/gobreaker 防止级联故障
✓使用 context 超时 — 所有外部调用用 ctx.WithTimeout，永不永久阻塞
✓用 slog 结构化日志 — 与 OpenTelemetry trace ID 关联

常见问题解答

什么是微服务 API 技术栈？适合做什么项目？

Go + gRPC + PostgreSQL + Redis + NATS + OpenTelemetry，用于高吞吐微服务架构。它通过分层组合提供端到端类型安全与开箱即用的部署体验，适合从 MVP 到生产 SaaS 的快速迭代。

如何用微服务 API 技术栈在 10 分钟内跑通一个 demo？

两步起步：① 定义 proto — api/proto/user.proto 含 service + message 定义；② 生成 Go 代码 — protoc --go_out=. --go-grpc_out=. api/proto/*.proto。先跑通本地 dev server，再接一个真实数据源验证端到端链路。