1
如上图，目前seata和业务都是虚拟机部署，且业务服务使用seata是直接虚拟机ip:port的方式。云化后，再部署一套seata容器化节点。集群内的业务使用集群内的seata节点（通过nacos高可用的方式），集群外的不变。想确认一下：
- 这种渐进式方案是否可行？通过使用同一套数据库做无状态使用是否有问题？
- 还未结束的事务，业务迁移到集群内还能继续么？
Q
[seata]seata容器化部署+注册中心使用并行是否会有问题
A
回答
0
@slievrly
5
建议先将ip:port方式部署的集群改到nacos上（client可以继续保持ip:port），seata-server都接入nacos后，此时client再去接入nacos，这样可以平滑升级 client接入nacos后再把seata-server切到k8s中部署（切换cluster），client部署到k8s中切换事务分组且对应上nacos上seata-server的cluster，也就是事务分组的value=seata-server的cluster 然后将虚拟机中的client浏览器迁移到k8s上的client，迁移后，下线虚拟机client，下线虚拟机seata-server
2
@lin1005q 共享存储是一种可行的方案。
@a364176773 说的这种方案实际上多套seata集群注册到同注册中心，通过切换事务分组的映射关系来切换流量。这个在上图中的架构实际上是有几个问题：1. VM形态的seata-server注册到nacos要做停顿业务 2. 如果VM和K8S使用相同事务分组切换的方式必定只会路由到一套集群，VM client到K8S seata-server我觉得是网络不通的以及VM client 是否能连接K8S Nacos。
0
还有几个没提到的
- 目前整体目标是为了上k8，肯定是渐进式。迁移是服务级的。
- 现在业务使用的是spring cloud g版本，全部注册到eureka注册中心。只是 vm seata没有注册，也可能是历史原因
- 因为cloud版本太老了，所以我们现在要求各系统新建或者迁移使用cloud 2021版本。
- 目标是上k8后业务都用新的seata 新的nacos，但迁移应该跨系统分布式事务应该没影响
- 已经做了nacos sync来同步双注册中心数据 这边所有系统所有微服务都在注册中心一个大平面里面。
- 这边系统比较多有十几个涉及财务，仓储。
- vm确实无法直通pod ip
- nacos可以通过nodeport暴露。
- 我没明白您说的共享存储什么意思
- 目前所有系统所有微服务都使用同一个事务group
6
目前用1.3.0，计划升级1.5。支持metric监控。 集群内和集群外不同版本是否可行。集群外保持不变，集群内上1.5。
2
In my impression, the upgrade of 1.3. X - > 1.5. X will involve the change of Seata server backend database script.
1
是的，想起来了。
7
想到另一种思路，看看有没有问题。
- 为虚拟机的两个副本添加一个vip。 新的业务使用vip:port接入,老业务暂时不改动。
- 在k8中部署一个容器化实例，并把该容器化实例的nodeport加入到vip后端节点中。这样新业务可以使用到3个节点（vm2+docker1），旧的业务要求逐步更换ip，将两个物理ip替换为一个vip地址。
- 扩容k8中的节点数量，停止vm的一个节点。
- 继续扩容k8，停止vm最后一个节点。
不确定点有以下
- seata是否支持4层代理，是否需要做会话保持
- 老业务停机更换物理ip为vip。对业务是否会有影响？
@a364176773 麻烦了
0
1.seata-server不支持4层代理,会存在二阶段无法成功下发的情况, 2.vip肯定不行的,必须使用注册中心,或者ip固定,否则存在如上问题
3
建议做注册中心+配置中心通过事务分组来切流量
0
@a364176773 #4676 我看了这个pr只是在客户端通过元数据发现seata-server的公网ip+port 。 但是您不是说不支持4层代理么？ 这个是怎么解决的？
3
@slievrly https://github.com/seata/seata/issues/2847#issuecomment-651530457 https://github.com/seata/seata/issues/4897#issuecomment-1232914671 https://github.com/seata/seata/issues/4897#issuecomment-1250113434 您好，请再确认一下 基于共享存储(mysql)的方案，是否支持f5高可用负载使用，目前想要求业务组逐步迁移到f5地址，f5后面接nodeport类型的容器版服务和现有的虚拟机服务 。 同时f5开启http check :7091/health
1
不支持这么搞的，rm需要知道所有tc的地址
1
通过注册中心获取到所有存活可用的tc连接对每个tc都做长连接
4
那k8暴露的nodeport实际是无法被业务所使用？只能被集群内服务使用？
4
通过podip呀，seata-server注册到nacos上，暴露出podip，业务应用也在k8snode内，不也是pod上呀，也通过nacos服务发现连接到seata-server的pod
6
我想集群内的seata服务被集群外的业务使用
3
没有问题呀，网络打通就行了
1
我们这vm直接跟pod都通的，我们基建都是vm部署，如果不同pod怎么用那些基建，比如zk，kafka
7
vm和pod不通就没法用了对吧
3
让你们运维负责网络的打通掉，不好干就一个node一个pod，或者公有云就用lb，一个tc一个lb，或者像我之前说的，vm一个集群，pod一个集群，网关把流量从vm切到pod上，再关停vm
7
好的，感谢