服务编排的核心是隔离编排逻辑与业务服务，需通过事件或抽象契约交互、避免强耦合；应置于internal/orchestration层且不持db连接；禁用grpc改用http+消息队列；temporal落地须严守初始化顺序与序列化约束。
服务编排不是写个 workflow 就完事
服务编排在 Go 微服务里常被误认为是“用 Temporal 或 Cadence 写个流程图”。实际痛点在于：编排逻辑一旦和业务强耦合，就会变成不可测试、难回滚、无法灰度的单点故障。真正该关注的是编排层与服务边界的隔离程度——编排代码里不能出现 UserService.Create 这类具体服务调用，而应通过事件或抽象契约交互。
常见错误现象：
- 编排函数直接 new 一个
OrderService实例并调用其方法，导致单元测试必须启动整个依赖链 - 状态机逻辑硬编码在编排器里（如 “支付成功 → 发货 → 通知”，没抽象成可配置规则）
- 超时、重试、补偿全部写死在编排代码里，上线后无法动态调整
实操建议：
- 用接口定义编排契约，比如
type OrderFlow interface { Start(ctx context.Context, orderID string) error }，实现由具体服务提供 - 把状态迁移规则抽到外部配置（如 YAML 或 Consul KV），编排器只负责加载和执行，不参与决策
- 补偿动作必须是幂等且可独立触发的，避免依赖编排器当前状态，例如用
CancelOrderCmd而非flow.RollbackStep(2)
Go 里编排层该放在哪？别塞进 service 或 gateway
很多团队把编排逻辑塞进 cmd/api 或直接扔进 internal/service，结果是它既不像 API 那样暴露 HTTP 接口，又不像 service 那样专注领域逻辑，最后变成没人敢动的“幽灵包”。Go 项目里最合理的编排层位置是 internal/orchestration，且必须满足两个条件：不持有任何 DB 连接、不直接 import 具体 service 包。
使用场景：
- 跨多个服务的长事务（如下单+扣库存+发券+推消息）
- 需要人工干预或状态审核的流程（如退款审批流）
- 第三方系统集成桥接（如对接银行支付网关 + 内部账务系统）
参数差异：
- 编排器接收的是 DTO（如
OrderPlacedEvent），不是 domain model - 所有下游调用必须通过 interface 注入，禁止
import "xxx/internal/service/order" - 启动时需显式注册 handler，比如
orchestrator.Register("order-create", NewOrderFlow())
为什么 gRPC 不适合做编排通信协议
gRPC 的强契约和同步阻塞特性，让它在服务间调用中表现优异，但在编排场景下反而成为瓶颈。编排本质是异步、状态驱动、可能长时间挂起的操作，用 gRPC 容易触发客户端超时、服务端 goroutine 泄漏、链路追踪断点等问题。
性能 / 兼容性影响：
- 一次编排流程涉及 5 个服务调用，若全走 gRPC 同步串行，P99 延迟会线性叠加；改用事件驱动后可降为最大单跳延迟
- gRPC 的 proto 版本升级需上下游同时发布，而编排层往往滞后于业务服务迭代，导致兼容性断裂
- Kubernetes liveness probe 会因编排长期运行误判服务异常，触发不必要的重启
实操建议：
- 编排触发用 HTTP POST（轻量、易调试、天然支持幂等 header）
- 服务间协作用消息队列（如 Kafka 或 NATS JetStream），事件 payload 用 JSON Schema 约束而非 proto
- 状态查询走独立的只读 API（如
GET /orchestration/{id}/status），不复用 gRPC 通道
Temporal 在 Go 项目里的落地陷阱
Temporal 是目前 Go 生态最主流的编排引擎，但直接 go run main.go 启一个 worker 往往跑不通。根本问题不在 SDK，而在 Go 项目的初始化顺序和依赖注入方式不匹配 Temporal 的生命周期模型。
常见错误现象：
- worker 启动时报
failed to start worker: failed to get client: rpc error: code = Unavailable desc = connection closed，其实是temporal.Client初始化早于配置加载 - Workflow 函数里调用了未 mock 的
log.Sugar()，导致测试 panic，因为 Temporal 的 test framework 不接管你的日志封装 - 使用
workflow.Sleep模拟延时，但生产环境因 clock skew 导致定时不准，且无法被 Prometheus 抓取
实操建议：
- Temporal client 必须在配置加载完成、logger 初始化之后创建，推荐放在
cmd/orchestrator/main.go最后一步 - 所有 Workflow 函数参数必须是可序列化的结构体，禁止传入
*sql.DB或context.Context（Temporal 自己管理） - 用
workflow.Now(ctx)替代time.Now()，确保时间语义一致；监控指标统一走temporal-go提供的metrics.Handler
复杂点往往藏在初始化顺序和类型约束里，而不是语法或 API 调用本身。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
