Docker部署Seata 2.x整合Spring Cloud与Nacos实战

分布式事务这件事说起来都是泪。单体应用拆成微服务之后原本一个本地事务能搞定的事情突然变成了跨服务、跨数据库、跨消息队列的难题。订单扣了库存没扣、库存扣了余额没扣这种数据不一致的场景在生产环境里一旦出现排查起来能把人逼疯。Seata 就是在这个背景下进入视野的——它把分布式事务的复杂度封装起来让业务代码尽量少感知。而 Seata 2.x 相比 1.x 在架构上做了不小的调整尤其是配置中心和注册中心的解耦做得更彻底。这篇内容围绕 Docker 部署 Seata 2.x、整合 Spring Cloud、用 Nacos 同时承担配置与注册中心这条主线展开把版本选型、镜像构建、配置推送、客户端接入、踩坑排查这些环节逐一拆开讲清楚。适合正在做微服务事务治理、准备从 1.x 升级到 2.x、或者第一次接触 Seata 的开发者参考不管你是刚上手还是已经踩过几轮坑下面这些细节应该都能对上你的实际场景。1. 整体方案设计与版本选型考量1.1 为什么选 Seata 2.x 而不是 1.xSeata 2.x 最核心的变化在于配置模型的调整。1.x 时代很多配置项散落在 registry.conf 和 file.conf 两个文件里注册中心和配置中心的配置混在一起改一个 Nacos 地址要动好几个地方。2.x 把配置体系重新梳理了一遍支持通过 application.yml 统一管理并且对 Nacos 配置中心的支持更加原生——配置项可以直接从 Nacos 拉取本地只需要保留最少的引导配置。这个变化看起来只是配置文件格式的调整实际影响的是部署和运维方式容器化部署时你可以把大部分配置推到 Nacos 里镜像本身保持通用不同环境用不同的 namespace 和 group 来隔离不用为每个环境单独构建镜像。另一个关键变化是 Seata 2.x 对 JDK 和 Spring Boot 版本的要求提高了。2.x 主线要求 JDK 8 以上推荐 11 或 17Spring Boot 建议 2.6 以上。如果你还在用 Spring Boot 2.3 以下的版本整合时会遇到自动配置类不兼容的问题这个后面排查章节会细说。选 2.x 的另一个理由是社区维护重心已经转移1.x 的很多问题在 2.x 里已经修复新项目没有理由再用旧版本。1.2 Nacos 同时做配置中心和注册中心的合理性把 Nacos 同时用作配置中心和注册中心在中小规模微服务团队里是很常见的做法。理由很直接少维护一套中间件少一个故障点。Seata Server 启动时需要知道两件事——自己的配置从哪来配置中心以及自己注册到哪去让客户端发现注册中心。Nacos 两件事都能干而且 Seata 2.x 对 Nacos 的支持是官方一等公民级别的配置项命名规范、心跳机制、命名空间隔离都做得比较完善。不过这里有个细节要注意配置中心和注册中心虽然都用 Nacos但建议用不同的 namespace 或者至少不同的 group 来隔离。配置数据放在配置中心的 namespace 下服务注册信息放在注册中心的 namespace 下避免运维时混淆。我在实际项目里见过把两者混在同一个 namespace 的情况后来排查一个注册异常问题时翻配置翻到眼花这个教训值得记一下。1.3 Docker 部署 Seata Server 的镜像策略Seata 官方在 Docker Hub 上提供了 seataio/seata-server 镜像但直接用官方镜像有个问题默认配置是 file 模式要改成 Nacos 模式需要挂载配置文件或者设置环境变量。我的做法是基于官方镜像做一层薄封装把引导配置通过环境变量注入这样镜像本身不需要改动不同环境靠环境变量区分。具体来说Seata 2.x 支持通过 SEATA_CONFIG 相关的环境变量指定配置中心类型和地址这个机制在容器编排时非常方便。另一种做法是自己写 Dockerfile把 application.yml 打进镜像。这种方式适合配置相对固定的场景但灵活性差一些每次改配置都要重新构建。我倾向于环境变量方案配合 Nacos 的 namespace 隔离一套镜像跑多个环境运维成本最低。2. 核心配置细节与实操要点拆解2.1 Seata Server 端的关键配置项Seata Server 的配置分两块引导配置告诉 Server 去哪找配置中心和业务配置事务分组、存储模式、线程池等。引导配置在 2.x 里通过 application.yml 或者环境变量提供核心是这几项seata: config: type: nacos nacos: server-addr: 127.0.0.1:8848 namespace: seata-config group: SEATA_GROUP >seata: tx-service-group: my_tx_group命名上建议用有业务含义的名字比如order_tx_group、inventory_tx_group不要用默认的my_test_tx_group否则多个业务线混在一起排查问题时分不清谁是谁。2.3 客户端接入的依赖与配置要点Spring Cloud 项目接入 Seata 2.x依赖主要是seata-spring-boot-starter版本要和 Server 端保持一致至少大版本要一致。2.x 的 starter 内部已经集成了对 Nacos 配置中心的支持不需要额外引 seata-config-nacos 之类的包1.x 时代需要。客户端配置的关键项seata: enabled: true application-id: order-service tx-service-group: order_tx_group service: vgroup-mapping: order_tx_group: default registry: type: nacos nacos: server-addr: 127.0.0.1:8848 namespace: seata-registry group: SEATA_GROUP config: type: nacos nacos: server-addr: 127.0.0.1:8848 namespace: seata-config group: SEATA_GROUP注意application-id要和 Nacos 注册中心里注册的服务名一致否则 Seata 在事务协调时找不到对应的服务实例。这个细节在文档里不太显眼但实际排查时经常是问题根源。2.4 数据源代理的配置陷阱Seata 的 AT 模式依赖数据源代理来拦截 SQL、生成 undo log。Spring Cloud 项目里如果用默认的 HikariCP 数据源Seata 的自动配置会尝试包装它。但如果你自己手动配置了 DataSource Bean自动代理可能不生效表现为事务回滚时 undo log 没生成数据没回滚。解决办法是显式配置seata.enable-auto-data-source-proxytrue默认就是 true并确保你的 DataSource Bean 没有被Primary之外的逻辑绕过。更稳妥的做法是用 Seata 提供的DataSourceProxy手动包装Bean Primary public DataSource dataSource(DataSourceProperties properties) { HikariDataSource ds properties.initializeDataSourceBuilder() .type(HikariDataSource.class).build(); return new DataSourceProxy(ds); }手动包装的好处是可控坏处是要自己管理连接池参数。两种方式选一种即可不要混用混用会导致代理套代理性能下降还可能出诡异问题。3. 完整部署与整合实操流程3.1 Nacos 环境准备与命名空间规划先确认 Nacos 已经跑起来版本建议 2.x和 Seata 2.x 配套。登录 Nacos 控制台创建两个命名空间一个给 Seata 配置用比如seata-config一个给服务注册用比如seata-registry。命名空间 ID 可以自定义建议用有意义的字符串而不是自动生成的 UUID方便在配置文件里引用。然后在配置命名空间下创建配置项Data ID 为seataServer.propertiesGroup 为SEATA_GROUP内容就是 Seata Server 的业务配置。这里贴一份我实际用的配置骨架transport.typeTCP transport.serverNIO transport.heartbeattrue transport.enableClientBatchSendRequesttrue transport.threadFactory.bossThreadPrefixNettyBoss transport.threadFactory.workerThreadPrefixNettyServerNIOWorker server.recovery.committingRetryPeriod1000 server.recovery.asynCommittingRetryPeriod1000 server.recovery.rollbackingRetryPeriod1000 server.recovery.timeoutRetryPeriod1000 server.maxCommitRetryTimeout-1 server.maxRollbackRetryTimeout-1 server.rollbackRetryTimeoutUnlockEnablefalse store.modedb store.db.datasourcedruid store.db.dbTypemysql store.db.driverClassNamecom.mysql.cj.jdbc.Driver store.db.urljdbc:mysql://127.0.0.1:3306/seata?useUnicodetruerewriteBatchedStatementstrue store.db.userseata store.db.passwordseata123 store.db.minConn5 store.db.maxConn30 store.db.globalTableglobal_table store.db.branchTablebranch_table store.db.lockTablelock_table store.db.queryLimit100 store.db.maxWait5000 service.vgroupMapping.order_tx_groupdefault service.vgroupMapping.inventory_tx_groupdefault存储模式用 db数据库连接指向提前建好的 Seata 库。service.vgroupMapping那几行就是事务分组映射有几个业务分组就写几行。3.2 Seata Server 容器启动与参数注入用 Docker 启动 Seata Server关键是把引导配置通过环境变量传进去。Seata 2.x 支持SEATA_CONFIG_TYPE、SEATA_CONFIG_NACOS_SERVER_ADDR这类环境变量但不同小版本的环境变量命名略有差异稳妥的做法是挂载一个精简的 application.yml 到容器里或者用-e传 JVM 参数。我实际用的启动命令docker run -d \ --name seata-server \ -p 8091:8091 \ -p 7091:7091 \ -e SEATA_IP127.0.0.1 \ -e SEATA_PORT8091 \ -e CONSOLE_PORT7091 \ -e SEATA_CONFIG_TYPEnacos \ -e SEATA_CONFIG_NACOS_SERVER_ADDR127.0.0.1:8848 \ -e SEATA_CONFIG_NACOS_NAMESPACEseata-config \ -e SEATA_CONFIG_NACOS_GROUPSEATA_GROUP \ -e SEATA_CONFIG_NACOS_DATA_IDseataServer.properties \ -e SEATA_REGISTRY_TYPEnacos \ -e SEATA_REGISTRY_NACOS_SERVER_ADDR127.0.0.1:8848 \ -e SEATA_REGISTRY_NACOS_NAMESPACEseata-registry \ -e SEATA_REGISTRY_NACOS_GROUPSEATA_GROUP \ seataio/seata-server:2.0.08091 是 Seata 的 RPC 端口7091 是控制台端口2.x 新增的 Web 控制台可以查看事务状态。SEATA_IP要填客户端能访问到的地址容器部署时如果客户端在宿主机或其他容器这里不能填 127.0.0.1要填宿主机的局域网 IP 或者容器网络里的可达地址。这个坑我踩过——填了 127.0.0.1 之后客户端能注册但事务协调时连不上报连接超时排查了半天才发现是 IP 问题。启动后看日志出现Server started, listen port: 8091就说明起来了。再去 Nacos 注册中心看应该能看到seata-server这个服务实例。3.3 Spring Cloud 客户端接入与验证客户端项目引入依赖dependency groupIdio.seata/groupId artifactIdseata-spring-boot-starter/artifactId version2.0.0/version /dependency配置文件按 2.3 节的模板填好重点是tx-service-group和vgroup-mapping要对上registry和config的 Nacos 地址、namespace 要和 Server 端一致。验证分两步先看客户端启动日志里有没有RM will register resource和TM register success之类的信息有就说明注册成功再写一个简单的分布式事务场景——两个服务一个扣款一个扣库存用GlobalTransactional注解标注入口方法故意在扣库存后抛异常看扣款是否回滚。回滚成功说明整条链路通了。这里有个验证技巧在 Seata 控制台7091 端口能看到全局事务的 XID 和分支事务状态事务执行后去控制台查能看到分支注册和回滚记录比翻日志直观。3.4 数据库表与 undo log 的初始化Seata AT 模式需要在每个业务库建一张undo_log表这个表不是可选的没有它事务回滚时会报错。建表脚本在 Seata 仓库的 script/client/at/db 目录下MySQL 版本大致是CREATE TABLE IF NOT EXISTS undo_log ( branch_id BIGINT NOT NULL COMMENT branch transaction id, xid VARCHAR(128) NOT NULL COMMENT global transaction id, context VARCHAR(128) NOT NULL COMMENT undo_log context, rollback_info LONGBLOB NOT NULL COMMENT rollback info, log_status INT NOT NULL COMMENT 0:normal status,1:defense status, log_created DATETIME(6) NOT NULL COMMENT create datetime, log_modified DATETIME(6) NOT NULL COMMENT modify datetime, UNIQUE KEY ux_undo_log (xid, branch_id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENTAT transaction mode undo table;每个参与全局事务的业务库都要建别漏。另外 Seata Server 自己的库存 global_table、branch_table、lock_table也要提前建好脚本在 script/server/db 目录下。这两个库可以分开也可以合并我习惯分开Server 库独立业务库各自建 undo_log职责清晰。4. 常见问题排查与避坑经验实录4.1 客户端报 no available service 的排查路径这个错误几乎是接入 Seata 时最高频的问题。报错信息大致是no available service default found, please make sure registry config correct。排查顺序建议这样走先确认 Server 是否注册到了 Nacos去注册中心看seata-server实例在不在健康状态是不是 UP。如果不在检查 Server 的 registry 配置和 Nacos 地址。如果在再看客户端的tx-service-group和 Server 端vgroupMapping是否一致——客户端配的是order_tx_groupServer 端映射里也必须有service.vgroupMapping.order_tx_groupdefault少一个字符都不行。最后检查客户端和 Server 的 Nacos namespace 是否一致客户端连的是seata-registryServer 注册的也必须是同一个 namespace跨 namespace 是发现不了的。我遇到过一次特别隐蔽的情况Server 端配置中心里的vgroupMapping写的是order_tx_group客户端配的是order-tx-group中划线 vs 下划线肉眼几乎看不出来排查了快一个小时。所以命名统一用下划线别混用。4.2 事务不回滚的几种典型原因GlobalTransactional注解加了但事务不回滚常见原因有这么几类。第一类是异常被吞了——方法内部 try-catch 了异常但没有重新抛出Seata 感知不到异常就不会触发回滚。这种情况要么把异常抛出去要么手动调用GlobalTransactionContext.reload(RootContext.getXID()).rollback()。第二类是数据源没被代理前面 2.4 节说过undo log 没生成回滚时无据可依。第三类是跨服务调用没走 Feign 或者 RestTemplate 的 Seata 增强分支事务没注册上全局回滚时这个分支被忽略。还有一种情况是事务超时。Seata 默认全局事务超时时间不算长业务逻辑执行久了会超时回滚但业务代码可能已经提交了部分操作。这种要在GlobalTransactional上显式设置timeoutMills根据业务实际耗时留足余量。4.3 Nacos 配置拉取失败的排查Server 启动时报can not get config from nacos或者配置项为空先检查 Nacos 里配置项的 Data ID、Group、namespace 三要素是否和 Server 端配置完全一致。Data ID 大小写敏感seataServer.properties和seataserver.properties是两个不同的配置项。Group 默认是DEFAULT_GROUP如果你建配置时用了SEATA_GROUPServer 端也要配SEATA_GROUP。另一个常见原因是 Nacos 的鉴权。如果 Nacos 开了鉴权Server 端配置里要带 username 和 password环境变量方式传的话是SEATA_CONFIG_NACOS_USERNAME和SEATA_CONFIG_NACOS_PASSWORD。没带的话 Nacos 返回 403日志里能看到权限相关的错误。4.4 常见问题速查表现象可能原因排查动作no available service分组映射不一致 / namespace 不一致核对 vgroupMapping 与 tx-service-group核对两端 namespace事务不回滚异常被吞 / 数据源未代理 / 分支未注册检查异常抛出、DataSourceProxy、Feign 拦截器配置拉取失败Data ID/Group/namespace 不匹配 / 鉴权三要素逐字核对检查 username/password连接超时SEATA_IP 填了 127.0.0.1改为客户端可达的 IPundo_log 表不存在业务库未建表每个业务库执行建表脚本控制台打不开7091 端口未映射检查 docker run 的 -p 参数4.5 生产环境的几条实操心得第一Seata Server 不要单点部署。生产环境至少两个实例注册到同一个 Nacos 集群客户端会自动负载。Server 本身是无状态的db 存储模式下多实例没有数据同步问题。第二事务日志表要定期清理。global_table、branch_table会随事务量增长虽然 Seata 有自动清理机制但高并发场景下建议配一个定时任务归档历史数据避免表膨胀影响性能。第三store.db.maxConn别设太小。默认值在高并发下容易成为瓶颈根据实际事务量调整一般 30 到 50 之间比较稳妥同时观察数据库连接池的使用率。第四升级 2.x 时注意配置项迁移。1.x 的 file.conf 里的配置项在 2.x 里有些改了名字比如service.disableGlobalTransaction在 2.x 里语义有调整升级前对照官方迁移文档逐项核对别直接复制旧配置。第五客户端和 Server 版本尽量保持一致。2.0.0 的客户端配 2.1.0 的 Server 一般能跑但跨大版本比如 1.7 客户端配 2.0 Server大概率出问题协议层有变化。这套方案我在几个中等规模的微服务项目里跑过事务量不算特别高但场景比较杂有跨库的、有跨服务的、也有混合消息队列的。整体跑下来 Seata 2.x 的稳定性比 1.x 好不少尤其是配置中心解耦之后环境切换和灰度发布方便很多。真正花时间的不是部署本身而是把事务分组、数据源代理、异常传播这几件事理清楚这几处理顺了后面基本就是按部就班。如果你们团队正在做类似的事情建议先在测试环境把回滚链路完整验证一遍包括各种异常场景别等上了生产再补课。