Seata 这名字在微服务圈子里，但凡搞过分布式事务的人应该都不陌生。之前一直在裸机或 K8s 里部署它，最近因为要快速给一个内部项目搭建一套可复现的分布式事务环境，我把 Seata 的部署方式仔细捋了一遍，发现直接拿 Docker 跑最省心——不用装 JDK、不用配 MySQL 客户端、不用手工初始化一堆配置，一条 docker run 就能把 Server 端拉起来。这篇文章我就围绕 Docker 部署 Seata 这件事，把架构思路、核心配置、实际踩坑和排障技巧一次性讲透，力求让你照着操作就能顺利跑通。

1. 部署前必须理解的 Seata 核心机制与容器化思路

1.1 三个角色一条链路：TC、TM、RM 到底在干嘛

很多人在部署 Seata 时容易陷进“配好环境就行”的误区，一上来就拉镜像、改配置、启动容器，结果后面集成微服务时怎么都注册不上、事务不生效，回头排查才发现是根本没理解 Seata 的工作机制。所以在敲任何 docker 命令之前，建议先花十分钟把这套模型捋清楚。

Seata 的核心是 AT 模式，也可以理解成一种“增强版两阶段提交”。它把参与分布式事务的组件拆成了三个角色：

• TC（Transaction Coordinator）：事务协调者，就是 Seata Server 本身，负责维护全局事务的状态、分支事务的提交回滚决策。
• TM（Transaction Manager）：事务管理器，通常嵌入在业务发起方的服务里，负责开启全局事务、提交或回滚全局事务。
• RM（Resource Manager）：资源管理器，同样嵌入在业务服务里，负责管理分支事务的资源（比如数据库连接）、上报分支状态，并执行 TC 下发的提交或回滚指令。

部署 Seata Server 的本质就是部署 TC 这个角色。而 TM 和 RM 是通过在你自己的微服务里引入客户端依赖、加上配置来激活的。这也就解释了为什么很多人光把 Server 端跑起来没用——业务服务没有正确接入，TC 只是个空架子。

从实现细节上看，AT 模式之所以受欢迎，是因为它对业务代码的侵入性极低。核心原理是通过代理数据源，在业务 SQL 执行前后自动记录 undo_log 日志。如果全局事务需要回滚，RM 根据 undo_log 里的镜像数据反向生成补偿 SQL，把数据恢复原状。这里的核心库需要一张 undo_log 表，这个我在后面部署环节会详细说。

1.2 为什么用 Docker 部署：一致性、隔离性与快速迁移

早期我在本地环境部署 Seata 时，Mac 上一套、Linux 服务器上一套、测试环境再一套，每套的环境变量、JDK 版本、配置中心连接串都可能不太一致。一旦某个环境出问题，往往要花半天去比对差异。后来改成 Docker 部署，相当于把 Seata Server 连同它的运行环境整个打包，镜像在哪跑，环境就是什么样。

用 Docker 跑 Seata 还有几个很实际的好处：

• 环境隔离：Seata Server 依赖 JDK、依赖配置读取、依赖日志目录。容器把这些全部隔离在自己文件系统里，不会污染宿主机。
• 快速扩容：后续并发上来想多开几个 TC 实例，直接复制一份容器配置、修改端口映射即可，不需要再重复装环境。
• 版本切换方便：想从 1.5 升到 1.8，拉个新镜像重新映射配置就行，旧环境想保留也容易。

当然，容器化不等于无脑化。Seata 是状态敏感的应用，它依赖外部存储来持久化事务状态，所以部署容器时必须把配置文件、日志目录和外部存储关系想清楚。这些我在第 3 部分会展开讲。

2. Docker 部署的准备工作与选型解析

2.1 镜像选型：官方镜像、版本号与扩展镜像的差异

Seata 的镜像在 Docker Hub 上的命名是 seataio/seata-server，社区维护，推送频率还算稳定。拿最新稳定版来说，目前推荐用 1.8.x 系列，也是主流 Spring Cloud Alibaba 版本能够良好兼容的版本。如果用太老的 1.4.x，虽然也能跑，但在配置结构和部分 API 上会跟新版本有差异，排查问题的资料也少。

镜像标签的选择有个小技巧：如果你本地网络拉取 Docker Hub 的速度不理想，可以直接换用国内常见的镜像仓库地址，前缀替换成 registry 服务商地址，后面的 seataio/seata-server:1.8.0 照抄即可。这里不做具体推荐，但你应该能理解它的原理。

另外说明一下，官方镜像默认用的配置是 file.conf 和 registry.conf 的组合，注册中心、配置中心默认都是 file 模式。如果你的环境里已有 Nacos，想在容器里直接读取 Nacos 上的配置，建议不要手工改镜像里的配置，而是通过挂载卷的方式把宿主机准备好的配置文件覆盖进去。这样镜像本身保持纯净，配置跟镜像解耦，后续升级版本时也方便。

2.2 外部依赖规划：注册中心、配置中心与数据库的选择

Seata Server 运行过程中有两个外部依赖要提前选型，很多时候部署失败就是因为这两块没提前规划好。

第一个是注册中心。Seata Server 需要让业务服务（TM/RM）找到它。如果客户端和服务端不在同一个注册中心体系里，服务端即使启动了，客户端也发现不了它。常见的注册中心有 Nacos、Consul、Eureka、ZooKeeper 等。国内微服务生态基本集中在 Nacos，所以我下面的方案也都默认采用 Nacos 作为注册中心。

第二个是配置中心。Seata 服务端本身有很多配置，比如事务组名、锁超时时间、日志级别等。默认情况下它读取本地 file.conf，如果你有多台 TC 实例要保持配置一致，建议把配置托管到 Nacos Config。这样做的好处是修改配置不需要逐个进容器改文件，重启应用后自动拉取最新配置。

第三个是存储端。Seata 的事务会话信息、全局锁信息、分支事务状态，都要落库。默认 file 模式会把数据写在本地文件里，容器一删数据就没了，而且不支持多实例共享。生产环境必须使用数据库模式，官方支持 MySQL、PostgreSQL、Oracle 等。我一般选 MySQL 8.x，部署简单、运维也熟悉。需要注意，使用 db 模式时要在数据库里执行官方提供的 SQL 脚本，建出三张核心表：global_table、branch_table、lock_table。

选型时还有一个容易忽略的点：客户端和服务端的版本号必须匹配，尤其是注册中心、配置中心的版本。Nacos 2.x 的 gRPC 端口和 1.x 不同，如果你用的是 Nacos 2.x，Seata Server 和客户端的配置都必须指定好命名空间、分组、集群名，否则会出现注册成功但临时下线的情况。

2.3 端口规划：服务端口、控制台端口与 Nacos 端口的分配

Seata Server 默认监听 8091 端口，同时还有一个额外的 7091 端口承载管理控制台（从 1.5.0 后开始支持）。容器映射到宿主机时要注意别跟已有服务冲突，尤其是同一个宿主机上要部署多套环境的时候。

另外，如果注册中心用 Nacos，你需要确认业务服务、Seata Server、Nacos 三者之间的网络是互通的。Nacos 2.x 默认使用 8848 端口提供 HTTP 服务，还会占用 9848 作为 gRPC 通信端口。Seata 客户端启动时会根据服务端在 Nacos 上注册的地址去连接，如果防火墙或者安全组只放行了 8091 没放行 9848，就会出现注册成功但连接超时的问题。

端口这块建议在部署前就整理成一份清单，把每台机器的端口占用情况和用途都列清楚。实际项目中我就遇到过 Seata 容器映射的 8091 被宿主机上另一个监控进程占用，导致容器起来了但端口没生效，微服务一直连不上，排查了很久才发现是端口冲突。

3. Docker 部署 Seata Server 的完整实操过程

3.1 环境准备与目录结构梳理

为了减少出错的概率，我建议在宿主机上先把目录结构规划好。以常用的 /opt/seata 为根目录举例：

/opt/seata/ ├── config/ │ ├── registry.conf │ └── file.conf ├── logs/ └── docker-compose.yml

config 目录存放 Seata Server 的配置文件，logs 目录映射容器内的日志输出，docker-compose.yml 用于编排启动。这样做的最大好处是，后续想要调整配置，只需要修改宿主机上的文件，然后重启容器即可，不需要进入容器内部操作。

注意一点，从 Seata 1.5.0 开始，官方对配置方式做了比较大的调整，开始推荐使用 application.yml 方式代替老的 file.conf + registry.conf。不过考虑到网上资料大多还是基于老方式来写的，我这里也以老方式为主来讲解，但是会提醒你版本差异可能带来的问题。如果你用的是 1.6 以上版本，可以优先采用 Nacos 配置中心来管理服务端配置，效果更好，也更贴近官方推荐方向。

3.2 使用 docker run 直接启动 Seata Server

这是最快能跑通的方式。拉取镜像并启动一个基础容器：

docker run -d --name seata-server \ -p 8091:8091 \ -p 7091:7091 \ -e SEATA_IP=192.168.1.100 \ -e SEATA_PORT=8091 \ -v /opt/seata/config:/seata-server/resources \ seataio/seata-server:1.8.0

简单解释一下这里几个关键参数：

• SEATA_IP：指定 Seata Server 注册到注册中心时对外暴露的 IP。这个必须写宿主机上能被业务服务访问到的 IP，不能写容器 IP。如果漏了这个参数，容器会默认取容器内部的网络 IP，业务服务在另一个网段时根本连不上。
• SEATA_PORT：对外服务端口，默认 8091 不用改。
• 挂载卷：把宿主机上准备好的 registry.conf 和 file.conf（或 application.yml）挂载到容器内的 /seata-server/resources 目录，覆盖镜像内的默认配置。

如果只是做本地功能验证，注册中心用 file 模式，事务存储也用 file 模式，上面这组命令足够用。但要注意，每次容器重新创建后，file 模式下的事务数据会丢，所以只能用于学习和功能验证，不能直接上生产。

3.3 使用 docker-compose 编排 Seata、Nacos 与 MySQL

真实项目中不太会把 Seata 单独拎出来跑，通常是 Nacos、MySQL、Seata 一起编排在同一套 Docker 环境里。为了方便复现，我写了一个 docker-compose.yml 松耦合版本，供你参考：

version: "3.8" services: seata-server: image: seataio/seata-server:1.8.0 container_name: seata-server ports: - "8091:8091" - "7091:7091" environment: - SEATA_IP=192.168.1.100 - SEATA_PORT=8091 - SEATA_CONFIG_NAME=file volumes: - /opt/seata/config:/seata-server/resources - /opt/seata/logs:/seata-server/logs restart: always

这段编排文件假设你已经有一个可用的 Nacos 地址（不管是否容器化），Seata Server 启动时会根据挂载进去的 registry.conf 找到 Nacos 并完成注册。如果你希望把 Nacos、MySQL 也一并编排，可以再增加两个 service。但这里有个细节要提醒：MySQL 需要提前把 global_table 等三张表建好，Seata 容器启动后不会自动建表。

docker-compose 相比裸 docker run，最大的价值是可复现、可移交。你可以把整个目录打包给同事，别人只要装好 Docker 引擎，执行 docker compose up -d 就能拉起一套相同环境。对于团队协作来说，这种“环境即配置”的方式比口头描述一百遍都管用。

3.4 初始化数据库脚本与关键表结构解析

无论你选择 db 模式还是后续想用 Seata 的 Saga 模式，数据库里的表结构都得提前准备好。Seata 官方在源码仓库里的 script/server/db 目录下提供了各类数据库的建表 SQL。以 MySQL 为例，需要执行 mysql.sql 文件。

三张核心表的作用分别是：

• global_table：全局事务表，每条全局事务在这里有一条记录，包含事务 ID、状态、应用名等。
• branch_table：分支事务表，记录每个参与者的事务分支状态。
• lock_table：全局锁表，AT 模式在操作记录行时会上全局锁，避免多个全局事务并发修改同一行数据导致数据异常。

表结构本身并不复杂，但需要注意字符集和引擎选择。建议统一使用 InnoDB 引擎，字符集使用 utf8mb4，避免出现中文乱码或者行锁支持问题。

关于 undo_log 表，它不需要建在 Seata 的库里，而是要建在业务服务自己的业务数据库里。因为 undo_log 是 RM（客户端）在执行业务 SQL 前后写入的，每个参与分布式事务的业务库都需要有这张表。很多人在接入 Seata 后事务回滚不生效，排查到最后就是发现业务库少了 undo_log 表。

3.5 file.conf 与 registry.conf 核心配置解读

在 1.5 之前的老版本里，Seata Server 的配置主要在这两个文件里，很多人会被这里搞晕，我这里挑最核心的配置项说明一下。

registry.conf 的作用是告诉 Seata Server 使用什么注册中心和配置中心：

registry { type = "nacos" nacos { application = "seata-server" serverAddr = "192.168.1.100:8848" group = "SEATA_GROUP" namespace = "" cluster = "default" username = "nacos" password = "nacos" } } config { type = "nacos" nacos { serverAddr = "192.168.1.100:8848" namespace = "" group = "SEATA_GROUP" username = "nacos" password = "nacos" } }

file.conf 的主要作用是配置事务组与存储模式。在 1.5 及以上版本中，事务组名等大量配置被建议统一放到 Nacos 配置中心，而存储模式仍然可以在本地指定：

store { mode = "db" db { datasource = "druid" dbType = "mysql" driverClassName = "com.mysql.cj.jdbc.Driver" url = "jdbc:mysql://192.168.1.100:3306/seata?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai" user = "seata" password = "seata123" minConn = 5 maxConn = 20 } }

这里最容易出错的地方是 driverClassName。MySQL 5.x 和 8.x 的驱动类不一样，如果数据库用的 MySQL 8，但配置里写的是老驱动，启动时大概率会报 ClassNotFound 或者连接失败。

另外，Seata 从 1.5 开始还引入了 service 相关配置项，你需要按版本确认事务分组名。客户端配置的事务分组名必须和服务端一致，否则会报类似 no available server 的错误。常见的坑是客户端配置了 my_test_tx_group，而服务端的事务分组名是 default，两边对不上，事务肯定起不来。

4. 微服务客户端接入 Seata 的实操要点

4.1 引入依赖与配置 Nacos 上的 Seata 相关配置

Seata Server 部署好了，只是完成了一半工作。要让分布式事务真正生效，业务服务还需要接入 Seata 客户端。以常见的 Spring Cloud Alibaba 技术栈为例，核心步骤如下。

在业务服务中引入依赖：

<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-alibaba-seata</artifactId> <version>对应版本</version> </dependency> <dependency> <groupId>io.seata</groupId> <artifactId>seata-spring-boot-starter</artifactId> <version>1.8.0</version> </dependency>

然后在 application.yml 中配置：

spring: cloud: alibaba: seata: tx-service-group: my_test_tx_group seata: registry: type: nacos nacos: server-addr: 192.168.1.100:8848 namespace: "" group: SEATA_GROUP config: type: nacos nacos: server-addr: 192.168.1.100:8848 namespace: "" group: SEATA_GROUP

这里的 tx-service-group 是一个逻辑分组名，它会在客户端启动时映射到服务端对应的集群。如果配置不对齐，最典型的症状就是客户端启动后报错：could not found any available seata server。

4.2 数据源代理：AT 模式生效的关键一环

AT 模式能实现无侵入回滚，核心在于对数据源做了代理。Seata 客户端启动时会自动将业务的数据源包装成 DataSourceProxy。如果这一步没生效，后面所有与数据库相关的操作都不会被纳入全局事务。

正常情况下，使用 seata-spring-boot-starter 时会自动完成数据源代理，但有些项目里自己额外加了多数据源配置或者动态数据源，就可能导致代理失效。一个比较稳的兜底方案是手动定义一个数据源 Bean，显式包装：

@Bean @ConfigurationProperties(prefix = "spring.datasource") public DataSource dataSource() { DruidDataSource dataSource = new DruidDataSource(); return dataSource; } @Bean public DataSourceProxy dataSourceProxy(DataSource dataSource) { return new DataSourceProxy(dataSource); }

这样接入以后，业务代码里的普通 SQL 操作都会被 Seata 感知到。如果某个服务不需要参与分布式事务，那就保持普通数据源即可，不必全局代理，避免性能损耗。

4.3 使用 @GlobalTransactional 开启全局事务

在业务发起方的 Service 方法上添加注解，就能把一个调用链纳入同一个全局事务：

@GlobalTransactional(rollbackFor = Exception.class) public void createOrder(OrderDTO orderDTO) { // 1. 创建订单 orderMapper.insert(orderDTO); // 2. 远程调用账户服务扣减余额 accountFeignClient.decrease(orderDTO.getUserId(), orderDTO.getAmount()); // 3. 远程调用库存服务扣减库存 inventoryFeignClient.decrease(orderDTO.getProductId(), orderDTO.getCount()); }

这里要说明的是，@GlobalTransactional 只需要加在最外层的业务发起方法上，被调用的远程服务不需要重复加。TM 在方法开始时向 TC 申请全局事务，拿到 XID 后通过微服务调用链传递下去，RM 根据 XID 把后续分支事务注册到同一个全局事务里。

还有一点值得注意，@GlobalTransactional 的 rollbackFor 建议显式指定异常类型。如果不指定，默认只回滚 RuntimeException，像自定义的 checked exception 就不会触发回滚，这个坑在实际业务中很常见。

4.4 接入后的验证方法与性能开销评估

环境配好以后，不要急着写复杂业务，建议先用一个最小可用的 demo 验证链路是否通。验证点有两类：

第一类验证是注册与心跳。通过 Nacos 控制台查看 seata-server 和 microservice 是否都在线。Seata Server 在 Nacos 上的注册名通常是 seata-server，归属于 SEATA_GROUP 分组。如果看不到服务实例，说明注册中心配置有问题。

第二类验证是事务回滚。发起一个带全局事务的调用，故意让远端服务抛出异常，观察数据库里的数据是否全部回滚。可以在数据库里开启 binlog 或者开启 SQL 日志，观察是否有 undo_log 表插入和删除记录。

接入 Seata 后会带来额外的性能开销。因为 AT 模式需要写 undo_log、获取全局锁，相对普通单库事务确实会慢一些。实测下来，简单 INSERT/UPDATE 场景下耗时大约是普通事务的 1.2 到 1.5 倍。如果业务对延迟极其敏感，又不想牺牲一致性，可以考虑改 TCC 模式或 Saga 模式，但这通常需要更大的改造量。

5. Docker 环境下 Seata 的常见问题与排查技巧实录

5.1 容器内配置读取异常与挂载冲突

很多人在 Docker 环境启动 Seata 时，最先遇到的报错是找不到配置文件或者配置读取失败。画像通常是：自己写了 registry.conf，挂载到容器里，但启动日志显示还是用了镜像内的默认配置。

排查思路是进入容器确认挂载是否生效：

docker exec -it seata-server sh ls -l /seata-server/resources

如果发现容器内看到的还是默认配置，很可能是挂载路径不对。不同镜像版本里 Seata Server 的工作目录可能不同，有些是 /seata-server/resources，有些是 /root/seata/conf。建议先 docker inspect 查看镜像的 WORKDIR，或者直接不挂载整个 config 目录，只挂载单独文件：

-v /opt/seata/config/registry.conf:/seata-server/resources/registry.conf

这样能避免因为目录层级不一致导致整个挂载卷覆盖了镜像原有内容的问题。

5.2 客户端注册成功却连不上 Server 的超时故障

这个问题的表现是：Nacos 控制台里能看到 Seata Server 实例，客户端日志里也能看到注册信息，但真正发起全局事务时却报连接超时或 io exception。

最常见的原因就是 SEATA_IP 配置成了容器内网 IP。客户端拿到注册中心里的地址去连接时，连接的是一个 172.x.x.x 这样的网段地址，业务服务所在宿主机根本路由不到。解决办法是在启动 Seata Server 容器时显式指定 SEATA_IP 为宿主机 IP，或者在 registry.conf 中对 nacos 配置添加 ip 与 port 的显式声明。

还有一种情况是 Nacos 版本与 Seata 版本不兼容，造成临时实例心跳中断。Nacos 2.x 使用 gRPC 端口（默认 9848），如果该端口被防火墙挡掉，客户端和服务端会频繁出现服务列表为空的情况。这个要检查安全组和防火墙策略，同时可以在 Nacos 控制台查看实例是否标记为“不健康”。

5.3 undo_log 表缺失导致回滚静默失败

这个坑非常隐蔽。业务服务成功注册到了 Seata，也生成了全局事务，但是中间服务一旦报错，前面的数据纹丝不动。日志里也看不到明显异常，最多出现 UndoLogException 之类的提示，严重时直接吞掉异常，只留下一条 WARN。

原因十有八九是参与事务的业务库没有建 undo_log 表。这个表不能建在 Seata 的库里，必须建在业务服务自己的数据库里。举个例子，订单服务连接的是 order_db，那么 undo_log 就要建在 order_db 中。如果账户服务连接的是 account_db，那也需要在 account_db 里建一张相同的 undo_log 表。

排查时可以全局搜索日志里的 undo_log 关键字，也可以直接登录业务库查询：

SHOW TABLES LIKE 'undo_log';

如果确实缺失，找到 Seata 官方 SQL 脚本，在对应业务库里执行建表。注意表名必须是小写，字段名也按官方脚本保持一致，不要自行改名，否则客户端写入时会因为表名不匹配而失败。

5.4 容器时间与宿主机时间不一致导致的异常

容器默认使用 UTC 时区，而宿主机往往是 CST 时区。这个时间差虽然在大多数场景下影响不大，但在 Seata 的全局事务超时判断上可能出现问题。如果数据库连接字符串里没有设置 serverTimezone，或者配置文件中没有统一时区，就会导致全局事务创建时间和实际时间有偏差，严重时会出现锁等待超时。

解决方式有两种：一是在 docker-compose 里添加时区挂载：

volumes: - /etc/localtime:/etc/localtime:ro - /etc/timezone:/etc/timezone:ro

二是给 JVM 传递时区参数，通过环境变量 JAVA_OPTS 设置：

-e JAVA_OPTS="-Duser.timezone=Asia/Shanghai"

实际使用时我会两种方式都做，保证时间一致性。这属于部署中很容易忽视但又很重要的细节。

5.5 常见问题速查表

5.6 快速恢复与备份技巧

容器化环境下最实用的经验是：配置文件一定要放在宿主机上，不要改成容器内文件后再 docker commit。这个习惯能让你在镜像升级、容器误删时快速恢复。我曾经遇到过一次容器被清理的情况，因为配置都在宿主机挂载目录里，重新 docker run 一条命令就恢复了全部功能，完全没影响正在进行的联调测试。

另外，事务存储如果是 db 模式，建议对 Seata 数据库做定期备份。global_table、branch_table、lock_table 这三张表的数据量通常不大，但在长事务场景下会保留很多记录。可以写一个简单的定时任务，每天凌晨 dump 一次，防止误删容器导致数据库里的历史事务记录丢失。

6. 从容器化到生产级部署的进阶建议

6.1 多实例部署与高可用设计

单机 Docker 部署 Seata 适合开发联调和中小规模项目，但生产环境对可用性要求更高的时候，建议把 Seata Server 横向扩展成多实例。因为 Seata 的事务状态是存储在数据库里的，所以多实例之间没有无共享状态的问题，天然支持水平扩展。

用 docker-compose 跑两个 seata-server 实例，只需要修改 container_name 和宿主机端口映射，同时保证两个实例注册到同一个 Nacos 集群、使用同一个数据库即可。客户端会从 Nacos 拉取到所有 Seata Server 实例，默认按照负载均衡策略选择其中一个发起事务。

这里有一个坑要提醒：两个实例的 registry.conf 里的 cluster 名称必须一致，否则它们会被 Nacos 认为属于不同集群，客户端只会去找自己事务分组映射的那个集群。更详细的集群概念涉及 Nacos 本身的命名空间和集群配置，初次接触时容易绕晕，建议先在单集群模式下跑通。

6.2 配置管理批量下发与版本回滚策略

多实例部署后，逐个进入容器改配置文件绝对不是一个好方案。我建议把 Seata Server 的配置统一托管到 Nacos Config，然后通过 Nacos 控制台维护一份配置，所有 Seata 实例启动时自动拉取。这样配置变更就是一次发布操作，而且 Nacos 的配置历史可以支持快速回滚。

在实践中，我会在 Nacos 上建一个独立的命名空间，专门放 Seata 相关的配置，避免跟业务服务配置混在一起。同时利用 group 来区分环境，比如 SEATA_GROUP 下面分 dev、test、prod 三套配置。这样同一个 Seata 版本可以适配不同环境的数据库和网络地址，灵活度非常高。

6.3 监控告警与日志采集

容器化以后，日志不像裸机那样直接写在固定目录里，通常需要采集到统一的日志平台才能方便排查。Seata 的日志主要输出到 logs 目录，你可以把日志目录挂载出来，再用采集组件把日志写入检索系统。重点关注日志里的 transactionState 变化、异常堆栈和超时警告。

监控方面，Seata 1.5+ 版本开始支持 metrics 指标，可以暴露给监控系统。你可以通过配置开启 metrics，并用采集器按固定间隔拉取，重点关注几个指标：active global transaction 数量、committed transaction 总数、rollbacked transaction 总数。如果 rollbacked 数量异常增长，说明业务链路里频繁出现异常，需要回头检查服务稳定性和数据一致性。

6.4 与 Kubernetes 环境部署的衔接思考

虽然这篇以 Docker 为主，但如果你所在团队已经全面转向 Kubernetes，Docker 的经验大部分可以平移过去。核心区别在于 K8s 里更强调声明式部署和生命周期管理。你需要把配置做成 ConfigMap，把数据库地址放在 Deployment 的环境变量里，然后通过 Service 暴露 8091 端口。Seata Server 的注册 IP 配置在 K8s 环境里会给客户端带来麻烦，因为我前面提到的 SEATA_IP 在 Pod 漂移时无法保持固定。业内常用方案是结合 K8s 的 Service 或固定网络方案，让 Seata 的注册地址与客户端可达地址保持一致。

7. 写在最后的一些实操心得

我个人在实际操作中体会最深的一点是：部署 Seata 本身并不难，难的是部署前把业务服务和 Seata Server 之间的协调机制想明白。事务分组名、注册中心地址、配置中心命名空间、数据库连接串，这四样东西必须在部署前全部对齐，否则启动以后就是来回撞墙。

最后再分享一个小技巧：如果你不确定当前 Seata 版本与 Spring Cloud Alibaba 版本是否兼容，最直接的办法是去 Spring Cloud Alibaba 官方依赖说明里看它内嵌的 Seata 版本号，然后让 Seata Server 镜像标签与这个版本保持一致。我在一次项目中就吃过版本不一致的亏，客户端用的是 1.5.2，服务端却是 1.4.2，结果服务端日志一直报客户端版本不兼容，浪费了整整一个下午。

这套以 Docker 部署 Seata 的方案，我后来在多个项目里复用，从单机联调到双机高可用都跑得比较稳。希望这篇文章能帮你少走一些弯路，把主要的坑提前绕开。