故障隔离的核心是压测流量“看得见、分得清、写得对”，影子库/表实现数据层隔离，关键在路由精准、标透传全、边界严守；需同步强化日志、缓存、通知、对账等全链路隔离。
故障隔离的核心，是让压测流量“看得见、分得清、写得对”——不干扰生产数据、不触发真实业务逻辑、不污染监控和日志。影子库和影子表正是实现这一目标的数据层隔离手段，关键不在“建没建”，而在“路由准不准、标透传全不全、边界守不牢”。
影子表：轻量但需精细路由控制
影子表在生产数据库同一实例中创建，结构与原表一致，命名通常为 shadow_原表名（如 shadow_order）。它不新增数据库实例，节省资源，但要求所有写操作必须被精准识别并重定向。
- 依赖中间件或ORM层拦截：比如 MyCat、ShardingSphere 或自研分库分表组件，根据请求头中的压测标（如
X-Traffic-Tag: test）动态改写 SQL，将INSERT INTO order改为INSERT INTO shadow_order - 读操作默认走原表：除非明确需要验证影子链路读一致性，否则查询不走影子表，避免误读测试数据
- 风险点在于连接池共享：压测高并发可能挤占生产连接，需单独配置影子连接池，或限制影子流量的连接数上限
影子库：物理隔离更稳妥，但运维成本上升
影子库是独立的数据库实例（或同一实例下的独立 database），与生产库完全解耦。压测流量通过专属连接池访问，天然规避了资源争抢和误写风险。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 服务端需识别压测标后，主动切换数据源：例如 Spring Boot 中用 @DS("shadow") 注解或动态数据源路由规则
- 影子库可配置更低规格（如 CPU/内存减半），既降低成本，又模拟出“资源受限”下的真实瓶颈
- 缺点是需维护双套 DDL 同步机制（如监听生产库表变更，自动在影子库执行相同 DDL），否则结构不一致会导致压测失败
光有影子还不够：必须配合流量标全程透传
没有压测标，影子库/表就是摆设。标一旦丢失，压测请求就会像“无证车辆闯入主干道”，直写生产表，引发脏数据、误发短信、库存错扣等事故。
- 入口打标：网关统一注入
X-Pressure-Test: true+X-Scene-ID: d11-2026等多维标识 - 跨线程/跨MQ保标：使用 TransmittableThreadLocal 传递上下文；MQ 消息必须把标写进 headers 而非 body，消费端从中还原
- 定时任务与补偿逻辑是重灾区：它们常从数据库扫待办记录触发，原始请求标早已丢失，必须在落库时把标存入业务字段（如
trace_id、scene_id），供后续任务识别
额外隔离项不能漏：日志、缓存、通知、对账
数据写入影子库/表只是第一步。若日志没过滤、Redis 没区分、短信网关没拦截、下游对账系统照单全收，照样会出事。
- 日志打标：所有压测日志附加
[SHADOW]前缀，ELK 或 Loki 查询时可一键排除 - 缓存键加标：如
cache:order:12345:test，避免压测数据覆盖生产缓存 - 通知类接口熔断：短信、邮件、站内信等强副作用服务，在网关或 SDK 层直接返回 mock 响应
- 对账系统识别影子标记：从影子表同步的数据，需在 binlog 或 CDC 流中标记为
is_shadow=1，下游不做资金结算或用户触达
