关于springcloud-alibaba+nacos(注册中心、配置中心)之seata1.1.0版本之坑

关于springcloud-alibaba分布式事务组件seata集成问题

环境：

	jdk 1.8
	springcloud  2.1.1
	seata  1.1.0
	nacos   1.2.1  (配置中心、注册中心)

关于seata集成

当下网上有很多关于springcloud-alibaba全家桶的相关教程，但我大概都浏览了一下（没办法啊！新东西坑比较多），关于分布式事务解决方案seata的整合大都是1.0.0版本以下（可能是网上大佬对于这东西运用的较早），技术肯定要逐步更新的，更何况cloud-alibaba的生态正在逐步完善。好了闲话不鬼扯了直接上问题：
seata版本在1.0.0前到1.1.0版本相关配置差异（这里是我遇到坑的差异，其他的暂时没去管）：

1.关于vgroup_mapping.xxx关键字更改为vgroupMapping.xxx，跟着视频教程走的同学就需要注意自己下载的版本和集成版本配置是否一致了；

如果该配置没有做出相应改变将报错：com.alibaba.fescar.common.exception.FrameworkException: can not connect to fescar-server.
本人此处采坑！！

发现问题：

seata中配置按照官方文档和视频教程修改完毕后服务启动报错：

这里seata服务启动正常且注册到nacos

这里报错是说在收seata分布式事务组件管控的服务不能连接到seata相关服务：no available service ‘null’ found ，NettyClientChannelManager心跳式访问相关服务却一直找不到。
相关配置没毛病，服务启动正常，组件启动正常；但就是连接不上 。。。。 呵呵！
经过我多方请教大神，冲浪查找最后得出个结论：配置问题。这就尴尬了无论是官方文档还是B站视频都没有相关配置说明。。hhh 可能吃嫩螃蟹的人比较少吧，亦或者是我太菜了别人都没摸到的坑 被我一脚给踏了个结实。没办法没有足够的资料只能自己慢慢磨了；蠢办法，报错跟源码：

我这边引入的是seata-all-1.1.0 jar 其中NettyClientChannelManager对象就在，类中reconnect(String transactionServiceGroup)方法就是尝试请求seata服务传入的参数就是seata配置文件中我们自己定义的映射分组vgroupMapping.xxx中的xxx如下图：

接下来是要携带这个参数去注册中心查找相关服务列表：lookup(transactionServiceGroup)这个方法接口衔接了多个注册中心实现：

有兴趣可以看看这些实现，这里不是重点！

但是这里获取相关服务列表居然是null

到这儿我就有些晕了，seata组件配置里是配过这个bakery_tx_group服务映射属性的，咋就找不到呢？后面接着来：

注意：这里就是为啥前面开始时说的检查组件和集成版本问题的原因所在，你看人家这1.1.0版本里查找映射服务前面是写死的就只是差个XXX参数而已！
不用看了前面都没查到服务这里初始化配置肯定没卵用，果不其然它又null了，至此相关源码追完了，但是为啥会找不到服务还是没找到原因。
哎！我本事有限只能靠自己脑瓜子脑补原因-------emmmmm--------------- “臣妾做不到啊！”

“柳岸”摸出一个村儿

作为一个程序员儿的苦恼，问题到这儿了也算是尽力了，但工作还得继续啊！总不能撂挑子吧。 呵呵！ 接着找解决办法：

于是又开始了度娘三千问，但凡是有关seata集成的都爬进去看看---->别看，就是这么卑微。
终于瞄到一个博文上关于从seata源码中导入配置到nacos配置中心的东西，并且吸引了我，没办法既然是配置出错死马当活马医吧！具体操作如下：
从源码https://github.com/seata/seata/tree/develop/script/config-center根目录下下载config.txt文件到/seata，再到nacos目录下下载nacos-config.sh（xshell脚本）或者nacos-config.py （python命令脚本）到seata客户端/seata/conf目录下;再运行相应脚本文件向nacos添加相关配置，我这里是使用git命令行运行命令：

注意：config.txt文件中关于seata相关配置要先改了再运行上面导入命令！
然后检查nacos配置中心多出SEATA_GROUP分组配置如下：

这里关于config.txt文件中的配置信息完全可以根据具体要求去筛选配置，没必要全都导入nacos,很多配置基本上seata内部都有默认，简单的差不多到这个样子就能正常运行了：

#service.default.grouplist=127.0.0.1:8091
#service.enableDegrade=false
service.disableGlobalTransaction=false
store.mode=db
store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.cj.jdbc.Driver
store.db.url=jdbc:mysql://127.0.0.1:3306/nacos_config_seata_manager
store.db.user=root
store.db.password=123456
store.db.minConn=3
store.db.maxConn=30
store.db.globalTable=global_table
store.db.branchTable=branch_table
store.db.queryLimit=100
store.db.lockTable=lock_table

再次跟源码就发现：相关服务列表不再为null

且与nacos中seata服务地址相同：

至此问题终于解决了，NettyClientChannelManager不再报错：

终于“花明”了

现在问题是解决了，但是原因还没有找到，心有不甘，又去看了一下官网爬了几篇文章终于明白了：seata 1.1.0 不再依赖于服务注册配置：registry.conf 默认根据seata组件注册配置：

直接就默认注册到了相关注册中心，并将相关配置托付于nacos配置中心，读取nacos配置中心里相关配置，来获取注册服务信息，具体操作在这儿：

在这个地方会默认发送get请求到nacos来获取相应配置,我们把url提出来就是这个样子：

返回结果：


注意，这里面的参数来自配置信息的千万不能错，否则拿不到hosts数据
关于这个获取配置信息追源码的过程我就不陈述了，直接引用一篇文章，这里面描述步骤很详细，一般的配置问题都可以这么去跟：
https://www.freesion.com/article/7552502508/

可能是版本更新生态发展比较快，官方文档不是很健全，比如没有说明整合服务是直接通过组件配置来默认nacos配置中心配置来获取seata服务注册信息。

到这儿此坑终于爬出来了，真是不容易！以上是个人理解，如有不足之处希望各位看官能给与评论指正。

本来老早的笔记直到今天才空下来发文，发现已经有小哥和我踩过相同的坑且发过文了，下面是他的文章给大家分享一下，没看明白的可以看看：
一篇相似问题的文章：https://blog.csdn.net/VincentGTX_huang/article/details/106499162