必须隔离核心交易与营销查询链路，因其业务后果迥异：支付失败引发客诉、资损、监管上报，而营销加载慢仅致用户离开；隔离通过流量标记、数据库三级隔离、缓存/中间件拆分、熔断降级及分链路可观测实现。
核心交易与营销查询链路必须隔离，不是因为它们“类型不同”，而是因为它们的业务后果完全不同：一笔支付失败可能引发客诉、资损、监管上报；一次营销页加载慢，用户最多刷新或离开。隔离的本质，是让高风险、强一致、低容忍的交易链路，不受低优先级、高波动、可降级的查询链路干扰。
按业务语义做流量标记与路由分流
所有进入系统的请求，必须在最前端（如API网关或ServiceMesh入口）携带明确的业务上下文标识。常见做法是统一约定请求头，例如：
-
x-business-type: core-payment（核心交易） -
x-business-type: marketing-query（营销查询）
这些标识不依赖客户端传入，而由网关根据路径、方法、Token权限等自动打标。比如 /api/v1/order/pay 自动打 core-payment，/api/v1/campaign/banner 自动打 marketing-query。标记后，通过 ServiceMesh（如Istio）的 VirtualService + DestinationRule 规则，将两类流量导向完全独立的服务实例组和资源池：
# 路由到高保障Pod组（带priority=high标签）
- match:
headers:
x-business-type:
exact: core-payment
route:
- destination:
host: payment-service
subset: high-priority
关键点：两个子集（subset）背后是物理或逻辑隔离的Pod，CPU、内存、数据库连接池、缓存命名空间全部不共享。
数据库层强制租户级与用途级隔离
不能让营销查询和订单写入共用同一张 order 表或同一个MySQL实例。推荐三级隔离：
第一级：库分离
core_db（强一致性，主从+半同步，binlog保留72小时） vsmarketing_ro_db（只读副本，延迟容忍≤30秒，定期重建）第二级：表前缀/Schema隔离
即使同库，营销统计表用mkt_user_click_202609前缀，核心订单表用core_order_202609，避免误操作或SQL注入穿透-
第三级：连接池与执行计划隔离
应用端使用不同数据源配置（如coreDataSource/mktDataSource），并设置不同连接池参数：- 核心数据源：最大连接数小（如50）、超时短（3s）、启用事务传播校验
- 营销数据源：最大连接数大（200）、允许长查询（30s）、禁用事务嵌套
某银行核心系统重构后，营销报表查询导致的慢SQL再未影响过支付TTL，正是靠这三层硬隔离。
缓存与中间件按链路切面拆分
- Redis 实例不混用：
redis-core-pay（持久化开启、maxmemory-policy volatile-lru）与redis-mkt-banner（纯内存、noeviction 策略防驱逐误伤） - 消息队列 Topic 分开：
core.order.created.v1和mkt.user.viewed.v1不共用一个Topic，消费组也完全独立 - 本地缓存（Caffeine/Guava）禁止跨链路复用：
CoreOrderCacheLoader和MktBannerCacheLoader各自管理生命周期与刷新策略
特别注意：营销查询若依赖订单数据，必须走「异步快照」而非实时JOIN。例如每日凌晨将核心库订单状态快照至营销库，查询时只读快照——切断实时耦合。
故障时自动熔断与降级不越界
当营销服务不可用，核心交易不能因此失败，也不能因“兜底查营销数据”而拖慢自身。要做到：
- 核心链路代码中，所有对营销服务的调用必须包裹 Hystrix 或 Resilience4j 熔断器，且 fallback 返回静态默认值（如“暂无活动”），不重试、不日志告警（避免刷屏）
- 熔断器配置激进：错误率阈值设为 20%（非默认50%），10秒内5次失败即熔断，恢复窗口≤30秒
- 数据库层面，营销查询超时直接抛
SQLTimeoutException，由上层捕获并降级，绝不让慢查询占用核心连接池
一线支付系统实践表明，将营销查询链路整体熔断后，核心支付P99延迟下降42%，DB CPU峰值回落至安全水位以下。
可观测性必须分链路建模
监控、日志、链路追踪不能共用一套大盘。要分别建设：
- 核心交易看板：聚焦
pay_success_rate、db_core_write_p99、redis_core_set_latency、order_state_machine_stuck_count - 营销查询看板：关注
mkt_qps、mkt_cache_hit_rate、mkt_db_ro_delay、banner_render_timeout - 链路追踪中，强制
service.name标签区分payment-service-core与marketing-service-ro，避免Span混排误导定位
没有分链路的可观测，就等于没有隔离——你永远不知道抖动来自哪一边。
基本上就这些。
