链路上下文、灰度与故障传播：跨服务变化怎样保持同一旅程
把 trace context、灰度标签、版本路由、异步传播、采样、故障链和回滚指标连成可验证的跨服务治理模型。
OpenTelemetry Context Propagation 说明 context 在跨进程 carrier 中注入与提取，并提醒外部 trace header 与 baggage 的伪造和敏感数据风险。
Trace Context 表达因果关系，不表达身份真伪
入口提取或创建 traceId/spanId，下游调用在请求头或消息 header 中注入父上下文，接收方提取后创建子 span。线程池、CompletableFuture、Reactor 和消息消费会切换执行单元，若上下文未显式传播，日志与 span 会断链；若 ThreadLocal 未清理，又可能把上一请求 trace 泄漏给下一请求。
来自公网的 traceparent 可以用于继续或重新建立链路，但不能作为授权证据。baggage 会自动跨服务扩散，不能放 token、个人信息或无限增长的调试键。入口应限制 header 长度、清理不受信 baggage，并决定哪些内部目标允许继续传播。
灰度路由必须让整条依赖链理解版本
入口可按用户稳定哈希、租户、区域或白名单选择 v2，并把受控 route tag 传到下游。若只有 Gateway 进 v2、下游又随机落到 v1，新旧契约和数据语义会混合。每个服务要么理解并继续传递标签，要么明确在兼容边界终止；消息和异步任务还需把标签写入稳定信封。
标签路由依赖实例元数据，而元数据传播可能陈旧。灰度发布先确保 v2 能接收 v1 契约，再注册少量实例，等待发现缓存收敛后放量。回退时先停止新流量，再等待长请求、消息和任务完成；直接删实例会把旧路由缓存变成连接失败。
回滚判据要比较同时间窗的对照组
灰度指标按 routeVersion、operation 与结果聚合，比较 v1/v2 的错误率、尾延迟、业务转化、降级率和下游放大。用户 id 不进入指标标签，而通过采样 trace 定位。采样不能只保留成功请求；错误、慢请求和关键业务应有尾部或规则增强。
故障传播图要区分原始错误与派生错误。库存超时导致订单失败、Gateway 502 和客户端重试是同一根因的多个信号，不能按三个独立事故计数。回滚后仍要观察配置缓存、连接池、消息积压和异步任务是否继续携带 v2 标签，直到跨服务版本分布回到预期。
把同步调用画成预算递减的状态机
设计时为每条边记录 owner、协议、连接模型、超时阶段、重试责任、幂等键、流量上限、降级语义和回滚方式。同步扇出越大，成功率乘积越低，尾延迟取最大值；能异步解耦的非关键副作用不要停留在主请求链。
失败控制必须按依赖隔离
注册中心不可用、无实例、连接池满、连接失败、读取超时、业务拒绝和服务端错误要分型。只有动作未开始或有幂等保障的暂态失败允许重试；结果未知先查询或使用稳定幂等键。限流、隔离和熔断的拒绝应成为可观测结果，不能统一包装成空数据。
采样决定你能否看见低频灾难
头部采样在请求开始时决定是否记录，成本可控却看不到稍后才知道的错误；尾部采样在收集端根据完整 trace 的错误、时长和业务属性选择，能够保留异常但需要缓存更多 span。关键写操作、灰度版本和错误请求应提高保留概率，同时用速率上限防止事故时遥测反向压垮系统。
Span 数量也要有上限。循环逐条远程调用、每条 SQL 或每个消息都创建高基数属性，会放大 CPU、网络和存储。批量操作记录 count、失败样本和受控事件，不把 payload 与用户标识全量写入 span。观测必须帮助恢复，而不能成为新的敏感数据复制链。
用两个 Java 状态模型固定决策边界
这两个 Java 17 模型不启动真实注册中心、Gateway 或 RPC Server，而是把本篇的状态、预算和不变量转成确定输出。真实集成测试继续验证客户端协议、自动配置、连接复用、推送延迟与故障时序。
javac --release 17 -Xlint:all -Werror examples/backend-development/microservice/microservice-tracing-gray/TracePropagationDemo.java examples/backend-development/microservice/microservice-tracing-gray/GrayRoutingDemo.java
java -cp examples/backend-development/microservice/microservice-tracing-gray TracePropagationDemo
java -cp examples/backend-development/microservice/microservice-tracing-gray GrayRoutingDemotraceId=abc parentSpan=gateway childSpan=inventory asyncContextPreserved=true baggageTrusted=false
userBucket=17 targetVersion=v2 downstreamVersion=v2 fallbackToV1=false rollbackErrorRate=0.08状态模型输出变化时，要解释对应的服务边界、Deadline、版本或治理不变量为什么改变。集成测试必须主动制造连接已写出后超时、实例列表陈旧、配置刷新一半、半开探测和灰度标签断链。
契约、安全与配置共同决定可运营性
服务间认证使用短期身份、mTLS 或受信 token，身份上下文只从受控入口或服务网格生成。客户端传入的角色、租户、灰度和 trace header 不能未经校验直接信任。日志、metrics、baggage 和错误响应都不得扩散密钥或个人信息；URL 与 header 先规范化、脱敏并限制大小。
动态配置和发现元数据都可能陈旧。变更必须带版本、owner、范围、过期时间和回滚值，先灰度到少量实例并比较版本分布。会影响线程池、连接池、路由、限流和鉴权的配置要通过不变量校验，失败时保留上一完整快照。
容量与可观测证据要覆盖控制面和数据面
上线证据包括新旧契约互调、实例排空、Deadline 传播、幂等重试、治理状态机、灰度指标和回滚后的残留任务。完成标准不是“组件控制台显示健康”，而是业务不变量保持、未知结果可查询、故障被限制在预算内并最终收敛。
从开发环境到生产流量要跨过四层验证
依赖拓扑必须有复杂度上限
变更和回滚要覆盖控制面残留
架构评审要把“自动”翻译成具体责任
评审结论最终落成可执行证据：依赖图可以生成，BOM 不允许混 train，契约测试覆盖新旧版本，状态模型输出固定，故障注入验证未知结果，压测证明下游预算，灰度看板能区分版本，回滚演练清理控制面残留。微服务的成熟度不由服务数量或中间件数量衡量，而由边界是否自治、失败是否局部、变化是否可验证衡量。