Seata 分布式事务与服务网格

• 网关安全分层
• 限流防刷与 WAF/Bot
• 鉴权与 DDoS 放大

网关安全分层：外层做限流防刷、WAF（Web 应用防火墙）、Bot 防护，内层做认证授权。协作顺序：WAF/Bot 防护在最外层过滤恶意流量 → 限流防刷控制流量规模 → 认证授权验证身份授权。避免鉴权成为 DDoS 放大点：鉴权涉及 JWT 验签、token 校验、数据库查询等计算，若直接对每个请求做高强度鉴权，攻击者可用大量无效请求消耗鉴权资源（放大点）。因此：先做低成本防护（限流、WAF、IP 黑名单）过滤大部分恶意流量，再对剩余流量做鉴权；鉴权失败快速失败，避免进入重逻辑。工程上：分层防护（WAF/限流前置 + 鉴权后置），避免鉴权成为被攻击的瓶颈。

分层协作是"低成本防护前置、高成本鉴权后置"。避免鉴权被无效请求打爆。WAF/Bot/限流过滤，鉴权只处理有效流量。

• 动态路由
• 服务变更监听
• 刷新机制

Gateway 集成 Nacos 时，动态路由刷新：路由定义（RouteDefinition）变化通过配置中心刷新，服务实例变化通过 Nacos 服务发现推送。ServiceDefinitionChangeListener：Nacos 客户端的 ServiceChangeListener（或 EventListener）监听服务实例变化，当实例上下线时触发回调，Gateway 据此更新路由缓存/实例列表。动态路由刷新机制：路由指向 Nacos 服务名（lb://service），服务实例变化时 Nacos 推送，LoadBalancer 缓存更新，Gateway 无需重启即可路由到新实例。工程上：用 ServiceDefinitionChangeListener 监听服务变化，结合 lb:// 路由与 LoadBalancer 缓存刷新，实现动态路由。

动态路由依赖"服务变更监听 + 缓存刷新"。ServiceDefinitionChangeListener 感知实例变化，LoadBalancer 更新。路由定义与实例分离刷新。

• 令牌桶算法
• Redis + Lua 原子性
• 限流原理

Gateway 的 RequestRateLimiter 过滤器基于 Redis 实现令牌桶限流：令牌桶以固定速率生成令牌，请求需取令牌通过，桶满则拒绝。实现用 Redis 的 Lua 脚本（request_rate_limiter.lua）保证原子性：脚本读取当前令牌数、上次补充时间，按速率补充令牌，判断是否足够，扣减并返回通过/拒绝。KeyResolver 定义限流 key（如按用户、按 IP）。原理：用 Redis 存储令牌桶状态（令牌数、时间戳），Lua 脚本原子执行"补充+判断+扣减"，避免并发竞态。集群环境下 Redis 提供共享状态，实现分布式限流。工程上：key 用低基数（用户/IP），阈值合理，Lua 保证原子。

RequestRateLimiter 是"令牌桶 + Redis 分布式状态 + Lua 原子性"。Redis 共享状态支持集群限流，Lua 防并发竞态。

• 熔断集成
• fallbackUri 降级
• 配置

Gateway 熔断集成：可接 Sentinel（spring-cloud-alibaba-sentinel-gateway）或 Resilience4j（spring-cloud-starter-circuitbreaker-reactor-resilience4j）。熔断后降级响应：fallbackUri 过滤器（SpringCloudCircuitBreakerFilterFactory）配置熔断/失败时的降级转发地址——fallbackUri: forward:/fallback 或 lb://fallback-service，熔断时将请求转发到 fallback 地址返回降级响应。配置示例：路由的 SpringCloudCircuitBreaker 过滤器指定 fallbackUri，熔断触发时转发。工程上：熔断（Sentinel/Resilience4j）+ fallbackUri 降级，实现网关容错与优雅降级。

熔断保护下游，fallbackUri 降级响应。熔断组件 + fallbackUri 过滤器实现网关容错。区分熔断执行与降级转发。

• 网关监控端点
• 路由指标
• Prometheus 集成

Gateway 监控：/actuator/gateway/routes 暴露当前路由列表（路由定义），用于查看路由配置；/actuator/gateway/globalfilters、/actuator/gateway/routefilters 查看过滤器。指标：Gateway 通过 Micrometer 暴露指标（请求数、延迟、错误），接入 Prometheus（/actuator/prometheus）。集成：配置 management.endpoints.web.exposure.include=gateway,prometheus，引入 micrometer-registry-prometheus，Prometheus 抓取网关指标，Grafana 展示。监控点：路由数量（路由配置异常）、请求 QPS、延迟、错误率、熔断/限流次数。工程上：暴露 gateway 端点 + Prometheus 指标，监控路由与流量。

网关监控分"路由端点"（显示配置）与"指标"（流量统计）。Prometheus 采集指标，Grafana 展示。监控路由数量与流量健康。

• TraceID/SpanID
• 上下文传播
• OTel 集成

Gateway 作为入口，负责链路追踪的 TraceID/SpanID 生成与注入：Gateway 为每个请求生成 TraceID，创建入口 Span，并通过 HTTP 头（traceparent/baggage）把 Trace 上下文传播到下游服务，下游服务继续 trace。OpenTelemetry 集成：Spring Boot 3+ 用 Micrometer Observation + OTel，Gateway 通过 HttpServerObservation 自动生成 span，配合 OTel 的 W3CTraceContextPropagator 传播 TraceContext。上下文传播：Gateway 接收上游 traceparent（若已有 trace 则沿用），生成根 span，注入 traceparent 到下游请求头，形成完整链路。工程上：Gateway 统一生成/传播 TraceID，关联日志与指标，实现全链路可观测。

Gateway 是链路入口，负责 TraceID 生成与上下文传播。OTel 的 W3C 传播器把 traceparent 传给下游。统一入口保证链路完整。

• KeyResolver
• 多维度限流
• 限流策略

Gateway 的 RequestRateLimiter 通过 KeyResolver 定义限流维度（key）：默认按 IP，可自定义按用户（从 JWT/Header 取 userID）、按 API Key（从 Header 取 key）。实现：定义 KeyResolver Bean，返回限流 key（用户 ID、IP、API Key），RequestRateLimiter 按该 key 限流。多维度：按用户限流（防单用户刷）、按 IP 限流（防爬）、按 API Key 限流（按调用方配额）。可组合：多个限流过滤器（不同 KeyResolver）分别限流不同维度。KeyResolver 需返回低基数 key（用户/API Key 有限），避免高基数。工程上：自定义 KeyResolver 实现按用户/IP/API Key 多维度限流。

KeyResolver 决定限流维度。按用户/IP/API Key 是多维度限流的 key 来源。多个过滤器可组合多维度。key 需低基数。

• Netty 线程模型
• acceptor/worker 线程
• 性能调优

Spring Cloud Gateway 基于 WebFlux/Netty，采用 Reactor 模式：acceptor（boss）线程负责接受连接，worker（event loop）线程负责处理 IO 事件；业务处理在 event loop 线程上（响应式非阻塞）。高并发下线程模型：acceptor 线程数较少（核心数），worker 线程数默认 可用核数 * 2（spring.webflux 相关配置）。性能调优：worker 线程数（server.netty 或 spring.webflux 的 event loop 配置）——根据并发与 CPU 调整；避免在 event loop 线程做阻塞操作（会阻塞事件循环）；连接队列、超时、线程池分离。关键：非阻塞模型下 worker 线程数不必过多，重点是避免阻塞与合理 backlog。工程上：调优 worker 线程数、避免阻塞 event loop、监控线程利用率。

Reactor 模型是"acceptor 接受 + worker 处理 IO"。非阻塞设计下 worker 数基于 CPU/并发，重点是避免阻塞 event loop。调优关注线程利用与阻塞。

• 全局锁
• undo_log 回滚日志
• AT 模式原理

Seata AT 模式：分支事务执行本地 SQL 时，Seata 拦截并记录 undo_log（回滚日志：before image、after image），同时获取全局锁（GlobalLock）防止并发冲突。全局锁：保证同一数据的并发事务串行，避免脏写；undo_log：记录数据变更前后镜像，用于回滚时恢复。执行流程：本地事务执行 SQL → 记录 undo_log（before/after image）→ 获取全局锁 → 提交本地事务 → 全局事务提交时向 TC 汇报，删除 undo_log；回滚时按 undo_log 的 before image 生成反向 SQL 恢复数据。全局锁与 undo_log 是 AT 模式"无侵入回滚"的关键。工程上：AT 模式依赖 undo_log 表与全局锁，需建表并注意锁冲突。

AT 模式核心是"全局锁 + undo_log"。全局锁防并发，undo_log 提供回滚能力。before/after image 是回滚的数据基础。

• 全局锁作用
• 锁管理
• 冲突处理

Seata AT 模式的全局锁（Global Lock）用于保证分布式事务中同一数据的并发访问安全：分支事务在修改数据时，会向 TC 申请全局锁（对应数据行），其他分支事务修改同一数据时需等待锁。全局锁管理：TC 维护全局锁（锁对应 resourceId + 行），分支事务提交本地事务前获取锁，全局事务提交/回滚后释放锁。冲突处理：若锁被占用，分支事务等待（LockConflictException），超时则失败/重试。全局锁防止"多个全局事务同时修改同一数据"导致数据不一致。工程上：全局锁保证并发安全，但锁冲突影响性能，需合理设计事务粒度。

全局锁是 AT 模式的并发控制。TC 管理锁，分支事务申请/释放。防止并发写冲突，锁冲突需重试。

• SAGA 模式原理
• 长事务处理
• 补偿机制

Seata SAGA 模式用于长事务：把长事务拆分为多个子事务（正向步骤），每个子事务有对应的补偿（反向）步骤，通过状态机编排。长事务优势：避免长事务持有数据库锁过久（相比 AT/XA 的全局锁，SAGA 每个子事务独立提交，释放锁），适合跨服务、耗时长的业务流程。SAGA 通过正向步骤执行 + 失败时反向补偿回滚，实现最终一致。补偿机制：若某步骤失败，按状态机反向执行已执行步骤的补偿。SAGA 无隔离性（各子事务独立提交，中间态可见），需业务补偿。适用长事务：订单流程、跨服务编排、异步流程。工程上：SAGA 适合长事务，用状态机定义步骤与补偿。

SAGA 是"长事务拆分 + 补偿"模式。每个子事务独立提交释放锁，失败反向补偿。无隔离性，需业务补偿。适合长流程。

• SAGA 与工作流引擎
• 跨服务编排
• 协作方式

Seata SAGA 模式与工作流引擎（Camunda/Activiti）在长事务与跨服务编排中协作：SAGA 提供分布式事务的补偿能力，工作流引擎提供流程编排（状态机、人工审批、条件分支）。协作方式：用工作流引擎（Camunda/Activiti）编排跨服务的业务流程（正向步骤），每个步骤的分布式事务用 Seata SAGA 定义补偿；SAGA 状态机处理事务补偿，工作流引擎处理流程流转。Seata 的 SAGA 状态机（StateMachineEngine）可定义正向/补偿步骤，与工作流引擎结合实现复杂的长事务编排。SAGA 适合"化整为零"的跨服务流程，工作流引擎适合"流程驱动 + 人工干预"。工程上：长事务用 SAGA 补偿，复杂流程用工作流引擎编排，二者结合。

SAGA 管"事务补偿"，工作流引擎管"流程编排"。结合实现复杂跨服务长事务。SAGA 状态机定义补偿，引擎驱动流程。

• TCC 三阶段
• 业务侵入性
• 性能取舍

Seata TCC 模式：Try（预留资源）→ Confirm（确认提交）→ Cancel（取消回滚）三阶段。业务侵入性：TCC 侵入性最高——需业务实现 Try/Confirm/Cancel 三个方法，手动管理资源预留与释放，代码复杂；性能：TCC 性能较好——资源在 Try 阶段预扣，Confirm 阶段释放，无全局锁持有（相比 AT 的全局锁），各阶段独立事务，性能高。取舍：TCC 用"业务侵入性"换取"性能与资源控制"——适合资源可预扣、需要强隔离与高性能的业务（如库存、账户、积分）；AT 用低侵入（自动记录 undo_log）但依赖全局锁，性能略低。选型：需要高性能、资源可预扣选 TCC；需要低侵入选 AT。工程上：TCC 权衡侵入性 vs 性能，适合预扣型业务。

TCC 是"高侵入 + 高性能"。Try 预扣、Confirm 释放、Cancel 回滚，各阶段独立事务性能高。与 AT 的"低侵入 + 全局锁"权衡。

• Seata 与事务消息
• 最终一致性
• 协作模式

Seata 与 RocketMQ 事务消息在最终一致性场景协作：Seata 保证本地事务与分布式事务的一致性，RocketMQ 事务消息保证"本地事务与消息发送"的原子性。协作模式：业务流程中，Seata 处理跨服务的数据一致性，RocketMQ 事务消息处理"业务变更 + 发消息"的原子性（如订单创建后发消息），二者结合实现最终一致。典型场景：Seata 保证库表一致，事务消息保证事件可靠投递，后续流程消费消息异步处理。RocketMQ 事务消息：发半消息 → 本地事务 → commit/rollback，配合回查。Seata 与事务消息可独立或组合：数据一致性用 Seata，事件可靠投递用事务消息。工程上：根据"是否需要跨服务强一致"选 Seata，根据"是否需要可靠事件"选事务消息，组合实现最终一致。

协作是"Seata 管数据一致性 + 事务消息管事件可靠投递"。二者互补，分别解决数据与事件的一致性。组合实现最终一致。

• Seata vs 本地消息表
• Seata vs 事务消息
• 一致性/性能/侵入性

Seata 与本地消息表、事务消息的选型对比：一致性——Seata 提供强一致（AT/XA）或最终一致（TCC/SAGA），本地消息表/事务消息提供最终一致；性能——Seata（AT 全局锁）性能略低，本地消息表/事务消息异步、性能高；侵入性——Seata AT 低侵入（注解），但需 undo_log 表与 TC；本地消息表需业务维护消息表与投递逻辑（侵入中等），事务消息需业务实现回查接口。选型：需要强一致或跨服务事务选 Seata；能接受最终一致、性能优先、事务简单选本地消息表/事务消息。本地消息表/事务消息适合"异步解耦 + 最终一致"，Seata 适合"需要事务语义"。工程上：按一致性需求、性能、侵入性权衡。

对比维度是"一致性、性能、侵入性"。Seata 强一致/侵入可控，本地消息表/事务消息最终一致/性能高/实现简单。按需选择。

• Seata 与 Spring Boot 4 兼容
• 版本对齐
• 集成注意事项

Seata 在 Spring Boot 4.x 的兼容性取决于 Seata 版本与 Spring Cloud Alibaba 的对齐。Seata 通过 seata-spring-boot-starter 与 Spring Boot 集成，Boot 4.x 需对应支持 Boot 4 的 Seata 版本（2.x+）。兼容性关注：@GlobalTransactional 的 AOP 实现与 Spring Boot 4 的 AOP/自动配置兼容；Seata 对 Jakarta EE 11、虚拟线程的适配；Seata 客户端（TC 注册、数据源代理）与 Boot 4 的兼容。集成注意事项：数据源代理（DataSourceProxy）与 Boot 4 的自动配置、seata.registry/seata.config 配置、@GlobalTransactional 扫描。升级需查兼容矩阵，验证 AT/TCC/SAGA 在 Boot 4 下正常工作。

兼容性由 Seata 版本决定。Boot 4 的 AOP 与自动配置变化需适配。升级验证全局事务功能。

• AT 与 TCC 混合
• 使用场景
• 策略

Seata 的 AT 与 TCC 可在同一业务中混合使用：AT 模式适合"低侵入、自动回滚"的分支（常规数据操作），TCC 模式适合"需要资源预扣、性能要求高"的分支（库存、账户、外部资源）。混合策略：同一全局事务内，不同分支用不同模式——数据操作简单用 AT（自动 undo_log），资源型/预扣型用 TCC（手动 Try/Confirm/Cancel）。Seata 的 XID 在全局事务内共享，各分支模式独立。混合使用需注意：各分支模式一致性与补偿协调；TCC 分支的 Cancel 需与 AT 分支的回滚协同时序。工程上：按分支业务特点选择 AT/TCC，混合使用兼顾低侵入与资源控制。

混合策略是"按分支业务特点选择模式"。AT 低侵入、TCC 资源控制。XID 共享，各分支独立模式。混合兼顾需求。

• 四种模式原理
• 一致性/侵入性/性能
• 工程取舍

Seata 四种模式取舍：AT（Auto Transaction）——自动记录 undo_log 回滚，低侵入，用全局锁，适合大多数常规场景，性能中等；TCC——手动 Try/Confirm/Cancel，高侵入、高性能、资源预扣，适合预扣型业务；SAGA——长事务拆分 + 补偿，适合长流程、跨服务编排，无隔离性；XA——基于数据库 XA 协议，强一致、两阶段，但依赖数据库支持、性能差、锁持有到全局结束。工程取舍：一致性（XA/AT 强，TCC/SAGA 最终）、侵入性（AT/XA 低、TCC 高、SAGA 中）、性能（TCC 高、AT 中、XA 低）。选型：常规短事务用 AT，高性能预扣用 TCC，长事务用 SAGA，强一致且 DB 支持用 XA。核心是"一致性、侵入性、性能"权衡。

四种模式是"一致性强度 × 侵入性 × 性能"的权衡矩阵。AT 通用、TCC 高性能、SAGA 长事务、XA 强一致。按业务选择。

• Saga 状态机 JSON
• StateMachineEngine
• 集成

Seata SAGA 用 JSON 定义状态机：JSON 描述状态（state）、每个状态的动作（正向 Service）与补偿（补偿 Service）、状态转移（条件/异常）。示例：状态机定义 start → 各 state（调用服务）→ 每个 state 有 CompensateState（补偿）。集成：Spring Boot 中通过 SagaStateMachineEngine（StateMachineEngine）执行状态机——stateMachineEngine.start(状态机名称, 输入参数) 启动，内部按 JSON 驱动步骤执行与补偿。集成配置：seata.server.enable 与状态机引擎 Bean，@EnableSaga（如需）。工程上：用 JSON 定义状态机（可维护、可视化），StateMachineEngine 执行，实现 SAGA 编排与补偿。

SAGA 状态机 JSON 定义"步骤 + 补偿 + 转移"，StateMachineEngine 执行。JSON 化提升可维护性，引擎驱动补偿。

• undo_log 快照
• 补偿机制
• 快照读

Seata AT 模式下 undo_log 记录数据变更的 before image（变更前快照）与 after image（变更后快照）。补偿机制：回滚时，根据 undo_log 的 before image 生成反向 SQL，把数据恢复到变更前状态。快照读：AT 模式读操作默认读已提交数据（读未锁），结合全局锁与 undo_log 保证一致性；分支事务提交时，undo_log 保留到全局事务结束（提交后删除，回滚时用 before image 恢复）。实现：拦截 SQL 记录前后镜像 → 提交本地事务 → 全局提交删除 undo_log / 全局回滚用 before image 恢复。快照读与补偿都依赖 undo_log 的镜像数据。工程上：undo_log 表是 AT 模式必需，快照与补偿依赖它。

undo_log 是 AT 模式的"回滚数据源"。before image 用于补偿（恢复），after image 用于校验（防止并发覆盖）。快照读与补偿基于镜像。

• 各模式适用边界
• 场景选择
• 边界

Seata 四种模式适用边界：AT——适用于大多数常规分布式事务（短事务、数据一致、低侵入），数据库需支持 undo_log；TCC——适用于资源可预扣、需要高性能与强隔离的业务（库存、账户、积分），需手动实现三阶段；SAGA——适用于长事务、跨服务编排、能接受最终一致与无隔离性的业务（订单流程、异步流程）；XA——适用于需要强一致、数据库支持 XA 协议、事务量小的场景，但性能差。边界划分：按"事务时长、一致性强度、业务侵入性、性能、数据库能力"选择。短事务常规选 AT，预扣型选 TCC，长事务选 SAGA，强一致选 XA。工程上：明确各模式边界，避免误用。

适用边界由"时长、一致性、侵入、性能、DB 能力"决定。AT 通用、TCC 预扣、SAGA 长事务、XA 强一致。按边界选型。

• tx-service-group
• 集群与高可用
• 配置

Seata 的事务分组（tx-service-group）是客户端逻辑分组：客户端通过 tx-service-group 标识自己所属的事务分组，Seata 通过该分组映射到具体的 TC 集群（通过 registry 配置）。seata.tx-service-group 客户端配置，service.vgroupMapping 把分组映射到 TC 集群名，TC 集群通过 registry（Nacos）发现。集群：TC 可部署集群（多节点）保证高可用，客户端通过 registry 发现 TC 节点，故障时切换。配置：tx-service-group（客户端逻辑分组）、vgroupMapping（分组→集群）、registry（TC 注册发现）。工程上：分组用于逻辑隔离，集群保证高可用，映射关系配置正确。

tx-service-group 是"客户端到 TC 的映射"。分组映射到集群，集群高可用。理解分组与注册发现的配置。

• 多集群 Mesh
• 跨集群服务
• 配置与网格

Service Mesh 的多集群（Multi-Cluster）指把多个 Kubernetes 集群纳入同一个服务网格（Mesh），实现跨集群的服务发现、流量路由、安全与可观测。多集群场景：主从式（一个主集群控制面，其他从集群）、多主（多集群各自控制面互连）。跨集群服务：一个集群的服务可调用另一集群的服务，通过 Mesh 统一路由（负载均衡、故障转移）。多集群价值：跨地域容灾、弹性（跨集群扩缩容）、隔离与合规。Istio 支持多集群（多主/主从），通过控制面互联 + 跨集群服务发现。工程上：多集群 Mesh 提供跨集群治理，但需处理网络、证书、配置同步。

多集群是"跨集群统一 Mesh"。提供跨集群服务发现与路由。用于容灾、弹性、隔离。需处理网络与控制面互联。

• @GlobalTransactional 注解
• Spring AOP 拦截
• 实现

Seata 2.x 的 @GlobalTransactional 通过 Spring AOP 实现：GlobalTransactionScanner 扫描 @GlobalTransactional 标注的方法，创建 GlobalTransactionalInterceptor（AOP 切面），拦截方法执行。拦截逻辑：方法执行前开启全局事务（GlobalTransaction.begin() 获取 XID），执行后提交/回滚，异常时回滚。AOP 顺序：@GlobalTransactional 拦截器需在 @Transactional 本地事务拦截器外层（先全局后本地），保证全局事务上下文正确。Spring Boot 3.5+ 中，AOP 基于 AspectJ 注解（@Aspect），Seata 的 interceptor 注册为 Bean，配置 @GlobalTransactional 生效。实现：GlobalTransactionInterceptor.invoke() 包裹方法，管理全局事务生命周期。

@GlobalTransactional 靠 AOP 拦截器实现。拦截方法开启/提交/回滚全局事务。AOP 顺序（全局外、本地内）是关键。

• JWT 签名校验
• claims 校验
• opaque token introspection

Spring Security 资源服务器校验 JWT：配置 JwtDecoder 用授权服务器的公钥校验 JWT 签名（RS256/ES256），验证 iss、aud、exp 等 claims（签发者、受众、过期）。签名校验保证 token 未被篡改，claims 校验保证 token 有效。opaque token 的 introspection 模式：资源服务器不本地校验 token，而是调用授权服务器的 /oauth2/introspect 端点（userinfo/introspection）换取 token 的元数据（scope、claims）。代价：每次请求都需调用授权服务器 introspection（网络开销、延迟、依赖授权服务器可用性），无法本地校验（无签名），比 JWT 慢且依赖外部服务。选型：JWT 本地校验（无状态、快）适合高频；opaque introspection（服务端撤销即时）适合需实时撤销的场景。工程上：JWT 验签本地校验高效，opaque introspection 需权衡网络依赖。

JWT 本地验签（无状态、快），opaque introspection 依赖授权服务器（可撤销、慢）。权衡无状态高效 vs 即时撤销。

• OAuth2/OIDC + JWT 认证链路
• 网关统一鉴权 vs 服务内鉴权
• 取舍

OAuth2/OIDC + JWT 认证链路：客户端通过授权服务器（Authorization Server）获取 JWT（access token），携带 JWT 调用微服务；网关/服务校验 JWT 签名与 claims，获取用户身份。网关统一鉴权 vs 服务内各自鉴权：网关统一鉴权——网关校验 JWT、做认证，服务内信任网关（透传身份），优点：集中、统一、减少重复代码；缺点：网关是单点、服务内无法独立做细粒度鉴权（需信任网关）。服务内各自鉴权——每个服务自己校验 JWT（资源服务器），优点：安全边界分散、可独立校验；缺点：重复代码、每个服务都需配置。取舍：常见做法是网关做认证（校验 token、透传身份），服务内做授权（按角色/权限校验，可独立评估），兼顾统一与安全。工程上：网关统一认证 + 服务内授权（细粒度），权衡单点与安全。

认证（网关统一）+ 授权（服务内）分工是常见架构。网关认证去重，服务内授权保安全。权衡网关单点与权限粒度。

• 密钥管理（Vault/KMS）
• 静态加密 vs 动态凭据
• 轮换机制

微服务密钥与凭据管理：用 Vault/KMS 集中管理密钥与凭据，应用不硬编码密钥，通过 Vault/KMS 获取。静态加密：配置/存储中的敏感数据加密（配置加密、数据库加密），用于"静态数据"保护。动态凭据：Vault 可动态生成短期凭据（如数据库密码、云凭证），用后即失效（短期有效），降低凭据泄露风险。轮换机制：密钥/凭据定期轮换（Vault 的 rotation），轮换时保证新旧并存过渡，不中断业务。配合：静态加密保护存量数据，动态凭据保护短期访问，轮换保证长期安全。工程上：Vault/KMS 集中管理，静态加密 + 动态凭据 + 轮换配合，实现凭据全生命周期安全。

密钥管理是"集中 + 分层"。静态加密、动态凭据、轮换分别保护存量、短期、长期安全。配合实现完整生命周期。

• mTLS
• 客户端凭证 JWT
• SPIFFE/SPIRE

服务间身份认证方案：mTLS——双向 TLS，服务间用证书互相验证身份，加密通信，适合强安全、零信任；客户端凭证 JWT——服务用 client credentials 获取 JWT 访问其他服务，适合与 OAuth2 体系集成、有授权服务器；SPIFFE/SPIRE——SPIFFE 定义服务身份（SPIFFE ID），SPIRE 是签发/验证 SPIFFE 身份的实现（基于 mTLS 证书），适合云原生、Service Mesh（Istio 集成）。适用边界：mTLS 通用强安全（网格/零信任）；客户端凭证 JWT 与 OAuth2/授权体系结合；SPIFFE/SPIRE 提供标准化的服务身份（云原生、多集群）。选型：需要标准化服务身份选 SPIFFE/SPIRE，强安全加密选 mTLS，与 OAuth2 集成选客户端凭证 JWT。工程上：按安全需求与生态选择。

三种方案是"证书、JWT、标准身份"。mTLS 证书强安全、JWT 契合 OAuth、SPIFFE 标准化身份。按场景选择。

• RBAC/ABAC
• PDP 与 PEP 分离
• 分层协同

RBAC（基于角色）/ABAC（基于属性）权限模型在微服务中协同：网关——做粗粒度认证与路由（是否允许访问服务）；服务——做细粒度授权（角色/权限校验）；数据层——做数据级权限（行级/字段级过滤）。PDP 与 PEP 分离：PDP（Policy Decision Point，决策点）——集中评估权限策略（决定是否有权），PEP（Policy Enforcement Point，执行点）——在请求处执行决策（拦截请求、执行 PDP 决策）。分离：PEP 分布在各服务/网关（拦截请求），PDP 集中（如内置策略引擎或外部 PDP 服务），权限策略集中管理，执行分散。好处：策略统一（PDP 易更新）、执行一致。工程上：PEP 拦截 + PDP 决策，策略集中动态化。

RBAC/ABAC 分层授权（网关/服务/数据），PDP/PEP 分离（决策集中、执行分散）。策略统一管理、执行一致。

• 零信任原则
• 内网流量风险
• 逐请求鉴权

零信任（Zero Trust）架构：不信任任何来源（包括内网），每个请求都需验证身份与授权。落地：服务间 mTLS（加密 + 身份验证）、逐请求鉴权（PDP/PEP 分离）、最小权限、微分段（限制网络访问）、持续监控。为什么不能默认信任内网：内网流量可能是被攻破的横向移动、被注入的恶意服务、或内网攻击者，内网不等于安全边界（传统"内网可信"假设已失效）。因此需逐请求鉴权：每个请求都验证调用方身份（mTLS/SPIFFE）与权限，而非信任网络位置。工程上：零信任 = 逐请求鉴权 + mTLS + 最小权限 + 微分段，不信任内网。

零信任核心是"不信任内网、逐请求鉴权"。内网可能被攻破，网络位置不可信任。mTLS + 逐请求鉴权 + 最小权限落地。

• xDS 协议
• 配置下发
• 控制面与数据面

Envoy 的 xDS 协议是控制面（Control Plane）向数据面（Envoy 代理）下发配置的接口协议，xDS 是"x Discovery Service"的集合，包括：CDS（Cluster 发现）、EDS（Endpoint 发现）、LDS（Listener 发现）、RDS（Route 发现）等。工作原理：控制面（如 Istiod）通过 gRPC 流式下发配置到 Envoy，Envoy 监听服务发现、路由、监听器变化并动态更新，无需重启。xDS 是 Service Mesh 的"控制面-数据面"标准化接口，Istio 的 Istiod 通过 xDS 下发 VirtualService/DestinationRule 等配置。工程上：xDS 让数据面动态配置，实现服务发现、路由、负载均衡的实时更新。

xDS 是"控制面 → 数据面"的配置下发协议。CDS/EDS/LDS/RDS 覆盖集群、端点、监听、路由。动态更新数据面。

• WebSocket 代理
• Upgrade 协议
• 长连接管理

Gateway 代理 WebSocket：通过 WebsocketRoutingFilter 处理 WebSocket 升级（Upgrade 协议），支持 ws:// 路由。配置：spring.cloud.gateway.httpclient.websocket-max-frame-size（帧大小）、websocket-max-frame-size、websocket 超时。长连接管理：WebSocket 是长连接，需配置读超时（ReadTimeout）、空闲超时、心跳（ping/pong）、连接数限制。WebSocket 代理需处理协议升级（HTTP → WebSocket）、双向消息转发、连接生命周期。工程上：配置 Upgrade 路由 + 帧大小 + 超时 + 心跳，管理长连接。注意代理与后端连接池、超时协调。

WebSocket 代理是"协议升级 + 双向长连接"。配置帧大小、超时、心跳管理连接。长连接需超时与心跳保活。

• GlobalFilter
• 统一鉴权
• 灰度路由

Gateway 的 GlobalFilter 对所有请求生效，适合实现统一鉴权与灰度路由。统一鉴权：实现 GlobalFilter，在 filter() 中校验请求（JWT、Header、Token），未通过则返回 401/403，通过则继续（透传身份）。灰度路由：基于 Header——GlobalFilter 读取请求头（x-version）决定路由到哪个版本；基于权重——按权重把请求路由到不同版本实例（结合 Nacos 元数据 + LoadBalancer）。实现：GlobalFilter 中设置路由属性（GATEWAY_REQUEST_URL_ATTR）或结合负载均衡规则。GlobalFilter 的 order 控制执行顺序（鉴权在前）。工程上：GlobalFilter 统一鉴权 + 灰度路由（Header/权重），横切治理。

GlobalFilter 是"全局横切"点。统一鉴权 + 灰度路由都在其中。order 控制顺序，Header/权重决定灰度路由。

• 灰度流量切分
• Header/Cookie/权重
• 版本路由

Gateway 灰度发布通过流量切分与版本路由实现：Header——按请求头（x-version=v2）路由到指定版本；Cookie——按 Cookie 标识（如灰度用户）路由；权重——按权重比例把流量切分到新旧版本（如 10% 新版本）。实现：路由过滤器或 GlobalFilter 判断 Header/Cookie 决定路由目标；权重用 Weight 路由谓词或 LoadBalancer 权重。版本路由：结合 Nacos 实例元数据（version），把灰度流量路由到对应版本实例。工程上：Header/Cookie 精准灰度（指定用户）、权重比例灰度（按量），配合元数据路由与回滚。

灰度是"流量切分 + 版本路由"。Header/Cookie 精准、权重按量。结合元数据路由实现版本灰度。

• GatewayFilterFactory
• OrderedGatewayFilter
• 顺序控制

Gateway 的自定义过滤器工厂（GatewayFilterFactory）：实现 GatewayFilterFactory 创建自定义过滤器，通过配置（- name: CustomFilter）在路由中应用。OrderedGatewayFilter：包装过滤器并指定顺序（order），控制过滤器在链中的执行顺序（order 越小越先执行）。自定义过滤器工厂用于定义可配置的过滤逻辑（如签名、改写），OrderedGatewayFilter 控制其在过滤器链中的位置。顺序控制重要：过滤器执行顺序影响逻辑（如鉴权过滤器的顺序、灰度过滤器的顺序）。工程上：自定义工厂 + Ordered 控制顺序，管理过滤器链。

GatewayFilterFactory 创建过滤器，OrderedGatewayFilter 控制顺序。顺序决定过滤器链的执行逻辑。自定义 + 顺序管理。

• Gateway CORS
• Spring Security CORS
• 冲突解决

Gateway 与 Spring Security 都配置 CORS 时可能冲突（重复 CORS 头、配置覆盖）。解决：统一在一处配置 CORS——若 Gateway 处理跨域，则在 Gateway 的全局 CORS 配置（spring.cloud.gateway.globalcors）设置，Spring Security 禁用/简化 CORS（不重复处理）；若服务内处理，则 Gateway 不配 CORS。冲突原因：两处都添加 CORS 头会导致重复或顺序问题。优先原则：跨域由网关统一处理（入口），服务内不重复配置；或明确分层（Gateway 处理预检、服务处理业务）。工程上：统一 CORS 配置位置，避免重复与冲突。

冲突源于"多处配置 CORS"。统一一处（网关优先）+ 服务内不重复，避免重复头与覆盖。明确分层。

• Istio（Service Mesh）vs Spring Cloud
• 能力对比
• 选型

Istio（Service Mesh）与 Spring Cloud 的取舍：Istio——把网络治理（负载均衡、熔断、重试、mTLS、可观测性）下沉到数据面（Envoy），业务代码无感，语言无关（多语言），支持零信任；Spring Cloud——在应用内通过框架实现治理（LoadBalancer、OpenFeign、Sentinel、链路），代码侵入、Java 专属。取舍：Istio 适合多语言、需要平台化治理、减少框架侵入、云原生（K8s）场景；Spring Cloud 适合 Java 团队、已有 Spring 生态、需要深度代码集成（如配置、事务）的场景。Istio 剥离框架能力但引入代理开销，Spring Cloud 侵入但灵活。工程上：Istio 平台化 vs Spring Cloud 框架化，按团队与云原生程度选择。

取舍是"平台化 Mesh vs 框架内治理"。Istio 无侵入但代理开销，Spring Cloud 侵入但 Java 生态。按云原生与多语言需求选。

• Ambient Mesh
• 无 Sidecar 数据面
• 演进

Istio 的 Ambient Mesh 是"无 Sidecar"的数据面模式演进：传统 Sidecar 模式每个 Pod 注入一个 Envoy 代理（开销大、资源占用高），Ambient Mesh 用"节点级/可用区级"的 ztunnel（零信任隧道）代理 + 可选的 waypoint 代理，替代每个 Pod 一个 Sidecar。演进：减少代理数量与资源开销（Ambient 数据面更轻量）、降低部署复杂度（无需注入 Sidecar）、按需启用 L7 治理（waypoint）。Ambient 保留 Mesh 的 mTLS、安全（L4 默认）、可观测性，L7 治理通过 waypoint 按需启用。价值：更轻量、更易运维、适合大规模与资源敏感场景。工程上：Ambient 降低代理开销，按需启用 L7，是 Sidecar 的演进。

Ambient 是"无 Sidecar 的轻量数据面"。ztunnel 处理 L4 安全，waypoint 按需 L7。减少资源开销，提升可运维性。

• Telemetry V2
• 可观测性
• 指标采集

Istio 的 Telemetry V2 是新一代可观测性（遥测）实现：数据面（Envoy）生成标准指标（HTTP/gRPC 请求、延迟、错误、流量），通过 Prometheus 暴露，控制面统一管理。Telemetry V2 提供：标准指标（RED：请求速率、错误、延迟）、分布式追踪（与 Jaeger/OTel 集成）、访问日志。可观测性：Istio 自动埋点（无需应用代码），采集服务间流量指标，Monitor 服务健康。与旧版（Telemetry V1，mixer 架构）相比，V2 去掉了 mixer 组件，指标直接由 Envoy 生成、Prometheus 拉取，更轻量。工程上：Telemetry V2 提供标准服务指标，Prometheus/Grafana 展示，Kiali 可视化。

Telemetry V2 是"去掉 mixer 的轻量遥测"。Envoy 生成标准指标，Prometheus 采集。提供服务可观测性。

• mTLS
• AuthorizationPolicy
• 安全

Istio 安全：mTLS——服务间双向 TLS，默认自动注入，加密通信并验证身份（基于 SPIFFE ID），实现零信任；AuthorizationPolicy——授权策略，定义"谁可以访问什么服务/端口"，支持 ALLOW/DENY 规则（匹配来源、请求属性、方法）。mTLS 保证身份验证与加密，AuthorizationPolicy 保证授权控制。安全模型：mTLS 验证身份（服务间互信），AuthorizationPolicy 控制访问权限（按来源/方法）。Service Mesh 的 mTLS 自动管理证书（Istiod 签发），无需应用代码。工程上：mTLS 加密 + 身份，AuthorizationPolicy 授权，实现零信任。

mTLS 管"身份与加密"，AuthorizationPolicy 管"授权"。mTLS 自动证书，AuthorizationPolicy 按来源/请求授权。零信任基础。

• Istiod
• Envoy
• Pilot

Istio 核心组件：Istiod——统一控制面，整合了 Pilot（服务发现与配置）、Citadel（证书签发）、Galley（配置校验）、Mixer（策略，V2 已去），通过 xDS 下发配置到 Envoy；Envoy——数据面代理（Sidecar），负责流量处理（负载均衡、路由、TLS、可观测性）、执行 xDS 配置；Pilot——（Istiod 内）负责服务发现与流量管理配置，把 K8s 服务/Ingress 转换为 xDS 下发。架构：Istiod（控制面）通过 xDS 管理所有 Envoy（数据面）。工程上：Istiod 集中控制，Envoy 分散执行，xDS 连接。

Istiod 是统一控制面（合并 Pilot/Citadel/Galley），Envoy 是数据面代理。xDS 下发配置。控制面集中、数据面分散。

• VirtualService
• DestinationRule
• 流量管理

Istio 流量管理核心：VirtualService——定义流量路由规则（把请求路由到目标服务的子集，按 Header/权重/路径），支持灰度、分流、故障注入；DestinationRule——定义目标服务的策略（负载均衡、连接池、TLS、子集划分），与 VirtualService 配合（VirtualService 指路由到哪个子集，DestinationRule 定义子集与策略）。流量管理：VirtualService 控制"流量去哪"，DestinationRule 控制"如何访问目标"（负载均衡、TLS、子集）。二者配合实现灰度、分流、熔断、超时。工程上：VirtualService 路由 + DestinationRule 策略，实现精细流量管理。

VirtualService 管"路由"，DestinationRule 管"目标策略"。二者配合实现灰度、负载均衡、TLS。流量管理核心。

• Linkerd 轻量
• 与 Istio 差异
• 特点

Linkerd 的轻量化：数据面用 Rust 实现的微代理（linkerd-proxy），占用资源低、性能好；控制面轻量（无 Envoy 依赖）。差异化：Linkerd 更简单、更轻量、默认安全（mTLS 自动）、性能好（低开销），聚焦"简单、可观测、安全"；相比 Istio 功能丰富但复杂，Linkerd 牺牲部分功能（如部分 L7 高级治理）换取简单与性能。Linkerd 特点：自动 mTLS（无需配置）、零配置的 Pod 间加密、Rust 代理低开销、K8s 原生简化。适用：对性能与简单性要求高、不需要复杂 L7 治理的场景。工程上：Linkerd 轻量简单，Istio 功能全，按复杂度与性能选择。

Linkerd 差异化是"轻量 + 简单 + 默认安全"。Rust 代理低开销、mTLS 自动。与 Istio 的复杂丰富对比。

• TC 职责
• 事务协调
• 全局事务管理

Seata TC（Transaction Coordinator，事务协调器）是 Seata 的独立部署组件，负责全局事务的协调：创建全局事务（生成 XID）、管理分支事务注册、协调全局提交/回滚（二阶段）、维护全局锁与事务状态。TC 是 Seata 的"控制面"，TM（事务管理器）发起全局事务（发给 TC），RM（资源管理器）注册分支事务（发给 TC），TC 协调二者。TC 职责：全局事务生命周期管理、分支事务协调、全局锁维护、事务状态持久化（Session Manager）。TC 高可用：TC 可集群部署，通过 registry 注册，客户端发现 TC。工程上：TC 是分布式事务中枢，需部署与高可用。

TC 是"事务协调中枢"。创建/协调/提交/回滚全局事务，维护锁与状态。TM/RM 与 TC 交互（XID 贯穿）。

• XA 模式
• 数据库 XA 协议
• 两阶段

Seata XA 模式基于数据库 XA 协议实现强一致分布式事务：XA 是数据库的标准两阶段提交协议（准备/提交/回滚），Seata XA 模式利用数据库的 XA 能力。流程：TM 发起全局事务 → 各分支数据源执行 XA prepare（准备）→ 全局提交时各分支 XA commit，回滚时 XA rollback。特点：强一致（数据库保证原子性）、无侵入（不用改业务代码，用 @GlobalTransactional + XA 数据源）、但依赖数据库支持 XA（MySQL、Oracle）且性能差（锁持有到全局结束）。Seata XA 适合需要强一致、数据库支持 XA、事务量小的场景。工程上：XA 模式强一致但性能与数据库支持受限。

XA 是"数据库两阶段提交"。Seata XA 利用数据库 XA 能力，强一致但性能差、依赖 DB。与 AT（undo_log）对比。

• Seata 职责
• Resilience4j 职责
• 边界

Seata 与 Resilience4j 的边界：Seata 负责分布式事务（跨服务数据一致性，AT/TCC/SAGA/XA），保证"多个服务的数据要么都提交要么都回滚"；Resilience4j 负责容错（熔断、重试、限流、舱壁），保证"服务调用失败时优雅降级"。边界：Seata 管"数据一致性"（事务），Resilience4j 管"调用容错"（故障防护）。二者可协作：Seata 保证事务一致性，Resilience4j 在调用失败时重试/熔断（配合事务幂等）。不冲突：Seata 解决"中途失败如何回滚"，Resilience4j 解决"失败如何重试/降级"。工程上：明确边界（事务 vs 容错），组合使用。

边界是"事务一致性 vs 调用容错"。Seata 管数据一致，Resilience4j 管故障容错。可组合（重试需配合事务幂等）。

• GlobalTransactionScanner
• @GlobalTransactional
• 扫描与拦截

Seata 的 GlobalTransactionScanner 负责扫描应用中的 @GlobalTransactional 注解，并为标注的方法创建 AOP 代理（GlobalTransactionalInterceptor）。@GlobalTransactional 标注在方法上，表示该方法开启全局事务。GlobalTransactionScanner 扫描范围：@GlobalTransactional 标注的方法（根据 @EnableGlobalTransaction 或配置的扫描路径）。拦截逻辑：GlobalTransactionalInterceptor 拦截方法，开启全局事务（生成 XID）、执行、提交/回滚。工程上：@GlobalTransactional 声明，GlobalTransactionScanner 扫描并拦截，实现全局事务。

GlobalTransactionScanner 是"扫描器"，@GlobalTransactional 是"声明"。扫描器创建 AOP 拦截，注解声明事务边界。二者配合。

• LockConflict
• 重试机制
• 锁冲突处理

Seata 的 LockConflictException（锁冲突）发生在分支事务申请全局锁时，锁已被其他全局事务占用。处理：Seata 默认对锁冲突进行重试（client.rm.lock.retry-times 与 client.rm.lock.retry-interval），重试获取锁，超过重试次数则失败。锁冲突场景：多个全局事务并发修改同一数据，后到的事务等待锁。重试机制：配置重试次数与间隔，避免立即失败（短暂冲突可重试），也避免无限等待。工程上：锁冲突重试缓解并发冲突，配置合理重试参数，同时优化事务粒度减少锁冲突。

LockConflict 是"全局锁被占用"。重试缓解短暂冲突，超时失败。配置重试参数 + 优化事务粒度。

• LockStore
• SessionManager
• 状态持久化

Seata 的 LockStore（锁存储）与 SessionManager（会话管理器）是 TC 端管理全局锁与事务会话的组件：LockStore——存储全局锁（记录资源/行锁的持有者），支持锁的申请、释放、查询；SessionManager——管理全局事务会话（GlobalSession）与分支会话（BranchSession），记录事务状态、分支、undo_log 关联，支持事务状态持久化（提交/回滚/超时）。TC 端通过 SessionManager 持久化事务状态（数据库/内存），故障恢复时依据会话恢复事务。工程上：LockStore 管锁，SessionManager 管会话状态，支撑 TC 的协调与恢复。

LockStore 管锁、SessionManager 管会话状态。TC 依赖二者持久化事务状态，支持故障恢复与协调。

• Seata SPI
• 扩展点
• 定制

Seata 基于 SPI（Service Provider Interface）提供扩展点，允许自定义实现。主要扩展点：注册中心（RegistryProvider，实现 Nacos/Eureka/Consul 等）、配置中心（ConfigProvider）、序列化（Serializer）、事务管理器（TransactionManager，TM）、分支事务处理器（BranchTransactionHandler）、存储（Store，LockStore/SessionStore 实现）、数据源（DataSource 代理）。通过 SPI 机制（META-INF/services 或 @SPI）加载自定义实现。定制场景：自定义注册中心、自定义序列化、自定义存储（接入分布式存储）、自定义事务钩子。工程上：Seata SPI 提供可扩展性，按需定制。

Seata SPI 覆盖注册、配置、序列化、存储、事务处理等扩展点。通过 SPI 机制定制，增强可扩展性。

• Seata 配置
• Configuration 抽象
• 配置中心

Seata 的 Configuration 是配置抽象，统一管理 Seata 配置（seata.*），支持从配置中心（Nacos/Consul/Etcd）或本地文件读取。SeataConfig（Configuration 实现）提供配置读取 API（getConfig、getIntConfig 等），按 key 获取配置。Seata 配置可通过配置中心动态加载（如 Nacos 存 Seata 配置），支持 seata.config.type 指定配置中心。Configuration 抽象让 Seata 配置可插入不同配置源。工程上：Seata 配置通过 Configuration 抽象管理，可接配置中心实现动态配置。

Configuration 是 Seata 的配置抽象，可从配置中心/本地读取。SeataConfig 实现。支持动态配置接入。

• TC/TM/RM 角色
• 三阶段协作
• 工程价值

Seata 三个核心组件：TC（事务协调器）——集中协调全局事务，管理状态与锁；TM（事务管理器）——发起全局事务（begin/commit/rollback），定义事务边界；RM（资源管理器）——管理分支事务（注册/上报/提交/回滚），代理数据源。三阶段协作：TM 发起全局事务（向 TC 获取 XID）→ XID 贯穿调用链 → 各分支 RM 注册分支事务（向 TC）→ 全局提交/回滚时 TC 协调各 RM 提交/回滚。工程价值：TC 集中协调（状态集中、可恢复）、TM 定义边界（业务无感）、RM 资源管理（数据源代理、undo_log/XA）。三者解耦分工，实现可扩展的分布式事务。

TC/TM/RM 是"协调、边界、资源"三分。XID 贯穿三阶段，TC 集中协调。工程价值是解耦与可扩展。

• undo_log 字段
• 快照存储
• 表结构

Seata 的 undo_log 表用于 AT 模式存储回滚日志，表结构字段：branch_id（分支事务 ID）、xid（全局事务 ID）、context（上下文，含序列化信息）、rollback_info（回滚信息，before/after image 的序列化数据）、log_status（日志状态，0 正常 1 已提交）、log_created、log_modified（时间戳）。作用：rollback_info 存 before/after image 用于回滚；branch_id/xid 关联分支与全局事务；log_status 标记已删除/已提交。每次分支事务执行时插入 undo_log，全局提交后删除，回滚时用 rollback_info 恢复。工程上：undo_log 表是 AT 模式必需，需建表并维护索引。

undo_log 存"分支/全局 ID + 前后镜像 + 状态"。rollback_info 是回滚数据，log_status 标记状态。表结构支撑 AT 回滚。

• registry.conf
• TC 集群注册
• 高可用

Seata 高可用：TC 集群部署多节点，通过注册中心（registry.conf 配置的 Nacos）注册，客户端从注册中心发现 TC，故障时切换。registry.conf 配置 registry.type=nacos、registry.nacos.serverAddr 等，TC 启动时注册到 Nacos，客户端（TM/RM）通过 Nacos 发现 TC 节点。高可用：TC 多节点 + 注册发现，TC 故障时客户端切换到其他节点；事务状态持久化（SessionManager 存 DB/内存）支持恢复。工程上：TC 集群 + Nacos 注册 + 状态持久化，实现高可用分布式事务。

高可用是"TC 集群 + 注册发现 + 状态持久化"。registry.conf 配置 Nacos 注册，客户端发现 TC。状态持久化支撑恢复。

• JWT 过期与刷新
• token 撤销
• 分布式撤销难点

JWT 过期与刷新：access token 短有效期（如 15 分钟），refresh token 长有效期（如 7 天，可轮换），access token 过期时用 refresh token 换取新 access token，避免频繁登录。token 撤销难点：JWT 无状态（服务端不存状态），无法立即撤销——需黑名单（把撤销的 JWT 加入黑名单，存 Redis，校验时查）或短有效期（缩短 token 有效期，撤销等过期）。分布式下难点：黑名单需分布式共享（Redis 单点/集群），短有效期牺牲体验（频繁刷新）；撤销需跨服务一致（所有服务校验同一黑名单）。工程上：access token 短效 + refresh token 轮换 + 黑名单（Redis）实现撤销，权衡安全性（短效）与体验（长效）。

JWT 无状态导致撤销难。黑名单（Redis 共享）或短有效期解决。分布式下黑名单需共享存储，撤销一致性是难点。

• Saga 状态机演进
• 可视化编排
• 补偿策略

Seata 2.x 的 Saga 状态机引擎演进：支持更完善的状态机定义（JSON DSL）、可视化编排（通过状态机 JSON 描述，可配合可视化工具编辑）、补偿策略（每个状态定义补偿，失败时按状态机反向补偿）。演进：状态机引擎更易用（DSL 化）、支持复杂流程（并行、条件、循环）、补偿策略可配置（合理补偿、补偿失败处理）。可视化编排：用 JSON/工具定义状态机，直观展示流程与补偿。补偿策略：定义补偿服务、补偿重试、补偿顺序。工程上：Saga 状态机演进提升编排能力与补偿可靠性。

Saga 演进是"DSL 化 + 可视化 + 完善补偿"。状态机 JSON 编排，补偿策略可配置。提升长事务编排能力。

• report.success.enable
• 分支上报
• 性能

Seata 的 client.rm.report.success.enable（默认 true）控制分支事务是否上报成功结果给 TC。配置为 true：分支事务提交/回滚成功后上报 TC（TC 明确知道分支状态）；false：分支事务不主动上报成功（TC 根据全局事务状态判断，或依赖超时/其他机制）。作用：上报成功让 TC 掌握分支状态，及时协调；关闭上报（false）可减少分支上报的 RPC 开销（性能优化），但 TC 需要其他方式确认分支状态（可能依赖超时）。工程上：默认 true 保证分支状态明确；性能敏感场景可权衡关闭，但需注意 TC 状态一致性。

report.success.enable 控制"分支成功是否上报"。true 明确状态、false 省开销。权衡状态明确性与性能。

• Mesh 与 Gateway 职责
• 边界划分
• 协同

Service Mesh 与 API Gateway 的边界：API Gateway——南北向流量入口（对外），负责路由、鉴权、限流、协议转换（面向外部客户端）；Service Mesh——东西向流量（服务间调用），负责服务间负载均衡、熔断、TLS、可观测性（面向内部服务）。边界：Gateway 管"外部到内部"，Mesh 管"内部到内部"。二者可协同：Gateway 作为入口（南向），Mesh 处理服务间（东向），Gateway 的流量进入 Mesh 后按 Mesh 治理。边界划分：Gateway 面向外部客户端（认证、聚合），Mesh 面向服务间（治理、安全）。工程上：Gateway 管南北向、Mesh 管东西向，职责清晰。

边界是"南北向 vs 东西向"。Gateway 对外入口，Mesh 服务间治理。二者协同，不重叠（如需重叠可合并）。

• Mesh 诊断
• Java 应用诊断
• 结合

Service Mesh 与 Java 应用诊断：Mesh 诊断——通过控制面（Istiod）状态、数据面（Envoy）日志、xDS 配置、Kiali 可视化、指标（服务间流量）诊断 Mesh 的流量/路由/安全问题；Java 应用诊断——通过 JVM 监控（GC、堆）、线程栈、Arthas、链路追踪（TraceID）诊断应用自身问题。结合：Mesh 观察"服务间流量与网络"，Java 诊断观察"应用内部"。当服务超时/失败时，先看 Mesh 流量（路由错误、负载均衡、mTLS）再看应用（JVM、慢 SQL、线程）。Mesh 的 TraceID 与 Java 应用日志关联，定位问题在网络层还是应用层。工程上：Mesh 管网络诊断，Java 管应用诊断，结合定位。

诊断分"网络层（Mesh）"与"应用层（Java）"。Mesh 看流量/路由/安全，Java 看 JVM/性能。结合 TraceID 定位。

• 共存
• 职责分配
• 策略

Service Mesh 与 Spring Cloud Gateway 共存策略：明确职责分配——Gateway 负责南北向（对外入口、鉴权、限流、聚合），Service Mesh 负责东西向（服务间路由、熔断、TLS、可观测性）。共存时避免重复治理：Gateway 之外的服务间调用由 Mesh 治理，不重复实现负载均衡/熔断（Mesh 已做）；Gateway 也可作为 Mesh 的入口（Gateway 流量进入 Mesh）。策略：Gateway 管入口（业务层），Mesh 管服务间（网络层），分层治理；避免两套都做同一件事（如都做熔断/重试）。工程上：Gateway 对外 + Mesh 对内，职责分层，避免重复治理。

共存是"分层职责"。Gateway 南北向、Mesh 东西向，避免重复治理。清晰分层实现协同。

• mTLS 开销
• 性能影响
• 优化

Service Mesh 的 mTLS 性能影响：加解密开销——每个请求都要 TLS 握手与加解密，CPU 开销与延迟增加；握手开销——首次连接 TLS 握手（密钥交换、证书验证）耗时，长连接复用减少握手；CPU 影响——加解密占用 CPU，吞吐下降。缓解：长连接复用（减少握手）、硬件加速（TLS 卸载）、会话复用（Session resumption）、合理证书（减少验证开销）。mTLS 性能影响通常可接受（现代硬件），但高吞吐场景需评估。工程上：mTLS 加密开销 + 握手开销，用长连接/会话复用/硬件加速缓解。

mTLS 影响是"加解密 + 握手"开销。长连接复用、会话复用、TLS 卸载缓解。权衡安全与性能。

• Kiali
• Jaeger
• Prometheus

Service Mesh 可观测性三件套：Kiali——服务拓扑可视化，展示服务间依赖、流量、健康状态；Jaeger——分布式追踪，展示请求跨服务的链路（跟踪延迟/错误）；Prometheus——指标采集与告警，采集服务间流量指标（RED）。三者结合：Prometheus 采指标（告警）、Kiali 可视化拓扑（服务关系）、Jaeger 追踪链路（定位瓶颈）。结合方式：Istio 生成指标（Prometheus 采集）、追踪（Jaeger 收集）、拓扑（Kiali 基于指标构建）。工程上：Prometheus 指标 + Kiali 拓扑 + Jaeger 追踪，构成 Mesh 可观测性。

可观测性三件套：Prometheus（指标）、Kiali（拓扑）、Jaeger（追踪）。三者互补，构成 Mesh 可观测性。

• Sidecar
• Data Plane
• Control Plane

Service Mesh 核心概念：Sidecar——与应用同部署的代理容器（Envoy），处理应用的进出流量（负载均衡、TLS、路由、可观测性），应用无感知；Data Plane（数据面）——所有 Sidecar 的集合，负责实际流量处理（转发、治理）；Control Plane（控制面）——管理数据面的组件（如 Istiod），负责配置下发（xDS）、服务发现、证书签发、策略管理。三者关系：控制面通过 xDS 管理数据面，数据面（Sidecar）处理流量，应用只感知 Sidecar（透明代理）。概念理解：Sidecar 是数据面的单元，Data Plane 是流量侧，Control Plane 是配置侧。

Sidecar 是代理单元，Data Plane 管流量，Control Plane 管配置。三者构成 Mesh 的"数据面 + 控制面"架构。

• Mesh 零信任
• mTLS 与授权
• 落地

Service Mesh 的零信任：不信任任何网络流量，通过 mTLS + 授权策略实现逐请求安全。Mesh 零信任落地：mTLS——服务间双向 TLS 验证身份（SPIFFE ID）+ 加密，默认自动；AuthorizationPolicy——授权控制（谁可访问），按来源/请求属性；微分段——网络层限制服务间访问。Mesh 零信任的价值：mTLS 自动化（证书管理由控制面）、逐请求鉴权（AuthorizationPolicy）、身份标准化（SPIFFE）。相比应用层零信任，Mesh 把 mTLS/授权下沉到平台，应用无感。工程上：Mesh 零信任 = mTLS 自动 + 授权策略 + 微分段，实现服务间安全。

Mesh 零信任是"平台下沉的零信任"。mTLS 自动验证身份 + AuthorizationPolicy 授权。无侵入实现服务间安全。

• RoutePredicateFactory
• 过滤器链顺序
• 执行

Spring Cloud Gateway 的路由谓词（RoutePredicateFactory）用于匹配路由条件（Path、Header、Method、Query、Weight 等），匹配成功则路由到目标。内置谓词工厂：Path、Header、Method、Query、Host、Weight、Cookie 等；自定义谓词可实现 RoutePredicateFactory。过滤器链执行顺序：GlobalFilter（全局）与 GatewayFilter（路由级）构成过滤器链，通过 Order（order() 或 @Order）控制执行顺序（order 越小越先执行）。执行顺序：路由匹配（谓词）→ 过滤器链（按 order）→ 转发。工程上：谓词匹配路由，过滤器链按 order 执行，自定义谓词/过滤器扩展。

谓词管"匹配"，过滤器链管"处理"。执行顺序按 order。理解谓词匹配与过滤器链顺序。

• 身份透传
• SecurityContext 传播
• 异步/Feign/WebClient

跨服务调用身份透传：把用户身份（JWT、用户信息）放入请求头（如 Authorization、X-User-Id），下游服务从请求头解析并恢复 SecurityContext。传输方案：Feign——用 RequestInterceptor 把当前 SecurityContext 的用户信息写入请求头；WebClient——用 WebClientCustomizer 或拦截器把身份写入请求头；异步——ThreadLocal 的 SecurityContext 在异步线程丢失，需用 SecurityContextHolder 的 DelegatingSecurityContextExecutor 或 TaskDecorator 在切换线程时传递 SecurityContext。传播方案：同步（Feign/WebClient 拦截器）、异步（TaskDecorator/上下文传递）、消息（消息头带身份）。工程上：请求头透传身份 + 拦截器注入 + 异步上下文传递，实现跨服务身份传播。

身份透传靠"请求头 + 拦截器 + 异步上下文传递"。SecurityContext 在异步/Feign/WebClient 各场景需显式传播，避免 ThreadLocal 丢失。