📚 课程目录第1章课程导论

1. 课程导论：gRPC事务边界故障的典型场景与排查痛点

在微服务架构中，gRPC凭借其高性能、强类型和双向流特性，已成为服务间通信的首选协议。然而，当业务逻辑跨越多个gRPC调用构成一个逻辑事务时，故障排查的复杂度呈指数级上升。本导论将系统梳理gRPC事务边界的典型故障模式，并揭示传统排查手段的致命短板。

事务边界是指一个业务操作在多个gRPC服务之间形成的一致性范围。与数据库本地事务不同，gRPC事务边界通常没有全局锁或两阶段提交，而是依赖补偿、重试和幂等性来维持最终一致性。

  关键定义： gRPC事务边界 = 发起方调用 + 下游服务处理 + 响应回调 + 补偿逻辑，这四个阶段共同构成一个不可分割的故障排查单元。

根据生产环境统计，gRPC事务边界故障可归纳为以下六大类。下表列出了每类故障的触发条件、典型表现和排查难度。

在引入可观测性之前，工程师面对gRPC事务边界故障时，往往陷入以下三个无法逾越的困境。

调用链断裂：gRPC的二进制协议和连接复用机制，使得传统日志无法将一次事务的多个调用关联起来。每个服务只看到自己的局部日志，无法还原全局调用拓扑。
状态盲区：事务边界内的中间状态（如“已扣款但未发货”）在服务端没有持久化记录。故障发生时，工程师无法判断事务执行到哪一步，只能靠猜测。
时序混乱：多个gRPC调用可能并发执行，日志时间戳受时钟偏移影响，导致事件顺序错乱。在排查“先扣款后发货”还是“先发货后扣款”这类问题时，时序错误直接导致误判。

典型教训： 某电商团队在双11大促期间，因gRPC超时重试导致库存服务被重复调用，最终超卖2000单。事后复盘发现，日志中出现了6个不同TraceId的扣减请求，但实际只有1笔真实订单——传统日志完全无法揭示重试与原始请求的关联关系。

下图展示了gRPC事务边界在缺乏可观测性时的真实状态。每个服务节点都是一个“黑盒”，工程师只能看到入口请求和出口响应，而事务内部的执行路径、状态变化和异常点完全不可见。

图中每个问号代表一个排查盲点：服务A是否成功调用了服务B？服务B的响应是否被正确解析？服务C的补偿逻辑是否触发？在没有链路追踪和分布式日志聚合的情况下，这些问题只能通过“重启大法”或“逐行打日志”来试探，效率极低。

要系统性地解决gRPC事务边界故障，必须建立可观测性的三大支柱。下表对比了传统手段与可观测性方案在事务边界排查中的核心差异。

维度	传统手段	可观测性方案	对事务边界的价值
日志	单机文件，无关联ID	结构化日志 + TraceId注入	将一次事务的所有日志串联成完整时间线
指标	CPU/内存等基础设施指标	RED指标 + 业务指标	实时发现事务成功率、延迟和吞吐量异常
链路追踪	无	分布式追踪 + Span上下文	可视化展示事务在服务间的完整调用拓扑

课程核心主张： 本课程将证明，只有将三大支柱在gRPC事务边界处统一对齐，才能实现“一次定位、精准修复”的排查效果。任何单一维度的可观测性都无法独立解决事务边界问题。

为保障实战效果，本课程所有案例均基于以下技术栈构建，并会在后续章节中逐一展开。