seata中我用服务A调用服务B，A发生异常，B并没有回滚，服务B日志打印，是什么原因呢？

在Seata中，您遇到的问题是服务A调用服务B，尽管两者的方法上都添加了@GlobalTransactional注解，并且服务B的数据插入操作成功，但当服务A发生异常时，服务B的事务并未如预期那样回滚。从服务B日志中看到事务提交状态为“Committed”，这表明事务被正常提交而非回滚。针对这一情况，我们可以分析以下可能的原因及解决步骤：

1. 事务传播行为不正确: 确保服务A调用服务B时，事务的传播行为设置正确。默认情况下，如果服务B的事务配置为REQUIRED或REQUIRES_NEW，理论上应能正确参与到全局事务中。检查服务B的事务配置，确保它能够正确嵌套到服务A开启的全局事务里。

2. Seata配置问题:

   • 检查application.properties或相应的配置文件中，seata.txc.txServiceGroup是否配置正确，确保所有服务都指向同一个GTS服务实例。
   • 验证seata.txc.accessKey和seata.txc.secretKey是否配置正确，以确保鉴权无误。

3. Seata服务端与客户端版本兼容性: 确认Seata服务端与客户端版本之间是否存在兼容性问题，不匹配的版本可能导致事务处理逻辑异常。

4. 网络通信问题: Seata依赖于RPC通信来协调事务。检查Seata服务端与客户端之间的网络连接，确保没有防火墙或网络策略阻止必要的通信。

5. Seata事务XID传递: 确保在微服务调用链路中，全局事务ID（XID）被正确传递。任何中断XID传递的环节都将导致事务无法关联，从而影响事务一致性。

6. Seata事务超时设置: 查看Seata事务的超时时间设置，过短的超时时间可能导致事务在未接收到回滚指令前已自动提交。

7. 日志深入分析: 详细查看Seata服务端和客户端的日志，特别是错误日志和事务处理流程相关的日志，寻找是否有其他异常信息提示，比如网络超时、资源锁定失败等。

8. Seata事务模式确认: 确认Seata配置中的事务模式（如AT、TCC等）是否符合您的业务需求，不同的模式有不同的执行逻辑和要求。

9. 资源管理器配置: 确保数据库等资源管理器已正确集成并配置于Seata中，以便Seata能够对这些资源进行事务控制。

根据上述分析，请逐一排查并调整相关配置或代码逻辑。如果问题依旧存在，建议收集详细的系统环境信息、Seata配置详情以及完整的日志记录，进一步寻求专业支持或在Seata社区寻求帮助。

参考知识库资料： - [1] Seata 应用样例 - [2] 基于 Seata 的 Spring Cloud 应用样例您可以复制页面截图提供更多信息，我可以进一步帮您分析问题原因。