对seata的seata.tx-service-group理解

事务分组是什么？​

• 事务分组：seata的资源逻辑，可以按微服务的需要，在应用程序（客户端）对自行定义事务分组，每组取一个名字。
• 集群：seata-server服务端一个或多个节点组成的集群cluster。 应用程序（客户端）使用时需要指定事务逻辑分组与Seata服务端集群的映射关系。

事务分组如何找到后端Seata集群？​

1. 首先应用程序（客户端）中配置了事务分组（GlobalTransactionScanner 构造方法的txServiceGroup参数）。若应用程序是SpringBoot则通过seata.tx-service-group 配置
2. 应用程序（客户端）会通过用户配置的配置中心去寻找service.vgroupMapping .[事务分组配置项]，取得配置项的值就是TC集群的名称。若应用程序是SpringBoot则通过seata.service.vgroup-mapping.事务分组名=集群名称 配置
3. 拿到集群名称程序通过一定的前后缀+集群名称去构造服务名，各配置中心的服务名实现不同（前提是Seata-Server已经完成服务注册，且Seata-Server向注册中心报告cluster名与应用程序（客户端）配置的集群名称一致）
4. 拿到服务名去相应的注册中心去拉取相应服务名的服务列表，获得后端真实的TC服务列表（即Seata-Server集群节点列表）

为什么这么设计，不直接取服务名？​

这里多了一层获取事务分组到映射集群的配置。这样设计后，事务分组可以作为资源的逻辑隔离单位，出现某集群故障时可以快速failover，只切换对应分组，可以把故障缩减到服务级别，但前提也是你有足够server集群。

对于文档说的为何不直接取服务名的理解：

假如我们有两个微服务serviceA ，serviceB要在同一个seate-server集群进行分布式事务，如果直接取服务名，那么要在serviceA，serviceB都写服务名seate-server1，假如seata-server1挂了，我们要修改成seata-server2，岂不是要修改每个serviceA，serviceB的配置。

如果引入了seata.tx-service-group，我们每个serviceA，serviceB都配置相同的seata.tx-service-group=project1，然后配置中心映射project1对应的是seate-server1，如果seate-server1挂了，我们只需要修改配置中心，把project1映射到seata-server2，都不需要修改每个serviceA，serviceB的配置